Ransomware operators are increasingly combining inbox flooding and voice phishing to obtain legitimate remote access into corporate environments.

The technique does not defeat existing controls directly. Instead, it exploits operational gaps between user training, helpdesk procedures, and endpoint monitoring.

This article identifies three specific control gaps that allow the attack to succeed.

Security In Practice | CyOps Consulting Team

In February 2026, Huntress documented an attacker who moved from initial Quick Assist access to nine additional endpoints inside a single organisation in eleven hours (Huntress 2026). That finding does not invalidate your patching cadence or your endpoint controls. It invalidates the assumption that phishing awareness training covers this threat vector. Training does not address voice pressure, and those are two different control problems.

The practitioners getting this wrong are not ignoring security; they are applying the right controls to the wrong surface. The February 2026 variant uses a modified Havoc C2 tool incorporating indirect syscalls and registry-based fallback channels (Huntress 2026). This confirms that the attack is far more sophisticated than the “gift-card purchase” scenario many practitioners associate with social-engineering incidents.

The Attack Pattern

The pattern is consistent across Black Basta and 3AM families as documented across Microsoft, Sophos, and Huntress research (Microsoft 2024; Sophos 2025; Huntress 2026). A high-volume email flood creates urgency; a vishing call redirects the user to open Quick Assist; the attacker takes remote control, deploys the Havoc C2 implant, establishes persistence, and stages for ransomware. The session is user-initiated throughout.

Two Assumptions That Do Not Hold

The first assumption is that phishing training covers this. Phishing simulations model asynchronous decisions made without time pressure. A vishing call is synchronous. The attacker manages the interaction in real time, narrows decision windows, and applies direct social pressure. Those are structurally different cognitive conditions. That is a category error in the control model, not a training gap.

The second assumption is that Endpoint Detection and Response (EDR) will catch it. The Havoc C2 variant uses Hell's Gate and Halo's Gate indirect syscall techniques targeting ntdll.dll, DLL sideloading from legitimate signed binaries, and URL paths mimicking legitimate API traffic (Huntress 2026). Each component is low-suspicion in isolation. The initial Quick Assist session is user-authorised, so it does not flag as anomalous. EDR on default rule sets and vendor-managed signatures lacks visibility into this chain without custom detection logic.

This attack does not expose a weakness in training or in EDR. It exploits the gap between them, operating where each control assumes the other provides coverage.

Those two assumption failures produce three specific operational gaps that most security programs have not closed.

Gap 1: Helpdesk Identity Verification Is Policy, Not Process

When the call arrives, the employee is already in a disrupted state. The inbox flood landed first, timed deliberately to precede the call (Microsoft 2024; Huntress 2026; Sophos 2025). Most organisations have a policy telling employees not to grant remote access to unsolicited callers. What they do not have is an operational path for executing that policy while someone is on the phone, applying pressure, and offering to fix the problem.

This gap persists because helpdesk identity verification has been treated as a user awareness problem and handed to training teams rather than operationalised by IT or security leadership. There is no directory-only callback procedure, no challenge phrase or one-time verification code mechanism, and no documented escalation path for an employee who is uncertain. Training names the problem. It does not resolve it.

The consequence is direct: the resulting Quick Assist session is user-initiated and user-authorised, so security tooling has no basis to flag it as anomalous (Huntress 2026). The attack proceeds inside a channel the victim opened themselves.

The fix is procedural: employees hang up and call back using only a number sourced from the verified internal directory, never a number provided during the call or in the email flood. The constraint is real: this adds friction to legitimate helpdesk volume and requires process redesign across IT operations. That is not a policy addendum, and it is not a training module. Whether to absorb that friction is the decision most organisations have not made.

Gap 2: Email Bombing Is a SOC Alert, Not a Spam Ticket

Hundreds or even thousands of subscription confirmation emails are sent from legitimate services within minutes. This email flood acts as a conditioning sequence and is typically timed to business hours immediately before the vishing call (Huntress 2026). Each message passes every content filter cleanly because each message is, in isolation, legitimate (Sophos 2025; Huntress 2026). The signal reaches the spam filter or an IT ticket queue. The SOC has no open investigation when the Quick Assist session is established.

The detection gap is architectural, not a tooling failure. Email security tools evaluate individual messages for malicious content. A subscription confirmation from a real service carries none. The attack is only visible in aggregate, as a volume anomaly against a per-user baseline. That detection logic is not a default rule in most environments. The tooling to build it exists. The configuration does not.

The consequence is that post-access is when visibility begins, after the session is authorised and after C2 is deployed.

Two actions close this gap. First, build a volume-based anomaly alert at the SIEM level: a per-user, per-time-window threshold trigger, independent of individual message classification. This is custom logic in most environments. Second, if the environment runs Microsoft Defender for Office 365, confirm that Mail Bombing Detection, rolled out between late June and early July 2025 (Microsoft 2025), is active and routing into the SIEM rather than silently deflecting to junk. If the environment is not on Defender P2, this detection and automated response capability does not exist natively. Users with legitimately high subscription volumes will require individual threshold tuning. That is a known cost.

Gap 3: Partial Remediation Leaves the Attacker In

Huntress documented the post-access toolchain explicitly: Havoc Demon C2 implants and legitimate Remote Monitoring and Management (RMM) tools running in parallel on compromised endpoints, functioning as separate access channels (Huntress 2026). The RMM tools use whitelisted, vendor-signed binaries. Default EDR configurations do not flag them. An IR process that identifies and removes the Havoc payload has removed one channel. The other remains open.

Standard incident response runbooks focus remediation on identified malicious artefacts. Vendor-signed RMM binaries are typically treated as legitimate unless a specific instance is explicitly flagged. Default EDR configurations rarely alert on DLL sideloading from signed binaries, which falls under MITRE ATT&CK technique T1574. They also typically miss anomalous registry activity under HKCU\SOFTWARE\Classes unless custom detection logic is implemented (Huntress 2026). The runbook has no step for auditing RMM installations because it was written before dual-persistence was a documented operational pattern.

The IR process closes. The ticket is resolved. The attacker holds an active access channel through a whitelisted binary. This is a defined failure mode, documented in confirmed incidents, not a theoretical edge case. The operational danger is not that the attacker is still present. It is that the organisation has formally certified they are not.

Two actions address this. First, after any Quick Assist or vishing-related incident, extend remediation scope to a full audit of RMM tool installations across affected and adjacent endpoints, and do not close the incident until that audit is reconciled against an authorised baseline. Second, build a DLL sideloading detection query for scheduled threat hunting against signed legitimate binaries, run weekly. Real-time alerting on DLL sideloading without significant tuning investment will produce unmanageable volume; scheduled hunting is the practical entry point. Both actions require an authorised RMM baseline to exist. If it does not, building it is the prerequisite.

Tactical Adjustments by Timeframe

Three gaps, each are addressable without new budget if the decision is made.

This Week

Issue a standing instruction to helpdesk staff: escalate any call requesting Quick Assist or remote access. Do not handle it. Define the escalation path and distribute it this week, before process redesign is complete. This closes the most immediate exposure with zero tooling dependency.

Verify that Microsoft Defender for Office 365 mail-flow alerting is routing anomalous volume events, including potential mail bombing patterns, to the SIEM rather than only junking or throttling at the mailbox level (Microsoft 2025). If the environment is not licensed for Defender P2, automated investigation and response capabilities will be absent. Flag that gap explicitly.

Brief SOC analysts: inbox flooding is an attack precursor, not a spam ticket. When a user reports sudden flooding, open a threat inquiry. Do not close it as a spam resolution. This requires no tooling and no budget.

This Quarter

Design and document a callback verification procedure. Pilot with highest-risk roles: finance, executive assistants, and HR. The procedure: hang up, locate the verified internal directory, call back on that number only. This requires IT operations process redesign and generates helpdesk friction. That friction is the cost of closing Gap 1.

Build a per-user email volume anomaly alert in the SIEM, independent of individual message classification. Calibrate threshold selection to per-user historical baseline, with the trigger as an anomaly relative to individual volume, not a universal figure. Tune per user over 30 days. Expect false positives from high-volume accounts until individual thresholds are adjusted.

Run a live voice-based tabletop exercise modelling this attack scenario. Do not use a phishing simulation: phishing simulations test asynchronous decisions, not voice pressure compliance (Huntress 2026). Test whether the callback procedure holds under real-time pressure. If it does not, redesign before deployment.

6-12 Months

Restrict Quick Assist and AnyDesk on high-risk endpoints via Group Policy or MDM enforcement (Huntress 2026). Define a documented exception process requiring explicit authorisation rather than a blanket whitelist. Expect helpdesk friction where remote access tools are embedded in current support workflows.

Build a DLL sideloading detection query for the EDR platform targeting sideloading from legitimate signed binaries, referencing MITRE ATT&CK T1574. Deploy as a scheduled weekly hunt, not a real-time alert rule. Real-time DLL sideloading alerts without tuning investment will generate unmanageable volume. Weekly triage is the practical entry point.

Audit all active RMM tool installations and build an authorised baseline: what is installed, on which endpoints, and authorised by whom. This is the prerequisite for Gap 3 remediation. Without it, partial remediation goes undetected. It requires IT operations time and cross-team coordination, not security team effort alone.

How to Frame This Internally

Ask your helpdesk lead this question today: "If a user calls saying they are being flooded with emails and then gets a call from someone claiming to be IT support, what do you do?" The answer tells you whether the operational gap is real in your organisation.

On training: "Training tells employees what not to do. This attack removes their ability to execute that instruction under real-time pressure."

Phishing targets a click, a decision made alone, without time pressure. This attack targets a conversation. Existing controls were not designed for a synchronous, real-time compliance trigger, and the incident record confirms they do not perform as if they were (Huntress 2026; Sophos 2025).

On detection: "Inbox flooding is not a spam event. It is a pre-attack conditioning sequence. Your SOC should know about it before the phone rings."

The three countermeasures in this article require process redesign and decisions. They do not require a technology purchase. The barrier is not budget.

On remediation: "Partial remediation in this scenario is not a safe outcome. The attacker planned for it."

What to Watch Next

The email bombing, vishing, and Quick Assist playbook is now confirmed across Black Basta, 3AM, Cactus, and Lynx ransomware families, documented across Sophos, Microsoft, and Huntress research (Sophos 2025; Microsoft 2024; Huntress 2026). The technique can be traced back to at least April 2024 (Microsoft 2024). Its adoption across multiple ransomware families indicates that it has been evaluated and retained across independent operations. The risk is not contingent on any single group remaining active.

Watch for Havoc C2 indicators in EDR telemetry: specifically DLL sideloading from signed binaries, indirect syscall patterns, and anomalous HKCU\SOFTWARE\Classes registry activity (Huntress 2026). Treat any unauthorised RMM tool activity on endpoints following a user-reported inbox flooding incident as a potential persistence channel, not an IT anomaly. Monitor threat intelligence sources for further ransomware affiliate adoption of this playbook beyond the four families currently confirmed.

The three gaps identified here will still be open in six months without a decision. They require decisions, not products.

Special thanks to Coursera for supporting today’s content.

Brought to by the CyOps Consulting Team. Discover our most recent publication.