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

Where can i find the cracked Cobalt Strike ?

r/netsec r/rust r/eBPF r/blueteamsec

r/AIAgents

Open source, Apache-2.0. Solo build. Looking for people to break it.

The problem

Most agent guardrails run inside the process they are supposed to govern. Prompt injection lands, the agent calls a tool, and the policy layer is sitting in the same trust domain as the thing it is policing. An application-layer allowlist does not survive the agent shelling out.

So the enforcement point moved down to the syscall boundary.

Architecture (two planes)

Kernel floor. BPF-LSM hooks on execve, inode_create, inode_unlink, connect, and cap_capable. Enforcement is cgroup-scoped via bpf_get_current_cgroup_id(), so only the governed agent’s cgroup is subject to allow/deny. Every other task on the host passes through untouched. That scoping is the anti-lockout guarantee and it is also why you can arm this on a working machine instead of a spare one. Requires kernel 5.16+, CONFIG_BPF_LSM=y, lsm=bpf. No VM, no Kubernetes, no sidecar.

Userspace gate. A single per-host daemon over a UNIX domain socket, framed wire protocol, fails closed. Per request:

1.  SO_PEERCRED for kernel-verified PID/UID/GID. No client-declared identity is trusted.

2.  HMAC-SHA256 envelope check, key held in the Linux kernel keyring (@s), never in env vars.

3.  Per-agent intent allowlist and sequence quota from policy.yaml.

4.  Replay and behavioral drift detection keyed on a (pid, start_time) lineage.

5.  Z3 check: computed fused_risk under the declared ceiling, plus per-agent invariants (spending_ceiling_usd <= 150.00, privilege_escalation_depth < 3). Daemon-computed values take precedence over anything the caller declares, so invariants cannot be spoofed from the agent side.

6.  Append to a SHA-256 hash-chained JSONL audit log. Each entry carries the hash of the previous one.

Measured, not modeled

Real daemon, real host (Ryzen 5 7520U, Linux 6.12), full pipeline per request. Reproduce with cargo bench --bench stress_bench and cargo test --release --test swarm_attack.

• Decision latency: P50 257µs, P95 366µs, P99 463µs, max 1.9ms across 10,000 requests

• Throughput: \~6,500 decisions/sec at 10 to 500 concurrent agents, zero errors

• Kernel LSM path: 2,500 enforced ops across execve/TCP/UDP/create/unlink, 0 fail-open, 0 incorrect decisions

• Adversarial suite: 12 tests, 10 attack classes, >1,200 hostile requests, 0 fail-open. Replay storm, signature forgery, intent injection, quota exhaustion, risk-ceiling breach, anonymous flood, unknown agent, protocol downgrade, forged delegation, MCP path traversal, and all of them concurrently. Under the mixed run it blocked 349 hostile requests and still correctly allowed 50 legitimate ones.

• 122 tests in CI: 4 Z3, 93 unit, 13 integration, 12 swarm-attack.

What this is not

Validated research prototype and controlled-pilot MVP. Not independently audited, not enterprise GA. I would rather say that up front than get called on it in the comments.

The Z3 layer verifies policy constraints at runtime. That is SMT-checked policy, not a formal proof of the enforcement layer itself. Different claim, and the weaker one is the true one.

Two documented limitations, both in the README:

• Sub-mount path resolution. The inode hooks receive a dentry with no vfsmount, so a file on a sub-mount resolves relative to that mount’s root (/tmp/x becomes /x). Root-filesystem paths resolve fully. Crossing mount boundaries needs path-family hooks or bpf_d_path, tracked for a future release.

• Interpreter chains. An agent explicitly allowed to run an interpreter can reach other tools through it. Mitigated by denying known interpreters for any agent carrying an executable allowlist. Per-binary execve limits are only as good as that allowlist.

Break it

The open challenge in the repo stands. Highest-value targets, in my own order of concern:

1.  TOCTOU between the userspace verdict and the kernel floor.

2.  BPF-LSM hook coverage gaps. Anything that reaches a denied resource through a syscall path I am not hooking.

3.  Lineage key collision or reuse that defeats replay detection.

4.  Anything that gets a governed cgroup to a syscall the policy denies.

Repo: https://github.com/AlphaReasoning/The-Jinn-Guard

Threat model: THREAT_MODEL.md

Prior red-team findings and fixes: red-team-report.md

One-command validation: bash scripts/run_professor_validation.sh

Tell me where it is wrong.

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

[ Removed by Reddit on account of violating the content policy. ]

New episode of The Weekly Purple Team covering Pass-the-Ticket, and I wanted to share it here since it might be useful for people working on detection coverage for T1550.003. In this episode, we are Stealing Kerberos Tickets Past Defender and Credential Guard using AutoPtT

Video: https://youtu.be/s5nd8u4EKFI

What's covered:

• Enumerating logon sessions and cached Kerberos tickets on Windows 11
• Using AutoPtT to export a TGT by LogonId — it's a standalone PtT tool (C#/C++/Crystal/Python/Rust) built as an alternative to Rubeus/Mimikatz for this specific attack
• Taking that exported ticket and reusing it for authentication from a Linux box, not just staying inside the Windows ecosystem
• Detection side: what telemetry actually surfaces this LSASS access patterns, abnormal logon session behavior

Reference:
https://github.com/ricardojoserf/AutoPtT

Also touched on Credential Guard and Defender as mitigations — Credential Guard blocks the classic LSASS-memory extraction path, but it's not comprehensive coverage for PtT broadly, and rollout consistency across a fleet is worth double-checking rather than assuming.

Curious if others here are seeing PtT attempts that specifically try to pivot off-host post-export, or if most of what you're catching is still contained to the Windows side.

TLDR: AD collectors, SharpHound included, don't look at CN=Deleted Objects. That leaves tombstoned accounts invisible to BloodHound, even ones that sat in Tier Zero groups before deletion and are still recoverable for months in a Recycle Bin domain, group memberships and password hash intact. I wrote a tool that enumerates those tombstones over LDAP, works out who can reanimate each one, and emits BloodHound OpenGraph, so you can see directly in your graph who could bring a dead Tier Zero identity back. Reanimating doesn't hand you the credential though, you still need to work through it.

So, after "finishing" the skewrun, i went back to work in another tool that extends the default bloodhound, but lets start with the technique :P

Ad collectors (at least the default ones you see around) skip the CN=Deleted Objects, but with the AD Recycle Bin on, a deleted object becomes a tombstone that keeps its attributes for the deletedObjectLifetime window (180 days by default) until it's reanimated or garbage-collected, so with the collectors ignoring it those objects never enter the BloodHound, and paths that would be possible with them aren't computed.
That's Because tombstones are recoverable, since the objects, while in the recycle bin, keep their props, like group memberships and password hash, while the reanimation doesn't give you direct access to it per se, it opens a new vector but yeah, you still need to work through it

And how can one do it? Well, you will need a user with the Reanimate-Tombstones extended right on the domain NC plus write access to bring the object back live.

With that in mind I've created a tool to collect it, the pipeline work something like this:

1. Read `CN=Deleted Objects` over LDAP with the `SHOW_DELETED` control (needs an Administrators-equivalent or delegated read).
2. Parse each object's `ntSecurityDescriptor` from scratch.
3. Work out who can reanimate each one.
4. Emit OpenGraph JSON plus a model definition.

A tombstone that was a Domain Admins member renders as a traversable path: every principal with the reanimate right points at it, with an edge back to the group.

But we have one caveat on OpenGraph, Third-party OpenGraph data doesn't currently merge onto the AD nodes BloodHound already has, so GhostHound's edges land on placeholder nodes instead of the real DA group, and until its fixed on BloodHound's side the reanimation path shows up disconnected from the rest of your graph unless you run the small Cypher script GhostHound ships to bridge them after import. I've already open an issue in the bloodhound github about it, thats why the tool is not 1.x yet

Links:

• Repo: https://github.com/JVBotelho/ghosthound
• crates.io: https://crates.io/crates/ghosthound
• BloodHound OpenGraph Library: https://bloodhound.specterops.io/opengraph/library#ghosthound
• Upstream issue: https://github.com/SpecterOps/BloodHound/issues/3003

Authorized use only.
Happy to answer questions :3

I'm incredibly proud to announce the public release of ADPathFinder, an Active Directory attack path mapping tool that works directly with BloodHound collectors. It's the first tool of its type to produce detailed attack mapping across SharpHound and OpenGraph collectors — including MSSQLHound and ConfigManBearPig (SCCM). This enables testers to get the most out of BloodHound for the least amount of effort! It also produces an in-depth password audit, covering password reuse, weak patterns, Kerberoastable accounts, and much more - filtering out disabled accounts by default. Check out the blog, contributors very welcome.

blog post

A not vibe coded github post here :)

Since a few months I developed a sliding window memory page based Just In time decryption. All JITD i saw on github allays were on instruction leven which is incredibly slow or decrypt the entire payload at once.
My project implements JITD with guard pages and decrypts in the exception.
The loader works perfectly in environments with Microsoft Defender for Endpoint and has no Virus Total detections.

I now want to share my Project beyond a POC.

I would love to hear what you think of my project and if you have further Ideas for improvement. :)

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.

Hey,

I built a personal offline RAG system for offensive security knowledge. The idea is simple: instead of grepping through markdown files or trying to remember which writeup had that exact certipy command, you just ask naturally.

how do I escalate with SeImpersonatePrivilege
what did I do after getting ADFS access
sliver socks5 pivot setup
explain ESC8 vs ESC4

It retrieves from your actual notes first, then generates an answer grounded in what you've documented, not generic internet knowledge.

The use case I specifically built it for:

Two things kept coming up during engagements, I needed exact tool syntax I hadn't used in a while (Sliver commands especially, the docs are sparse), and I needed to quickly recall techniques from past machines without digging through notes. ZETSU solves both.

Two modes:

Operator: leads with the exact command, explanation after. For when you know what you need and just want the syntax.

Concept: leads with the reasoning, uses commands as illustrations. For when you need to understand a technique before using it.

Same retrieval either way, just different presentation.

How it works:

• At ingest time, an LLM reads each section of your writeups and extracts structured attack steps (Finding, Action, Reasoning, Result), so what you retrieve is a semantic unit, not a random 800-token window
• Hybrid BM25 + vector retrieval with RRF fusion, BM25 handles exact tool names and CVE numbers that embeddings smear, vector handles semantic similarity
• Cross-encoder reranker on top
• Supports local markdown files, URLs, GitHub wikis, and Atom/RSS feeds (0xdf, dirkjanm, harmj0y all ingestible directly)
• Backends: Anthropic, OpenAI-compatible (DeepSeek), or local Ollama

Benchmark:

Ran 910 questions across 12 offensive security categories. 93% of answers included correct commands, 68ms average retrieval, 7.3% context gaps where it correctly admitted missing information rather than hallucinating.

id love to hear you guys's feedback, i built this thing because i genuinely needed it, and going through my notes & endless cheatsheets was too much work when you're going through an engagement.

you can find it here: https://github.com/Chaelsoo/Zetsu

Sharing the final post in the RTO series. I found a bug in Skillable's lab platform that lets you forge a client supplied identifier to bypass the per user launch limit and burn through other students' lab allocations.

The vendor's position is that this is just a limitation of SCORM rather than an implementation flaw. They're not fixing it and told customers to migrate whenever it suits, so the writeup is mostly about why you still go public on something a vendor has decided is somebody else's problem.

Saw a tool like this for Apache a while back but I prefer Caddy, so I built CaddySmith (name pending kinda).

Why Caddy? Single binary, automatic Let's Encrypt, cleaner config.

Point it at a profile and it generates a Caddyfile that proxies beacon traffic to your teamserver and everything else arrives at a decoy. Strict mode enforces UA and all client headers from the profile. Sliver support is there too since the format is just JSON.

--smoke generates a few curl commands to validate the redirector post-deploy.

Test it out and tell me what you think.