New phishing kits target Microsoft 365 accounts, evade MFA

1. Executive summary

Two new phishing kits — Jalisco and OmegaLord — have been discovered targeting Microsoft 365 accounts using techniques that defeat multi-factor authentication (MFA). Jalisco abuses the OAuth 2.0 Device Authorization Grant flow to obtain access and refresh tokens without requiring victim passwords, generating fresh device codes in real-time to bypass Microsoft's 15-minute code validity window. OmegaLord uses a fake PDF reader login page to harvest credentials and phone numbers, the latter likely intended to facilitate MFA interception or SIM-based bypass. Post-compromise, attackers register multiple rogue devices, exfiltrate data from SharePoint and SaaS platforms in as little as six minutes, and follow up with extortion threats. EMEA financial services relying on Microsoft 365 for email, collaboration, and document storage face direct exposure of customer PII, financial records, and internal communications.

2. Regulatory framing

3. Technical analysis & attack chain

Jalisco — device-code phishing kit

Attack chain (confirmed steps)

1. Initial access via social engineering. The attacker sends a phishing message (e.g., document-sharing notification, Teams invite) containing a short device code and instructions to visit Microsoft's legitimate device sign-in verification page.
2. Real-time device code generation. When the victim opens the phishing page, Jalisco automatically generates a fresh Microsoft OAuth device code. This is specifically designed to bypass Microsoft's 15-minute validity window for device codes — by provisioning codes at the moment of victim interaction, the code is always within validity.
3. Victim authorises attacker-controlled device. The victim navigates to the real Microsoft login page (https://login.microsoftonline.com/common/oauth2/deviceauth) and enters the code. They see standard Microsoft sign-in and consent screens, potentially including their organisation's branding. No fake page is presented; the victim never types credentials into a non-Microsoft form.
4. OAuth token capture. Upon victim approval, the attacker's device receives OAuth access and refresh tokens tied to the victim's Microsoft 365 account. The attacker authenticates without ever possessing the victim's username or password.
5. Rogue device registration. Attackers register additional rogue devices on the compromised account — up to five devices observed in a single account. Device names are chosen to appear benign, containing strings such as "Microsoft" or "Windows" to reduce suspicion.
6. Rapid data discovery and exfiltration. Attackers search SharePoint and other SaaS services for valuable data — customer/employee PII, financial records, internal communications. Exfiltration occurs in as little as six minutes post-compromise.
7. Extortion. Following exfiltration, attackers issue extortion demands and threaten to leak stolen data.

Technical specifics

• Protocol abused: OAuth 2.0 Device Authorization Grant flow (RFC 8628).
• Token types compromised: OAuth access tokens and refresh tokens. Refresh tokens enable long-term persistence until revoked or expired.
• Bypass mechanism: Jalisco generates codes in real-time at phishing-page load, defeating the 15-minute device-code TTL that Microsoft implemented as an anti-phishing control.
• Management portal: Jalisco includes a web portal for operators to manage captured sessions and compromised accounts.
• Default device registration limit: Microsoft Entra ID default is 50 devices; ReliaQuest recommends reducing to 1–2.

OmegaLord — credential + phone-number harvesting kit

Attack chain (confirmed steps)

1. Initial access via phishing lure. Victim receives a phishing message directing them to a fake PDF reader login page.
2. Credential and phone-number harvest. The fake login page collects the victim's email address, password, and phone number. The phone number is explicitly targeted to support MFA bypass — likely for SIM-swap, MFA-code interception, or MFA-fatigue attacks.
3. Post-compromise use of harvested data. Credentials and phone numbers enable subsequent MFA bypass or account-recovery attacks (specific post-compromise behaviour not detailed in source).

Technical specifics

• Masquerade vector: Fake PDF reader login page.
• Harvested data elements: Email address, password, phone number.
• MFA evasion rationale: Phone-number collection is engineered specifically to circumvent MFA as a control, complementing the device-code approach used by other kits.

Broader threat landscape (context from related sources)

Multiple PhaaS platforms now target Microsoft 365 using similar techniques. The device-code phishing family includes: Jalisco, EvilTokens, Kali365, Tycoon2FA, Venom, and Forg365. Kali365 has expanded beyond Microsoft 365 to target AWS, Okta, and Russian platforms. Additional kits and techniques observed in the ecosystem include:

• Forg365: Combines adversary-in-the-middle (AiTM) and device-code methods with AI-assisted lure generation.
• Mirage2FA: Uses short-lived HTML smuggling with obfuscated JavaScript loaders to deliver fake M365 login pages; business-themed lures (secure documents, remittance services, automated billing, payment requests). Identified by Fortra.
• Vishing campaigns: Okta has warned of voice-based attacks directing victims to phishing sites mirroring Microsoft Entra ID login pages. A separate campaign targets M365 users with fake security requests to enroll new Entra passkeys.

Attribution and confidence

No MITRE ATT&CK actor profile has been resolved for the operators of Jalisco or OmegaLord. Attribution to specific threat actors is unconfirmed. Technical analysis is attributed to ReliaQuest (single-sourced; verify before enforcement). The broader kit ecosystem (Kali365, Forg365, Mirage2FA, vishing campaigns) is corroborated across multiple sources (BleepingComputer, Malwarebytes, Help Net Security, SecurityWeek, Dark Reading).

4. Mitigation & containment

P1 — Within 24 hours

1. Block device-code authentication via Entra Conditional Access. Create a Conditional Access policy denying the OAuth 2.0 Device Authorization Grant flow for all users unless explicitly required by a documented business case. In Microsoft Entra admin centre: Protection → Conditional Access → New policy → Grant controls → Block, scoped to the "Device code authentication (preview)" condition.
2. Reduce Entra ID device-registration limit. Change the default from 50 to 1–2. In Microsoft Entra admin centre: Devices → Device settings → Maximum number of devices per user. Set to 1 or 2. This limits rogue-device registration and accelerates remediation.
3. Audit existing device registrations. Review all recently registered devices across Entra ID. Flag devices with names containing "Microsoft" or "Windows" that were registered outside normal IT provisioning windows. Remove any unrecognised devices.
4. Hunt for active token-based compromise. Query Microsoft Graph / Entra sign-in logs for: - Device-code authentication events (authenticationProtocol == deviceCode). - Refresh-token usage from unfamiliar IP ranges, devices, or geographies. - Concurrent sessions from disparate locations. - Bulk SharePoint/SaaS access patterns within short timeframes (≤15 minutes).
5. Revoke tokens for suspected compromises. For any confirmed or suspected account: Revoke-AzureADUserAllRefreshToken -ObjectId <user> (Azure AD PowerShell) or use Microsoft Graph API POST /users/{id}/revokeSignInSessions. Force re-authentication.

P2 — Within 72 hours

6. Restrict OAuth Device Authorization grant in Okta (if Okta is in use alongside M365). Disable or tightly scope the device authorization grant in Okta admin settings.
7. Audit and remove unnecessary app registrations. Review all OAuth app registrations in Entra ID. Remove apps with excessive scopes (especially Mail.Read, Files.Read.All, Sites.Read.All) that are not business-justified. Block consent for non-admin users: Enterprise applications → User settings → Users can consent to apps accessing company data on their behalf → No.
8. Deploy anti-phishing controls for device-code lures. Configure email security gateways to flag or block messages containing device codes and instructions to visit login.microsoftonline.com/common/oauth2/deviceauth. This is a legitimate Microsoft URL — blocking the URL itself is not viable; instead, detect the social-engineering pattern (short alphanumeric code + instructions + urgency cues).
9. Brief users on device-code phishing. Specifically warn users that legitimate Microsoft will never send a device code via email and ask them to enter it on a verification page. Device codes are only used in flows the user initiated (e.g., signing in a TV, CLI tool, or IoT device).

P3 — Within 7 days

10. Implement Entra ID Conditional Access location-based controls. Restrict access to trusted locations or require compliant device for all M365 access. This narrows the window for token replay from attacker-controlled infrastructure.
11. Enable Entra ID Identity Protection. Configure risk-based conditional access policies to automatically block or require step-up auth for token replay from anomalous sessions.
12. Review M365 audit log retention. Ensure Unified Audit Log (UAL) retention is set to maximum (180 days for E5 / 365 days with appropriate licensing) to support post-incident investigation of data access in SharePoint, Exchange, and OneDrive.
13. Tabletop exercise: token-based account takeover. Run a simulated incident covering: detection via sign-in anomaly → token revocation → rogue-device removal → SharePoint/OneDrive access audit → data-exfiltration assessment → extortion response → regulatory reporting assessment (DORA Art. 19 / NIS2 Art. 23).

5. Indicators of compromise

No indicators of compromise available in the source material. The source articles describe kit names, techniques, and behaviours but do not publish specific IOCs (domains, IPs, file hashes, URLs, or email artefacts). The following behavioural indicators should be used for detection instead (see §6).

Behavioural indicators (from source material)

6. Detection

Sigma rule — Entra ID device-code authentication and rogue-device registration

title: Suspicious Device-Code Authentication and Rogue Device Registration in Entra ID
id: AT-2026-07-14-295-device-code-phish
status: experimental
description: >
  Detects device-code authentication events in Entra ID sign-in logs and
  multiple device registrations on a single account, consistent with
  Jalisco and related device-code phishing kits. Also flags devices
  registered with names containing "Microsoft" or "Windows" outside
  normal provisioning.
author: Adverse Trace
date: 2026/07/14
references:

  - https://www.bleepingcomputer.com/news/security/new-phishing-kits-target-microsoft-365-accounts-evade-mfa/
logsource:
  product: microsoft
  service: azure.signinlogs
detection:
  device_code_auth:
    authenticationProtocol: deviceCode
    ResultType: 0
  rogue_device_name:
    DeviceDisplayName|contains:

      - "Microsoft"
      - "Windows"
  multiple_device_reg:
    condition: selection
    # Correlate: count of device registrations per user > 2 within 1h
    # Implement via KQL query against Entra ID audit logs
  filter_legitimate_provisioning:
    DeviceDisplayName|contains:

      - "Corporate"
      - "Managed"
    # Adjust filter to match your organisation's device naming convention
  condition: (device_code_auth and not filter_legitimate_provisioning) or (rogue_device_name and not filter_legitimate_provisioning)
fields:

  - UserPrincipalName
  - DeviceDisplayName
  - DeviceId
  - IPAddress
  - Location
  - TimeGenerated
  - authenticationProtocol
  - ResultType
falsepositives:

  - Legitimate device-code flows (CLI tools, IoT devices, TV apps) — validate against known provisioning
  - IT-managed devices with "Microsoft" or "Windows" in the name — filter on provisioning source
level: high

KQL query — Rapid SharePoint data access post device-code auth

// Detect rapid SharePoint/SaaS access following device-code authentication
// Adjust time windows as needed
let deviceCodeSignins = SigninLogs
  | where AuthenticationProtocol == "deviceCode"
  | where ResultType == 0
  | project TimeGenerated, UserPrincipalName, IPAddress, DeviceId;
let saasAccess = OfficeActivity
  | where RecordType in ("SharePointFileOperation", "OneDriveFileOperation")
  | where Operation in ("FileAccessed", "FileDownloaded", "FolderAccessed")
  | project TimeGenerated, UserPrincipalName, Operation, Site_Url, SourceFileName;
deviceCodeSignins
  | join kind=inner (saasAccess) on UserPrincipalName
  | where TimeGenerated1 between (TimeGenerated .. (TimeGenerated + 15m))
  | project TimeGenerated, UserPrincipalName, IPAddress, DeviceId, TimeGenerated1, Operation, Site_Url, SourceFileName
  | summarize FileAccessCount = count(), FilesAccessed = makeset(SourceFileName), FirstAccess = min(TimeGenerated1), LastAccess = max(TimeGenerated1) by UserPrincipalName, IPAddress, DeviceId
  | where FileAccessCount > 10

Sigma rule — OmegaLord fake PDF reader credential harvest (email detection)

title: Phishing Email with Fake PDF Reader Login Page — OmegaLord Pattern
id: AT-2026-07-14-295-omegalord-phish
status: experimental
description: >
  Detects phishing emails directing users to a fake PDF reader login page
  that harvests email, password, and phone number — consistent with the
  OmegaLord phishing kit.
author: Adverse Trace
date: 2026/07/14
references:

  - https://www.bleepingcomputer.com/news/security/new-phishing-kits-target-microsoft-365-accounts-evade-mfa/
logsource:
  product: microsoft
  service: exchange
detection:
  selection_subject:
    Subject|contains:

      - "PDF"
      - "document"
      - "view"
      - "secure document"
      - "shared"
  selection_body:
    Body|contains:

      - "PDF reader"
      - "login"
      - "sign in"
      - "phone number"
      - "mobile number"
  selection_url:
    Body|re: 'https?://[^\s]*(login|signin|auth|verify)[^\s]*'
  condition: selection_subject and selection_body and selection_url
fields:

  - Sender
  - Subject
  - Recipient
  - Body
falsepositives:

  - Legitimate document-sharing services with PDF preview functionality
level: medium

7. Sources

• BleepingComputer — "New phishing kits target Microsoft 365 accounts, evade MFA" — https://www.bleepingcomputer.com/news/security/new-phishing-kits-target-microsoft-365-accounts-evade-mfa/ — 2026-07-14
• BleepingComputer — "New Forg365 phishing platform uses AI to target Microsoft 365 accounts" — https://www.bleepingcomputer.com/news/security/new-forg365-phishing-platform-uses-ai-to-target-microsoft-365-accounts/
• Help Net Security — "Mirage2FA phishing kit uses HTML smuggling to steal Microsoft 365 credentials" — https://www.helpnetsecurity.com/2026/06/26/mirage2fa-phishing-kit-microsoft-365-html-smuggling/ — 2026-06-26
• SecurityWeek — "Okta Warns of Vishing Attacks Targeting Microsoft 365 Customers" — https://www.securityweek.com/okta-warns-of-vishing-attacks-targeting-microsoft-365-customers/
• BleepingComputer — "Entra passkey enrollment vishing targets Microsoft 365 users" — https://www.bleepingcomputer.com/news/security/entra-passkey-enrollment-vishing-targets-microsoft-365-users/
• Malwarebytes Labs — "Kali365 phishing kit bypasses MFA and steals Microsoft logins" — https://www.malwarebytes.com/blog/scams/2026/05/kali365-phishing-kit-bypasses-mfa-and-steals-microsoft-logins — 2026-05
• Dark Reading — "FBI-Flagged Phishing Kit Kali365 Expands Its Reach" — https://www.darkreading.com/cyber-risk/fbi-flagged-phishing-kit-kali365-expands-its-reach

8. Adverse Trace position

Severity: High. The Jalisco and OmegaLord kits represent a material escalation in M365 phishing capability. Jalisco's real-time device-code generation directly defeats Microsoft's 15-minute TTL mitigation, and the six-minute exfiltration window means traditional SOC response timelines are inadequate. OmegaLord's explicit phone-number harvesting signals continued adversary investment in engineering around MFA as a primary control. For EMEA financial services, the exposure is acute: SharePoint and SaaS platforms routinely hold customer PII, financial records, and internal communications that trigger DORA Art. 18/19 and NIS2 Art. 23 reporting obligations. No specific IOCs have been published; detection must rely on behavioural signals — device-code auth events, rogue-device registration patterns, and rapid SharePoint access post-authentication. Attribution is unconfirmed (no MITRE actor profile resolved; ReliaQuest analysis is single-sourced). We are monitoring for IOC publication and will issue an update if indicators become available. Clients should immediately block device-code authentication via Conditional Access, reduce the Entra device-registration limit to 1–2, and brief users on the device-code phishing pattern.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.