Eye Security has observed threat actors using links to login.microsoftonline.com in phishing emails. Not for device code or consent phishing, but to redirect victims to malicious pages via Microsoft’s legitimate login infrastructure.
About five months ago, at DEFCON33, Keanu Nys gave a great presentation titled “Turning Microsoft’s Login Page into our Phishing Infrastructure”. Among some other (pretty cool) attacks, he showed how login.microsoftonline.com can be used to redirect users to phishing pages. This is exactly what we’re now seeing in the wild.
This email was reported to us by a customer, using our ‘Report Phishing’ button. We use these emails as a source of threat intelligence with the goal of better protecting our customers.
The email was unremarkable; it was sent from a free email provider and did not look targeted. It contained a message we see often: it was time for the user to update their credentials:
We routinely tell users to verify they’re on login.microsoftonline.com before entering credentials. The problem here? The link did point to that domain.
The URL contained lots of parameters, but when we strip the non-essential ones, this remains:
hXXps://login.microsoftonline.com/common/oauth2/v2.0/authorize?scope=openid+profile+https%3A%2F%2Fgraph.microsoft.com%2FUser.Read&client_id=6ef7853e-61e3-4265-af74-b197f5230b19&prompt=none&state=<encoded email address>
A similar URL was scanned at any.run. The client_id parameter contains an application id (6ef7853e-61e3-4265-af74-b197f5230b19) that points to an application in a threat actor-controlled tenant. The redirect URL of this application is set to the phishing page.
We identified the tenant (c26d632b-ae7a-4a76-b721-e66b91262104) this application is registered in. It has no domains connected to it, other than a default onmicrosoft domain. This leads us to believe that this tenant was created by the threat actor for the purpose of creating phishing links, rather than being a legitimate but compromised tenant.
When clicking the link, the page immediately redirects to a workers[.]dev domain (which is configured as the redirect URL for the application), which is a CloudFlare worker. These are frequently abused for phishing. The user is then presented with a CAPTCHA challenge.
The email address of the victim is encoded in the ‘state’ parameter in the original URL. The page the user is redirected to decodes the email address using javascript and redirects to the final phishing page, which uses a variant of the NakedPages phishing framework (on damane[.]cloud or yukazimani[.]com or chouests[.]com). Here the user is prompted for credentials on a copy of the login page, like any regular AiTM phishing attempt.
At this point, the victim is no longer on a Microsoft domain and may notice something is off by looking at the address bar.
We replicated the attack and confirmed it’s straightforward to execute. The threat actor simply creates a multi-tenant application in a Microsoft 365 environment and sets the redirect URI to their phishing page.
Note it doesn’t matter if the user is actually logged in to their account, they will be redirected immediately regardless.
Registering the application requires a privileged role. This is most simply obtained by creating a new tenant, though a compromised account with the Application Developer role (or higher) would also suffice.
How novel is this? Similar techniques have been described before as far back as 2021 by Proofpoint. More recently, Push Security has documented attacks using ADFS and application consents to redirect to phishing sites.
Using urlscan.io, we were able to find examples of this specific technique (using prompt=none) dating back to March 2025, even before the technique was presented publicly. These early examples do not seem to encode the victim email address in the ‘state’ parameter, but use a static value instead. The redirect still works, but the phishing page is long gone.
More recently, other phishing emails using the technique were reported to us just days ago. These are using application ID 981f26f8-00c9-407a-9fd9-058d374656f8, which is hosted in the same Microsoft 365 tenant as the example described in this post.
Using legitimate sites to redirect to phishing sites is not new. We’ve seen threat actors use open redirect vulnerabilities in all sorts of sites, including from Google, Microsoft and security vendors. These attacks can circumvent certain security measures, like scanning emails for malicious links. Domains for large vendors are often included on allow lists.
What is new is that this attack abuses trust in the login.microsoftonline.com domain to convince users it is a legitimate email. Once the user clicks the link, they will hopefully still notice the odd-looking domain.
To help users spot phishing pages, consider installing our AitM block browser extension, which will alert users when they visit a phishing page, including this one.
We reported the URL with the malicious application id to Microsoft. At the time of writing, it remains active.
