Living Off the Land: Using Built-in Tools

Living Off the Land Binaries, commonly referred to as LOLBins, represent one of the most persistent challenges in modern threat detection. As a penetration tester, I consistently find that these techniques are among the most effective at bypassing security controls, precisely because the tools being used are legitimate, signed Microsoft binaries that exist on every Windows system. This post maps to MITRE ATT&CK technique T1218 (System Binary Proxy Execution) and its many sub-techniques, and my goal is to help defenders build effective detection around these commonly abused tools.

Why LOLBins Are Effective

The fundamental challenge with LOLBin detection is the dual-use nature of these tools. Every LOLBin has a legitimate purpose, and in many environments, these tools are used daily by system administrators, software installers, and automated processes. Application whitelisting solutions typically allow these binaries because they are signed by Microsoft and required for normal system operation. Attackers exploit this inherent trust by using these tools to download files, execute code, and perform other malicious actions that would be blocked if attempted through unsigned or unknown executables. The key for defenders is not to block these tools outright, which would break legitimate functionality, but to monitor for anomalous usage patterns that indicate abuse.

Common LOLBins and Their Abuse Patterns

Understanding the specific ways each tool can be abused helps defenders build targeted detection rules. Here are the most commonly abused LOLBins I encounter during engagements.

• certutil.exe (T1140) - Intended for certificate management, certutil can download files from URLs using the -urlcache flag and encode or decode Base64 data. Defenders should monitor for certutil.exe with command-line arguments containing -urlcache, -split, -encode, or -decode. Any network connection initiated by certutil.exe should be investigated, as certificate management operations rarely require internet access in most environments.
• mshta.exe (T1218.005) - The Microsoft HTML Application Host executes HTA files that can contain VBScript or JScript. Attackers use it to execute scripts from remote URLs or local files. Defenders should alert on mshta.exe executing with URL arguments or spawning child processes like cmd.exe or powershell.exe, which is almost never a legitimate usage pattern.
• regsvr32.exe (T1218.010) - Designed to register COM DLLs, regsvr32 can also execute COM scriptlets from remote URLs using the /s /n /u /i:URL pattern, known as the Squiblydoo attack. Monitor for regsvr32.exe with /i arguments containing URLs or executing scripts from temporary directories.
• rundll32.exe (T1218.011) - This tool executes DLL functions and can be abused to run arbitrary code. Defenders should watch for rundll32.exe executing DLLs from unusual locations such as user temp directories, download folders, or network shares, rather than from System32 or Program Files.
• msiexec.exe (T1218.007) - The Windows Installer can install packages from remote URLs, allowing attackers to download and execute malicious MSI packages. Monitor for msiexec.exe connecting to external URLs or installing packages from non-standard locations.

PowerShell Alternatives

As PowerShell detection has improved significantly with Script Block Logging and AMSI, attackers have shifted to alternative execution methods that provide similar capabilities with less visibility.

• wmic.exe (T1047) - Windows Management Instrumentation Command-line can create processes, query system information, and even execute scripts remotely. WMIC process call create commands are a direct PowerShell alternative for command execution. Defenders should monitor for WMIC with process call create arguments and watch for remote WMIC connections.
• cscript.exe and wscript.exe (T1059.005) - The Windows Script Hosts execute VBScript and JScript files. These scripting engines predate PowerShell and are less commonly monitored. Defenders should treat script host execution with the same level of scrutiny as PowerShell, monitoring for scripts executed from unusual locations and watching for child process creation.
• msbuild.exe (T1127.001) - The Microsoft Build Engine can compile and execute inline C# code from XML project files, effectively providing a code execution mechanism that bypasses application whitelisting. Defenders should alert on msbuild.exe executing outside of development environments and monitor for msbuild.exe spawning unexpected child processes.

Detection Strategies for LOLBin Abuse

Effective LOLBin detection requires a combination of behavioral analytics, baseline analysis, and contextual awareness. Here is the approach I recommend to organizations based on my testing experience.

• Command-line argument analysis - Most LOLBin abuse involves specific command-line arguments that differ from legitimate usage. Enable command-line logging via Sysmon Event ID 1 or Windows Security Event ID 4688 with process command line auditing. Build detection rules that flag known malicious argument patterns for each LOLBin.
• Network connection monitoring - Many LOLBin techniques involve downloading content from the internet. Tools like certutil, mshta, msiexec, and regsvr32 should rarely initiate outbound network connections in most environments. Use Sysmon Event ID 3 (Network Connection) to monitor for unexpected network activity from these binaries.
• Parent process anomalies - LOLBin abuse often produces unusual parent-child process relationships. For example, mshta.exe spawned by outlook.exe or winword.exe is highly suspicious and likely indicates a phishing payload. Build process tree analysis rules that flag unexpected parent processes for common LOLBins.
• Execution from unusual locations - Legitimate LOLBin usage typically involves binaries executing from their standard System32 locations. If rundll32.exe or regsvr32.exe are loading DLLs from user-writable directories, that is a strong indicator of abuse.

Detection and Defense Recommendations

Building comprehensive LOLBin detection requires an investment in understanding your environment baseline. Here are my specific recommendations for defenders.

• Baseline legitimate LOLBin usage - Before building detection rules, spend time understanding how these tools are used legitimately in your environment. This prevents alert fatigue from false positives and allows you to create more precise detection rules.
• Leverage the LOLBAS Project - The Living Off the Land Binaries, Scripts, and Libraries project maintains a comprehensive database of dual-use binaries and their abuse potential. Use this resource to identify which LOLBins are present in your environment and build detection for each one.
• Implement application control policies - Where possible, use Windows Defender Application Control or AppLocker to restrict which users and processes can execute LOLBins. For example, most end users never need to run msbuild.exe or regsvr32.exe, so these can be blocked for standard users while remaining available for administrators.
• Create SIEM correlation rules - Combine multiple weak signals into stronger detections. A single certutil download might be benign, but certutil downloading a file followed by rundll32 executing a DLL from the same directory within a short time window is highly suspicious.
• Test your detections regularly - Use frameworks like Atomic Red Team to periodically test your LOLBin detections. Each test validates that your rules are functioning correctly and identifies any gaps that have developed due to environment changes or rule drift.

The Evolving LOLBin Landscape

The LOLBin landscape continues to evolve as security researchers discover new dual-use capabilities in existing system binaries. Defenders must stay current with new discoveries by monitoring the LOLBAS Project and threat intelligence feeds. During every penetration test I conduct, I document which LOLBin techniques successfully bypass the client detection stack, providing actionable intelligence for improving their security posture. The most effective organizations treat LOLBin detection as an ongoing program rather than a one-time configuration, continuously refining their rules and expanding their coverage as the threat landscape changes.