ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks

An investigation revealed a sophisticated intrusion campaign leveraging compromised vendor credentials for cloud services, specifically targeting Microsoft 365 tenants via ConnectWise Cloud Backup/SkyKick. The initial vector involved application sign-ins originating from the IP range 144.172.64[.]128 on October 15, allowing attackers to acquire Microsoft Graph access tokens across hundreds of tenants. Once access was gained in two reviewed tenants, the post-compromise activity was noted as rapid and scripted; this involved granting the application Global Administrator rights and planting new client secrets into other applications for persistence.
Subsequent analysis uncovered a second wave of targeted attempts from the same IP range against specific sectors, including policy and national security organizations, involving manual targeting of services like Exchange Online and SharePoint Online. Furthermore, evidence suggests credential abuse may extend beyond publicly visible audit logs, as directory reads via Microsoft Graph leave no record in standard logs. The vendor response emphasized a surgical containment strategy, prioritizing confirmation of unauthorized sign-ins over broad systemic disabling, while urging customers to immediately disable the affected applications and review all associated service principal credentials for unusual changes made since October 13.

Application identity signed into customer Microsoft 365 tenants from IP address 144.172.64[.]128 on October 15.
Between October 10 and October 14, failed user password spray attempts originated from 144.172.64[.]128 and associated provider ranges.
In two reviewed tenants on October 15, the application granted itself Global Administrator rights shortly before planting new secrets in other applications.
The post-compromise activities in the reviewed tenants occurred around 03:45 UTC on October 15, taking place within two minutes of each other.
An attempt was made to add credentials to an application in one tenant and another application in the same tenant using access gained from a ConnectWise app family identity.
On October 16, Huntress identified and removed an unauthorized credential placed on its own security platform application in one customer tenant.
A second targeted wave of activity occurred on October 15 against sixteen Huntress-protected tenants across critical sectors.
Huntress observed almost 1,000 Entra tenants with sign-in activity from 144.172.64[.]128; over 300 of these attempts succeeded.
The initial authenticated access via the ConnectWise app family came from private Azure IPv6 space, differing from the 144.172.64[.]128 IP associated with earlier activity.
ConnectWise communicated on October 17 that relevant apps had been disabled.

The operational model revealed here suggests a tiered attack methodology: initial credential harvesting via broad vendor application access (allowing bulk token acquisition), followed by targeted lateral movement through administrative escalation and persistence planting, as seen in the Global Administrator self-assignment. This echoes classic supply chain exploitation patterns where trust within one ecosystem grants entry into many dependent client environments—a compounding risk amplified in MSP structures. The reliance on app-only permissions, which bypass typical user authentication controls like MFA, transforms established service functionality into a stealthy vector for data exfiltration and persistence setup (T1098.001).
The defensive posture exhibited by researchers—favoring surgical containment over blanket lockdown—demonstrates an understanding of operational fragility; the desire to prevent collateral disruption clashes directly with the imperative for absolute risk elimination in a complex cloud environment. The crucial divergence between what logs record (role changes, application modification) and what they omit (data reads via Graph tokens) highlights a modern governance blind spot: administrative action is visible, but covert data enumeration is functionally invisible without specialized, deep-level auditing.
The implicit assumption underpinning this incident response framework is that the threat actor’s scope was strictly limited to confirmed activity in specific tenants. However, the potential exists for 'quiet' access—reading sensitive directory metadata or content via Graph without triggering audit alerts. This necessitates a proactive stance where perceived containment based on observed log gaps might be premature closure on a persistent risk profile.
Patterns detected: ARC-0041 Supply Chain Vectoring, ARC-0037 Ambiguity (regarding data exfiltration visibility)
What specific compensating controls are needed to monitor for *actions* permitted by the application role versus actual *data flow* utilized? How can an organization verify the integrity of a vendor's underlying credentials when their own platform is used as both the entry point and the ultimate detection mechanism? If access relies entirely on permission scope rather than user identity, what organizational risk threshold must be met before complete service cessation becomes necessary?