Seven Microsoft 365 service accounts fell because a password guess was enough. According to The Hacker News, citing Proofpoint, UNK_CondorFiltration used TeamFiltration from 1,487 AWS EC2 IPs to password-spray more than 5,700 accounts across 28 Chilean retail and finance tenants in late July and August 2026. All seven compromised identities were unmanaged functional or service accounts with default or never-rotated passwords and no multi-factor authentication. Six of seven broke within about seven minutes. Closing that single-factor non-human login stops the cloud session from existing. Post-auth app use and token requests after a successful password login are residual containment, not another login-factor story.
What the Chilean M365 spray actually hit
Proofpoint’s disclosure, reported on 24 September 2026, describes three spray waves against Microsoft 365 tenants concentrated in Chilean banking and retail. Source traffic came from 1,487 unique AWS EC2 addresses. Early waves hit major banks at roughly 100 to 120 unique accounts per day, then peaked near 1,520 accounts on 27 July against another financial institution. The August wave peaked near 1,560 accounts on 15 August against a major retailer that alone drove 78.3% of observed authentication events.
The open-source TeamFiltration framework automated the guessing. Proofpoint previously described a separate cluster, UNK_SneakyStrike, that also abused TeamFiltration at cloud scale. UNK_CondorFiltration is a different 2026 campaign. The shared lesson is tooling that finds accounts still willing to accept one shared secret.
No phishing page, device-code coach, or helpdesk reset appears in the public initial-access story. The operator sprayed until authentication succeeded. Public reporting does not name the legal entities behind the 28 tenants beyond Chilean retail and finance context. Public reporting does not establish confirmed data exfiltration from sign-in events alone. Public reporting does not confirm persistence beyond continued cloud app use.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: how TeamFiltration sprayed seven MFA-less Chilean M365 service accounts.
Why single-factor service accounts lost at login
Initial access was a credential problem. Authentication had not finished when the spray started. The seven accounts still accepted a password as the only factor. IT had provisioned default or never-rotated secrets for convenience. Nobody rotated them. Nobody required a second factor on those functional paths. Six of seven compromises landed inside about seven minutes, which fits a small shared default set rather than a long random walk. Password spray completed sign-in because there was nothing else to fail.
That is not “MFA bypassed.” MFA was never on the path. Employee-centric MFA programs that ignore non-human identities leave exactly this hole. A forgotten service account with a cloud mailbox, OneDrive, Teams, or Graph rights is still a workforce identity path. Spray does not need a clever kit when the account was never finished.
Lateral movement and app probing were token problems. Within roughly two minutes of a successful login, the operator moved through a German VPN, opened Office, OneDrive, and Teams, and probed a corporate SAML VPN endpoint shaped like vpn.[redacted].cl/SAML20/SP, plus Azure Portal, SharePoint Online, and Microsoft Graph API token requests. Those steps used sessions and tokens the identity platform had already issued. No login control revokes a session that exists because the password alone was enough.
Data access and persistence are only partly documented. Compromised service accounts could reach Office, OneDrive, and Teams. Public reporting does not establish volume or type of data taken. Public reporting does not confirm a successful SAML VPN breach, only probing. No attacker MFA enrollment or helpdesk reset is described.
| Phase | What was abused | Login MFA verdict |
|---|---|---|
| Initial access | Default service-account password, no MFA | Preventable if every path demands a non-replayable factor |
| Lateral / probe | Issued M365 session, Graph token requests, SAML probe | Outside login MFA; needs revoke and session controls |
| Data access | Possible app use on valid session | Not proven as exfiltration; still post-auth |
| Persistence | Continued cloud app use only | Not confirmed beyond that |
SSO and federation amplify the credential miss. One valid Microsoft 365 identity is not a single-app problem. It is a skeleton key for every workload that trusts the same session fabric. Classic SSO auto-login collides with zero-trust language that claims never trust, always verify at each boundary.
Stopping non-human spray before a cloud session exists
Prevention value sits only at the credential phase. Require phishing-proof, device-bound proof on every interactive workforce and non-human cloud login that can mint a session, or remove interactive cloud sign-in from service accounts that do not need it. Password spray then guesses a secret that is no longer sufficient to authenticate.
Device-bound credentials change the surface. There is no central password database worth spraying for those paths, and no OTP, SMS code, or push approval to satisfy from a remote EC2 fleet. The private key stays on enrolled hardware. The server holds public keys. A correct password guess, if a password even remains anywhere adjacent, does not complete origin-bound authentication by itself. MFA 2.0 is that phishing-proof model: same-device, hardware-bound signatures with no transferable factor at login.
That is prevention, not detection: stop the session from being minted, rather than hoping analytics notice Graph probes two minutes later. Fooling a spray bot into a single-factor service login is easy at cloud scale. Planting malware on an already-logged-in machine after a legitimate session is a harder, separate problem.
Passkeys and FIDO2 put a key pair on the enrolled device. The private key never leaves hardware. Each sign-in produces an origin-bound signature a remote spray host cannot forge by guessing a shared secret. Industry language correctly calls that phishing-resistant at the login act: there is no reusable OTP to relay and no password database entry that completes authentication alone. On a generic enterprise identity provider that only accepts hardware-bound signatures for cloud apps, TeamFiltration-style password spray against those paths fails because a password is not the authenticator. That hardens authentication. It is still the login stage only unless enrollment and recovery are equally clean.
FIDO2 and passkeys are phishing-resistant at authentication. If provisioning still plants a default password, leaves MFA off, or allows a phishable recovery factor to stand up a new device later, the lifecycle reopens a transferable secret. Public reporting on UNK_CondorFiltration does not show helpdesk reset or attacker MFA enrollment. The documented failure was earlier: identities born with default secrets and no second factor. Phishing-proof coverage means no phishable factor at registration, device onboarding, authorisation, authentication, or decommissioning, including when non-human accounts are first created. Enrolment policy is what keeps a service account from shipping with a sprayable password as its only door.
When federation is in play, prefer Secure Explicit Sign-On over classic SSO. SSO issues one shared session many apps trust, so one stolen or minted token becomes multi-app access. Secure Explicit Sign-On keeps the same one-tap user experience while authenticating each application with its own fresh, device-bound signature. No shared replayable federation cookie sits ready for Office, SharePoint, Teams, and Graph as one package. That shrinks blast radius after any residual endpoint compromise. It does not pretend login MFA undoes tokens already issued.
Phishing-proof controls do not stop malware on a machine that already holds a legitimate session, and they do not revoke Graph or OAuth tokens minted after a completed password login. Containment still needs continuous access evaluation, explicit revoke, short lifetimes as hygiene (not as a substitute for prevention), and monitoring of abnormal non-human app use. Closing the phishable, single-factor login is the prevention claim. Revoke remains hygiene for everything after a real session exists.
Non-human identity inventory is mandatory for this class of failure. Every functional account that can reach Microsoft 365 apps is in scope. Default passwords at provisioning are not a niche ops issue. They are an authentication design failure. Either the account authenticates with hardware-bound proof, or it should not accept interactive cloud sign-in at all.
Key Takeaways for Defenders
- Inventory every Microsoft 365 functional and service account that can sign in interactively; treat forgotten non-human identities as first-class attack surface.
- Kill default and never-rotated passwords on those accounts, or disable interactive cloud sign-in where a human never needs the path.
- Require device-bound, phishing-proof authentication on every remaining workforce and non-human login that can mint a cloud session.
- Assume one valid M365 session reaches Office, OneDrive, Teams, SharePoint, and Graph; plan revoke and continuous access evaluation before the next spray wave.
- Do not equate sign-in or app-use telemetry with proven exfiltration; still investigate Graph and file access after any non-human compromise.
The next spray will not wait for a phished employee. It will walk the accounts nobody owns. Make those paths incapable of minting a session from a password alone, and the two-minute pivot never starts.
FAQ
Would phishing-proof MFA have stopped the UNK_CondorFiltration TeamFiltration spray?
Yes at initial access, if every compromised path had required device-bound proof instead of a password alone. UNK_CondorFiltration password-sprayed Microsoft 365 service accounts that had default or never-rotated passwords and no MFA. Phishing-proof controls on those non-human logins would have blocked minting the cloud session from a guessed secret. Login MFA would not have undone Office, OneDrive, Teams, Graph, or SAML probing after a session already existed.
How should defenders protect Microsoft 365 service accounts from password spray?
Defenders should inventory unmanaged functional accounts, remove default passwords, and either require device-bound authentication on interactive cloud sign-in or disable interactive sign-in entirely for pure automation identities. The UNK_CondorFiltration campaign compromised seven such accounts across Chilean retail and finance tenants because those controls were missing. Spray volume from thousands of AWS EC2 IPs only works when the account still accepts a single shared secret.
Does MFA 2.0 use classic SSO for Microsoft 365 style app access?
No. MFA 2.0 does not recommend classic SSO as the architectural answer when one stolen or minted session unlocks many apps. It uses Secure Explicit Sign-On: the user still gets one-tap convenience, but each application receives its own fresh, device-bound signature instead of trusting one shared federation cookie. In a campaign like UNK_CondorFiltration, that design shrinks multi-app blast radius after any residual session problem without pretending login proof revokes tokens already issued.
Are passkeys enough to stop service-account spray like TeamFiltration?
Passkeys are phishing-resistant at login and stop remote password guessing from completing origin-bound authentication on paths that enforce them. They are not automatically enough if service accounts are provisioned with default passwords, left without strong factors, or recovered with phishable methods. MFA 2.0 is phishing-proof across the full identity lifecycle, which is the stronger bar for non-human accounts that often skip employee-centric MFA rollouts.
Did UNK_CondorFiltration prove data theft from the Chilean tenants?
Public reporting does not establish confirmed data exfiltration or a stolen record count for UNK_CondorFiltration. Proofpoint-reported activity shows seven compromised service accounts with access to Office, OneDrive, and Teams, plus probes of Graph and SharePoint. Sign-in and app-use events alone are not evidence that data left the tenants.
