Detects Empire component - file Invoke-MetasploitPayload.ps1

Hunt Hypothesis

The detection of the Invoke-MetasploitPayload.ps1 file indicates potential use of the Empire framework to execute arbitrary payloads, leveraging PowerShell for command and control. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate early-stage adversary activity that may lead to persistent access or data exfiltration.

YARA Rule

rule Empire_Invoke_MetasploitPayload {
   meta:
      description = "Detects Empire component - file Invoke-MetasploitPayload.ps1"
      author = "Florian Roth"
      reference = "https://github.com/adaptivethreat/Empire"
      date = "2016-11-05"
      hash1 = "a85ca27537ebeb79601b885b35ddff6431860b5852c6a664d32a321782808c54"
   strings:
      $s1 = "$ProcessInfo.Arguments=\"-nop -c $DownloadCradle\"" fullword ascii
      $s2 = "$PowershellExe=$env:windir+'\\syswow64\\WindowsPowerShell\\v1.0\\powershell.exe'" fullword ascii
   condition:
      ( uint16(0) == 0x7566 and filesize < 9KB and 1 of them ) or all of them
}

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

References

• https://github.com/adaptivethreat/Empire
• Source Rule

False Positive Guidance

• Scenario: A system administrator is using PowerShell to run a legitimate PowerShell script for system maintenance, which happens to have a similar name to Invoke-MetasploitPayload.ps1.
  Filter/Exclusion: Check for presence of known admin tools or scripts in a trusted directory (e.g., C:\Windows\System32\) or check for presence of Get-Command or Get-Module usage to confirm script legitimacy.

• Scenario: A scheduled job is configured to run a PowerShell script that is part of a SIEM or log management tool (e.g., Splunk or ELK stack) that uses PowerShell for data ingestion.
  Filter/Exclusion: Filter based on the script’s location (e.g., C:\Program Files\Splunk\) or check for presence of known SIEM tool cmdlets or modules.

• Scenario: A security tool like Microsoft Defender for Endpoint or CrowdStrike runs a PowerShell script as part of its endpoint detection and response (EDR) capabilities.
  Filter/Exclusion: Check for the presence of known EDR tool paths (e.g., C:\Windows\System32\WindowsPowerShell\v1.0\) or use process parent filtering to exclude child processes of known security tools.

• Scenario: A devops pipeline (e.g., Azure DevOps, Jenkins) runs a PowerShell script to deploy or configure infrastructure, which includes a script with a name similar to Invoke-MetasploitPayload.ps1.
  Filter/Exclusion: Filter based on the script’s location (e.g., C:\DevOps\scripts\) or check for the presence of CI/CD tool-specific cmdlets or environment variables.

• Scenario: A third-party application (e.g., **VM