Help desk social engineering: the password reset procedure

Social engineering aimed at the help desk consists of convincing a technician to reset a password or a second factor for someone who is not the account holder. The defense comes down to one rule: no reset without identity verification through a channel the caller does not control.

This article describes a typical call and explains why support is a prime target. It details the verification procedure to apply, with the sentences to say.

Why is the help desk a prime target?

A help desk exists to help quickly. Its quality indicator is often resolution time, and its culture is one of service. That is exactly what an attacker exploits.

Resetting a password or a second factor is also one of the few operations that give direct access to an account. Instead of forcing a technical defense, the attacker politely asks a person to bypass it.

The technician sees dozens of requests a day, from colleagues in a hurry, sometimes away from their desks. An urgent call from a “user” who has lost their phone looks ordinary. The attacker counts on that ordinariness.

What does a social engineering call to support look like?

Picture a call late in the morning. The caller introduces himself as a sales manager on the road. He has lost his phone, so he no longer has his second factor, and he has to send a proposal before noon.

The scenario often follows the same steps:

1. The credible pretext: a lost phone, a trip, an imminent presentation.
2. Information already known: name, job title, manager, project name, found on professional networks or the company website.
3. Urgency: “My client is waiting, I can’t stay locked out.”
4. Pressure on the person: irritation, flattery (“you’re the only one who can help me”) or a reference to a superior.
5. A request that seems small: “Just reset my password, I’ll handle the rest.”

Each step is a lever described in the article on the psychological levers of social engineering. None is technical: everything is played out in the conversation.

Why are classic verification questions not enough?

Many help desks verify identity with questions: date of birth, employee number, manager's name, office address. This information is often public or easy to find, or has already leaked elsewhere.

A question whose answer can be found online proves nothing. It only gives the technician the feeling of having checked. That feeling is precisely what the attacker is after.

The subject is detailed in the article on the questions to verify a caller's identity. For a help desk, the conclusion is clear: verification must rest on an element the caller cannot guess or obtain alone.

What procedure should you apply before resetting anything?

A good procedure is written, short, and does not depend on the judgment of the technician on duty. Here is a base that each organization adapts to its context.

1. Do nothing during the call. The request is noted, not executed.
2. Call back through an independent channel: the number in the internal directory, not the caller's. See the callback procedure.
3. Use a second means of proof: a link sent to the work address already on file, or approval by the manager through their usual channel.
4. Require physical presence or a video call with ID for sensitive accounts: executives, finance, administrators.
5. Keep a record of the request: time, number, name announced, result of the verification.

For a second factor that is being reset, the level of proof must be at least as high as for a password. An attacker who obtains both controls the whole account.

What sentences can the technician say without causing offense?

The technician does not have to justify themselves. They apply a rule that is valid for everyone, including management. Saying that the rule applies to all reduces friction.

• “For your security, I don’t reset anything by phone. I’ll call you back on your registered line.”
• “I’m going to send you a link at your usual work address.”
• “The rule is the same for everyone, including management.”
• “I understand it’s urgent. I can’t make an exception.”
• “I’m passing your request to my manager. You’ll get an answer quickly.”

If the caller becomes aggressive or invokes a superior, the answer does not change. To hold firm against insistence, the method for saying no under pressure applies word for word.

Which signals should alert the technician?

No single signal proves fraud. It is their accumulation that counts, and above all the gap with what you would expect from a real user.

• An urgency tied to a specific event: trip, client, presentation, inspection.
• A hidden or foreign number, or one different from the directory's.
• A reluctance to be called back: “I have no signal, do it now.”
• A request to reset the password and the second factor in the same call.
• Insistence on receiving the new password orally, or at another address.
• Surprisingly precise knowledge of the organization, mixed with ignorance of details the user would know.

The most reliable indicator remains the gap in behavior: a real colleague accepts being called back, an attacker tries to stay on the line.

What happens if a reset has already taken place?

Sometimes the doubt comes afterwards. The technician remembers an odd voice or a detail that did not fit. You then need to act without delay, without trying to find out who is at fault.

1. Alert the security officer immediately, stating the time of the operation.
2. Have open sessions revoked and access reset again, through a verified route.
3. Contact the real account holder through their usual channel.
4. Record the call: number, name announced, requests, what was done.

Saying quickly “I think I made a mistake” is a professional quality. A culture that punishes that admission makes incidents longer and more costly.

How can management protect the help desk?

A technician who refuses a legitimate request must not be punished. If they fear the reproaches of a manager in a hurry, they will end up giving in. The rule only holds if it is publicly backed at the top of the hierarchy.

In practice, you need to:

• announce to everyone that every reset requires verification;
• make clear that this is not a lack of trust;
• give support the explicit right to escalate without justification;
• measure resolution time without penalizing verifications;
• provide a fast route for real emergencies, also verified.

Without this backing, the procedure is bypassed at the first pressure from a manager in a hurry.

How do you train a support team to hold to the procedure?

A procedure read in a document is lost under pressure. What holds is the habit repeated aloud: do not execute, say the sentence, call back. This reflex is built by practice, not by a module to click through.

With a role-play, the technician takes a call from a persona who has lost their phone and is growing impatient. They must verify, refuse, then escalate. A Face Up trainer writes the scenario from the real cases of their organization's support team. After the session, the debrief shows whether the verification took place and what was given away. The technician can then play again.

This approach is part of the guide to security awareness training and vishing.

Frequently asked questions

Should a reset by phone always be ruled out?

It is possible if verification rests on an independent channel and an element the caller does not control. Without that, it is better to use a link sent to an address already on file. The choice depends on the sensitivity of the account.

What if the caller says they are the CEO?

Apply the same procedure. Say: “I’ll call you back on your usual line.” A real executive approves this rule. If the call is fraudulent, the callback ends the attempt.

Should a failed attempt be reported?

Yes. An attacker who fails on the first call often tries another colleague. Reporting allows the team to be warned. The checklist of information to retain helps do it in two minutes.

Want to see how a trainer builds a scenario for their help desk? Book a Face Up demo.