Social Engineering Exposed (2/3): The Helpdesk Attack

Part one covered three breaches: MGM, Odido, and Uber. Three different organisations, three different techniques, the same core problem. The attacker had credentials, hit the MFA wall, and found a person to cross it for them.

Of those three cases, the MGM approach is the one I want to look at more closely. Not because it was the largest, but because of what it actually did inside the tenant. The Odido attacker got one session. The Uber attacker got one session. The MGM attacker got a registered device. That’s a different problem entirely.

This part covers what a helpdesk reset looks like in Entra ID, why it bypasses Conditional Access completely, and why the process most helpdesks follow today is not designed to stop it.

Key Takeaways

• Attackers call your helpdesk and request an MFA reset, bypassing the need to break any technical control
• Knowledge-based authentication fails because the answers are findable before the call is even made
• In Entra ID, Authentication Administrator is the role that can delete authentication methods for non-admin accounts — in practice, IT commonly assigns this role to helpdesk staff
• Once an attacker registers their own authenticator, every Conditional Access policy requiring MFA works in their favour
• Outsourced helpdesks remove the informal verification that in-house teams often rely on without realising it

What did MGM, Odido, and Uber have in common?

All three attacks needed to get past MFA. The credentials were already obtained, through phishing, LinkedIn research, or purchase from breach markets. The remaining problem was the second factor.

Each group solved that problem differently.

At Odido, the attacker called the employee directly and asked them to approve a push notification. One call to one person. That’s all it took. At Uber, the contractor’s phone was flooded with MFA push notifications until the attacker messaged over WhatsApp, pretending to be from Uber IT, and told them to approve one to make it stop. At MGM, someone called the IT helpdesk, claimed to be an employee, and asked for a password and MFA reset.

The Odido and Uber approaches gave the attacker one session. Once the employee or contractor stopped cooperating, or the session expired, the attacker had to try again. The MGM approach was different. A helpdesk reset doesn’t give you one session. It gives you permanent access.

That’s the specific risk this article focuses on.

What made the MGM helpdesk call so effective?

In September 2023, Scattered Spider identified a real MGM employee through LinkedIn. They had a name, a job title, and enough personal detail to sound like someone the helpdesk would recognise. The call lasted about ten minutes.

The helpdesk operator asked the caller to verify their identity using knowledge-based authentication: employee ID, personal details, maybe a manager’s name. All of it was findable from LinkedIn and data breaches the attackers had already checked. The verification passed. The operator reset the password and cleared the MFA registration.

With that, the attackers logged into MGM’s Okta environment. From there, Azure. Ten days of disruption across Las Vegas properties. $100 million in total damage.

What I find striking about this case is not the scale. It’s how ordinary the call must have sounded from the operator’s side. Someone had lost access to their account. They knew their employee ID. They answered the security questions. The helpdesk did exactly what it was supposed to do.

The problem was not the operator. The problem was that the process they were following was never designed to hold up against someone who had prepared.

Why does a helpdesk MFA reset bypass Conditional Access?

This is the part worth understanding in detail.

Conditional Access policies in Entra ID check whether a login meets certain conditions before granting access. “Require MFA” is the most common condition. What those policies check is whether MFA was performed. Not by whom. Not on which device. Just whether MFA happened.

When a helpdesk operator resets MFA for an account, they remove the existing authenticator registration. The account is now unregistered. The attacker logs in with the stolen password. Entra ID prompts MFA registration because your Conditional Access policy requires it. The attacker registers their own phone.

From that point on, the attacker is the MFA factor. Every login they make triggers a push notification. They approve it themselves. Every Conditional Access policy that requires MFA sees a compliant response and grants access.

There is no alert. The account looks like a normal user who just set up a new device.

This is why the helpdesk variant is worse than what happened at Odido or Uber. The Odido attacker had access for as long as the employee’s session lasted. The MGM attacker had access for as long as the helpdesk reset remained in place. That’s a fundamentally different threat.

The helpdesk variant is different: the attacker registers their own device and keeps access indefinitely. One-session access expires. A registered device does not.

What does an attacker say to the helpdesk?

The most common pretext is straightforward: “I’ve got a new phone and I’ve lost access to my authenticator app.”

This works because it’s a real situation that every helpdesk handles multiple times a week. A new phone, a factory reset, an upgrade. The request sounds routine.

The attacker needs to pass knowledge-based authentication. Most helpdesks ask for employee ID, date of birth, a manager’s name, the last four digits of a registered phone number. None of this is secret. LinkedIn shows job title, reporting line, and tenure. Breach databases contain dates of birth and phone numbers for most adults. An attacker who has spent 20 minutes on OSINT before calling will answer every question correctly.

The “broken phone” pretext removes a common fallback. When the helpdesk says “I’ll send a code to your registered mobile,” the attacker says “I can’t access that phone, that’s why I’m calling.” The out-of-band verification option disappears. The operator now has to either deny the request or proceed with weaker verification.

What I notice in most organisations is that this scenario has never been tested. The helpdesk process was written assuming the person calling is who they say they are. Nobody sat down and asked: what does this process look like when someone has prepared for it?

Which Entra ID roles can reset MFA?

One built-in role can delete a user’s authentication methods: Authentication Administrator. It can remove registered authenticators and force a fresh MFA registration for any non-privileged user. It cannot touch accounts that hold privileged roles — a Global Administrator is protected.

Helpdesk Administrator — the role that sounds relevant — has no authentication method permissions at all. It can only reset passwords. The vector is whoever holds Authentication Administrator. In practice, that is often helpdesk staff, because IT assigns them Authentication Administrator to enable MFA resets. That assignment is where the risk sits.

Authentication Administrator is also commonly assigned to outsourced vendors who provide helpdesk services. It makes operational sense: the vendor needs to reset MFA for users who are locked out. It also means anyone who convincingly impersonates an employee when calling that vendor has a path to MFA reset across the entire non-admin user base.

Check this now: open Entra ID, go to Roles and administrators, and search for Authentication Administrator. In most tenants I review, the number is higher than the admin expected. At least one account often belongs to a third-party vendor.

Why are outsourced helpdesks more exposed?

The operator at an outsourced provider does not know your employees. They can’t recognise a voice, notice that this person always emails rather than calls, or recall a conversation from last month. Every call starts from zero.

In an in-house helpdesk, informal verification exists even without a formal policy. “I saw you in the office last Tuesday.” “Didn’t we sort out your laptop a few weeks ago?” That context disappears entirely when the helpdesk is outsourced.

Outsourced teams also tend to have higher turnover. A newer operator is more likely to follow the documented process exactly: ask for employee ID, ask for date of birth, reset. There’s less experience to draw on when something feels slightly off.

This is not an argument against outsourcing helpdesk work. It’s an observation that informal knowledge acts as a layer of verification that most organisations don’t realise they’re relying on. When that layer disappears, the formal process has to cover it. Most formal processes don’t, because they were never designed to.

The same gap exists in large in-house teams. An operator at a 5,000-person company doesn’t know most of the people they’re helping either. The problem is the process, not who runs it.

What does this look like in Entra ID?

The sequence the attacker follows:

1. They have a password, obtained via phishing, a breach database, or credential stuffing
2. They call the helpdesk and request an MFA reset
3. The helpdesk operator goes into Entra ID, opens the user’s authentication methods, and deletes the registered authenticators
4. The attacker logs in with the stolen password
5. Entra ID prompts MFA registration. The attacker registers their own device
6. Access granted, with full MFA compliance on every subsequent login

In the Entra ID audit logs, step 3 is recorded under Authentication Methods Activity as an admin action. Step 5 appears as a self-service registration by the user.

Both events are logged. Neither generates a default alert. The only way to catch this is to look for the combination: an authentication method deletion by an admin, followed quickly by a new registration from an unfamiliar device or IP, preferably with a location check against the user’s normal login pattern.

That query is not difficult to write in Log Analytics. It generates almost no false positives in normal operation. If it fires, something happened that needs immediate attention.

Frequently Asked Questions

Can Conditional Access block this attack?

Not on its own. Conditional Access checks at login time. Once the attacker has registered their own authenticator, they satisfy MFA on every login. Adding a compliant device requirement helps significantly: the attacker’s phone is not Intune-enrolled, so access is blocked regardless of MFA status. But require MFA alone does not stop this.

What is a more reliable verification method for the helpdesk?

Manager callback. Before any MFA reset, the helpdesk calls the employee’s manager using a number already in the directory, not one provided by the caller. This removes KBA entirely. To defeat it, the attacker also needs to compromise the manager. That’s a substantially higher bar.

Does Microsoft have a built-in feature for safer MFA recovery?

Yes. Temporary Access Pass (TAP) is a time-limited one-time code a helpdesk can issue. The user registers a new authenticator within a short window, typically one hour. If an attacker obtains the TAP via social engineering but cannot act in time, the attack fails. It doesn’t stop the call from being made, but it limits how long the window stays open.

Are admin accounts protected from this?

Partially. Authentication Administrator cannot reset MFA for accounts that hold privileged roles. A Global Administrator is protected. A user with SharePoint, Exchange, or finance system access who doesn’t hold a privileged Entra role is fully exposed.

How do I detect if my helpdesk has been targeted?

In Entra ID, go to Monitoring > Audit logs and filter by Authentication Methods Activity. Look for authentication method deletions followed within minutes by a new registration from an unfamiliar device or IP. If the source country doesn’t match the user’s normal location, treat it as an incident until you can prove otherwise.

The gap is not in the product

Your MFA setup is probably fine. The gap is not in the authentication system. It’s in the process that sits around it: the one that decides whether someone is allowed to remove it.

The Odido attacker got access by asking an employee to approve a push notification. The MGM attacker got it by asking a helpdesk operator to remove the push notification requirement entirely. The latter is harder to recover from.

Part three covers what a verification process that holds up actually looks like, and which Entra ID settings reduce the blast radius when it doesn’t.

Read Part 3: Social Engineering Exposed (3/3): Defence That Works