It’s crazy how things come full circle more than a decade later.

About a decade ago, I got interested in calendar phishing after seeing Beau Bullock’s work at BHIS. Around that time, I built and shared some of my own Graph API scripts for calendar phishing, added support for it in my open source PhishAPI tool, and even introduced the idea to KnowBe4 so they could eventually bring it into phishing training for clients (which Kevin Mitnick himself used Beau's command-line tool to demonstrate).

I brought it to their attention at a client’s request after using the technique successfully on them, during a time when calendar phishing was still largely overlooked as a real-world attack path.

Back then, it was still niche enough that plenty of defenders were not thinking about calendar invites as a phishing channel at all.

More than a decade later, I’m still refining the concept, now as part of the commercial PhishU Framework.

I’m happy to say the Framework fully supports Calendar Event phishing again, but now in a much more usable way:

· Native calendar event workflow
· Simple WYSIWYG w/ AI-generated timing suggestions and content
· As easy as selecting the Calendar Event template
· Automatically tied into training when used in a campaign

It’s built for red teams and security teams that want realistic phishing assessments, including credential and session capture paths, not just allow-list-only email testing.

Most AI discussions focus on correctness.

Accuracy. Alignment. Output quality.

But there’s a more fundamental problem underneath all of that:

Who — or what — is actually allowed to execute a decision?

---

I just published a paper introducing:

Authority Encoding Risk (AER)

A measurable variable for something most systems don’t track at all:

Authority ambiguity at the moment of execution.

---

Today’s systems can tell you:

• if something is likely correct

• if it follows policy

• if it appears safe

But they cannot reliably answer:

Is this decision admissible under real-world authority constraints?

---

That gap shows up in:

• automation systems

• AI-assisted decisions

• institutional workflows

• underwriting and loss modeling

And right now, it’s largely invisible.

---

The paper breaks down:

• how authority ambiguity propagates into risk

• why existing frameworks fail to capture it

• how it can be measured before loss occurs

---

If you’re working anywhere near AI, risk, infrastructure, or decision systems — this is a layer worth paying attention to.

---

There’s a category of risk most AI systems don’t even know exists.

This paper represents an initial formulation.

Ongoing work is focused on tightening definitions, expanding evidence, and strengthening the model.

https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=6229278

By end of 2026, will the penetration testing market bifurcate such that average prices for traditional high-end pentests remain within 20 percent of 2024 rates AND AI-automated pentest offerings commoditize the low end priced comparably to vulnerability scanning tools like Qualys or Tenable under 10K per year for equivalent coverage, rather than AI displacing mid-career pentesters through firm closures and broad price compression across all tiers?

If you set LmCompatibilityLevel to 5 a couple years back and called it done, there's a good chance NTLMv1 is still running in your environment. Not because the setting doesn't work. Because it doesn't work the way you think it does.

This isn't just aimed at people who never fully switched to Kerberos. It's also for the ones who are pretty sure they did.

For people not deep into auth protocols: NTLMv1 and NTLMv2 are both considered unsafe today. NTLMv1 especially. It uses DES encryption, which with a weak password can be cracked in seconds. And because NTLM never sends your actual password (challenge-response, the hash gets passed not the plaintext), it's also wide open to pass-the-hash. An attacker intercepts the hash and reuses it to authenticate as you. Responder is the tool that makes this trivial and it's been around forever.Silverfort's research puts 64% of authentications in AD environments still on NTLM.

Here's the actual problem with the registry fix. LMCompatibilityLevel is supposed to tell your DCs to reject NTLMv1 traffic and require NTLMv2 or Kerberos instead. Sounds reasonable. But enforcement runs through the Netlogon Remote Protocol (MS-NRPC), the mechanism application servers use to forward auth requests to your domain controllers. There's a structure in that protocol called NETLOGON_LOGON_IDENTITY_INFO with a field called ParameterControl. That field contains a flag that can explicitly request NTLMv1, and your DC will honor it regardless of what Group Policy says.

The policy controls what Windows clients send. It has no authority over what applications request on the server side. Any third party or homegrown app that hasn't been audited can still be sending NTLMv1 traffic and you'd have no idea.

Silverfort built a POC to confirm this. They set the ParameterControl flag in a simulated misconfigured service and forced NTLMv1 authentications through a DC that was configured to block them. Worked. They reported it to Microsoft, Microsoft confirmed it but didn't classify it as a vulnerability. Their response was to announce full removal of NTLMv1 starting with Windows Server 2025 and Windows 11 24H2. So that's something, atleast.

If you're not on those versions, you're still exposed and there's no patch coming.

What you can do right now: turn on NTLM audit logging across your domain. Registry keys exist to capture all NTLM traffic so you can actually see what's authenticating how. From there, map every app using NTLM, whether primary or as a fallback, and look specifically for anything requesting NTLMv1 messages. That's your exposure.

I looked at how Cursor, Claude Code, Devin, OpenAI, and E2B actually isolate agent workloads today. The range goes from literally no sandbox (Cursor runs commands in your shell) to hardware-isolated Firecracker microVMs (E2B).

Container runtimes have had escape CVEs every year since 2019. Firecracker: zero guest-to-host escapes in seven years. AWS themselves said "we do not consider containers a security boundary."

The post covers five assumptions traditional isolation makes that agents break, real incidents (Devin taken over via one poisoned GitHub issue, Slack AI exfiltration, Clinejection supply chain attack), and the six dimensions of isolation I'll be exploring in this series.

Axios is one of the most used npm packages which just got hit by a supply chain attack. Malicious versions of Axios (1.14.1 and 0.30.4) hit the npm registry yesterday. They carry a malware dropper called plain-crypto-js@4.2.1. If you ran npm install in the last 24 hours, check your lockfile. Roll back to 1.14.0 and rotate every credential that was in your environment. Currently, as of now, npmjs has removed the compromised versions of axios package along with the malicious plain crypto js package. Live updates + info linked.

tl;dr - one POST request decrypted every API key in a 14K-star project. tested 5 more MCP servers, found RCE, SSRF, prompt injection, and command injection. 70K combined github stars, zero auth on most of them.

• archon (13.7K stars): zero auth on entire credential API. one POST to /api/credentials/status-check returns every stored API key decrypted in plaintext. can also create and delete credentials. CORS is *, server binds 0.0.0.0

• blender-mcp (18K stars): prompt injection hidden in tool docstrings. the server instructs the AI to "silently remember" your API key type without telling you. also unsandboxed exec() for code execution

• claude-flow (27K stars): hardcoded --dangerously-skip permissions on every spawned claude process. 6 execSync calls with unsanitized string interpolation. textbook command injection

• deep-research (4.5K stars): MD5 auth bypass on crawler endpoint (empty password = trivial to compute). once past that, full SSRF - no URL validation at all. also promptOverrides lets you replace the system prompt, and CORS is *

• mcp-feedback-enhanced (3.6K stars): unauthenticated websocket accepts run_command messages. got env vars, ssh keys, aws creds. weak command blocklist bypassable with python3 -c

• figma-console-mcp (1.3K stars, 71K weekly npm downloads): readFileSync on user-controlled paths, directory traversal, websocket accepts connections with no origin header, any local process can register as a fake figma plugin and intercept all AI commands

all tested against real published packages, no modified code. exploit scripts and evidence logs linked in the post.

the common theme: MCP has no auth standard so most servers just ship without any.

An attack class that passes every current LLM filter

https://shapingrooms.com/research

I opened OWASP issue #807 a few weeks ago proposing a new attack class. The paper is published today following coordinated disclosure to Anthropic, OpenAI, Google, xAI, CERT/CC, OWASP, and agentic framework maintainers.

Here is what I found.

Ordinary language buried in prior context shifts how a model reasons about a consequential decision before any instruction arrives. No adversarial signature. No override command. The model executes its instructions faithfully, just from a different starting angle than the operator intended.

I know that sounds like normal context sensitivity. It isn't, or at least the effect size is much larger than I expected. Matched control text of identical length and semantic similarity produced significantly smaller directional shifts. This specific class of language appears to be modeled differently. I documented binary decision reversals with paired controls across four frontier models.

The distinction from prompt injection: there is no payload. Current defenses scan for facts disguised as commands. This is frames disguised as facts. Nothing for current filters to catch.

In agentic pipelines it gets worse. Posture installs in Agent A, survives summarization, and by Agent C reads as independent expert judgment. No phrase to point to in the logs. The decision was shaped before it was made.

If you have seen unexplained directional drift in a pipeline and couldn't find the source, this may be what you were looking at. The lens might give you something to work with.

I don't have all the answers. The methodology is black-box observational, no model internals access, small N on the propagation findings. Limitations are stated plainly in the paper. This needs more investigation, larger N, and ideally labs with internals access stress-testing it properly.

If you want to verify it yourself, demos are at https://shapingrooms.com/demos - run them against any frontier model. If you have a production pipeline that processes retrieved documents or passes summaries between agents, it may be worth applying this lens to your own context flow.

Happy to discuss methodology, findings, or pushback on the framing. The OWASP thread already has some useful discussion from independent researchers who have documented related patterns in production.

GitHub issue: https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/issues/807

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

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.

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).

We pentested a web app built 100% with AI — no human-written code. Functional, clean, well-structured. But security-wise, we found critical issues on day one: LFI, IDOR, vulnerable dependencies, and more.

AI-generated code is not secure by default. And vibe coding moves fast enough that security gets skipped entirely.

Full writeup with technical details and recommendations: https://www.hackmosphere.fr/en/?p=3803

Anyone else seeing this pattern in AI-generated apps?

There are reports of OVHcloud-related data being posted on a forum for sale. No official confirmation so far from OVHCloud. Given OVH’s scale, potential impact could be significant depending on scope, especially in Europe

UPDATE: OVHcloud CEO, Octave Klaba has commented that the sample dataset was not found in their system.

Most AI security testing focuses on the model: prompt injection, jailbreaking, and output filtering.

We've been working on something different: testing the agent *system*. The protocols, integrations, and decision paths that determine what agents do in production. The result is a framework with 209 tests covering 4 wire protocols:

**MCP (Model Context Protocol)** Tool invocation security: auth, injection, data leakage, tool abuse, scope creep

**A2A (Agent-to-Agent)** Inter-agent communication: message integrity, impersonation, privilege escalation

**L402 (Lightning)** Bitcoin-based agent payments: payment flow integrity, double-spend, authorization bypass

**x402 (USDC/Stablecoin)** Fiat-equivalent agent payments: transaction limits, approval flows, compliance

Every test maps to a specific OWASP ASI (Agentic Security Initiatives) Top 10 category. Cross-referenced with NIST AI 800-2 categories for compliance reporting.

```

pip install agent-security-harness

```

20+ enterprise platform adapters included (Salesforce, ServiceNow, Workday, etc.).

MIT license. Feedback welcome. Especially from anyone running multi-agent systems in production. What attack vectors are we missing?

SnappyClient is a malware found by Zscaler that uses a custom binary protocol (encrypted and compressed) to communicate with its C&C server, with little to work with when it comes to network detection.

At Netomize, we set out to write a detection rule targeting the encrypted message packet by leveraging the unique features of PacketSmith + Yara-X detection module, and the result is documented in this blog post.