Case Files from the Help Desk: A Month of Vishing (Q2 2026)

July 16, 2026

by imper.ai

TL;DR/ Executive Summary

ThreatCoordinated vishing attacks targeting help desk password resets
Customer profileRetail enterprise, approximately 16,000 employees, spanning a large field workforce and corporate knowledge workers
Detection windowOne month of an ongoing deployment, Q2 2026
Volume reviewed450 password reset attempts within the one-month window
Cases highlighted3, drawn from a larger set of flagged incidents
TTPs observedImpersonation, spearphishing voice, proxy and VPN masking, VoIP identity artifacts, device and channel mismatch, cross-session infrastructure reuse across claimed identities
Attribution confidenceStated per case. No case asserts confirmed attacker identity.
MITRE ATT&CKT1656 · T1566.004 · T1090 · T1090.003

imper.ai runs continuously at the IT help desk of a retail enterprise with approximately 16,000 employees, spanning a large field workforce alongside corporate knowledge workers. The statistics in this brief cover a single month of that ongoing deployment in Q2 2026, during which 450 password reset attempts were reviewed and multiple incidents were flagged for signal combinations consistent with vishing and coordinated social engineering tradecraft. Three of those incidents are highlighted here, selected because each demonstrates a distinct detection pattern.

Each case in this brief is presented as a hypothesis about attacker behavior, not a confirmed finding. Detection confidence, the strength of the signal correlation that triggered review, is high in all three cases. Confidence in the underlying attack pattern varies by case and is stated individually rather than applied as a blanket assessment.

This brief documents the observed tactics, techniques, and procedures (TTPs), maps them to published tradecraft where a direct match exists, and provides detection guidance for security teams responsible for protecting the account recovery workflow.

Threat Background: Why the Help Desk Is the Easier Way In

The IT help desk exists to remove friction from account recovery. That design goal is also the exposure. Gartner’s own service desk research puts password resets at roughly 12 percent of all calls to internal IT service desks, with a further 34 percent concerning system access. A caller who cannot authenticate through normal means has to be trusted through something else: a security question, an agent’s judgment, or a phone number on file. Attackers have learned which of those three is weakest.

Voice phishing became the second most common initial infection vector overall in 2025, and the fastest growing, according to Mandiant’s M-Trends 2026 report. CrowdStrike’s 2026 Global Threat Report goes further for one named cluster: Scattered Spider, also tracked as UNC3944 and Octo Tempest, relied on social engineering of help desk personnel to trigger self-service password resets throughout 2025, gaining access to cloud and single sign-on accounts without deploying malware in the large majority of cases. Eighty two percent of the detections CrowdStrike tracked in 2025 were malware-free, up from 51 percent in 2020. The attacker is not breaking in. The attacker is calling in.

The pretext does not require technical sophistication. It requires reconnaissance and a plausible reason to ask for help. Public reporting on the 2023 MGM Resorts breach describes an attacker identifying an employee on LinkedIn and social-engineering a password reset in a single call, at an estimated cost to MGM of more than 100 million dollars. The same shape reappears across the Caesars Entertainment and Marks & Spencer breaches: a call, a pretext built from reconnaissance, and a help desk agent whose job is to be helpful.

The cases in this brief were surfaced at a help desk that had already deployed signal-based verification underneath the agent’s process, catching what agent judgment and a phone number on file would not have caught alone.

Observed TTPs

The following tactics, techniques, and procedures (TTPs) were observed across the three cases in this brief. Each is documented in the referenced published research; imper.ai’s findings represent independent corroboration inside a live help desk environment, not a novel technique.

Impersonation of a Trusted Employee (T1656)

All three cases opened with the same move: the caller claimed to be a specific, real employee rather than an anonymous requester. In Case 1, the claimed identity was an IT staff member locked out of their own account, a pretext that leans on the informal trust extended between IT colleagues. Impersonation of this kind is typically preceded by reconnaissance: gathering a name, a role, and an employee ID from professional networking sites, breach data, or prior contact with the organization.

Spearphishing Voice (T1566.004)

Every session in this brief arrived as a live phone call requesting a password reset, not an email or a self-service portal submission. Voice channels route around email security controls entirely and put a human agent in the position of making a real-time trust decision with limited information.

Proxy and VPN Masking (T1090 / T1090.003)

Case 1 presented an active VPN alongside network latency inconsistent with the caller’s claimed US location. Latency is a physical property. A VPN exit node can make a session appear US-based, but it cannot shorten the round-trip time between a caller’s actual location and infrastructure near their claimed one.

VoIP and Virtual Phone Numbers

A VoIP number appeared in Case 1 and recurred across the cases in this brief. VoIP numbers are not inherently malicious. Combined with other identity gaps, they are one component of a low-trust identity profile rather than a standalone indicator, which is why this row carries no MITRE mapping below: the published framework has no direct sub-technique for virtual telephony used this way.

Device and Channel Mismatch

Case 1’s verification link was delivered by SMS to the phone number the caller was using, and was opened from a desktop browser rather than that phone. A caller who does not access a phone-bound verification channel from the phone in question does not have the physical control over that number the channel is designed to confirm.

Cross-Session Infrastructure Reuse Across Claimed Identities

Case 3 presented the same environment and the same phone number in reset attempts for two different employees, hours apart, after the first attempt failed contextual verification. Identity rotation from a stable operating environment is consistent with an operator working through a target list, and was escalated to the highest risk score. The published framework has no direct technique for this correlation, so it carries no MITRE mapping below.

TTP Summary

TTPMITRESignalCase(s)
Impersonation of a trusted employeeT1656IT-employee pretext, built on a researched employee IDCase 1
Spearphishing VoiceT1566.004Live phone call requesting a password resetCase 1, 2, 3
Proxy / VPN maskingT1090 / T1090.003VPN active; latency inconsistent with claimed locationCase 1
VoIP / virtual phone numbersn/aVoIP number provided as a contact or verification numberCase 1, 2
Device / channel mismatchn/aSMS-delivered verification link accessed from a different device classCase 1
Cross-session infrastructure reusen/aSame environment and phone number across reset attempts for two different employeesCase 3

“n/a” in the MITRE column indicates no direct corresponding ATT&CK sub-technique, consistent with how imper.ai’s Q1 2026 DPRK threat research handled indicators without a published mapping.

Case Observations

The three cases below are drawn from the incidents flagged during the one-month window this brief covers, at a help desk where imper.ai runs continuously. Each is presented as a hypothesis about attacker behavior, not a confirmed finding. Detection confidence, the strength of the signal correlation that triggered review, is stated separately from confidence in the underlying attack pattern, which varies case by case.

Case 1: Single-Operator, Multi-Signal Impersonation

Pretext: the caller identified as an IT employee who had lost their password, requesting a reset by phone. A common vishing pretext, and one that leans on the informal trust between IT staff to lower an agent’s guard.

Network signals:

  • VPN active
  • Network latency inconsistent with a US-based presence, despite a US-facing session

Identity signals:

  • VoIP phone number
  • Correct employee ID provided; contextual verification questions beyond the static identifier failed

Device and channel signals:

  • Verification link sent by SMS to the calling number; accessed from a desktop browser rather than the phone that received it

Agent-side observation:

  • The help desk agent reported nothing suspicious about the caller’s accent or delivery. Included as context only; imper.ai does not analyze call content or voice.

Detection confidence: High. No single signal here disqualifies the caller. Each has an innocent explanation. The combination does not. The caller knew a researched, static identifier but failed the dynamic contextual questions. The network signals contradicted the claimed US identity. The verification link sent to the caller’s phone was opened from a desktop browser. The agent heard nothing suspicious, and imper.ai does not analyze call content or voice. The signals underneath the call are what flagged it.

Pattern hypothesis: Moderate to high. Consistent with help desk vishing tradecraft attributed in public reporting to Scattered Spider, also tracked as UNC3944 and Octo Tempest: a researched employee ID with no deeper contextual knowledge, an IT-staff pretext, and a caller the agent found unremarkable. A pattern match, not an attribution.

case1-signal-correlation.png, provided alongside this file. Alt text suggestion: "Diagram of five signals detected on a single help desk vishing call, VPN active, latency mismatch, VoIP phone number, failed contextual verification, and an SMS verification link opened from a desktop browser, correlating across network, identity, device, and channel into a flagged session and blocked password reset."

Case 2: Multi-Touch, Divergent Infrastructure

Sessions:

  • Session 1: a password reset attempt for a claimed employee identity, from one device and location.
  • Session 2, several days later: a password reset attempt for the same claimed identity, from a different device, a different location, a different ISP, and a different phone number provided by the caller.

Detection confidence: High, on the correlation itself. Each session, evaluated alone, is defensible. A different device could be a new phone. A different ISP could be travel or a change of home internet provider. A new phone number is something people legitimately update. None of these, taken individually, clears a normal suspicion threshold. What ties the two sessions together, and what a point-in-time verification check has no way to see, is that both claim the same identity within days of each other while sharing no infrastructure in common.

Pattern hypothesis: Low to moderate. No single explanation is confirmed. Candidates considered:

  • Reconnaissance, then attack. A first touch gathers what the verification flow asks for; a second touch, days later, executes with that intelligence from a cleaner environment. This shape is documented in independent incident response reporting on Scattered Spider-style intrusions, where self-service reset reconnaissance from one environment preceded an account phone number change and reset from a second.
  • Distributed operation. A crew with enough operator volume can work a target more than once, each attempt carrying its own device and infrastructure profile.
  • Resale. The underlying identity details change hands between two buyers unrelated to each other, days apart.

No signal beyond this meta-pattern, the identity claim held constant while the infrastructure did not, is available for this case. That absence is worth stating plainly rather than working around: a thinner evidence base means a lower-confidence hypothesis, not a stretched one.

Case 3: One Environment, Two Claimed Identities

Sessions:

  • Session 1: a password reset attempt for a claimed employee identity. Contextual verification questions failed. The reset was denied.
  • Session 2, a few hours later: a password reset attempt for a different employee. The session presented the same environment as Session 1, and the caller provided the same phone number.

Detection confidence: High. Unlike a timing-only correlation, the link between these two sessions is directly observed: the same environment and the same phone number, hours apart, attached to reset requests for two different employees. One environment claiming one identity and failing verification is an unremarkable event on its own; people forget things. One environment claiming a second, different identity within hours has no plausible benign explanation. The session was escalated to the highest risk score on that basis.

Pattern hypothesis: Moderate to high. The leading hypothesis is a single operator working through a target list: an attempt against one employee fails at contextual verification, so the operator moves to the next name rather than retrying the first. Rotating target identities after a failed attempt, while reusing the same operating environment, is consistent with how vishing crews documented in public reporting work a victim organization at volume. Stated as a hypothesis: the identity-rotation read is strongly supported by the observed reuse, but the operator’s affiliation and broader campaign context are not established.

Cases 2 and 3 are mirror images. Case 2 held the claimed identity constant while the infrastructure changed. Case 3 held the infrastructure constant while the claimed identity changed. Neither pattern is visible to a help desk evaluating each call as an independent event; both only exist across sessions.

Assessment

The three cases in this brief do not share a single attacker profile the way the four candidates in imper.ai’s Q1 2026 DPRK threat research shared a consistent tradecraft signature. They share a workflow, the IT help desk password reset process, and a common vulnerability: an agent’s judgment is the control, and an agent’s judgment is exactly what social engineering is built to defeat.

Confidence varies by case because the evidence varies by case, and this brief states that plainly rather than flattening it to a single number.

CaseDetection confidencePattern hypothesis confidenceLeading hypothesis
1HighModerate to highScattered Spider-style single-operator vishing
2HighLow to moderateRecon-then-attack, distributed operation, or resale; unconfirmed
3HighModerate to highSingle operator rotating target identities from one environment

What the three cases demonstrate together, more than any one of them alone, is that a single point-in-time verification check misses two of the three patterns entirely. Case 1 would likely have been caught, or missed, on the strength of one call. Case 2’s two sessions would each have looked unremarkable in isolation; only linking them by claimed identity across days surfaces the pattern. Case 3’s second session, arriving as a routine reset request for a different employee, only becomes the highest-risk event of the month when someone is correlating environment and phone number across sessions and notices one caller claiming two identities.

Attribution confidence is stated per case above. imper.ai does not claim definitive attribution for any of the three cases absent additional corroborating intelligence.

Detection Guidance

The following is intended for security practitioners and teams responsible for the help desk account recovery workflow.

 detection-workflow.png, provided alongside this file. Alt text suggestion: "Workflow diagram of the help desk password reset process from call received through verification, reset decision, and access restored, with the verification stage highlighted and five observable signals listed: VPN and latency mismatch, VoIP number, device and channel mismatch, contextual verification failure, and cross-session environment reuse."

Channel possession, not just channel delivery: Sending a verification link to a phone number on file confirms the number exists. It does not confirm the caller is holding that phone. Flag sessions where a phone-bound verification channel is accessed from a device class inconsistent with a phone, and treat self-reported phone numbers, especially newly provided ones, as unverified until corroborated.

Latency and network proximity: Where feasible, implement network proximity or BGP-level origin checks against a caller’s claimed location. Latency is a physical property that VPNs cannot fully obscure: an exit node can make a session appear US-based, but it cannot shorten the round-trip time between a caller’s device and infrastructure near their true physical location.

Cross-session correlation, in both directions: Link password reset attempts by claimed identity across time, and link them by environment and phone number across claimed identities. Case 2 in this brief was only visible in the first direction: one identity, divergent infrastructure, days apart. Case 3 was only visible in the second: one environment and one phone number, two different employees, hours apart. A help desk evaluating each call as an independent event sees neither. A failed verification should also raise the baseline risk of subsequent attempts sharing that session’s environment or contact number, regardless of which employee they claim.

Signal correlation is necessary: No single indicator in this TTP set is sufficient for a confident assessment. Detection requires correlating device, network, identity, and channel signals simultaneously. Organizations relying on agent judgment or a callback number as the primary control will not surface the indicators described in this brief.


References

  1. Gartner, G00842004, “Protect Your IT Service Desk Against Social Engineering Attacks,” Akif Khan and James Hoover (January 2026)
  2. Mandiant / Google Cloud, M-Trends 2026 (2026) https://cloud.google.com/security/resources/m-trends
  3. CrowdStrike, 2026 Global Threat Report (February 2026) https://www.crowdstrike.com/en-us/global-threat-report/
  4. CrowdStrike, “Scattered Spider Escalates Attacks Across Industries” (2025) https://www.crowdstrike.com/en-us/blog/crowdstrike-services-observes-scattered-spider-escalate-attacks/
  5. Obsidian Security, “Behind the Breach: Scattered Spider SaaS Attack Analysis and MITRE ATT&CK Mapping” (2025) https://www.obsidiansecurity.com/blog/scattered-spider-saas-attack-analysis
  6. MITRE ATT&CK, T1656 (Impersonation), T1566.004 (Spearphishing Voice), T1090 / T1090.003 (Proxy), T1078 (Valid Accounts) https://attack.mitre.org