Hacking

UNK_CondorFiltration Hits 5,700 Microsoft 365 Accounts

Published  ·  6 min read

UNK_CondorFiltration

A TeamFiltration campaign tracked as UNK_CondorFiltration has been hitting Microsoft 365 tenants hard, with more than 5,700 accounts targeted across 28 tenants, and the activity has focused mainly on Chilean retail and financial institutions.

Proofpoint disclosed the details, and the numbers tell a story, because the attacks came from 1,487 unique AWS EC2 source IP addresses, which means the operator was spreading the spray across a wide pool of cloud hosts to avoid simple IP-based blocking.

But here's the part that really matters, out of 5,700 accounts targeted, only 7 were compromised, and every single one of them was an unmanaged functional or service account rather than a real employee account, so the story here isn't the scale of the attack, it's the shape of the exposure.

Quick Summary

What

Details

Campaign

UNK_CondorFiltration

Tool

TeamFiltration

Targets

5,700+ accounts, 28 M365 tenants

Compromised

7 accounts, all unmanaged service accounts

Source IPs

1,487 AWS EC2 addresses

Primary Target

Chilean retail and financial institutions

Three Waves, Three Targets

The campaign unfolded in three distinct waves from late July to August 2026, and one unnamed Chilean retailer absorbed 78.3% of all observed authentication events, so the targeting was deliberate rather than opportunistic.

  • The first wave ran from July 21 to 24, hitting roughly 100 to 120 unique accounts per day, and it was aimed at two major Chilean banking institutions.
  • The second wave ran from July 26 to 28, peaking at about 1,520 accounts on July 27 before dropping sharply, and it was aimed at another major Chilean financial institution.
  • The third wave ran from August 13 to 16, peaking at about 1,560 accounts on August 15, and it was aimed at a major Chilean retailer, which is where the seven compromises actually landed.

So the operator worked through a list of targets in sequence, escalating the volume each time, and the final target is the one that gave them a foothold.

Why Service Accounts Are the Weak Point

Proofpoint's assessment is that the threat actor likely sprayed accounts with default passwords, including credentials provisioned by IT teams and never rotated, and the activity mainly targeted dormant service accounts rather than personal employee accounts.

That distinction matters, because users are forced to change passwords from time to time, which means their credentials rotate naturally, but service accounts were provisioned to run business operations and then left unmonitored, while still carrying their original credentials.

Every successful compromise was tied to an unmonitored service account with a default password, and six of the seven compromised accounts were broken into within 7 minutes, which strongly suggests a shared or default password rather than individually targeted credential stuffing.

So the attacker didn't need clever tradecraft here, they just needed to find the accounts nobody was watching.

What TeamFiltration Actually Does

TeamFiltration is a legitimate cross-platform offensive framework, built for enumerating, spraying, exfiltrating, and backdooring Entra ID accounts, and it's open source, which means anyone can pick it up.

It lets an operator validate email accounts, test common or targeted passwords across enumerated accounts, harvest sensitive data, and gain covert interactive access to OneDrive, so it does most of the work for whoever is running it.

The framework has been used in malicious attacks before, and in June 2025, Proofpoint detailed another cluster called UNK_SneakyStrike that targeted over 80,000 user accounts across hundreds of cloud tenants using the same tool.

So this is a known toolkit being pointed at a fresh set of targets.

What Happened After the Compromise

Across most of the compromised accounts, the threat actor used the foothold to access Microsoft Office, OneDrive, and Teams, which is potentially indicative of data harvesting and exfiltration, though Proofpoint was careful to note that sign-in events alone cannot be taken as evidence of exfiltration.

Less than 2 minutes after a successful compromise, the operator pivoted to a German VPN node, then probed the corporate VPN, accessed the Azure Portal, browsed SharePoint Online, and initiated Microsoft Graph API token requests.

That pivot to a German exit node is a familiar pattern, because it separates the initial spray from the follow-on activity, so defenders looking only at the source IPs of the spray would miss the second phase entirely.

The Bigger Lesson

Proofpoint's conclusion is blunt, and it's worth repeating, because the campaign is a reminder 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, and they sit outside the normal password rotation cycles that keep user accounts safe.

So the fix isn't exotic, it's inventory, because you cannot protect accounts you don't know exist, and most organizations don't have a complete list of the service accounts their own IT teams created.

What You Should Do

  1. Inventory your service and functional accounts, and treat any account with a default or unchanged password as compromised until proven otherwise.
  2. Rotate credentials on service accounts and enforce MFA wherever the platform allows it.
  3. Monitor for spray patterns across many accounts from cloud IP ranges, especially AWS EC2, because that is what this campaign looked like on the wire.
  4. Watch for post-compromise pivots to VPN nodes in unexpected countries, since that is the second phase of this attack.
  5. Review sign-ins to Office, OneDrive, Teams, and Graph API token requests from accounts that normally stay dormant.
  6. Disable or delete service accounts that are no longer in use, because an unused account with a default password is a permanent liability.

The Bottom Line

UNK_CondorFiltration targeted more than 5,700 Microsoft 365 accounts across 28 tenants in Chile, and while only 7 were compromised, every one of them was a forgotten service account with a default password, so the campaign is less a story about a sophisticated attacker and more a story about the accounts organizations forget they own.

Quick Reference

Key Point

Detail

Campaign

UNK_CondorFiltration

Tool

TeamFiltration

Targets

5,700+ accounts, 28 tenants

Compromised

7 unmanaged service accounts

Source IPs

1,487 AWS EC2 addresses

Key Weakness

Default passwords on forgotten accounts

What to Do

  • Inventory service and functional accounts
  • Rotate credentials and enforce MFA
  • Monitor for cloud-IP spray patterns
  • Watch for VPN pivots to unexpected countries
  • Disable unused accounts
  • Review dormant account sign-ins

FAQ Section

What is UNK_CondorFiltration?

It is a TeamFiltration campaign that targeted over 5,700 Microsoft 365 accounts across 28 tenants, primarily focused on Chilean retail and financial institutions.

How many accounts were compromised?

Only 7 accounts were compromised, and all of them were unmanaged functional or service accounts, not individual employee accounts.

Why were service accounts the target?

Because they were provisioned to run business operations and then left unmonitored, while still carrying their original default credentials and no MFA.

What is TeamFiltration?

It is a legitimate open-source offensive framework for enumerating, spraying, exfiltrating, and backdooring Entra ID accounts, and it has been used in multiple malicious campaigns.

What should organizations do?

Inventory service accounts, rotate their credentials, enforce MFA, monitor for spray patterns from cloud IPs, and watch for post-compromise VPN pivots.

Source: The Hacker News
Professional Services

Explore Our Cybersecurity Services

Our insights are backed by hands-on service delivery. If your business needs professional cybersecurity support, our UK-based specialists are ready to help.

© 2016 – 2026 Red Secure Tech Ltd. Registered in England and Wales — Company No: 15581067