Jalisco kit auto-refreshes M365 device codes on demand

Confirmed: ReliaQuest published on July 14, 2026 two additional Microsoft 365 phishing kits — Jalisco and OmegaLord — with observed use against enterprise tenants. Both slot into the MFA-defeating operating pattern already documented for Forg365 PhaaS and the Evilginx crews Lexfo mapped last week. Confidence on the kits’ existence, mechanics, and defensive controls below: as-reported by ReliaQuest.

Jalisco — device-code phishing that keeps the code fresh

Microsoft OAuth device codes are valid for 15 minutes. That window is the thing that stops a phishing operator from staging a code once and hoping the target arrives inside it. Jalisco removes the window. Per ReliaQuest, the kit generates a fresh device code automatically the moment a victim loads the phishing page, so the code the user sees is always inside its validity horizon. Confidence: as-reported.

Operator side: a web portal for managing compromised accounts and the sessions the kit produces. Nothing exotic — the value is the freshness pipeline, not the console. Confidence: as-reported.

Context: the debull cluster reported July 8 worked the device-code flow without the auto-refresh trick, and pieces of the campaign lapsed the 15-minute limit under the operator’s nose. Jalisco is the same class of attack, tuned so that mistake stops mattering.

OmegaLord — credential harvester with a phone number field

OmegaLord poses as a PDF reader page. It collects three things: email, password, and phone number. The phone number is the interesting field — ReliaQuest reads it as staging for MFA bypass, either SIM-swap targeting or push-notification social engineering with a real callback number in hand. Confidence: as-reported.

What operators do once inside

Per ReliaQuest, observed tenant compromises followed a compact pattern:

• Data exfiltration inside six minutes from SharePoint and other SaaS platforms. Confidence: as-reported.
• Up to five rogue devices registered per compromised account. Default Entra ID limit is fifty. Confidence: as-reported.
• Rogue device names carry benign strings — “Microsoft,” “Windows” — chosen to survive a fast device-inventory scan. Confidence: as-reported.
• Extortion demand follows exfil. Confidence: as-reported.

Threat-actor attribution: not offered by ReliaQuest. Distribution model, subscription pricing, and any Telegram storefront: not reported in the writeup. Unconfirmed — treat accordingly.

Where Jalisco and OmegaLord sit in the market

ReliaQuest lists these next to a familiar shelf: EvilTokens, Kali365, Tycoon2FA, Venom, Forg365, Bluekit. Each solves a different piece of the MFA problem — session token replay, AitM proxy, device code, credential harvest — and each is in active use somewhere. The market is not narrowing.

What to actually do

Direct from ReliaQuest’s writeup, restated because the controls do not require a CVE or a KEV addition:

1. Reduce the Entra ID device-registration limit from the default 50 to one or two. Fifty devices per user is a ceiling designed for edge cases; the operators are using the headroom.
2. Block device-code authentication via Entra Conditional Access. Most tenants do not need the flow enabled for the general user population. Microsoft’s Conditional Access documentation covers the block policy. Jalisco is not possible without device-code flow.
3. Restrict the OAuth Device Authorization grant in Okta where Okta is the front door.
4. Audit app registrations and remove ones no team can name. Both kits move under the shape of legitimate OAuth traffic — the unaudited backlog is where a rogue registration hides. This is the same drum Proofpoint’s OAuth-client-ID-spoofing writeup beat on yesterday, from a different angle.

There is no CVE to wait for. Both kits abuse an intentional protocol feature — the fix is a tenant configuration change, and it is available now.

Sources

• BleepingComputer — “New phishing kits target Microsoft 365 accounts, evade MFA” — July 14, 2026, summarizing ReliaQuest’s research.