The Attack That Doesn’t Need Your Password

A new FBI advisory describes phishing that hijacks a Microsoft 365 session without stealing a password and without breaking multi-factor authentication the way you’d expect. For an SEC-registered adviser, that makes it a Regulation S-P and Rule 206(4)-7 problem — not just an IT ticket. Here is the mechanism, why your MFA won’t catch it, and the configuration changes worth making this week.

Key takeaway: The FBI’s Internet Crime Complaint Center (Alert I-052126-PSA, 21 May 2026) is warning about Kali365, a subscription phishing kit that captures Microsoft 365 OAuth tokens and grants persistent access to Outlook, Teams, and OneDrive — without capturing a password and without defeating MFA in the way most firms assume. The single most effective countermeasure is a Conditional Access policy that blocks the device code authentication flow. If your tenant allows device code flow today, you are exposed.

What the FBI is warning about

On 21 May 2026 the FBI published an advisory (Alert I-052126-PSA) on a Phishing-as-a-Service platform it calls Kali365, first observed in April 2026 and sold largely through Telegram. Despite the name, it has nothing to do with the Kali Linux security distribution — it is a criminal subscription service.

A subscription buys turnkey account takeover. The kit supplies AI-generated lures, automated campaign templates, live dashboards that track who has taken the bait, and the payload itself: capture of Microsoft 365 OAuth tokens. The barrier to entry is deliberately low. The operator does not need to be sophisticated.

The end state is persistent access to a victim’s Microsoft 365 mailbox, Teams, and OneDrive — with no password and no further MFA prompts.

Why your MFA didn’t help

Conventional credential phishing steals a password; MFA is what stops a stolen password from being reused. This attack never touches the password.

It abuses the OAuth 2.0 device authorization grant — “device code flow,” the same legitimate mechanism that lets you sign a smart TV or a command-line tool into your account by typing a short code into a normal browser. The attacker simply inserts themselves into that flow:

1. Lure. The attacker starts a device-code sign-in and receives a short code from Microsoft. A phishing email — impersonating a trusted document or productivity service — tells the target to enter that code on the genuine Microsoft device-login page.
2. Authorization. The target visits the real Microsoft page, signs in, completes their own MFA, and enters the code — unknowingly authorizing the attacker’s device.
3. Token theft. Microsoft issues access and refresh tokens to the attacker’s device, because from Microsoft’s perspective the user just approved it.
4. Persistence. The attacker now reaches Outlook, Teams, and OneDrive with no password and no further MFA challenge.

Tokens are bearer credentials: whoever holds them is trusted until they expire or are revoked. The refresh token lets the attacker keep minting new access tokens, so the foothold persists long after the lure is forgotten. No password reset is triggered and no MFA challenge reappears, because the attacker never logs in again — they ride the tokens the user already authorized.

“We require MFA” is no longer, by itself, a defensible control statement. In this attack the MFA requirement was satisfied — and the firm was still compromised.

Why this is a compliance problem, not just an IT problem

For an SEC-registered investment adviser, a Microsoft 365 takeover lands on at least four rules at once:

• Regulation S-P. As amended in 2024, the rule requires a written incident response program and — where unauthorized access to sensitive customer information is reasonably likely to result in substantial harm — customer notification, generally within 30 days. A compromised mailbox or OneDrive routinely holds exactly that information. If your monitoring can’t see token-based access, you can’t reliably detect the incident, let alone start the notification clock.
• Rule 206(4)-7. The compliance program must be reasonably designed to prevent violations — and “reasonably designed” is measured against known, foreseeable threats. This technique is now the subject of a public FBI advisory. An examiner can reasonably ask whether your firm restricted device code flow.
• Rule 204-2. Mailbox and file-store compromise threatens the confidentiality and integrity of required records. Intruders read and exfiltrate, and they can alter or delete.
• Regulation S-ID. Unfamiliar device registrations and anomalous account access are textbook identity-theft red flags your program is supposed to identify and act on.

The through-line: examiners increasingly evaluate whether controls match the current threat picture, not whether a policy binder exists. “We have MFA” describes a control this attack defeats.

What to do this week

In priority order. The first item does most of the work.

1. Block device code flow with Conditional Access. Create a Conditional Access policy that blocks the device code authentication flow for all users. This is the FBI’s lead recommendation and it removes the attack path directly.
2. Audit before you block. Some legitimate tools — certain CLI utilities, older or headless devices — rely on device code flow. Pull your sign-in logs, filter for device-code authentications, and identify real dependencies first. Scope any exception narrowly and write down the business justification. That documentation is your examination evidence.
3. Block authentication transfer. Disable the “continue on another device” authentication hand-off so a desktop session can’t be pushed onto an attacker-controlled phone.
4. Protect your break-glass accounts. If you genuinely cannot eliminate device code flow everywhere, exclude your emergency / break-glass admin accounts from the blocking policy so a misconfiguration can’t lock you out — and monitor those accounts closely.
5. Shorten the blast radius. Where your licensing allows, use sign-in risk policies and continuous access evaluation to force re-authentication on risky sign-ins and revoke tokens faster. Many advisers on Microsoft 365 E3 or Business Premium have more of this capability available than they are using.

None of these steps is exotic, but each has a way of going in half-finished — a policy created in report-only mode and never enforced, an exception scoped too broadly, a break-glass account left unmonitored. Confirming the configuration actually does what you think it does is its own piece of work, and it’s the piece an examiner will test.

How to block it — the exact Conditional Access policy

This is the step-by-step version of item 1 above, and it is the FBI’s lead recommendation. Microsoft exposes the control in Conditional Access under the Authentication flows condition. Build it in report-only mode first so you can see what it would block before you enforce it.

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com) as at least a Conditional Access Administrator.
2. Go to Entra ID → Conditional Access → Policies, and select New policy.
3. Under Assignments → Users, set Include to All users. Under Exclude, add your emergency / break-glass accounts (and any service accounts), so a misconfiguration can’t lock you out.
4. Under Target resources → Resources (formerly cloud apps), set Include to All resources.
5. Under Conditions → Authentication Flows, set Configure to Yes, select Device code flow, then Done.
6. Under Access controls → Grant, choose Block access and select it.
7. Set Enable policy to Report-only and create it. Review which sign-ins it would have blocked to surface any legitimate device-code dependencies (older or headless tooling).
8. When the report-only results are clean, switch Enable policy from Report-only to On.
9. Repeat the same steps for Authentication transfer (select it instead of Device code flow at step 5) to disable the “continue on another device” hand-off.

A note on licensing: Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium and in E3/E5. The sign-in risk policies and continuous access evaluation mentioned above draw on Entra ID P2 (E5, or as an add-on). Retain the report-only results and the final policy configuration — that record is your Rule 206(4)-7 examination evidence that the control is in place and reasonably designed.

Sources for this section: FBI / IC3 Alert I-052126-PSA; Microsoft Learn, “Block authentication flows with Conditional Access policy.”

How to tell if you’ve already been hit

• Sign-in logs showing device-code-flow authentications you can’t account for.
• Sign-ins from unexpected IP addresses, geographies, or hosting providers (ASNs).
• Newly registered devices and active sessions on accounts that the user doesn’t recognize.
• Suspicious inbox rules (auto-forward to external addresses, rules that quietly move or delete security alerts), unexpected OAuth application consents, and new mailbox delegations — all common post-takeover persistence.

Preserve the evidence as you find it: lure email headers and body, sign-in records (time, IP, location), and the list of unauthorized devices and sessions. That single package is both your IC3 report and your Regulation S-P incident documentation.

If you confirm a compromise

• Contain. Revoke the user’s sessions and refresh tokens, remove unrecognized devices and active sessions, reset credentials, and audit for attacker persistence (inbox rules, OAuth grants, delegations).
• Report. File with the FBI’s Internet Crime Complaint Center at ic3.gov with the evidence package above.
• Comply. Run your Regulation S-P incident response procedure and assess the customer-notification trigger. Document the determination and the reasoning either way — examiners want to see a deliberate, evidence-based decision, not silence.

The bottom line — and how to confirm you’re covered

Reading an advisory and being able to prove your own tenant is configured against it are two different things. The defensible answer to “are we protected against this?” is no longer “we have MFA.” It is: device code flow is blocked by Conditional Access, the exceptions are documented, and we can detect token-based access. Most firms cannot say that today — not because the controls are hard, but because no one has gone and checked.

Confirming it is exactly what a focused Microsoft 365 configuration audit does. MTradecraft’s risk assessments and threat-detection processes test the live Entra configuration against the techniques the FBI and SEC examiners are now naming, identify where the gaps actually are, map each finding to the controlling rule, and hand you the evidence — the policy settings, the audit results, the finding language — that holds up in an examination file. If you’d rather know than assume, that’s the engagement. The point isn’t a longer control list; it’s protecting client data, staying out of an enforcement posture, and being able to demonstrate both.

For reference, the kind of finding such a review produces reads like this:

FINDING. The firm’s Microsoft 365 (Entra ID) tenant permits the OAuth 2.0 device authorization grant (“device code flow”) for all users, and no Conditional Access policy restricts it. This exposes the firm to password-less, MFA-bypassing account takeover of the type described in FBI / IC3 Alert I-052126-PSA (21 May 2026).

RECOMMENDATION. Implement a Conditional Access policy blocking device code flow for all users, preceded by a sign-in-log audit to identify and narrowly except documented business dependencies. Exclude designated break-glass accounts and monitor them. Retain the policy configuration and audit results as examination evidence.

REGULATORY MAPPING. SEC Rule 206(4)-7 (compliance program reasonably designed against known threats); Regulation S-P (incident detection, response, and customer notification); Rule 204-2 (integrity and confidentiality of required records); Regulation S-ID (account-access red flags).

Sources

1. FBI / Internet Crime Complaint Center (IC3), Public Service Announcement, Alert I-052126-PSA — “Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens,” 21 May 2026. ic3.gov/PSA/2026/PSA260521
2. Cybersecurity & Infrastructure Security Agency (CISA), “Phishing Guidance: Stopping the Attack Cycle at Phase One.”

Brian Hahn is the founder and principal consultant of MTradecraft LLC (Dallas, TX), an independent cybersecurity compliance and corporate intelligence consultancy serving SEC-registered investment advisers.

BrainTrust members: the step-by-step Conditional Access policy above is the whole checklist — copy it straight into your tenant. And if you’d like us to confirm your own tenant actually blocks this — and produce the exam-ready evidence that it does — a Microsoft 365 configuration audit is the fastest way to find out.

This article is provided for informational purposes and is not legal advice.