This repo is a technical and social experiment to explore whether replacing Cobalt Strike's evasion primitives (Sleepmask/BeaconGate) with a Crystal Palace PICO is feasible (or even desirable) for advanced evasion scenarios

A way to maintain long-term access to Windows LAPS for lateral movement in AD via installing an Offensive LAPS RPC backdoor on a DC.

Supporting PoCs and scripts for my talk "OverLAPS: Overriding LAPS Logic"

– Persistence Arsenal Kit
– Malleable Profile
– Module Stomping
– Shellcode Loader .cna for integration
– Asynchronous BOFs
– Out-of-the-Box Evasion Overhaul
– VNC and Other useful tools and scripts

Proof of Concept (PoC) implant for creating custom Cobalt Strike Beacons

UDRL loader for Cobalt Strike built with Crystal Palace that combines Raphael Mudge's page streaming technique with a modular call gate (currently a PIC version of the Sleepmask-VS Draugr callgate BOF).

This project enables the development of BOFs using Rust with full no_stdsupport. It leverages Rust's safety features and modern tooling while producing small, efficient COFF objects.

The framework provides everything needed for BOF development. The build process compiles your code to a static library, which boflink then links into a COFF object with proper relocations and imports for Beacon's dynamic function resolution.

WPvivid Backup & Migration ≤ 0.9.123 Unauthenticated RCE PoC (Cryptographic Fail-Open + Path Traversal)

This is a technique that does as the name implies: We use what is already available to us in the remote process of our choosing to accomplish a given goal. In this case, the goal will be to write shellcode indirectly into the remote process with as low of a footprint as possible. When I say indirectly, I mean we won’t be using WriteProcessMemory to write the shellcode. That API does play a small role, but ultimately we will be indirectly writing our shellcode in 8 byte chunks using ROP gadgets and assembly stubs all made available in the remote process. We will also avoid the creation of RWX regions of memory.

This vulnerability essentially works by forcing a process running as system and that uses the undocumented function Windows_Storage!_SHCoCreateInstance, to create an arbitrary COM object of our choice. For this to happen, the object must be associated with an already registered COM class that supports CLSCTX_INPROC_SERVER. Arbitrary COM object creation is archived by manipulating a CoCreateInstance call first argument

One more BYOVD. STProcessMonitor driver is not in Windows vulnerable driver blocklist and allows to terminate AV / EDR processes.

Customizable Linux Persistence Tool for Security Research and Detection Engineering.
www.rgrosec.com/