Decoding the world of cybersecurity

Microsoft 365 phishing moves beyond passwords

Jalisco and OmegaLord target Microsoft 365 identities by abusing device-code authentication and collecting information that can support interception of weaker MFA methods.

Microsoft 365 phishing moves beyond passwords
Summary
  • Jalisco convinces users to authorise an attacker-controlled device through Microsoft’s genuine authentication service.
  • OmegaLord imitates a PDF reader and collects credentials and telephone numbers, potentially supporting attacks against phone-based authentication.
  • Device-code restrictions, phishing-resistant authentication, token monitoring, and tighter device registration can limit exposure.

ReliaQuest has identified two phishing toolkits targeting Microsoft 365 accounts through methods designed to operate around multi-factor authentication rather than break its cryptography directly.

The first, named Jalisco, uses device-code phishing. Microsoft’s device-code flow allows a user to authenticate a device with limited input capabilities by entering a short code on another computer or telephone. Authentication takes place through Microsoft’s genuine sign-in service, including any required MFA check.

In the malicious workflow, the code belongs to an attacker-controlled session. The victim sees a legitimate Microsoft page and successfully proves their identity, but the resulting access and refresh tokens are delivered to the attacker’s tooling.

Jalisco provisions new OAuth device codes through a backend service whenever a lure is opened. Generating codes on demand avoids relying on a static value that may expire before the victim responds and allows the operator to manage captured sessions through a web portal.

The victim does not need to enter a password into a counterfeit Microsoft page. Password resets may also be insufficient once valid tokens and attacker-controlled device registrations have been established, because those sessions and devices need to be removed explicitly.

Javvad Malik, lead CISO adviser at KnowBe4, said: “The main point here is that attackers aren’t trying to break MFA, they’re simply going around it. Device-code phishing is particularly sneaky because it doesn’t ask the user to type a password into a fake page. It only asks them to approve a legitimate Microsoft authentication prompt. From the user’s perspective, it looks like a normal workflow. From the defender’s perspective, the login is technically valid.”

OmegaLord uses a more conventional credential-harvesting approach but adapts the lure to current authentication controls. Its JavaScript interface imitates a PDF reader and asks the user for an email address, password, and telephone number.

ReliaQuest assesses that the telephone number may support attempts to intercept or manipulate SMS codes, MFA requests, or account-recovery procedures. That intended use has not been directly confirmed by an identified operator, although collecting the number alongside credentials gives an attacker information relevant to phone-based controls.

Jamie Akhtar, chief executive and co-founder of CyberSmart, said: “These phishing kits show how cyber criminals are adapting their tactics to work around traditional multi-factor authentication. One method tricks victims into authorising an attacker-controlled device through Microsoft’s legitimate sign-in process, while another uses a fake PDF reader to steal credentials and phone numbers. Once inside a Microsoft 365 account, attackers can move quickly to access sensitive information held in services such as SharePoint, potentially leading to data theft, fraud and extortion.”

Microsoft classifies device-code flow as a high-risk authentication method and recommends blocking it wherever possible. Its Conditional Access guidance advises organisations to audit current use, begin with report-only enforcement, and retain exceptions only for documented systems that genuinely require the flow.

New Microsoft Entra tenants using security defaults began blocking device-code flow automatically on 1 July 2026. Existing tenants and organisations operating custom Conditional Access policies still need to establish whether the method remains enabled and which devices or applications depend on it.

Removing the flow without preparation can interrupt meeting-room equipment, command-line tools, and other devices built around its use. Exceptions should be limited to identified accounts and systems, assigned to an owner, and reviewed rather than granted across a broad population.

Identity investigation also needs to extend beyond passwords. Unexpected device-code authentications, newly registered devices, refresh-token activity, unusual sign-in locations, MFA-method changes, and rapid access to Exchange, SharePoint, or OneDrive can reveal activity that appears technically valid at the initial login stage.

Phishing-resistant authentication methods, including passkeys and hardware-backed FIDO credentials, reduce exposure to credential replay and approval manipulation. Session governance, token revocation, device registration, and conditional access remain necessary where attackers can obtain authorisation through a legitimate authentication service.

Akhtar said organisations should retain MFA but distinguish between the protection offered by different methods, combining stronger authentication with device-code restrictions, monitoring, workforce awareness, and tested incident response.

MFA continues to remove large classes of password-only compromise. Jalisco and OmegaLord show how authentication flows, device trust, token lifetimes, enrolment rights, and SaaS activity determine whether a completed MFA event should be accepted as legitimate.

×