AI Agents Don't Need to Log In. The Storm-0940 Attack Shows Where to Look Instead

Most security teams watch the front door. Microsoft's new write-up describes attacker agents that came in through the vendor entrance, and the fix is the service principal sign-in log most people never open.

Most of what we call identity security is built around a person typing a password. MFA prompts, impossible-travel alerts, "new device" emails: they all fire when a human signs in. Software that already holds permission never sees any of it.

That gap just got a very concrete example. On October 21, Microsoft published a breakdown of a campaign by Storm-0940, a group it calls China state-aligned, that used an AI agent framework called ARTEX against customers of ConnectWise, a company whose tools many IT service providers use to manage their clients. The headline number is big: sign-in attempts against more than 2,250 Microsoft 365 tenants (a tenant is one organization's Microsoft 365 account). The part that matters for builders is smaller and quieter. After the attackers compromised ConnectWise's cloud backup app, their agents reached customer environments through apps that customers had already approved, which, in Microsoft's words, "allowed the threat actor to operate without requiring an interactive user sign-in." (Microsoft Security)

So the lesson is about where to look, not about scarier AI. Once an agent holds an app's identity, it works in a log most teams never review. And if you run agents of your own, they live in that same log. The first move takes five minutes: open the service principal sign-ins tab in Microsoft Entra and see which apps are in it.

What happened, in plain terms

Start with ARTEX itself. Microsoft describes it as "an open-source penetration testing framework" with LLM-driven agents, built to automate the kind of probing a human security tester does: find assets, try logins, map what is reachable. The agents build a graph of what they discover as they go. Tools like this exist for defenders. Storm-0940 pointed one at real victims. (The Hacker News reports ARTEX was later made closed-source after the abuse, so do not assume a public copy is still there.)

The campaign ran in two phases, and they look very different in your logs.

Phase one was loud. Between October 10 and 14, Microsoft captured more than 151,000 failed logons from a password-spraying run (trying a few common passwords against many accounts, so no single account locks out). Activity peaked on October 11 at 2,900 failures per minute. This is the part existing defenses are built to see, and it shows up in the user sign-in logs with all the usual alarms.

Phase two was quiet. On October 15, per Microsoft, the agents gained control of identities belonging to several ConnectWise cloud applications and used them to authenticate into customer tenants. No user typed anything. The apps already had consent, so the agents simply asked for tokens the way the real backup service would. In some environments they went further into Microsoft Graph (the API behind Microsoft 365) and directory operations: reconnaissance, adding credentials to applications for persistence, and changing identities, groups and privileged roles. Microsoft also saw several cases where the time from first targeting to privileged access was under three hours.

One honest caveat from Microsoft itself belongs right here: "the presence of an affected application or successful threat actor authentication does not necessarily indicate that customer data was accessed or exfiltrated." This is an exposure story first. Some tenants were touched, and not every touch was a breach.

A side note: Zscaler found a custom ARTEX deployment set up to call a DeepSeek model, per The Hacker News, not Microsoft. Which model ran the agents changes nothing about what you should do on Monday.

The idea: there are two kinds of "logging in"

Here is the mental model that makes the rest of this easy.

Think of an office building. Employees badge in at the front desk every morning; a guard sees their face. The cleaning company has a master key and a standing contract. Its crew comes in through the service door at night, and nobody at the front desk ever sees them. If someone steals the cleaning company's key, the front desk's facial recognition is useless.

In Microsoft Entra (Microsoft's identity system, formerly Azure AD), employees are users and the cleaning company is a service principal: the identity an application uses inside your tenant. When an app has been granted permissions and given a secret or certificate, it can get tokens on its own, with no person involved. Entra even files these events in a separate place. Its sign-in logs split into categories, and Microsoft's documentation lists servicePrincipal as its own sign-in event type next to interactiveUser, nonInteractiveUser and managedIdentity. In the portal, each one lands on its own tab. (Microsoft Learn)

That separate tab is the whole story. Phase one of Storm-0940 hit the front desk. Phase two used the service door.

And this is where it stops being someone else's problem. Every AI agent you deploy that talks to Microsoft 365, Google Workspace, GitHub or Slack on its own schedule is also coming in through the service door. Your background summarizer, your ticket-triage bot, the MCP server (a connector that gives an agent tools) that reads your SharePoint: if it runs unattended, it most likely holds an app identity with standing permissions. Storm-0940 did not need a new trick. It needed an identity that was already trusted and a place nobody was watching.

Why the agent part matters

You could fairly ask whether any of this needed AI. Stolen app credentials are an old attack.

The difference is tempo. A human operator with a stolen app credential still has to read the directory, figure out which groups matter and decide what to change. ARTEX-style agents do that reading and deciding in a loop, at machine speed, across many tenants at once. Microsoft's under-three-hours figure is the number to sit with. If your review of app activity happens monthly, or only when a vendor emails you, an agent has a lot of hours to work with.

This lines up with a wider argument making the rounds this week. Drew Silcock wrote on October 23 that the gap between a vulnerability being reported and being exploited "has gone from weeks/months to hours/minutes," while being careful that many recent bugs were found by "human meat fingers," not models. (Drew Silcock) You do not need to settle that debate to act on it. Slow review loops are a bad bet either way.

Put this into practice

None of this requires a new product. It requires opening a tab and making a list. Here is the lowest-friction version, in order.

1. Look at the service principal tab once. In the Entra admin center, go to sign-in logs and open the service principal sign-ins tab. Sort by app. The first time most teams do this, they find apps nobody remembers approving. That list is your real attack surface for the "service door."

2. Pull it from a script so you can do it again. With the Microsoft Graph PowerShell SDK, the filter for this sign-in type needs the beta cmdlet. You need the beta reports module, the AuditLog.Read.All permission, a role that can read sign-in logs (Reports Reader or Security Reader works), and Microsoft Entra ID P1 or P2 for Graph access to sign-in logs, per Microsoft Learn. Then run the query from this write-up:

Install-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All"
$sp = Get-MgBetaAuditLogSignIn -Filter "(signInEventTypes/any(t:t eq 'servicePrincipal'))" -Top 5000 -Sort "createdDateTime DESC"

Per Office 365 for IT Pros, the v1.0 cmdlet does not support filtering on signInEventTypes, which is why this uses Get-MgBetaAuditLogSignIn. Expect a list of app sign-ins with IP addresses, locations and the credential type used (secret or certificate). What you are hunting for: an app signing in from somewhere its vendor does not operate, or at hours it never used before.

3. Watch for new credentials on apps. The persistence move Microsoft describes (adding credentials to an application) leaves an audit event. Elastic's detection rule for it matches the Entra audit operation "Add service principal credentials" and flags it when the person doing it has not done so recently, because in most organizations this is rare. (Elastic) If your SIEM (the system that collects your security logs and raises alerts) has nothing on this event, that is a one-rule fix with a high payoff.

4. Shrink what each app can do. Microsoft's own recommendations include applying "least privilege to multi-tenant application permissions and consent grants" and monitoring "credential additions, privilege assignments, and anomalous app-only activity." In practice: open your enterprise applications list, sort by permission scope, and question anything with directory-wide write access that only needs to read one mailbox.

5. Do the same for your own agents. Give each agent its own app identity rather than sharing one, with the narrowest scopes that work. Then the service principal log tells you which agent did what, and a stolen credential only opens one small door.

6. If you use ConnectWise, follow the incident guidance directly. Microsoft's immediate steps include keeping affected ConnectWise app connections disabled until ConnectWise gives formal restoration instructions, preserving logs before deleting anything ("Do not delete enterprise applications as the first response"), and reviewing activity from at least October 15, with service-principal sign-in review back to October 1.

Honest limitations

A few things this article cannot tell you, and a few ways this advice falls short.

The numbers are Microsoft's. The 2,250 tenants are sign-in attempts, not breaches, and Microsoft says outright that an authentication does not prove data was taken. Treat the scale as a measure of reach.

The service principal log is noisy. Busy tenants generate a lot of app sign-ins, and a raw list of 5,000 rows is not a detection. The value comes from a baseline (which apps, from where, how often) and from alerting on changes, which takes a few weeks of watching before it is useful.

Logs only help if you keep them. How long Entra keeps sign-in data depends on your license, so if you have never exported these logs anywhere, today's review might only reach back a few weeks. Export them before you need them.

The beta cmdlet is beta. Microsoft can change it. For anything you automate, check the current Graph docs first.

And this is a Microsoft-shaped answer. Google Workspace, Okta, GitHub and Slack all have their own versions of app-only access with their own logs. The question carries over; the commands do not.

The question to take into Monday

Every tenant has a front desk and a service door. Most teams staff only the front desk, and AI agents, theirs and yours, mostly use the service door.

You do not need to solve that this week. Open the service principal tab once, count the apps you recognize, and ask who reviews the rest. If the answer is nobody, you have found your first project. If you run agents yourself, give each one its own key and its own line in that log, so the next time something walks through the service door, you can tell whose key it was.

Sources: Microsoft Security blog, Storm-0940 and ARTEX, October 21, 2026 (updated October 23); The Hacker News, October 22, 2026; Microsoft Learn, sign-in log activity details; Office 365 for IT Pros, service principal sign-ins; Elastic detection rule, service principal credentials added; Drew Silcock, October 23, 2026.