The Key Was Issued to an App, Not a Person

Most conversations about account takeover start with a person: someone who clicked, typed a password or approved a prompt. A report from Microsoft this week describes something different. An attacker group used an AI agent framework to try its luck against more than 2,250 Microsoft 365 tenants, and the key it carried had been issued to a piece of software, not to a person.

No one in those organisations had to make a mistake in the moment for the door to open. Someone did, at some earlier point, approve a third-party app and leave it running. That decision is where the human side of this story sits, and it is worth understanding properly.

What Microsoft reported

On 21 October 2026, Microsoft Threat Intelligence published its findings on a group it tracks as Storm-0940. Microsoft describes it as China state-aligned, active since 2021 and focused on data theft. From September 2026, Microsoft says, the group used ARTEX, an open-source agentic AI penetration testing framework, to automate attacks against hundreds of organisations across many industries.

The part that matters most for everyday businesses is the supply chain link. Microsoft assesses that Storm-0940 was responsible for the compromise of ConnectWise Cloud Backup, a multi-tenant cloud backup application. ConnectWise has said it found "unauthorized access to application identities within the ConnectWise Cloud Backup environment", and it suspended Cloud Backup, SaaS Security and Cloud Management while it investigated, according to Infosecurity Magazine's report. Microsoft says the attacker then used the stolen application credentials to authenticate to downstream customer tenants without any interactive user sign-in.

Microsoft says the agents attempted sign-ins to more than 2,250 tenants. That is a count of attempts, not of confirmed breaches. In some environments the agents went on to query Microsoft Graph, change application credentials for persistence, alter identities, groups and privileged roles, and read secrets from multiple Azure Key Vaults. Several attacks reached privileged cloud access, and Microsoft says multiple instances took under three hours from first targeting. It also states that none of this came from a compromise of Microsoft's own systems or products.

Is this a phishing story?

Not on the evidence published so far. Microsoft's write-up does not mention phishing or social engineering, and it does not explain how the ConnectWise environment was first breached. Treating this as a phishing attack would go beyond what the sources support, so we won't.

It belongs on a human risk blog anyway, because it shows how much of an organisation's exposure comes from decisions that were made once and then forgotten. A backup tool is connected to Microsoft 365 and given the permissions it needs to do its job. Everyone moves on. That standing trust was what the attacker needed here.

Why an app credential is a different kind of key

A person signing in meets a series of checks. There is a password, usually a second factor, a sign-in risk assessment and a lockout if the guesses pile up. An application identity that has already been approved gets very little of that. It presents its own credentials, receives a token and acts with whatever permissions it was given. There is no one to prompt and no one to notice an unusual login time.

That is why the incident is a good reminder that multi-factor authentication protects people, and only people. It does nothing about an app credential held by a third party. The protection for that sits in other places: how few permissions the app was given, whether anyone reviews it, and whether unusual app-only activity is being watched.

The password spray was a separate, noisier story

Alongside the application-credential route, Microsoft also describes a password spray between 10 and 14 October. Infrastructure at one IP address ran a cross-tenant spray against 327 accounts in eight organisations, producing more than 151,000 failed logons, with a peak of 2,900 failures a minute on 11 October. Lockouts accounted for nearly 98% of the activity, and Microsoft observed no successful authentication, token issuance, Graph call or directory change from that campaign.

This is the defence working as intended. Account lockout and sensible sign-in policies turned a loud, high-volume attempt into a pile of failures. Two things are worth keeping apart here. The spray hit user accounts and failed. The ConnectWise route used trusted application identities and, in some cases, succeeded. The first was blocked by controls aimed at people. The second went around them.

What to do this week

Microsoft's guidance is detailed and aimed at responders, but the underlying habits are ones any organisation can adopt. Based on that guidance and the ConnectWise customer advice:

• If you use ConnectWise Cloud Backup, SaaS Security or Cloud Management: check the status of the affected application connections and keep them disabled until ConnectWise gives restoration instructions. Preserve your sign-in and audit logs before you change anything.
• Do not delete the enterprise applications as a first move. Microsoft advises preserving configuration and evidence first, then having authorised responders remove confirmed unauthorised credentials and grants.
• Review beyond the obvious. Look at credential additions, new app owners, consent grants, privileged role assignments, Conditional Access changes, mailbox forwarding and inbox rules, and delegated mailbox access. Disabling the original apps does not remove other access paths the attacker may have created.
• Audit every third-party app with access to Microsoft 365. Remove the ones nobody remembers approving or that are no longer needed, and give the rest the least privilege they can work with.
• Name an owner for each integration. An app with no human accountable for it is an app nobody will review.
• Keep user-side basics in place. Strong, unique passwords, lockout policies and MFA are what turned the spray into a failure. Keep them.
• Tell the people who approve apps what they are approving. Consent decisions are made by staff and administrators. Our earlier post on OAuth consent phishing covers what a good approval habit looks like.

The people question, answered fairly

It would be easy to read an incident like this and conclude that the lesson is technical, and in large part it is. But the control that would have helped most is not exotic. It is an up-to-date list of what is connected to your tenant, a named person responsible for each item on it, and a routine for asking whether it still needs to be there.

Staff and administrators are a defence layer here, and they can only play that role if they have the information and the time to do it. Asking an IT manager at a small business to review dozens of app permissions on top of everything else, with no prompt to do so, is a process gap rather than a personal failing. Build the review into the calendar and it becomes ordinary work.

The bottom line

The detail that stays with us is the timeline. Microsoft reports that several attacks reached privileged cloud access in under three hours. The window for noticing a problem with a trusted app is short, which is why the useful work happens before an incident: knowing what is connected, limiting what it can do, and having logs you can read when it matters. AI automation was part of how the attempts were run. It did not change where the weakness was.

For most organisations, the next step is simple and free. Open the list of enterprise applications in your Microsoft 365 tenant, and ask who approved each one and why.

Sources: Microsoft Threat Intelligence, 21 October 2026; Infosecurity Magazine, 19 October 2026.

Phishing Tackle offers the tools businesses need to strengthen their human risk strategies, with multi-platform testing, real-time behavioural insights, and actionable data to keep your organisation ahead of modern cyber threats.

Contact us today to learn how Phishing Tackle can help safeguard your organisation from the growing array of cyber risks.