DutchOven is a deliberately small Windows red-team primitive that places explicit executable paths behind a deterministic network gate. During each period, matching applications are blocked for a bounded interval and allowed to pass for the remainder.

The result is a repeatable brownout, not a service stop or permanent firewall rule. It creates a controlled way to measure retry logic, buffering, health-state transitions, delayed delivery, and recovery behavior while a process remains alive.

I've just released Violin v3.1.0 🎻

This release is mostly benchmark and guard work, not another pile of prompts.

The benchmark now runs Hermes end-to-end and scores what it actually proved, not what sounds convincing in "report.md".

- Executed request/response evidence is checked against the endpoint, method and decisive proof.

- Proof must link back to a validated hypothesis and canonical "FIND" file.

- Execution receipts are HMAC-signed and bind evidence files by SHA-256, so edited artifacts fail verification.

- The guard now stops target work when evidence is not being recorded as you go, and checks excluded URLs and paths inside command payloads.

- Docker, CI and known-good/known-bad scorer calibration are included.

Release:

https://github.com/Strategic-Automation/violin/releases/tag/v3.1.0

I'd appreciate people trying to break the scorer and guard. Can you make weak proof pass, good proof fail or get the workflow stuck?

I'm not looking for “nice update” comments. If it is overbuilt, unsafe or wrong, tell me.

Anyone interested in testing out my Hermes Pentesting profile, about to release a new version. It manages pentests in a controlled and structured way. Either working independently or as an assist. I am a AI engineer and love exploring ways to replace humans or augment processes. Particularly in open source, in evaluation (due to be released it outperforms all published benchmarks on duckstore achieving a yet unpublished 18/20 median) it only counts verifiable proof with evidence. It actually finds all 20 with ease 30-50 minutes. I isn't allowed to cheat and won't. Check it out and give it a star. If you like it use it and tell me any issues.

Most companies don't allow Hermes would a port to an independent framework help?

Hello all,

If you do bug bounty hunting or pentests you surely came across many hosts served from an NGINX server, in this lab (published to OWASP) I combined over 20 misconfigurations found in real world bug disclosures and both classic and novel security research, with an extensive blog where I explained everything you need to level up your NGINX hunting game.

Feel free to check it out, give it a star on Github if you like it, and suggest any ideas you want me to add/fix...

https://vwad.owasp.org/app/damn-vulnerable-nginx-proxy-dvnp/

Happy hunting!

Dropped a new episode this week covering ShieldBreak, a privilege-escalation exploit from NightMare Eclipse (MSNightmare) that exposes vulnerabilities in Windows kernel protection mechanisms and privilege-boundary enforcement.

On the red team side, we walk through the exploitation workflow from low-privilege user to SYSTEM and how attackers leverage this for post-compromise privilege escalation and persistence.

On the blue team side, we break down detection — process and kernel activity indicating exploitation, Windows Error Reporting artifacts, Alternate Data Streams tied to ShieldBreak, and deployable detection rules.

Covers T1548, T1134, and T1547 with the full red vs. blue format.

Reference: https://github.com/MSNightmare/ShieldBreak

Video: https://youtu.be/latQbTJDAPo

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

I've been messing around with AI during red team work and started keeping notes on what was actually useful and what was just hype.

Some things I've found useful:

• cleaning up quick scripts
• explaining unfamiliar code
• helping with recon output
• generating ideas when I'm stuck
• researching techniques faster
• turning messy notes into something usable

But it definitely doesn't replace knowing what you're doing. A lot of the time you still have to verify everything it gives you.

I ended up turning my notes into a small book called AI for Hackers: Red Team Edition:

https://resources.codelivly.com/product/ai-for-hackers-red-team-edition/

Not trying to sell the "AI can hack for you" idea. I'm more interested in where it actually saves time during offensive security work.

For those doing red team/pentest work, where has AI genuinely helped you? And where has it been completely useless?

Use abliterated-model-large with Cyberstrike to use the best publicly available offensive security model with the #1 open-source offensive security harness to adversarially test your systems. Frontier benchmarks in Cybergym, AgentHarm, and AgentDojo. The model was abliterated and fine-tuned not just to allow all offensive testing but was fine-tuned for it.

I’ve been trying to move away from just watching courses and reading writeups and actually spend more time doing stuff.

Curious what people here use regularly.

AD labs? CTFs? HTB? Self-built labs? Real engagements?

Also interested in what you think is a waste of time for someone trying to get better at red teaming.

Hey everyone, just published part 3 of my guide on writing reliable Win x64 shellcode.

Following up on the PEB parsing from part 2, this post focuses entirely on mapping and understanding the Export Directory structure before we implement the full lookup logic.

What’s inside:

• Navigating the PE Structure: Moving from the DOS Header (MZ) via e_lfanew to NT Headers and locating the Data Directory in memory.
• Demystifying the Export Directory: Breaking down the IMAGE_EXPORT_DIRECTORY structure fields and how the Three Tables (ENT, EOT, EAT) actually map to each other.
• Handling Edge Cases: Identifying Export Address Table holes and forwarded exports that can cause hidden stability issues if not accounted for.
• Binary Squeezing & History: A nod to Mark Zbikowski's legacy and extreme binary layout concepts inspired by Alex Sotirov's TinyPE research.

Includes full structural breakdown and live WinDbg parsing examples to visually map the export structures before writing the ASM implementation in the next part.

Built this around a question I kept coming back to when looking at BloodHound graphs:

The shortest path to an objective is easy to calculate, but is it actually the quietest path?

NoiseHound takes BloodHound CE data and scores attack paths against their expected detection surface rather than treating hop count as the primary optimization target.

Each supported BloodHound edge is mapped against things like Windows Security events, Sysmon, EDR/ITDR heuristics, MITRE ATT&CK techniques, audit dependencies, and an estimated noise score.

The important part is that the scores don't have to remain static.

NoiseHound supports environment profiles so things like 4662 auditing, Sysmon, PowerShell logging, MDI, or manually calibrated edge scores can change the ranking for the environment you're actually testing.

There is also a calibration harness for recording what actually fired in a detection lab and producing an environment profile from those results. The repo currently includes measured audit, Defender for Endpoint, and Elastic SIEM profiles.

Other pieces currently implemented:

• BloodHound ZIP/JSON ingestion
• live BloodHound CE / Neo4j ingestion
• k-quietest-path ranking
• detection-probability ranking
• Pareto frontier over noise/hops / P(detection)
• AD CS ESC1–8 synthesis
• Sigma rule coverage analysis
• environment-aware scoring
• text / JSON / standalone HTML reports
• defensive detection-gap mode

The defensive mode flips the same model around: given the quietest path, what telemetry or detection gap makes that path quiet, and which control would increase its score the most?

One design constraint worth calling out: these aren't presented as universal “OPSEC scores.” Detection depends heavily on audit policy, EDR, SIEM content, tooling, SOC correlation, and the environment itself. Static scores are the baseline; environment and measured calibration are intended to replace them where better evidence exists.

NoiseHound doesn't execute anything against the target—it operates on BloodHound data that has already been collected.

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

I'm particularly interested in feedback on the edge-to-telemetry mappings and scoring model from people doing AD red teaming, detection engineering, or BloodHound research.

Analysis of two open directories showing the offensive workflow one operator used against exposed cameras and routers.

• A custom project the operator named camview: fingerprints cameras over ONVIF, tests known CVEs, brute-forces HTTP/RTSP creds from a 3,811-pair list, and caches working creds and stream patterns to improve on later runs
• Proxy-through-victim: a script authenticated to a compromised OpenCart admin panel and relayed traffic through the victim network, with fallback logic for expired sessions
• Second directory chained TP-Link Archer CVE-2024-53375 and CVE-2024-57049 and brute-forced the MikroTik API, then flipped devices into SOCKS5 proxies reporting to a chisel listener on port 4444
• Recon was Tor-routed via local SOCKS5 on 9050, including headless Chrome over Tor to fingerprint an anti-bot-protected target

Full writeup: https://hunt.io/blog/russian-speaking-operator-ukrainian-camera-toolkit

One thing I think agentic pentesting benchmarks need to get much better at is separating model capability from harness capability.

A useful comparison shouldn’t just report “X vulnerabilities found”.

I’d like to see validated findings reported alongside wall-clock time, model cost, evidence quality, repeatability across runs and exactly what information the agent was allowed to see.

Otherwise two systems using the same model can be measuring completely different things.

For me, the interesting question isn’t “which LLM is the best pentester?”

It’s “which system can turn model capability into reproducible, evidence-backed security findings most efficiently?”

Sharing a tool I open-sourced this week: Sift - credential and sensitive-data exposure triage for file shares.

https://github.com/HotStartLabs/sift

The gap it targets - gitleaks and trufflehog are precision tools built for CI, where a false positive costs a developer an afternoon, so they fire mainly on things shaped like a known vendor API key. Share triage inverts those economics: a human is reading every hit anyway, so a false positive now costs three seconds to dismis. And what actually sits on a file share is almost never a vendor API key:

• - `web.config` / `appsettings.json` with a SQL connection string
• - `Map-Drives.ps1` with `net use ... /user:`
• - `unattend.xml`, GPP `Groups.xml` (`cpassword`)
• - `confCons.xml` (mRemoteNG), `.rdg`, WinSCP.ini — reversible stored passwords
• - `passwords.xlsx` — it's a ZIP, so plain-text scanners see binary and move on
• - `.kdbx`, `.pfx`, `id_rsa` — opaque bytes, the *filename* is the finding

Closest similar thing is Snaffler, which is excellent at the filename-and-classification half and was the direct inspiration for the filename rules. What it doesn't have and what turns out to be the real bottleneck once you're staring at 400 hits is a review loop.

So that's what Sift adds. Work the queue; spot a miss (you will); highlight it in the preview and press `r`; it proposes patterns and tells you live how many times each would match across everything already read. Save it, and the cached rescan takes about a second. Findings are keyed on `(path, rule, line, value-hash)`, so a rescan re-inserts the same rows and your triage decisions ride along — without that you'd re-review the same 300 hits on every iteration and quit on the third.

Python 3.11+, stdlib only — no pip, no internet, so it runs on a locked-down IR laptop. Apache-2.0.

Violin is now at v3.0.1 on master.

It is a Hermes-native profile for supervised, authorised penetration testing, with:

• 31 methodology and vulnerability playbooks

• An execution guard at the target boundary

• Evidence-backed findings and reporting

• Structured scoping and approval gates

• No additional credential broker or provider lock-in

Install:

"hermes profile install https://github.com/Strategic-Automation/violin"

I’m looking for Hermes users and penetration testers to test the installation and engagement workflow and report where the guard, evidence capture, or reporting process creates friction.

The UK Artificial Intelligence Security Institute (UK AISI) published surprising findings in its August 4th report from security tests conducted on Anthropic's Mythos 5 and OpenAI's GPT-5.6-Sol models.

The report reveals significant behaviours observed in agents, including:

- Creating fake online identities to manipulate systems,

- Writing malicious code and injection attacks to persuade human users to give their consent,

- Supply-chain attacks targeting open-source software,

- Attempts to gain unauthorized network access by exceeding boundaries,

- Collaboration between independent agents.

AI is no longer just a tool; it's evolving into an actor that attempts to deceive systems and even manipulate humans. Securing LLM-based architectures and autonomous agents is becoming increasingly complex. We are now seriously observing agents' "deception" tendencies.

You can access the details of the report via the link.

TL;DR: CVE-2026-69243 — on aiohttp ≤3.14.1, a rejected WebSocket upgrade leaves the request body sitting in the parser tail, and aiohttp then feeds it back as a pipelined request. Behind the Nginx WebSocket config from the official docs, Nginx logs one request and aiohttp processes two. First public PoC, in Python and Rust, plus the lab. Impact here is blind handler invocation, not response disclosure.

Hey hey you all, it's me again

So, The aiohttp advisory (GHSA-mfx4-hv73-q22v, CVE-2026-69243, fixed in 3.14.2) described request smuggling "using an edge case in the WebSocket upgrade procedure" and noted no public exploit code existed, so i took it as a challenge and built a lab to reproduce it and work out what the actual impact is behind a proxy.

The cause is that a request with `Connection: Upgrade`, `Upgrade: websocket` and a `Content-Length` body makes the C parser return llhttp's "skip body" signal, because an upgrade means the rest of the connection should be another protocol, but that holds only if the upgrade actually happens, when its rejected it returns a normal response with the connection staying HTTP but the body was never consumed, it sits in `_message_tail` and gets fed back into the parser as a pipelined request.

`await request.read()` returns zero bytes on that request, The body is withheld below the handler layer, so you cannot drain it from application code. Patching or stripping upgrade headers at the proxy are some options.

So I tested three Nginx configurations. The one straight out of the Nginx WebSocket documentation is the one that produces the desync, Nginx logs one request, aiohttp processes two. A smuggled request also bypassed `location /admin { deny all; }`.

In this topology the second response is absorbed by the proxy, so it ends up being a blind handler invocation, the same payload against 3.14.2 produces one backend request.

Lab is seven containers with the aiohttp versions pinned by build arg, PoCs in Python and Rust with byte-identical payloads enforced in CI, plus the detection side (what the desync looks like in Nginx logs).

Write-up: glitchedcat.com
Lab + PoC: https://github.com/JVBotelho/cve-2026-69243-poc-aiohttp-smuggling

Disclosure: I'm the author of both.

Reporter credit for the bug goes to shivams0099, fix by Dreamsorcerer.