The call was clean. The caller identified as an IT employee locked out of their account, knew the employee ID, spoke without an accent, and gave the help desk agent no reason to hesitate. The agent reported nothing suspicious. Underneath the call, five signals said otherwise: an active VPN, round-trip latency inconsistent with the claimed US location, a VoIP calling number, failed contextual verification beyond the static employee ID, and an SMS verification link sent to the caller’s phone that was opened from a desktop browser instead.
Any one of those has an innocent explanation. All five at once do not. The reset was blocked.
That call is Case 1 in imper.ai’s new Q2 2026 threat research brief, Case Files from the Help Desk: A Month of Vishing. The brief covers a single month of an ongoing deployment at a retail enterprise with roughly 16,000 employees: 450 password reset attempts reviewed, multiple incidents flagged, three highlighted because each demonstrates a distinct detection pattern.
Why the help desk keeps getting picked
Voice phishing was the number one initial infection vector for cloud compromises in Mandiant’s M-Trends 2026 reporting, and the shape of the attack explains why. The help desk exists to help people who cannot authenticate. That makes it the one workflow where an attacker is supposed to show up without credentials. The control at that moment is a security question, a phone number on file, or an agent’s judgment, and social engineering is purpose-built to beat all three. CrowdStrike’s 2026 Global Threat Report found 82 percent of detections in 2025 were malware-free. The attacker is not breaking in. The attacker is calling in.
Three patterns, one workflow
The three highlighted cases do not share an attacker profile. They share the password reset workflow, and together they map the detection problem.
Case 1 is the single anomalous call described above: five independently explainable signals with no benign explanation in combination. Pattern hypothesis: moderate to high confidence alignment with Scattered Spider-style help desk tradecraft. A pattern match, not an attribution.
Case 2 is two calls, days apart, claiming the same employee from completely different infrastructure: different device, location, ISP, and phone number. Each call alone looked routine. The pattern only exists when reset attempts are linked by claimed identity across time.
Case 3 is the inverse, and the highest-risk event of the month. A reset attempt for one employee failed contextual verification. Hours later, a reset attempt arrived for a different employee, from the same environment, providing the same phone number. One environment claiming one identity and failing a question is unremarkable; people forget things. One environment claiming a second identity within hours has no plausible benign explanation. It was escalated to the highest risk score.
Cases 2 and 3 are mirror images. One held the identity constant while the infrastructure changed. The other held the infrastructure constant while the identity changed. A help desk evaluating each call as an independent event sees neither.
Voice analysis is the wrong control for this
A natural instinct is to point AI at the call itself: analyze the voice, catch the deepfake, score the audio. Two problems. First, none of these three cases needed a synthetic voice. Case 1’s caller was, by the agent’s own account, unremarkable to listen to. Attackers with fluent operators do not need generative audio, and voice analysis has nothing to find. Second, where synthetic voice is in play, detection is a probabilistic race against a generative curve that improves every quarter.
Infrastructure does not have that problem. Latency is physics; a VPN exit node cannot shorten the round-trip time to the caller’s actual location. A verification link opened on the wrong device class is a binary fact. An environment reappearing under a second employee’s name is a correlation, not a judgment call. None of it gets harder to detect when a better audio model ships. imper.ai does not analyze call content or voice at all, and every flag in this brief came from the signals underneath the call.
The window is before the reset, and across sessions
A completed reset hands the attacker legitimately issued access: no anomalous login, no malware, nothing for the downstream stack to catch. The detection window is during verification, before the reset executes. And as Cases 2 and 3 show, the window is wider than one call: reset attempts need to be correlated by claimed identity across time and by environment across claimed identities, in both directions.
imper.ai for help desks runs that verification inside the reset workflow itself, correlating network, device, identity, and channel signals on every attempt and across attempts, before an agent’s judgment is the last line.
The full case files, TTP mappings, and detection guidance are in the Q2 2026 threat research brief.
imper.ai Threat Research | Q2 2026. Each case is presented as a hypothesis about attacker behavior with confidence stated per case. imper.ai does not claim definitive attribution absent additional corroborating intelligence.
