Loading…
A stolen vendor app secret skips MFA. Check service principal sign-ins, app credentials and role grants in Entra ID, disable risky apps, and tighten consent before free-tier logs age out.
LiteLLM 1.107.0 on PyPI and Docker shipped a credential stealer and backdoor. How to check if you're affected, what to rotate first, and how to clean up.
9 min read
One attacker pointed AI agents at 1,200+ sites and got into 100+ companies. Here's what the agents hunted for and how to close each door on your own site.
9 min read
A vendor app secret can sign into your Microsoft 365 tenant as the app itself. User MFA never fires. If you are on free Entra ID, sign-in and audit logs from mid-October roll off within days — so export what you have now, then run the same checklist against every enterprise app, not just the one in the news.
In mid-October 2026, a credential for the ConnectWise Cloud Backup app (formerly SkyKick) was used to sign into customer Microsoft 365 tenants as that app and obtain Microsoft Graph tokens. Huntress reported that because the sign-in was an application identity, user MFA never applied. Huntress confirmed unauthorized sign-ins in 162 tenants as of 19:00 UTC on October 16; The Hacker News later reported 173. Microsoft Threat Intelligence tracked the incident as an active supply-chain attack via the trusted OAuth app.
Huntress placed the bulk of observed sign-ins on October 15 between roughly 06:13 and 08:34 UTC, from the defanged source 144.172.64[.]128, hitting tenants in sorted GUID order a few seconds apart — consistent with a scripted sweep. ConnectWise suspended Cloud Backup by revoking credentials for the affected app connections and stated shared credentials were no longer valid; partners still have to review their own tenants because ConnectWise cannot see downstream environments. There is no CVE here — this was a stolen app credential, not a disclosed product vulnerability.
A service principal is the app's identity inside your tenant. When you grant that app broad application permissions — mail, files, Teams, directory — and the vendor holds a client secret or certificate, whoever gets that credential can call Graph with the app's rights. No interactive user login means no MFA prompt. BleepingComputer, citing Todyl's analysis of nine tenants, reported that the app's existing permissions allowed read and write of mail, OneDrive and SharePoint files, and Teams chats, and that only sign-in activity was observed in those nine — which is still enough reason to treat the identity as compromised until you prove otherwise.
Most admins stare at interactive user sign-ins by default. Service principal sign-ins are a separate log type in Microsoft Entra ID (Microsoft Learn: Sign-in logs). If you never open that tab, an app walking your mailbox looks quiet.
The Graph access token that comes back is a JWT. For your own test tokens only, decode the payload with the JWT debugger so aud, roles, and expiry are readable — background on claims is in What is a JWT?. Protocol-level OAuth bugs in web apps are a different problem; for those, see the OAuth 2.0 / OIDC auditing tutorial. Tenant-side Entra hardening for storage and RBAC lives in the Azure Blob / Entra ID security checklist.
In Microsoft Entra admin center → Enterprise applications, search for App ID 506e08f9-6e9a-4da4-942b-a099a03644ae (ConnectWise Cloud Backup). Clear the default filter if the app does not show. Huntress also names 24205314-2b89-4e07-a2a4-579e898a5640 (ConnectWise Cloud Management – MS Teams).
Open Service principal sign-ins for those apps. Look for sources outside Microsoft and Azure infrastructure — Huntress and Microsoft cited 144.172.64[.]128. Confirm whether an IP is a Microsoft range or a hosting provider with IP address info and reverse DNS lookup.
Huntress and BleepingComputer also reported that on roughly fifty tenants the Cloud Management apps assigned themselves directory roles (mostly Exchange Administrator) and that in one tenant the MS Teams app gave itself Global Administrator and added credentials to two other apps. Disabling the ConnectWise app does not remove credentials an attacker already planted elsewhere — hunt those separately under Certificates & secrets on every other high-privilege app.
Run this for every high-privilege enterprise app, not only ConnectWise. The news will fade; the audit should not.
1. Inventory apps and permissions. Enterprise applications → open each third-party or vendor app → Review permissions. Note application (app-only) vs delegated grants, and anything ending in .All (for example Directory.ReadWrite.All). Microsoft Learn's guide on reviewing enterprise app permissions is the reference path. Write down an owner for each app that holds mail, files, or directory scopes — orphaned vendor apps are how this class of incident outlives the news cycle.
2. Read service principal sign-ins. Sign-in logs → Service principal sign-ins. Filter by the app, unusual IPs, spikes, or activity outside change windows. An app that never signs in and suddenly does is a lead. Compare source IP geography and ASN against what you expect for that vendor's infrastructure.
3. Pull the right audit activities. In the audit log, filter for:
Those activity names come from Microsoft Learn's application-permissions audit table and the Entra security operations guide for applications. Sort by time overlapping any suspicious sign-in window.
4. Check app credentials. On each app, open Certificates & secrets (or the equivalent credentials blade). Look for secrets or certificates added recently that your change process did not create. Huntress's point stands: disabling one compromised app does not erase credentials already added to other apps. Rotate anything you cannot attribute.
5. Look for directory roles on service principals. Service principals should almost never hold Global Administrator or Exchange Administrator. If an app granted itself a directory role, treat that as a containment event, not a curiosity. Remove the role assignment after you have exported the evidence.
For a confirmed or strongly suspected app:
Microsoft Learn's Entra data retention table is blunt: Entra ID Free keeps audit and sign-in logs for 7 days; P1/P2 keep 30 days. Buying P1 later does not resurrect free-tier logs that already aged out. Tenants hit around October 15 lose that evidence around October 22 if they stay on free retention.
Export service principal sign-ins and the audit activities listed above to storage you control before the window closes. Even a CSV pulled today is better than a blank console next week. If you run many tenants (MSP or multi-cloud), queue the exports by risk: apps with mail or directory .All scopes first.
*.All application permissions — quarterly is a minimum for tenants that add vendor tools often.Agents and MCP servers that touch Microsoft 365 usually get the same kind of app registration and Graph scopes. Same failure mode: one leaked secret, no MFA on the app path, scopes far wider than the job. Scope them tightly with MCP tool permissions and least privilege, keep their secrets out of the agent with AI API key security for agents and MCP, and vet an MCP server before you connect it — the MCP directory is for discovery after that bar, not instead of it.
Then put a runtime gate between the agent and its tools. SentinelAgent Guard enforces policy on agent tool calls at runtime (22 controls, mcpgrade-2.0.0). Andrax's MCP scanner grades a server before you connect (39 checks, scanner 1.4.0). Those are different layers. A grade finds risk; a gate enforces policy.
506e08f9-6e9a-4da4-942b-a099a03644ae and 24205314-2b89-4e07-a2a4-579e898a5640 (and clear filters)144.172.64[.]128)*.All)Share this article
Complete operational masterclass guide to 25+ AWS IAM privilege escalation paths: from policy version hijacking and PassRole confused-deputy exploits to Pacu/PMapper automation, custom Boto3
11 min read
Sign in to leave a comment.