Entra ID App Identity Detections

A detection release for Microsoft Entra ID, published October 23, 2026. Four new behavior rules alert when an app (a service principal acting with no user signed in) assigns directory roles or adds credentials to other apps. An attacker does exactly this with a stolen app certificate or secret, as in the Storm-0940 compromise of ConnectWise's multi-tenant apps that Microsoft reported on October 21. Until now, role assignments and credential changes made by an app were only context, or one step of the EntraID_App_Takeover correlation.

No action is needed: the rules sync to every instance automatically. These notes also correct how the October 18–20 notes described EntraID_DeviceCode_UserApp.

Rollout and requirements

• Rollout. All four rules are published to the default rule set and reach each instance through resource sync within about two hours. No configuration is needed.
• Data sources. The rules read the Entra ID audit logs, collected by Entra ID Audit via Event Hubs or Microsoft Graph. Tenants that send only the Microsoft 365 unified audit log, with no Entra ID audit logs, are not covered yet.
• A first week of learning. Three of the rules alert on an app's first time in 30 days. Each one learns for 7 days from the first event it sees in a tenant and raises no alert in that time. EntraID_App_Privileged_Role_Assigned, EntraID_App_Role_Assigned and EntraID_App_Credential_By_App therefore start alerting about a week after they reach a tenant. EntraID_App_Self_Role_Assigned alerts from the start.
• Recommended. Collect service principal sign-ins as well. They are where an app signing in with a stolen credential shows up. See Not covered yet.

The attack

Microsoft Threat Intelligence attributes the compromise to Storm-0940, a China state-aligned actor. It automated the attack with ARTEX, an open-source agentic AI penetration-testing framework. Its targets were ConnectWise Cloud Backup (formerly SkyKick) and the ConnectWise Cloud Management apps, which MSPs and their customers had consented to in their Microsoft 365 tenants.

• October 10–14. A password spray against 327 accounts at eight organizations, peaking at 2,900 failed attempts a minute. Microsoft saw no successful sign-in in this phase.
• October 15. The attacker signed in as the apps, with no user, using the apps' own credentials. Microsoft reports attempts against more than 2,250 tenants. Huntress had confirmed unauthorized sign-ins in 162 tenants by the next day.
• Same day. In about 50 tenants that Huntress monitors, the Cloud Management apps assigned themselves directory roles, mostly Exchange Administrator. In one tenant, the Teams management app made itself Global Administrator. It then ran a Python script that added client secrets to two other apps. Microsoft also saw Graph reconnaissance and bulk reads of Key Vault secrets. In several cases, it measured under three hours from first targeting to privileged access.
• October 17. ConnectWise disabled the apps.

User-based rules miss this. No user signs in, so there is no MFA prompt, no risky sign-in and no new device. The app is one the tenant already trusts, so app-creation and consent rules do not fire either. What the audit log does show is a service principal assigning roles, often to itself, and adding secrets to other apps.

New detections

ID	Rule	Severity	Alerts	Fires when
102184	EntraID_App_Self_Role_Assigned	Critical	Every time	An app assigns any directory role to its own service principal. Apps are given roles by an administrator, so an app granting itself one is never routine.
102168	EntraID_App_Privileged_Role_Assigned	High confidence	First time per app in 30 days	An app assigns a privileged directory role (Global, Exchange, Privileged Role or Application Administrator and the like) to a user or group, or any directory role to another service principal.
102169	EntraID_App_Role_Assigned	Medium	First time per app in 30 days	An app assigns a non-privileged directory role to a user or group.
102170	EntraID_App_Credential_By_App	Medium	First time per app in 30 days	An app adds a secret or certificate to another app or service principal, so that its access survives the original credential being revoked. An app re-keying itself, such as Entra Connect or a vendor's connector, is not counted.

The role rules map to MITRE ATT&CK T1098.003 (Additional Cloud Roles), and the credential rule to T1098.001 (Additional Cloud Credentials).

Some apps do these things as their job: a just-in-time access broker grants admin roles every week, and CI pipelines rotate other apps' secrets. So the three first-time rules alert only the first time an app does it in 30 days, keyed on the app ID; repeats are not recorded. A compromised app that already does this routinely will not trip them. Self-assignment has no such allowance.

Microsoft's own service apps are excluded by app ID: Privileged Identity Management, Microsoft support's GDAP access, Approval Management, ESTS, managed identities, Purview, Dynamics and AAD App Management. Role grants through PIM therefore stay with EntraID_Privileged_Role_Assigned (102119).

Each alert is keyed on the app's name. The app ID, service principal ID, role and target are in the event's attributes.

Parser change. EntraID_AuditRules now also emits a line keyed on the acting app for role and credential operations. Its existing output, and the rules that read it, are unchanged.

Not covered yet

Step	Why it is not covered	What helps
The app signs in with a stolen credential	Most tenants do not collect service principal sign-ins, so an app that only reads (Graph reconnaissance, mail, files) leaves no trace.	Collect service principal sign-ins: select the ServicePrincipalSignInLogs category in the Entra ID diagnostic setting that feeds Entra ID Audit via Event Hubs. The Microsoft Graph template collects interactive sign-ins only. Volume varies widely between tenants, so check it first. Non-interactive user sign-ins are not needed for this.
The app uses Exchange Administrator	No rule yet looks at Exchange admin cmdlets run by an app identity.	Planned.
Tenants with only the Microsoft 365 audit log	The unified audit log's version of these operations is not matched yet.	Planned. Entra ID audit logs, through Event Hubs or Microsoft Graph, cover it today.
Key Vault secrets read in bulk	Key Vault logs are rarely collected.	Ask us for a hunt if you send Key Vault diagnostics.

Correction: EntraID_DeviceCode_UserApp alerts on every match

The October 18–20 notes said EntraID_DeviceCode_UserApp (102129) alerts only on a user's first device-code sign-in to an application. That was wrong. Every successful device-code sign-in to an application that is not an admin tool alerts at medium. A user's first such sign-in to an application in 30 days scores higher. The rule's own description is corrected in the next release. Its detection logic is unchanged.

Triage guidance

Alert	Check first	Respond
EntraID_App_Self_Role_Assigned	The app's name, app ID and owner tenant (is it a vendor's multi-tenant app?), and the role it took. Check the vendor's security advisories.	Treat it as a compromise unless the vendor confirms the change. Remove the role, disable the service principal and remove its credentials. Then review what the app did after the grant: other role assignments, credentials added to other apps, password resets, mail access.
EntraID_App_Privileged_Role_Assigned	Whether the app is a known access broker or automation (a JIT or PAM product, an identity governance tool), and who received the role.	If it is not expected, remove the assignment and contain the app as above. If it is an access broker, confirm the grant matches a request.
EntraID_App_Role_Assigned	The role and the recipient, and whether the app manages roles as part of its job.	Confirm with the app's owner, and remove the assignment if it is not expected.
EntraID_App_Credential_By_App	Which app was keyed, and what permissions that app holds. A secret added to a highly privileged app is the persistence step.	Remove the new secret or certificate from the target app and contain the acting app. Rotating the acting app's own credential does not remove the one it added elsewhere.

Rule IDs are the same on every instance. To find these alerts, search behavior events by rule name. Each rule is also listed by name on the Behavior Rules page.

References

• Microsoft Threat Intelligence, AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise (Storm-0940), October 21, 2026.
• Huntress, ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks, October 16, 2026, updated October 19, 2026.