> ## 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 SkyKick credentials abused for mass M365 tenant access and persistence - URL: https://f4n6.co.uk/security-feed/connectwise-skykick-credentials-abused-for-mass-m365-tenant-access-and-persistence/ - Published: 2026-10-17T20:49:06.000Z - Updated: 2026-10-17T20:49:06.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary A credential belonging to ConnectWise Cloud Backup (formerly SkyKick) was used on 2026-10-15 to authenticate as the application itself into customer Microsoft 365 tenants and obtain Microsoft Graph tokens, with Huntress confirming unauthorized sign-ins in 162 tenants as of 19:00 UTC on 2026-10-16\. The credential is a client assertion held in the vendor's own tenant, so no customer-side misconfiguration produced it and no customer action could have prevented the initial access. In one tenant the actor escalated from the vendor application to Global Administrator, then added client secrets to two further applications, including a security tool, giving persistence that survives rotation of the original ConnectWise credential. Any EMEA financial services firm with the application consented, directly or through an MSP, should treat its tenant as potentially accessed: the application holds read and write access to mail, OneDrive, SharePoint, Teams and directory data, and directory reads through Microsoft Graph leave no audit trail. No CVE is associated with this item and no exploitation entry exists for it in CISA KEV. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 28: ICT third-party risk, general principles | The compromised credential belongs to a third-party backup provider and is held in that provider's tenant, not the client's. | The incident is a third-party ICT risk event. Contractual and risk-management arrangements with the provider, and with any MSP that consented the application, are in scope for review. | | DORA Art. 30: key contractual provisions with ICT third-party providers | The provider's credential was used to access client tenant data, and the client cannot remediate the root cause (the vendor-held credential) itself. | Check whether the contract requires the provider to notify of credential compromise, to reset credentials, and to support the client's incident handling. | | NIS2 Art. 21(2)(d): supply chain security measures | The attack path runs through a supplier's application identity that is consented into the client's environment with broad permissions. | Supply chain security measures must cover the permissions granted to supplier application identities and the credentials attached to them. | ## 3\. Technical analysis & attack chain ConnectWise Cloud Backup is a cloud backup and recovery service for MSPs, protecting 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 credential abused here is a client assertion, meaning it lives in ConnectWise's own tenant. Huntress states the authentication is certain because it comes from Microsoft's own sign-in logs in each tenant, and that nothing a customer did in their environment could have produced it. Confirmed sequence, from Huntress telemetry and tenant audit logs: 1. 2026-10-13 to 2026-10-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. 2. 2026-10-15 from 01:58 UTC: in roughly 50 tenants monitored by Huntress, service principals for ConnectWise Cloud Management applications (Exchange Online, Microsoft Teams, Microsoft Graph) assigned themselves directory roles, mostly Exchange Administrator. The User-Agent on these events was kiota-dotnet, the one ConnectWise's own applications use. 3. 2026-10-15, 03:44 to 03:49 UTC, one customer tenant: the ConnectWise Cloud Management application 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 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\. The whole sequence took about five minutes; the application added itself to Global Administrator at 03:44 and again at 03:48, and made nine changes to the two applications, six succeeding and three failing. One failure was a certificate credential Microsoft rejected with a thumbprint mismatch. 4. 2026-10-15, 06:13 to 08:34 UTC: the ConnectWise Cloud Backup application authenticated from 144.172.64\[.\]128 and received Microsoft Graph tokens. Huntress confirmed this in 17 of the first roughly 290 tenants it checked, across 17 different partner accounts. The actor moved through tenants in sorted GUID order, a few seconds apart, consistent with a script working from a target list. Legitimate traffic for this application comes from Azure private IP space. The persistence mechanism is the credential addition. A client secret and a certificate are two ways for an application to prove its identity to Entra, and either gives the holder the same access: sign in as that application, from anywhere, with the permissions already granted. App-only sign-ins involve no user, no device and no MFA prompt, and the person who creates a secret sees its value at creation, so the attacker holds working credentials for both modified applications until someone removes them. Adding credentials to an existing application is MITRE ATT&CK T1098.001 (Account Manipulation: Additional Cloud Credentials). Huntress maps the wider activity to T1078.004 (Valid Accounts: Cloud Accounts) for use of the vendor credential and T1098.003 (Account Manipulation: Additional Cloud Roles) for the self-assigned administrator roles. The two applications that received new secrets are privileged tools. Adding a credential to an MSP management application can extend access beyond one tenant, because those applications are often consented into the MSP's customers' tenants. A credential on a security tool's application gives the holder whatever that tool is permitted to do. What the actor can do with the tokens depends on the permissions already granted in each tenant. A backup service normally holds read access to mail, files, Teams and directory data so it can copy them, and write access so it can restore them. An attacker holding tokens for that application inherits the same access: bulk reading of mail and files, downloading mailbox and OneDrive contents, enumerating users, groups and applications, and, where write permissions exist, changing or deleting data. If an application can assign directory roles, as seen in one tenant, it can make itself Global Administrator, and an administrator can add credentials to other applications, create new applications and grant them permissions, reset user passwords and authentication methods, and change Conditional Access policies. Each step gives another route back in that does not depend on the original vendor credential, which is why rotating that credential is necessary but not sufficient. Detection is constrained by logging. Microsoft's audit log records role assignments and application changes along with the acting application, but for app-only actions it carries no source IP, and it does not record the details of the credential that was added or what an application read through Microsoft Graph. Confirming exactly what was added in a tenant requires the Entra audit log or a Graph query for that tenant. The relevant audit events appear as Add member to role, Update application, and Add service principal credentials; the fields that matter are the initiating application, the target, the result and the user agent. Unconfirmed points, stated as such by Huntress. Impact: in the one tenant audit log reviewed in detail the actor shows no mail or file access, but directory reads through Microsoft Graph leave no audit trail, so "tokens issued, nothing visible taken" is the current state and does not establish that no data was taken. Secondary application exposure: ConnectWise has multiple applications with very high-level permissions, and Huntress cannot verify that the remaining ConnectWise applications are secure. Attribution between phases: the Global Administrator change and credential additions happened about two and a half hours before the first app authentications from 144.172.64\[.\]128 at 06:13 UTC, and Huntress has no source address for the earlier activity, so it has not tied the two phases to the same operator. Vendor automation: the kiota-dotnet User-Agent on the 01:58 UTC role assignments points to vendor automation, but Huntress has not confirmed that with ConnectWise. No threat actor is named in the source material and no MITRE ATT&CK group profile is available for this activity; attribution is unconfirmed. The User-Agents are not unique to this actor, and Python and curl are common in ordinary administration, so the combination of actor, operation and User-Agent is the useful signal rather than any single one. The 162-tenant figure is Huntress's confirmed count as of 19:00 UTC on 2026-10-16 and is a floor, not a total: the credential works against every tenant where the application is consented. The Hacker News report cites 173 tenants; the discrepancy is not explained in the material available and the Huntress figure is the one tied to a stated cut-off time. ## 4\. Mitigation & containment P1, within 24 hours: - Disable the application. In the Microsoft Entra admin center, go to Enterprise applications and search for Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, or search for "SkyKick" or "ConnectWise Cloud Backup". Open Properties and set "Enabled for users to sign-in" to No. Do not delete the application: deleting it removes the consent and you will need to re-consent to restore service. Disabling pauses automated backups until it is re-enabled; mail, files, Teams messages and user sign-ins keep working, and existing backups held by ConnectWise are not deleted. Assess whether a gap in recovery points is acceptable. - Search for and disable other ConnectWise and SkyKick applications you cannot verify as safe, again without deleting. Application IDs to look for: ConnectWise Cloud Backup 506e08f9-6e9a-4da4-942b-a099a03644ae; ConnectWise Cloud Management 2399d300-6fca-4e6a-a686-399fefe75b83; ConnectWise Cloud Management - MS Teams 24205314-2b89-4e07-a2a4-579e898a5640; ConnectWise Cloud Management - Exchange Online b78f6a77-d4e5-46fb-87e5-d1648bd02519; ConnectWise Cloud Management - MS Graph 0de14c77-b9b0-4137-9360-34878a929827; ConnectWise Cloud Management - Partner Center 412dcf96-176d-4b3a-a1b0-4981ad66971e; ConnectWise Cloud Management - SharePoint Online b2b55f5b-7758-4719-8d8f-88ae172e6bdb. In older tenants the Cloud Management applications may appear as "SkyKick Cloud Manager". - Review the credentials (client secrets and certificates) on all Enterprise applications and App registrations, especially management and security tools, for anything added since 2026-10-13 that you did not create. Remove anything unexpected. If you use Huntress, include the Huntress Security Platform application in this review. - Where a ConnectWise or SkyKick application holds a directory role, especially Global Administrator or Privileged Authentication Administrator, review it, and after the application is disabled remove any role you did not intentionally grant. - Check Entra audit logs for ConnectWise or SkyKick applications adding themselves to a directory role, and for those applications modifying other applications. In those events check the user agent: the ConnectWise Cloud Management and Partner Center applications reviewed by Huntress make their Graph calls with kiota-dotnet, while the application changes in the one tenant came from Python-urllib/3.12. - Do not re-enable any ConnectWise application until ConnectWise confirms all credentials have been reset. P2, within 72 hours: - Review Conditional Access. If any policy excludes this application, for example from a location-based block, the attacker's infrastructure will not be blocked there. Review those exclusions once the application is disabled. - Check sign-in logs directly. In the Entra admin center go to Monitoring > Sign-in logs, open the Service principal sign-ins tab, and filter by Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae. The default User sign-ins tab will not show this data. In the IP address column look for any address outside Microsoft and Azure ranges; the application's normal egress is Azure private IPv6\. Search for 144.172.64\[.\]128 specifically. A clean result does not rule out access, which is why the application should be disabled regardless. - Where you have the licensing and log access, query Microsoft Graph for credentials added to applications since 2026-10-13, since the audit log does not record the details of an added credential. P3, within 7 days: - Reduce standing exposure. Application management policies can restrict or block client secrets on app registrations and cap credential lifetimes. Limit who holds the Application Administrator and Cloud Application Administrator roles. Conditional Access for workload identities, which requires additional licensing, can restrict where an application may sign in from, and Microsoft Entra ID Protection can flag risky service principals. None of these replaces the credential review above. - Where an MSP consented these applications into your tenant, require the MSP to complete the same credential review across the tenants it manages, and confirm in writing that ConnectWise has reset the affected credentials before any application is re-enabled. ## 5\. Indicators of compromise | type | value | confidence | source | | -------------- | ------------------------------------ | ---------------------------------------------------------------------------------------------- | -------------------------------------------- | | ipv4 | 144.172.64\[.\]128 | high | Huntress; ConnectWise acknowledgement; Todyl | | user-agent | curl/7.88.1 | low (not unique to this activity) | Huntress | | user-agent | Python-urllib/3.12 | low (not unique to this activity) | Huntress | | user-agent | python-requests/2.31 | low (not unique to this activity) | Huntress | | user-agent | kiota-dotnet | low (vendor automation User-Agent, not attacker-specific) | Huntress | | application-id | 506e08f9-6e9a-4da4-942b-a099a03644ae | high (legitimate application; do not block the ID, disable the service principal) | Huntress | | application-id | 24205314-2b89-4e07-a2a4-579e898a5640 | high (legitimate application; do not block the ID, disable the service principal) | Huntress | | application-id | 2399d300-6fca-4e6a-a686-399fefe75b83 | high (legitimate application) | Huntress | | application-id | b78f6a77-d4e5-46fb-87e5-d1648bd02519 | high (legitimate application) | Huntress | | application-id | 0de14c77-b9b0-4137-9360-34878a929827 | high (legitimate application) | Huntress | | application-id | 412dcf96-176d-4b3a-a1b0-4981ad66971e | high (legitimate application) | Huntress | | application-id | b2b55f5b-7758-4719-8d8f-88ae172e6bdb | high (legitimate application) | Huntress | | tenant-id | 3f9cd7a0-127a-4ed4-bf06-2f830d5616b7 | medium (application owner tenant ID seen on the service principal events, the vendor's tenant) | Huntress | The application IDs above are legitimate Microsoft Entra applications. They are listed for identification and service principal review, not for blocking. Blocking the IDs will break the backup service and will not stop the abuse, which runs through the application's own identity. ```iocs ipv4 144.172.64[.]128 user-agent curl/7.88.1 user-agent Python-urllib/3.12 user-agent python-requests/2.31 user-agent kiota-dotnet application-id 506e08f9-6e9a-4da4-942b-a099a03644ae application-id 24205314-2b89-4e07-a2a4-579e898a5640 application-id 2399d300-6fca-4e6a-a686-399fefe75b83 application-id b78f6a77-d4e5-46fb-87e5-d1648bd02519 application-id 0de14c77-b9b0-4137-9360-34878a929827 application-id 412dcf96-176d-4b3a-a1b0-4981ad66971e application-id b2b55f5b-7758-4719-8d8f-88ae172e6bdb tenant-id 3f9cd7a0-127a-4ed4-bf06-2f830d5616b7 ``` Behavioural indicators | behaviour | where to observe | confidence | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | Service principal sign-in for the ConnectWise Cloud Backup application from an IP outside Microsoft and Azure ranges (normal egress is Azure private IPv6) | Entra admin center > Monitoring > Sign-in logs > Service principal sign-ins, filtered by Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae | high | | Service principal for a ConnectWise or SkyKick application adding itself to a directory role, most commonly Exchange Administrator, or to Global Administrator | Entra audit log event "Add member to role" | high | | A ConnectWise or SkyKick application modifying other applications in the tenant, including adding client secrets | Entra audit log events "Update application" and "Add service principal credentials" | high | | Client secrets added to applications with expiry set years out (observed expiring in 2028) that the tenant did not create | Entra audit log, or a Microsoft Graph query for application credentials | medium (observed in one tenant) | | Application changes originating from User-Agent Python-urllib/3.12 or python-requests/2.31, distinct from the kiota-dotnet User-Agent used by the vendor applications reviewed | Entra audit log user agent field on the events above | medium (User-Agents are not unique to this actor) | | Scripted OAuth2 token requests from datacenter infrastructure using curl/7.88.1, with account lockouts from smart lockout | Entra sign-in logs, user sign-ins | medium (low fidelity on its own; useful with the IP) | | Application sign-ins across many tenants in sorted GUID order, seconds apart | Entra sign-in logs across managed tenants | medium (pattern observed by Huntress across partner accounts) | ## 6\. Detection The source material contains no file hashes, file paths, registry keys, mutexes or scheduled task names. The usable artefacts are the observed User-Agent strings and the audit event names. The YARA rule below targets the User-Agent strings as they would appear in tooling or script content; the Sigma rule targets the Entra audit and sign-in behaviour. ```yara rule Cloud_App_Credential_Abuse_UserAgents { meta: author = "Adverse Trace" date = "2026-10-17" reference = "https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access" description = "Detects the User-Agent strings observed in the ConnectWise SkyKick credential abuse activity. Low fidelity on their own; use with the associated IP and audit events." strings: $ua1 = "Python-urllib/3.12" ascii wide $ua2 = "python-requests/2.31" ascii wide $ua3 = "curl/7.88.1" ascii wide condition: any of them } ``` ```yaml title: ConnectWise or SkyKick Application Self-Assigning Directory Role or Modifying Other Applications id: 8f2c1a44-5d3e-4b7a-9c10-6e2f0a1b7d93 status: experimental description: Detects a ConnectWise or SkyKick service principal adding itself to a directory role, or modifying other applications including adding credentials, as observed in the October 2026 ConnectWise Cloud Backup credential abuse. references: - https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access author: Adverse Trace date: 2026-10-17 logsource: product: azure service: auditlogs detection: selection_events: operationName: - 'Add member to role' - 'Update application' - 'Add service principal credentials' selection_app: initiatedBy|contains: - '506e08f9-6e9a-4da4-942b-a099a03644ae' - '24205314-2b89-4e07-a2a4-579e898a5640' - '2399d300-6fca-4e6a-a686-399fefe75b83' - 'b78f6a77-d4e5-46fb-87e5-d1648bd02519' - '0de14c77-b9b0-4137-9360-34878a929827' - '412dcf96-176d-4b3a-a1b0-4981ad66971e' - 'b2b55f5b-7758-4719-8d8f-88ae172e6bdb' condition: selection_events and selection_app falsepositives: - Legitimate vendor automation performing role assignment or application updates during onboarding or maintenance level: high ``` ```yaml title: Service Principal Sign-In for ConnectWise Cloud Backup from Non-Microsoft IP id: 2b7d9e01-4c6a-4f88-a3d5-9e0b1c2f4a67 status: experimental description: Detects service principal sign-ins for the ConnectWise Cloud Backup application from an IP outside Microsoft and Azure ranges. Normal egress for this application is Azure private IPv6. references: - https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access author: Adverse Trace date: 2026-10-17 logsource: product: azure service: signinlogs detection: selection: appId: '506e08f9-6e9a-4da4-942b-a099a03644ae' signInType: 'servicePrincipal' filter_known: ipAddress|cidr: - '144.172.64.0/24' condition: selection falsepositives: - Any legitimate change to the vendor's egress infrastructure level: high ``` The second rule's filter\_known block is included so an analyst can pivot on the known infrastructure; remove it to alert on all non-Microsoft source addresses for this application. The IP 144.172.64\[.\]128 is in AS14956 (RouterHosting), a hosting provider. ## 7\. Sources - Huntress, "ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks", https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access, published 2026-10-16. - 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, October 2026. - ConnectWise incident acknowledgement on its website, referenced by Huntress; the specific URL was not supplied in the source material. - Todyl reporting on the incident, referenced by Huntress; the specific URL was not supplied in the source material. The technical detail in this advisory is drawn primarily from the Huntress investigation. The Hacker News item corroborates the campaign and the tenant count but adds no independent technical detail in the material available. The ConnectWise acknowledgement and the Todyl report are referenced second-hand and were not reviewed directly. Treat the tenant count, the phase attribution and the vendor-automation reading of the kiota-dotnet User-Agent as single-sourced to Huntress and verify before relying on them for enforcement decisions. ## 8\. Adverse Trace position Adverse Trace assesses this as a high-severity third-party identity compromise with confirmed cross-tenant impact and a persistence mechanism that outlives the initial credential. The initial access is not defensible by the customer: the credential is a client assertion held in ConnectWise's tenant, and the authentication is confirmed in Microsoft's own sign-in logs. The exposure is broad because the application is designed to read and write mail, files, Teams data and directory objects, and directory reads through Microsoft Graph leave no audit trail, so absence of evidence of data access is not evidence of absence. The persistence step, adding client secrets to an MSP management application and to a security tool's application with expiry in 2028, is the part that should drive urgency: rotating the ConnectWise credential does not remove those secrets, and in MSP environments a credential on a management application can reach the MSP's customers. We will track ConnectWise's confirmation that all affected credentials have been reset and will update this advisory when that confirmation is available or when Huntress publishes further affected-tenant counts or additional source IPs. Clients with the application consented should complete the P1 steps before considering re-enablement, and should treat any client secret or certificate added to an application since 2026-10-13 that they did not create as hostile until proven otherwise. --- [Read the original source →](https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*