TTechniqueActive Directory
Living Off the Land Binaries (LOLBins)
Living off the land means an attacker uses the trusted tools already on a Windows system, instead of bringing their own, to enumerate, execute code, and evade defenses. This lesson explains why native binaries are so effective for evasion, what an attacker gains, and how to communicate the risk clearly in interviews, reports, and stakeholder conversations.
Why it matters
Living off the land is less a single exploit than a posture: the attacker decides to use only what is already on the machine. Native enumeration commands, the PowerShell and WMI engines, and trusted Microsoft binaries together let an operator survey a host, map the domain, and execute code without ever pulling a recognizable hacking tool into the environment.
The whole point is to look like normal administration, not an attack. Modern environments watch for new, unsigned executables landing on disk and for known tools by hash or signature. Reaching for binaries that are already present, already signed, and already allowed sidesteps most of that. Interviewers ask about this because it separates candidates who only know how to run a tool from those who understand how defenders detect tools and how attackers stay underneath that line.
Key Concepts
- Living off the land (LOTL) — using tools, binaries, and scripts that already ship with the operating system to carry out an attack, rather than uploading custom tooling that defenders are more likely to detect
- LOLBin / LOLBAS — a Living Off the Land Binary is a legitimate, Microsoft-signed executable (rundll32.exe, installutil.exe, certutil.exe, and others) that can be abused for code execution, download, or evasion; LOLBAS is the public project that catalogs them
- Signed-binary trust — these binaries are signed by Microsoft and live under C:\Windows, so application allowlisting (AppLocker) and many detection rules permit them by default, letting attacker activity blend in
- Native enumeration — built-in commands and engines (PowerShell, WMI, net, dsquery) can map the host, the network, and Active Directory without any external tool ever touching disk
- Indirect execution — a LOLBin runs the attacker's payload on the attacker's behalf, so the malicious process tree appears to originate from a trusted Windows binary rather than from an unknown executable
Theory
Preconditions
Living off the land requires code execution on a Windows host as some user, the same foothold any post-exploitation step needs. There is no special privilege requirement to start: most native enumeration runs fine as a standard domain user, and the abused binaries are present on essentially every Windows install by design.
What makes the technique attractive is the environment it is used in. It is the natural choice when a host is hardened against bringing your own tools, with no internet access, application allowlisting in place, EDR that flags unsigned binaries, or a client who has explicitly asked to see what is possible without uploading anything. The attacker still needs to know which native tools do what, because the abuse paths are not obvious from the binary's normal purpose. Some actions, such as code execution through certain LOLBins, are smoother with local administrator or SYSTEM context, but the enumeration core works at user level.
Why it works
Two properties combine. First, Windows ships with a deep administrative surface, PowerShell, WMI, net, dsquery, systeminfo, that is designed to query the host, the network, and Active Directory. The same capability a sysadmin uses to manage the domain is the capability an attacker uses to enumerate it. There is no malicious code to detect because there is no new code at all.
Second, the binaries an attacker leans on for execution are signed by Microsoft and live under C:\Windows. Application allowlisting such as AppLocker tends to permit anything in the Windows folder by default, and a Microsoft signature buys trust with both allowlists and detection tooling. Utilities like rundll32.exe and installutil.exe have legitimate jobs, loading DLLs, installing .NET assemblies, but they can be coaxed into running an attacker's payload instead. The malicious work runs under the identity of a trusted binary. When a defender looks at the process tree, the action appears to originate from a normal Windows component rather than from an unknown executable, so it blends into ordinary activity.
Attacker gain
The gain is stealth, and stealth is what turns a noisy foothold into a durable one. Native enumeration yields the full picture an operator needs, host configuration, network neighbors and routes, domain users, groups, service accounts, and trust relationships, while generating the kind of log entries a busy environment already produces by the thousand. The reconnaissance that would normally announce itself becomes hard to distinguish from administration.
The execution LOLBins add a second gain: a way to run a payload past application allowlisting and signature-based defenses, because the launching process is trusted. Combined, the attacker maps the environment and runs follow-on code without ever crossing the tripwire that "a new tool appeared on this machine" represents. That is often the difference between an operation that completes quietly and one that is caught at the first download.
Where it fits
Living off the land is not a phase of its own; it is a style that overlays the phases an attacker is already in. It shows up most heavily right after initial access, discovery and enumeration of the host, network, and domain, and again whenever the operator needs to execute code in a watched environment.
In a realistic chain, an operator lands on a host, uses native commands to understand where they are and what the domain looks like, and only then decides how to move. If allowlisting or EDR blocks their preferred tooling, they fall back to LOLBins for execution rather than abandoning the path. It pairs naturally with credential-access techniques that follow enumeration, because the quiet mapping it provides is exactly what tells the attacker which accounts and services are worth targeting next.
Tools / examples
- PowerShell: built-in scripting engine for host and domain recon, downloads, and in-memory execution; attackers may invoke older versions to dodge script-block logging
- WMI (
wmic, WMI engine): query host, user, group, and domain-controller information locally or remotely without external tooling net/net1,dsquery,systeminfo: native enumeration of users, groups, shares, and Active Directory objects;systeminfosummarizes the host in one low-noise command- rundll32.exe: signed Microsoft binary that loads and runs DLLs; abused to execute attacker-supplied DLL code while bypassing AppLocker (T1218.011)
- installutil.exe: signed .NET install utility; abused to run code placed in an
Uninstallmethod, bypassing allowlisting and blending in (T1218.004) - LOLBAS project: public, searchable catalog of Microsoft-signed binaries and the abuse functions (execute, download, bypass) each one offers
Defender view
- Do not trust a binary just because it is signed and lives in
C:\Windows. Build allowlisting and detection around behavior: rundll32 or installutil spawning a shell, making a network connection, or being launched from an unusual parent is suspicious regardless of signature. - Enable and forward PowerShell script-block and module logging, and block or alert on legacy PowerShell v2, which exists to evade that logging.
- Baseline normal administration. Native commands like
net group "Domain Admins"ordsqueryare routine for admins but anomalous from a marketing workstation; alert on context, not just the command. - Constrain code execution with AppLocker in conjunction with Windows Defender Application Control, and watch for the known LOLBin invocation patterns published in the LOLBAS project.
- Monitor parent/child process relationships and command-line arguments, since that is where LOLBin abuse separates itself from legitimate use.
Communication
Explain it to a stakeholder
Living off the land is when an attacker who is already inside a machine uses the tools that came with Windows, the same ones your administrators use, instead of bringing in their own hacking tools. They map your network and run their code using trusted, Microsoft-signed programs that are already there.
The risk is that most defenses are tuned to catch new or unknown tools, and this technique deliberately avoids ever introducing one. Activity that should stand out instead looks like ordinary system administration, which means an intruder can quietly learn your environment and run their code while staying under the radar. Defending against it is less about blocking files and more about watching how trusted tools are actually being used.
Report language
Finding: Inadequate Detection of Living-off-the-Land Techniques. During the assessment, the operator performed host, network, and Active Directory enumeration using only native Windows utilities (PowerShell, WMI, net, and dsquery) and achieved code execution through Microsoft-signed binaries (rundll32.exe and installutil.exe), bypassing the application allowlisting policy. No alerts were generated for the enumeration activity, and the signed-binary execution was permitted by the default AppLocker rules, which allow any binary located within C:\Windows.
Severity: Medium to High, depending on the sensitivity of the environment and the maturity of monitoring.
Recommendation: Implement behavior-based detection for known LOLBin abuse patterns rather than relying on signature or path trust. Enable PowerShell script-block logging, block legacy PowerShell v2, and pair AppLocker with Windows Defender Application Control. Baseline legitimate administrative activity so that anomalous use of native tooling from non-administrative hosts generates alerts.
Common weak answers
- Calling living off the land "a tool" or "an exploit." It is a posture, choosing to use what is already on the system, not a single technique or CVE.
- Saying LOLBins "bypass antivirus" without explaining why: the binaries are Microsoft-signed and live in trusted locations, so allowlists and detection rules permit them by default.
- Listing commands without explaining the goal. The point is stealth and blending in, not just "running commands natively."
- Confusing the enumeration side (native commands for quiet recon) with the execution side (signed binaries abused to run a payload past allowlisting). A strong answer distinguishes both gains.
- Claiming it requires no skill because the tools are built in. Knowing which benign binary can be coerced into code execution, and how to do it without tripping behavioral detection, is the actual expertise.
Interview answer
Living off the land means that once an attacker has a foothold, they deliberately use only the tools that already ship with Windows instead of uploading their own. Most defenses are tuned to catch new or unsigned tools landing on disk, so avoiding that entirely is the whole point. On the enumeration side, they use PowerShell, WMI, net, and dsquery to map the host, network, and domain, and that activity is hard to separate from normal administration. On the execution side, they abuse Microsoft-signed binaries like rundll32 or installutil to run their payload.
Those binaries work because they are signed and live under C:\Windows, so application allowlisting like AppLocker permits them by default, and the malicious action appears to come from a trusted Windows process. So the attacker gets to enumerate the environment and run code without ever crossing the line that "a new tool appeared" represents. Defending against it is about behavior, watching how trusted tools are used, not just blocking files.
Follow-up questions
- Why does a Microsoft signature and a path under C:\Windows make a binary attractive to an attacker, and what does that imply for how defenders should detect abuse?
- What is the difference between the enumeration benefit and the code-execution benefit of living off the land?
- How would you detect rundll32 or installutil being abused, given that both have legitimate uses?
- Why might an attacker invoke an older version of PowerShell, and what does that tell you about a logging gap?
- If a client has strong application allowlisting in place, why is living off the land still a relevant risk to test for?