detect PlugX in memory

Hunt Hypothesis

This hunt hypothesis targets adversaries utilizing the PlugX malware family to establish persistent, fileless footholds within Azure environments by executing malicious code directly in memory. Proactively hunting for these indicators is critical because PlugX’s ability to evade traditional disk-based scanning allows it to silently exfiltrate sensitive data before triggering standard alert thresholds.

YARA Rule

rule PlugX {
          meta:
            description = "detect PlugX in memory"
            author = "JPCERT/CC Incident Response Group"
            rule_usage = "memory scan"
            reference = "internal research"

          strings:
            $v1 = { 47 55 4c 50 00 00 00 00 }
            $v2a = { 68 40 25 00 00 }
            $v2c = { 68 58 2D 00 00 }
            $v2b = { 68 a0 02 00 00 }
            $v2d = { 68 a4 36 00 00 }
            $v2e = { 8D 46 10 68 }
            $v2f = { 68 24 0D 00 00 }
            $v2g = { 68 a0 02 00 00 }
            $v2h = { 68 e4 0a 00 00 }
            $enc1 = { C1 E? 03 C1 E? 07 2B ?? }
            $enc2 = { 32 5? ?? 81 E? ?? ?? 00 00 2A 5? ?? 89 ?? ?? 32 ?? 2A ?? 32 5? ?? 2A 5? ?? 32 }
            $enc3 = { B? 33 33 33 33 }
            $enc4 = { B? 44 44 44 44 }
         condition: $v1 at 0 or ($v2a and $v2b and $enc1) or ($v2c and $v2b and $enc1) or ($v2d and $v2b and $enc2) or ($v2d and $v2e and $enc2) or ($v2f and $v2g and $enc3 and $enc4) or ($v2h and $v2g and $enc3 and $enc4)
}

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 13 string patterns in its detection logic.

References

• internal research
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the detect PlugX in memory rule, including suggested filters and exclusions tailored for an enterprise environment:

• Microsoft Defender Antivirus Real-Time Scanning

  • Scenario: The MsMpEng.exe process (Microsoft Defender) frequently injects DLLs into target processes to perform real-time scanning. This injection activity often mimics the PlugX behavior of loading suspicious modules into memory, particularly when scanning large files or performing deep heuristic analysis on user workstations.
  • Filter/Exclusion: Exclude alerts where the parent process is MsMpEng.exe and the injected module path contains \Program Files\Windows Defender\. Additionally, filter out events where the loaded module has a valid Microsoft code signing certificate with a timestamp within the last 24 months.

• Sysmon or CrowdStrike Falcon Sensor Updates

  • Scenario: Endpoint Detection and Response (EDR) agents like Sysmon (sysmon64.exe) or CrowdStrike (csagent.exe) regularly update their in-memory signatures and configuration policies. These updates involve loading new DLLs into the agent’s own memory space or into critical system processes, which can be misidentified as PlugX lateral movement or persistence mechanisms.
  • Filter/Exclusion: Create a whitelist for known EDR executable hashes (e.g., csagent.exe, osqueryd.exe) and their associated update paths (e.g., \Program Files\CrowdStrike\). Exclude memory load events where the file hash matches the known “Good” baseline of the organization’s security stack.

• Scheduled PowerShell Script Execution for Patch Management

  • Scenario: Enterprise patch management tools often utilize scheduled tasks running powershell.exe to deploy updates or run compliance checks. These scripts frequently load custom .NET assemblies or COM objects into memory dynamically. If these scripts are executed by