Crystal Kit
好的,我现在需要帮用户总结一篇文章,控制在100字以内。用户的要求是直接写文章描述,不需要开头。首先,我得仔细阅读这篇文章,理解其主要内容。 文章主要讲的是Crystal Kit项目,目的是替代Cobalt Strike的Sleepmask。Sleepmask和BeaconGate在Beacon的内存逃逸中起关键作用,还能作为API代理。Crystal Kit通过IAT挂钩技术,允许开发者使用更多API,并且支持postex DLL的逃逸,这对安全研究人员和红队人员来说是个好消息。 接下来,我需要提炼这些信息,确保在100字以内。重点包括:项目目的、技术方法、优势以及适用场景。同时,语言要简洁明了。 可能的结构是:项目名称、目标、技术手段、优势和应用场景。例如:“Crystal Kit项目旨在替代Cobalt Strike的Sleepmask,通过IAT挂钩技术实现更广泛的API支持和内存逃逸功能,提升安全研究人员和红队的操作灵活性。” 检查一下字数是否符合要求,并确保没有遗漏关键点。 </think> Crystal Kit项目旨在替代Cobalt Strike的Sleepmask,通过IAT挂钩技术实现更广泛的API支持和内存逃逸功能,提升安全研究人员和红队的操作灵活性。 2025-10-12 18:43:4 Author: rastamouse.me(查看原文) 阅读量:126 收藏

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


文章来源: https://rastamouse.me/crystal-kit/
如有侵权请联系:admin#unsafe.sh