Advanced Evasion and Defense

AMSI Bypass Techniques

AMSI (Antimalware Scan Interface) is a Windows API that hooks into PowerShell, JScript, VBScript, and .NET to scan code before execution. Endpoint security products register as AMSI providers, receiving each script block for analysis before it runs.

How the scan chain works: when a process loads amsi.dll, the registered security provider receives each script block via AmsiScanBuffer() before the scripting engine executes it. If the provider returns a malicious classification, execution is blocked before the code runs.

The classic reflection bypass patches the amsiInitFailed field in System.Management.Automation to true. This causes PowerShell to believe no AMSI provider is loaded, skipping subsequent scans. Understanding this conceptually is important for defenders -- the specific strings used in bypass attempts become detection signals. Working bypass code is intentionally not reproduced here.

Detection of AMSI bypass attempts: PowerShell Script Block Logging (Event ID 4104) captures bypass attempts including the strings used, such as "AmsiUtils", "amsiInitFailed", or "amsiContext". These strings appearing in a script block are high-confidence AMSI bypass indicators, regardless of whether the bypass succeeded.

A less common variant uses a fake AMSI COM server that always returns AMSI_RESULT_CLEAN, convincing the security provider that every submitted script is benign. More complex to deploy than the reflection bypass, but detects differently -- no PowerShell strings, but anomalous COM registration activity.

Defense: Constrained Language Mode (CLM) combined with AMSI materially reduces attack surface. CLM prevents full .NET API access, which blocks the reflection call used in the classic bypass without requiring the attacker to find an alternative.

AppLocker and WDAC Bypass

AppLocker and Windows Defender Application Control (WDAC) are application allowlisting controls. They block unsigned or non-whitelisted executables from running. The theory is sound. The problem is that LOLBins already pass both controls by default.

Why LOLBins bypass both by design: LOLBins are Microsoft-signed binaries in C:\Windows\System32. AppLocker's default rules allow all binaries in that path signed by Microsoft. No bypass is needed because the binary was never blocked. This is the fundamental limitation of default AppLocker policy against LOTL attacks.

Specific LOLBins are useful precisely because they execute code without spawning a child process from an unauthorized path:

• regsvr32 Squiblydoo -- runs a remote COM scriptlet inside regsvr32.exe. No new process with an unapproved path is ever created.
• installutil /logfile= /LogToConsole=false /U assembly.exe -- .NET assembly proxy execution. installutil is in the .NET framework path, already on the allowlist.
• MSBuild inline task -- compiles C# code inside msbuild.exe. No compiled binary is written to disk. The compiled payload runs in the msbuild.exe process.
• regasm /U assembly.exe and regsvcs -- similar proxy execution to installutil, both .NET framework binaries already whitelisted.

WDAC is stricter than AppLocker. A well-configured WDAC policy can block even Microsoft-signed binaries through specific hash, path, and publisher rules combined with deny lists. This is the only application control posture that actually defeats LOTL at the control level rather than at the detection level.

EDR Evasion via LOLBins

EDR products monitor process creation, network connections, file operations, and registry writes through kernel callbacks and user-mode hooks. LOLBins help attackers operate under reduced EDR scrutiny through three mechanisms.

Reduced process creation. In-memory execution via PowerShell IEX never creates a child process with a suspicious binary path. EDR has no new binary to scan, hash, or evaluate against reputation databases. The malicious code runs entirely within the trusted powershell.exe process space.

Trusted binary context. EDR products apply different logic to Microsoft-signed System32 binaries. A network connection from powershell.exe triggers different analysis than the same connection from an unknown binary. The trusted binary context means LOLBin network activity passes through with lower-confidence alerts.

PPID spoofing. EDR logic that uses parent-process chain analysis can be deceived by PPID spoofing (covered in chapter 4). By spoofing the parent to appear as explorer.exe or a trusted process, the entire chain analysis is distorted.

At the leading edge, advanced LOTL abuse in .NET combines in-memory loading with direct syscall execution that bypasses user-mode EDR hooks entirely. This removes EDR's ability to intercept API calls via user-mode hooks, forcing reliance on kernel-level telemetry. Most practical LOTL attacks do not require this because EDR tuning gaps are sufficient. The sophisticated techniques appear in nation-state campaigns targeting high-security environments, not in commodity ransomware.

Defensive Hardening Controls

Seven controls ordered by impact on LOTL attack surface reduction. These are not theoretical -- each has documented effectiveness against the techniques in this module.

1. PowerShell Constrained Language Mode (CLM). Blocks .NET reflection API access, preventing AMSI bypass via reflection and in-memory assembly loading. The strongest single PowerShell hardening control. Configured via AppLocker or WDAC policy. No user-visible impact for standard PowerShell usage.
2. Script Block Logging (EID 4104). Enabled via GPO. No measurable performance impact. Captures deobfuscated script block content -- meaning obfuscated payloads are logged in their evaluated form after PowerShell processes them. Required baseline for any PowerShell detection strategy.
3. PowerShell Transcription. Writes all PowerShell input and output to a log file. Forensically valuable when Script Block Logging is unavailable. Slower to query than event logs but captures full session context.
4. Attack Surface Reduction (ASR) Rules. Windows Defender ASR rules directly mitigate Office-spawning-LOLBin chains: block Office applications from spawning child processes, block Office from creating executable content, block execution of potentially obfuscated scripts, block Win32 API calls from Office macros. These four rules address one of the most common initial delivery chains seen in enterprise intrusions.
5. WDAC with deny rules for specific LOLBins. Explicitly deny mshta.exe, wscript.exe, cscript.exe, and regsvr32 from user-writable paths in environments where these binaries serve no legitimate business function. This is operationally feasible in most enterprise environments with a proper exclusion workflow.
6. HVCI (Hypervisor-Protected Code Integrity). Prevents LOLDriver and BYOVD attacks by enforcing code integrity at the hypervisor level. Blocks the technique BlackMatter used with mhyprot2.sys to kill AV before encryption. Available on all modern Windows hardware. Enabled in Windows Security settings under Device Security.
7. VBScript disabled. Windows 11 24H2 deprecated VBScript by default. On earlier versions, VBScript can be manually disabled via registry, eliminating the wscript.exe and cscript.exe attack surface entirely. Where VBScript has no legitimate business use, disabling it is a low-cost, high-impact control.

Testing Your Detection Coverage

Writing detection rules without testing them provides false confidence. Validation closes the loop between building coverage and knowing the coverage works.

Atomic Red Team is the standard open-source test framework for this purpose (atomicredteam.io). It provides documented, safe simulations of ATT&CK techniques including most T1218 subtechniques. Tests are executed via Invoke-AtomicTest in PowerShell:

# Run the certutil download cradle test (T1218.001)
# Execute in a lab environment only
Invoke-AtomicTest T1218.001 -TestNumbers 1

This test downloads a benign file using certutil syntax identical to attacker usage. If the detection rule is working, an alert fires. If it does not fire, the rule has a gap that needs investigation before the rule is considered production-ready.

Purple team validation: run Atomic Red Team tests in a controlled lab environment, verify that alerts fire in your SIEM or EDR with the expected fidelity, and document pass/fail per technique. The output is a detection coverage map -- which T1218 subtechniques produce quality alerts, which produce no alert, and which produce alert noise without useful context.

Continuous validation: detection rules drift over time. Analyst tuning suppresses too broadly. Platform updates change telemetry field names or collection paths. Running detection tests on a monthly or post-change schedule catches regressions before they become coverage gaps in production.

Per detection, maintain documentation that includes the ATT&CK technique, the Atomic Red Team test number used for validation, the date last tested, the test result, known false positive cases, and the active suppression list. This documentation is the evidence that the rule works, not just a description of what it should do.

Threat-Informed Defense for LOLBins

Threat-informed defense prioritizes defensive investment based on actual threat actor behavior rather than hypothetical scenarios or vendor marketing. Applied to LOLBin coverage, it means building detection based on techniques that actors targeting your industry actually use.

MITRE ATT&CK Evaluations conduct annual red team exercises against specific APT groups using real commercial EDR tools. The evaluations show which techniques each tool detects, misses, or partially detects. LOLBin techniques -- particularly T1218 subtechniques -- consistently appear among the hardest to detect with high confidence across all evaluated products. No tool does this perfectly.

The Center for Threat-Informed Defense (CTID) produces sensor mapping research that documents which data sources detect which ATT&CK techniques, adversary emulation plans that provide structured tests for specific threat actors, and detection analytics that can be adapted for any SIEM platform.

A practical prioritization framework for LOLBin detection coverage:

1. Identify which LOLBins appear in threat actor playbooks targeting your industry or geography.
2. Map those techniques against your current detection coverage to find gaps.
3. Identify which gaps already have a deployed data source that could support detection.

Cover item 3 first (quick wins using existing telemetry), then solve item 2 (gaps requiring new data source deployment), then refine item 1 coverage over time as actor behavior evolves.

The LOLBAS Project (lolbas-project.github.io) is the ongoing community catalog of documented LOLBin abuse cases. It is actively maintained and receives new entries as the security community discovers new techniques. A quarterly review of new entries translates directly into new detection candidates: each new entry is a question -- is this technique covered by existing rules, and does the required data source exist?

Module Summary and Next Steps

Eight chapters covered the full LOLBAS detection engineering curriculum:

• Chapters 1-3: Taxonomy -- what LOLBins, LOLScripts, LOLLibs, and LOLDrivers are, how they differ, and the LOLBAS Project catalog structure.
• Chapter 2: The technique catalog -- certutil, mshta, regsvr32, rundll32, PowerShell, wmic, bitsadmin, installutil, and related binaries with their specific abuse patterns.
• Chapter 4: Attacker tradecraft -- download cradle, execution proxy, persistence, lateral movement, and defense evasion patterns using LOLBins.
• Chapter 5: Detection strategy -- behavioral detection, parent-child analysis, baseline deviation, and network-side indicators.
• Chapter 6: Detection queries -- KQL, SPL, and Sigma rules for every major LOLBin covered.
• Chapter 7: Threat actor campaigns -- APT32, APT34, Lazarus, BlackMatter, LockBit, Conti, and Cobalt Strike stager delivery.
• Chapter 8 (this chapter): Advanced evasion and hardening -- AMSI bypass, AppLocker/WDAC limitations, EDR evasion, and the seven hardening controls.

Immediate next steps. Run Atomic Red Team tests against the T1218 subtechniques from chapter 6. Build the hunt hypotheses from chapter 7 into formal hunt plans in HYPOS. Enable Script Block Logging (EID 4104) if not already deployed -- this single GPO change unlocks detection for PowerShell-based LOTL at no cost. Enable ASR rules if the environment supports them.

Cross-module reference. The Threat Hunting module covers hypothesis-driven hunt methodology. Chapter 9 of that module (Hunting LOLBin Abuse) applies the full threat hunting lifecycle specifically to LOLBins, combining both modules into an end-to-end workflow from hypothesis to after-action report.

Continuing education resources: LOLBAS Project (lolbas-project.github.io), loldrivers.io for LOLDriver coverage, MITRE ATT&CK T1218 subtechnique pages, Center for Threat-Informed Defense research library, and the Atomic Red Team test catalog at atomicredteam.io.