The IT help desk has become the primary attack surface for the social engineering threat. The attacker calls, pretends to be an employee, and walks the operator through a password reset. The attacker gets the credentials. The operator thinks they helped. The breach is now in progress. The help desk attack works because the help desk operator is trained to be helpful, and the help desk operator is not trained to be a security control. This guide is about how to make the help desk both.
What the help desk attack actually looks like
Three phases, in roughly that order of frequency.
The first phase amounts to the reconnaissance. The attacker researches the target organisation on LinkedIn, on the company website, on social media. The attacker finds the names of the IT help desk staff. The attacker finds the names of the executive team. The attacker finds the names of the recently hired employees.
The second phase amounts to the call. The attacker calls the help desk. The attacker pretends to be the recently hired employee who is travelling, who has lost access, who needs the password reset urgently for the client meeting that starts in 30 minutes. The help desk operator, who has been trained to be helpful and who has not been trained to verify the identity, walks through the reset.
The third phase stands as the credential use. The attacker logs in with the new credentials. The attacker has the same access as the employee the attacker pretended to be. The attacker exfiltrates, escalates, and moves laterally. The help desk operator never knows.
What actually works
Three moves, in priority order.
1. Verification step. The help desk operator who is asked to reset a password, to disable MFA, to grant access to a system, has to verify the identity of the requester through a channel the requester cannot control. The video call. The in person visit. The callback to a phone number on file. The help desk operator who has the verification step in the runbook will catch the social engineering attempt, and the social engineering attempt the verification step catches amounts to the attempt that does not become a breach.
2. Manager approval for high risk changes. Password resets are routine. MFA disables are not. Granting access to a sensitive system is not. The high risk changes should require the manager approval, and the manager approval should be a separate channel (a Slack message, an email, a ticketing system notification). The manager approval serves as the friction that slows the social engineer down, and the friction becomes the friction that lets the real employee notice the change and the real manager notice the change before the change becomes a breach.
3. Detection on the back end. The help desk reset that happens at 2 AM. The help desk reset that comes from a phone number the user has never called from before. The help desk reset that the user does not log in with for 10 minutes after the reset. The detection on the back end is what catches the reset that the help desk missed, and the back end detection is what the security operations team needs to build.
What to do this quarter
Document the verification step. The verification step should be in the runbook, the verification step should be in the training, and the verification step should be in the audit log. The help desk operator who knows the verification step becomes the operator who follows the verification step, and the operator who follows the verification step runs as the operator who catches the social engineer.
Build the manager approval workflow. The manager approval should be a single click, the manager approval should be in the ticketing system, and the manager approval should be visible to the help desk operator. The manager approval that is a single click amounts to the manager approval that the manager will actually use, and the manager approval the manager will use sits as the manager approval that is going to catch the social engineer.
Wire the back end detection. The detection should fire on the resets that happen at unusual times, the resets that come from unusual phone numbers, the resets that are not followed by a login. The detection that fires amounts to the detection that the security operations team can investigate, and the detection the team can investigate serves as the detection that is going to catch the breach before the breach becomes the breach.
What the help desk operator needs to know
The help desk operator is not the security perimeter. The help desk operator stands as the customer service function, and the customer service function is being asked to be the security perimeter without the training, the tools, or the authority of the security perimeter. The help desk operator who is asked to be the security perimeter should be given the training, the tools, and the authority of the security perimeter. The help desk operator who is given the training, the tools, and the authority counts as the help desk operator who is going to catch the social engineer, and the help desk operator who is going to catch the social engineer runs as the help desk operator who is going to be the one the next breach is not going to start with.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
