The Pattern Keeps Showing Up in Post-Incident Reviews

This isn't a single incident. It's a pattern — specific enough in structure that it deserves a name rather than being filed under "social engineering" and moving on.

The attack has emerged consistently across multiple post-incident reviews, and it tends to generate the same conversation among security teams: smart people landing in different places about where the failure actually occurred. The controls worked. The people followed reasonable instincts. And somehow the attacker still ended up with a ransomware payload on the way to staging.

The reason that keeps happening is that neither the controls nor the post-incident analysis is looking at the chain as a whole.

The Attack Chain

The sequence across confirmed incidents looks like this:

• Stage 1 — Inbox Flood The target receives hundreds of subscription confirmation emails within minutes. Every message is legitimate — real opt-in confirmations from real services. No malicious content, nothing for a filter to act on.
• Stage 2 — Vishing Call ("IT Support") Shortly after the flood hits, the target receives a call from someone claiming to be from internal IT. The caller references the email problem the user is actively experiencing, establishing immediate credibility. They offer to help.
• Stage 3 — Quick Assist Remote Session The user is walked through launching Microsoft Quick Assist — a built-in Windows tool — and sharing their screen. Because the user initiated the session, it doesn't flag. No policy violation. No alert raised.
• Stage 4 — C2 Deployment → Persistence → Ransomware From the active session: C2 framework deployed, persistence established, staged ransomware payload delivered. In several confirmed incidents, Havoc C2 was run alongside a legitimate, vendor-signed RMM binary as a parallel channel.

Where the Detection Gap Actually Sits

The inbox flood is only recognizable as an attack in aggregate — specifically as a sudden per-user volume spike over a compressed time window. Most SIEM pipelines aren't built to surface that by default.

Microsoft Defender's Mail Bombing Detection has been available since mid-2025, but depending on your configuration it may route messages to junk rather than generating a SOC alert. The flood gets cleaned up. The call comes in. Nobody gets paged.

In several confirmed incidents, visibility didn't start until after remote access already existed. By the time any tool in the stack flagged something, the attacker was already operating inside the session the user opened for them.

The Procedural Control That Has the Most Leverage

The obvious defence is process: hang up, find the IT support number independently, call back using the internal directory only.

Simple in theory. In practice it adds friction to every legitimate helpdesk interaction and requires process design that still holds when users are stressed, distracted, and under time pressure — which is exactly the state the inbox flood is engineered to create.

Most organisations have this written down somewhere. Far fewer have actually operationalised it. And almost none have stress-tested it under simulated voice pressure.

Why Cognitive Load Is the Real Attack Surface

Social engineering resistance degrades under cognitive load. The inbox flood isn't accidental — it's engineered to create exactly the mental state in which a plausible offer of help gets accepted without friction. The caller doesn't need to be perfect. They just need to be good enough for someone who is overwhelmed and looking for the problem to stop.

This is why "Layer 7 is the new perimeter" isn't a slogan. The human decision point is the attack surface, and it operates under completely different conditions than the ones your policy was written for.

Two Diagnostic Questions Worth Asking Now

These separate organisations that catch this pattern from those that don't:

• Does your remediation runbook explicitly scope RMM tools? Not "check for unauthorised software generally" — does it include a step that compares installed remote access tooling against an approved baseline? If the honest answer is "we'd probably catch it," that's the same as no.
• Has anyone stress-tested your callback procedure under live voice pressure? Not a tabletop. Not a phishing email. A call and someone offering to fix a problem. If the answer is no, you don't actually know whether the procedural control holds when it matters.

How Breacher.ai Simulates This Attack Chain

Breacher.ai is a multi-stage simulation platform built around exactly this threat model — not isolated phishing tests, but coordinated sequences that replicate the vishing call, the trust establishment, and the remote access ask. We simulate every stage of the chain an attacker uses after the stressor has done its work.

The vishing + Quick Assist pattern is a first-class scenario in our assessment platform because it represents what's actually being used in the wild right now, not a theoretical edge case.

• Agentic Vishing Calls AI voice agents with sub-200ms response latency, OSINT-informed caller scripts, and real-time adaptive dialogue — running live against your actual user population, not a tabletop scenario.
• Multi-Stage Chained Scenarios Full attack chain simulations running voice → trust establishment → remote access request in sequence. Measures exactly where the chain breaks — or doesn't — and produces empirical data on where the gap is.
• Deepfake Video (Teams / Meet / Zoom) Static and interactive deepfake avatars for executive and IT impersonation via video conferencing — the escalation of the vishing vector that's already in production use by threat actors.
• OSINT Threat Mapping Target profiling from open sources to build contextually credible call scripts — the same reconnaissance an attacker runs before dialing your help desk.
• Post-Assessment Breach Chain Analysis Detailed reporting that shows exactly where in the control stack the failure occurred — not just who clicked, but which gap in the sequence the attacker walked through and why.