Seven Forgotten Accounts: TeamFiltration's M365 Service Account Campaign

Proofpoint disclosed on September 24, 2026 that TeamFiltration (an open-source password-spray framework) was used to target Microsoft 365 service accounts across Chilean retail and financial institutions in a 26-day campaign between July 21 and August 16, 2026.

The campaign targeted 5,714 accounts across 28 tenants. It compromised seven. Every single one was a service account IT had provisioned with a default password and then forgotten.

The Campaign

The attackers used 1,487 unique AWS EC2 source IPs to distribute the spray attempts, staying under rate limits and avoiding IP-based blocks. TeamFiltration is designed for exactly this: automated credential testing across large Microsoft 365 tenant footprints, with built-in evasion of basic detection. It's open source. It's documented. Anyone can run it.

The accounts targeted were not random. The campaign focused on Chilean institutions: retail chains, financial services, logistics. Sectors where operational automation relies heavily on service accounts to sync data between systems, run scheduled tasks, and access APIs. The kind of infrastructure where IT provisions an account to "just get this working" and moves to the next ticket.

The seven compromised accounts were all unmanaged functional accounts. Not employees. Not contractors. Not third-party integrations subject to vendor security reviews. These were the accounts IT created internally for automation (syncing databases, running reports, sending notifications) and then never touched again. Default passwords from the day they were created. No multi-factor authentication. No monitoring. No rotation policy. No inventory.

Why It Worked

User-focused security controls don't catch service accounts. MFA rollouts target employees. Password policies apply to interactive logins. Access reviews ask managers which team members need what permissions. Service accounts aren't on the org chart. They don't have managers to approve their access. They don't show up in phishing training or user behavior analytics. They exist in scripts, scheduled tasks, and integration configs. Documented nowhere, monitored by no one, running forever.

When IT provisions a service account, the goal is functionality. Make the automation work. Deploy it. Close the ticket. "We'll rotate the credentials later" becomes "we'll do it next quarter" becomes "we forgot it exists." The account sits there for months or years, carrying the same password, with no logging, no anomaly detection, no human ever touching it again unless something breaks.

And when attackers spray 5,714 accounts looking for exactly that pattern (old credentials, no MFA, no monitoring), they find seven.

The Exposure Window

The campaign ran from July 21 through August 16, 2026, nearly four weeks. Proofpoint disclosed it September 24, five weeks after it ended. That's the disclosure timeline. The exposure window is longer.

A service account with a default password didn't become vulnerable on July 21. It was vulnerable from the day it was created: six months ago, two years ago, whenever IT set it up and walked away. The TeamFiltration campaign just found it. How many other password sprays, credential stuffing runs, or brute-force attempts hit that same account before July and failed to log anything anyone would notice? How many succeeded and left no trace because the account had no monitoring?

The seven compromised accounts are the ones Proofpoint's investigation identified. What those accounts accessed, what data moved, what permissions were exercised during the compromise window: that's the forensic work still running. But the larger question is: how many OTHER service accounts exist across those 28 tenants, with the same pattern (default passwords, no MFA, no rotation, no inventory) that this campaign didn't happen to spray?

Because attackers don't stop after one campaign. They note what works. They share credential lists. They return.

What Should Have Happened

Microsoft 365 supports conditional access policies for service principals. You can enforce MFA. You can require access from specific IP ranges. You can mandate device compliance. You can log every authentication attempt and alert on anomalies: new IPs, unusual times, actions outside normal behavior.

None of that was configured on the seven compromised accounts. They were created with default passwords, granted whatever permissions made the automation work, and left alone.

Service accounts should be inventoried the same as user accounts. Who created them? What do they access? When were the credentials last rotated? Who's responsible if something goes wrong? If you can't answer those questions for every non-human identity in your environment, you don't know your attack surface.

Credentials should rotate on a schedule, not when someone remembers. Automate rotation where possible. Where it's not possible (legacy systems, vendor integrations that break when credentials change), document the exception, scope the account to minimum required permissions, and monitor it aggressively.

Permissions should be scoped to least privilege. A service account created to send email notifications doesn't need Global Admin. An API integration that reads calendar availability doesn't need write access to mailboxes. Principle of least privilege applies to automation the same as humans.

And when the project ends, the integration gets replaced, or the vendor contract terminates — delete the credentials. Don't leave them sitting there "in case we need them later." Decommission the account. Revoke the token. Remove the API key. If you need it again, recreate it with current credentials and proper scoping.

The Pattern

This isn't TeamFiltration's first campaign. It won't be its last. And it's not the only tool doing this. Password spraying is not sophisticated. It's not zero-day exploitation. It's not supply-chain compromise. It's trying common passwords against large lists of accounts, at a rate slow enough to avoid lockouts, from enough source IPs to avoid blocks.

It works because organizations treat service accounts as infrastructure instead of credentials. They're provisioned once, configured to make something work, and then invisible until a breach investigation asks "who created this account and why does it have admin access?"

Proofpoint's September 24 disclosure gives the technical details: 5,714 accounts targeted, 7 compromised, AWS EC2 source IPs, TeamFiltration tooling, Chilean institutions. The real finding is simpler: forgotten credentials are found credentials. And when those credentials carry permissions to systems, data, and operations no individual user could touch, "we forgot it existed" stops being an explanation and starts being the vulnerability.

Source: Proofpoint, "Spraying in the Andes: TeamFiltration Returns to Exploit Forgotten Service Accounts," September 24, 2026. https://www.proofpoint.com/us/blog/threat-insight/Spraying-in-the-Andes-TeamFiltration-Returns