> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # ConnectWise credential compromise grants access to 173 Microsoft 365 tenants - URL: https://f4n6.co.uk/security-feed/connectwise-credential-compromise-grants-access-to-173-microsoft-365-tenants/ - Published: 2026-10-17T12:04:45.000Z - Updated: 2026-10-17T12:04:45.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary A credential belonging to ConnectWise Cloud Backup (formerly SkyKick) was used to authenticate into customer Microsoft 365 tenants and obtain Microsoft Graph access tokens, with Huntress confirming unauthorized sign-ins in 162 tenants as of 19:00 UTC on October 16 and The Hacker News reporting 173\. The credential is a client assertion held in the vendor's own tenant, so no customer-side configuration change caused the access and no customer-side control could have prevented it. Any organisation with the ConnectWise Cloud Backup application consented in its tenant is in scope, and the application's backup and restore role means the tokens carry read and write access to mailboxes, OneDrive, SharePoint, Teams and directory data. For EMEA financial services clients this is a third-party identity compromise with a direct path to bulk data access across the tenant, and the exposure is not bounded by the tenants confirmed so far. No CVE is associated with this item and no CISA KEV entry applies. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | DORA Art. 28: ICT third-party risk, general principles | The compromise sits with an ICT third-party provider (ConnectWise Cloud Backup) whose credential grants access into the client's own M365 tenant | The client must treat this as a third-party ICT risk event and assess its own contractual and monitoring position with the provider, not only its internal controls | | DORA Art. 19: reporting of major ICT-related incidents to competent authorities | Unauthorized access to the client's M365 tenant via a vendor credential, where the client's own data may have been read or written | If the incident meets the client's major-incident classification, the reporting clock and competent-authority notification run from the client's own detection, not from the vendor's disclosure | | NIS2 Art. 21(2)(d): supply chain security measures | The access path is a vendor-held credential with broad delegated permissions across the client's tenant | The client must be able to evidence supply chain security measures over the provider, including what access the provider's application holds and how that access is monitored | ## 3\. Technical analysis & attack chain ConnectWise Cloud Backup is a cloud backup and recovery service for MSPs, protecting client Microsoft 365 and Google Workspace data. To do that it is granted broad access to mailboxes, OneDrive, SharePoint, Teams and directory data in every tenant where it is installed. The application authenticates using a client assertion, meaning the credential lives in the vendor's tenant rather than the customer's. An actor holding that credential can authenticate to the application with their own tooling and receive tokens carrying the application's existing permissions. Confirmed steps: 1. On October 15, between 06:13 and 08:34 UTC, the ConnectWise Cloud Backup application identity signed in to customer Microsoft 365 tenants from 144.172.64\[.\]128, a hosting provider address, and received Microsoft Graph access tokens. Legitimate traffic for this application comes from Azure private IP space, so the source address is anomalous. 2. The actor moved through tenants in sorted GUID order, a few seconds apart, consistent with a script working from a target list rather than interactive access. 3. Huntress confirmed unauthorized sign-ins in 162 tenants as of 19:00 UTC on October 16\. The Hacker News reports 173 tenants. The authentication evidence comes from Microsoft's own sign-in logs in each tenant, so the sign-ins themselves are certain. 4. Because backup and restore both require read and write, the tokens the actor obtained carry the same broad permissions as the service: read access to the mailboxes, files and directory data the backup service can reach. Huntress observed related activity from the same infrastructure that it has not tied to the vendor credential with the same certainty: - October 13 to 14: password spraying against four law firm tenants from 144.172.64\[.\]128, with scripted OAuth2 token requests using User-Agent curl/7.88.1 from datacenter infrastructure. Two accounts were locked out by smart lockout. Huntress saw no successful user sign-ins from this IP in its telemetry. - From 01:58 UTC on October 15: in roughly 50 tenants monitored by Huntress, service principals for ConnectWise's Cloud Management apps (Exchange Online, Microsoft Teams and Microsoft Graph) assigned themselves directory roles, mostly Exchange Administrator. The User-Agent on these events was kiota-dotnet, the one ConnectWise's own apps use, which points to vendor automation, but Huntress states it has not confirmed this with ConnectWise. - October 15, 03:44 to 03:49 UTC, in one customer tenant: the ConnectWise Cloud Management app for Microsoft Teams (application ID 24205314-2b89-4e07-a2a4-579e898a5640) added itself to the Global Administrator role, then ran a Python script (User-Agent Python-urllib/3.12) that modified two other applications in the tenant, an MSP management application and Huntress's own application (Huntress Security Platform), adding new client secrets to both. A follow-up attempt to add a certificate failed. The new secrets were set to expire in 2028. Confidence caveats. The credential compromise and the tenant sign-ins are corroborated: Huntress reads them from Microsoft sign-in logs, ConnectWise has acknowledged the incident on its website and confirmed the IP is associated with unauthorized activity, and Todyl has also reported on it. The directory-role self-assignment, the Global Administrator escalation, the application modification and the client-secret additions are single-sourced to Huntress and, for the kiota-dotnet User-Agent, explicitly unconfirmed with ConnectWise. Treat the escalation chain as a working hypothesis to hunt for in your own logs, not as established fact. No actor is named in the source material and no attribution is made here. The source does not state whether data was read or exfiltrated, only that the tokens permitted it. ## 4\. Mitigation & containment P1 within 24 hours - Identify every tenant where the ConnectWise Cloud Backup application is consented. The credential works against every tenant the app is consented in, so the affected population is not limited to the 162 or 173 tenants reported. - Pull Microsoft Entra sign-in logs for the application identity and search for authentication from 144.172.64\[.\]128, and more broadly for application sign-ins originating outside Azure private IP space. The window of confirmed activity is October 15, 06:13 to 08:34 UTC; extend the search to October 13 to cover the earlier password spraying. - Review Entra audit logs for service principals of the ConnectWise Cloud Management apps (Exchange Online, Microsoft Teams, Microsoft Graph) assigning themselves directory roles, particularly Exchange Administrator, and for any addition to the Global Administrator role. Check specifically for application ID 24205314-2b89-4e07-a2a4-579e898a5640. - Review all application credential changes in the tenant: new client secrets or certificates added to any app registration, with attention to secrets set to expire in 2028\. Remove any secret or certificate you cannot account for and rotate the credentials of any application that was modified. - If the tenant shows any of the escalation behaviour above, treat the ConnectWise Cloud Backup tokens as compromised and revoke the application's sessions and refresh tokens, then re-consent only after ConnectWise confirms the credential has been rotated. - Contact ConnectWise for confirmation that the affected credential has been revoked and rotated, and for the definitive list of tenants where the application identity authenticated from the anomalous address. P2 within 72 hours - Reduce the application's standing permissions to the minimum the backup function requires, and remove any directory role granted to the service principal that is not needed for backup. - Enable and alert on Entra ID sign-in risk and application sign-in logs, with an alert on application authentication from non-Azure address space. - Confirm smart lockout and password spray protections are active on all tenant accounts, given the October 13 to 14 spraying against law firm tenants. P3 within 7 days - Add the vendor application identity to the third-party access inventory with its granted permissions, and set a review cadence for those permissions. - Review the contract with ConnectWise against DORA Art. 30 key contractual provisions, covering breach notification timelines and the provider's obligation to notify you of credential compromise. ## 5\. Indicators of compromise | type | value | confidence | source | | -------------- | ------------------------------------ | ---------- | -------------------------------------------------------------------------------------------------------- | | ipv4 | 144.172.64\[.\]128 | high | Huntress, confirmed by ConnectWise as associated with unauthorized activity | | user-agent | curl/7.88.1 | medium | Huntress, observed in password spraying October 13 to 14 | | user-agent | kiota-dotnet | medium | Huntress, observed on directory-role assignment events; vendor automation not confirmed with ConnectWise | | user-agent | Python-urllib/3.12 | medium | Huntress, observed on the Python script that modified two tenant applications | | application-id | 24205314-2b89-4e07-a2a4-579e898a5640 | high | Huntress, ConnectWise Cloud Management app for Microsoft Teams | ```iocs ipv4 144.172.64[.]128 user-agent curl/7.88.1 user-agent kiota-dotnet user-agent Python-urllib/3.12 application-id 24205314-2b89-4e07-a2a4-579e898a5640 ``` Behavioural indicators | behaviour | where to observe | confidence | | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ---------------------------------- | | Application identity authenticating from a hosting provider address rather than Azure private IP space | Entra sign-in logs, application sign-ins | high | | Sign-ins across many tenants in sorted GUID order, seconds apart | Entra sign-in logs, correlated across tenants | high | | Service principals for ConnectWise Cloud Management apps assigning themselves directory roles, mostly Exchange Administrator | Entra audit logs | medium, single-sourced to Huntress | | An application adding itself to the Global Administrator role | Entra audit logs | medium, single-sourced to Huntress | | New client secrets added to unrelated applications, set to expire in 2028 | Entra audit logs, app registration credential changes | medium, single-sourced to Huntress | | Failed attempt to add a certificate to an application | Entra audit logs | medium, single-sourced to Huntress | ## 6\. Detection The source material gives usable artefacts for a Sigma rule: the anomalous source IP, the three User-Agents, and the application ID. These are log and behavioural indicators, so a Sigma rule is the appropriate form. No file artefacts, strings or hashes are present, so no YARA rule is authored. ```yaml title: ConnectWise Cloud Backup Application Sign-In from Anomalous Hosting Address id: 8f2c1a44-7b6e-4d19-9c3a-2e5f0b7a1d63 status: experimental description: Detects Microsoft 365 application sign-ins from the hosting provider address used in the ConnectWise Cloud Backup credential abuse campaign, and related anomalous User-Agents. author: Adverse Trace date: 2026-10-17 references: - https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access - https://thehackernews.com/2026/10/hackers-use-compromised-connectwise.html logsource: product: azure service: signinlogs detection: selection_ip: IPAddress: '144.172.64.128' selection_ua: UserAgent|contains: - 'curl/7.88.1' - 'kiota-dotnet' - 'Python-urllib/3.12' condition: selection_ip or selection_ua falsepositives: - Legitimate administrative scripting using curl or Python from approved infrastructure - ConnectWise vendor automation using kiota-dotnet, which is expected for the vendor's own apps level: high ``` ```yaml title: Directory Role Self-Assignment by ConnectWise Cloud Management Service Principal id: 3d9b7e21-5a4c-4f88-b0d2-6c1e8a9f2b47 status: experimental description: Detects a service principal adding itself to a privileged directory role, and application credential additions, consistent with post-compromise escalation observed in the ConnectWise Cloud Backup campaign. author: Adverse Trace date: 2026-10-17 references: - https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access logsource: product: azure service: auditlogs detection: selection_role: ActivityDisplayName|contains: 'Add member to role' TargetResources|contains: 'Exchange Administrator' selection_globaladmin: ActivityDisplayName|contains: 'Add member to role' TargetResources|contains: 'Global Administrator' selection_appid: InitiatedBy|contains: '24205314-2b89-4e07-a2a4-579e898a5640' condition: selection_appid or selection_role or selection_globaladmin falsepositives: - Legitimate administrative role assignment during onboarding or break-glass procedures level: high ``` ## 7\. Sources - Huntress, "ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks", https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access, accessed 2026-10-17 - The Hacker News, "Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants", https://thehackernews.com/2026/10/hackers-use-compromised-connectwise.html, published 2026-10-17 - ConnectWise incident acknowledgement on its website, referenced by Huntress, not directly retrieved - Todyl reporting on the incident, referenced by Huntress, not directly retrieved ## 8\. Adverse Trace position The tenant sign-ins are confirmed by Microsoft sign-in logs and acknowledged by ConnectWise, so the credential compromise is treated as established; the escalation chain (directory-role self-assignment, Global Administrator addition, client-secret injection) is single-sourced to Huntress and is treated as unconfirmed until corroborated. No actor is named and no attribution is made. The severity of the exposure is high for any client with the ConnectWise Cloud Backup application consented, because the tokens carry read and write access to mailboxes, files and directory data, and the affected population is not bounded by the tenants reported so far. Clients should assume their tenant is in scope until ConnectWise confirms otherwise, and should hunt the behavioural indicators in §5 rather than wait for a vendor list. Adverse Trace will monitor for ConnectWise's credential rotation confirmation and for corroboration of the escalation chain, and will update this advisory when either lands. --- [Read the original source →](https://thehackernews.com/2026/10/hackers-use-compromised-connectwise.html?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*