Proofpoint’s latest TeamFiltration reporting is a sharp reminder that cloud identity incidents do not always start with a polished phishing kit or a zero-day. Sometimes the weak point is much simpler: an old Microsoft 365 service account with a predictable password, no MFA, and no clear owner.

In late July and mid-August 2026, Proofpoint tracked an active campaign it calls UNK_CondorFiltration. The activity targeted more than 5,700 accounts across 28 Microsoft 365 tenants, with a heavy focus on Chilean organizations. The attacker used TeamFiltration-style tooling and infrastructure to spray credentials, validate accounts, and move into Microsoft cloud applications after successful sign-ins.

The most important finding is not the volume. It is the pattern of compromise: Proofpoint reported that all seven confirmed account compromises were unmanaged functional or service accounts with no prior legitimate login baseline, no MFA enforcement, and signs of default or predictable passwords that had never been rotated.

What happened

TeamFiltration is a publicly available offensive framework built for Microsoft 365 assessment work. In legitimate hands, it helps red teams test account enumeration, password spraying, and cloud data exposure. In attacker hands, the same automation can be used to identify accounts, test common passwords, and rapidly access Microsoft 365 data after a successful login.

Proofpoint observed the campaign unfold in multiple bursts between July 21 and August 16, 2026. The actor used AWS EC2 infrastructure for the spray activity and focused heavily on a major retailer and several financial institutions in Chile. Personal user accounts did not produce confirmed compromises. The successful logins came from dormant functional accounts used for business operations such as tickets, approvals, point-of-sale workflows, and request handling.

After access, Proofpoint observed activity against Microsoft Teams, Microsoft Office, OneDrive, Azure Portal, SharePoint Online, and a corporate VPN portal. In one case, the attacker switched from spray infrastructure to a German VPN node within 90 seconds, attempted corporate VPN access, triggered an MFA enrollment prompt in Azure Portal, and browsed SharePoint resources.

Why service accounts are the real story

Service accounts often sit in the worst possible security zone. They are important enough to keep enabled, but boring enough to be forgotten. They may have predictable names, long-lived passwords, weak ownership, no MFA, broad access, and limited behavioral baselines.

That makes them ideal for password spraying. A normal employee account usually has interactive login history, password changes, MFA prompts, device signals, and user behavior that can be modeled. A dormant service account has almost none of that. If it suddenly succeeds from cloud infrastructure, the organization may not have enough baseline context to recognize the sign-in as obviously wrong.

For SMBs and government contractors, this is especially relevant. Microsoft 365 is frequently the business backbone: email, SharePoint, Teams, OneDrive, Entra ID, SSO, finance workflows, customer data, proposal material, and contract documentation. A forgotten account with access to those systems is not a minor housekeeping issue. It is an identity attack path.

Defensive takeaways

  • Inventory non-human accounts. Identify service, shared, functional, automation, scanner, integration, and break-glass accounts across Microsoft 365 and Entra ID.
  • Assign ownership. Every non-human account should have a named business owner and technical owner. If nobody owns it, disable it until someone can justify it.
  • Eliminate default passwords. Any provisioned account that may still carry an initial password should be rotated immediately and moved into managed credential storage.
  • Apply MFA or compensating controls. Some service accounts cannot use traditional MFA, but they can still be protected with conditional access, workload identity controls, certificate-based auth, app-only permissions, source restrictions, and monitoring.
  • Block interactive login where possible. If an account exists for automation, it should not be able to sign in like a human unless that is explicitly required and monitored.
  • Detect spray infrastructure. Watch for high-volume failed sign-ins, AWS-origin login bursts, repeated user-agent patterns, impossible travel, and login attempts against dormant accounts.
  • Baseline cloud application access. A service account that suddenly touches Teams, OfficeHome, Azure Portal, SharePoint, or OneDrive should generate a high-priority investigation.
  • Review Graph and SharePoint access. Successful cloud identity compromise can move quickly into document reconnaissance, mailbox access, Teams data, and OneDrive/SharePoint exfiltration.

Hunting ideas

Defenders should look for Microsoft 365 sign-in activity that combines several weak signals into one stronger story:

  • Dormant accounts with no normal human login history suddenly authenticating successfully
  • Service or functional accounts receiving MFA registration prompts
  • Authentication bursts from cloud providers, especially across many accounts in the same tenant
  • Legacy or unusual Teams desktop user-agent strings associated with automation tooling
  • Successful sign-ins followed by Office, OneDrive, SharePoint, Graph API, or Azure Portal activity
  • VPN or SAML application probes shortly after a Microsoft 365 login
  • Accounts with stale passwords, no owner, no MFA, or no recent legitimate use

Proofpoint listed a TeamFiltration-linked user agent and several infrastructure indicators, but the more durable detection is behavioral: password spraying against dormant accounts, followed by cloud app access that does not match the account’s intended purpose.

Bulwark Black assessment

This campaign is less about a clever exploit and more about identity hygiene debt. The attacker succeeded where accounts had been provisioned, forgotten, and left outside the controls applied to normal users.

The practical fix is straightforward but rarely glamorous: find non-human accounts, assign owners, rotate credentials, remove interactive login where possible, enforce conditional access, and alert when dormant accounts suddenly become active. For contractors handling sensitive business or government data, that work should be treated as part of the security baseline, not as optional cleanup.

If an account can reach Microsoft 365 data, SharePoint libraries, Teams content, VPN SAML apps, or Azure Portal, it needs lifecycle management and monitoring. Forgotten accounts are still accounts — and attackers are clearly looking for them.

Source: Proofpoint — Spraying in the Andes: TeamFiltration Returns to Exploit Forgotten Service Accounts