Obsidium1336ObsidiumSoftware

Hunt Hypothesis

This hunt hypothesis targets the presence of Obsidium software artifacts within the environment to identify potential supply chain exposure or unauthorized legacy applications that may lack modern security controls. Proactively hunting for these signatures in Azure Sentinel allows the SOC team to map the attack surface and assess whether this specific software introduces unique risks requiring enhanced monitoring or remediation strategies.

YARA Rule

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

condition:
		$a0
}

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 Obsidium1336ObsidiumSoftware detection rule, including suggested filters and exclusions:

• Scenario: Automated Endpoint Protection Updates

  • Context: The Obsidium software agent performs scheduled updates or signature downloads via its background service (e.g., ObsidiumService.exe) during off-hours. This process often spawns a temporary worker process that matches the YARA signature, triggering an alert despite being expected behavior.
  • Filter/Exclusion: Create an exclusion rule based on the parent process name and path. Exclude alerts where the parent process is ObsidiumUpdater.exe running from the standard installation directory (e.g., C:\Program Files\Obsidium\Bin\).

• Scenario: IT Admin Script Execution via PowerShell

  • Context: System administrators frequently run custom PowerShell scripts to deploy or configure Obsidium policies across a fleet of machines. When these scripts invoke the Obsidium CLI tool (obsidum-cli.exe) to push configurations, the detection logic flags the CLI invocation as a potential anomaly because it is not running in its standard interactive context.
  • Filter/Exclusion: Implement a filter that suppresses alerts where the command line arguments contain specific administrative keywords (e.g., --deploy, --config-push) and the user account belongs to the “IT_Operations” or “Domain_Admins” security group.

• Scenario: Scheduled Backup and Reporting Jobs

  • Context: The enterprise runs nightly scheduled tasks using Windows Task Scheduler to generate compliance reports from Obsidium data. These jobs execute a batch file that calls the Obsidium reporting engine, which generates temporary log files and processes matching the YARA signature’s heuristics for “suspicious software activity.”
  • Filter/Exclusion: Add an exclusion for specific scheduled task names (e.g.,