How to detect PowerShell-based attacks

Threat snapshot

PowerShell is the most consistently abused tool in the modern attacker's playbook. It is installed on every Windows host, runs with the same privileges as the invoking user, can reach the internet directly, and provides a rich scripting environment that can execute entirely in memory without writing a file to disk. These properties make it useful for system administrators and indispensable for attackers. The challenge for defenders is that the line between legitimate administrative PowerShell activity and malicious PowerShell execution runs through the same binary, the same event logs, and in many environments, the same accounts.

The behaviors that distinguish malicious PowerShell from legitimate use are consistent across threat actors: commands encoded in Base64 to obscure their content, download cradles that pull payloads from remote sources and execute them in memory, AMSI bypass techniques that disable the AntiMalware Scan Interface before executing further malicious commands, execution policy tampering that removes the script restriction normally enforced on untrusted scripts, and deliberate removal of PowerShell history and ETW tracing to limit forensic evidence.

Log360 maps 67 detection rules to PowerShell attack patterns across these categories. Coverage spans process creation events, PowerShell script block logging (Event 4104), and registry events that capture policy tampering. This page covers what each attack pattern looks like in the logs, which rules detect them, and how an analyst should respond when they fire.

PowerShell attack detection, at a glance

How PowerShell attacks work

Encoded and obfuscated commands

Base64 encoding is the simplest obfuscation technique available to an attacker using PowerShell. The -EncodedCommand (or -enc) parameter accepts a Base64-encoded string and executes it directly, bypassing any script file-based controls. The encoded content is typically invisible to administrators monitoring running commands without dedicated logging and is frequently used to deliver download cradles, Mimikatz invocations, or C2 beacon stagers. Log360 detects this via the Base64 Encoded PowerShell Command Detected rule, which fires on process creation events where the PowerShell command line contains the -enc or -EncodedCommand flag.

Beyond simple Base64 encoding, attackers use Invoke-Obfuscation, a public PowerShell obfuscation framework, to transform commands into versions that retain their behavior while being syntactically unrecognizable. Invoke-Obfuscation generates RUNDLL LAUNCHER, MSHTA, and Rundll32 variants that invoke PowerShell indirectly through other system utilities. Log360 detects these through dedicated Invoke-Obfuscation pattern rules.

Download cradles

A download cradle is a short PowerShell snippet that retrieves a payload from a remote source and executes it in memory without writing it to disk. The most common forms use Invoke-WebRequest, DownloadString, DownloadFile, or COM objects like MSXML2.XMLHTTP to fetch content and then use Invoke-Expression (IEX) to execute it. These patterns are the delivery mechanism for Cobalt Strike stagers, Meterpreter payloads, and ransomware droppers. Log360 covers this through PowerShell DownloadFile, Suspicious Invoke-WebRequest Execution, Suspicious Invoke-WebRequest Execution With DirectIP, and Potential COM Objects Download Cradles Usage rules.

AMSI bypass

The Windows AntiMalware Scan Interface (AMSI) passes PowerShell script content to registered security products before execution. Attackers disable AMSI before running malicious scripts to prevent this scanning. The most common bypass technique uses .NET reflection to find the amsiInitFailed field and set it to true, causing AMSI to report initialization failure and skip scanning. This specific pattern is what Log360's AMSI Bypass Pattern Assembly GetType and Potential AMSI Bypass Via .NET Reflection rules detect. Attempts to hijack the AMSI COM server registration are detected by Potential AMSI COM Server Hijacking.

ETW disabling and history clearing

Event Tracing for Windows (ETW) provides the infrastructure that PowerShell script block logging uses to capture command content. Attackers patch ETW provider methods in memory to suppress logging before executing malicious commands. Log360 detects this through the Disable of ETW Trace - Powershell rule. History clearing, using Clear-History or removing the PSReadLine history file, is detected by Clear PowerShell History - PowerShell and Disable Powershell Command History. These rules fire on the evasion step rather than the malicious activity itself, providing an earlier warning signal.

PowerShell-based credential access

PowerShell provides convenient access to Windows credential stores and memory, making it the primary tool for credential theft in many attack chains. Live LSASS memory dumping via PowerShell, Mimikatz invocation through PowerShell (Invoke-Mimikatz), credential manager enumeration, and Kerberos ticket requests are all detectable through specific script block and process creation patterns.

Real-world campaigns

APT29/Cozy Bear: encoded cradles for in-memory payloads

APT29 has extensively used Base64-encoded PowerShell download cradles to deliver their BEACON and other implants entirely in memory, leaving no files on disk for traditional forensic analysis. The pattern involves an encoded command that decodes to a download cradle, which pulls a further encoded payload, which decodes to a reflective DLL loader. Each stage uses encoding to obscure the next. Log360's encoded command detection fires at the first stage, before any payload reaches memory.

FIN7: Invoke-Obfuscation for script-based delivery

FIN7 used heavily obfuscated PowerShell scripts delivered through malicious Office documents, with obfuscation generated by Invoke-Obfuscation to evade signature-based detection. Their scripts used the LAUNCHER obfuscation variant that invokes PowerShell through a Rundll32 call to avoid direct PowerShell process creation. The Invoke-Obfuscation RUNDLL LAUNCHER and Invoke-Obfuscation Via Use Rundll32 rules detect this pattern.

General ransomware pre-staging: PowerShell for defense disabling

Across virtually every documented ransomware incident involving a manual operator, PowerShell is used to disable Windows Defender, add exclusion paths, stop security services, and clear event logs before deploying the encryptor. The Powershell Disable Security Monitoring rule (Critical) specifically targets this pre-ransomware disabling sequence.

Business impact

• In-memory execution leaves no file on disk for endpoint security tools to scan: Fileless PowerShell attacks bypass antivirus and many EDR tools that rely on file scanning. SIEM-based detection through log analysis is one of the few controls that remains effective against fully in-memory attack chains.
• PowerShell is trusted by the OS and is not blocked by application whitelisting: Default application control policies trust PowerShell because it is a system component. Attackers exploit this trust to execute arbitrary code without triggering application whitelist alerts.
• Encoded and obfuscated commands make manual review unreliable: A SOC analyst reviewing process creation logs cannot easily identify a malicious encoded PowerShell command without dedicated decoding tools. Automated detection rules that flag the obfuscation pattern itself, rather than the decoded content, are necessary for reliable coverage.

Detecting PowerShell attacks with Log360

For full PowerShell detection coverage, three logging sources must be enabled: Windows Security Event 4688 with command-line auditing for process creation; PowerShell Script Block Logging (Event 4104) for capturing deobfuscated script content; and PowerShell Module Logging (Event 4103) for capturing individual module invocations. Without script block logging, encoded and obfuscated command detection coverage drops significantly.

Attack chain visibility

Investigation playbook

Step 1: Decode and understand the command

• For any Base64 encoded command alert, extract the encoded string from the process creation event command line and decode it. The decoded content reveals the actual attack payload and determines the correct response path. A decoded download cradle has a different response priority than a decoded reconnaissance command.
• Check the PowerShell script block logs (Event 4104) on the affected host for the same time window. Script block logging captures the deobfuscated content of PowerShell scripts even when they are delivered encoded, providing a clearer view of what ran.
• Identify the parent process that launched PowerShell. PowerShell launched by a scheduled task, a service process, a document application, or another scripting host is higher priority than PowerShell launched interactively by a logged-in administrator.

Step 2: Determine if AMSI was bypassed

• If an AMSI bypass rule fired before or concurrent with download cradle activity, assume that any further PowerShell execution on that host was not scanned by registered security products. Expand the investigation to cover all process creation events on the host for the period following the AMSI bypass event.
• Check for ETW disabling events on the same host. If ETW was patched, script block logging may be incomplete or absent for the period following the patching event, creating a blind spot in the forensic record.

Step 3: Trace network connections to download URLs

• Correlate the timestamp of download cradle events with firewall or proxy logs to identify the external IP or domain contacted. Block that IP/domain at the perimeter immediately. Query the firewall logs for any other internal hosts that have contacted the same destination in the prior 48 hours.
• Check whether the download URL resolves to a known CDN or file sharing service. Some ransomware operators stage payloads on legitimate cloud services to avoid domain reputation blocking. Even a connection to a trusted service should be investigated if the download cradle pattern was present.

Response and remediation

Immediate actions

• Isolate the host if credential dumping or AMSI bypass has occurred: These two events, particularly in combination, represent a high-confidence active compromise. Credential dumping means the attacker may have obtained credentials that are valid across other hosts. AMSI bypass means subsequent malicious activity on the host is not being scanned by security tools.
• Enable PowerShell Constrained Language Mode on all hosts where it is not already active: Constrained Language Mode prevents the .NET reflection operations that underpin most AMSI bypass techniques and restricts the PowerShell API surface available to scripts. It does not prevent PowerShell execution but significantly raises the cost for attackers.
• Enable Script Block Logging and Module Logging via Group Policy if not already deployed: These two logging mechanisms are the most impactful single configuration change for PowerShell attack detection. Without them, encoded and obfuscated command detection is limited to process creation event command-line inspection, which catches far fewer variants.