When the Help Desk Becomes the Way In
A convincing caller can turn an ordinary support request into access to a real employee account. The critical control is the process for proving identity before changing a password, replacing an authenticator, or granting temporary access.
BlackSight Team
Offensive security & threat analysis
Updated
The recovery process is part of your security boundary
Account recovery changes who can prove control of an identity. If a caller can persuade support staff to replace that proof, strong sign-in settings may offer little protection afterward. Google's July 2025 analysis of UNC3944 described employee impersonation at the help desk as the starting point for attacks that reached critical administrative systems. Read Google's investigation.
The potential impact extends beyond infrastructure administration. In September 2025, Okta reported a separate campaign targeting recovery procedures to gain access to HR applications and change payroll details. An ordinary employee account can therefore be valuable even when it cannot administer servers. See Okta's payroll-fraud advisory.
Verify identity before changing access
Support teams need a process that survives urgency, a missing phone, and a caller who knows internal terminology. That process should not depend on the apparent seniority of the person asking for an exception. Make the escalation route explicit so a staff member can stop a risky request without having to invent an alternative under pressure.
Okta's December 2025 guidance discusses restricting front-line recovery permissions and using constrained, temporary access after identity has been verified. Where the platform supports these controls, limit the duration and context of recovery access and separate routine support from changes to privileged accounts. Recovery design also matters in passwordless environments. Read Okta's recovery guidance.
Connect the ticket to the security event
Google's investigation highlights the value of correlating password resets and new MFA enrollments with help-desk records. A ticket marked complete should not be the end of the evidence trail. The security team should be able to establish which account changed, who authorized the change, and what happened next. Review the detection recommendations.
For a planning exercise, choose a fictional employee who loses a phone while traveling. Walk through the normal route and the out-of-hours route. If a contractor answers the call, check that the same verification and escalation expectations apply. Record where ownership changes between the service desk, identity team, and security operations.
Test the workflow with clear outcomes
We recommend measuring an authorized exercise against observable steps:
- Was identity verified through the approved process before any account change?
- Was an exception escalated to someone with defined authority?
- Could the responder connect the recovery ticket to the subsequent account activity?
- Did the team know how to revoke the temporary access and confirm the account owner?
Use agreed accounts, realistic business context, and a clear stopping point. A useful outcome is a better recovery process with named owners and evidence that it works. Staff should be able to report uncertainty promptly; a campaign built around embarrassment makes that harder. BlackSight's red teaming and manual testing can scope the identity and operational checks together, with most pentests delivered on site worldwide.
Common questions
What is help-desk impersonation?
It is a social-engineering attack in which someone pretends to be an employee or support worker to obtain access or change security settings. Account recovery and authenticator enrollment are common targets.
Does MFA stop an attacker from abusing account recovery?
MFA helps protect sign-ins, but a weak recovery process can let an attacker replace the enrolled factor. Recovery and enrollment need verification strong enough for the account being changed.
How should a help-desk security exercise be measured?
Measure whether staff verify identity, escalate exceptions, record changes, and alert the security team. Use authorized scenarios and agreed accounts, and treat the results as process improvements rather than a test of individual blame.