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.
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.