PlugX RAT

Hunt Hypothesis

This hypothesis posits that adversaries are deploying the PlugX Remote Access Trojan to establish persistent footholds and exfiltrate sensitive data through covert command-and-control channels within our Azure environment. The SOC team should proactively hunt for these indicators despite the low severity rating because PlugX is known for its advanced evasion capabilities, allowing it to operate undetected for extended periods before escalating into a critical incident.

YARA Rule

rule plugX : rat
{
	meta:
		author = "Jean-Philippe Teissier / @Jipe_"
		description = "PlugX RAT"
		date = "2014-05-13"
		filetype = "memory"
		version = "1.0" 
		ref1 = "https://github.com/mattulm/IR-things/blob/master/volplugs/plugx.py"
		
	strings:
		$v1a = { 47 55 4C 50 00 00 00 00 }
		$v1b = "/update?id=%8.8x" 
		$v1algoa = { BB 33 33 33 33 2B } 
		$v1algob = { BB 44 44 44 44 2B } 
		$v2a = "Proxy-Auth:" 
		$v2b = { 68 A0 02 00 00 } 
		$v2k = { C1 8F 3A 71 } 
		
	condition: 
		$v1a at 0 or $v1b or (($v2a or $v2b) and (($v1algoa and $v1algob) or $v2k))
}

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

• Source Rule

False Positive Guidance

Here are 4 specific false positive scenarios for the PlugX RAT detection rule in an enterprise environment, including suggested filters and exclusions:

• Scenario: Enterprise Endpoint Protection Scans via PowerShell

  • Context: Managed security suites like CrowdStrike Falcon, Microsoft Defender for Endpoint, or Carbon Black frequently utilize PowerShell scripts to perform deep file system scans or update signature databases. These scripts often spawn powershell.exe processes that inject code into other running services (e.g., svchost.exe) to analyze memory, mimicking the DLL injection and process hollowing techniques used by PlugX.
  • Filter/Exclusion: Create an exclusion rule for PowerShell execution paths located in standard vendor directories (e.g., C:\Program Files\Microsoft Defender Antivirus\* or C:\ProgramData\CrowdStrike\*\*). Additionally, filter out events where the parent process is a known security service executable with a valid digital signature from the respective vendor.

• Scenario: Scheduled Group Policy Updates and Software Deployment

  • Context: System administrators often deploy software updates or configuration changes using Microsoft SCCM (Configuration Manager), Ivanti, or Ansible. These tools utilize scheduled tasks that trigger msiexec.exe or custom PowerShell scripts to install patches. During this process, the deployment agent may inject DLLs into user sessions to apply registry keys or modify user profiles, generating network traffic and file creation patterns identical to PlugX’s initial establishment phase.
  • Filter/Exclusion: Exclude alerts originating from specific scheduled task names (e.g., Microsoft SCCM Client Agent, Ivanti Endpoint Manager) running under the SYSTEM account. Filter by excluding network connections where the destination IP belongs to internal management subnets or known software update repositories (e.g., Microsoft Update servers).

• **Scenario: Enterprise Document