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.

Where Obiguard fits

Obichat does not audit your Microsoft 365 tenant, and it won't find the forgotten scanner account. Proofpoint's list above is the fix for that. What Obichat does is stop the same kind of account from appearing around AI use, by giving employees a sanctioned workspace that removes the reasons to share one.

Every user signs in as themselves. Obichat supports SAML and OIDC single sign-on with Okta, Azure AD or any other identity provider you already use. There is no shared team login to hand around. Sign-ins go through your identity provider, so the MFA and Conditional Access rules you already apply to staff accounts also cover AI use. When someone leaves, disabling them in the identity provider removes their Obichat access too.

Provider keys stay with IT, not in notebooks. Each team gets its own workspace, and IT decides which model providers that workspace connects to. Employees chat with approved models without ever holding an API key, so there is no key to paste into a Slack message and forget. Obichat pairs with Obiguard's network-layer proxy, so direct traffic to consumer AI endpoints can be blocked at the firewall and Obichat becomes the only approved route.

Sensitive data is filtered before it reaches a model. Policy sets assigned per workspace redact sensitive data and catch risky prompts before they are sent. That limits how much an attacker could read from any one account's history.

There is a record per workspace. Security and compliance teams get an exportable log of conversations and events for every workspace. If an identity is ever compromised, you can see from your own records what that user sent to AI, without asking an AI vendor.

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?

Explore Obichat or talk to us about giving every employee a governed AI workspace under their own identity, so a shared AI account never gets created.