No Password, No MFA Prompt, No Person: How Stolen App Secrets Let One Attacker Into 27 Organizations Through Their IT Providers
A single attacker used stolen Microsoft Entra ID application secrets to sign in as trusted apps at managed service providers and reach their customers’ Microsoft 365 and Azure environments. Why multi-factor sign-in didn’t help, and the layers that do.
Here Is How Layered Defenses Help When the Login Isn’t a Person
Most security advice about Microsoft 365 is about people: strong passwords, multi-factor prompts, rules about where staff can sign in from. This week’s campaign skipped people entirely. Starting around November 1, an attacker signed in as the software itself, using stolen secrets that belong to app registrations in Microsoft Entra ID, the identities programs use to reach Microsoft services with no person present. Field Effect reports that Azure DevOps environments were targeted the same way.
The account below is based on Cybersecurity Dive’s report, which draws on research from Todyl and comments from Huntress, along with a technical summary and defensive guidance from Field Effect.
Following the attacker’s path
The operator arrived with a stockpile of valid application secrets, collected before November 1 by means still under investigation. Working from a single server at a hosting provider in Poland, the attacker targeted 45 app registrations at about 18 organizations, including managed service providers, and authenticated successfully with at least 33 of them. Around 95% of the sign-ins came from scripts, in bursts of 24 sign-ins within 10 seconds and retries every 11 seconds.
Because MSP tools are built to manage many customers, those app identities opened doors well beyond the MSPs themselves. Researchers say the attacker reached 27 organizations, including downstream clients in energy, government, food and agriculture, transportation and construction. They ran searches across 25 Microsoft 365 tenants, downloaded 81 files and accessed about 2,300 mailbox items, looking especially for files holding credentials and settings for VPNs, remote management tools, backups and firewalls. Field Effect reports that previously unused apps began signing in within minutes, suggesting newly found secrets were being used to spread further, and that integration apps for security tools were among those abused, with no sign that a vendor’s platform had been breached.
When detections fired on November 3, the attacker switched to disguised browser signatures and replayed users’ refresh tokens. Conditional Access blocked every replay observed that day. Researchers say the speed fits AI-assisted tooling but have not tied it to a specific tool, and found no evidence linking it to the recent ConnectWise Cloud Backup campaign.
Why multi-factor sign-in didn’t help
An app signing in with a secret never sees a multi-factor prompt, and policies written for users do not apply to it. Microsoft does offer Conditional Access for workload identities, but Field Effect notes it requires an extra license and does not cover the multi-tenant apps MSPs commonly use.
The layers that limit the damage
- Know your app identities. List every app registration and service principal in your tenant, who owns it and what it can reach. Disable anything unused or unrecognized.
- Cut permissions down. Remove broad rights an app does not need, especially across mailboxes, files, key stores and admin functions.
- Retire long-lived secrets. Where possible, replace client secrets with managed identities or federated credentials, and set short expirations on whatever remains.
- Apply location and risk rules to apps, not just people. Use Conditional Access for workload identities where licensed, or an equivalent control in your identity platform; researchers recommend blocking the attacker’s address, 199.19.77[.]84.
- Watch app sign-ins. Review service principal sign-in logs for failed secret attempts followed by a success, and for apps that suddenly wake up after long inactivity.
- Keep secrets out of documents. Move passwords and keys out of runbooks, tickets, shared drives and mailboxes into a managed secrets vault, so a mailbox search does not hand over the keys to your firewall. Limit key vaults and storage to private networks where you can.
- Have a cleanup plan. If an app is exposed, remove all of its secrets and certificates, disable it, revoke related sessions and tokens, and rotate every credential it could reach, from VPN to backups.
What this means for your company
If an IT provider manages your Microsoft 365 or Azure environment, their tools have standing access to it, and that access is only as safe as their secrets. Ask your provider which apps and delegated permissions they hold in your tenant, how those secrets are stored and rotated, and whether they monitor app sign-ins. Inside your own tenant, review app registrations as carefully as user accounts, and make sure nobody keeps passwords for critical systems in email or shared documents. Built-in tools from Microsoft or other identity and monitoring vendors can do this job, but only if someone turns them on and reads the alerts.
Do you know which apps, partners and service accounts can sign in to your Microsoft 365 tenant right now, and what they can reach? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
