LOLBAS

What is LOLBAS (Living Off The Land Binaries And Scripts)?

LOLBAS refers to legitimate binary files, scripts and libraries already present in the operating system or in standard environments that are actually intended for administration, diagnostics or system operation, but can be misused by attackers for malicious purposes. The official LOLBAS project documents such files, including possible misuse scenarios, and assigns them to typical attacker techniques.

For IT decision-makers, one point is particularly important: LOLBAS is not primarily about “classic malware”, which must first be introduced to systems, but about the misappropriation of existing, trustworthy system tools. This reduces the visibility for traditional protection mechanisms because the behavior formally originates from legitimate Windows components.

In strategic terms, this means that a company can be compromised despite having an up-to-date anti-virus solution, patch management and a clean software inventory if existing admin and system tools are not adequately controlled. LOLBAS is therefore not a peripheral issue for specialists, but a core aspect of modern endpoint and identity security.

What are LOLBins and how do they differ from LOLBAS?

LOLBins are the actual executable files, i.e. the “binaries” that can be abused. Examples are wmic.exe, cscript.exe or ftp.exe, which are described in the LOLBAS project with specific abuse functions such as execution, download, upload or proxy execution.

LOLBAS is the broader generic term. It includes not only binary files, but also scripts and libraries, i.e. scripts and libraries that are present in legitimate environments and can be misused by attackers. This is relevant for decision-makers because protection concepts must not only focus on EXE files; scripting languages, runtime environments and system-related libraries also need to be included in the risk assessment.

In practice, “LOLBins” is often used as a shortened synonym. However, it is technically correct to say that LOLBins are a subset of LOLBAS. Anyone defining governance, monitoring or guidelines should therefore always take a broader view of executable files, scripts and libraries.

Why are LOLBAS techniques dangerous for companies?

LOLBAS techniques are so risky because they abuse trust. Security products and administrators initially classify many of these tools as legitimate because they originate from the operating system manufacturer or are regularly used for IT operations. As a result, an attacker moves “in the shadow of legitimate administration”, so to speak.

This poses multiple risks for companies: firstly, attacks can remain undetected for longer. Secondly, the likelihood of attackers moving laterally in the network, leaking data or compromising other systems without immediately triggering an alarm increases. Thirdly, forensic evaluation is more difficult because the same tools are also used in regular operations.

From a management perspective, this is particularly relevant because LOLBAS is not a purely technical problem, but a control problem: a lack of transparency regarding privileged tools, unclear responsibilities, overly broad admin rights and inadequate telemetry significantly increase the risk. The issue therefore affects security, IT operations, IAM and compliance in equal measure.

How do LOLBAS differ from conventional malware?

LOLBAS techniques use existing and trusted system files, while traditional malware is usually inserted into the system as separate, recognizable code. Since LOLBins are part of the operating system, they are often not recognized as a threat by security solutions. Furthermore, no additional software is installed, which makes detection and forensic analysis much more difficult. Attackers can therefore act more inconspicuously and bypass security measures based on new or unknown files.

How can companies protect themselves against LOLBAS attacks?

1. Monitoring and logging:
   • Tools such as PowerShell should be run in restrictive modes that only allow signed scripts.
   • Monitoring tools such as Endpoint Detection and Response (EDR) can identify anomalies in the behavior of legitimate files.
2. enforce restrictions:
   • Application whitelisting: Only authorized programs may be executed.
   • Group Policies: Restrict which users have access to administrative tools such as PowerShell or WMI.
3. Training and sensitization:
   • IT teams should be trained to recognize typical signs of LOLBAS techniques.
4. Zero trust strategy:
   • A zero-trust architecture ensures that no application or file can be executed without restriction, even if it appears trustworthy at first glance.
5. Forensic analysis:
   • Logs from SIEM (Security Information and Event Management) systems can be used to track suspicious activities.

Which LOLBins are most frequently used by attackers?

The LOLBAS project shows a large number of Windows components that can be abused. Tools such as PowerShell, WMI/WMIC, Cscript/Wscript, MSHTA, Rundll32, Certutil, FTP and similar system programs are particularly frequently discussed and considered critical in many security architectures because they can execute commands, load content, start scripts or initiate other processes. The official directory documents specific cases of abuse for many of these programs.

At wmic.exe, for example, the LOLBAS project describes abuse for command execution, remote execution and even the creation of shadow copies, which can be relevant for further attack steps. ftp.exe is described there for launching commands and downloading files, among other things. Such functions show why standard tools are attractive in attack chains: They combine availability, trustworthiness and operational usefulness.

For decision-makers, it is less important which tool is used “most frequently” than which categories are approved and monitored in their own company: Script interpreters, remote management tools, installation and signature tools as well as programs with a network or proxy function. This is where the risk is typically concentrated.

How do attacks with LOLBAS actually work?

Typically, an attack does not start with LOLBAS, but with initial access via phishing, compromised credentials, exploitable services or another vulnerability. Attackers then use existing system tools to execute further commands, load additional content, build persistence or reach other systems. LOLBAS is therefore often a building block within a multi-stage attack chain.

A typical process can look like this: After successful login, an attacker uses a legitimate tool for script execution or remote control, loads additional components via an existing system program or retrieves commands from the network. The LOLBAS project documents these types of use cases very specifically, such as “Execute”, “Download”, “Upload”, “ADS”, “AWL Bypass” or “Remote”.

Crucial from a management perspective: LOLBAS attacks often appear unspectacular because they do not necessarily start with a new EXE file or an immediately visible malware dropper. The risk lies precisely in operational normality. A legitimate process starts another legitimate process – only in a malicious chain. This is precisely why context, correlation and behavior analysis are more important than pure file scanning.

What is fileless malware in the context of LOLBAS?

In the context of LOLBAS, fileless does not necessarily mean “completely without files”, but mostly: The malicious code is preferably executed in memory, by script or via existing tools instead of being stored on the hard disk as a classic malware file. This reduces the attack surface for signature-based detection.

PowerShell is a good example of this because Microsoft itself documents that Script Block Logging can log the processing of commands, script blocks, functions and scripts. This recommendation alone shows that PowerShell is not only an admin tool, but also a central observation point for memory and script-based activities.

For IT decision-makers, “fileless” means two things in particular: firstly, the effectiveness of purely file-based controls decreases. Secondly, the value of telemetry from memory, process, script and network activities increases. Anyone who only wants to address this risk with classic AV is defending the present with tools from the past – somewhat exaggerated, but unfortunately often true.

Why do classic antivirus solutions fail to detect LOLBAS?

Traditional antivirus solutions have historically focused heavily on known malicious files, signatures and unique malware artifacts. LOLBAS techniques, on the other hand, use regular operating system components. This means that the executed file itself is often not suspicious, but only its context, its command chain or its interaction with other processes.

This is precisely why Microsoft emphasizes behaviour-related controls such as attack surface reduction rules and the evaluation of audit and event data in protective measures against script- and app-based attacks. These controls are not only applied to the file itself, but also to risky behavior patterns and process relationships.

For decision-makers, the consequence is clear: a simple “Does the company have antivirus?” is no longer a meaningful maturity level question. The more robust question is: Can the security architecture detect, classify and stop the misuse of legitimate tools? If you don’t have a clear answer to this question, you probably have a detection gap.

How can LOLBAS attacks be detected?

Detection is primarily based on behavior analysis, logging and correlation. Microsoft documents script block logging, module logging and transcription for PowerShell, whereby script block logging logs the content of processed script blocks. This data is central to the detection of unusual commands, obfuscated scripts or administrative activities outside of normal behavior.

Process chains and target relationships are also important: Which legitimate file starts which child process? Is a normally harmless tool suddenly used for downloading, remote code execution or policy circumvention? The LOLBAS project lists precisely these types of misuse per binary and is therefore very well suited as a reference for detection engineering and use case design in SIEM or EDR.

From a control perspective, reliable detection requires three levels: clean telemetry, use cases based on real abuse paths and operational baselines. Without a baseline, all detection produces is alarm noise; without telemetry, it remains blind; without clearly defined use cases, it remains academic. The trick is therefore not to collect as many logs as possible, but to recognize deviant use of legitimate tools in a targeted manner.

What measures protect against LOLBAS attacks?

Effective protection consists of a combination of several controls. Microsoft recommends Attack Surface Reduction Rules, which are explicitly designed to make attacks with apps and scripts more difficult, and advises testing rules in audit mode first in order to understand the impact on specialist applications. This is important for companies because security measures against LOLBAS often affect operational processes and therefore need to be implemented properly.

Equally important is the reduction of unnecessary tools and rights. Not every system needs every administrative function. The fewer freely usable scripting, remote and auxiliary tools are available or executable, the smaller the attack surface that can be abused. Restrictive guidelines, application control, clean role models and the hardening of privileged accounts also help.

A pragmatic triad is recommended for decision-makers: 1. increase visibility, 2. reduce the area of abuse, 3. improve responsiveness. In other words: First know which tools are actually being used; then stop unnecessary use; then be able to quickly interrupt suspicious use. Everything else sounds great in PowerPoint, but only helps to a limited extent in an incident.

What role does LOLBAS play in modern cyberattacks, such as ransomware or APTs?

MITRE ATT&CK repeatedly documents the use of living-off-the-land techniques by groups and campaigns. This shows that such methods are not theoretical, but an integral part of real attack patterns. Living-off-the-land is also explicitly mentioned in campaign descriptions in connection with defense evasion, webshells and multi-stage attack chains.

In the context of ransomware, LOLBAS is particularly relevant because human-driven attacks typically do not encrypt immediately, but first perform reconnaissance, privilege escalation, lateral movement and data leakage. It is precisely in these phases that legitimate admin and system tools offer high operational benefits. In the Attack Surface Reduction environment, Microsoft explicitly refers to protection against advanced threats such as human-operated ransomware.

For IT decision-makers, this means a clear priority: LOLBAS is not a special topic for threat hunters, but a strategic indicator of the maturity of cyber defense. Those who cannot control the misuse of legitimate tools will be less able to recognize the early phases of modern attacks and will often only react when the economic damage has already been done. This is precisely why LOLBAS belongs on the agenda in security architecture, detection strategy, hardening guidelines and crisis prevention in equal measure.

What is a LOLBin?

An LOLBin (Living Off The Land Binary) is a legitimate system file or script that was originally developed for administrative or diagnostic purposes. However, attackers use these files to carry out malicious activities without injecting new, suspicious files into the system. This approach makes detection by traditional security solutions such as antivirus programs more difficult. One example is “certutil.exe” on Windows systems, which was developed to manage certificates but can also be misused to download malware.

What is an example of a LOLBin?

One prominent example is “powershell.exe”, a powerful administration tool on Windows operating systems. Attackers can use PowerShell scripts to execute commands, exfiltrate sensitive data or load malware. Another example is “mshta.exe”, a file for executing HTML applications that attackers use to execute malicious JavaScript or VBScript codes.

Which LOLBins are used most frequently?

• powershell.exe: For the execution of scripts and automation. Often misused to bypass security controls.
• wmic.exe: Enables queries and manipulation of system information and is often used to execute commands on multiple devices.
• mshta.exe: Loads malicious HTML or VBScript files.
• rundll32.exe: Used to execute DLL files that may contain malicious code.
• certutil.exe: Is used to manage certificates, but also to transfer data via HTTP.

These tools are particularly attractive because they are pre-installed in most operating systems and are considered trustworthy.

Are there resources to learn more about LOLBAS?

The LOLBAS project is one of the most comprehensive resources for IT decision makers and security experts. It documents a variety of known LOLBins, LOLLibs (Living Off The Land Libraries) and LOLScripts, including their legitimate and abusive uses. It also contains recommendations for prevention and identification.

Zurück zur Übersicht des Glossars