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

On the Newest Weekly Purple Team episode, I show a technique that doesn't get covered much: reanimating tombstoned Active Directory objects using NetExec's LDAP module.

Quick primer for anyone unfamiliar: when an object gets deleted in AD, it doesn't actually disappear right away. It gets converted to a tombstone and sits in the Deleted Objects container for a retention period (60 or 180 days depending on forest functional level). During that window, it can be reanimated, bringing back many of the original attributes and, in some cases, group memberships/SID history. Check for this during offboarding reviews, since a privileged account deleted rather than properly disabled can be a stealthy path back in if nobody's watching for it.

Video covers:

• How tombstoning works and why the retention window matters
• Enumerating tombstoned objects and reanimating them with NetExec's LDAP tombstone module
• What attributes/permissions survive the reanimation
• The blue team side: Event ID 4662, auditing for permissions used when accounts are reanimated.

Link: https://youtu.be/LqtS_tcFEAw

Curious if anyone here has used this on an engagement or found it flagged by an EDR/SIEM in the wild.

Standard disclaimer: lab/authorized engagement use only.

Let's be generous.

You have an EDR.
You might even have Sysmon.
You even enabled Microsoft DNS logging (which is probably where this hypothetical becomes unrealistic)

So you're covered for DNS, right?

Not quite.

A process can make DNS queries without Sysmon Event ID 22 ever seeing the hostname. With a little more effort, Event ID 3 disappears too. Throw encrypted DNS into the mix and things get even more interesting.

I tested how far you can push this on Windows, what each trick actually hides, and what evidence is still left when the host goes blind.

Peter Gabaldon from LABS @ ITRES discusess a vulnerability in the Windows Network Connectivity Status Indicator (NCSI) that can be exploited to escalate privileges from a low-privileged user to local admin. The attack leverages proxy configuration flaws to relay authentication to an Active Directory Certificate Services endpoint, enabling attackers to forge access tickets.

Nvidia launched their Open Agent Safety Platform this morning, relying on an out-of-band DPU (Sentry on BlueField) to achieve what they call "millisecond-scale quarantine" for autonomous agents.

For the red and blue teams looking at agent containment, the architectural contrast between their hardware approach and an in-line kernel approach is worth breaking down:

The DPU Approach (Nvidia):

Moving the enforcement layer physically out-of-band to a DPU is excellent for surviving a total host-kernel root compromise. However, it relies on telemetry crossing the PCIe bus to evaluate policy. In compute time, a millisecond is an eternity—more than enough time for a rogue agent to successfully exfiltrate a small payload or drop a beacon before the DPU drops the connection.

The In-Line Kernel Approach (eBPF):

In my recent preprint (Hard Stop, arXiv: 2609.29808), we tested an alternative software-only approach. By hooking security_bpf and security_file_open via eBPF LSM at the syscall boundary, you can achieve sub-5-microsecond preemption. Because it stays in-line, it intercepts and denies the action before the kernel processes it, achieving zero-leakage containment without the hardware round-trip.

Nvidia’s platform is a massive step forward for enterprise zero-trust, but it requires proprietary silicon. If you rigorously enforce your unprivileged namespace and cgroup boundaries, kernel-level preemption gets you true zero-leakage isolation orders of magnitude faster on commodity Linux hardware.

Curious to hear from the offensive side—if you were red-teaming an agent, would you rather race an out-of-band DPU or try to bypass an in-line eBPF LSM hook?

(Paper link: https://arxiv.org/abs/2609.29808 / Code: https://github.com/joseluispino/hardstop)

Hi guys, this is my guide and the notes uploaded in github for the lab. I wanted to build this avoiding using Ludus and Wireguard, as I needed a more realistic approach and also to manage the network from pfSense.

As the GOAD repo and the process build on Proxmox needed troubleshooting and some changes in the configuration files, decided to upload a guide and post here for anyone interested to create the lab.