Seven Accounts Fell and Every One Was a Service Account

The interesting number in Proofpoint's latest campaign report is zero. Across more than 5,700 targeted Microsoft 365 accounts, an attacker spraying default passwords compromised not a single personal employee account. Seven accounts did fall, and Proofpoint reports that every one of them was an unmanaged functional or service account — provisioned to run a business process, then left alone, still carrying the password it was created with.

That is not a story about password complexity. It is a story about ownership: what happens to a credential when the person who typed it in has moved on and nobody inherited it.

What Proofpoint reports

Proofpoint published the campaign on 22 September, tracking it as UNK_CondorFiltration. The figures are Proofpoint's own telemetry: 32,825 authentication events against 5,714 unique accounts across 28 Microsoft 365 tenants, from 1,487 source IP addresses that all resolved to AWS EC2. Targeting was concentrated on Chilean organisations — one unnamed major retailer accounted for 78.3% of observed events, with two unnamed major financial institutions also targeted. The activity came in three waves between 21 July and 16 August. All seven compromises, and the post-access activity, occurred on 14–15 August.

The tooling is publicly documented: TeamFiltration, an offensive framework built by Melvin Langvik at TrustedSec and released at DEF CON 30, which chains account enumeration, password spraying, exfiltration and a OneDrive backdoor. Proofpoint identified it from a hardcoded user-agent string in its default configuration — a 2020-era Teams desktop client that legitimate modern clients no longer present. That fingerprint identifies the tool, not the operator; attribution remains unknown, which is what Proofpoint's “UNK_” prefix means.

Two details explain the outcome. Proofpoint found that none of the seven compromised accounts had any prior legitimate user session in its telemetry window — these were not accounts humans logged into. And six of the seven gave way within seven minutes, which Proofpoint says strongly suggests a shared or default password set by an organisational provisioning process rather than individually targeted credential stuffing. Against personal accounts the same spray achieved nothing, which Proofpoint attributes to users being required to change passwords periodically.

What happened next, and what remains unverified

Proofpoint's case study of one compromised account is worth reading closely. Within about 90 seconds of the successful spray, the operator moved off the AWS infrastructure to a German VPN node and began working: probing the organisation's corporate VPN portal, reaching the Azure Portal, opening SharePoint Online, and triggering a Microsoft Graph API token request. The VPN probe failed — multi-factor authentication or a conditional access policy blocked it. The Azure Portal attempt produced an MFA enrolment interrupt, which Proofpoint reads as indicating the account had no MFA configured at the time.

For most of the compromised accounts the observed activity was access to Office, OneDrive and Teams from the same infrastructure, matching TeamFiltration's automatic exfiltration mode. Proofpoint is explicit about the limit here, and so are we: sign-in logs alone cannot confirm that exfiltration occurred. The access pattern points to it. It does not establish it.

Other things remain unknown. No victim organisation is named. There is no count of records or mailboxes reached. And because this is one vendor's visibility, the campaign may be larger or smaller than the tenants Proofpoint can see.

Microsoft's own documentation explains the gap

The structural problem is not specific to Chile or to this operator, and it is documented by Microsoft itself. Microsoft's guidance on mandatory Entra multifactor authentication states that workload identities — managed identities and service principals — are not affected by either phase of MFA enforcement. But if a user identity is used as a service account to run automation, that identity must sign in with MFA once enforcement begins, and Microsoft says plainly that user identities are not recommended for automation and should be migrated to workload identities.

That sentence describes exactly the account type that fell. A user account acting as a service account sits in the worst position available: outside the workload-identity model that would protect it properly, and outside the password-expiry and MFA habits that protect real people. Microsoft also notes that the OAuth resource-owner password credentials grant is incompatible with MFA and that the corresponding username-and-password APIs are deprecated across its authentication libraries — which is precisely how a script holding a stored password authenticates. The path of least resistance for automation is the one being deprecated.

What to do about the accounts nobody owns

Find them by behaviour, not by naming convention. The accounts that fell had no interactive human sessions. Query sign-in logs for enabled accounts with no interactive sign-ins, or with sign-ins only from server IP ranges, and for accounts whose password has never changed since creation. A list built from names containing “svc” will miss the ones created in a hurry.
Give every one of them a named human owner. Not a team alias — a person, recorded somewhere durable, who is accountable for its credential and who is asked at offboarding. An account with no owner has no one to rotate it.
Migrate what you can to workload identities. A managed identity or service principal removes the password from the equation entirely, which is a better outcome than rotating it well. Microsoft's own recommendation, and the only fix that closes the class of problem rather than one instance.
Where a password must remain, break the provisioning pattern. Six compromises in seven minutes is the signature of one password shared across accounts. Every service credential should be unique and randomly generated, never derived from a template a provisioning process can reproduce.
Apply conditional access even where MFA is impractical. The corporate VPN probe in Proofpoint's case study failed because a policy blocked it. Restrict service accounts by source address range and permitted application, so a valid password from an unexpected country is still refused.
Alert on first interactive use. An account that has never had a human session is a superb tripwire. Any interactive sign-in to it is either a mistake or an intruder, and both are worth a page.
Scope them down before you rotate them. Several of these accounts hold far more access than the process they run needs. Rotating an over-privileged credential preserves the over-privilege.

The part that usually goes wrong: the handover

Service-account passwords are not mostly leaked by attackers. They are mostly spread by us. A credential provisioned once and needed again three years later tends to have been pasted into a runbook page, a ticket comment, a team chat channel, a deployment script, and an email to whoever was on call that week. Each copy outlives the reason it was made, and none of them are audited.

When you do rotate one, the new value has to reach the person or system that needs it, and that step is where the next durable copy gets created. A few rules make it survivable. Decide who actually needs the value, and send it only to them — not to the channel where the work is being discussed. Keep the notification separate from the value itself. Prefer a channel that does not retain the secret after it has been read, over one that keeps it searchable forever. And for the credentials that unlock everything else, require more than one holder to reconstruct the value, so a single compromised mailbox does not undo the rotation.

Then go looking for the old copies. A rotation that leaves the previous password in a wiki page has taught an attacker your naming convention without removing their access to the next account.

Where Secretus fits — and where it does not

Secretus covers one step of this: delivering a replacement service-account credential, an enrolment code or a break-glass password to a specific verified person over a one-time channel, instead of leaving it in a ticket, a wiki page or a chat thread that keeps it searchable. Team Split can require several holders to reconstruct a high-value text secret.

It is not an identity provider, a secret manager for running workloads, or a discovery tool. It cannot inventory your dormant accounts, migrate anything to a managed identity, enforce conditional access, or find the copy of the old password in a wiki page from 2023. The durable fix is removing the password from automation altogether; a one-time channel only keeps the human handover from creating the next permanent copy.