Obsidium1258ObsidiumSoftware

Hunt Hypothesis

This detection identifies the presence of Obsidium software components within the environment by matching file signatures against a specific YARA rule to establish a baseline for legitimate application behavior. Proactive hunting is essential in Azure Sentinel to distinguish these known good artifacts from potential false positives or unauthorized deployments that could obscure malicious activity during incident response.

YARA Rule

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

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 Obsidium1258ObsidiumSoftware detection rule, including targeted exclusion strategies:

• Scenario: Scheduled Antivirus Definition Updates via Obsidium Agent

  • Context: The Obsidium endpoint agent runs a nightly scheduled task (e.g., Task Scheduler job named “Obsidium_Def_Update”) to fetch and install the latest malware definition database. This process triggers the YARA rule as it spawns child processes with high I/O activity that matches the rule’s signature for software installation or modification.
  • Filter/Exclusion: Exclude processes where the parent executable path is C:\Program Files\Obsidium\Agent\obsdsvc.exe and the command line contains arguments related to “definition update” or specific scheduled task IDs (e.g., /task:DailyDefUpdate).

• Scenario: IT Admin Deploying Patch via Obsidium Control Console

  • Context: A System Administrator initiates a bulk software deployment using the Obsidium Control Console on a management workstation. The rule triggers when the console pushes configuration profiles or patches to multiple endpoints, generating network traffic and local file writes that mimic potential suspicious software behavior.
  • Filter/Exclusion: Create an exclusion for user accounts belonging to the “IT_Ops” or “Security_Admin” groups (e.g., DOMAIN\IT_OPS, DOMAIN\SOC_ADMIN) when the process is launched from the Obsidium management server IP range (e.g., 10.50.20.x).

• Scenario: Automated Backup Job Utilizing Obsidium Integration

  • Context: A third-party backup solution (such as Veeam or Commvault) configured to integrate with Obsidium runs a daily snapshot job. During the backup window, the integration service triggers file locking and metadata updates that satisfy the YARA rule’s conditions for software