Ninety seconds at peak tempo. That is roughly how fast the attackers behind the ConnectWise breach were working — Microsoft researchers counted nearly 3,000 attempted sign-ins per minute against customer Microsoft environments, after credentials were stolen from ConnectWise's cloud backup service. Around 2,250 organizations were targeted, and the campaign was driven by AI agents, not tired humans grinding through a list at 2am.
If you run an RMM — ScreenConnect, NinjaOne, Datto RMM, N-able, anything with a deployed agent and centralized credentials — this story is about your tooling, even if you never touched ConnectWise. Your RMM is the most privileged piece of software in every environment you manage. It executes scripts on hundreds of endpoints, opens remote sessions, pushes software, and holds the keys to entire tenants. The ConnectWise breach is what happens when that concentration of power meets vendor-side credential theft and machine-speed automation.
And here is the uncomfortable operational truth: most IT teams still respond at human speed, across four disconnected consoles, with audit logs that don't line up. When attackers iterate in milliseconds and your incident answers take a day, the math stops working.
What Actually Happened — and Why It Lands on Your Desk
The short version: state-aligned Chinese threat actors obtained credentials tied to ConnectWise's cloud infrastructure, specifically its backup service, and used them to reach customer Microsoft environments. Nobody brute-forced 2,250 endpoints one at a time — one vendor-side credential set, thousands of downstream tenants. Microsoft documented the pace: close to 3,000 sign-in attempts per minute, a tempo only sustained automation can produce.
If you work in the ConnectWise ecosystem, none of this arrives out of nowhere. ScreenConnect admins already spent a February 2024 weekend emergency-patching the authentication bypass (CVE-2024-1709) before it was mass-exploited within 48 hours of disclosure. The lesson hasn't changed since — only the tempo has. Centralized remote management is efficient precisely because it concentrates access. That same concentration is why a single vendor-side event becomes a multi-thousand-organization event.
For an internal IT team, the parallel is your own privileged tooling: the deployment console, the RMM agent on every workstation, that management service account nobody has audited since 2021. For an MSP, it's worse — your RMM vendor is effectively a shared root account across your entire client base.
The Problem in Depth: Your Tools Can't Answer the Questions an Incident Asks
When an event like this hits, the questions come fast and specific:
- Which of our endpoints had active remote sessions in the last 72 hours?
- What scripts ran against client environments, from which console, by whom?
- Which clients are on the affected vendor version, and which have queued actions?
- What did WE change, and when, so we can separate our activity from attacker activity?
Now try answering those with a typical stack: RMM (ConnectWise, NinjaOne, Datto), standalone monitor (PRTG, SolarWinds, Zabbix), helpdesk (Freshservice, Jira SM), and patch reporting from a fourth tool. Four exports, three timestamp formats, manual reconciliation in Excel. A question that should take five minutes takes half a day — during an active incident, when you have neither the time nor the patience.
This is where existing tooling systematically fails:
The RMM isn't monitored by anything you own. Your RMM watches your servers — but who watches the RMM? For most teams, the answer is vendor status pages and email blasts. You learn about vendor-side trouble when the vendor posts about it, which is to say: last.
Audit trails are a feature of each product, not the platform. Session history lives in the RMM, alert history in the monitor, ticket history in the helpdesk, patch state in a fourth system. Nothing shares a timeline, so incident forensics becomes archaeology.
Every action crosses a tool boundary. Alert fires in the monitor → tech opens the RMM tab → searches for the device → runs the fix → copies output into a ticket in the helpdesk. Ten minutes of overhead per device, none of it fixing anything. Multiply by 100 endpoints in a fleet-wide event and you have spent 16 hours on tab-switching alone.
MSPs get multi-tenant blast radius with single-tenant answers. A vendor security notice lands Friday at 4:45pm. Which of your 40 clients are exposed? Which scripts ran in the last 72 hours? If the honest answer is 'I will know Monday,' your SLA reporting is already fiction.
The business impact is familiar to anyone running operations: inflated MTTR where 20 of the 45 minutes is pure tool-switching; duplicate tickets because the helpdesk never learned the monitor already remediated the issue; SLA misses nobody can cleanly explain because the data lives in separate systems; and the burnout that comes not from alerts themselves but from the friction around them. Techs don't quit because they got paged. They quit because they got paged at 2am about a disk that started filling at 1:40am, and they couldn't push the cleanup script until someone got to the right console.
How AlertMonitor Changes the Outcome
AlertMonitor was built on the opposite premise: infrastructure monitoring, RMM, helpdesk, network topology, and patch management are not five products — they are one workflow.
Concretely, against the failure modes above:
Remote management inside the monitoring console. An alert fires on a device; the tech clicks through to a remote session on that same device, from the same screen. No second agent to deploy, no separate client to launch, no credential juggling, no 'which console has access to that client again?'
Scripts run across device groups, and results feed back into the monitoring timeline. Push a remediation script to 200 endpoints and every device's output lands in the same timeline as the alerts that triggered the run. Automated remediations and manual technician actions are visible in one history. 'What ran, where, when, with what output' is a filter — not a forensic project.
The helpdesk reads the same data. The monitoring alert that started an incident is the same record the ticket references. When monitoring auto-remediates, the ticket reflects it. SLA reporting comes out of one dataset, so the report your CIO gets actually matches what happened.
Patching sits next to monitoring health. Compliance state per endpoint is visible alongside its alert history; push patches, spot the endpoints stuck on pending reboot, and script the stragglers without leaving the platform.
A real multi-tenant NOC for MSPs. Per-client scoping and device groups that map to client environments mean a fleet-wide question — 'all endpoints in clients A, B, and C running version X' — is one selection, not 40 console sessions.
The honest caveat: no platform makes a vendor-side breach impossible. If a vendor's cloud is compromised, containment is theirs; your exposure and your response speed are yours. What you control is surface area and reaction time. One unified platform with one agent surface and one audit timeline means fewer privileged vendor connections to track — and when something breaks, the questions above get answered in minutes, because the data was never scattered in the first place.
Practical Steps You Can Take Today
1. Verify your fleet is actually remotely manageable. Machine-speed response is fiction if half your servers don't answer WinRM. Run this against your server list:
$servers = Get-Content .\servers.txt
$results = foreach ($s in $servers) {
try {
$null = Test-WSMan -ComputerName $s -ErrorAction Stop
[PSCustomObject]@{ Server = $s; WinRM = 'Reachable' }
}
catch {
[PSCustomObject]@{ Server = $s; WinRM = 'No response' }
}
}
$results | Format-Table -AutoSize
Every 'No response' is an endpoint someone would have to touch manually during an incident. In AlertMonitor, save this as a script, run it against your Windows Servers group, and the per-device results land in the monitoring timeline — a living record instead of a stale spreadsheet.
2. Get a real disk picture before it pages you at 2am.
Invoke-Command -ComputerName (Get-Content .\servers.txt) -ScriptBlock {
Get-CimInstance Win32_LogicalDisk -Filter 'DriveType=3' |
Select-Object PSComputerName, DeviceID,
@{n='SizeGB'; e={[math]::Round($_.Size/1GB,1)}},
@{n='FreeGB'; e={[math]::Round($_.FreeSpace/1GB,1)}},
@{n='FreePct'; e={[math]::Round($_.FreeSpace/$_.Size*100,1)}}
} | Sort-Object FreePct | Format-Table -AutoSize
Run it on demand during an incident, or schedule it weekly in AlertMonitor with alert thresholds on FreePct, so you find out at 30% free instead of at 0%.
3. Run a patch-compliance reality check. This surfaces the endpoints whose last update is months old — exactly the machines attackers count on:
Invoke-Command -ComputerName (Get-Content .\servers.txt) -ScriptBlock {
$last = Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1
$age = if ($last.InstalledOn) { [int]((Get-Date) - $last.InstalledOn).Days } else { 9999 }
[PSCustomObject]@{
Server = $env:COMPUTERNAME
LastPatch = if ($last) { $last.HotFixID } else { 'None found' }
InstalledOn = if ($last.InstalledOn) { $last.InstalledOn } else { 'Never' }
AgeDays = $age
}
} | Sort-Object AgeDays -Descending | Format-Table -AutoSize
Then find the machines perpetually stuck on a pending reboot — the silent patch treadmill:
Invoke-Command -ComputerName (Get-Content .\servers.txt) -ScriptBlock {
$cs = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
$wu = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
[PSCustomObject]@{
Server = $env:COMPUTERNAME
PendingReboot = (Test-Path $cs) -or (Test-Path $wu)
}
} | Sort-Object PendingReboot -Descending | Format-Table -AutoSize
In AlertMonitor, these become scheduled group scripts, with compliance drift visible in the same place as the alerts and tickets they generate.
4. Standardize your remediation pattern. Wrap fixes so they are idempotent and produce output worth keeping:
$svc = Get-Service -Name 'wuauserv'
if ($svc.Status -ne 'Running') {
Start-Service -Name 'wuauserv' -ErrorAction Continue
'wuauserv started on {0} at {1}' -f $env:COMPUTERNAME, (Get-Date -Format 'yyyy-MM-dd HH:mm:ss')
} else {
'wuauserv already running on {0}' -f $env:COMPUTERNAME
}
Push that through AlertMonitor to a device group and the output is in the timeline — attached to the alert, attached to the ticket, reviewable a month later without asking anyone what happened.
5. Rehearse the incident question. Ask yourself right now: show me every remote session and every script executed against your most critical client or server in the last 72 hours. Time the answer. If it's under five minutes and needs no exports, your tooling is ready for a ConnectWise-style event. If it involves three consoles, a CSV, and a strong drink — that gap, not the threat actor, is the thing to fix this quarter.
Machine-speed attacks are here, and they don't outmuscle good IT teams — they outrun slow workflows. The teams that come through vendor-side incidents like this one are the ones where detection, remote action, and documentation live in one place and one timeline. That is the entire thesis behind AlertMonitor: detect fast, act fast, and have the record prove it.
Related Resources
AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.