Turning Microsoft's Login Page into our Phishing Infrastructure

Turning Microsoft's Login Page into our Phishing Infrastructure

Speakers: Keanu Nys

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=B4pVpByWOcI

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Keanu%20Nys%20-%20Turning%20Microsoft%27s%20Login%20Page%20into%20our%20Phishing%20Infrastructure.pdf

Overview

Keanu Nys presents a class of abuse techniques that weaponize legitimate Microsoft authentication infrastructure — specifically Microsoft's own login pages and identity services — to conduct convincing phishing campaigns that bypass most conventional defenses. The core insight is that by exploiting design decisions and trust relationships within Microsoft's identity platform, an attacker can construct phishing flows that are hosted entirely on login.microsoftonline.com or adjacent Microsoft domains. Victims see a real Microsoft URL, a valid TLS certificate, and a genuine Microsoft login page, yet their credentials go to the attacker. The talk is delivered against a backdrop of Microsoft's own pressure on Nys not to present — adding a layer of meta-commentary about vendor disclosure dynamics.

Background

▶ Watch: Introduction: Turning Microsoft's login page into phishing infrastructure (0:02)

The talk opens with an account of Microsoft's pre-conference attempts to obtain a preview of Nys's slides, escalating from email to party invitations to a meeting with the Microsoft Security Response Center (MSRC). Nys declined each time, arguing that Microsoft would simply classify the findings as "does not meet the bar for immediate servicing" — a response he anticipated based on the nature of the techniques. This framing is important: the attacks he presents exploit design choices and intended functionality, not traditional code-level vulnerabilities. They are in the grey zone between "bug" and "feature abuse," which is exactly the space Microsoft historically resists patching.

Microsoft's identity platform — Azure Active Directory (now Entra ID), OAuth 2.0 flows, and SAML federation — is the authentication backbone for hundreds of millions of enterprise users and consumer accounts. The login page at login.microsoftonline.com is one of the most trusted URLs in enterprise computing: users are trained to look for it, security awareness programs tell them it means safety, and email security tools permit links to it. That trust is precisely what these techniques exploit.

Key Findings

▶ Watch: OAuth flow abuse: how legitimate Microsoft auth enables phishing (7:30)

Microsoft's own login page can host attacker-controlled content. Through manipulation of OAuth parameters, application registrations, and federation configuration options, Nys demonstrates scenarios in which the content displayed on Microsoft's own login domains is substantially controlled by the attacker — inserting attacker-branded content, redirecting credentials, or pre-filling identity fields to target specific users.

OAuth consent flows as a phishing vector. Microsoft's OAuth consent flow — the page that asks users to grant permissions to an application — can be crafted to appear as a legitimate authentication step while actually granting attacker-controlled applications access to the victim's account. The URL is genuine Microsoft. The TLS certificate is genuine Microsoft. The redirect afterward goes to the attacker.

Application registration abuse. Azure/Entra ID allows any organization (and in some configurations, any user) to register OAuth applications. Nys details how application registrations can be crafted to appear as legitimate Microsoft services, exploit the trust the platform extends to registered apps, and conduct man-in-the-middle or credential-harvesting operations with Microsoft-hosted infrastructure doing most of the work.

Federation and External Identity Provider manipulation. Microsoft's support for external identity providers (SAML, OIDC federation) creates additional attack surfaces. Configurations intended for legitimate B2B and consumer federation can be abused to redirect authentication flows through attacker-controlled identity providers while maintaining the appearance of a Microsoft login experience.

The "not a vulnerability" classification problem. Perhaps the most pointed finding is systemic: Microsoft's security response framework does not have a clear path for design-level issues that enable significant user harm but do not constitute code vulnerabilities. The result is that entire classes of phishing infrastructure can exist on Microsoft-branded domains without triggering vendor remediation.

Technical Deep Dive

▶ Watch: Live demo: phishing via Microsoft's own login infrastructure (9:03)

OAuth 2.0 flow mechanics. The authorization code flow and implicit flow both involve user-agent redirects between the relying party and the authorization server (Microsoft). The redirect_uri, response_type, scope, and client_id parameters in these flows are under attacker control if the attacker controls the application registration. Nys details how each parameter contributes to the attack surface.

Crafting convincing consent screens. OAuth consent screens display the application name, the permissions being requested, and the publisher verification status. Nys shows how to configure an application registration to display content that looks like a Microsoft first-party service or a target organization's internal tool, increasing the likelihood that users will click "Accept."

Domain hint and login hint manipulation. Microsoft's authentication endpoints support domain_hint and login_hint parameters that can pre-populate identity fields, restrict which identity providers are shown, and otherwise shape the authentication experience. An attacker constructing a targeted phishing URL can use these parameters to make the login page appear specifically tailored to the victim's organization or account.

The token harvest. After a victim completes a Microsoft authentication flow that was manipulated by the attacker, the resulting access tokens — which may include access to email, files, Teams, or other Microsoft 365 services — are returned to the attacker's registered application. The victim has authenticated against genuine Microsoft infrastructure; they simply granted access to the wrong application.

Avoiding detection. Because all traffic goes to and from legitimate Microsoft domains, proxy-based URL filtering, email link scanners, and network security tools that trust *.microsoftonline.com will not flag the attack. The TLS certificate is valid. The domain is in every allowlist. Nys demonstrates that this makes the technique significantly harder to detect with conventional tooling than conventional phishing pages.

Tenant isolation failures. Some techniques rely on insufficient isolation between Azure tenants. Nys explores cases where cross-tenant trust configurations, shared infrastructure, or default permission settings create opportunities that were not intended by the platform designers but are technically within spec.

Demo / Proof of Concept

▶ Watch: Evasion of email security and URL reputation tools (27:30)

The talk includes live demonstrations of several attack scenarios:

1. The consent phish: An OAuth application crafted to mimic a legitimate Microsoft service requests permissions from a demo account. The entire flow occurs on Microsoft-owned infrastructure, with a genuine Microsoft URL in the browser, ending with the attacker receiving access tokens.

1. Pre-targeted login: Using login_hint and domain_hint parameters, Nys constructs a phishing URL that arrives pre-populated with the victim's email address — making it appear that the user was already logged in and just needs to confirm — a psychological pattern that dramatically reduces victim suspicion.

1. Federation redirect: A demonstration of how external identity provider federation can be configured to insert an attacker-controlled step into an otherwise legitimate Microsoft authentication flow.

Each demo emphasizes the same point: a technically sophisticated user checking the URL would see login.microsoftonline.com, a valid cert, and familiar Microsoft UI — and reasonably conclude they are safe.

Defensive Implications

▶ Watch: Multi-factor authentication bypass using this technique (32:30)

Conditional Access policies are your main lever. Organizations should configure Conditional Access policies that restrict which OAuth applications can request access to corporate resources. Requiring admin consent for all third-party applications — rather than allowing users to consent individually — eliminates a large portion of the OAuth phishing surface.

Monitor application registrations. Azure AD audit logs capture application registration events. Organizations should alert on new registrations, especially those that request high-privilege scopes or claim to be Microsoft first-party services. Microsoft Defender for Cloud Apps can help identify anomalous OAuth app activity.

Disable user consent for OAuth applications. In most enterprise environments, end users should not be able to grant OAuth application permissions without administrator approval. This default is configurable and many organizations leave it at the permissive default.

Educate users about OAuth consent screens. Security awareness programs that only train users to check for https:// and a valid domain are insufficient for this attack class. Users need to understand that a Microsoft-hosted page asking for application permissions can still be malicious.

Publisher verification is not a guarantee. Microsoft's "Verified publisher" badge on OAuth consent screens provides some signal but is not a reliable indicator of legitimacy for all attack scenarios Nys presents.

Review federation configurations. Organizations using external identity provider federation should audit which external providers are trusted, what the fallback behavior is when federation fails, and whether configurations created during onboarding remain appropriate.

Key Takeaways

1. Microsoft's own authentication infrastructure can be weaponized as phishing infrastructure through OAuth abuse, application registration manipulation, and federation configuration exploitation.
2. The resulting phishing pages are hosted on genuine Microsoft domains with valid TLS certificates, bypassing URL-based defenses and defeating user training that relies on domain inspection.
3. These techniques fall in the design-abuse grey zone that Microsoft's MSRC historically does not treat as vulnerabilities requiring immediate servicing.
4. The primary defensive controls are Conditional Access policies, admin-only OAuth consent, and application registration monitoring — not URL filtering or certificate inspection.
5. The disclosure dynamics around this research illustrate a systemic gap in how large platform vendors handle design-level security issues versus code-level vulnerabilities.

About the Speaker(s)

▶ Watch: Mitigations and Microsoft's response to the technique (42:30)

Keanu Nys is a security researcher specializing in identity infrastructure, OAuth, and cloud security. His work focuses on the boundaries between intended platform functionality and exploitable abuse — particularly in Microsoft's identity and authentication stack. The talk's disclosure narrative reflects his view that some research is best communicated through conference presentation rather than vendor-mediated disclosure, especially when the findings sit in the "by design" zone that vendors use to avoid addressing systemic security issues.