LatLoader – Evading Elastic EDR In Lateral Movement

LatLoader is a PoC module to demonstrate automated lateral movement with the Havoc C2 framework. The main purpose of this project is to help others learn BOF and Havoc module development.

This project can also help others understand basic EDR rule evasions, particularly when performing lateral movement. The sideload subcommand is the full-featured PoC of this module.

It will attempt to perform lateral movement via DLL sideloading while evading default Elastic EDR rules.

For a full list of every rule evaded by this module and how it was done, please see the below section titled Elastic EDR Rule Evasions.

Video demo w/ Elastic EDR

Dependencies/Basic Usage

This module was designed to work on Linux systems with mingw-w64 installed. Additionally, you must have osslsigncode installed to provide cert signing for the DLL utilized by the sideload subcommand.

Once all dependencies are installed, simply type make and then load the module into Havoc using the script manager. To view help in Havoc, run help LatLoader.

To view help for subcommands, run help [subcommand].

Usage/Subcommands

The LatLoader module contains 5 different subcommands. The first two, rupload and exec, serve as the main mechanism for executing the provided BOFs.

The 3 other subcommands (load, xorload, & sideload) combine the previous two in order to perform automated lateral movement.

The rupload command can be used to upload a local file to a remote system via SMB using the writefileBOF.c BOF like so:

LatLoader rupload dc1 /root/demon.x64.exe C:\Windows\Temp\test.exe

The exec subcommand can be used to execute a command on a remote system via WMI using the wmiBOF.cpp BOF like so:

LatLoader exec dc1 "cmd.exe /c whoami > C:\poc.txt"

The load subcommand combines the two subcommands above to transfer a specified exe to the remote host via SMB and execute it over WMI:

LatLoader load dc1 /root/test.exe

The xorload subcommand will perform lateral movement using a simple shellcode loader. This is designed to bypass basic AV detections:

LatLoader xorload dc1 /root/demon.x64.bin

Finally, the sideload subcommand will perform lateral movement by DLL sideloading a simple shellcode loader. Actions were also taken to evade various elastic EDR rules.

LatLoader sideload dc1 /root/demon.x64.bin

Elastic EDR Rule Evasions

The following is a list of various Elastic EDR rules that could alert when performing lateral movement. I have provided what steps were taken to evade each rule.

All evasions described here were implemented in the sideload subcommand to demonstrate how they can be combined to create a fully functional PoC.

Remote Execution via File Shares

Description: Identifies the execution of a file that was created by the virtual system process. This may indicate lateral movement via network file shares.

Bypass: This rule was bypassed by performing DLL sideloading.

Malicious Behavior Detection Alert: Unsigned File Execution via Network Logon

Description: Identifies the execution of a recently created file that is unsigned or untrusted and from a remote network logon. This may indicate lateral movement via remote services.

Bypass: This rule was bypassed by performing DLL sideloading.

Malicious Behavior Detection Alert: Execution of a File Dropped from SMB

Description: Identifies the execution of a file that was created by the virtual system process and subsequently executed. This may indicate lateral movement via network file shares.

Bypass: This rule was bypassed by executing the transferred file using cmd.exe /c. This evades the rule because the file is not executed directly, but instead by a trusted binary.

WMI Incoming Lateral Movement

Description: Identifies processes executed via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement, but could be noisy if administrators use WMI to remotely manage hosts.

Bypass: This rule was bypassed by including a path in our command that the rule excludes. As seen in the query, C:\\Windows\\CCMCache\\* is one of these directories, which was appended to each wmi command like so: && echo --path C:\\Windows\\CCMCache\\cache

Malicious Behavior Prevention Alert: DLL Side Loading via a Copied Microsoft Executable

Description: Identifies when a Microsoft signed binary is copied to a directory and shortly followed by the loading of an unsigned DLL from the same directory.

Adversaries may opt for moving Microsoft signed binaries to a random directory and use them as a host for malicious DLL sideloading during the installation phase.

Bypass: This rule was bypassed by signing the DLL sideloader with an expired cert. The expired cert was obtained from here

Malicious Behavior Prevention Alert: VirtualProtect API Call from an Unsigned DLL

Description: Identifies the load of an unsigned or untrusted DLL by a trusted binary followed by calling VirtualProtect API to change memory permission to execute or write. This may indicate execution via DLL sideloading to perform code injection.

Bypass: This rule was bypassed by signing the DLL sideloader with an expired cert. The expired cert was obtained from here

Potential Lateral Tool Transfer via SMB Share

Description: Identifies the creation or change of a Windows executable file over network shares. Adversaries may transfer tools or other files between systems in a compromised environment.

Bypass: This rule was bypassed by creating the file via SMB with a safe extension like .png, and then making a copy of the file with it’s real extension via WMI.

Malicious Behavior Detection Alert: ImageLoad of a File dropped via SMB

Description: Identifies the transfer of a library via SMB followed by loading it into commonly DLL proxy execution binaries such as rundll32, regsvr32 and shared services via svchost.exe. This may indicate an attempt to remotely execute malicious code.

Bypass: This rule was bypassed by creating the file via SMB with a safe extension like .png, and then making a copy of the file with it’s real extension via WMI.

Standalone Binaries

I have also provided standalone versions of the BOFs used in this project. These could be useful if you are unfamiliar with BOF development and would like to learn by comparing a normal program to it’s BOF counterpart.

wmiexec.cpp is the standalone binary for command execution via WMI. It can be compiled with mingw like so:

x86_64-w64-mingw32-g++ wmiexec.cpp -I include -l oleaut32 -l ole32 -l wbemuuid -w -static -o /share/wmiexec.exe

The exe can then be transferred to the target and executed like so, providing arguments via the cli:

.\wmiexec.exe dc1 'cmd.exe /c whoami > c:\test.txt'

writefile.c is the standalone binary for file transfer via SMB. It can be compiled with mingw like so:

x86_64-w64-mingw32-gcc writefile.c -w -static -o /share/writefile.exe

The exe can then be transferred to the target and executed like so, providing arguments via the cli:

.\writefile.exe .\test.txt \\dc1\C$\poc.txt