The password spray failed. Seven accounts fell, and not one of them belonged to a person

0.12 per cent

Divide the outcome by the effort and this campaign reads as a failure.

Proofpoint counted 32,825 authentication events against 5,714 unique accounts across 28 Microsoft 365 tenants, launched from 1,487 source addresses, all of them AWS EC2. Seven accounts were compromised.

Seven out of 5,714 is 0.12 per cent. Put another way, the attacker made about 4,689 attempts for every account they got into.

That is the number most coverage led with, in the other direction: seven accounts compromised. It is worth holding both halves at once. The spray was enormous and it very nearly did not work.

Then look at which seven.

Every one of the seven was an unmanaged functional or service account. Not one personal employee account fell, anywhere, across all 28 tenants.

Proofpoint is direct about why. Personal accounts are subject to password expiry, so the credentials provisioned by IT at the beginning have long since been replaced by something the user chose. Service accounts are not. They were provisioned to run a thing, and then nobody touched them again.

So the correct reading of 0.12 per cent is not that the attack was weak. It is that the password policy worked exactly as designed on every identity it actually governed, and that seven identities were outside its reach.

Say what the arithmetic does not establish.

It does not establish that data was stolen. Proofpoint is careful here and so should everyone else be: sign-in logs alone cannot confirm exfiltration occurred, but the access pattern points to it. The pattern matches TeamFiltration's automatic exfiltration mode, which pulls email, Teams conversations and OneDrive files after a successful sign-in. That is an inference from application access, not a record of files leaving.

It does not establish that the seven organisations were careless in some unusual way. Forgotten service accounts are the ordinary condition of every Microsoft 365 tenant of any age, including yours.

It does not establish that password spraying is an effective technique in general. On this evidence it is a very poor one, against humans.

And it does not establish attribution. Proofpoint tracks the activity as UNK_CondorFiltration, where UNK means exactly what it looks like.

Six in seven minutes is not guessing

The single most useful sentence in Proofpoint's write-up is a timing observation, and it changes what the incident means.

Six of the seven accounts were compromised within seven minutes of each other.

That is not what credential guessing looks like. Guessing produces a scatter: different accounts fall at different times, because different people chose different passwords of different quality. A cluster inside seven minutes means the same credential, or the same trivially predictable pattern, worked on six separate accounts in a row. Proofpoint draws the conclusion plainly: a shared or default password set consistent with an organisational provisioning process, rather than individually targeted credential stuffing.

Which means the vulnerability was not a weak password. It was a process that created accounts with a known password and had no step at the end that changed it. One decision, made once, probably years ago, by somebody who has since left.

A review of sign-in telemetry for all seven found the same thing: none had any prior legitimate user session in the period Proofpoint's data covers. These were not underused accounts. They were unused accounts that still worked.

The shape of the campaign

The activity ran in three bursts across a 26 day window, from 21 July to 16 August 2026, and the targeting shifted between them.

The opening wave on 21 to 24 July was small, roughly 100 to 120 accounts a day, aimed at two Chilean banking institutions. The second, on 26 to 28 July, surged to about 1,520 accounts on 27 July and then collapsed, aimed at a third financial institution. After roughly two weeks of silence the operator returned on 13 to 16 August, peaking at around 1,560 accounts on 15 August, and this time against a major retailer.

All seven compromises happened in that third wave, on 14 and 15 August, at the retailer.

Target landscape, from Proofpoint's campaign statistics. Percentages are Proofpoint's own.

Target	Accounts targeted	Share of events	Outcome
Major retailer	3,038 (53.2 per cent)	78.3 per cent	7 accounts compromised
Major financial institution 1	1,873 (32.8 per cent)	11.5 per cent	None recorded
Major financial institution 2	110 (1.9 per cent)	4.7 per cent	None recorded
Other Chilean organisations	217 (3.8 per cent)	1.4 per cent	None recorded
Outside Chile	476 (8.3 per cent)	4.1 per cent	None recorded

One detail in the second financial institution is worth pulling out, because it shows a different intent running alongside the spray. That target received 1,536 authentication attempts across roughly 110 accounts, Proofpoint's table and its prose disagreeing slightly on the count, and over half of those attempts, 782 of them, were aimed at 57 senior accounts including multiple managers. The wide spray was indiscriminate. That part was not.

The tooling is not exotic. TeamFiltration is a legitimate offensive framework written by Melvin Langvik and released publicly at DEF CON 30 in 2022, built for testing Microsoft 365 environments. It enumerates valid accounts through the Teams API at around 300 addresses a second without triggering lockouts, sprays passwords while rotating AWS regions through FireProx to defeat address based blocking, and, once inside, harvests email, Teams chats and OneDrive files automatically.

It also carries a hardcoded user agent string from a 2020 Microsoft Teams desktop client, which is how Proofpoint recognised it. That is the whole attribution fingerprint: a version number nobody legitimate still runs.

Ninety seconds later, the attacker changed address

For most of the seven, the only activity after login was access to Microsoft Office, OneDrive and Teams from the same AWS infrastructure, which is the automatic exfiltration mode running.

One account went further, and the sequence is worth reading in full because it contains the most instructive thirty seconds of the whole incident.

At 18:41:41 UTC the account was compromised from an AWS address. Within ninety seconds the attacker had left that infrastructure entirely and was operating from a German VPN node. At 18:42:30 they probed the corporate VPN portal, and it failed, blocked by multi factor authentication or Conditional Access. At 18:43:29 they opened the Azure Portal, which let them in and then prompted them to enrol in multi factor authentication, an interrupt that only fires when the account has no second factor configured.

Then OfficeHome at 19:03:59, SharePoint Online at 19:07:23, and a Graph API token request twelve seconds after that.

The same identity, in the same minute, hit a door that was locked and a door that was not.

The VPN was protected. Conditional Access held. Fifty nine seconds later the Azure Portal, from which that organisation manages its cloud, opened and merely suggested that the user might like to set up multi factor authentication at some point.

That is the finding to take to your own tenant, and it has nothing to do with Chile or retail. Multi factor authentication was not absent. It was uneven. Somebody had done the work of enforcing it at the perimeter, which is the visible, audited, board reported control, and the same account walked into the cloud management plane without it.

The enrolment prompt is the part that should sting. Microsoft knew the account had no second factor. It said so, to the attacker, as a helpful suggestion.

Service account is a category, not a control

There is a comfortable phrase that does a great deal of damage here, and it is worth naming.

When an identity is described as a service account, three things tend to be assumed without being checked. That it is low privilege. That it is monitored, because it is infrastructure. And that it is exempt from the controls applied to people for a good reason that somebody wrote down.

None of those is a property of the account. They are properties of a decision somebody may or may not have made.

Proofpoint's list of what the seven did includes approving vendor payments and operating a point of sale system. Those are not low privilege. They are accounts with no human owner, which is a different thing entirely and is worse, because there is nobody to notice an anomaly, nobody to receive an alert, and nobody whose absence from the office contradicts a 3am login from Frankfurt.

The honest framing is that these are non-human identities, and that the single distinguishing feature is not what they can do but that no person is accountable for them. Everything else follows from that. The password is old because nobody owns it. There is no second factor because there is no phone. There is no baseline of normal behaviour because there is no behaviour.

What the phrase service account invites you to assume, against what the seven compromised accounts actually were, per Proofpoint's telemetry review.

Assumed	Found in this incident
Low privilege	Included approving vendor payments and operating a point of sale system
Monitored, because it is infrastructure	No prior legitimate sessions in the telemetry period, so no baseline existed to deviate from
Exempt from MFA for a documented reason	The Azure Portal fired an enrolment prompt, which means nothing had been configured at all
Password managed by a process	A shared or default set, unchanged since provisioning, common to six accounts
Owned by IT	Described by Proofpoint as belonging to nobody

What to do, in order

Every control in this story worked on the identities it was pointed at. Password expiry defeated every attempt against an account a person actually used. Conditional Access held the VPN door shut against an attacker who already had a valid session.

The seven accounts that fell were simply not in scope for any of it, and had not been for years, because nobody was in a position to notice.

So the question is not whether your password policy is strong. It is this. If you asked today for a list of every enabled account in your tenant that no living person owns, who would produce it, and how long would they need?

Key facts