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

git fetch vs git pull: How They Work and When to Use Each

Both git fetch and git pull talk to a remote repository, but they do very different things to your…

4 days ago

git cherry-pick Command: Apply Commits from Another Branch

Sometimes the change you need already exists, just on the wrong branch. A hotfix lands…

4 days ago

Best Email APIs for Secure Business Email: Why Developers Are Moving Beyond SMTP

Email is still one of the most important communication channels inside modern applications. Password resets,…

5 days ago

Nginx Commands in Linux: Start, Stop, Reload, Test, and Log

Nginx is a high-performance web server and reverse proxy trusted by some of the largest…

1 week ago

ufw Command in Linux: Manage Firewall Rules with Examples

ufw (Uncomplicated Firewall) sits on top of iptables (or nftables on newer systems) and replaces…

1 week ago

who Command in Linux: Show All Logged-In Users and Sessions

When you share a server with a team or investigate unexpected activity, the first question…

1 week ago