Two New Phishing Kits Walk Around Your Microsoft 365 MFA From Opposite Directions. One Never Asks for a Password. This Is Ransomware Without the Ransomware.

ReliaQuest documented two new Microsoft 365 phishing kits this week, Jalisco and OmegaLord, and the interesting thing about them is not that they exist — phishing kits are a commodity — but that they attack multi-factor authentication from two completely different angles, and neither of them is the thing your MFA rollout was designed to stop. One of them never asks the victim for a password at all. Together they are a clean illustration of a shift we have been writing about for a year: the endpoint is no longer the target. Your identity provider is. And the attack that used to end in encrypted files now ends in your own SharePoint being emptied out with a valid session token.

OmegaLord: the honest-looking front door

OmegaLord is the more traditional of the two. It puts up a fake PDF Reader login page and harvests what you type — email, password, and, tellingly, your phone number. That last field is the point. A phishing kit that specifically collects phone numbers is not doing it for the mailing list; it is collecting the number so the operator can intercept the SMS code or push the MFA prompt to a channel they control. OmegaLord treats MFA as a data-collection problem: get the credential, get the second factor's delivery address, defeat both in one form. It is the brute-force-the-human approach, and it still works because a convincing login page and a plausible reason to "re-authenticate" is all most people need.

Jalisco: the kit that never needs your password

Jalisco is the one worth studying, because it does not phish credentials at all — it abuses the OAuth 2.0 Device Authorization Grant, the flow designed for signing a smart TV or a CLI into your account. Here is the move: the attacker starts a real sign-in against a Microsoft service, Microsoft issues a legitimate device code, and the victim is socially engineered into typing that code into the genuine Microsoft login page. The victim authenticates, with their real MFA, on Microsoft's real site — and the attacker's device, the one that started the request, is what gets authorized. No fake page to detect, no credential to steal, the MFA prompt is real and the user passes it correctly. They just pass it on the attacker's behalf.

The kit's cleverness is in the timing. Microsoft device codes are only valid for about fifteen minutes, which is the natural defense against this class of attack — the window to trick someone is short. Jalisco defeats that by generating a fresh device code automatically the moment a victim opens the lure page, so the code is always live when the target arrives. It ships with an operator web portal to manage captured sessions, and the post-compromise playbook ReliaQuest describes is fast and specific: exfiltration in as little as six minutes through SharePoint and connected SaaS, the registration of up to five rogue devices on the compromised account under anodyne names like "Microsoft" or "Windows" for persistence, and then an extortion demand.

This is the pattern we have been naming, now packaged as a product

We have written this thesis repeatedly under different headlines. When Russia's APT28 hijacked router DNS to steer Microsoft 365 OAuth flows, we called it a pattern we had already written. Through the Salesloft/Drift breach, the UNC6395 OAuth compromise, and the third Salesforce OAuth theft in twelve months where Icarus stole tokens from Klue, the through-line was the same: the token is the target, not the machine, and MFA does not protect a token that was minted legitimately after the user was tricked into consenting. Jalisco is that thesis commoditized into a kit with a management portal. Device-code phishing used to be a technique in an APT report; it is now a product with a UI.

And notice what the endgame is. No malware runs on the endpoint. No files are encrypted. The operator logs into your tenant with a valid session, registers persistence devices named to blend in, pulls your data out of SharePoint in six minutes, and demands money. It is ransomware's business model with the ransomware removed — which also removes the thing your EDR was watching for. The detection surface moved to identity, and most shops are still instrumented for the endpoint.

What to actually do — and it is not "more MFA"

The reflex here is wrong. Adding MFA does not help against Jalisco, because Jalisco lets the user complete real MFA on Microsoft's real site. The defenses are configuration, not authentication strength:

Block the OAuth device-code flow entirely for users who do not need it — Microsoft Entra Conditional Access can disable device-code authentication, and the overwhelming majority of your users are never legitimately signing a smart TV into their work account. Cut the Entra device-registration limit down from the default of 50 to one or two, so an attacker cannot quietly register five persistence devices named "Windows" behind a compromise. Audit and remove app registrations you do not recognize, because a consented app is a token that survives a password reset. And watch the identity plane, not just the endpoint — a login from a new device followed by five device registrations and a SharePoint bulk download in six minutes is the whole attack, and every step of it is a log entry you can alert on if you are looking.

We do not just recommend this — we checked our own tenant while writing it, because publishing security advice you do not follow yourself is the fastest way to deserve the breach. Two receipts. First, the exact control that stops Jalisco: our Conditional Access is enforcing a "block device code flow" policy — enabled, grant set to block — so the device-authorization grant Jalisco abuses cannot complete against our accounts at all. Second, the delivery layer: our Microsoft 365 Tenant Allow/Block List enforcement ran this morning at 09:10 UTC and succeeded, pushing our curated malicious-sender and URL indicators into Exchange's block list — because the mail tier is where these lures land first, and blocking the delivery is cheaper than catching the session. Defending the identity plane is not a product you buy; it is a set of defaults you change — and we changed them before we told you to.

The honest note

We did not find Jalisco or OmegaLord — this is ReliaQuest's research and we credit it; they published the kits, the mechanisms, and the six-minute exfil timing, and the article carries no IOCs for us to add to a feed yet. What we bring is the placement: this is not a novel attack, it is the OAuth-blind-spot pattern we have documented for a year finally shrink-wrapped into a kit any operator can run, and the reason it matters is that it defeats the one control most organizations think closed this door. MFA raised the floor. Device-code phishing built a ramp over it, and now the ramp comes with a web portal. We hold this at 95 percent, and the five percent is that named kits get renamed and IOCs shift — but the mechanism is the durable part, and the mechanism is a configuration problem you can fix today.

Sources: ReliaQuest research on the Jalisco and OmegaLord Microsoft 365 phishing kits (July 2026), via BleepingComputer; DugganUSA prior OAuth-blind-spot coverage (APT28 M365 OAuth, Salesloft/Drift, UNC6395, Salesforce/Icarus), queried directly.

---

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register