r/redteamsec

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.

A depth-8 ftrace analysis of how the Linux kernel processes ICMP Timestamp (Type 13/14) requests — covering the full call chain, payload validation, conntrack behavior, and ts_ori echo mechanics.
————————

Most security tooling treats ICMP as a monolith: ping works, or it doesn’t. ICMP Timestamp (Type 13/14) sits in that overlooked middle ground — defined in RFC 792, implemented in every Linux kernel, but rarely scrutinized at the source level.
This post documents a depth-8 ftrace investigation of icmp_timestamp() on Linux kernel 6.17.13. Beyond cataloguing individual findings, the goal is to map the architectural reality of how the kernel processes ICMP Timestamp requests — every code path, every decision point, every place where the implementation diverges from what RFC 792 specifies.
What emerged was a set of concrete, reproducible behaviors: a silent payload threshold, a Code field that is never read, ts_ori that is echoed without any range check, and a netfilter pipeline that creates a conntrack entry for every single exchange.

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.

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.

Hey yall,

was wondering what would be the best thing to do if someone has build a builder that generates payloads, which bypass crowdstrike falcon (on extra aggressive settings) and get you a reverse shell.. CS is gonna give me like 200$ probably.. not really into that tbh

Writeup on two open directories we recovered, with a defender-focused breakdown of the camera and router compromise techniques and the network behavior their proxy tooling produces.

Detection and mitigation angles worth pulling out:

• Edge devices opening outbound connections on port 4444 (chisel reverse tunnels) is a strong compromise signal
• Sequential ONVIF and RTSP discovery and repeated hits on camera ports show up better at the network boundary than in camera logs, which are usually shallow or absent
• Credential guessing was the primary access path before any CVE was tried, so default and weak creds on cameras and routers are still the main exposure
• Exploited camera CVEs are years old and long patched (Hikvision, Dahua); TP-Link Archer and MikroTik were the router targets
• Every targeted device answered directly from the internet, so pulling cameras and routers behind a VPN or onto isolated VLANs removes most of this

Outcomes against the government and military sites in the operator's bash history are not confirmed from the files. Full mitigations and ATT&CK mapping in the post:
https://hunt.io/blog/russian-speaking-operator-ukrainian-camera-toolkit 

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?

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.

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.

I built qsa.sh to give you an instant, outside-in security scan of your own public IP straight from your terminal.

You can run it like this:

curl qsa.sh

What it does: It triggers a real external port and vulnerability scan (using open-source tools like naabu, nmap + vulners, and nuclei) of the public IP you're connecting from, streamed live back to your terminal in about 30 seconds.

How it handles safety & consent:

Only your IP: There is no target input field. You cannot point it at anyone else.

The 15-second abort window: When you run the command, it prints your detected IP and gives you a 15-second grace period (Ctrl-C) to abort before anything is actually scanned.

Refusals: Known CGNAT, mobile-carrier, and detected VPN/Tor/IPv6 origins are refused outright.

Zero retention: The results are entirely ephemeral and streamed live—nothing is written to disk.

Curious to hear what people think.

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.