RastaMouse
@rastamouse
make pic +relax
There's no constexpr in C, so the new __ror13_x intrinsic makes it easier to use hashes without the need for strings or pre-computed hashes. Useful when performing tasks like resolving syscalls. Just declare as a DWORD and use.
MSF's Railgun was massively underrated but incredibly powerful. Resolve and call an API without needing to alloc and run a whole BOF or DLL. I hope to get this implemented nicely in CrystalC2 at some point.
CS 4.13 is right around the corner, so I've been having a play with the new Beacon Interpreter. This script will stomp a PICO over a module, with unwind data, for post-ex.
Pushed 0.0.3 of my Crystal Palace VSC extension. It adds new +options, like +relax and +unwind; and adds better syntax support for the ised command.
I had the occasion to play with EAF the other day, so I added a bypass to the TCG's PIC services module. It provides a way to resolve Win32 APIs through gadget in NTDLL's .text section.
Created a small .NET tool for ROR13 hashing that you can install to add a global command to cmd/pwsh. It's a lifesaver if you just need some quick hashes.
No, not pushed yet. Still a few tweaks to be made. This is stock CPL too. Just managing the process state inside the client app.
I have a new version of the CrystalC2 client that supports BOF cocktails. It's also using the CPL linker sidecar API.
Built a custom version of Crystal Palace's linkserve. It adds an option to bind to 0.0.0.0 and takes an auth key in the HTTP request. Works great with Docker.
Having a play with BOF inversions to create atomic test units for detection engineering. Not that I'm a blue teamer of course...
Adding the Crystal Palace YARA generator to CrystalC2. The feedback loop between modifying the .spec, clicking 'build' in the client, and seeing the new rules is super-fast.
Added initial SOCKS support to CrystalC2. Keeping modularity in mind, the 'extension' needs to be enabled when building a payload. Note that it's the CrystalC2 client that acts as the SOCKS server (rather than the C2 server). Just point tools at your localhost and away you go.
Got some SOCKS magic working with CrystalC2 but the bigger challenge is how best to implement it. Make it a postex PICO? Expose an option to merge it into the agent at build time? Something else?
There's some elegance in the simplicity (imo), as it makes them very easy to modify or replace. Here's a view of the agent spec.
No, I'm currently just packaging a resources directory with the client release.
Built a C2 optimised for hyprland-style dynamic window tiling (instead of the class tab-approach)
I've been playing with a C2 built around PIC modularity for the last few weeks. C2 comms are merged into the agent at link time and output as shellcode. COFFs are transformed into PICOs for postex. Evasion tradecraft can be woven in via spec files. Very scriptable using Sleep.
The idea was to merge hooks into a BOF, 'make coff', then run via beacon_inline_execute. I don't think we want to attach the Beacon BOF APIs to funcs within the merged COFF though. What would you attach them to? Can't we just leave/ignore them so Beacon can link them to the proper internal funcs?