Cyber security

Cobalt-Strike-Profiles-For-EDR-Evasion + SourcePoint Is A C2 Profile Generator For Cobalt Strike

Bypassing Memory Scanners

The recent versions of Cobalt Strike have made it so easy for the operators to bypass memory scanners like BeaconEye and Hunt-Sleeping-Beacons.

The following option will make this bypass possible: set sleep_mask “true”; By enabling this option, Cobalt Strike will XOR the heap and every image section of its beacon prior to sleeping, leaving no string or data unprotected in the beacon’s memory.

As a result, no detection is made by any of the mentioned tools.

BeaconEye also fails to find the malicious process with the sleeping Beacon:

While it bypassed the memory scanners, cross-referencing the memory regions, we find that it leads us straight to the beacon payload in memory.

This demonstrates that, since the beacon was where the API call originated, execution will return there once the WaitForSingleObjectEx function is finished.

The reference to a memory address rather than an exported function is a red flag. Both automatic tooling and manual analysis can detect this.

It is highly recommended to enable “stack spoof” using the Artifact Kit in order to prevent such IOC. It is worthwhile to enable this option even though it is not a part of the malleable profile.

The spoofing mechanism must be enabled by setting the fifth argument to true:

During the compilation, a .CNA file will be generated and that has to be imported in Cobalt Strike. Once imported, the changes are applied to the new generated payloads.

Let’s analyze the Beacon again:

The difference is very noticeable. The thread stacks are spoofed, leaving no trace of memory address references. It should also be mentioned that Cobalt Strike added stack spoofing to the arsenal kit in June 2021.

However, it was found that the call stack spoofing only applied to exe/dll artifacts created using the artifact kit, not to beacons injected via shellcode in an injected thread.

They are therefore unlikely to be effective in obscuring the beacon in memory.

Bypassing Static Signatures

It is time to test how well the beacon will perform against static signature scanners.

Enabling the following feature will remove most of the strings stored in the beacon’s heap: set obfuscate “true”; Once the profile is applied to Cobalt Strike, generate a raw shellcode and put it in the Shellcode loader’s code.

Once the EXE was compiled, we analyzed the differences in the stored strings:

During many test cases we realized that the beacon still gets detected even if it is using heavy-customized profiles (including obfuscate). Using ThreadCheck we realized that msvcrt string is being identified as “bad bytes”:

For more information click here.

Varshini

Varshini is a Cyber Security expert in Threat Analysis, Vulnerability Assessment, and Research. Passionate about staying ahead of emerging Threats and Technologies.

Recent Posts

Understanding the Model Context Protocol (MCP) and How It Works

Introduction to the Model Context Protocol (MCP) The Model Context Protocol (MCP) is an open…

6 days ago

The file Command – Quickly Identify File Contents in Linux

While file extensions in Linux are optional and often misleading, the file command helps decode what a…

6 days ago

How to Use the touch Command in Linux

The touch command is one of the quickest ways to create new empty files or update timestamps…

6 days ago

How to Search Files and Folders in Linux Using the find Command

Handling large numbers of files is routine for Linux users, and that’s where the find command shines.…

6 days ago

How to Move and Rename Files in Linux with the mv Command

Managing files and directories is foundational for Linux workflows, and the mv (“move”) command makes it easy…

6 days ago

How to Create Directories in Linux with the mkdir Command

Creating directories is one of the earliest skills you'll use on a Linux system. The mkdir (make…

6 days ago