UNK_CondorFiltration: Proofpoint's numbers on a Microsoft 365 spray
Proofpoint published its analysis on September 22, 2026. It tracks the operator as UNK_CondorFiltration, and the campaign targeted over 5,700 accounts across 28 Microsoft 365 tenants in Latin America, focusing intensively on Chilean organizations. eSecurityPlanet, The Hacker News and Dark Reading have all reported the same core figures from Proofpoint's research. The Hacker News notes that the activity originated from 1,487 unique AWS EC2 source IP addresses.
The published statistics show how uneven the targeting was. Proofpoint logged 5,714 unique accounts across 28 Microsoft 365 tenants, generating 32,825 authentication events. One organization took most of the traffic: a major retailer that accounted for 78.3% of observed events. Proofpoint's target breakdown puts 3,038 accounts (53.2% of the total) at that retailer. The largest financial target had 1,873 accounts. A second bank saw only about 110 accounts probed, but those accounts took 1,536 authentication attempts.
Proofpoint says the second bank's figures point to deliberate targeting. More than half of those 1,536 attempts, 782 of them, went after 57 senior accounts, including several managers. None of the bank accounts were confirmed compromised.
Proofpoint's timeline has the banks first and the retailer last
The campaign came in three bursts over 26 days. Some early write-ups got the order wrong: they placed the retailer in the opening wave and had the attacker moving from a financial institution to the retailer only at the end. Proofpoint's primary report tells it differently, and Dark Reading's account matches Proofpoint.
- From July 21 to 24, a small opening wave probed roughly 100 to 120 unique accounts a day, mainly at two major Chilean banks.
- From July 26 to 28, volume jumped to about 1,520 accounts on July 27 before dropping sharply. This wave targeted a third Chilean financial institution.
- After about two weeks of quiet, a final burst ran from August 13 to 16 and peaked at around 1,560 accounts on August 15. This wave went after the major retailer, and all seven confirmed compromises and all observed post-access activity happened there on August 14 and 15.
Dark Reading's summary of the early phase agrees: the operator probed hundreds of M365 accounts associated with two major banking institutions in Chile. A week later, it probed thousands at a third financial institution in the same country. Proofpoint doesn't name any of the affected organizations.
Why the seven service accounts fell and employee accounts held
Proofpoint's explanation for the results is simple. The attacker likely sprayed accounts with default passwords - credentials provisioned by IT and never rotated. Against personal employee accounts, this approach yielded no confirmed compromises, since users are required to change passwords from time to time. Against dormant service accounts, it worked.
Password spraying tries a small set of likely passwords against a large number of accounts. It's the opposite of hammering one account with many guesses. Each account sees only a few failures, which helps the attacker stay under lockout thresholds. The technique only works when some accounts still have the guessed password. That describes accounts created with a standard starting password that nobody ever reset.
When Proofpoint reviewed the login history of the seven compromised accounts, none had any legitimate user sessions in the period its telemetry covered. The researchers say the accounts had been created for business tasks such as managing tickets, approving vendor payments, running a point-of-sale system and handling requests. After that they sat idle but stayed active in the directory. Proofpoint doesn't say which task each compromised account performed.
The timing supports the default-password theory. Six of the seven accounts were compromised within seven minutes, which Proofpoint says points to a shared or default password set from the organization's provisioning process rather than credential stuffing aimed at individuals. That conclusion is Proofpoint's inference from the timing, not something it directly observed. Still, it fits everything else in the report. Proofpoint's statement, quoted by The Hacker News, calls the exposure a critical exposure gap around forgotten, non-human identities carrying default or unrotated passwords and no MFA.
Proofpoint director of threat research Yaniv Miron told Dark Reading the problem is common. He said organizations create service accounts for specific purposes, and then when that purpose is no longer needed, nobody's making sure that user is locked out or disabled.
TeamFiltration automates the Microsoft 365 attack from enumeration to exfiltration
TeamFiltration was written by Melvin Langvik of TrustedSec as a penetration-testing tool for Microsoft 365 environments and released publicly at DEF CON 30. Dark Reading describes it as a kit that lets ethical and non-ethical hackers alike enumerate a tenant's accounts and brute-force them while rotating infrastructure to avoid IP blocks.
Proofpoint splits the tool into four modules:
| Module | What Proofpoint says it does |
|---|---|
| Enumeration | Checks whether accounts exist at around 300 emails per second through the Teams API, without triggering lockouts |
| Spray | Tests common or targeted passwords across enumerated accounts, rotating AWS regions through FireProx to get around IP-based blocking |
| Exfiltrate | After login, automatically collects email, Teams chats, OneDrive and SharePoint files, and Graph API data |
| Backdoor | Gives interactive OneDrive access to browse, download and quietly replace files, so a malicious file can run the next time a user opens the original |
The AWS rotation explains why a campaign against 28 tenants came from nearly 1,500 EC2 addresses. Blocking individual IPs does little against a tool built to keep changing its source.
The tool also gives itself away. TeamFiltration's default configuration includes a hardcoded user agent string from a 2020 Microsoft Teams desktop client. The string is Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.30866 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36. Proofpoint says modern legitimate Teams clients don't send it. That makes it a cheap hunting signal, as long as the operator hasn't changed the default.
This is Proofpoint's second public TeamFiltration case. In June 2025, Proofpoint detailed another threat cluster dubbed UNK_SneakyStrike that targeted over 80,000 user accounts across hundreds of organizations' cloud tenants with the same framework. SneakyStrike was spread across many regions. CondorFiltration is concentrated in Chile, which Proofpoint calls a notable change.
What the attacker reached: Teams, OneDrive, Azure Portal and a Graph token
On most of the seven accounts, the only activity after login was sign-ins to Microsoft Teams, Microsoft Office and OneDrive, all from the same AWS infrastructure. Proofpoint says the pattern matches TeamFiltration's auto-exfiltration mode, which pulls email, Teams conversations and OneDrive files right after a successful login. Its analysts also added a caveat: eSecurityPlanet notes that the researchers cautioned that sign-in logs alone could not confirm that data was actually exfiltrated. Some coverage, including Dark Reading's headline, describes the data theft as fact. Proofpoint's own report stops short of that. The access pattern points to exfiltration, but the logs don't prove it happened.
One account shows what a determined operator does next. According to Proofpoint, within 90 seconds of the successful compromise, the attacker switched from the TeamFiltration infrastructure to a German VPN node and began a post-access sequence: probing the corporate VPN, accessing Azure Portal, browsing SharePoint, and triggering a Microsoft Graph API token request. Proofpoint's log timeline, in UTC on August 14 or 15:
- At 18:41:41, a Microsoft Teams sign-in from AWS address 3.101.157.240 marks the first compromise through the password spray.
- At 18:42:30, an attempt on the organization's SAML-based corporate VPN portal from 149.88.104.19, a German VPN exit, failed. Proofpoint attributes the block to MFA or Conditional Access.
- At 18:43:29, a sign-in to the Azure Portal triggered an MFA enrollment prompt, which shows the account had no MFA set up.
- At 19:03:59, the attacker reached OfficeHome, the Microsoft 365 portal.
- At 19:07:23, the attacker accessed SharePoint Online. Proofpoint says this could have been document reconnaissance, exfiltration or delivery of a backdoor, and it doesn't claim to know which.
- At 19:07:35, SharePoint Online Web Client Extensibility requested an access token for Microsoft Graph or external APIs.
The corporate VPN attempt is the one clear success for defenders in the report. It failed because a control stood in the way, which suggests that at least one resource in that tenant enforced MFA or Conditional Access where the Microsoft 365 sign-in didn't. The Azure Portal enrollment prompt shows the other side of the problem: the account had never been registered for MFA at all.
The Graph token request is important because Microsoft Graph is the API that sits in front of mail, files, Teams data and directory information across Microsoft 365. What a token can actually reach depends on the permissions behind it. Proofpoint recorded the request but not what the token was used for.
What this means for you in Entra ID and Microsoft 365
If you run a Microsoft 365 tenant, the job is to find every account that can sign in interactively but has no owner, then close it or lock it down. The attacker got nothing from accounts belonging to people who are forced to change passwords now and then. All of the damage came from accounts outside that routine.
Start with an inventory. List every functional, shared and service account in Entra ID. Record who owns it, what process it supports and when it last signed in legitimately. Disable accounts that have no owner or purpose. Proofpoint's defining finding was that the compromised accounts had no legitimate sign-in history at all, so an account that never signs in but is still enabled deserves an immediate look.
For accounts you keep, get automation off user-style password accounts wherever the platform allows. Microsoft documents managed identities as a way for Azure resources to get tokens from Entra ID using credentials Azure manages, so no password sits in code or in the directory waiting to be sprayed. Entra logs managed-identity and service-principal sign-ins in their own categories, separate from interactive user sign-ins. That separation is also useful for investigations: a plain user account running a script shows up in the user sign-in logs, not the workload logs. Any account that still needs a password and interactive sign-in should get a rotated, unique credential and be covered by MFA or Conditional Access. The failed VPN probe in Proofpoint's timeline shows that control working.
For hunting, the interactive user sign-in logs in the Microsoft Entra admin center show sign-in location and whether Conditional Access was applied, which covers most of what this campaign would leave behind. Look for bursts of failed sign-ins spread across many accounts, several successes close together, sign-ins from AWS EC2 ranges, the TeamFiltration user agent, and a country or network change within minutes of a first successful login. Proofpoint's campaign-specific indicators are the AWS ranges 3.101.0.0/16, 18.144.76.0/24 and 13.52.201.0/24, plus the German VPN address 149.88.104.19. Addresses like these go stale quickly, so treat them as leads, not blocklist material. If you query through Log Analytics, Microsoft notes that the TimeGenerated field is when the log entry was ingested; the actual sign-in time is in CreatedDateTime.
- Disable any enabled account in Entra ID that has no named owner, no documented purpose, and no legitimate sign-ins in recent history.
- Treat any service account still using its original provisioning password as compromised: reset it, then review its sign-in history before assuming it's clean.
- Move scripts and integrations to managed identities or other workload identities wherever the platform supports them, instead of running them under user accounts with passwords.
- Put every account that keeps interactive sign-in under MFA or Conditional Access, including shared mailboxes and point-of-sale or ticketing accounts that people assume nobody logs into.
- Search sign-in logs for the TeamFiltration user agent string, AWS EC2 source addresses, and clusters of successful sign-ins a few minutes apart.
- If you find a match, check for OneDrive, SharePoint, Azure Portal and Graph token activity after the first login, because sign-in records alone won't tell you whether data left the tenant.
The CondorFiltration campaign ran across the whole region, used a freely available tool, and reached into its victim's SharePoint within half an hour of the first successful login. What stopped it from going further was the one resource where the organization enforced a second factor. TeamFiltration has now shown up in two Proofpoint campaigns about a year apart. eSecurityPlanet also points to a separate Huntress-reported spray in June 2026 that generated 81 million login attempts, compromising 78 accounts across 64 organizations. Attackers are clearly still running these sprays at scale. Tenants that inventory and retire ownerless accounts before the next wave arrives won't give a spray like this anything to find.