Obsidium1311ObsidiumSoftware

Hunt Hypothesis

This detection identifies the presence of Obsidium software components within the environment to establish a baseline for legitimate application behavior and potential supply chain risks. Proactively hunting for these signatures in Azure Sentinel allows the SOC team to distinguish between expected software usage and anomalous deployments that could indicate unauthorized tooling or early-stage adversary activity.

YARA Rule

rule Obsidium1311ObsidiumSoftware
{
      meta:
		author="malware-lu"
strings:
		$a0 = { EB 02 [2] E8 27 00 00 00 EB 02 [2] EB 03 [3] 8B 54 24 0C EB 01 ?? 83 82 B8 00 00 00 22 EB 04 [4] 33 C0 EB 01 ?? C3 EB 02 [2] EB 02 [2] 64 67 FF 36 00 00 EB 04 [4] 64 67 89 26 00 00 EB 01 ?? EB 03 [3] 50 EB 03 [3] 33 C0 EB 01 ?? 8B 00 EB 03 [3] C3 EB 01 ?? E9 FA 00 00 00 EB 03 [3] E8 D5 FF FF FF EB 01 ?? EB 03 [3] 58 EB 03 [3] EB 01 ?? 64 67 8F 06 00 00 EB 01 ?? 83 C4 04 EB 03 }

condition:
		$a0 at pe.entry_point
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 1 string patterns in its detection logic.

• Source Rule

False Positive Guidance

Here are 4 specific false positive scenarios for the Obsidium1311ObsidiumSoftware detection rule, along with targeted filters and exclusions:

• Scenario: Scheduled Antivirus Engine Updates

  • Context: The Obsidium software often runs as a background service on endpoints to fetch definition updates. During peak update windows (e.g., 02:00 AM), the engine executable (ObsidiumEngine.exe) spawns child processes that match the YARA signature, triggering alerts even though no malicious behavior is occurring.
  • Filter/Exclusion: Create a whitelist exclusion for the specific process path C:\Program Files\Obsidium\bin\ObsidiumEngine.exe and its immediate children when running under the system account (NT AUTHORITY\SYSTEM) during defined maintenance windows (e.g., 01:00–04:00 local time).

• Scenario: Enterprise Endpoint Management Deployment

  • Context: IT administrators use tools like Microsoft Intune or SCCM to push the Obsidium agent installation or configuration updates across the fleet. The deployment scripts invoke the installer (ObsidiumSetup.exe), which generates file system artifacts and registry keys that mimic the rule’s detection logic.
  • Filter/Exclusion: Exclude events where the parent process is a known management tool (e.g., ccmexec.exe for SCCM or IntuneManagementExtension.exe) and the user context is an administrative account (e.g., DOMAIN\IT-Admins).

• Scenario: Automated Patch Management Scripts

  • Context: Internal PowerShell scripts run nightly to audit software versions. These scripts invoke the Obsidium CLI tool (ObsidiumCLI.exe) to query license status or generate compliance reports, causing the YARA rule to trigger on the CLI’s execution and output generation.
  • **Filter/