A new phishing toolkit can break into Microsoft 365 accounts without stealing a single password, and it does so by exploiting a legitimate Microsoft sign-in workflow. The attack, detailed in research published July 14, 2026, tricks users into approving device logins that actually belong to an attacker, sidestepping multi-factor authentication (MFA) entirely.

ReliaQuest researchers have identified two distinct campaigns, one built around a toolkit called Jalisco and another named OmegaLord, both targeting Microsoft 365 identities. The more alarming finding is that Jalisco uses Microsoft’s own device authorization page as part of the phish, leaving very little that looks suspicious to the person being tricked.

Here’s what’s actually happening, who’s vulnerable, and exactly what admins should do now.

A phishing attack that turns Microsoft’s own login into a weapon

The device authorization flow exists for good reason. Hardware like smart displays, conference-room systems, and command-line tools often cannot display a standard browser sign-in page. Instead, the device shows a short alphanumeric code, and the user types that code on another device to complete authentication. Microsoft’s implementation follows the OAuth 2.0 Device Authorization Grant standard and supports a wide range of input-constrained hardware.

Jalisco abuses this flow from start to finish. The attacker’s server generates a device code on demand, then directs the victim to visit Microsoft’s real device login page at the well-known URL. Because the page is genuine—showing a valid TLS certificate, the correct Microsoft domain, and often the organization’s branded sign-in experience—there is no visual tip-off that anything is wrong. The problem is that the code belongs to a device the attacker controls.

Once the victim completes authentication and any MFA challenge, Microsoft issues access and refresh tokens for the attacker’s session. The victim walks away believing they just approved a legitimate work device, while the attacker now holds a valid token that can be used for email, SharePoint, Teams, and any other service tied to that identity.

Two details make this more dangerous than a standard credential phish. First, Jalisco generates device codes in real time. Microsoft’s codes expire after about 15 minutes, but real-time generation lets the attacker keep presenting fresh codes instead of watching an expired link kill the campaign. Second, ReliaQuest found the toolkit includes an operator portal for tracking captured sessions—meaning less experienced attackers can run the campaign as a managed service.

OmegaLord, the second toolkit, takes a different route. It presents a fake PDF reader login page that harvests email addresses, passwords, and phone numbers. The phone number collection is particularly notable: researchers believe it is used to manipulate or intercept MFA after the credentials are stolen, possibly through vishing or SMS-based verification tricks, though ReliaQuest has not confirmed the exact follow-on technique.

What this actually means for you

For individual Microsoft 365 users, the immediate risk is any unsolicited prompt to visit a device login page and enter a code. You should never enter a device code unless you personally initiated the sign-in on the device right in front of you. If someone asks you to “verify your account” by entering a code, stop and contact your IT department.

For IT administrators, Jalisco’s technique exposes a gap between what users are conditioned to trust—the look and feel of the correct login page—and what really needs to be verified: which session they are authorizing. MFA is not broken, but the social engineering around it has evolved. The attack bypasses MFA by convincing the victim to complete legitimate authentication for the wrong session.

Post-compromise cleanup is heavier than a simple password reset. ReliaQuest observed attackers registering up to five unauthorized devices against a single compromised account. Those devices often used innocent-sounding names like “Microsoft” or “Windows,” blending into the Entra ID device list. Because Entra device identities can participate in single sign-on and Conditional Access decisions, an unauthorized registration can give an attacker a persistent foothold even after passwords are changed.

Rapid data theft is the norm, not the exception. Researchers reported cases where attackers moved from initial access to exfiltrating data from SharePoint in as little as six minutes, searching for customer records, financial documents, and internal communications. Some incidents escalated to extortion, with attackers threatening to publish stolen data.

For developers and automation engineers, the collateral damage of blocking device code flow could break legitimate workflows. Azure CLI tools, Microsoft Graph PowerShell, and certain shared-device scenarios rely on this flow. A blanket block without scoped exceptions will likely cause service disruptions, so careful auditing is essential.

How we got here

Device authorization abuse is not a new concept—OAuth flow attacks have been documented for years—but Jalisco packages the technique into an accessible phishing toolkit at a time when AI-powered phishing-as-a-service platforms are flooding the market. ReliaQuest reported a 1,380% increase in phishing activity between late 2025 and early 2026, driven by tools that can recreate an organization’s branding from a single website and host phishing pages on legitimate cloud platforms like workers.dev and edgeone.app.

The underlying issue is that Microsoft’s device code flow was designed for trusted hardware in controlled environments, but the mechanism itself makes no such distinction. Once an attacker obtains a valid device code, any user who authenticates using that code hands over a session token, regardless of the attacker’s intent.

Microsoft has long categorized device-code authentication as a high-risk flow and recommends blocking it where possible, but many organizations leave it enabled either out of convenience or because they don’t realize it’s active. The Entra ID default of 50 registered devices per user is another legacy setting that few teams revisit, giving attackers ample room to plant rogue registrations.

What to do now: concrete steps for Microsoft 365 admins

If you manage a Microsoft 365 tenant, the following actions can significantly reduce exposure to Jalisco-style attacks. Start with an audit, then move to enforcement.

1. Inventory device-code sign-ins immediately

Before blocking anything, examine your sign-in logs for device-code authentication events. In the Entra admin center, navigate to the sign-in logs and filter for “authentication protocol: device code.” Identify which users, applications, and devices are relying on this flow. Typical legitimate cases include Microsoft Teams Rooms, shared meeting-room hardware, and developer scripts using Azure CLI.

2. Block device code flow with Conditional Access

Only organizations with Microsoft Entra ID P1 or higher can create Conditional Access policies, but if you have the licensing, this is where you can make the most immediate impact. Microsoft’s current guidance is to block the device code flow by default and allow only tightly scoped exceptions for accounts with a confirmed business need.

Start by creating a policy that targets the “device code flow” authentication protocol, set the grant control to “block access,” and run it in report-only mode for at least 24–48 hours. Monitor the reports to identify any legitimate traffic that would be blocked. Then transition to enforcement while creating a separate exception policy for allowed groups.

3. Restrict device registration and reduce limits

Review who can register devices in Entra ID. By default, all users can register devices, which is too permissive for most environments. Use the Device settings blade to restrict registration to an administrator-defined group.

Lower the per-user device limit from the default of 50 to a number that reflects reality in your organization. ReliaQuest recommends one or two devices where operationally possible, though you’ll need to account for users with multiple workstations, lab VMs, or tablets. The goal is not to disrupt productivity but to make unauthorized devices stand out in the list.

Attackers who gain a session token can often create new app registrations or grant consent to malicious applications, providing persistence beyond token expiry. Review existing application permissions in the Entra admin center, paying special attention to apps with high privilege or those that were created recently. Similarly, check each compromised account’s authentication methods—an attacker may add an alternate phone or email to regain access later.

5. Revoke everything after a compromise

A password reset is not enough. The post-breach playbook must include:

  • Force-sign-out all sessions and revoke refresh tokens.
  • Remove unauthorized Entra devices from the user’s account.
  • Inspect and remove any new app registrations or consent grants.
  • Review sign-in logs for unusual activity, including unfamiliar locations, clients, or device-code events during the intrusion window.
  • If data exfiltration is suspected, audit Microsoft 365 activity logs for bulk downloads, unusual search behavior, or access to sensitive SharePoint sites.

6. Harden MFA configurations

While Jalisco can work around MFA, that does not mean MFA should be weakened. Move away from SMS and voice verification toward phishing-resistant methods like FIDO2 security keys, passkeys, and Windows Hello for Business. Enable number matching in Microsoft Authenticator to reduce simple push-notification fatigue, but be aware that number matching alone cannot stop a user from approving a legitimate-looking device-code prompt.

What to watch next

Jalisco works because it exploits a legitimate Microsoft workflow, not a software vulnerability. That means no patch will eliminate the threat; defense lies entirely in configuration and user awareness. Microsoft will likely improve admin controls around the device code flow and may introduce additional signals in sign-in logs to help differentiate legitimate device authentication from abuse. Keep an eye on Conditional Access enhancements and any new report-only insights for device-code traffic.

More broadly, the industrialization of phishing via toolkits that embed operator dashboards and real-time code generation suggests the volume of device-code attacks will rise before it falls. Admins who act now—blocking the flow where possible, scoping exceptions carefully, and tightening device registration policies—will be ahead of the next wave.