Attackers do not always need to impersonate people. They can impersonate procedures, and most organizations have no controls designed to stop them.‍

Microsoft recently warned that attackers are now using Microsoft Teams to impersonate IT help desk staff by initiating chats, building trust, and walking employees through the steps necessary to grant remote access. It might appear to be a striking escalation, but it represents an overdue realization that the help desk is a valuable target.

Attackers understand its importance even if organizations do not. The help desk is a trusted source for information, for resolving access problems, and for authorizing changes to accounts and devices. That trust can be abused by attackers who adopt their identity. When attackers invoke the help desk role, defenders will see them as an insider: one who often has more information, access, and authority relative to the person they are contacting.

Manufactured Urgency, Stage Access

In late April 2026, Microsoft documented the steps before credentials have been harvested. Each step provides an opportunity for attackers to progress closer to their target. Each also provides an opportunity for a defender to intervene.

Step 1. Pre-Contact: Emptying the Reservoir

The attack begins before the first call. The target's inbox is flooded with hundreds or thousands of spam messages in minutes, approximately 1,000 emails in 50 minutes in one case. Sustained volume forces reactive triage, consuming working memory and displacing the deliberative processing that evaluates new information critically. This allows the attacker to begin social engineering when the employee’s defenses are at their lowest. Every technique that follows depends on this depletion.

Step 2. Identity Establishment: Wading into the Flood

While the target is managing the flood, the attacker contacts them over Microsoft Teams, presenting as internal IT support and offering to resolve the email issue. The account is external, but while they are drowning in information, it's hard to notice. They are looking for help.

The attacker is not impersonating a person. The help desk agent might know Sara from finance, and the attacker certainly does not. But they do know about roles and the power they hold.

Most social engineering attacks exploit fabricated identities: an executive, a colleague, a vendor. The help desk is different. Its authority is not vested in a single person, it is a procedural hub. Procedures are what keep organizations working. Help desks can override those procedures, making them an informal control hub.

Organizations have created help desks to be accessible to employees, to help repair broken workflows. Like security, they perform a dedicated, trusted function. The help that they offer is a blank cheque that the caller wants to repay, except they must give them their trust before they can receive the assistance.

Four social cognitive processes are at work here.

First, the email problem is the most salient feature of the victim’s environment by design. It overwhelms everything else. The availability heuristic takes over, everything else recedes.

Second, the attacker’s offer comes from an apparent authority. This is not a stranger with vague details, it is an apparent insider with a very specific request. This is congruent with an employee's mental schema: ticket numbers, known software, and escalation procedures. Using organization- and task-specific terms reinforces the request's legitimacy.

Third, the channel amplifies to the trust signal. Microsoft Teams is perceived as a protected space. Anyone inside this channel is assumed to be a trusted insider. Everything is congruent with the help desk schema. Under the typical cognitive load of a work day, warnings might be seen but are quickly dismissed.

Fourth, the offer to help closes the loop. The defender thinks they need help. They are obliged to take action on behalf of the organization. There can be no suspicion when the script is so natural. This is what help desks were created for, a formalization of indirect reciprocity that defines organizational life.

Follow-up messages were sent 29 seconds apart in some incidents. This doesn’t have the appearance of an attacker working urgently to compromise a defenders thinking. It is consistent with workplace norms. It also helps build up a sense of desperation without immediate relief.

The full chain has been completed in as little as 12 minutes. Just enough time to appear to be a legitimate offer of help, but not long enough for someone to step back and reflect on events that are ongoing.

Step 3. Credential Request: Helping Hand and Hidden Hook

The victim is now directed to a page labeled "Mailbox Repair and Sync Utility v2.1.5." It checks whether the victim is using Edge and displays a persistent warning until they switch. This isn’t terribly uncommon or unexpected, everyone knows browsers can have different capabilities. What the target does not know is that the browser check is a technical requirement for the next stage, not an IT preference. The page then presented a "Health Check" button and prompted credential entry.

This is when procedure-based impersonation becomes most apparent. The attacker is not asking the target to trust them. They are asking them to trust a process. Each element of this page is congruent with the schemas of what a legitimate IT tool looks like: a version name, a functional label, an action button, and an authentication prompt.

When provided, awareness training teaches employees to detect impostors: suspicious senders, mismatched domains, and unusual requests. It does not teach them how impersonation techniques work. A page that looks like internal IT infrastructure, reached by using a trusted channel, following steps that match their expectations of a help desk interaction would not trigger a cognitive anomaly detector.

The page rejects them once. Then again. A fake progress bar teases them. By closing the door in their face, the solution appears further away. A sense of urgency is created. By repeating the action, commitment and consistency bias takes hold. Each failed attempt is a commitment, an investment of time toward achieving a resolution. Each attempt provides a precedent, justifying the same action without further reflection.

Step 4. Invisible Installation

While the progress bar runs, the page downloads a malicious file without visibility. The script verifies a live environment, then installs a browser extension on an instance the target cannot see. By this stage, if the target has any concerns, time, or mental resources remaining, the extension is already in place. They have been carried forward from one decision point to another without realizing it.

The extension is named after a familiar system process. Institutional-sounding labels exploit the tendency to treat familiarity as evidence of authenticity. Procedural impersonation is consistent from first contact to persistence. Persistence follows silently via schedule tasks.

There are more steps in this attack, but they are not for the employee. Their job is already done, their trust exploited. Unless they have the IT competencies, there is nothing they can do.

Dismantling the Procedural Attack Surface

The help desk was created because organizations acknowledge that problems will occur and solutions need to be readily available to maintain workflows. They were designed to be a way to regain access and control fast and reliably. They were never designed to be a human firewall.

If the problem was simply that a naive employee clicked on a link, organizations could simply terminate an unqualified employee or provide more training. The problem is not a naive employee. It is a legitimate process that is followed correctly by a competent employee. When we compare the attack chain described above, the reason for its efficacy is clear: help desk agents would need to find a series of low-diagnostic cues buried within and between each task. The employee that completes the script is not making a categorical mistake. They are following a process that feels legitimate at each step. Training people to detect impostors does little to defend against a procedural attack.

Help desk agents might have access to credential reset and software install workflows, but employees don’t. How can we expect them to defend against them? Employees often come to the help desk helpless: “My manager told me to call you. They gave me a ticket number.” When they receive a callback from a help desk agent, they trust them.

If the problem has procedural roots, so does the fix. Legitimate IT processes and impersonated ones are currently indistinguishable to the person following them. Organizations invest in making their people identifiable but rarely apply the same rigor to their processes. Out-of-channel verification is used for identity, but not for processes. Workflows must also be transparent for employees.

We cannot expect employees to remember all security procedures and workflows. In situations defined by power asymmetry like help desk interactions, we must accept that employees will likely defer to the authority. If this is the case, then we need systems that can analyze calls and emails that define workflows. If we can identify anomalies in how a business transaction unfolds - which employees should be doing what - we can intervene when processes deviate from our expectations. If humans cannot do this themselves, systems can analyze conversations. Organizations should deploy conversational monitoring systems that can flag when a workflow deviates from expected patterns, turning procedural transparency into a detection control. Protecting your people requires protecting your procedures.