[GAME THEORY] The help desk is becoming the new intrusion broker.

The help desk is not merely a side door. It is a market where urgency can be converted into enterprise authority.

Attackers have learned to pressure the people and workflows that reset passwords, enroll MFA factors, approve recovery, and steer users toward “support” applications. Defenders face an awkward tradeoff: slow every request and business operations suffer; optimize only for ticket closure and a convincing caller may leave with durable SaaS access. The practical move is not more generic awareness training. It is to identify each trust transaction, require independent evidence for consequential changes, and correlate the change with what happens next.

The phone call is the lure. The product is authority.

TL;DR

• Google reported that UNC6671 used help-desk vishing, adversary-in-the-middle portals, MFA-token interception, and automated cloud-data theft while operating through multiple extortion brands.
• Microsoft separately documented vishing-led malicious OAuth consent in which users authorized attacker-controlled applications presented as legitimate tooling.
• We assess that these operations exploit a market failure: support speed is rewarded locally, while the enterprise absorbs most of the downside when a trust decision is wrong.
• Help-desk recovery, AiTM session theft, and malicious OAuth consent are distinct paths. A single “MFA bypass” label hides different control boundaries and telemetry.
• Defenders get leverage by separating identity proof from authority changes, reducing the cost of independent verification, governing risky consent, and correlating trust changes with SaaS use.

The key judgment

The strongest attacker innovation here is not a new phishing kit or extortion brand. It is a repeatable way to turn institutional pressure into authorized access.

A support agent wants to resolve the ticket. An employee wants to comply with someone who sounds like security. An identity platform wants recovery to work. A SaaS vendor wants integrations to remain easy. An executive wants business friction kept low. Each incentive is reasonable in isolation.

The attacker arbitrages the seams.

That makes access a transaction rather than a single credential-theft event. The attacker presents a claim, manufactures urgency, supplies just enough evidence, and asks the defender’s process to mint something valuable: a password reset, a new MFA factor, an authenticated session, an OAuth grant, or a role change.

Google Threat Intelligence described UNC6671 as a financially motivated threat cluster that continued compromising organizations after BlackFile’s alleged retirement, used several extortion brands, and combined help-desk vishing, AiTM phishing, MFA-token interception, and automated exfiltration from Microsoft 365 and Okta environments. Microsoft separately reported vishing cases in which users were persuaded to authorize malicious applications disguised as a Salesforce Data Loader tool.

Observed: actors are using social pressure to obtain recovery changes, sessions, or delegated SaaS authority, then moving quickly toward cloud data.

Assessed: the repeatable advantage is the trust-conversion workflow, not any one brand, portal, or authentication trick.

Unknown: how much infrastructure and scripting the named crews share, and whether reported incidents represent one coordinated market or several groups converging on the same economics.

Three games hiding inside “vishing”

The common label is convenient. It is also analytically dangerous.

1. Help-desk recovery vishing

The attacker impersonates an employee and persuades support to reset a password, change recovery information, enroll a new MFA factor, or initiate another recovery path.

The control boundary is the enterprise’s identity-proofing and recovery process. The useful telemetry begins with service-desk tickets and call records, then moves into password-reset, MFA-registration, recovery-data, role-change, sign-in, and SaaS audit events.

2. AiTM session theft

The attacker directs an employee to an adversary-in-the-middle portal that relays authentication to the real identity provider. The employee may complete MFA successfully while the attacker captures a usable session artifact.

No help-desk action or OAuth grant is required. The control boundary is the active authenticated session. Useful telemetry includes sign-in context, device state, conditional-access decisions, proxy or DNS evidence for a look-alike portal, and subsequent SaaS behavior that does not fit the original user or device.

3. Vishing-driven malicious OAuth consent

The attacker persuades a user to approve a purported support or migration application. The authorization service records the grant and issues tokens to the attacker-controlled client. The client can then call SaaS resources within the intersection of granted scopes, tenant policy, and the user’s underlying entitlements.

The control boundary is delegated authorization. Password resets alone may not remove it. Defenders need consent events, application and service-principal changes, publisher and redirect-URI context, granted scopes, and resource-side API activity tied back to the client or application ID.

Three paths. Three control boundaries. Three opportunities to avoid a vague “the user got phished” postmortem.

The incentive problem

For the frontline agent, fast handling has an immediate and visible benefit: the requester gets back to work, the queue moves, and service metrics improve. Independent verification has an immediate cost: more time, another person, a callback, or a frustrated employee.

The breach cost is delayed, uncertain, and mostly borne by someone else.

That is why “be more careful” is weak control design. It asks a tired person to absorb organizational friction while making a high-stakes judgment with incomplete information. Attackers can rehearse the script. The defender has to judge a single call in real time.

A better policy changes the payoff:

• make independent verification fast and routine;
• provide better signals to the decision-maker;
• prevent one pressured interaction from both proving identity and granting consequential authority;
• measure safe resolution, not only closure speed;
• correlate the trust change with the access and collection that follow.

Practical gut-check: which request in your support queue can create the most authority with the least independent evidence?

Below the tear line: how attackers and defenders are likely to adapt, which signals matter, and the one workflow change worth testing this week.

We also include the technical report.

Which team owns the full sequence from a high-risk support request to the next SaaS export—and can that team reconstruct it before the attacker finishes collecting?

Moves and countermoves

Defender move: require verified recovery

Use a directory-sourced callback, authenticated self-service channel, managed-device confirmation, or independent approval for high-risk recovery and identity changes. Do not trust contact details supplied inside the same inbound interaction.