Blog

Your Backup Vendor’s App Just Became a Global Admin: Non-Human Identity Drift Across Microsoft 365, Cloud Platforms, and Alike

A backup vendor’s app made itself Global Admin and planted secrets on other apps. How non-human identity drift beats scanners, and the checks to run this week.

October 19, 2026

-

-

Min Read

When an engineering or IT team integrates a third-party SaaS tool—whether for cloud backup, log aggregation, or asset management into Microsoft 365, Google Workspace, AWS, or alike—the transaction feels routine. The admin consents to scoped API permissions so the integration can sync mailboxes, replicate data stores, or parse telemetry.

That is the declared policy. The events of mid-October 2026 showed what a system can actually do with that consent.

Between 06:13 and 08:34 UTC on October 15, an attacker used compromised credentials belonging to ConnectWise Cloud Backup (formerly SkyKick) to initiate automated Microsoft Graph token requests across customer tenants. Incident response telemetry from Huntress identified sign-in activity targeting nearly 1,000 organizations, confirming unauthorized access in over 300 tenants.

The credential originated directly within ConnectWise’s internal infrastructure. In Huntress’s words: "Nothing a customer did in their environment could have produced it."

While mass token requests represented broad reconnaissance, the critical architectural lesson took place inside a customer tenant investigated by Huntress: at 03:44 UTC, a related identity from the same ecosystem—ConnectWise Cloud Management for Microsoft Teams—promoted itself to the Global Administrator directory role. Within five minutes, it generated and attached new client secrets (configured to expire in 2028) to two unrelated applications in the tenant: an MSP management tool and Huntress's own security platform. Huntress subsequently identified the identical self-elevation and persistence pattern in a second tenant.

ConnectWise responded transparently, disabling seven application identities, suspending affected services, and releasing detailed remediation guides. Microsoft confirmed that the attacker abused broad application permissions previously granted by customers, specifically high-privilege scopes such as Directory.ReadWrite.All.

The policy said: "Backup data."
The runtime execution said: "Grant Global Administrator and plant secondary backdoors."

1. The Non-Human Identity (NHI) Problem Is Universal

While this incident unfolded within Microsoft Entra ID, the vulnerability is not unique to Microsoft. It is the systemic design of modern cloud architecture.

Whether managing Microsoft 365, AWS, Google Cloud, Salesforce, or modern developer pipelines, the majority of access is no longer human. It belongs to Non-Human Identities (NHIs): OAuth applications, service principals, cross-account IAM roles, and automated machine agents.

These programmatic identities bypass the entire security stack engineered for human operators:

  • Zero Interactive Friction: Service principals and IAM roles do not answer MFA prompts, undergo biometric verification, or carry physical FIDO2 security keys.
  • Conditional Access Blind Spots: Security teams routinely exempt automated data pipelines and third-party SaaS tools from location and IP restrictions to avoid breaking operational syncing. Once an API token or credential is stolen, the bearer can execute requests from any hosting provider IP in the world.
  • Asymmetric Logging: Across Microsoft 365 and major cloud control planes alike, programmatic directory reads frequently leave zero forensic trace, or strip originating IP addresses from basic-tier telemetry logs, leaving security teams blind to the true blast radius.

The attacker did not breach an endpoint or bypass an authentication challenge. They leveraged an authorized programmatic token to execute capabilities granted during an administrative onboarding flow approved years prior.

2. Remediating the Vendor vs. Remediating the Environment

One of the most critical warnings highlighted in ConnectWise’s remediation documentation applies to every cloud ecosystem: disabling the vendor's integration does not undo actions already executed inside your environment.

Identity-based attacks rely on decoupling the initial entry point from long-term lateral persistence:

‍

If an organization simply disconnects the vendor application, the attacker loses that initial front door. But if that application was used to inject an API secret into a secondary, trusted enterprise application within Microsoft 365 or an IAM role in an AWS account, the attacker retains persistent programmatic access under an entirely different identity.

‍

Remediation cannot stop at the perimeter of the compromised supplier; it requires continuous, deterministic verification of every downstream identity object in the environment.

3. The Scanner Trap: Why Identity Drift Bypasses Traditional Tools

Traditional vulnerability management relies on matching installed components against lists of known-bad artifacts (CVEs). If an unpatched binary or an outdated library is discovered, a ticket is raised.

The ConnectWise incident illustrates why this model cannot protect modern cloud environments:

  1. Zero Outdated Binaries: The cloud APIs, identity endpoints, and vendor services were running fully supported, current code.
  2. Authorized by Design: An identity holding permissions like Directory.ReadWrite.All or RoleManagement.ReadWrite.Directory that modifies directory roles or generates application secrets is fundamentally valid within the API specification.
  3. The Architectural Reasoning Gap: The failure is architectural, not a software bug. A static scanner cannot distinguish between an authorized administrative script updating application secrets and an attacker backdooring a tenant via an automated loop.
Scanners check inventory against known-bad catalogs. They cannot reason about your actual operational intent.

4. Turning Cloud Identity Governance into Behavioral Contracts

Most organizations maintain documented identity governance policies stating: "Third-party applications must adhere to least privilege, and administrative privileges are reserved strictly for authorized human personnel."

Yet almost no organization can mathematically prove whether that statement remains true between annual audits.

At Crowsnest, we built our platform to eliminate this gap by translating declared security policies into machine-enforceable Behavioral Contracts evaluated continuously at runtime:

  • Continuous Control Plane Verification: Rather than running periodic point-in-time scans, Crowsnest continuously evaluates directory roles, app registrations, service principals, cross-account IAM roles, and credential creations across Microsoft Entra ID, cloud infrastructure, and connected platforms on every state change.
  • Deterministic Invariant Enforcement: Behavioral contracts such as "No non-human identity may assign directory roles to itself" or "No third-party service principal may create credentials on peer applications" are evaluated immediately. If an identity attempts to cross those boundaries, drift is surfaced instantly with timestamped evidence.
  • Run Everywhere, In-Tenant, Zero Data Exfiltration: Evaluating cloud and identity posture should not require shipping sensitive directory metadata, employee details, or access logs to an external multi-tenant SaaS vendor. Crowsnest deploys directly into your environment—running on-host, on-cluster, and in-tenant via CrowAI. No customer operational data leaves your environment, giving you continuous proof while preserving absolute data sovereignty.
A policy that is not evaluated continuously at the runtime API layer is merely an assumption.

5. Technical Audit: What Engineering & Security Teams Must Run This Week

Whether managing Microsoft 365, AWS, Google Cloud, or hybrid environments, execute these technical checks immediately:

1. Audit All High-Privilege Roles Held by Non-Human Identities: Query your identity providers for third-party service principals, OAuth apps, or cross-account IAM roles holding administrative privileges (e.g., Global Administrator, Privileged Role Administrator, or AdministratorAccess policies). Ensure every assignment has a verified owner, a documented ticket, and an active business justification.

2. Scan for Stale and Newly Created Application Credentials: Export all client secrets, certificates, and programmatic access keys across your cloud providers. Filter for credentials created between October 13 and the present. Cross-reference every key against internal engineering change orders; immediately revoke any credential lacking documented lineage.

3. Implement Real-Time Alerts for In-Tenant Self-Elevation: Configure continuous monitoring on directory and audit logs (such as Entra ID Audit Logs or AWS CloudTrail) for two high-risk events:

  • Programmatic role assignments where the initiator is an app-only service principal or non-human identity.
  • Credential creation events where one service principal or automated workflow generates secrets or certificates on another application.

4. Inspect Conditional Access & IP Allowlist Exclusions: Review every policy enforcing trusted network locations or device-compliance checks. Identify every third-party service principal or workload identity explicitly excluded from these boundaries.

5. Verify Telemetry Retention Limits: Audit your retention windows across cloud control planes. Standard tiers often retain sign-in and audit telemetry for only 7 to 30 days. If your control plane logs are not being streamed into cold, immutable long-term storage, investigating an intrusion that occurred weeks prior becomes mathematically impossible.

The lesson from the ConnectWise incident is clear: modern compromises do not wait for quarterly audit cycles, and adversaries do not limit themselves to software bugs. They exploit the open permission surface of trusted non-human identities.

If your security posture relies on assuming an approved cloud application behaves only as intended, you are operating on assumption. Closing that gap requires continuous runtime evidence that your systems—and every external identity inside them—execute strictly within the behavioral boundaries you define.

Sources & References

  • Huntress Technical Analysis: Vendor Credential Enables Unauthorized Access across M365 Customers
  • ConnectWise Trust Center: Cloud Backup Service Interruption Advisory & Remediation Guide
  • The Hacker News: Hackers Abuse Compromised ConnectWise Credential to Target Microsoft 365 Tenants

‍

Prove your systems are doing their job

See how Crowsnest helps security teams uncover blind spots, validate coverage, and prove what their stack is doing.