2 min read

Crystal Kit

tl;dr - repo here.

The Crystal Kit is an experimental project designed to replace Cobalt Strike's Sleepmask. The Sleepmask (and BeaconGate) are key to Beacon's runtime evasion strategy - not only does it mask Beacon's memory, it also acts as an API proxy for Beacon (and BOFs). This allows operators to wrap supported API calls in custom evasion techniques, such as call stack spoofing.

In my view, the aspect of BeaconGate that holds it back the most is the limited number of APIs that it supports. For instance, not supporting CreateProcessA means that any postex command that spawns a process (shell, run, powerpick, execute-assembly, etc) are difficult to use when up against defences that employ call stack analysis. It also impacts process injection BOFs because it doesn't support that many APIs that are useful for novel injection techniques. And although not a weakness of the Sleepmask directly, there's quite a significant gap when it comes to the runtime evasion of postex DLLs. Since there is no Sleepmask/BeaconGate equivalent for postex DLLs, there's no CS kit that ergonomically allows operators to implement similar evasion techniques for API calls that they make.

IAT hooking is a technique that's been shown in the past by reflective loaders like TitanLdr and AceLdr. The strategy is to inject a PIC blob into memory and hook the IAT of the DLL as it's being loaded. The hooked APIs are redirected to the PIC blob, which performs the evasions developed by the author.

Crystal Palace is specifically designed to load multiple resources as PIC and provide conventions for accessing them as symbols in your code. This greatly reduces the burden on the developer to get all these components working with each other. Two interesting samples included in the garden are simplehook and stackcutting. The hooking sample shows how a PICO can hook the IAT of the DLL to mask/unmask memory before and after an API call; and the stackcutting sample shows how a hooked API can be pushed through PIC that implements a call stack spoofing technique.

Between them, we have a solid foundation for a POC, which is what I've essentially put together.

The Crystal Kit provides:

  • A prepended reflective loader.
  • A PIC stub that performs call stack spoofing (based on Draugr).
  • A PICO that hooks the DLL's IAT.
  • An Aggressor script that registers the relevant hooks in Cobalt Strike.

The two big wins for this approach are that it allows us to hook APIs that are not supported by BeaconGate; and it's compatible with postex DLLs as well! It means that Beacon can call APIs (like CreateProcessA) and have them benefit from the same evasion techniques as can be provided by the Sleepmask. It completely opens up the APIs that a BOF can call with those same evasion techniques, without Beacon having to explicitly expose them. And hooking LoadLibrary in postex DLLs provides a huge pushback against detections that target image loads (e.g for System.Management.Automation.dll and clr.dll).

There's a lot of detail that I could go into about why I made certain design decisions, particularly in the reflective loaders and the hooking PICO, but perhaps that's another post for another day (if there's interest).