Operators Posing as IT Staff Had Employees Authorise a Connected App

From mid-2025, operators associated with the cluster tracked as ShinyHunters ran voice-phishing campaigns against enterprise SaaS tenants. In one documented variant, callers impersonating internal IT directed employees to the platform’s own legitimate app-connection page and talked them through entering a connection code, thereby authorising an application the attackers controlled.

The employee visits the real vendor’s real domain over a valid certificate. They authenticate normally, with multi-factor if it is enforced. They are shown a consent screen and they consent.

There is no phishing page, no credential to capture, no malware, and no vulnerability. Every anti-phishing control an organisation deploys is looking for a fake site, and there was no fake site.

OAuth exists so that granting an application access does not mean handing over a password. The user sees what is being requested and decides. It is a genuine improvement over what preceded it.

It assumes the person deciding understands the request. A consent screen listing API scopes is not a document an employee on a support call has any basis to evaluate, and the whole model rests on that evaluation.

This is the identity-boundary argument this desk files throughout — 25-0512, 25-0514, 25-0701 — with the boundary moved from a help desk to a dialogue box.

An authorised connected application queries the platform’s API from its own infrastructure, using a token the tenant issued. It is not a session, not a login from an unusual location, and not subject to conditional access rules written for users.

Detection has to come from noticing an unfamiliar application with broad scopes and unusual query volume — which requires an inventory of connected applications that most organisations do not maintain.