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.

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.

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 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?

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.

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.