Six of seven broken Microsoft 365 accounts fell within seven minutes. The passwords were defaults IT had provisioned and never rotated, and multi-factor authentication was never applied. According to The Hacker News, citing Proofpoint, UNK_CondorFiltration used the TeamFiltration framework from 1,487 AWS EC2 IP addresses to password-spray more than 5,700 Microsoft 365 accounts across 28 Chilean retail and finance tenants in late July and August 2026. Seven unmanaged functional or service accounts were compromised. All seven held default or never-rotated passwords and no MFA. Public reporting does not establish that sign-in events equal confirmed data theft.
How TeamFiltration hit 28 Chilean tenants
Proofpoint’s disclosure, reported on 24 September 2026, frames UNK_CondorFiltration as a multi-wave spray against Microsoft 365 tenants concentrated in Chilean banking and retail. Activity ran from late July through mid-August 2026. Source traffic came from 1,487 unique AWS EC2 addresses, a volume pattern that spreads lockout risk and muddies simple geo blocks.
The first observed wave, from 21 to 24 July 2026, hit two major Chilean banking institutions at roughly 100 to 120 unique accounts per day. A second wave, from 26 to 28 July, peaked near 1,520 accounts on 27 July against another major Chilean financial institution. The third wave, from 13 to 16 August, peaked near 1,560 accounts on 15 August against a major Chilean retailer. That retailer alone accounted for 78.3% of all observed authentication events in the campaign, according to the same reporting.
TeamFiltration is an open-source penetration-testing framework previously tied to large cloud-tenant sprays. Proofpoint earlier described a related cluster, UNK_SneakyStrike, that used the same tooling against more than 80,000 user accounts across hundreds of organizations. UNK_CondorFiltration is a separate campaign. The shared framework is the useful defender takeaway: automated password guessing at cloud scale, aimed at accounts that still accept a single shared secret.
No phishing page, device-code coach, or helpdesk reset appears in the public account of initial access. The operator guessed passwords until authentication succeeded. That is credential-phase access in the simplest form.
Why seven service accounts fell in minutes
Every compromised identity was an unmanaged functional or service account, not an individual employee mailbox. Proofpoint’s line, via The Hacker News, is blunt: the campaign compromised 7 accounts, all of which were unmanaged functional or service accounts rather than individual employee accounts, highlighting a critical exposure gap around forgotten, non-human identities carrying default or unrotated passwords and no MFA.
Six of the seven breaks landed inside about seven minutes. That timing fits a small set of shared or default passwords rather than a long random walk through unique secrets. IT had provisioned the passwords for convenience. Nobody rotated them. Nobody put a second factor on the path. Password spray did the rest.
| Control on the account | What Proofpoint observed | Why spray worked |
|---|---|---|
| Password hygiene | Default or never-rotated secrets | One good guess completed login |
| MFA on the service account | None applied | No second factor existed to fail |
| Account ownership | Unmanaged functional/service IDs | Forgotten non-human paths stayed open |
| Monitoring focus | Employee-centric assumptions | Spray traffic still minted sessions |
SSO and app federation then did what they always do after a valid cloud login. One successful password on a Microsoft 365 identity is not a single-app problem. It is a skeleton key for every workload that trusts the same session fabric.
Public reporting does not name the legal entities behind the 28 tenants beyond Chilean retail and finance sector context. Public reporting also does not establish individual employee mailbox compromise in this campaign. The documented foothold sat on the forgotten accounts.
What the operator did after the password worked
Authentication was already finished when the interesting part of the timeline starts. Within roughly two minutes of a successful login, the operator moved through a German VPN and opened Office, OneDrive, and Teams on the compromised service accounts. The same window included probes against a corporate SAML VPN endpoint in the form vpn.[redacted].cl/SAML20/SP, Azure Portal, SharePoint Online, and Microsoft Graph API token requests.
Those steps are post-authentication work on tokens and sessions the identity platform had already issued. Login-time MFA cannot revoke a session that exists because the password path had no MFA to enforce. Containment after that point is revoke, continuous access evaluation, short-lived tokens as hygiene, and detection of abnormal Graph and app-use patterns. None of that undoes the fact that the first factor alone was enough to mint the session.
Proofpoint’s own framing, again via The Hacker News, lands on the structural gap rather than a glamorous exploit: the UNK_CondorFiltration campaign shows that one of the weakest links in an enterprise identity perimeter is often not a phished employee or a zero-day exploit. It is the forgotten account. Service accounts provisioned for convenience and never revisited are a structurally unprotected attack surface.
Public reporting does not establish volume or type of data taken. Sign-in and app-use events alone are not proof of exfiltration. Public reporting does not confirm persistence beyond continued use of the compromised cloud apps. No helpdesk password reset, no attacker MFA enrollment, and no additional backdoor are described. The SAML VPN endpoint was probed; public reporting does not establish a successful VPN breach.
The blast radius is still ugly on paper. A service account that can reach Office, OneDrive, Teams, Graph, and SharePoint is a high-value non-human identity. Federation multiplies whatever that identity can already touch. Zero-trust language that still auto-trusts a single cloud session across many apps collides with the reality of one guessed password.
Defenders who only hunt employee phishing will miss this class of failure. Inventory every non-human Microsoft 365 login path. Kill default passwords. Require a real second factor on service and functional accounts, or remove interactive cloud sign-in from them entirely. Spray campaigns do not need a clever kit when the account was never finished.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: how non-human identity controls stop service-account password spray before a cloud session is minted.
FAQ
How did UNK_CondorFiltration get into the Chilean Microsoft 365 tenants?
UNK_CondorFiltration got in by password-spraying Microsoft 365 accounts with the TeamFiltration framework from 1,487 AWS EC2 IPs. According to The Hacker News citing Proofpoint, more than 5,700 accounts across 28 Chilean retail and finance tenants were targeted in late July and August 2026, and seven unmanaged functional or service accounts with default or never-rotated passwords and no MFA were compromised.
Were employee mailboxes the accounts that fell in the TeamFiltration campaign?
No. Public reporting on UNK_CondorFiltration states all seven compromised accounts were unmanaged functional or service accounts, not individual employee accounts. The exposure gap was forgotten non-human identities left with weak passwords and no multi-factor authentication.
Did the attackers steal customer or employee data from the Chilean tenants?
Public reporting does not establish confirmed data exfiltration or a stolen record count for UNK_CondorFiltration. Compromised service accounts had access to Office, OneDrive, and Teams, and the operator probed Graph and SharePoint, but sign-in and app-use events alone are not evidence that data left the tenants.
Why did multi-factor authentication not stop the TeamFiltration password spray?
Multi-factor authentication did not stop the spray because MFA was never applied on the seven service accounts that fell. The initial access path was a successful password guess on accounts that still accepted a single factor. After login, the operator held issued cloud sessions and token requests; no login control can undo authentication that already completed without a second factor.
Is UNK_CondorFiltration the same campaign as UNK_SneakyStrike?
No. UNK_SneakyStrike is an earlier Proofpoint-described cluster that also abused TeamFiltration at large scale against cloud tenants. UNK_CondorFiltration is a separate 2026 campaign against Chilean Microsoft 365 tenants. The shared tooling is TeamFiltration; the incidents should not be conflated.
