Why attackers call instead of hack
Multi-factor authentication substantially raises the cost of a technical attack — which is exactly why so many attackers have shifted to a much simpler approach: calling an employee, claiming to be internal IT, and asking them to simply provide or approve the thing MFA was supposed to protect. No firewall, password policy, or endpoint protection tool stops an employee who's been convinced to read out a one-time code to a caller who sounds entirely legitimate.
The two requests that matter more than anything else
- Reading out or approving an MFA code/push notification. No legitimate IT support process ever requires you to relay a one-time code you didn't request, or approve a push notification for a login attempt you didn't initiate. If either happens, treat it as an active attack in progress, not a technical support request.
- Installing remote-access software at the caller's direction. An unverified caller asking you to install a remote-access tool — especially one your organization doesn't already use as standard — is requesting the single most direct path to full device or account compromise available to them.
Why "they knew a lot about our systems" isn't proof of legitimacy
Attackers researching a target organization can gather a surprising amount of accurate internal detail — team names, software in use, even specific employee names — from public sources, previous breaches, or earlier reconnaissance calls. Knowing internal details is not the same as being internal IT, and shouldn't substitute for actual verification.
The verification that actually works: check your own system
Before complying with any unsolicited IT request, check your organization's own ticketing system for a matching ticket, or call your IT department back using a number from your company directory — never a number the caller provides. This single step defeats help-desk impersonation regardless of how convincing the caller sounds, because it removes the attacker's control over the verification channel.
Watch for the extra ask layered onto a normal request
Some of the most effective help-desk impersonation attempts start with a genuinely normal-sounding request and add the real compromise attempt as a smaller, secondary ask partway through — "while I have you, can you also just confirm the code that just came through." Treat any late-added request for a code or credential with the same scrutiny as if it had opened the call.
Report it even when nothing goes wrong
An unsuccessful help-desk impersonation attempt is still worth reporting to your security team. A single blocked attempt is useful information; a pattern of similar attempts across an organization can indicate a targeted campaign worth actively defending against, not just an isolated incident.
Frequently Asked Questions
No legitimate IT support process ever needs you to relay a one-time code or approve a push notification for a login you didn't initiate — MFA exists specifically to prevent someone else from accessing your account even if they have your password. A request to bypass it this way should be treated as an active attack, not a routine support request.
Not necessarily. Attackers can gather accurate internal details — team names, software in use, specific employee names — from public sources, prior breaches, or earlier reconnaissance calls. Knowing internal information isn't the same as being internal IT, and shouldn't replace actual verification through your own ticketing system or directory.
Check your organization's own ticketing system for a matching ticket, or call your IT department back using a number from your company directory — never a number the caller themselves provides. This removes the attacker's control over the verification channel entirely.
Yes. A single blocked attempt is still useful information for your security team, and a pattern of similar attempts across your organization can reveal a targeted campaign worth actively defending against, rather than treating each incident as isolated.
Yes — the Help Desk Impersonation Verification Checklist is an 11-point weighted checklist that puts the heaviest weight on MFA-code requests and remote-access installation, producing a live 0-100 risk score before you comply with any request.