Microsoft 365 Password Spray and OpenBullet Credential Stuffing
| Attack type | Credential attacks: password spraying, credential stuffing |
| Threat actors | Unattributed. Part of the traffic runs OpenBullet / SilverBullet credential-stuffing configs, and a related toolset uses hosting (FranTech) also seen in the LSHIY campaign Huntress reported |
| Coverage since | October 30, 2026 |
| Platforms | Microsoft Entra ID, Microsoft 365 |
One attempt per address, and in the end, the right password. Since at least October 1, 2026, a password spray has worked through Microsoft 365 accounts from thousands of IP addresses, each used once or twice: too slow and too spread out for any threshold. It reached 42 of the 104 Microsoft 365 tenants Fluency monitors. When it guesses right, the sign-in usually fails at MFA or Smart Lockout, and the attacker keeps the password.
The threat
- Low and slow. In one tenant, 2,173 IP addresses in 30 days: 92% used once, none more than five times, and no address tried more than four accounts. The busiest networks include cloud and transit providers such as Alibaba, ColoCrossing, NTT, Amazon, Tencent, OVH and Cogent, and almost all of them geolocate to the US.
- One fixed client. The attempts carry the same truncated browser user agent, one no real browser sends. Others carry
<RndUA>, the unfilled placeholder of an OpenBullet / SilverBullet credential-stuffing config. - Aimed at Outlook on the web. The spray targets interactive browser sign-ins to Outlook on the web.
- The right password, stopped at the last step. About half the attempts end in Smart Lockout and the rest in wrong passwords. In October, the attacker entered the correct password for accounts in several Fluency customer tenants, and MFA or Smart Lockout stopped each sign-in.
- Then back with other tools. On accounts whose password it had, the attacker kept retrying from Bangladesh, India, Iraq, Thailand and the US, through Azure CLI, SMTP basic authentication and a Go client. Other toolsets hit the same accounts through the password-only (ROPC) sign-in of Azure CLI and Azure AD PowerShell, where MFA may not apply at all.
Why it gets past defenses
- IP rotation defeats IP thresholds. With one or two attempts per address, "many failures from one IP" rules and IP block lists never trigger.
- Few attempts per account. Each account sees a handful of tries spread over days, below brute-force thresholds.
- Microsoft's own detection needs Entra ID P2. Identity Protection's Password Spray detection and sign-in risk scoring exist only for P2-licensed users. In P2 tenants, Microsoft rated the correct-password sign-ins high risk. In the others, nothing flagged them.
- A failed sign-in looks like a defense that worked. A correct password that ends at an MFA prompt or in a lockout is easy to dismiss. But the attacker now knows the password, and once the lockout clears, it still works.
How Fluency catches it
- A correct password from a spray client. A sign-in from the spray's user agent or the OpenBullet placeholder that presents the correct password raises a high alert, whether it succeeded, hit MFA, was locked out or was blocked. Across 30 days of sign-ins in 104 tenants, these clients never had a successful sign-in, so a match is the attacker, not a user.
- A correct password, locked out, from a network the user never uses. When Smart Lockout refuses a sign-in that had the correct password, from a network the user has had no successful sign-in from in 30 days, Fluency raises a high alert, whatever the client. That keeps catching the attacker after it changes tools. A phone with an old saved password does not trigger it: it fails with the wrong password, from the user's own networks.
- A correct password held at Conditional Access. When Conditional Access blocks a sign-in right after the correct password, or holds a risky one at an MFA prompt it cannot pass, Fluency flags the password as compromised.
- No Entra ID P2 needed. The first two read the result of the password check, which every tenant's sign-in log records, so tenants without Identity Protection get the same coverage.
- Proven on the campaign. In its first day live, the new-network detection raised six alerts, all on accounts already known to be compromised, and caught two sign-ins that did not use the spray's user agent. Replayed on 30 days of sign-ins in 52 tenants, it raised about 60 alerts a month across all of them, almost all confirmed attacker sign-ins.
Detections included
| Detection | What it catches |
|---|---|
EntraID_Spray_Client_Correct_Password | A correct password from either spray user agent, whatever the sign-in's result. High. |
EntraID_Correct_Password_Lockout_New_Network | A correct password refused by Smart Lockout, from a network the user has had no successful sign-in from in 30 days. Any client. High. |
EntraID_Valid_Password_Blocked | Conditional Access blocking a sign-in right after the correct password, or holding a risky one at an MFA prompt it did not meet. Medium. |
EntraID_High_Risk_SignIn | A sign-in Entra ID Protection rates high risk. High. |
EntraID_SignIn_After_Block | A successful sign-in within two hours of a high-risk blocked attempt with the correct password, from another address. High. |
EntraID_Brute_Force_User | More than 15 failed sign-ins for one user in an hour, from any number of IPs. Medium. |
Where Microsoft Defender is connected, Identity Protection's own Password Spray and risky sign-in alerts arrive as behavior events too.
MITRE ATT&CK
| Tactic | Technique |
|---|---|
| Credential Access | T1110.003 Brute Force: Password Spraying |
| Credential Access | T1110.004 Brute Force: Credential Stuffing |
| Initial Access, Persistence | T1078.004 Valid Accounts: Cloud Accounts |
Get this coverage
The detections are on every Fluency instance and need the Entra ID sign-in logs, collected through Azure Event Hubs or Microsoft Graph. Entra ID sign-in logs require an Entra ID P1 or P2 licence; the spray-client and new-network detections need nothing more. Event Hubs also collects non-interactive sign-ins, which both new detections read.
Detection shortens the attacker's window; a password reset closes it. Pair the detections with prevention:
- Reset the password and revoke the sessions of every account with a correct-password sign-in you do not recognize, even if the sign-in failed.
- Block legacy authentication, and turn off SMTP AUTH for mailboxes that do not need it.
- Restrict Azure CLI, Azure AD PowerShell and the password-only (ROPC) flow to administrators.
- Require MFA for every user and every app, and make sure every account has an MFA method registered.
- For the indicators and queries to check your own tenant, see the advisory.
Not a customer yet? Start a free trial or book a demo.
Related
- MFA fatigue and password attacks: push bombing, brute force, and the sprayer who signs in from somewhere else after a blocked attempt.
- Advisory: Ongoing Microsoft 365 Password Spray: what Fluency observed, the indicators, and queries to check your tenant.
- Password-Spray Correct-Password Detections: the release notes, with each rule's full match conditions, what it does not cover, and triage guidance.