Due to the increasing trend of OAuth abuse in phishing and most users' lack of understanding between Device Code and OAuth App Consent phishing, I just added them to the PhishU Framework. Now with a quick, two-step process red teams and internal orgs can leverage the templates to train users for this very real-world attack.

Check out the blog for details at https://phishu.net/blogs/blog-microsoft-entra-device-code-phishing-phishu-framework.html if interested!

I built a set of Claude Code subagents designed for pentesters and red teamers doing authorized engagements.

What it does: You install 6 agent files into Claude Code, and it automatically routes to the right specialist based on what you're working on. Paste Nmap output and it prioritizes attack vectors with

follow-up commands. Ask about an AD attack and it gives you the methodology AND the detection perspective. Ask it to write a report finding and it formats it to PTES standards with CVSS scoring.

The agents cover:

- Engagement planning with MITRE ATT&CK mapping

- Recon/scan output analysis (Nmap, Nessus, BloodHound, etc.)

- Exploitation methodology with defensive perspective built in

- Detection rule generation (Sigma, Splunk SPL, Elastic KQL)

- DISA STIG compliance analysis with keep-open justifications

- Professional pentest report writing

Every technique references ATT&CK IDs, and the exploit guide agent is required to explain what the attack looks like from the blue team side — so it's useful for purple team work too.

Repo has example outputs so you can see the quality before installing: https://github.com/0xSteph/pentest-ai/tree/main/examples

Open to feedback. If you think an agent is missing or the methodology is off somewhere, PRs are welcome.

Write up of a vulnerability chain from a recent SaaS pen test. Two medium-severity findings (file upload bypass and stored XSS) chained together for full admin account creation.

The target had CSP restricting script sources to self, CORS locked down, and CSRF tokens on forms. All functioning correctly. The chain bypassed everything by staying same-origin the entire way.

The file upload had no server-side validation (client-side accept=".pdf" only), so we uploaded a JS payload. It got served back from the app's own download endpoint on the same origin. The stored XSS in the admin inbox messaging system loaded it via an <img onerror> handler that fetched the payload and eval'd it. The payload created a backdoor admin account using the admin's session cookie.

CSP didn't block it because the script was hosted same-origin via the upload. CORS irrelevant since nothing crossed an origin boundary. CSRF tokens didn't matter because same-origin JS can read the DOM and grab them anyway.

Full write up with attack steps, code, and screenshots: https://kurtisebear.com/2026/03/28/chaining-file-upload-xss-admin-compromise/

Also built a Docker lab that reproduces the exact chain with the security controls in place. PHP app, both vulns baked in, admin + user accounts seeded. Clone and docker-compose up: https://github.com/echosecure/vuln-chain-lab

[ Removed by Reddit on account of violating the content policy. ]

Author here. DVRTC is our attempt to fill a gap that's been there for a while: web app security has DVWA and friends, but there's been nothing equivalent for VoIP and WebRTC attack techniques.

The first scenario (pbx1) deploys a full stack — Kamailio as the SIP proxy, Asterisk as the back-end PBX, rtpengine for media, coturn for TURN/STUN — with each component configured to exhibit specific vulnerable behaviors:

• Kamailio returns distinguishable responses for valid vs. invalid extensions (enumeration), logs User-Agent headers to MySQL without sanitisation (SQLi), and has a special handler that triggers digest auth leaks for extension 2000
• rtpengine is using default configuration, that enables RTP bleed (leaking media from other sessions) and RTP injection
• coturn uses hardcoded credentials and a permissive relay policy for the TURN abuse exercise
• Asterisk has extension 1000 with a weak password (1500) for online cracking

7 exercises with step-by-step instructions. There's also a live instance at pbx1.dvrtc.net if you want to try it without standing up your own.

Happy to answer questions.

Backdoor operates at the kernel level using BPF to passively inspect traffic and trigger on crafted packets, avoiding exposed ports or typical C2 indicators.

Tradecraft enables long-term persistence and covert access inside core network infrastructure, with very limited visibility from standard monitoring.

Interesting case of network-layer backdoor design rather than traditional userland implants.

In enterprise environments, identity effectively became the control plane once network perimeters broke down (e.g. zero trust, et cetera).

I’m seeing a similar pattern emerging on the public internet via age verification and safety regulation, but with identity moving closer to the access layer itself.

Not just: “Are you over 18?”

But: identity assertions are becoming part of how access is granted at the OS/device/app store level.

From a security perspective, this seems to introduce some new attack surfaces:

• high-value identity tokens at the OS/device level
• new trust boundaries between apps, OS, and third-party verifiers
• incentives to target device compromise or token reuse rather than account-level bypass
• potential centralisation of identity providers as enforcement points

Questions I’m trying to think through:

• Does this effectively make identity providers the new perimeter/control plane?
• How would you model this system (closer to DRM, identity federation, or something else?)
• What are the likely failure modes if this layer becomes centralised?
• Are decentralised / on-device credentials actually viable from a security standpoint, or do they just shift the attack surface?

Curious how people here would threat model this or where the obvious breakpoints are.

NTLM-Relaying has been proclaimed dead a number of times, signing requirements for SMB and LDAP make it nearly impossible to use captured NTLM authentications anymore. However, it is still possible to relay to many webservers that do not enforce Extended Protection for Authentication (not just ADCS / ESC8).