Obsidium1341ObsidiumSoftware

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 this signature in Azure Sentinel allows the SOC team to distinguish between expected software deployments and anomalous instances that could indicate unauthorized installations or early-stage compromise vectors.

YARA Rule

rule Obsidium1341ObsidiumSoftware
{
      meta:
		author="malware-lu"
strings:
		$a0 = { EB 01 ?? E8 2A 00 00 00 EB 04 [4] EB 02 [2] 8B 54 24 0C EB 03 [3] 83 82 B8 00 00 00 21 EB 02 [2] 33 C0 EB 03 [3] C3 EB 02 [2] EB 01 ?? 64 67 FF 36 00 00 EB 01 ?? 64 67 89 26 00 00 EB 02 [2] EB 03 [3] 50 EB 04 [4] 33 C0 EB 02 [2] 8B 00 EB 04 [4] C3 EB 02 [2] E9 FA 00 00 00 EB 02 [2] E8 D5 FF FF FF EB 01 ?? EB 01 ?? 58 EB 03 [3] EB 04 [4] 64 67 8F 06 00 00 EB 04 [4] 83 C4 04 EB 02 [2] E8 C3 27 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 5 specific false positive scenarios for the Obsidium1341ObsidiumSoftware detection rule, including suggested filters and exclusions:

• Scenario: Scheduled Endpoint Security Updates

  • Context: The Obsidium software agent performs nightly updates or policy synchronization with the central management server. This process often spawns a background service that matches the YARA signature for legitimate software execution but mimics suspicious behavior due to network connectivity and file writes during off-hours.
  • Filter/Exclusion: Create an exclusion based on the specific process name (e.g., ObsidiumAgent.exe) running under the SYSTEM or a dedicated service account (e.g., DOMAIN\ObsidiumSvc). Additionally, filter alerts occurring between 01:00 and 05:00 local time to exclude scheduled maintenance windows.

• Scenario: Deployment via Configuration Management Tools

  • Context: IT administrators use tools like Microsoft Endpoint Configuration Manager (MECM/SCCM) or Ansible to push Obsidium software updates or configuration changes to a fleet of workstations. The installation or update process triggers the rule as it writes files and registers services, which can be misinterpreted as an unauthorized software deployment event.
  • Filter/Exclusion: Exclude events where the parent process is ccmsetup.exe (SCCM) or ansible-runner. Alternatively, filter by the specific installation package name or GUID associated with the Obsidium update bundle to distinguish it from ad-hoc user installations.

• Scenario: Automated Backup and Archiving Tasks

  • Context: Enterprise backup solutions like Veeam Agent for Windows or Rubrik often integrate with security agents to ensure data integrity during backups. When these tools scan or archive Obsidium-related log files or configuration databases, the file access patterns can trigger the rule’s logic regarding software behavior and