Rule to detect UACMe - abusing built-in Windows AutoElevate backdoor

Hunt Hypothesis

The hypothesis is that an adversary is exploiting the Windows AutoElevate feature to bypass User Account Control and establish persistent, elevated access to the system. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate potential long-term persistence mechanisms used by advanced threats.

YARA Rule

rule UACME_Akagi {
	meta:
		description = "Rule to detect UACMe - abusing built-in Windows AutoElevate backdoor"
		author = "Florian Roth"
		reference = "https://github.com/hfiref0x/UACME"
		date = "2015-05-14"
		hash1 = "edd2138bbd9e76c343051c6dc898054607f2040a"
		hash2 = "e3a919ccc2e759e618208ededa8a543954d49f8a"
		score = 60
	strings:
		$x1 = "UACMe injected, Fubuki at your service." wide fullword
		$x3 = "%temp%\\Hibiki.dll" fullword wide
		$x4 = "[UCM] Cannot write to the target process memory." fullword wide
		
		$s1 = "%systemroot%\\system32\\cmd.exe" wide
		$s2 = "D:(A;;GA;;;WD)" wide
		$s3 = "%systemroot%\\system32\\sysprep\\sysprep.exe" fullword wide
		$s4 = "/c wusa %ws /extract:%%windir%%\\system32" fullword wide
		$s5 = "Fubuki.dll" ascii fullword
		
		$l1 = "ntdll.dll" ascii
		$l2 = "Cabinet.dll" ascii
		$l3 = "GetProcessHeap" ascii
		$l4 = "WriteProcessMemory" ascii
		$l5 = "ShellExecuteEx" ascii
	condition:
		( 1 of ($x*) ) or ( 3 of ($s*) and all of ($l*) ) 
}

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

• https://github.com/hfiref0x/UACME
• Source Rule

False Positive Guidance

• Scenario: Legitimate scheduled task using AutoElevate
  Description: A scheduled task configured with Run whether user is logged on or not and Run with highest privileges may trigger the rule due to the use of AutoElevate.
  Filter/Exclusion: Check for TaskName containing known legitimate tasks (e.g., Microsoft\Windows\TaskScheduler\), or filter by TaskXML containing valid task definitions.

• Scenario: Admin performing remote desktop session elevation
  Description: An administrator may use Remote Desktop Services (RDP) to connect and perform actions that require elevation, which could be flagged as AutoElevate abuse.
  Filter/Exclusion: Filter by ProcessParent or SessionId to exclude processes initiated from RDP sessions or by known admin accounts.

• Scenario: System update or patching via Group Policy
  Description: Group Policy updates or Windows Update tasks may trigger AutoElevate behavior during deployment, which could be mistaken for malicious activity.
  Filter/Exclusion: Check for CommandLine containing wuauclt.exe, gpupdate.exe, or dism.exe, or filter by ProcessName matching known update tools.

• Scenario: PowerShell script with elevated privileges
  Description: A legitimate PowerShell script that uses Start-Process with -Verb RunAs or Invoke-Command with -Credential may be flagged as AutoElevate abuse.
  Filter/Exclusion: Filter by CommandLine containing powershell.exe and check for ProcessOwner matching known admin accounts or trusted scripts.

• Scenario: Microsoft Intune or MDM policy enforcement
  Description: Mobile Device Management (MDM) tools like Microsoft Intune may use AutoElevate to enforce policies, which could be flagged by the detection rule