Attackers Used AI to Hit ConnectWise Cloud Backup — What It Means for Your RMM Stack

Microsoft reported that a China state-aligned hacking group used AI agents to accelerate its operations — including a supply chain compromise involving ConnectWise Cloud Backup. If you run an RMM, that sentence should land hard. Not because ConnectWise is uniquely broken, but because the target wasn't a customer's firewall or an unpatched web server. It was the management layer — the tooling that exists to give administrators remote control over fleets of endpoints.

Every RMM works the same way at the low level, whether it's ConnectWise Automate, NinjaOne, Datto RMM, or Kaseya VSA: a persistent agent runs as SYSTEM on every endpoint, beacons out, and executes whatever the console sends — scripts, binaries, commands. That's the job. It's also, precisely, the capability every attacker wants. A supply chain compromise means they don't have to fight for it. They inherit it.

And the AI detail matters for one unglamorous reason: speed. Reconnaissance that used to take days now takes hours. Meanwhile, most IT teams' own response timelines are already too slow — not because technicians are slow, but because their tooling is fragmented. Monitoring in one console. RMM in another. Helpdesk in a third. Patch reports in a fourth. When something happens — an incident, an audit, a client asking what ran on their server last night — reconstructing the answer means pivoting between consoles and aligning timestamps by hand. Attackers just compressed their timelines with AI. Most IT teams haven't compressed theirs at all.

The Problem in Depth

Your RMM is the master key — and probably your biggest blind spot

RMM agents are, by design, the most privileged software on any endpoint:

• They run as SYSTEM, above every user and most services
• They hold a persistent outbound channel
• They execute arbitrary scripts and push software on demand, across entire device groups
• They increasingly integrate with backup and cloud storage — exactly the component class hit here

When that trust chain is compromised upstream, at the vendor, every downstream endpoint becomes an execution point overnight. You patched everything. You configured MFA correctly. It doesn't matter — the compromise arrives through the channel you trusted most.

Now the uncomfortable question: if something executed through your remote management channel at 2 a.m., how long until you would know — and how long to answer "what exactly ran, on which machines, with what output?" If your RMM script logs live in one database, your monitoring metrics in another, and your ticket history in a third, the honest answer is hours or days, assembled by a technician from memory and spreadsheets.

What fragmented stacks get wrong

The typical mid-size IT shop or MSP runs PRTG or Zabbix for monitoring, ConnectWise Automate or NinjaOne for RMM, ConnectWise Manage or Freshservice for tickets, and WSUS or PDQ for patching. Each tool is individually decent. Together, they are a correlation problem:

• Script results stay in the RMM. The ticket says "restarted service." Monitoring shows a CPU dip. Nothing ties them together except a technician's memory.
• Device identities don't match across tools — hostname vs. agent ID vs. asset tag — so even CSV exports don't align cleanly.
• Every extra agent is another SYSTEM-level, outbound-capable service on every endpoint, expanding exactly the third-party surface this attack class exploits.
• Auditors and clients ask for a timeline; you hand them three exports and an apology.

These gaps exist for structural reasons: monitoring products were built for device polling, RMMs for ticket-driven remote work, helpdesks for ITSM process. The "integrations" between them sync tickets and asset records, but never context — script output, alert data, and actions land in separate databases with different clocks and device names.

A scenario every MSP tech recognizes

9:04 a.m. A ticket lands: the client's file server is "acting weird since last night." To reconstruct what happened, the tech opens:

1. The monitoring console — resource graphs show a disk I/O spike around 1 a.m.
2. The RMM console — script history shows something ran Tuesday, a patch job Wednesday.
3. The helpdesk — a colleague touched that server Wednesday afternoon.
4. The patch report — updates installed Wednesday, reboot required.

Four logins, four exports, 40 minutes of timestamp alignment in a spreadsheet — during an active incident, with the client escalating in the ticket thread. That's one server, one night, one technician. Now multiply across 50 clients and compare it to an adversary whose reconnaissance is AI-accelerated.

The business impact

• MTTR measured in hours, driven mostly by context-switching rather than diagnosis
• Follow-up tickets ("is it fixed yet?") piling onto the same overloaded techs
• SLA reports nobody trusts, because monitoring and helpdesk data live in separate systems
• Burnout: the tech with 12 tabs across 5 tools is the tech updating their LinkedIn

How AlertMonitor Solves This

AlertMonitor collapses the stack: infrastructure monitoring, RMM, helpdesk, patching, and network topology in one platform, on one agent, with one timeline.

One console for the entire remote workflow

Technicians remotely view and manage endpoints, run scripts across device groups, push software, and open remote sessions — without leaving the platform where the alert fired. No tab-switching between a monitoring console and a separate RMM tool. The device page puts live metrics, recent alerts, script history, patch state, and the ticket trail side by side.

Script results feed back into monitoring data

This is the difference that matters after an incident like this one. When a script runs — automated remediation or a manual technician action — the result lands in the same timeline as the alerts and metrics. Click any endpoint and see: alert at 02:14, disk-check script executed at 02:16 with full output logged, service restarted, alert cleared at 02:19, ticket auto-linked. When a client, auditor, or incident responder asks "what ran on this machine and when," the answer is a filter, not a forensic project.

The workflow, before and after

Fragmented stack: alert email → log into the RMM → search for the device → run the script → switch to the helpdesk → find or create the ticket → paste the output → switch to monitoring → verify the metric recovered. Fifteen to twenty-five minutes of tool-hopping per incident, per technician, with every hop a chance to lose context.

AlertMonitor: alert fires → device context is already in front of you → script pushed to the device or its whole device group → results stream back into the same timeline → ticket updated automatically → verification visible in the same view. Minutes, not a morning.

For MSPs: fleet control with a smaller third-party footprint

Cross-client device groups, bulk script execution, software push, and remote sessions from a single NOC dashboard. Consolidating the management plane also means fewer independent SYSTEM-level agents per endpoint — directly shrinking the third-party surface that supply chain attacks like this one abuse.

Speed is now a defensive control

The attackers used AI to compress their timeline. You don't counter that with another agent — you counter it by collapsing your own. When alert-to-resolution drops from an hour to minutes because monitoring, RMM, helpdesk, and patching finally share one timeline, you move faster than an accelerated adversary can work through the gaps.

Practical Steps You Can Take Today

1. Inventory every remote-capable agent on your endpoints. You can't secure keys you haven't counted. Run this across your device groups:

$patterns = 'screenconnect','automate','ninja','datto','kaseya','anydesk','teamviewer','vnc','rustdesk','splashtop','logmein'
Get-Service |
    Where-Object {
        $display = $_.DisplayName.ToLower()
        ($patterns | Where-Object { $display -like "*$_*" }).Count -gt 0
    } |
    Select-Object Status, Name, DisplayName |
    Sort-Object DisplayName

In AlertMonitor, schedule this as a weekly script across all managed devices. Anything unexpected in the output becomes a review item on the same timeline your team already watches.

2. Verify the health of critical agents — especially backup services. The compromised component in this incident was cloud backup, and dead backup agents are a classic silent failure:

$servers = Get-Content -Path .\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-Service |
        Where-Object { $_.DisplayName -match 'backup|cloud|sync' } |
        Select-Object @{n='Computer';e={$env:COMPUTERNAME}},
                      Name, DisplayName, Status, StartType
} | Sort-Object Computer | Format-Table -AutoSize

Push this from AlertMonitor to a device group. Any Stopped service shows up in the script output on the device timeline, and you can configure the run to raise an alert on failure.

3. Run the disk sweep before it pages you at 2 a.m.:

Get-CimInstance -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
    Select-Object DeviceID,
        @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
        @{n='TotalGB';e={[math]::Round($_.Size/1GB,1)}},
        @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
    Where-Object FreePct -lt 15

4. Check pending updates and let the result drive patching in the same platform:

$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$pending = $searcher.Search("IsInstalled=0 and Type='Software'")
[PSCustomObject]@{
    Computer     = $env:COMPUTERNAME
    PendingCount = $pending.Updates.Count
    TopUpdates   = ($pending.Updates | Select-Object -First 5 -ExpandProperty Title) -join ' | '
}

Run it fleet-wide from AlertMonitor. Machines reporting pending updates land on the patch queue, and the patch job plus its outcome appear on the same device timeline as the script that found the gap.

5. Close the loop in AlertMonitor. Create a device group for all endpoints running remote or backup agents, schedule the inventory and health scripts weekly, attach a remediation script to your disk-space alert so cleanup runs and logs itself, and let monitoring alerts open linked helpdesk tickets automatically — no copy-paste between systems.

The ConnectWise Cloud Backup attack is a supply chain story, but the operational lesson is local: the teams that come out ahead are the ones who can see every agent, script, patch, and action on one timeline — and act on it in minutes.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources