This hunt hypothesis targets adversaries leveraging the Hatman malware family to establish memory-resident or file-based persistence within Azure Sentinel environments. Proactive hunting for this behavior is essential because early detection of these subtle persistence mechanisms allows the SOC team to identify and contain stealthy threats before they escalate into significant incidents.
rule hatman_mftmsr : hatman {
meta:
id = "56b400d4-2989-5c34-9e8a-0a14b0bf0af1"
strings:
$mfmsr_be = { 7c 63 00 a6 }
$mfmsr_le = { a6 00 63 7c }
$mtmsr_be = { 7c 63 01 24 }
$mtmsr_le = { 24 01 63 7c }
condition:
($mfmsr_be and $mtmsr_be) or ($mfmsr_le and $mtmsr_le)
}
This YARA rule can be deployed in the following contexts:
This rule contains 4 string patterns in its detection logic.
Here are 5 specific false positive scenarios for the hatman_mftmsr detection rule, including suggested filters and exclusions tailored for an enterprise environment:
Scenario: Legitimate Backup Agent Scanning
vss.exe (Volume Shadow Copy Service) process space, which mimics the persistence behavior targeted by the Hatman rule.VeeamTransportService.exe, rubrik-agent.exe, and vss.exe when they are running under the SYSTEM or dedicated backup service accounts (e.g., DOMAIN\VeeamBackup).Scenario: Scheduled PowerShell Maintenance Jobs
System.Management.Automation assembly and inject code into memory, triggering the file-based persistence logic of the rule.svchost.exe (specifically the Schedule service) or powershell.exe, provided the script path resides within a trusted administrative directory such as C:\ProgramData\IT_Ops\Scripts and the user context is a known admin account.Scenario: Endpoint Detection and Response (EDR) Self-Protection