An investigation-driven approach to detecting compromised service principals, cross-tenant authentication, privilege escalation, and application-level persistence in Microsoft cloud environments.
Key Points
- Attackers used stolen ConnectWise app credentials to sign into customers’ Microsoft 365 tenants as ConnectWise’s own apps. MFA never applied because no user ever signed in.
- Secrets an attacker adds to other applications keep working after you disable the original integration or rotate its credentials.
- Correlated steps beat any single indicator. Hunt for an unusual app sign-in, then a role change, then new credentials on a second app.
Introduction
On Oct. 15, 2026, attackers used stolen ConnectWise application credentials to sign in to customers’ Microsoft 365 tenants as ConnectWise’s own apps. Huntress confirmed unauthorized sign-ins in at least 162 tenants. ConnectWise Cloud Backup, formerly SkyKick, was the first app reported, but the attackers had access to all of ConnectWise’s apps.
Those apps connect to customer tenants the way most third-party integrations do. Backup platforms, monitoring solutions, security products, and managed service providers frequently rely on Microsoft Entra ID application identities to access organizational resources without an interactive user sign-in, and they operate with extensive permissions.
That’s a pretty significant security challenge. What happens when an attacker steals a trusted third-party application's credentials?
Unlike traditional account compromise, malicious activity involving service principals doesn’t generate familiar indicators such as suspicious MFA prompts, impossible travel, or interactive user sign-ins. Instead, an attacker can authenticate through an existing application identity, acquire access tokens, interact with Microsoft Graph, and potentially modify sensitive directory configurations.
At first, this activity appears indistinguishable from legitimate vendor operations.
The ConnectWise case shows how an attacker turns one of these trust relationships into Microsoft 365 access, higher privileges, and persistence through credentials added to other applications.
This post takes the defender's side. Known indicators of compromise get you started. The rest is about spotting suspicious application behavior and catching unauthorized access when the attacker is operating through an identity you once trusted.
By the end, we hope it will help you develop a practical, hypothesis-driven threat hunting methodology that extends beyond a single incident.
Understanding the attack surface
Let’s establish what we’re working with. Microsoft Entra ID distinguishes between application registrations and service principals.
An application registration defines an application's identity and configuration. A service principal is an instance of that application within a particular tenant.
Third-party applications can use credentials, certificates, or federated identity mechanisms to authenticate and request access tokens for resources such as Microsoft Graph, Exchange Online, and SharePoint Online.
When attackers obtain usable application credentials, they can authenticate as the application without compromising an individual user account.
Authentication logs identify the application and its source, but they do not necessarily reveal who is operating the credentials.
A successful service principal sign-in therefore establishes that authentication occurred. It does not independently establish that the activity was authorized.
Defining the threat hunting scope
We hunt for this kind of activity across customer environments, starting with known infrastructure and application identities and expanding into behavior-based detection. The first three IP addresses and all seven application IDs below come from ConnectWise’s security advisory. The fourth IP, 144.172.94[.]243, comes from Huntress’s investigation.
Network indicators
Use these indicators as pivots. Attacker infrastructure changes, and this list is not exhaustive.
Application identities
The following application IDs belong to ConnectWise’s integrations, as listed in its advisory.
Seeing one of these application identities in your tenant does not establish compromise. They are legitimate integrations. Their presence tells you where to look.
The question is whether these identities have authenticated or made administrative changes in ways your organization has not seen from them before.
Building a layered hunting methodology
A comprehensive investigation covers six areas. Each one moves the hunt a step further from indicator searches toward the compromise mechanism itself.
- Authentication and exposure. Application identities, known infrastructure, token issuance.
- Behavioral deviations. Source changes, dormant identities, automation patterns.
- Privilege escalation. Directory role assignments and permission expansion.
- Persistence. Client secrets, certificates and secondary applications.
- Resource access. Graph, Exchange, SharePoint, Teams and Azure.
- Post-containment validation. Residual credentials and continued access.
Covering all six areas keeps an incident-driven threat hunt from concluding that an environment is unaffected simply because the known malicious IP addresses never showed up in the logs.
How to develop a threat hunting hypothesis
Hypothesis group A: Suspicious application authentication
An attacker may use compromised application credentials to request tokens from unexpected infrastructure or in tenants where the application is not normally active.
Hunt for:
- Successful or attempted service principal authentication from known suspicious IP addresses.
- Authentication involving the identified ConnectWise application IDs.
- First-seen source IP addresses, ASNs, or geographic locations for established applications.
- Unexpected application-only token requests against Microsoft Graph or other resource audiences.
- Previously dormant third-party applications becoming active.
- Unusual failures indicating invalid credentials, missing service principals, or disabled integrations.
- Application authentication occurring outside established vendor operation patterns.
Hypothesis group B: Behavioral anomalies and cross-tenant activity
An attacker may automate authentication against multiple tenants using the same application identity.
Potential indicators include rapid sequential authentication, repetitive token requests, and unusual resource-access patterns.
Establish a historical baseline for each application identity.
These anomalies need context before you call them malicious. Vendor infrastructure changes, load balancing, and ordinary cloud service routing produce the same patterns.
Hypothesis group C: Privilege escalation
A compromised application identity with sufficient directory permissions can assign privileged roles or expand access.
Hunt for:
- A service principal assigning Global Administrator to itself.
- Privileged directory roles assigned to other applications.
- Unexpected changes to application permissions.
- New administrator consent grants.
- Addition of application owners.
- Changes involving Directory.ReadWrite.All, Application.ReadWrite.All, or RoleManagement.ReadWrite.Directory.
Prioritize privileged role assignments initiated by an application, especially when the target principal is the initiating application itself.
The nested target information must be parsed to establish whether self-assignment occurred.
Hypothesis group D: Application credential persistence
An attacker with sufficient permissions may add a client secret or certificate to an existing application. The attacker can then authenticate as that application.
Hunt for:
- Unexpected creation of passwordCredentials or keyCredentials.
- One service principal modifying another application's credentials.
- New credentials on privileged or security-sensitive applications.
- New credential identifiers appearing in subsequent sign-ins.
- Previously dormant applications authenticating after credential changes.
- Continued authentication through secondary applications after the original integration is disabled.
For a conclusive investigation, analysts should inspect the modified properties, compare credentials against a historical inventory, and correlate the new credential key IDs with later authentication where telemetry permits.
Hypothesis group E: Reconnaissance and resource access
Once the attacker acquires the application token, they may attempt to enumerate directory objects or access resources permitted by the application.
Hunt for:
- Unusual Microsoft Graph requests targeting users, groups, service principals, application registrations, and directory roles.
- Unexpected Exchange Online operations.
- High-volume SharePoint or OneDrive file access.
- Suspicious Teams API activity.
- Azure Resource Manager enumeration.
- Partner Center activity inconsistent with normal delegated administration.
- Mailbox forwarding rules, inbox rules, or permission changes.
- Access to sensitive resources shortly after anomalous application authentication.
Not every Microsoft Graph read operation produces an Entra audit event. Investigators should distinguish between successful authentication, observed resource access, and confirmed data extraction.
A lack of recorded resource activity is not necessarily evidence that the attacker performed no reads.
Hypothesis group F: Post-containment persistence
Check whether access remains possible after you disable the original compromised integration.
Hunt for:
- Secondary applications continue authenticating after containment.
- Newly created credentials remain valid on unrelated applications.
- Privileged role assignments have not been reversed.
- Suspicious OAuth grants remain active.
- Previously disabled applications are reactivated.
- New credentials are added again after removal.
- Authentication resumes through alternative source infrastructure.
Rotating one application’s credentials doesn’t remove independent credentials created on other application identities.
Correlating events into an attack sequence
Each of the five events below can pass for routine activity on its own. The investigative value increases when these events form a meaningful sequence.
- Unusual application authentication — A trusted application authenticates from previously unseen infrastructure.
- Privileged directory operation — The same application performs an unexpected role assignment or permission modification.
- Secondary credential creation — A new secret or certificate is added to another application identity.
- Authentication through the secondary identity — The modified application begins authenticating from unfamiliar infrastructure.
- Continued access after containment — The original integration is disabled, but authentication through the secondary application continues.
This sequence connects initial access, privilege escalation, persistence, and possible lateral movement between application identities.
A detection built on this sequence outlives any single IP-based rule.
Lessons for threat detection engineering
Application identities require behavioral baselines. Most organizations watch user sign-ins more closely than service principal activity. Privileged application identities should receive the attention privileged user accounts get.
Changes to application secrets, certificates, and federated credentials can be both legitimate maintenance and persistence. Which one it is depends on who made the change and which application they changed.
Privilege escalation and persistence should be correlated. An unexpected privileged role assignment followed by credential modification on another application is a stronger indicator than either event alone.
An activity pattern that looks ordinary in one tenant becomes suspicious when you see it repeated across many. ConnectWise's apps signing in from new infrastructure looked routine in any single tenant. Across 162 of them, it was the incident.
Containment requires relationship analysis. Security teams should understand which applications can modify other identities, which permissions were granted, and whether additional access paths remain after the initial integration is disabled.
Conclusion
Compromised third-party application credentials are hard to catch because the attacker operates through an identity the tenant already trusts.
Known infrastructure and application identifiers are useful for initial scoping, but they are only the first layer of the investigation.
Effective hunting requires understanding how application identities authenticate, what permissions they possess, how their behavior changes, which other identities they can modify, and whether unauthorized access persists after containment.
The most valuable detections are those that connect authentication anomalies with administrative actions and credential changes.
A suspicious application sign-in is where the hunt starts, not where it ends. The question is whether the attacker abused the trust the tenant granted that application, what they did with the token once they had it, and whether they opened new paths of access.
Answering those three questions turns an IOC search into a hunt you can run again the next time a vendor's application credentials leak.
