Living off the Land (LOTL) and Fileless Malware Attacks

Living off the land (LOTL) attacks abuse legitimate tools already present in the environment (PowerShell, WMI, certutil, rundll32, mshta, bitsadmin) to carry out malicious actions while blending in with normal activity. What defines LOTL is the use of legitimate binaries and utilities to camouflage, not the absence of files: a LOTL attack can coexist with attacker-owned payloads or files. Fileless code, by contrast, is defined by running without writing a conventional file to disk, living in memory or in the system's own mechanisms (registry, WMI). Both techniques evade signature-based antivirus, but they answer different questions: LOTL is about which tools the attacker uses (legitimate ones) and fileless is about where the code lives (with no file on disk). Understanding the difference is key to detecting them.

For years, endpoint defense relied on identifying malicious files: an executable landed on disk, the antivirus compared it against a signature database and blocked it. Advanced attackers flipped that model on its head. If the operating system already ships powerful administration tools, why bring your own and risk detection? That idea is the core of living off the land (LOTL) attacks and fileless malware, two concepts that overlap but are not the same thing. In this article we explain what they are, how they differ, how adversaries operate and, above all, how to detect and mitigate them with a defensive mindset.

Key takeaways

• LOTL describes WHICH tools the attacker uses: legitimate system binaries (known as LOLBins).
• Fileless describes WHERE the malicious code lives: in memory or in system mechanisms, with no file on disk.
• Both evade signature-based antivirus: LOTL because the binary that runs is an already trusted legitimate utility, fileless because there is no file on disk to scan.
• Advanced groups and ransomware operators use them for persistence and lateral movement.
• Effective detection is behavior-based (EDR/XDR), with command-line telemetry and PowerShell logging.
• Mitigation relies on least privilege, application allowlisting and restricting the script interpreters.

What living off the land (LOTL) attacks are

A living off the land (LOTL) attack is one in which the adversary abuses legitimate tools already available in the environment to achieve their objectives, leaning on them to camouflage. The logic is simple: the operating system and its administration utilities include binaries signed by the vendor, trusted by default and present on virtually any machine. If the attacker can lean on them, their activity blends in with that of a legitimate administrator and stops standing out to traditional security solutions. What defines LOTL is not the absence of files (a LOTL attack can be combined with attacker-owned payloads), but that execution relies on legitimate utilities of the environment rather than on tools brought in by the attacker.

These utilities are called LOLBins (living off the land binaries) and are publicly catalogued in the LOLBAS project. The catalogue's purpose is to document which system binaries, scripts and libraries can be abused and for what functions (downloading content, executing code, evasion, persistence), so that defenders know what to watch.

Legitimate tools frequently abused

Among the best known native to Windows are PowerShell (the system's automation interpreter), WMI (Windows Management Instrumentation, for querying and controlling the system), certutil (certificate management that also allows encoding and downloading files), rundll32 (execution of DLL library functions), mshta (execution of HTML applications) and bitsadmin (background file transfer). To these are added third-party utilities very common in administration environments, such as PsExec (remote execution from the Sysinternals suite), which does not ship preinstalled by default on Windows and only counts as a LOTL tool when the binary is already available in the compromised environment. None of these tools is malicious in itself. They all have legitimate administrative uses, and that is precisely why they are so useful to an attacker: blocking them outright would break normal operational tasks.

Why they evade antivirus

Classic signature-based antivirus works by recognizing patterns in known malicious files. In a LOTL attack, the binary that runs is a legitimate utility, signed and trusted, not a suspicious executable to recognize by signature. What is malicious is not the file itself but the way it is used and the parameters it is invoked with (even if the attack also drops a file of its own, the signature engine has little more than a legitimate binary to analyze). That is why a file-centric engine has little to analyze, and detection must shift toward behavior. This same principle explains why many threat families, including variants described in our guide to types of malware, combine traditional payloads with LOTL techniques to maximize stealth.

What fileless malware is

Fileless malware is malicious code that runs without writing an executable to disk. Instead of leaving a binary the antivirus can scan, it lives in a process's memory or leans on the operating system's own mechanisms: scripts loaded and executed on the fly, WMI event subscriptions, registry keys that store the payload or scheduled tasks that relaunch it. By not depending on a file on disk, it leaves very little forensic trace and complicates post-incident analysis.

Where fileless code lives

Memory is the main stage. An attacker can inject code into a running legitimate process and operate from there, so that no trace of the payload exists on disk. The Windows registry is also abused as storage: the code or a loader is saved encoded in a key and retrieved at each boot. WMI offers an elegant persistence mechanism through event subscriptions that trigger execution when a condition is met. And scheduled tasks allow the code to be relaunched recurrently. In every case, the common denominator is the absence of a conventional executable file to analyze.

Low forensic footprint

The practical consequence of operating without a file is that traditional analysis techniques lose effectiveness. Searching for a suspicious binary on disk is useless if the payload only existed in memory and vanished on reboot. This trait makes fileless malware a relative of families designed for persistent stealth, such as rootkits, which also prioritize going unnoticed over leaving visible artifacts. Forensic investigation then requires capturing and analyzing memory, reviewing unusual persistence mechanisms and correlating telemetry rather than trusting a disk scan.

LOTL and fileless: overlapping but not the same

It is common to use both terms as synonyms, and in many real incidents they appear together, but they describe different dimensions of an attack. LOTL answers the question of WHICH tools the adversary uses: legitimate system binaries. Fileless answers the question of WHERE the malicious code lives: in memory or in system mechanisms, with no file on disk.

You can have one without the other. An attack can be LOTL without being fileless if, for example, it abuses a legitimate utility that does write a temporary artifact to disk. And it can be fileless without being strictly LOTL if it runs attacker-owned code injected into memory without leaning on a system binary. The most frequent case, however, is the combination: using PowerShell (LOTL) to load and execute a payload directly in memory (fileless). That combination best brings both advantages together, the stealth of a legitimate tool and the absence of a file, and it is the one that causes traditional defense the most headaches.

Who uses them and why

These techniques are especially popular among advanced groups and ransomware operators. Once initial access is achieved, the attacker needs to remain in the environment (persistence) and move toward other systems (lateral movement) without being detected. Tools like PsExec or WMI are ideal for that lateral movement because they are exactly what an administrator would use. In many attack chains, the credential theft phase with utilities such as those described in our article on Mimikatz and credential dumping relies on these same techniques to operate in memory and avoid leaving traces on disk.

How to detect LOTL and fileless attacks

If the problem is that there is no malicious file to recognize, the solution is to stop looking at the file and start looking at behavior. Effective detection is built on several complementary layers of telemetry and analysis.

Behavior-based detection (EDR/XDR)

The centerpiece is an endpoint detection and response solution that analyzes behavior instead of signatures. A modern EDR, or an XDR that correlates signals from multiple sources, observes sequences of actions: which process launches which other, with what parameters, what network connections it opens and what modifications it makes. That PowerShell exists is not suspicious; that an office document launches PowerShell, that it contacts an external domain and loads something into memory, is. It is also worth remembering that evasion techniques themselves evolve, a topic we cover in our analysis of EDR evasion and the role of LLMs.

Command-line telemetry and PowerShell logging

The full command line each process is invoked with is one of the most valuable detection sources against LOTL, because what is malicious usually lies precisely in the parameters. Logging and analyzing those command lines makes it possible to spot anomalous invocations of legitimate binaries. In the case of PowerShell, ScriptBlock logging and Module logging capture the content of what runs, even when it arrives obfuscated, and AMSI (Antimalware Scan Interface) allows the script to be inspected just before execution, narrowing the room for obfuscation.

WMI and registry monitoring

Since fileless code abuses WMI and the registry as persistence and storage mechanisms, monitoring the creation of WMI event subscriptions and changes to sensitive registry keys is essential. These activities are rare in normal operation, so their appearance warrants immediate attention.

SIEM correlation and mapping to MITRE ATT&CK

No isolated signal tells the whole story. Correlation in a SIEM allows scattered events (a login, a binary execution, a network connection) to be woven into a coherent attack narrative. Mapping observed techniques to the MITRE ATT&CK framework helps structure detection, understand what phase of the intrusion we are in and close visibility gaps systematically.

Proactive threat hunting

Because these techniques are designed to evade automatic detection, it is wise to complement it with proactive searching. Threat hunting starts from hypotheses (for example, looking for unusual invocations of certutil or mshta) and combs through telemetry for clues that automated rules might have missed. It is especially valuable against adversaries who tune their TTPs precisely to avoid triggering known alerts.

How to mitigate and reduce the attack surface

Detection matters, but reducing the attacker's opportunities up front is just as important. Several hardening measures notably limit the effectiveness of LOTL and fileless.

Least privilege and allowlisting

Applying the principle of least privilege reduces what an attacker can do even if they manage to execute code: without administrative permissions, many persistence and lateral movement techniques are blocked. Application allowlisting (permitting only what is explicitly authorized) is one of the most powerful countermeasures, because it stops the execution of unapproved code even when it leans on system interpreters.

Restrict and log the script interpreters

Interpreters like PowerShell are at once indispensable for administration and highly attractive to attackers. Restricting their use to what is necessary (for example, through constrained language modes where applicable), logging all their activity and watching who invokes them reduces the room for abuse without giving up their legitimate usefulness. The same logic applies to disabling macros in office documents, a classic initial-access vector, and to removing or restricting system utilities that are not needed in a given environment.

Reduce the available surface

Every present and enabled utility is a potential tool for the adversary. Reviewing which binaries and functions are truly necessary, disabling those that are not and controlling access to those that are directly shrinks the available LOTL arsenal. The point is not to break legitimate administration but to ensure that every powerful capability is justified, controlled and logged.

Frequently asked questions

What is the difference between LOTL and fileless malware?

LOTL describes which tools the attacker uses (legitimate system binaries, the LOLBins) while fileless describes where the malicious code lives (in memory or in system mechanisms, without writing a file to disk). They overlap and often appear together, but they answer different questions: one the what and the other the where.

Why does traditional antivirus fail to detect these attacks?

Because signature-based antivirus tries to recognize known malicious files. In LOTL the tool that runs is legitimate and signed (even if the attack drops a file of its own, the invoked binary is not suspicious by signature), and in fileless attacks the code may exist only in memory, with no file on disk to scan. What is suspicious is the behavior and the parameters, not the file, so detection must be behavior-based.

What are LOLBins and the LOLBAS project?

LOLBins (living off the land binaries) are legitimate binaries, scripts and libraries of the system itself that can be abused for malicious purposes. The LOLBAS project is a public catalogue documenting which ones they are and what offensive functions they enable (downloading content, executing code, evading defenses or persisting), so that defenders know what to watch.

What role does PowerShell play in these attacks?

PowerShell is a very powerful automation interpreter present by default in Windows, which makes it a common LOTL tool for loading and executing code directly in memory. That is why ScriptBlock logging, Module logging and AMSI are key controls: they allow inspecting and auditing what PowerShell executes, even when it arrives obfuscated.

How do you detect fileless malware if it leaves no file?

With behavior-based detection (EDR/XDR), command-line telemetry, PowerShell logging and AMSI, WMI and registry monitoring, and SIEM correlation mapped to MITRE ATT&CK. Since there is no file to scan, the key is to capture and correlate runtime activity and, when forensic analysis is needed, examine memory and persistence mechanisms.

What preventive measures reduce the risk of LOTL and fileless?

Least privilege, application allowlisting, restricting and logging the script interpreters, disabling unnecessary macros and removing utilities that are not needed. These measures reduce the attack surface and limit what an adversary can do even if they manage to execute code, complementing behavior-based detection.

Related resources

• Types of malware
• What is a rootkit: how it works and detection
• EDR evasion and LLMs: attacks and defense
• What is an EDR
• What is MITRE ATT&CK: tactics and techniques
• What is Mimikatz and credential dumping
• What is threat hunting
• What is malvertising and SEO poisoning

Professional help

At Secra we are an offensive cybersecurity company with our own vulnerability research program. Our work includes the discovery and responsible disclosure of CVEs, such as CVE-2025-40652 in CoverManager and CVE-2023-3512 in Setelsa ConacWin CB, both registered in NVD and INCIBE-CERT. Knowing firsthand how real adversaries operate, including living off the land and fileless techniques, lets us assess your defenses with a realistic perspective. If you want to test your organization's ability to detect this kind of stealthy activity, get in contact with us.