A threat actor associated with the LockBit 3.0 ransomware operation is abusing the Windows Defender command line tool to load Cobalt Strike beacons on compromised systems and evade detection by security software.
Cobalt Strike is a legitimate penetration testing suite with extensive features popular among threat actors to perform stealthy network reconnaissance and lateral movement before stealing data and encrypting it.
However, security solutions have become better at detecting Cobalt Strike beacons, causing threat actors to look for innovative ways to deploy the toolkit.
In a recent incident response case for a LockBit ransomware attack, researchers at Sentinel Labs noticed the abuse of Microsoft Defender’s command line tool “MpCmdRun.exe” to side-load malicious DLLs that decrypt and install Cobalt Strike beacons.
The initial network compromise in both cases was conducted by exploiting a Log4j flaw on vulnerable VMWare Horizon Servers to run PowerShell code.
Side-loading Cobalt Strike beacons on compromised systems isn’t new for LockBit, as there are reports about similar infection chains relying on the abuse of VMware command line utilities.
Abusing Microsoft Defender
After establishing access to a target system and gaining the required user privileges, the threat actors use PowerShell to download three files: a clean copy of a Windows CL utility, a DLL file, and a LOG file.
MpCmdRun.exe is a command line utility to perform Microsoft Defender tasks, and it supports commands to scan for malware, collect information, restore items, perform diagnostic tracing, and more.
When executed, the MpCmdRun.exe will load a legitimate DLL named “mpclient.dll” that is required for the program to operate correctly.
In the case analyzed by SentinelLabs, the threat actors have created their own weaponized version of the mpclient.dll and placed it in a location that prioritizes loading the malicious version of the DLL file.
The executed code loads and decrypts an encrypted Cobalt Strike payload from the “c0000015.log” file, dropped along with the other two files from the earlier stage of the attack.
While it’s unclear why the LockBit affiliate switched from VMware to Windows Defender command line tools for side-loading Cobalt Strike beacons, it might be to bypass targeted protections implemented in response to the previous method.
Using “living off the land” tools to evade EDR and AV detection is extremely common these days; hence organizations need to check their security controls and show vigilance with tracking the use of legitimate executables that could be used by attackers.
Comments
matziq - 1 year ago
The title of the blog suggests they bypassed Defender. Do better. Clicks aren't everything.
"After establishing access to a target system and gaining the required user privileges, the threat actors use PowerShell to download three files: a clean copy of a Windows CL utility, a DLL file, and a LOG file."
U_Swimf - 1 year ago
The last few i read from this guy have ambiguities about the context within.
Clicks are fairly important. But even more important is presenting accurate information..
Lawrence Abrams - 1 year ago
I disagree. The title suggests that Windows Defender was abused to install Cobalt Strike, which it was.
I can't even see how you got to the meaning that it was abused for initial access?
The point of the article is to illustrate how the threat actors are using Windows Defender as a LOLBin to evade detection.
https://twitter.com/GossiTheDog/status/1553724626802544640
plat1098 - 1 year ago
Many times, these threats are aimed at Enterprise. But a Home user could get infected also.
Some wax passionately about Defender, saying it can be used by itself. Fine. Doesn't stop me from hardening the OS a bit with a third party software. It only took one time to prove its worth to me.
UnknownArtist - 1 year ago
"In the case analyzed by SentinelLabs, the threat actors have created their own weaponized version of the mpclient.dll and placed it in a location that prioritizes loading the malicious version of the DLL file."
I thought this part could be more concise, especially for our threat hunters. Attackers would likely place mpclient.dll in the same location as their own copy of mpcmdrun.exe as executing it would find and load any dlls in its same directory first before it attempts to follow the environment's path. The second method would be elevating privileges to the extent that you could place a copy of mpclient.dll along the path. But because System32 is usually first, an attacker would need to modify the legitimate version of mpclient.dll which is risky for the attacker as many new files are scrutinized automatically upon arrival into the Windows environment, according to most EDR features, or so they say. Im new to this, so if Im wrong, feel free to correct me.