We can accomplish this with two calls to VirtualQuery. Now that we have an address for Beacon’s memory range, we need to find its base address. This will give us the address that Beacon will resume executing from after our BOF finishes, which is inside Beacon’s. This will get us from our function to our BOF entry point, to the return address of Beacon. When a BOF is executed, and we call a function from our BOF entry point, our stack frame looks like this at the top:īelow is a snippet of assembly to go back two stack frames. There are a few ways we could figure out this information, but the method I found to be most reliable uses a bit of assembly and the VirtualQuery API. To mask Beacon in memory, we need to know its base address and its size. A Developer’s Introduction to Beacon Object Files, TrustedSec.This blog is not intended to be a reference on BOFs, so you can find more information about BOFs here: Allocated BOF memory is cleaned up according to your Malleable C2 settings.Execution is passed to the entry point, your BOF content runs, and Beacon resumes executing.The BOF loader handles linking any imported functions and finding the specified entry point of the BOF.Beacon allocates memory according to your Malleable C2 settings and writes the BOF content.When you execute a BOF, it looks something like this: This allows operators to quickly develop post-exploitation tooling without the hassle of writing shellcode or reflective DLLs.
#Cobalt strike beacon code
If you’re unfamiliar with the internals of Beacon Object Files (BOFs), they’re essentially a way to write position independent code where Beacon handles loading and linking any dependencies. However, during normal BOF execution, Beacon is sitting in memory. This demonstrates that it is possible to have Beacon encrypted and sleeping during BOF execution. As of Cobalt Strike 4.7, Sleep Mask is implemented as a BOF, which provides the operator with much more control over how Sleep Mask works. This helps prevent detection by threat hunting tools or memory scanners that look for Beacon signatures or suspicious artifacts like unbacked executable memory. This can result in an EDR product finding your Beacon sitting in memory and killing the process.Ĭobalt Strike (somewhat) recently introduced the Sleep Mask functionality, which serves to hide Beacon in memory while it’s sleeping. While an initial beacon can go undetected, performing common post-exploitation activities from a Beacon Object File can trigger a memory scan of your process by EDR. You fire up your trusty BOF toolkit and watch the “last” timer tick up indefinitely.
The hard part is over, time to do some post-exploitation.
Picture this - you’re on a red team engagement and your phish went through, your initial access payload got past EDR, your beacon is now living in memory and calling back to you. In this post, we’ll review a simple technique that we’ve developed to encrypt Cobalt Strike’s Beacon in memory while executing BOFs to prevent a memory scan from detecting Beacon.
0 kommentar(er)
