No password, no MFA prompt. The attacker logged in as your apps.

On 3 November 2026, the US security firm Todyl published an investigation into an attacker who has been signing in to Microsoft 365 and Azure since 1 November, not as a person, but as the applications that businesses and their IT providers have connected to Microsoft. The credentials were stolen, and they still worked. So far the attacker has reached 27 organisations, many of them clients of managed service providers (MSPs), across government, energy, agriculture, legal, education and more.

Two things are worth knowing up front. First, there’s no Microsoft vulnerability here. Nothing was hacked in the traditional sense. Someone simply had valid keys. Second, Todyl is a security vendor and can only see organisations that send their logs to Todyl, so it describes its numbers as a minimum. Cybersecurity Dive has reported on the campaign, and Huntress researchers have traced the same activity to a hosting address in Poland. The investigation is still being updated as it develops.

If you use Microsoft 365 and an IT provider manages it for you, this one is worth fifteen minutes of your attention.

Your apps have their own logins

Every tool you connect to Microsoft 365 (your backup service, your IT provider’s management software, your security tools, the integration a developer built three years ago) gets its own identity in Microsoft Entra ID, called a service principal. It signs in with an app ID and a secret, which is effectively a username and password for software.

There’s no person behind that login, so there’s no MFA prompt, and the sign-in rules you’ve built for your staff don’t apply to it. If the secret is valid, the app is in.

Think of it as the spare key you gave the cleaning company. Your alarm, your guard and your camera are all set up around the people who live in the house. Whoever holds the cleaner’s key walks straight past all of it.

What the attacker did with the keys

According to Todyl, around 45 app registrations at roughly 18 organisations were targeted, and more than 33 of them signed in successfully. The pattern was the same almost every time. The attacker asked Azure for access to the app’s cloud resources, then to Key Vault, which is where businesses store their other passwords and keys, and then within seconds to email, files and storage.

That’s what makes it spread. Each app it got into gave it secrets for more apps, and within minutes apps that had never been used before started signing in. It then searched across tenants and bulk-downloaded files from SharePoint at about one per second, going after file names that looked like passwords and configuration. The files it took included password lists, VPN profiles, private keys, and API keys for remote management and MFA tools: exactly what someone needs to move beyond Microsoft 365 into everything else.

It also used a federated identity tied to Azure DevOps, and replayed stolen Azure DevOps session tokens, so if your developers or your IT provider use DevOps, that’s in scope too.

Why this lands on MSP clients

If an IT provider manages your Microsoft 365, their tools have access to your tenant, and often to dozens of other clients’ tenants at the same time. Todyl describes one case where a single compromised multi-tenant app swept through 15 client tenants in roughly ten-second loops.

You didn’t lose a password. Your provider’s app did, and it had the keys to your environment. That’s not a reason to drop your MSP. It is a reason to ask them, this week, whether they’ve checked.

Why your usual defences miss it

Firewall rules never see this traffic, because it goes straight to Microsoft. The Conditional Access policies most businesses have are written for users, so they don’t touch app sign-ins.

Microsoft does offer Conditional Access for workload identities, which can block an address for apps too. But it needs the separate Workload ID Premium licence, and it only covers single-tenant apps registered in your own tenant, not multi-tenant apps, managed identities or third-party SaaS. Most small businesses won’t have it, and it wouldn’t cover the MSP apps anyway.

Rotating the secret isn’t enough on its own either. The attacker kept retrying against apps that had already been disabled or rotated, and any access token it was already issued keeps working until it expires.

What to check today

If you or your IT provider have admin access to Microsoft Entra ID, start here:

If you find something

The real lesson: where do your secrets live?

Nobody has confirmed how the original secrets were stolen. Todyl notes that several had only ever been used from staff devices and office networks, which points to a file store or internal system rather than something scraped off the internet.

Either way, the pattern is familiar. App secrets end up in scripts, config files, shared drives, password spreadsheets, ticket notes and client documentation, because that’s the quickest place to put them at the time. Then one set of keys unlocks the folder holding the next set.

The longer-term fix is to need fewer secrets. Use managed identities or certificates instead of client secrets where you can, cap how long secrets last, lock Key Vault and storage down to known networks, and remove apps and old credentials nobody is using. Most tenants I look at have app registrations nobody can explain.

POPIA still applies

Mailboxes and SharePoint libraries are full of personal information. Section 19 of POPIA requires appropriate, reasonable technical and organisational measures to protect it, and Section 22 requires the responsible party to notify the Information Regulator and the people affected “as soon as reasonably possible” when there are reasonable grounds to believe their information has been accessed by someone unauthorised.

An attacker signing in as an app, rather than a person, doesn’t change that. If you confirm access, treat it as a possible data breach and bring in whoever handles legal and privacy early, not after the technical clean-up is done.

Connecting apps to Microsoft 365 is normal, and it’s how most businesses get anything done. But every connected app is a login without MFA, and most businesses have never looked at the list.

If you’d like a second pair of eyes, I run fixed-scope reviews of Entra ID app registrations: what’s connected, what each app can reach, where its secrets are stored, and what should be removed. Get in touch, and if you think you’ve been affected, say so in the first line and I’ll prioritise it.

References