Who makes the security decision in a help-desk impersonation attempt?
When an impersonator calls the real help desk, the agent decides whether to change an account. When fake IT contacts an employee, the employee decides whether to grant a permission or follow a request. Each workflow needs its own verification and reporting route.
Vishing means voice-based phishing. For this article, “inbound” means a call arriving at the real help desk; “fake IT” means an impersonator contacting an employee.
The joint FBI, CISA, and international Scattered Spider advisory describes both patterns: impersonating employees to obtain help-desk password or multifactor authentication (MFA) changes, and impersonating IT staff to obtain credentials or induce other actions. The July 2025 update covers investigations through June 2025. Joint advisory: Overview
Direction one: the impersonator calls the real help desk
Here the help-desk agent possesses the authority the caller wants to use. The requested action might be an account-recovery change. The agent’s job is to establish that the requester is entitled to that change before performing it.
Mandiant’s June 2024 UNC3944 reporting describes operators impersonating employees during calls to corporate service desks and requesting password or MFA resets. The report also describes attackers possessing personal information used in identity-verification processes. Mandiant: UNC3944 Targets SaaS Applications, TTPs
The caller verification guide covers the recovery procedure. When choosing a service-desk exercise, put the decision into a single sentence: “May this agent replace this account’s authentication method for this requester?” Then give the agent a documented route to answer it. Include a practical escalation path for the legitimate employee who cannot complete the ordinary verification procedure.
A control that simply tells the agent to be suspicious leaves the actual recovery decision unresolved. Specify who may authorize an exception and what evidence they need. Keep the pending account change on hold while that decision is made.
Direction two: fake IT contacts the employee
In this direction, the impersonator claims authority rather than asking a real agent to exercise it. The employee is the person being asked to do something consequential. That could be approving an application or following an authentication request.
GTIG’s June 2025 UNC6040 reporting describes attackers impersonating IT support and persuading employees to authorize a malicious Salesforce connected application, often a modified Data Loader. The report attributes the observed intrusions to social engineering rather than a Salesforce vulnerability. GTIG: The Cost of a Call, Introduction
For an employee exercise, name the requested action. “Verify an unexpected request before approving an application” is a clearer objective than “spot a scam call.” Give the employee an independent way to reach the real support team and identify the approved task.
Two directions of impersonation
Caller claims to be an employee
- Unverified caller
Requests an account recovery change.
- Real help desk
Verifies the requester and authority before changing access.
Caller claims to be IT
- Unverified caller
Requests app approval or remote access.
- Employee
Verifies the helper and task through the established support route.
Independent workflows. If verification is unresolved, pause and use the approved escalation route.
Compare the decisions side by side
| Question | Caller impersonates employee | Caller impersonates IT |
|---|---|---|
Who is being persuaded? |
Real help-desk agent |
Employee |
What authority is sought? |
Agent’s account-change capability |
Employee’s approval or action |
What must be verified? |
Requester’s entitlement to recovery |
Support request and requested action |
Where should uncertainty go? |
Authorized recovery escalation |
Independently contacted support team |
What should the exercise observe? |
Whether an unverified account change occurs |
Whether an unverified action is performed |
This table is a planning comparison. Adapt its escalation routes to your actual organization before using it in training.
Make both reporting routes usable
The employee should know how to pause and report an unexpected task. The desk should know how to investigate without accepting the original caller’s assertions as established facts. Resolve unavailable contacts, unclear exception policies, and missing application owners before an urgent request exposes the gap.
When testing, keep the criteria separate: the desk must hold an unverified recovery request, and the employee must confirm an unexpected support task through an established channel. A result in one direction does not establish how the other performs.
