Living Off the Land Attacks: The Risks

“Living-off-the-land binaries” (aka LOLBINs) are assets or software tools that exist on endpoints as default components of the native operating system. Sometimes called “LOLBAS” in Windows environments for “living-off-the-land binaries and scripts,” these executables have legitimate uses but are often weaponized by attackers who leverage them in their attacks.

Exploitable binaries are found primarily on Windows, but also exist in macOS and Linux distros and are favorites of attackers because their use is a good technique for avoiding detection.

In this article we’re going to highlight the risks of LOLBINs and cover some strategies for mitigation.

What Are LOLBINS?

LOLBINs appear everywhere, and the bad news is that you often cannot delete them—they’re primary components of the operating system or other core applications.

On Windows, most are found in the System32 directory. They’re challenging to control because they aren’t inherently malicious, have legitimate functions, and are often executed during normal operation, preventing their use from being readily detected by antivirus and EDR tooling. This is what makes them an appealing vector for attackers.

There are a few tools that analysts can use when researching LOLBINs that provide some tools to get their hands around these threats.

• Windows – https://lolbas-project.github.io
• Linux – https://gtfobins.github.io

Two newer projects have emerged to tackle this issue for macOS and Windows drivers:

• Mac – https://www.loobins.io
• Windows Drivers – https://www.loldrivers.io

While the MITRE map provided by the LOLBAS project provides a good starting point for risks in Windows, you’ll see that most of the attack techniques (ex. Discovery tactic) are accomplished via LOLBINs. Almost every tactic required by the kill-chain to make an attack effective is available via native binaries. These, however, do not appear to be highlighted in this version at the time of writing.

The Windows Project

A great feature of the LOLBAS Project is that you can filter the results by MITRE technique or the functionality of the program. Although this project doesn’t cover common IT administration tools (like RMMs or Sysinternals), which may also be used in an attack with similar successful evasion from security tools, this is an excellent place to begin learning the base operating system packages.

The shear number of exploitable binaries is staggering, and a vast array of options exist for the attacker who doesn’t have to install anything “malicious” on the endpoint. It is an eye-opening project, and a huge value to the security community.

The Linux Project

The Linux project is slightly different but still allows for filtering by functionality so you can search to determine which binaries should be prioritized.

In The Wild

The term “Living Off the Land” was coined in 2013 by Christopher Campbell and Matt Graeber, but the acronym LOLBINs was proposed during a Twitter discussion much later. Still, these binaries have existed since operating systems began, even as far as DOS days.

Many of the LOLBINs are tied to some of the attack frameworks we are concerned about now.

Metasploit is one excellent example. It uses payloads and exploits, but it also abuses many things natively on Windows. These can be weaknesses but not always vulnerabilities.

PowerShell Empire is another one that, once it gets into an environment, the entire attack can be essentially perpetuated via PowerShell and other LOLBINs. The developers behind PowerShell Empire even decided it was so dangerous (particularly when Emotet began using it) that they stopped the framework’s development.

The developers behind PowerShell Empire decided it was too dangerous. Primarily because it was being used by so many threat actors at the time, including Emotet, for one, they stopped the framework’s development.

PowerSploit is still around and is just as formidable as PowerShell Empire. You still find this attack framework being used by threat actors.

PowerShell is one of the most dangerous binaries enterprises can have in their environments, as well as one of the most useful. Because of its widespread use, organizations can’t get rid of it. It’s also difficult to configure for monitoring and security controls, and there are many ways that commands and switches can be passed to it that obfuscate what’s happening.

Abuse of Powershell traditionally has a low detection rate (although significant improvements are made in detection tools each year) and can run script files off disk or directly in memory. The defense evasion is built-in because the actual binary (such as powershell.exe) isn’t malicious. Antivirus will often ignore LOLBINs (especially if the tools don’t analyze scripts or execution in memory), but some EDRs have started building detection rules for them; however, it is often found that they aren’t comprehensive yet. If your organization has custom rule capabilities, there are definitely ways to do this beyond OOTB detection rules in order to enhance your defenses.

LOLBINs can be used throughout the entire kill chain of an attack via scripts or manual intervention by threat actors. There is very little need, if any, to download malicious code onto a victim’s device or exploit vulnerable applications. This depends, of course, on the controls already in place.

One specific function that any attack will need is downloading a payload. PowerShell already has native commandlets that will download from the local network or public internet for execution:

• Net.WebRequest
• GetSystemWebProxy
• DownloadString
• DefaultWebProxy
• Net.WebClient

Besides PowerShell, there are many local programs on Windows built into the operating system that can be used to download malicious payloads:

Looking at this list and thinking about all the different functionalities they can have is overwhelming. While you can’t just delete all these files, there are ways to reduce the risk of them being weaponized in your environment.

Mitigating the Risks

Start by picking a binary from a living-off-the-land list. That’s where those projects become helpful – you can pull additional information from OS documentation (such as MSDN from Microsoft or man pages) as well. Review the features and switches to define capabilities. From one of the existing research projects, you can also filter, as described earlier, by the binary’s functions or kinds of behaviors that you are more concerned within your environment.

Query Your Environment

Use something like OSQuery or EDR to reveal where the selected binary is running in your environment. Once you know where it’s running and how it’s being used, you will have a baseline of the legitimate usage in your environment. Consider questions such as:

• Does it run at a specific time of day?
• Is it being used in an automated way, such as a running service or task?
• What account context is it running under?

Some LOLBINs may not be used at all—these are easy once to isolate for further action. Other findings will reveal what legitimate usage you need to exclude (such as certain hosts or scripts) if you later set any controls or detections around the binary at hand.

Evaluating Your Results

Once you evaluate the query results, you’re ready to reorganize devices or user groups as needed. It’s an excellent opportunity to clean up your Active Directory a little at the same time or create device groups in your EDR or SIEM. Grouping based on functions and access will allow for easier policy assignments to systems where the LOLBIN is required and allow blocking for devices or users, not in those groups.

PowerShell Research

My recommendation is to start with the biggest part first: PowerShell. This practice lets you learn more about your environment by seeing all the systems, unsigned scripts, and administrators using this application. This LOLBIN will likely take the longest to get your hands around, but controlling it will have the greatest effect on your security posture in the end due to its extreme preference by attackers.

You get a clear picture of where PowerShell is being used legitimately, group all the genuine devices and users, then prevent PowerShell from being run by anyone else or in other contexts.

Upgrading PowerShell to Version 5

Most security controls for PowerShell were not introduced until version 5 (current version is 7.3). This was the first version that included script-block logging, PowerShell transcription, and running PowerShell in constrained mode.

Through the querying process, you should be able to identify common PS1 scripts that run in your environment or systems/accounts using PowerShell regularly. By signing these repeated scripts, for example, you can add additional controls, such as not allowing unsigned scripts to run. It also allows you to lock down usage where PowerShell is not needed.

Banning Binaries

Now we can start looking at ways to ban these binaries in different ways in your environment. There are a few options here in this list below:

Via the Host Firewall: One approach is banning the LOLBIN in the firewall from making network connections, which is only partially effective. The binaries will still run in the environment, but outbound communication will be blocked.

Windows Registry via Group Policy: Another option is to ban them in the registry using Group Policy. It’s more challenging to manage due to a higher likelihood of implementation errors.

Applocker: Another option is using Applocker, but there are some known bypasses, such as via accounts with local admin privileges. This is an excellent time to take action if you haven’t gotten local admins under control already.

Windows Defender Application Control (WDAC): Here again, there are some known bypasses, but there is some excellent documentation on Microsoft’s site on configuring WDAC that explains the different ways to ban binaries using this tool.

Aaronlocker: This tool can be found on Microsoft’s GitHub, and it can help prevent the bypasses for Applocker and WDAC. It also allows you to enable more control over application execution in your environment.

Commercial Solutions: There are also commercial whitelisting solutions that can help set policies and alert when banned binaries attempt to execute.

Bonus Points

Using the same methodology, there are other ways to control or block what’s running in your environment that are likely to avoid detection due to their common legitimate usage. Here are a few examples:

Macros: Typically, one or two departments at most need to run macros (unless maybe you’re a financial institution). By locking down macros to only users who need them, you can greatly reduce your potential attack surface.

Script Interpreters/IDEs: Some of these are already on the device, like PowerShell ISE, but your environment may have others, such as Anaconda. Control these applications just as you would the native binary that runs the scripts during normal execution. Usage for IT admins or developers who require these tools can be made as exceptions.

Third-Party Apps: For example, you may have Java that is outdated or systems and users that have no reason to be near Java. Same applies to Python, remote management tools (additional favorites of attackers such as TeamViewer), or common IT tools like ProcDump, PuTTY, or Rclone. Blocking these applications can reduce your organization’s attack surface even further.

While this may seem like a lot to take on, it’s an excellent exercise to assign to new analysts or engineers who want to learn threat hunting. They can iterate through the baselining process, which will pay off in their later hunts. Putting this on to the same person or team can bring many benefits in the end and help secure your organization against some of the most effective techniques in the hands of attackers today.