In 2025, 82% of the detections CrowdStrike recorded contained no malware. No new file to scan, no signature to recognise. The adversary walked in on valid credentials and moved around using programs already on the machine, signed by Microsoft and cleared to run.
That figure, published in the firm's 2026 Global Threat Report, stood at 51% five years earlier. The technique has its own name in defensive shorthand, living off the land, and it describes the attacker who brings no tools because yours will do. The problem for a defender is blunt. When a legitimate binary carries out the malicious action, traditional antivirus has nothing to compare it against.
What a LOLBin actually is
LOLBin is short for living-off-the-land binary. An executable that ships with the operating system, signed and used every day, which alongside its stated job can do something useful for an attacker: download a file from the internet, run a script, inject code into another process, or slip past an application allowlist.
The community catalogue that documents these abuses, the LOLBAS project, lists more than a hundred Windows binaries with capabilities of this kind. None of them is a vulnerability. certutil.exe exists to manage certificates, and it also knows how to download and decode files. rundll32.exe loads libraries, and it also runs code on demand. These are legitimate functions that, taken out of context, serve a very different purpose. MITRE ATT&CK groups them under the technique System Binary Proxy Execution (T1218) and several related ones.
The upshot is that the line between legitimate administration and attack no longer sits in the file; it sits in the context. The same PowerShell your systems team uses to push out an update is the one an intruder uses to fetch the next stage. What tells them apart is who invokes it, from where, with which arguments, and what it does next.
Why antivirus and application control miss it
Three properties let these techniques walk through controls built for malware. The first is the signature. These binaries are signed by Microsoft, so a control based on file reputation or digital signature waves them through, because they genuinely are legitimate.
The second is that nothing new lands on disk. An antivirus watching for files to appear has no event to inspect when the attacker simply calls a program that was already there. And application allowlisting, unless it is tuned, permits these binaries precisely because they are system components that plenty of legitimate tasks rely on.
The third is that the dangerous part lives on the command line, not in the executable. All of the intent (the URL it downloads from, the path it writes to, the script it runs) travels as an argument. If you are not recording full command lines, your telemetry registers that a system binary ran and little else. It is the same kind of blind spot we described when discussing EDR blind spots, except that here the gap comes from the depth of the log rather than an unmanaged device.
The families of abuse worth recognising
There is no need to memorise the hundred-odd binaries in the catalogue. It helps more to understand which categories of behaviour they fall into, because detection organises better by function than by name.
Interpreters and scripting engines
PowerShell, cscript, wscript and mshta run arbitrary code by design. They are the tool of choice for an attacker already inside, and also an everyday administration utility, which is why blocking them outright breaks legitimate work. Detection here leans on script block logging and the command line, not on stopping the interpreter from existing.
Download and transfer binaries
certutil, bitsadmin, curl and, for years now, tar itself pull the next stage of an attack onto the machine without a bespoke downloader. The defensive signal is context: certutil invoked with an argument that looks like a URL is anomalous on most fleets, because almost nobody manages certificates that way.
Execution proxies
rundll32, regsvr32 and mshta run code on another's behalf, which breaks the parent-child relationship an analyst expects. An office document that launches rundll32, which in turn opens a network connection, is a sequence that almost never maps to normal work.
Dual-use tooling
wmic, PsExec, schtasks and the remote administration utilities move an attacker from one machine to another using exactly the mechanisms your systems team relies on to manage the fleet. The signature is no help at all here; only knowing what is normal in your environment, and what is not, tells the two apart.
The joint guidance published by CISA, the NSA, the FBI and their international partners in 2024, written after the Chinese state group Volt Typhoon's intrusions into critical infrastructure, describes these categories in detail and settles on a single diagnosis: what is missing is not defensive tooling but a baseline that separates the rare from the routine.
If the signature is no use, what do you look at?
The mental shift this threat demands is to stop asking what a file is and start asking what a process is doing. Four signals hold most of the value.
- The full command line. It is the highest-return data point and the most neglected. Without recorded arguments, an execution event for certutil says nothing; with them, the download URL sits in plain sight. Windows offers it through process creation auditing and command-line logging (event 4688), and Sysmon enriches it.
- The parent-child relationship. Who spawned a process tells you as much as the process itself. Word spawning PowerShell, or a system service launching a script interpreter, are chains that rarely occur in legitimate work and stand out the moment you render them as a tree.
- The sequence of operations. A binary in isolation may be innocent; the chain is not. A download, a write to a temporary path, an execution and an outbound connection, all within seconds and linked together, form a behavioural pattern regardless of which signed binary runs each step.
- The integrity of the telemetry itself. When a source that should emit continuously falls silent, that silence is an alert in its own right. An adversary who tampers with the event log or stops an agent leaves a gap, and a gap where a signal used to be is worth investigating.
That change of focus, from artefact to behaviour, is the same argument behind modern detection engineering. A rule that counts covered techniques does not predict whether you will catch the attacker, because what traps an intruder living off the land is the behavioural anomaly rather than the match against a signature.
Detection starts in the telemetry, not the tool
Before buying anything, the question is whether you have the data. Hunting the abuse of legitimate binaries demands a specific kind of telemetry, and a good share of fleets are not collecting it with the depth required.
The starting point is process creation logging with the command line, on the endpoint and centralised. Sysmon adds the parent-child relationship, the hashes and per-process network activity, and its configuration largely decides what you will be able to see afterwards. On that base, user and entity behaviour analytics helps establish what is normal for each machine, so an invocation outside the usual pattern stands out instead of getting lost. None of this works without first deciding which sources matter and how long they are kept, which is exactly the conversation we set out on which logs to send to a SIEM.
Proactive hunting starts from a hypothesis instead of waiting for a rule to fire. A threat hunting team works from a premise (that someone is using a download binary outside maintenance windows, say) and tests it against the telemetry. It is work that rests on having the data and knowing the environment, and it is the kind of service we provide at Hard2bit, as a cybersecurity company, through a threat hunting service backed by a managed SOC.
Shrinking the surface before you have to detect
Detection is half the job. The other half is taking away the binaries you do not need available, so that abusing them stops being free.
Microsoft maintains a list of recommended block rules for application control that neutralises the most abused binaries without breaking the system, and a set of attack surface reduction rules that cut specific patterns, that target specific patterns, such as an office application spawning child processes. Applying the recommended block rules for Windows application control and tuning the allowlist so these executables only run where they are genuinely needed appreciably narrows the attacker's options.
A download binary is only useful if it can reach the attacker's server, so restricting where machines are allowed to connect, and watching for connections to unusual destinations, strips the utility from many of these techniques. None of these measures is new or exotic; what tends to be missing is the decision to apply them and the hardening that keeps them in place.
What this means for whoever runs security
For a board or a security lead, this shift carries an awkward budget implication. Historical investment concentrated on preventing malicious files from getting in, and that control remains necessary, yet it no longer covers most of the intrusive activity now detected. The adversary who walks in on valid credentials and operates with signed binaries trips none of those defences.
The useful questions for a provider or an in-house team are concrete. Do we record full command lines across the whole fleet, or only the process name? How long do we retain that telemetry? Do we know what is normal on our critical servers, or do we only have generic rules? Does anyone hunt proactively, or do we wait for an alarm to fire? If the answers show that visibility stops at the binary's name, that is the finding, and fixing it costs more in data discipline than in money for new tools.
This same move from artefact to behaviour runs through other current threats, from session takeover in Microsoft 365 to command and control hidden inside legitimate corporate traffic. The underlying pattern holds: when the attacker uses what you already trust, defence depends on knowing your own environment in enough detail to notice when something steps off the script.
Data and frameworks cited in this article: the CrowdStrike Global Threat Report 2026, the joint guidance from CISA, the NSA, the FBI and international partners on living-off-the-land techniques (February 2024), the community LOLBAS project and the MITRE ATT&CK and Microsoft documentation, reflecting the information available on 22 August 2026. The article describes detection and hardening controls from the defender's perspective and contains no reproducible attack procedures. Binary names are cited for their relevance to detection and correspond to legitimate operating-system components.
The telemetry, block-rule and hardening recommendations should be validated in a controlled environment before they are applied in production, because restricting script interpreters or administration binaries can affect legitimate tasks when it is not tuned for each organisation.
