Detect PowerShell Empire activity by correlating obfuscated PowerShell, suspicious network beacons, and post-exploitation behaviour such as credential access or remote execution. Look for short, repeated connections to the same destination, script content that disables logging, and processes launched from PowerShell that do not fit normal administration. Baseline legitimate remoting before tuning detections.
What PowerShell Empire leaves behind on Windows
PowerShell Empire is a post-exploitation framework, so detection works best when you look for the behaviour it creates rather than a single signature. The most useful signals are script-based abuse of PowerShell, suspicious child processes, logging suppression, and outbound beaconing that does not match normal admin activity. Windows telemetry matters here because the framework often blends into legitimate management workflows.
The first discriminator is PowerShell content and execution context. Obfuscation, encoded commands, download cradles, unusual command-line length, and script blocks that disable or evade logging are all consistent with Empire tradecraft. If you have the PowerShell Security Guide, use it to anchor your baseline for script block logging, constrained language mode, AMSI, and common abuse patterns.
Empire also tends to spawn a process chain that does not fit routine administration. Watch for PowerShell launching binaries such as cmd.exe, rundll32.exe, regsvr32.exe, mshta.exe, or other living-off-the-land tools when there is no clear operational reason. A process tree that starts with PowerShell and quickly branches into credential access or remote execution is especially important because it suggests the session has moved from initial script execution into hands-on post-exploitation activity.
How to separate Empire beaconing from normal remoting
The network side is often what turns a suspicious script into a stronger detection. Empire commonly uses short, repeated callbacks to the same destination with low and regular volume, which looks more like beaconing than interactive administration. Correlate that traffic with the originating PowerShell process, the parent process, and the user context so you can distinguish automated command-and-control from legitimate WinRM, remoting, or scheduled management jobs.
Legitimate Windows administration can look similar at a glance, which is why baselining matters. A domain admin using PowerShell remoting, a configuration tool invoking scripts, or a software deployment job can all generate remote process activity. The difference is usually in the pattern, purpose, and consistency of the destination, along with whether the surrounding host activity matches approved admin behaviour. If you can explain the session as a known management pattern, it is less likely to be Empire.
For correlation, give extra weight to combinations rather than single events: repeated outbound connections plus obfuscated PowerShell plus a child process that should not normally be launched from a shell is much more persuasive than any one artifact alone. That is also where MITRE ATT&CK Enterprise Matrix is useful, because it helps you map what you see to credential access, lateral movement, and privilege escalation behaviour instead of treating every alert as an isolated anomaly.
What to validate before you call it Empire
Confirm which logs are actually available on the host before you rely on a detection. Script block logging, module logging, and process creation telemetry should be reviewed together, because Empire can be noisy in one layer and quiet in another. If logging was disabled or tampered with, treat that as a meaningful signal rather than a gap to ignore.
Also validate the surrounding user and machine behaviour. If the PowerShell activity came from a known administrative toolchain, the process tree may be benign. If the same host also shows unusual outbound traffic, access to protected credentials, or remote execution against additional systems, the likelihood of a real intrusion increases quickly. A useful way to organise the response is to map the observed activity to NIST Cybersecurity Framework 2.0 so detection, response, and recovery are handled as linked tasks rather than isolated alerts.
Risk and Threat Considerations
PowerShell Empire is risky because it is designed to look like normal administration while giving an attacker a flexible post-exploitation platform. The main danger is not the script itself, but the access it can unlock: credential theft, lateral movement, remote execution, and quiet persistence after the initial foothold.
Failure mechanism: Obfuscated PowerShell and living-off-the-land binaries can evade weak logging or alerting, while periodic beaconing hides inside routine outbound traffic. If defenders have not baselined approved remoting patterns, the attacker can keep using the same host for command execution and follow-on compromise.
Impact: The result can be rapid expansion from one compromised endpoint into broader domain access, especially if the session reaches cached credentials, privileged accounts, or remote management paths. The same technique that starts as a script execution problem can become an enterprise-wide identity and lateral-movement incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Empire relies on scripted PowerShell execution to stage and run attacker activity. |
| T1071 — Application Layer Protocol | Empire commonly uses periodic network callbacks that resemble protocol-abiding beaconing. | |
| T1055 — Process Injection | Post-exploitation tools often pair script execution with stealthy code execution and process abuse. | |
| Recommendation — Map PowerShell execution chains to T1059 and hunt for obfuscated or encoded command lines. Correlate repeated outbound callbacks with process telemetry to separate beacons from normal traffic. Investigate suspicious PowerShell child processes and injected or anomalous execution chains. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, Software and Code | Detecting Empire depends on monitoring anomalous script, process, and network activity. |
| DE.AE-02 — Anomalous Activity is Detected and Analyzed | Empire activity is usually identified by correlated anomalies across host and network data. | |
| Recommendation — Monitor script, process, and network telemetry for deviations from approved PowerShell administration. Analyze correlated host and network anomalies before deciding the event is benign. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | PowerShell detection depends on generating script, process, and command-line records. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Correlating Empire behavior requires reviewing logs for process lineage and beacon patterns. | |
| SI-4 — System Monitoring | Empire is a host and network monitoring problem requiring behavioral detection. | |
| Recommendation — Enable and retain audit records for PowerShell, process creation, and network-relevant activity. Review audit data for obfuscated PowerShell, suspicious child processes, and repeated callbacks. Monitor endpoints for suspicious PowerShell behavior, logging suppression, and remote execution patterns. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Script block logging and related telemetry are central to finding Empire activity. |
| CIS-13 — Network Monitoring and Defense | Empire beaconing is often visible first as suspicious outbound network behaviour. | |
| Recommendation — Centralize and retain logs needed to spot obfuscated PowerShell and beaconing. Correlate periodic outbound connections with suspicious PowerShell processes and hosts. | ||
Practitioner Guidance
What to prioritise: Start with the host that first executed the suspicious PowerShell, then check for child processes, outbound beacons, and any evidence of credential access or remote execution. If logging is incomplete, compensate with process creation, network, and EDR telemetry rather than waiting for one perfect log source.
What to verify: Decide whether the PowerShell was part of an approved administration workflow before suppressing an alert. Confirm the parent process, user context, command line, destination, and timing against your normal remoting baseline; the more those elements diverge from sanctioned activity, the more likely the behaviour is malicious.
Practitioner takeaway: Empire detections are strongest when you treat PowerShell, process lineage, and beaconing as one story. The key judgement is whether the activity still fits a known admin pattern once you include destination, timing, and follow-on behaviour, not whether any single event looks suspicious in isolation.