Hackers have breached Microsoft 365 environments by targeting accounts that were still active but unmonitored. An old password and missing sign-in protections gave intruders a route into email, files, and cloud applications.
The campaign focused heavily on organisations in Chile, including a large retailer and financial institutions.
Rather than repeatedly guessing passwords for one person, the operator tested likely default passwords across many accounts, a technique seen in similar password spraying attacks, then used successful logins to explore cloud services.
Proofpoint analysts identified the activity as UNK_CondorFiltration, a campaign abusing TeamFiltration, a testing framework rather than a new malware strain.
Proofpoint said in a report shared with Cyber Security News (CSN) as source material that the operation hit 5,714 accounts across 28 Microsoft 365 tenants and produced seven confirmed compromises.
The numbers underline a narrow but serious weakness. None of the confirmed breaches involved personal employee accounts.
Every affected identity was a functional or service account, the kind created to process payments, run ticketing, support point-of-sale systems, or perform other routine tasks without a person regularly logging in.
Hackers Broke Into Microsoft 365 Through Forgotten Accounts
Researchers found that the seven compromised accounts had no earlier legitimate sign-in activity in the available records. Six were breached within seven minutes, a pattern that points to shared or unchanged default passwords rather than individually stolen credentials.
The accounts remained enabled, lacked clear ownership, and apparently had no multi-factor authentication, or MFA, to stop a valid password from being enough.
One retailer accounted for 25,715 of the campaign’s 32,825 authentication events, or 78.3 percent. The August 13 to 16 wave peaked at about 1,560 targeted accounts on August 15, and all seven confirmed compromises occurred at the retailer on August 14 and 15.
The pattern resembles a earlier TeamFiltration takeover campaign using the same framework against cloud identities. TeamFiltration can check whether accounts exist through the Teams API, test passwords at scale, and use cloud infrastructure to vary its source locations.
Following a successful sign-in, it can collect email, Teams messages, and OneDrive or SharePoint data. That makes an overlooked operational account particularly useful.
The findings point to practical safeguards. Organisations should inventory service accounts, assign an accountable owner, remove accounts that no longer serve a purpose, rotate any inherited credentials, and require MFA or a safer workload identity where possible.
Teams should also review conditional-access rules and sign-in logs for broad failures across many accounts, as coverage of Microsoft 365 spraying attacks also explains.
From Valid Login to Cloud Reconnaissance
The activity did not always end with a password check. For most affected accounts, researchers observed access to Microsoft Office, OneDrive, and Teams from the same cloud-hosted infrastructure.
That behavior is consistent with TeamFiltration’s automatic collection mode, though sign-in logs alone cannot prove that files or messages were removed.
In one case, the attacker changed to a German VPN node within 90 seconds of the initial compromise. The operator unsuccessfully probed the corporate VPN, then opened Azure Portal, OfficeHome, and SharePoint Online.
An MFA enrolment prompt during the Azure Portal visit indicated that the compromised account had not been configured for MFA.
The SharePoint access could have supported document discovery, data theft, or an attempt to place a harmful file where a trusted user might later open it.
A request for an access token through the SharePoint Online Web Client Extensibility application also suggested an effort to interact with Microsoft Graph or external application interfaces.
Similar post-login abuse has appeared in reports on hidden cloud mailbox rules, which can help intruders quietly retain visibility into business email.
Defenders should treat inactive accounts as an identity risk, not administrative clutter. Alerting on the distinctive user agent, password attempts from distributed cloud hosts, first-time sign-ins, and sudden access to sensitive apps can expose this type of intrusion early.
Blocking legacy or unnecessary sign-in paths and testing MFA coverage on non-human accounts can close the gap that this campaign exploited.
Indicators of compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| User agent | 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 | Hardcoded TeamFiltration default user agent used to identify the activity. |
| IP range | 3.101.0.0/16 | AWS EC2 infrastructure associated with password spraying. |
| IP range | 18.144.76.0/24 | AWS EC2 infrastructure associated with password spraying. |
| IP range | 13.52.201.0/24 | AWS EC2 infrastructure associated with password spraying. |
| IP address | 3.101.157.240 | Source of the initial Microsoft Teams compromise in the documented case. |
| IP address | 149.88.104.19 | German VPN node used for subsequent VPN probing and cloud application access. |
| Provider domain | amazon.com | Legitimate provider domain associated with the AWS attack infrastructure, not a malicious domain by itself. |
| Provider domain | cdn77.com | Provider attribution associated with the post-access IP, not a malicious domain by itself. |
| Provider domain | datacamp.co.uk | Additional provider attribution for the post-access IP, not a malicious domain by itself. |
| Redacted endpoint | vpn.[redacted].cl/SAML20/SP | Victim corporate VPN endpoint as printed in the source. Redaction prevents operational use. |
| Redacted URL | https://vpn.[redacted]/SAML20/SP | Corporate VPN target application identifier recorded in telemetry. Preserved exactly as published. |
| Application ID | 1fec8e78-bce4-4aaf-ab1b-5451cc387264 | Legitimate Microsoft Teams application accessed through all seven compromised accounts; useful for correlating suspicious activity. |
| Application ID | d3590ed6-52b3-4102-aeff-aad2292ab01c | Legitimate Microsoft Office application accessed through all seven compromised accounts. |
| Application ID | ab9b8c07-8f02-4f72-87fa-80105867a763 | Legitimate OneDrive SyncEngine application accessed through a subset of compromised accounts. |
| Application ID | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | Legitimate Azure Portal application involved in the documented post-compromise sequence. |
| Application ID | 4765445b-32c6-49b0-83e6-1d93765276ca | Legitimate OfficeHome application accessed through one compromised account. |
| Application ID | 00000003-0000-0ff1-ce00-000000000000 | Legitimate SharePoint Online application accessed during potential document reconnaissance. |
| Application ID | 08e18876-6177-487e-b8b5-cf950c1e598c | Legitimate SharePoint Online Web Client Extensibility application involved in an access-token request. |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC

