Weekly Purple Team: DLL Sideloading with Adaptix Beacon (python315.dll)

This week's episode covers DLL sideloading using an Adaptix Beacon payload hidden inside python315.dll, masquerading malicious code as a legitimate, signed process to establish C2 while evading process-based detection.

On the blue team side, we break down detection — process and module load telemetry, DLL path/signature anomalies, unusual parent-child process relationships, and deployable detection rules to catch sideloading before the beacon establishes persistence.

Covers T1574.002, T1055, and T1071 with the full red vs. blue format.

Video: https://youtu.be/szXFXvaXiEs

Happy to discuss the sideloading mechanics or the detection side in the comments.

I released TornadoC2 today

Repo: https://github.com/kamalx06/TornadoC2

Status: between beta and 1.0.0. Core is stable and usable end to end, but I'm still working through some transport edge cases, console polish, native commands, and doc gaps. Will tag 1.0.0 when those are closed.

I'm posting because I made specific choices about how a C2 should work, and I'd like criticism from people who've actually run C2 in the field. If any of those choices are wrong, I'd rather hear it now.

Three things worth reading about

1. Fully Malleable profiles that shape the whole response, not just its envelope. Where most tools shape the wrapper around a fixed payload model, TornadoC2's profile system controls what the response actually looks like, and it does so with one JSON file per profile. A profile declares the three request paths (check-in, tasks, results), the User-Agent with a separate Linux override, extra request headers and per-role request headers, the session cookie name, additional response headers a real server would send, and per-role HTTP status codes for check-in, tasks, results, and error paths. The shaping block then controls the structure of each body independently: an arbitrary JSON template with {{payload}}, {{ts}}, and {{nonce}} placeholders; an extract path that supports array indexing (data.items[0].envelope.b64); a selectable encoding (base64, base64url, hex, or NetBIOS-style lowercase letters); and a selectable placement (body, a named response header, or a Set-Cookie value). Three shapes per profile, each one independent — a check-in can return 201 with the payload in an X-Request-ID header, a task poll can nest a base64url blob three levels deep in a JSON envelope, and a result upload can return 204 with the payload in a Set-Cookie, all on one profile, each matching what a different endpoint of the mimicked service actually does. DNS and DoH profiles carry a separate dns_label block that renames the three verb characters and changes the per-chunk payload length, and a stager.path block can move the payload fetch to whatever URL the mimicked service actually uses. The profile applies to every transport that carries HTTP-shaped bodies — HTTP, QUIC, WebSocket, WireGuard, and the three pivot transports — while DNS and DoH read the label block and ignore the HTTP-specific fields. Every profile is validated at two gates: the handler refuses a profile with colliding paths or malformed shaping at startup, and the agent build runs a round-trip probe through every template — it renders a payload, walks the extract path, verifies the payload comes back unchanged before any binary is emitted.

2. Concurrent multi-profile handling on one listener. Every other framework binds one profile per team server. TornadoC2 serves every profile under profiles/c2/ at once — same port, same certificate, same process. The request path is the profile selector. A Chrome-profile beacon and a Slack-profile beacon hit the same handler and each gets the response shape its own profile declared. No restart to rotate profiles, no second server on a second port, no "active profile" state.

3. A team server designed for teams, not a single-user console with collaboration bolted on. Every other C2 I've used treats the operator side as a coordination layer added after the agent works. TornadoC2 treats the team as the point:

• RBAC with a distinct guardian role. Admins manage everything that keeps the engagement running. The guardian alone decides when it ends. A request to /deadman/arm or /deadman/halt from an admin credential is refused with a 403 and audited.
• Hash-chained tamper-evident audit log. Every operator action writes to a chain where each entry carries the SHA-256 of the previous entry, anchored by an HMAC at the tail. Every mutating API response carries an X-Audit-Id header so a scripted caller can cross-reference the entry.
• Credential vault with beacon-side validation. The check runs on the target, not on the team server, because a bind attempt from the wrong network either fails silently or succeeds against a system the engagement isn't authorized to touch. Values are never written to the audit chain.
• Owner-restricted task cancel. An operator can cancel a task they queued before the beacon picks it up. System-queued tasks can only be cancelled by an admin. A refused cancellation is audited with outcome=denied.
• Session viewers. Every beacons poll carries the caller's attached beacon ID, and the table gains a VIEWERS column showing who else is on the same beacon.
• Content-addressed loot store with per-operator ownership, admin override with an audit marker, chunked upload up to 128 GiB per file.
• Team chat with file sharing, DM filtering, pinned topic, and forensic preservation — when the sanitizer modifies a message body, the audit chain carries the SHA-256 and base64 of the raw input.
• Per-operator webhooks to Slack, Discord, or Telegram with an SSRF guard that refuses loopback, private, link-local, and cloud-metadata destinations at registration time and again on every dispatch.
• Beacon aliases, tags, notes, session graph. Keyed on beacon ID so they survive a stale-and-reconnect cycle.
• Dead-man's switch with eleven secure-deletion modes, held by the guardian role only. It runs on a wall-clock deadline, not on an idle timer — operator activity does not reset it. When it fires it stops every listener, wipes the entire repository tree with the configured deletion mode (eight pattern modes like dod, nist, gutmann, schneier, plus three structural modes: trim for TRIM/discard on SSDs, scrub for prealloc + O_DIRECT + TRIM, and crypto for LUKS header destruction), and can optionally power off or reboot the host. The remote API requires confirm: true for crypto mode on every request, because destroying the LUKS header makes every byte on that volume unrecoverable — including data outside the TornadoC2 tree.
• Two frontends over one client library. Terminal REPL as the reference implementation, PySide6/Qt GUI as a presentation layer over the same Client methods.

Transports

Ten native transports, split across three roles.

Direct transports. HTTPS, QUIC/HTTP-3, WebSocket, DNS TXT, DNS-over-HTTPS, ICMP echo, and WireGuard. HTTP, DNS, and DoH can be combined in one binary with automatic failover after N transport-level failures — a network that permits HTTP/3 but blocks TCP/443, or permits DoH but filters UDP/53, is reachable without rebuilding the agent for a different carriage. QUIC, WebSocket, and WireGuard are single-transport in this version. Each of the ten carries the same C2 protocol over a different carriage.

Pivot transports. SMB named-pipe pivot, TCP bind pivot, and TCP reverse pivot. All three solve the same problem: a child beacon that cannot reach the team server directly, carried by a parent that can. Every frame between the parent and the child is encrypted end to end with an AEAD session keyed off a fresh ECDH exchange — the parent forwards the child's C2 envelope verbatim and never inspects or modifies it. The child's own wire encryption to the team server is preserved independently of the pivot session. All three pivot transports share the same wire format, the same handshake, and the same per-direction keys; the only difference is which side dials.

Cryptography

• Task, result, and identity signing. Every task is signed with the handler's ECDSA P-256 key over canonical JSON ({id, verb, args, timeout}, sorted keys, no whitespace) and refused by the agent if the signature fails. Every result is signed with the agent's own build-time ECDSA key and pinned at first check-in. Every check-in carries a separate signature over machine_id|hostname|username|os|identity_ts, verified before the session is pinned — a valid signature presenting a different public key for a known fingerprint is refused and fires beacon-identity-mismatch.
• Wire encryption. Every request and response body is an AES-256-GCM envelope keyed off a P-256 ECDH exchange. The server's ECDH public key is embedded at build time; the agent's ephemeral keypair is fresh per check-in. The task signature covers the plaintext, not the envelope, so a MITM who terminates TLS and unwraps the wire encryption still cannot forge a task.
• Pivot session. One ECDSA P-256 pivot keypair per engagement. Parent proves possession of the private half, child proves possession of its own identity key, both handshake payloads carry a role-specific domain separator. Fresh ECDH per handshake, HKDF-SHA256 to per-direction AES-256-GCM keys, parent's ack bound to the child's ephemeral so a captured ack can't replay against a fresh hello. Every frame after that is length-prefixed AEAD with a monotonic per-direction sequence number in the additional data — a gap or repeat is a fatal protocol error and the session is torn down.

On forward secrecy: the pivot tunnel doesn't have it. The parent reuses the same long-term pivot key in every handshake, so if that key is stolen later, an attacker who recorded a past parent-to-child session can decrypt it. Because the key is reused, this applies to every recorded session, not just one. Having both sides use a fresh throwaway key per handshake would fix it — it's on the list.

The child's encryption to the team server is a separate layer and doesn't have this issue. It's keyed off the server's ECDH key, which the parent never holds, so a parent compromise gives the attacker the tunnel, not the child's C2 content. On the other side, the child's contribution to the pivot handshake is a throwaway key that's discarded after the exchange, so a child compromise doesn't break past pivot sessions either. Treat the pivot key as an engagement-lifetime secret and rotate it between engagements.

Rest of the stack

• Go implant for Linux + Windows, compile-time configured
• ~70 native verbs in-process, in-memory PE/ELF/.NET execution, COFF/BOF loader

Evasion features

Four compile-time OPSEC profiles (default, stealth, opsec, paranoid), bundling progressively more aggressive combinations of:

Anti-analysis heuristics. Anti-VM checks that detect common hypervisor artefacts (VMware, VirtualBox, Hyper-V, QEMU, Xen — registry keys, device names, MAC OUI prefixes, firmware strings), anti-sandbox checks that look for sandbox-typical process names, file paths, and hooking artefacts (Cuckoo, Joe Sandbox, ANY.RUN, CAPE, and the tools that ship with them), anti-debug checks against both userland and kernel-level debuggers (IsDebuggerPresent, CheckRemoteDebuggerPresent, NtQueryInformationProcess for the DebugPort/DebugObjectHandle/DebugFlags classes, PEB BeingDebugged, hardware breakpoint register inspection, and timing checks against rdtsc and QueryPerformanceCounter drift).

Runtime patching. AMSI bypass via in-process AmsiScanBuffer patch, ETW patching to blind the EtwEventWrite path that feeds script-block and .NET telemetry, and indirect syscalls on Windows where the agent reads the system service number out of the ntdll stub without executing it, then jumps directly to the syscall instruction inside ntdll.

Sleep masking. Four modes: rc4 and aes-ctr on Linux and Windows via a native sleep stub that encrypts the executable segment, cronos (fiber-based, Windows amd64 only) and hwbp (hardware-breakpoint + VEH handler, Windows amd64 only), both of which encrypt the same segment without running any Go code inside the encrypt/decrypt window. Every mode generates a fresh key on every sleep cycle, so two consecutive sleeps never produce the same ciphertext.

Binary shaping. String obfuscation, garble for control-flow obfuscation, and UPX packing in the paranoid profile.

Execution discipline. Shell history suppression for any child shell, jittered first check-in (2–17 s after launch) and jittered subsequent check-ins, working-hours window that suppresses outbound traffic outside a configured schedule.

Injection backends. Two for migrate <pid> — CreateRemoteThread on Windows and ptrace on Linux as the default, remote APC injection via NtQueueApcThread as the alternative on Windows.

What I'm not claiming

I'm not claiming full EDR evasion. I'm not claiming this defeats modern EDR, AMSI beyond the in-process patch, ScriptBlock logging, memory forensics, or behavioral detection. What I am doing is adding evasion techniques as aggressively as I can and continuing to add new methods as I find them — this is an active area of the project, not a finished one. If you know a technique that works against current EDR and would fit the framework, I want to hear about it.

The README has a full "what this tool does not claim" section. Short version on the specific limits: the hwbp sleep mask writes DR0/DR7 which is itself observable, APC injection removes CreateRemoteThread but NtQueueApcThread is instrumented by every major EDR, and lsassdump is the highest-signal verb by construction. The sleep mask encrypts the executable segment during the wait but does not encrypt the goroutine stack, so the call chain and locals remain readable between check-ins.

The limits section isn't hedging. It's what a defender looks for and what the tool doesn't do about it.

On the timeline and the AI assistance

I built this in 2–3 weeks with AI assistance. I'm saying that up front because it's relevant to how you read the post.

What that means in practice: I designed the protocol, the threat model, the role model, the profile system, the transport abstraction, and the pivot handshake. I made the decisions about what runs in-process vs. as a child, what's compile-time vs. runtime, what the audit chain records and what it doesn't, and why the guardian role is separate from admin. I understand every part of the codebase and can answer questions about why any specific piece works the way it does.

The AI assistance was for the mechanical volume — the ~70 native verb implementations, the transport boilerplate, the docs. The design is mine. The choices that determine whether the framework is useful or not are mine.

I'm noting this because a lot of people are curious about what you can build quickly with modern tooling when you actually know what you're doing, and a lot of people are (rightfully) skeptical of AI-generated security tooling. I'd rather be in the first conversation than the second.

Criticism on the design is what I'm after. If the abstraction is wrong, I'd rather hear it now than after 1.0.0.

Hey everyone,

I have been building OpenOsoosi (OshoosiClaw), an open-source (Apache-2.0 OR MIT), 25-crate decentralized Endpoint Detection and Response (EDR) agent and AI agent containment mesh written in pure Rust.

Most endpoint detection architectures follow a traditional hub-and-spoke model: agents collect telemetry on endpoints and stream it upstream to a centralized SIEM, data lake, or vendor SaaS. While centralized telemetry simplifies aggregation, it introduces well-known structural tradeoffs - single points of failure, ingestion bottlenecks, CGNAT/offline blind spots, and vulnerability to egress severance. Furthermore, with developers and enterprises increasingly running autonomous AI coding and OS agents (MCP servers, local LLMs, CLI agents) with ambient user privileges, traditional signature-based EDRs struggle to distinguish normal developer workflows from prompt-injected agent breakouts.

I wanted to explore an alternative design: what would host defense, threat hunting, and AI agent containment look like if endpoints formed a self-healing peer-to-peer security mesh capable of reaching distributed consensus locally without relying on a central cloud controller?

Repository: https://github.com/oyesanyf/OshoosiClaw

Latest Release (Signed Windows MSI & SLSA v0.2 Provenance): https://github.com/oyesanyf/OshoosiClaw/releases/tag/v1.2.0

Core Architecture & Design Choices

- Pure Rust for Low-Level Host Interception & Forensics (25 Crates):

Built in Rust for memory safety and predictable latency across Windows Kernel Minifilter/OB/WFP drivers (osoosi-driver-win), Linux eBPF tracepoints (osoosi-ebpf), and a native Windows SCM Service (OsoosiEDR). Includes an embedded, 100-table in-process relational SQL forensic engine (siquery, modeled on osquery / siquery-rs) backed by rusqlite, sysinfo, and native Win32 APIs (GetExtendedTcpTable, Toolhelp32, WMI) with zero external C++ binary dependencies.

- Hardware TPM 2.0 Attestation & Hybrid P2P Mesh (libp2p + Nostr WAN):

To prevent rogue or compromised endpoints from poisoning the mesh, nodes verify local platform state using hardware Trusted Platform Module (TPM 2.0) attestation (osoosi-tpm) and Ed25519 identity keys before participating in peer exchanges. Combines libp2p GossipSub/Kademlia/mDNS over LAN with a censorship-resistant Nostr WebSocket relay bridge for endpoints behind strict enterprise NATs or cellular hotspots.

- Byzantine Fault Tolerant (BFT) 14-Voter Consensus & Distributional RL:

Because individual detectors can misfire or be evaded, candidate detections are evaluated by 14 independent ThreatVoter engines spanning distinct evidence classes (Static YARA/Entropy, Behavioral, LSASS CredentialGuard-Memory, Network C2/JA3/Beaconing, Deception, and Temporal Lineage). Voter weights and containment thresholds are calibrated in a closed loop using Distributional Reinforcement Learning (a native Rust port of Google Dopamine's Quantile Regression DQN / QR-DQN with CVaR risk-averse action selection) persisted in SQLite WAL.

- Non-Disruptive Multi-Ring AI Agent Containment (OWASP Agentic Top 10 ASI01-ASI10):

Instead of hardcoding process names (python.exe, node.exe), a Bayesian DynamicAgentClassifier identifies autonomous AI agents at runtime via protocol provenance (LLM inference endpoints, MCP JSON-RPC framing, .gguf/.safetensors memory maps, gen_ai.* OTel spans, and 128-dim EmbeddingGemma-2 Matryoshka embeddings) while giving interactive human terminals (ConPTY) 100% pass-through.

Enforces a 4-ring containment boundary (recently scored 8.6 / 10.0 Hardened on SafetyCard):

1. Constant-time HMAC-SHA256 generation-epoch identities ((arm_id, epoch, role)) and lateral sink isolation.

2. Dogwood Temporal Authorization Engine extending Cedar policies with past-only Metric First-Order Temporal Logic (once[0, 10m], historically, since) over agent event histories.

3. 3-phase Agentjacking defense that strips GhostJacking invisible Unicode (U+E0000-U+E007F), defangs EchoLeak (CVE-2025-32711) Markdown image exfiltration, and blocks Phase 3 Chained Tool Abuse on tainted sessions.

4. Mathematical Ipv4Addr/Ipv6Addr SSRF guards (169.254.0.0/16, RFC1918, CGNAT, IPv4-mapped IPv6), elastic workspace Path::join traversal guards, Windows AppContainer + Job Object sandboxing (CREATE_SUSPENDED + IsProcessInJob), and surgical autotomy kill switches.

Current Engineering Challenges & Roadblocks

This is an active open-source implementation, and there are several architectural trade-offs I am currently navigating:

1. TPM Attestation vs. High-Frequency Gossip Throughput: Balancing the latency of hardware TPM quote verification against real-time peer alert propagation during high-volume telemetry bursts.

2. Mesh Partitioning & Byzantine Quorum: Tuning BFT quorum thresholds when a subset of endpoints transitions between low-latency LAN (libp2p TCP/QUIC) and higher-latency WAN relays under node churn.

3. Bayesian Agent Discovery False-Negative Boundaries: Keeping the zero-hardcode classifier 100% non-disruptive to normal developer compiler/CLI toolchains while catching custom obfuscated agent harnesses before their first tool call.

Where I Would Love Feedback

I am sharing this here to get raw technical critiques and architectural feedback from systems programmers and security engineers:

- Distributed Consensus & Gossip: For distributed systems folks, what failure modes or BFT state-sync bottlenecks should I anticipate as peer count scales past small enterprise clusters?

- TPM 2.0 & Remote Attestation: If you have deployed TPM remote attestation across heterogeneous Windows/Linux fleets, what PCR brittle-update edge cases or key-bootstrapping friction should I watch out for?

- Kernel & Agentic Interception: Are there specific Windows ETW/Minifilter callbacks, Linux eBPF LSM hooks, or MCP transport interceptors you think would make local containment significantly stronger?

Feel free to check out the repo, inspect the crates, tear into the architecture (docs/ARCHITECTURE.md), or open issues and PRs. I will be hanging out in the comments to answer questions and discuss the technical decisions!

i wanted to red-team myself on my project and id like to know how to reverse engineer so i can see what can be done to defend against it.

TLDR; i thought my project would have been harder to chew up. it was surprisingly low-effort.

my app is aiming to be fully client-side. An implementation in javascript seems like it would relatively easy for an AI to swallow. my latest project is in rust, which would make it harder for a person, but AI can now digest binaries.

i created a fairly unique p2p messaging app. a rust-based frontend with a rit-server backend, which can be used to establish a p2p connection. while this version remains close-source, i aimed to create comprehensive technical documentation (formal-verification and security audits too (all ai-slop-maxxing at scale under my guidance)).

1. https://glitr.io
2. https://app.glitr.io

a core detail to my project is the focus on client-side cryptography and storage. i think my older iteration as a javascript webapp would be relatively easy for AI, so i thought id put a spin-on-things by having a rust wasm frontend. In practice, i dont think AI broke a sweat.

i know nothing about decompiling, but i think the TUI would be the easiest for it to decompile... and given its largly one codebase for all the platforms, it can be used to trace and see what is going on in the builds for the other platforms.

it might be that all close source is obselete. i tried asking here, and the responses there are polar opposites, so i decided to get some first-hand experience.

i used cursor's "auto" agent (in contrast to the frontier models available). i used https://github.com/morluto/rea and tried to make it easier by proving it with a few binaries of my project (tui, apk, web, desktop) and pointed it to the documentation as a website.

after a few prompts, it seems to have done a decent job decompiling the project here:

https://github.com/positive-intentions/glitr-decompiled (note: this is basically AI-slop)

like with many projects, i see AI lacks taste in architecture. it consolidates a lot of complexity into one repo, when in my project it's split into multiple repos. it also seems to lack a bunch of bells-and-whistles i added for my own benefit like formal-verification and rigorous unit-tests. having done it myself before, i dont think that it's a large gap to close for somone who knows what they're doing.

i think the overhead to keep up with new changes may become trivial if you can automate the process of ingesting new binaries. i kinda offer the base in the repo above (maybe it saves you a few tokens?), but its for my own research and i dont plan to maintain it given it undermines the actual project.

in general, im impressed considering how fast and low effort this was. it seems this may push forward my timeline for when i open source my project, i wasnt expecting client-side close-source being so easy to undemine. while the project can be decompiled, in a project like this, its important to consider the countless nuances there are in software development and cybersecurity. the code is only a fraction of the project.

i think people should try this in their own code. while the decompiled output is not the same codebase, it seems trivial for me to take your app and rebuild a protocol-compatible version with some new button, feature... or auto-installing malware.

(note: feel free to try decompile this yourself or offer tips on how i can improve. id be keen to see what can be done. feel free to reach out for clarity about how it works if the docs are not clear)

Wrote up a technique I've been using during engagements - building a custom C# PowerShell runspace that neutralizes AMSI and ETW using pure .NET reflection, no native API calls like VirtualProtect or AmsiScanBuffer patching.

The approach flips amsiInitFailed and isEtwEnabled via reflection from a compiled binary, then spawns a runspace in Full Language Mode - sidestepping CLM enforcement since the policy is tied to the PowerShell host, not the engine.

The post also covers defensive considerations: what to monitor for on the blue side (non-standard processes loading System.Management.Automation.dll, telemetry gaps, CLR-level ETW events).

Feedback welcome, especially from anyone who's seen EDR detections specifically targeting the reflection-based approach vs. the classic memory patching route.

What is it?

A GTK4 desktop GUI for Linux that puts the wireless assessment workflow in one place. 57 modules: Wifi, Bluetooth, RF, router side, and network MITM. Every module is a standalone shell script; the GUI is a view over them, so you can call any of them directly and script them.

The reason I built it is that most wireless tooling is deep in one lane. Aircrack-ng is Wifi, Bettercap is network MITM, Bluetooth tooling is Bluetooth. So an assessment means five tools and five config files and no shared view of anything.

Some of what's in it

Wifi: Recon, deauth, handshake and PMKID capture, WPS including Pixie Dust, WPA3 and Dragonblood, WEP, Enterprise 802.1x, PMF bypass, KRACK, FragAttacks, Evil Twin, Karma, beacon and auth floods, Wifi Direct, client isolation testing, SSID overflow.

MITM and credentials: Responder, MITM6, ntlmrelayx, router advertisement poisoning, ARP MITM, rogue DHCP, USB Ethernet MITM.

Router side: TR-064, HNAP, UPnP, SNMP, DNS rebinding, web UI, recovery TFTP and UART.

Plus Bluetooth, sub-GHz, LoRa, Zigbee, NFC, drone remote ID, and the analysis side: capture analysis, fingerprinting, geolocation, wordlists, live traffic, passive IDs.

The hardware

For Wi-Fi, you need an adapter that can inject. Atheros AR9271 is what I used, or TP-Link WN722N v1 or an Alfa AWUS036NHA.

Intel adapters will not work for anything involving injection. The app detects iwlwifi and tells you so instead of failing quietly, but it will refuse. Monitor mode alone isn't enough.

What hasn't been tested yet

Bluetooth, all of it (except Bluetooth recon). I don't have an adapter, so none of those eight modules has run against real hardware. The code is written and reviewed, but that's not the same claim as working.

Same for sub-GHz, LoRa, Zigbee, NFC and drone remote ID. No SDR, no radio hardware here.

Thread does offline pcap analysis fine; the live scanning is untested, no 802.15.4 radio.

Jamming needs a modified driver and firmware that isn't shipped. It'll tell you it can't find the driver. That's correct behaviour, not a bug.

What I actually want from testers

Run it, and tell me:

Does it start on your distro? GTK4 version, Wayland vs X11, missing dependencies.

Does it get your adapter right? Wrong hardware detection is worse than none.

Modules that report OK but did nothing? This is the one I care about most. A module that says success while the target is untouched is worse than one that fails loudly, and it's the type of bug I'm hunting.

Anything that crashed or wedged your adapter.

And the most important: there's `tools/diag.sh --collect` which produces a report with distro, kernel, GTK version, adapter and driver, injection capability, dependencies, and per-module selftest results. It replaces MACs and SSIDs with placeholders and strips secrets before writing anything, and it never touches the loot folder. So you can paste it without leaking your neighbours' network names, which I'm not going to ask you to do.

I wanted to share a tool I've been working on. When performing manual source code reviews, offline security audits, or initial reconnaissance against frontend surfaces, I often needed a quick way to recursively download an entire web application along with all its local assets (scripts, stylesheets, media, etc.) into a clean layout for local analysis or static tooling.

While there are heavier scrapers out there, I wanted something straightforward that integrates smoothly into a workflow and makes local examination seamless.

Hope you can try out 🙏

I built this because nowadays most web apps are single page applications and there are no good tools out there that crawl and analyze javascript bundles. Most tools do a simple regex on js files which always yield false positives, miss routes, and don't even recover things like the HTTP method, request body schema, parameters, headers, etc.

jshound takes a URL, crawls the whole frontend bundle, and traces the http requests in the code. On most SPAs (e.g. claude.ai, x.com, lovable.dev) it gets you what you'd find crawling or clicking through the app, plus things you'd never encounter (e.g. admin dashboards, KYC gated features). It's very passive: it only fetches public static files. Output can be imported into Burp or Caido.

Bundlers it handles: webpack 5, webpack 4, Rspack, Turbopack, Vite / Rollup, esbuild, Parcel, Metro (React Native), webpack Module Federation

Limitations (why I'm open sourcing it so people can improve if they want lol):

- Values only known at runtime (config fetched from an API, etc.) stay unresolved

- Header and WebSocket message recovery are hit or miss

- WAFs can be a pain

- Probably many things I'm unaware of

It's still very solid and I'd appreciate issue reports and pull requests.

https://github.com/AmbitSecurity/jshound

I've been working on a more advanced generation of captive portals — all single .html files under 20 KB — that go well beyond the basic login screen. These let the target navigate a fully functional menu with working tabs, interactive sheets, and two additional sign-in paths beyond the standard email/password flow (victim can pick between logging in to Google or Apple as other options), both built with CSS-only overlays so they work within the esp32-c5’s constraints. Took a fair amount of iteration to get everything behaving correctly on the Marauder mini V3 and V8, but they should also be solid on any microcontroller running the marauder firmware or any firmware capable of launching captive portals.

My repo now has 400+ portals (not all are built around an advanced framework), each branded and built specifically for a real corporation — coffee shops, ISPs, banks, airlines, and more.

Please only deploy on networks you have explicit written permission to test. The intent behind this repo is education and authorized security assessments. It's a useful tool for security awareness presentations and red team engagements. It is not intended for unauthorized use and I take no responsibility for misuse.

PLEASE LEAVE A STAR ON THE REPO IF YOU ENJOY THE PROJECT AND WANT ME TO CREATE MORE🥹⭐️

If you run into any issues, feel free to DM me here on Reddit.

Hey everyone!

I'm Daniel, the developer behind NetCatTest, and I recently released CatSuite, a free Android application designed for web application security testing, offensive security research, and authorized penetration testing.

The idea was simple: what if you could carry a practical web security testing toolkit in your pocket, without needing a laptop for every task?

So I built CatSuite.

Some of its features include:

• HTTP/HTTPS Interception: Capture, inspect, and modify requests and responses.
• HTTP Repeater: Modify and resend requests to analyze application behavior.
• Intruder: Test payloads, parameters, and wordlists, including custom dictionaries.
• Endpoint Discovery: Explore directories, paths, and endpoints.
• Network Proxy: Inspect HTTP/HTTPS traffic during authorized testing.
• JWT Decoder and SSL/TLS Analysis: Inspect authentication tokens and certificate configurations.
• Technical Browser: Built-in network monitoring, DOM inspection, cookies, storage, and User-Agent modification.
• Extensibility: JavaScript extensions and customizable security testing workflows.
• Evidence Export: Export testing data in HAR, JSON, TXT, and cURL formats.

CatSuite is not intended to replace Burp Suite or other desktop tools. My goal is to make practical security testing more accessible from an Android device, especially for quick assessments, research, and lab environments.

The app is free and available on Google Play, with no subscription required.

Website: https://netcattest.com/catsuite

Google Play: https://play.google.com/store/apps/details?id=br.com.netcattest.catsuite.app

I'd really appreciate feedback from people working in offensive security and red teaming.

What features would make a mobile security testing toolkit genuinely useful in your workflow?

Thanks!

Hi everyone!

Over the last couple of moths/years, I've been developing TraceHunt. Red team operations in TraceHunt can be compared with something like HackTheBox ProLabs with one major difference: operators learn to work under detection pressure instead of blindly solving labs using noisy tooling, lack of attacker usable infrastructure and C2, ...

The more signals you generate, the lower your score will be. Next to network and host-based monitoring, we have some other cool ways signals could be generated such as simulated users browsing websites, acting as devs (pulling and pushing code) in CI/CD focussed operations to force operators to think about the consequences their actions will generate.

We are currently open for early adopters and there's two FREE operations to give it a go!

👉 Create an account on https://app.tracehunt.com/public/register using registration code TRACEHUNT-REGISTRATION{Rc7V0JvwbDpdzwP01ZpbpkymakGT8QSR} and evade those signals!

If there is any feedback, hurdles or issues you might have, feel free to send me a DM and I'll take care of it 🔥

I have a redteam tool nuguard that simplifies the process of building customized scenarios specific to your application and supports a wide range of auth options. The automated judge does the impact analysis and provides remediation suggestions.

Open an issue in the GitHub repo if you want additional features.

Hey,

Tool that creates a hidden desktop and gives complete user mouse/keyboard interaction without rdp/vnc. Every call is made through inlineexecute using win api’s

Also contains a second plugin called notrdpuser which streams users explorer desktop gui and monitors all keystrokes.

Real life usage:
Enterprise sso logged in web page spying and browsing webpages with already logged in user consoles.

https://github.com/dagowda/notRDP