diPackerV1XdiProtectorSoftware

Hunt Hypothesis

This detection identifies the presence of DiPacker V1X Protector software, a potentially legitimate application that may be leveraged by adversaries for obfuscation or as a foothold within the environment. SOC teams should proactively hunt for this signature in Azure Sentinel to distinguish between expected business usage and anomalous deployment patterns that could indicate early-stage supply chain compromise or unauthorized tool installation.

YARA Rule

rule diPackerV1XdiProtectorSoftware
{
      meta:
		author="malware-lu"
strings:
		$a0 = { 0F 00 2D E9 01 00 A0 E3 68 01 00 EB 8C 00 00 EB 2B 00 00 EB 00 00 20 E0 1C 10 8F E2 8E 20 8F E2 00 30 A0 E3 67 01 00 EB 0F 00 BD E8 00 C0 8F E2 00 F0 9C E5 }

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 diPackerV1XdiProtectorSoftware detection rule, including context and recommended filters:

• Scenario: Enterprise Antivirus Self-Protection Scans

  • Context: The diPacker executable is often part of a legitimate endpoint protection suite (e.g., Trend Micro or similar) that performs self-scanning. When the antivirus engine scans its own installation directory, it may trigger this YARA rule as it detects the packing signature within its own binaries during routine integrity checks.
  • Filter/Exclusion: Exclude the specific process path of the legitimate security agent (e.g., C:\Program Files\Trend Micro\OfficeScan Client\x64\diPacker.exe) and exclude events where the parent process is the antivirus service itself (e.g., tmfwsvc.exe or ofcservice.exe).

• Scenario: Scheduled Patch Deployment via SCCM/Intune

  • Context: During nightly maintenance windows, System Center Configuration Manager (SCCM) or Microsoft Intune deploys software updates. The deployment engine often extracts and unpacks the update payload using the diPacker utility before installation, triggering the rule as a new process creation event on multiple endpoints simultaneously.
  • Filter/Exclusion: Create an exclusion based on the “Parent Process Name” being ccmexec.exe (SCCM) or IntuneManagementExtension.exe, and limit the detection to business hours only if deployment is strictly scheduled for off-hours, or conversely, whitelist the specific file hash of the known good diPacker version used in the patch.

• Scenario: Admin-Initiated Software Installation via PowerShell

  • Context: IT administrators frequently run automated scripts to install new line-of-business applications. These scripts often invoke a silent installer that utilizes `di