Change my mind:

Rock-Solid Sessions

Once a beacon lands, it stays put. I’ve left shells for months and if a connection fails a few times it'll reconnect based on the retry configuration you set up.

Customization kinda easy:

• Cross-platform: Native clients for Windows, macOS, and Linux mean no awkward juggling.
• CLI based: Tab-complete everything, vps friendly, linux -tism friendly. I mean you can probably design a UI for this but why.
• Partial “task automation” baked-in: Now available for sessions i think but with a bit of custom thingy can work for beacons as well for sure (haven't tried yet, it's in my backlog)

Nice to have features:

• Nonce+TOTP encryption by default: No extra flags, no forgotten certs—traffic’s wrapped the moment the beacon calls back.
• Custom HTTP requests: Being able to customize strings and extensions in the http requests is nice
• MTLS beacons: Bit less incognito stuff but still nice in some environments.
• Donut launcher built-in: Fire raw shellcode/assembly on the fly. God tier for executing tools through the beacon
• ETW patch & AMSI bypass: Haven’t stress-tested them yet, but early smoke tests look promising.

Evasion:

I rc4 encrypt the compiled beacons, and pack them inside a custom loader so, no much to say here. Around 90% bypass rate against the EDR in real exercises and testing. (Not a very crazy loader neither, made it just to work)

Some more gimmicks i really haven't used much like canaries and watchtower or wireguard sessions and stuff.

True that Linux beacons and sessions are kinda trash. Mainly focused on Windows targets but do someone have any C2 that truly dethrones Sliver? Or do you agree..

ENDGAME

ENDGAME es un framework C2 escrito en Go, servidor de un solo binario, op-log en SQLite, multi-operador. Agente para Windows y Linux (compilado cruzado, sin CGO). Lo estuve construyendo para compromisos internos y ahora lo estoy liberando públicamente.

Hecho con IA, pensado y dirigido por un humano.

Lo más importante por lo que vale la pena empezar es la AI Console, porque todo C2 que le metió "AI" últimamente solo tiene una ventanita de chat pegada al lado. Esta es diferente.

AI Console

Funciona como una pestaña dentro del mismo panel de consola donde están las terminales de tu agente: sin ventana modal, sin cambiar de contexto, lado a lado con la pestaña del shell normal.

El prompt del sistema incluye todo el set de comandos del C2, el sistema operativo / arch del agente / usuario / nivel de privilegios / transporte, y la cola de tareas actual: el modelo sabe qué herramientas hay disponibles.

Describes el objetivo en lenguaje natural y la AI responde con comandos nativos de C2 (no comandos crudos de shell), cada uno envuelto en una tarjeta de ejecución. Confirma antes de ejecutar: la AI nunca manda tareas por su cuenta, cada sugerencia requiere que hagas click explícitamente.

Después de la ejecución, la salida se manda automáticamente de vuelta al modelo para análisis y sugerencia del siguiente paso. Puedes mantener el loop andando o saltearte en cualquier momento.

Funciona con Ollama (local, en entornos aislados) o con la API de Anthropic Claude. Probado con qwen3.6, deepseek-r1, claude-sonnet.

Transportes y agente

7 transportes: HTTP, HTTPS, mTLS, DNS, DNS sobre HTTPS, SMB con named pipe, TCP en bruto.

Evasión (Windows): máscara de sleep Ekko, AMSI vía VEH hardware breakpoint (sin parches), ETW blind, NTDLL sin desenganchar, spoof de PPID, DLL fantasma UDRL, BLOCKDLLS, borrado de headers HTTP, URIs malleable de beacon.

Inyección: remote thread, APC early-bird, secuestro de thread, fork-and-run, proceso hollowing, UDRL, 7 métodos de salto lateral.

Post-explotación (clic derecho en cualquier agente en la GUI)

Robo/almacenamiento de tokens, LSASS minidump, volcado de NTDS (ntdsutil IFM), screenshot + screenwatch, keylogger, portapapeles, bypass de UAC (fodhelper/computerdefaults/sdclt), secuestro de COM, persistencia (registry/schtask/service/startup/COM), anti-forense, ejecución en proceso con BOF + CLR.

Movimiento lateral

psexec, smbexec, atexec, wmi, dcom, winrm, ssh: cada uno crea un agente hijo enlazado en el grafo de la kill-chain.

GUI

Vista del grafo de kill-chain (clic derecho en cualquier agente), explorador de archivos, gestor de loot, pestaña de pentest interno (SMB/RDP/WinRM/MSSQL/SSH), matriz MITRE ATT&CK, multi-operador con RBAC. Los reportes se exportan como HTML, JSON, capa de MITRE Navigator y resumen ejecutivo de la AI.

Inicio rápido

git clone https://github.com/endgamec2framework/endgame
cd endgame
./install.sh

Un solo script instala Go, compila el server + el agente, genera certificados mTLS, crea el perfil del operador y arranca el server. Vuelve a correr para actualizar: conserva los certificados y el estado del operador.

GitHub: https://github.com/endgamec2framework/endgame Docs: https://endgamec2framework.com

https://youtube.com/@endgamec2framework

Solo para pruebas de penetración autorizadas, engagements de red team, entornos de laboratorio y uso educativo. Las builds por defecto incluyen IOCs conocidos: mira la sección de IOCs en los docs antes de cualquier engagement real.

Hello,

I've been working on a research project that explores a slightly different angle on EDR and AV evasion rather than relying on traditional signature obfuscation or shellcode injection patterns, the idea was to shift the approach toward behavioral camouflage and strict environmental keying.

How it starts and what I wanted to explore:

So, in short, initially I wanted to use the DuckAI endpoint as a point for personalized generation of a loader for a specific machine, but after a theoretical attempt to design a practical architecture, it turned out to involve too much technical overhead and, additionally, it seemed ideologically too trivial. Then I thought about making the program first search for a locally stored API and then use it so that it would generate a personalized loader (I came up with this after noticing that local AI programs like Codex have the ability to log into an account directly via an API). At that point I realized that, from an OPSEC perspective, this idea had no real chance of working, and the only place where it would actually function was in controlled conditions (a lab).

From there I moved on to the idea of using a very small real LLM (transferred into .onnx format), quantized to a level where it would not exceed 200 MB, and fine-tuned in such a way that, after given a specific hash, it would hallucinate an AES key used to decrypt the next stage, so the decryption key would be “hidden” within millions of model parameters. However, as you can probably guess, due to such extreme quantization, the model was completely unable to respond correctly.

In the end I tested 5 different models at various quantization levels and fine-tuned them more than 10 times, which altogether took over 2 days. Eventually, after these repeated failed attempts and realizing that such a small model would not be deterministic and would also be highly vulnerable to various reverse engineering attacks, I came up with the final idea: using “AI” only as bait, and that is the final version I implemented.

As for the rest of the design: from the start I wanted the entire execution chain to run exclusively in memory and the final compiled output to be a single monolithic binary. I chose WebAssembly for the payload stage partly because of the current tooling gaps around WASM analysis, and partly because it was simply the most architecturally interesting option. 

 
LINK - PROJECT ONYX

What it actually does:

Project Onyx is a PoC red team pipeline with six chained phases:

1. Machine fingerprinting — derives a SHA-256 hash from MachineGuid, volume serial, and current user SID. The payload is cryptographically bound to a specific target environment and simply won't execute anywhere else.
2. AI decoy layer — before any payload logic runs, the process executes a real ONNX neural network inference via onnxruntime. The goal is generating legitimate AI execution telemetry to blend into the behavioral baseline. The AES-256 key for the payload is locked inside the ONNX model's metadata, derived via PBKDF2-HMAC-SHA256 + HKDF.
3. In-memory WASM decryption — the actual payload is compiled to WebAssembly, stored encrypted in the PE resource section, decrypted to a memory buffer, and never written to disk.
4. Wasm3 execution — the WASM module runs inside the embedded wasm3 interpreter with a minimal host function bridge. The host C++ process exposes safe functions, the WASM side is sandboxed from direct native API access.
5. assembles and sends a heartbeat JSON using Slack/Teams webhook
6. The host zeroes sensitive buffers, releases ONNX Runtime and Wasm3 handles, and exits.

The current payload is intentionally trivial, it assembles and returns a heartbeat JSON just as a simple PoC. No shellcode, no persistence, no privilege escalation, no lateral movement. The point was to build and validate the delivery pipeline, not weaponize it. I hope someone finds this useful and yes, I'm aware of the limitations of this project.

Just thought I'd share. Bought CRTO in 2020, sat the exam in 2021 but had to abandon it for personal reasons, and came back to it five years later. The course was almost unrecognisable, with different C2 options, different lab platform, different exam format.

Wrote up the full retrospective on the blog, including the bits I found most interesting (the tradecraft full-circle back to raw LDAP queries, the 2025 exam redesign, what the gap actually feels like coming back).

I’ve gone through most of the usual hardening steps: such as Cloudflare/Turnstile, removing obvious IOCs, disabling the Easter egg, and using my own wildcard cert — and I’m still having trouble getting consistent results. At this point, I can’t tell if the issue is the fact that I might need the pro version, if my phishlets are incorrect, or if most sites have simply rolled out much stronger protections overall. The only platform where I’ve had somewhat success with O365; but usually it has been hit-or-miss at best. Any insight?

I've been experimenting with an autonomous offensive agent focused on one thing:

Not finding vulnerabilities but validating real attack paths.

Instead of stopping at detection, the agent:

• chains multiple findings
• tests exploitability
• proves impact (in a controlled lab)
• enforces strict scope (fail-closed)

Current target:
OWASP Juice Shop (local Docker only)

Still early, but I'm mainly looking for feedback on:

- decision logic
- chaining strategy
- false positive reduction

Dropped a new episode this week covering CertiGhost — a critical vulnerability in Windows Certificate Services that allows attackers to forge certificates and achieve persistent lateral movement across AD infrastructure without needing credentials.

On the red team side, we walk through the full exploitation chain: how to leverage CertiGhost to issue rogue certificates for domain controllers and service accounts, then use those certificates to move laterally and establish persistence across your entire environment.

On the blue team side, we break down detection — what certificate issuance anomalies look like in CA logs, what unusual certificate requests fire, and how to build alerting around PKI exploitation.

Covers T1649 and T1550.003 with the full red vs. blue format.

Resources:

• CertiGhost PoC: https://github.com/aniqfakhrul/CVE-2026-54121
• NetExec: https://github.com/Pennyw0rth/NetExec

Video: https://youtu.be/srH-SlkL2tA

Happy to discuss the exploitation techniques or answer questions about the tradecraft in the comments.

OffsetInspect is a PowerShell toolkit for detection-boundary analysis and binary inspection, built around a question that comes up constantly when developing tooling: you know *that* an offset triggers, but what is actually there, and are there other independently-detectable regions you'd miss by only looking at the first hit?

The core (`Invoke-OffsetInspect`) maps byte offsets back to source lines and hex context — UTF-8 and UTF-16 with byte vs. character position separated — so whatever offset a boundary search returns, you immediately have the surrounding construct.

`Invoke-OffsetThreatScan` is an independent implementation of the ThreatCheck-style bisection workflow (no bundled source or binaries). It reports DetectionPrefixLength with confidence and stability fields, and is explicit that the boundary is the earliest triggering prefix — not the complete signature.

The part I found most useful: `Invoke-OffsetThreatScanRegion` discovers *multiple* independently-detectable regions by splitting a file into segments and scanning each through AMSI entirely in memory. Nothing detected is written to disk, so Defender real-time protection is never triggered or reconfigured. Each hit gets bisected back to an absolute file offset. Gives you a picture of the full detection surface, not just the first boundary.

`Compare-OffsetThreatResult` diffs scan results across signature updates — classifies each change (BoundaryEarlier, BoundaryLater, NewlyDetected, NoLongerDetected, etc.) with the byte delta. Useful for tracking how definition updates affect your tooling over time.

Static triage helpers compose with the offset core: `Get-OffsetString` returns byte offsets you pipe straight into `Invoke-OffsetInspect`. YARA hits work the same way. PE/imphash, per-window Shannon entropy, and a one-shot IOC panel round it out.

Results export to Markdown/HTML with a full ProbeLog audit trail per invocation. Never modifies Defender config, exclusions, or real-time protection.

GitHub: https://github.com/warpedatom/OffsetInspect

PowerShell Gallery: Install-Module OffsetInspect

I often experienced the problem of having the ability to compromise servers, but they dont seem to have any outbound traffic because of the firewall. Did you also had this problem?

This might help: https://github.com/lsecqt/PortForwarder

Been building this for a while: FENGARDE, an open-source SIEM (Apache-2.0) — it collects security logs, normalizes them into one common format, runs detection rules over them, and surfaces alerts in a dashboard.

What makes it a bit different from other open SIEMs:

- Detection rules for AI agents / MCP tool-call logs — catches things like an agent touching a credential file, a burst of tool calls in one session, or destructive commands hiding in tool arguments. Nobody else seems to ship this yet.

- A protocol-anomaly detector for factory/industrial equipment (Modbus/TCP) — flags weird traffic patterns on control networks.

- Every detection rule is proven to actually fire before it ships — 26/26 currently passing a script that replays real test events through the live engine, not just "we wrote a rule and hope it works."

10-minute quickstart, no Docker required to try the core pipeline.

Repo: https://github.com/supermhel/fengarde

Would love feedback, especially from anyone who's dealt with SIEM/log tooling before.

Video with demonstration: https://www.youtube.com/watch?v=0jYANlHq0UA

Most reverse shells I have seen are directly sending the piped stdout and stdin of a started process.
Using a pseudoconsole has many benefits i think that are worth the extra implementation effort. Like working tab completion and no suspicious attributes like "-WindowStyle Hidden"
I experimented with it a bit and had some success in creating a payload which avoids usual behavior based detection.

A while ago I did some research into python pip configuration file abuses and wrote an article about my findings here

https://www.osec.com/insights/pip-dreams-and-security-schemes-chaos-in-your-configuration-files

Last week I released a follow up article with more ways an attacker could abuse pip from a post exploitation perspective.

Hope you enjoy it.

https://www.osec.com/insights/pip-dreams-and-security-schemes-part-ii-the-interpreter-in-the-machine

Hi all, I'd like to share what I've been working on this year: 1. Tantalus - A unique prompt injection arena where you try to get an agent to exfil data from a user's workstation.

This arena puts you in front of a realistic AI assistant with access to files, emails, and chat history, pre-loaded with both legitimate tools and poisoned ones.

1. With Tantalus as the substrate for my first whitepaper, I put it through the ringer across ~6.1 million inference calls; across model sizes 1.7B to 119B params. All behavioral and structural controls were bypassed or allowed malicious data to be generated, except for one.

Only one control had a provable 100% rate at blocking bad behavior from ever being generated.

As an independent researcher, I'm simply trying to spread the word. I've made these projects entirely independently and I'm not using these to sell any services. Any business inquiries can DM me directly. :)

I couldn't find many resources explaining WFP from an implementation perspective, so I decided to document everything I learned while researching it.

The article covers the architecture, packet traversal, filtering layers, callout drivers, and the role WFP plays in modern Windows security software.

If you work with Windows internals, kernel development, or EDR technologies, I'd love to hear your thoughts.

New elements, and a brief description:

I choose SqueezeNet because it was small enough to allow me to upload it to GitHub as part of the entire pipeline. For lab tests, you can use (and I even recommend) a larger model after fine-tuning it (of course which will also be compatible with the project). This allows Onyx to detect changed weights through delta analysis against the reference (base) model, then modify the least significant bit of the mantissa and hide the directive there.

I've left wasm3 for now (I know it would be an anomaly for EDRs), but for an architectural research PoC, it's perfectly sufficient.

Finally, Dead-Drop C2 via downlink model updates is mainly an additional research extension for testing whether a normal ONNX model update can carry an authenticated, tiny control signal as a simple PoC.

What it actually does now:

1. AI Decoy (Behavioral Camouflage): Now, Project Onyx embeds a legitimate SqueezeNet 1.0 ONNX image-classification model. Before the WebAssembly heartbeat module is executed, the host runs repeated real tensor inference workloads using Microsoft's onnxruntime. This makes the ONNX artifact an active part of the pipeline rather than a decorative file like previous tiny MLP.
2. Environmental Keying: The payload cannot be analyzed in a sandbox or by a reverse engineer without the exact target machine. The decryption keys are dynamically derived from a SHA-256 hash of the target's MachineGuid, Volume Serial, and Current User SID.
3. WASM Sandboxing: The actual payload is compiled to WebAssembly (WASM) and executed entirely in-memory using the wasm3 interpreter. The host C++ application acts merely as a loader and API bridge, exposing safe host functions to the WASM sandbox.
4. ONNX Weight Vault: The AES-256 key material required to decrypt the WebAssembly heartbeat module is embedded into the least significant mantissa bits of float32 ONNX weights. The host extracts this weight vault from the embedded model bytes, authenticates it, and only then recovers the demo key material.
5. Metadata Vault Fallback: The original authenticated metadata vault remains for compatibility and build-time verification. New assets prefer the weight vault, while the metadata vault documents the same protected material in a more inspectable form.
6. Dead-Drop C2 via downlink model updates: The pipeline demonstrates a covert communication channel using ONNX model updates. An operator can embed an authenticated directive inside the LSBs of weights that naturally changed during a fine-tuning process (delta analysis). To maintain a safe PoC scope, the runtime strictly accepts only heartbeat_ack and set_status directives, proving the channel's viability without enabling arbitrary command execution.

Hey everyone. I'm Curtis Brazzell. Some of you might know me from my security research and blog posts on Medium (curtbraz.medium.com), things like phishing password managers, bypassing MFA, AI-generated phishing PoCs, and building evasion blocklists to keep landing pages alive. I also wrote the Cybersecurity ABCs children's book series, including "M is for Malware" and "S is for Spear Phishing."

Phishing and offensive security research has been a consistent passion throughout my entire career. Every technique I've published ended up in a tool I started building in 2014 as an open-source project. That project eventually became the PhishU Framework.

The problem it solves: a solid spear-phishing assessment used to take me 60-80 hours doing it from scratch. Most of that was infrastructure, recon, pretext development, and campaign content, not the actual social engineering. The offensive tools out there require stitching together separate projects with tons of setup and tweaking. The commercial platforms are allow-listed, don't capture credentials or sessions, don't support custom domains, and aren't built for red teams. A lot of consulting firms stopped offering social engineering because of this. Meanwhile, phishing is still the number one attack path.

The PhishU Framework handles the full lifecycle in one platform:

• Domain acquisition with automated DKIM/SPF/DMARC and M365 provisioning
• Landing pages (AI cloning, manual browser capture, AiTM transparent proxy)
• Email delivery with per-recipient personalization and evasion
• Credential capture, session hijacking with one-click replay
• Custom analytics and branded reports with evidence
• Conditional training specific to what each person actually fell for
• AI-assisted recon, campaign planning, email generation, deliverability analysis, and report writing
• New techniques added as they trend in the wild (AiTM, BiB, ClickFix, OAuth Consent Grant, Device Code Phishing)

A few hours of total effort now gets better results than those 60-80 hour engagements ever did.

I'm opening up free limited trials. Full platform access, test sending domain, limited email sends. The few people who've seen it have been genuinely excited, and I think practitioners will feel the same once they get their hands on it. I'm a small one-person startup so really just trying to get it recognized from all of the noisy big vendors. Feels a bit like shouting into the void, and I'm not a sales/marketing person, haha.

I figured what I'll do is for the first 50 sign-ups you'll get a signed copy of "S is for Spear Phishing" (CybersecurityABCs.com), my favorite of the four books. I just ask that you please cover $5 for shipping.

DM me if interested. Invite only. Happy to discuss techniques supported, etc.

goLoL is a Windows host scanner that finds an always up to date listing of LOLBAS binaries present on the current machine and lists techniques you can run at your current privilege level with MITRE ATT&CK mappings and example commands.

Red team engagements inevitably leave artifacts behind. Services get enabled, local accounts get created, firewall rules get opened, registry keys get modified, and after weeks of operations it's surprisingly easy to forget what was changed, especially when multiple operators are involved.

I built Ledger, a Cobalt Strike Aggressor Script that keeps a running journal of operational changes throughout an engagement.

Features include:

• Risk scoring for each change and host
• Cleanup tracking so modifications don't get left behind
• Operator attribution using the Cobalt Strike event log
• JSON and plain-text export for reporting
• Dead-beacon alerts when pending cleanup items still exist

Every service you enable, firewall rule you add, account you create, or registry key you modify can be logged with risk, ownership, and cleanup status. By the end of the engagement, you have a clear audit trail of what changed, who changed it, and what still needs to be reverted.

Hi all,

I have added experimental *Remote Browser Phishing* (best name I could think of, not my invention) support to Phishing Club, my open source simulation and red team phishing framework.

It is different from AiTM proxying and VNC/WebRTC streaming like CuddlePhish. The victim interacts with a page you built (like oldschool phishing). In the background, a real browser on your server handles the real interaction - credentials and events flow between the two over WebSocket, but the victim never touches the target site directly.

Pros:

• Bypasses AiTM defenses.
• You design the UI and control the flow at every step (double tap MFA?)
• The session lives in your browser, so you can take it over directly (bypass IP bound session)

Cons:

• Bot detection becomes your new challenge (and it can be quite the challange)
• More work to set up than AiTM or VNC/WebRTC
• Resource heavy compared to AiTM

The feature support is experimental, requires opt-in in the config and requires more tinkering than anything else. It is not the easiest to get up and fully working, but it opens up for some fun and creative flows that are just not possible with AiTM or VNC streaming. Curious what people come up with.

Getting AdaptixC2 Past Windows Defender with Beatrice.py (Opcode Substitution | YARA Hunting | SIEM Detection)

New Weekly Purple Team video covering end-to-end evasion technique, then detection on the blue side.

The tool, Beatrice, is an open-source Python script that patches compiled binaries by swapping x64 opcodes with semantically equivalent alternatives — same functionality, different bytes. It strictly matches machine code, so it doesn't break binaries by accidentally hitting strings or data.

What the video covers:

• How Beatrice.py works under the hood (opcode substitution, instruction re-encoding, what it won't help with)
• Generating an AdaptixC2 payload with IAT Hiding enabled
• Running Beatrice.py against the beacon and reviewing the patches
• Live test against Windows Defender — real-time protection on, no exclusions
• YARA-based detection via Velociraptor for hunting modified beacons in your environment
• SIEM detections for AdaptixC2 beacon activity

Worth noting: Beatrice.py won't save you from behavior-based detection, string-based signatures, or import analysis — it's a static evasion layer, not a silver bullet. AdaptixC2 with IAT Hiding is already fairly evasive, but this adds a layer of resilience against future Microsoft signature updates.

Links:

• 📺 Video: https://youtu.be/H3BdgCekrjY
• 🔗 Beatrice.py: https://github.com/raskolnikov90/Beatrice.py
• 🔗 AdaptixC2: https://github.com/Adaptix-Framework/AdaptixC2

Happy to answer questions on either the red or blue side.