TeamFiltration Campaign Exploited Default Passwords to Breach Microsoft 365 Accounts

The TeamFiltration operation, tracked under the codenamed UNK_CondorFiltration by Proofpoint researchers, represented a large-scale credential-based attack against enterprise cloud infrastructure. The campaign originated from approximately 1,487 unique AWS EC2 instances that acted as proxy points for the attackers. Rather than deploying sophisticated malware or zero-day exploits, the attackers simply tried common or default credentials against Microsoft 365 login portals until they gained access. The targeting pattern was narrow but deep: the campaign focused on seven successfully compromised accounts within organizations across 28 different Microsoft 365 tenants, predominantly in the Chilean retail and financial sectors.

The use of disposable AWS infrastructure suggests a well-resourced operation with enough budget to run thousands of attacker-controlled instances without concern for cost. This is typical of teams operating from jurisdictions where AWS account takeover or mass instance renting carries minimal legal risk. The scale of the attempt (5,700 accounts probed across the tenants) versus the number of successful compromises (seven confirmed accounts) indicates that many organizations had already implemented basic protections like conditional access policies or MFA, which stopped the attackers cold.

The success of TeamFiltration against seven accounts illustrates a persistent vulnerability in how organizations onboard and manage cloud identities. Default credentials typically occur in three scenarios: accounts created by automated provisioning scripts that set a temporary password without forcing a change on first login, service accounts that never had passwords rotated because administrators assumed they were secure behind a firewall, and shared accounts where multiple users never established individual identity management.

Microsoft 365 environments that lack proper identity governance often inherit these weak-credential accounts from on-premises Active Directory migrations or legacy applications. An attacker who gains access to a default credential has immediate read access to email, calendar, contacts and any shared files the account can reach. From this position, the attacker can harvest email threads, business intelligence, vendor lists and financial data. Worse, a compromised account inside a trusted tenant can pivot toward other cloud services, on-premises systems and partner networks that trust the organization's identity provider.

The use of 1,487 separate AWS EC2 instances from which the TeamFiltration team operated is a deliberate evasion tactic. By distributing the login attempts across thousands of source IP addresses, the attackers avoid triggering rate-limiting rules and IP-based blocklists that would normally stop a brute-force attack. This also complicates forensic analysis because each individual IP address may show only a handful of login attempts, making it harder for security analysts to spot a pattern without aggregating across multiple tenants and security logs.

The reliance on AWS infrastructure raises questions about the attackers' identity and resources but stops short of confirming their location or intent. The focus on Chilean financial and retail institutions suggests either local threat actors with regional motivation or a broader group that selected these sectors based on perceived security posture or business opportunity. Proofpoint's disclosure did not reveal whether the seven compromised accounts remained under attacker control or had been remediated.

Default password attacks succeed because many organizations do not enforce a comprehensive onboarding workflow that requires password change on first login. Additionally, shared accounts created for legacy applications or service purposes often bypass modern identity protocols. Conditional access policies that require MFA or device compliance can block an attacker using correct credentials from an unfamiliar location or device, which likely explains why the success rate was low relative to the scale of the campaign.

Organizations that do not maintain an inventory of all Microsoft 365 accounts, particularly service and shared accounts, cannot identify which ones are at risk. Many finance and retail teams operate temporary accounts for seasonal staff or third-party vendors without deprovisioning them after the contract ends. Each orphaned account represents a weak point where a default or rarely-changed credential may still work.

If your organization uses Microsoft 365, protect yourself against similar campaigns:

1. Audit all Microsoft 365 user accounts and identify any that have never had a password change since creation or migration
2. Query Azure AD / Entra ID logs for accounts that have not performed interactive login in the past 90 days and consider deprovisioning them
3. Enforce conditional access policies that require multi-factor authentication for all users, with no exceptions for service accounts
4. Disable legacy authentication protocols (Basic Auth, IMAP, POP, SMTP AUTH) if they are not explicitly required by business-critical applications
5. Enable Azure AD sign-in risk policies to flag and block login attempts from unfamiliar locations or devices
6. Require password change on first login for all new and migrated accounts
7. Establish a quarterly account hygiene review process to identify and remediate orphaned service accounts
8. Implement passwordless authentication (Windows Hello for Business, FIDO2 keys or phone sign-in) for high-risk accounts

The TeamFiltration campaign confirms that attackers still profit from basic security oversights. A credential-based breach does not require advanced technical skills, and the attacker does not need to maintain presence or develop malware once they have the password. Email access alone gives them weeks or months to extract business data before detection. The fact that this campaign targeted financial and retail sectors specifically suggests that attackers recognize these verticals as having high-value information and potentially less mature security practices than technology or government organizations.

The breach also demonstrates that scale matters. By running thousands of AWS instances, the attackers could distribute their attempts widely and increase their odds of finding accounts without MFA or conditional access. This is not a sophisticated attack; it is a volume attack. Organizations with mature cloud security postures will have stopped this campaign before a single account was breached. Organizations without MFA will have found their email systems compromised.

What is TeamFiltration and why should I care?

TeamFiltration is the name given to a campaign of attackers who systematically target Microsoft 365 accounts by trying common credentials. If your organization uses Microsoft 365 for email and collaboration, you are potentially in scope for a similar attack if your accounts are not protected with MFA and conditional access policies.

Did the attackers use malware or was it purely credential-based?

The attack was purely credential-based; no malware was involved. The attackers simply guessed or obtained weak passwords and logged in. This makes the attack harder to detect with traditional antivirus or endpoint detection tools because the attacker appears to be a legitimate user.

How can I tell if my Microsoft 365 account was compromised in this campaign?

You cannot assume you were affected unless your organization was one of the 28 tenants targeted. If your organization uses Microsoft 365, contact your IT or security team and ask whether conditional access policies and MFA are enforced organization-wide. Request a review of sign-in logs for your account to look for logins from unfamiliar locations.

What does Proofpoint recommend for defense?

Proofpoint emphasized that organizations should enforce multi-factor authentication for all users and implement conditional access policies that block sign-ins from unusual locations or devices. Disabling legacy authentication protocols also reduces the attack surface.

Why did the attackers use AWS instances to launch the attack?

Using thousands of AWS EC2 instances distributed the login attempts across different source IP addresses, which evaded rate-limiting and IP-based blocklists. This tactic made the attack harder to spot and block because no single IP address showed abnormal activity.

Source: The Hacker News