Attackers Tried 5,714 Microsoft 365 Accounts. The Only Seven They Got Were Ones Nobody Had Ever Logged Into

Most identity programmes are built around people. New starters get an account, MFA enrolment, a laptop and a training module. Leavers get disabled on their last day. Access reviews go to managers, who look at a list of their staff and tick boxes.

The accounts that don't belong to anyone fall outside all of that. A shared mailbox for supplier invoices. A login a vendor asked for during an integration in 2023. A "scanner" account for the printers on the third floor. Nobody starts or leaves, so nobody reviews them.

On 22 September, Proofpoint published a campaign in which attackers tried thousands of accounts across 28 organisations and got into exactly seven. Every one of the seven was that kind of account.

What Proofpoint found

Proofpoint's write-up, which it tracks as UNK_CondorFiltration, covers three bursts of activity between 21 July and 16 August 2026, aimed almost entirely at Chilean organisations: several financial institutions and one large retailer.

The numbers:

Authentication attempts	32,825
Accounts targeted	5,714 across 28 Microsoft 365 tenants
Source IP addresses	1,487, all AWS EC2
Share of targets at one retailer	53.2%
Accounts compromised	7

All seven compromises were at the retailer. Proofpoint says every one was a functional or service account with no prior legitimate sign-in activity, which points to default or predictable passwords that were never changed and no MFA. Six of the seven fell within seven minutes of each other, which suggests they shared the same starting password. No personal employee account was confirmed compromised.

On the one account where Proofpoint saw follow-up activity, the attacker moved within about 90 seconds. They switched to a VPN exit node in Germany, tried the company's corporate VPN (Conditional Access and MFA stopped that), then opened the Azure Portal, OfficeHome and SharePoint Online and requested Microsoft Graph tokens.

The tool is a pentest framework

TeamFiltration is an open-source red-team tool published in 2022 by TrustedSec's Melvin Langvik. It automates the whole sequence:

1. Enumerate which email addresses exist, through the Microsoft Teams API, at about 300 per second, without tripping account lockout.
2. Spray a small number of likely passwords across all of them, rotating through AWS regions so no single IP address stands out.
3. Exfiltrate mail, Teams chats, OneDrive and SharePoint files and Graph data from anything that opens.
4. Backdoor OneDrive for later access.

This is not the first time criminals have picked it up. In June 2025 Proofpoint reported UNK_SneakyStrike, which used the same tool against more than 80,000 Entra ID accounts. The difference this time is how precisely the results show where the weak point is. Thousands of attempts against staff accounts, which have MFA and a person who would notice, produced nothing. The only accounts that opened were the ones outside the joiner-mover-leaver process.

What to do this week

None of this is new advice, but it is the advice that would have stopped this campaign:

1. List every account in the tenant with no interactive sign-in in the last 90 days, and every account that has never signed in. Entra ID's sign-in activity report shows both. Disable what nobody can explain.
2. Put every remaining functional account behind MFA or Conditional Access. If a device or app genuinely cannot do MFA, restrict it to known IP addresses and block interactive sign-in.
3. Rotate every password that was set at creation and never changed. If six accounts share one, assume the attacker knows it.
4. Give each non-human account a named human owner and put it on the same access review as the owner's staff.
5. Hunt for the tool. TeamFiltration hard-codes an old Teams client user agent (Teams/1.3.00.30866 on Electron/8.5.1) that no current client sends. A sign-in with that string, from AWS EC2 address space, deserves a look.
6. Block legacy and unused authentication flows where you can, so a sprayed password alone isn't enough.

The same problem is now building up around AI

This matters beyond Microsoft 365, because most organisations are creating the next generation of these accounts right now, around AI.

Look at how a team typically adopts AI without a sanctioned tool. Someone opens a ChatGPT or Claude team account and shares the login in a channel so colleagues can use it. Someone else creates a model-provider API key for a proof of concept and pastes it into a shared notebook, a Slack message and a .env file. A department signs up for an AI note-taker using a generic mailbox so the licence isn't "tied to one person".

Each of those is a functional account in all but name: shared, owned by nobody, set up for convenience, never rotated, often without MFA, and outside every access review. It also sits in front of the most sensitive material the team has, because that is what people paste into AI tools. A compromised AI account doesn't give up a mailbox. It gives up months of conversation history: contract drafts, customer records, source code, board papers.

We covered what happens when attackers get hold of AI credentials earlier this month. UNK_CondorFiltration shows how they find the weak ones: try everything, cheaply, and keep what opens.

The question to take away

UNK_CondorFiltration was not sophisticated. It used a public tool, rented cloud servers and passwords nobody had changed. It still worked, because the only accounts it needed were ones no process had been responsible for.

So the question is not do our staff have MFA? They probably do. It is: which accounts in your organisation have no person responsible for them, and how many of the new ones were created this year so a team could share an AI tool?

Talk to us about making sure every AI account in your organisation has a person responsible for it.