Bitget attributed a $387.5M crypto wallet raid to North Korea, and The Register's summary said it plainly: familiar fingerprints, to the surprise of nobody. For the exchange, the aftermath is months of forensics, recovery, and regulator meetings.
But if you run infrastructure for a living — sysadmin, help desk lead, MSP tech with a dozen client environments — the story asks a much more uncomfortable question:
If something ugly landed in your environment right now, how fast could you see and touch every endpoint you manage — from one console?
For most IT teams, the honest answer involves three tools, four CSV exports, and a spreadsheet. That gap is not a security problem first. It's an operations problem, and it's exactly what unified RMM is supposed to solve.
The First Hour After "Are We Exposed?" Is Where Tool Sprawl Kills You
Picture the scenario, because you will live some version of it. News breaks about a compromised application or a malicious update making the rounds. Your manager pings you at 4:40 PM on a Friday: Are we affected? Which machines have it? What's actually running on our endpoints? Show me by five.
Now watch what happens in a typical fragmented stack:
- Your monitoring platform (PRTG, Zabbix, SolarWinds, Nagios) knows your servers are up. It knows CPU, disk, ping. It knows nothing about which software is installed on which machine, and it has never seen the output of a script you ran yesterday.
- Your RMM (ConnectWise Automate, NinjaOne, Datto RMM) has the agents and can run scripts — but its console is a different browser tab, a different login, and a device list that may not match your monitoring group structure.
- Your helpdesk (ConnectWise Manage, Zendesk, Jira Service Management) has the ticket, zero endpoint telemetry, and a technician copy-pasting findings into the notes field by hand.
- Your patch console is a fourth tab, with a fourth device inventory, and a compliance report you'll export as CSV and hope is current.
So the first hour looks like this: export the software inventory from the RMM, export the server list from monitoring, VLOOKUP them together in Excel, manually run a PowerShell one-liner on a handful of "important" machines because nobody fully trusts the inventory anyway, then paste findings into the ticket. Two to three hours later, you have a partial answer to a question a unified platform answers in eight minutes.
Multiply that manual correlation tax across 30 incidents a week, and it stops being minutes. It's the difference between an SLA report you produce with confidence and one you reconstruct from memory. It's the difference between a technician who goes home at six and one who's still stitching spreadsheets at nine.
Why These Gaps Exist (and Why They're So Hard to Fix After the Fact)
These silos aren't incompetence — they're architecture. Monitoring platforms were built around devices-as-metrics. RMM platforms were built around devices-as-manageable-agents. Helpdesks were built around tickets-as-records. Each product stores its own device identity, its own history, its own definition of healthy, and almost none of them share a common device ID that survives across systems.
The result is structural, not cosmetic:
- No shared timeline. When an RMM script ran at 2:14 AM and monitoring saw the service recover at 2:16 AM, those are two disconnected records in two databases. Nobody can prove which action fixed what.
- Alerts without reach. Your monitoring tool pages you at 2 AM but can't open a remote session or push a fix. Your RMM can push a fix but never noticed the problem in the first place. So the human becomes the integration layer — at 2 AM.
- Inventory drift. Three tools, three device lists, three definitions of "this machine is fine." The list that's wrong is always the one you checked first.
- Manual correlation tax. Every incident pays a hidden toll: minutes lost tab-switching, minutes lost re-identifying the same device in a different console, minutes lost writing up what happened so the ticket record makes sense.
That 2 AM disk-full page is the perfect example. Monitoring caught the disk filling up — but the cleanup script, its output, and the remote session that fixed it all live somewhere else. Come audit time or post-incident review, the story has to be reassembled by hand.
What Unified RMM Actually Changes
This is the problem AlertMonitor was built around. Infrastructure monitoring, RMM, helpdesk, network topology, and patch management share one agent, one device identity, and one timeline. Concretely, for endpoint-focused teams:
- Remote view and manage any endpoint — servers, workstations, firewalls, switches, printers — from the same console where the alerts fire. No second tool, no second login, no second device list to reconcile.
- Run scripts across device groups — pick a group, pick a script, execute, and watch results stream back per device.
- Push software and patches from the same place you just saw the alert.
- Open a remote session directly from the alert or the ticket — no hunting through a separate RMM console to find the machine.
The detail that changes everything: script results feed back into the monitoring data. Automated remediations and manual technician actions both land on the same device timeline. Six months later, you can answer not just "what happened to SERVER-FIN-03" but "what did we do about it, when, and did it work" — in one view, without exporting anything.
The old way: monitoring alert → switch to RMM → hunt for the device → run script → switch to helpdesk → find the ticket → paste results → wait for the next alert to confirm the fix. Twelve tabs, five tools, 30–40 minutes if you're good.
The AlertMonitor way: alert fires → device page shows the script you need → one click to run it across the group → results appear on the same timeline as the alert → the ticket stays in sync automatically → the fix is verified against the same monitoring data that caught the problem. Minutes, not tens of minutes.
That's the alert-to-resolution workflow compressed into a single product — which is precisely the gap that turns a bad Friday afternoon into a manageable one.
Practical Steps: Build Your Endpoint Readiness Kit Today
You don't need an incident to justify this work. Take these scripts, save them as reusable jobs in AlertMonitor, and schedule them against your device groups. When the bad day comes, the answers already exist.
1. Baseline services that should be running but aren't. Run this on your Windows group nightly; anything it returns is either an incident or a documentation gap.
Get-Service |
Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' } |
Select-Object Name, DisplayName, Status
2. Audit patch compliance without opening a fourth console. This returns a per-machine count of pending Windows updates — ideal as a scheduled script whose results land on each device's timeline and feed your compliance reporting.
$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$pending = $searcher.Search("IsInstalled=0 and Type='Software'")
[PSCustomObject]@{
Computer = $env:COMPUTERNAME
PendingUpdates = $pending.Updates.Count
}
$pending.Updates | ForEach-Object { " - $($_.Title)" }
When you need to force a detection cycle across a group before pushing patches:
(New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()
3. Sweep disk usage across your servers so the 2 AM capacity page never happens again:
Get-CimInstance 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)}}
4. Do the same pass on your Linux fleet — running services and disk in one shot:
systemctl list-units --type=service --state=running --no-pager
df -h -x tmpfs -x devtmpfs
5. Inventory non-Microsoft scheduled tasks on your workstations. Whatever prompts you to need this list, you want it to be a saved script you run in one click — not a scramble.
Get-ScheduledTask |
Where-Object { $_.TaskPath -notlike '\Microsoft*' } |
Select-Object TaskName, TaskPath, State
In AlertMonitor, each of these becomes a scheduled job against a device group, with results visible per endpoint, alertable on drift, and attachable to a ticket in the same console. That last part matters more than it sounds: the answer to "which machines are affected" stops being a spreadsheet and becomes a live, filterable view you can hand to your manager while the question is still being asked.
The Metric That Matters: Time From Question to Answer
The Bitget raid will be studied in security courses for years. Your takeaway is more immediate — and more fixable. Run this tabletop this week: it's 4:47 PM Friday, and news breaks about a compromised application. How long until you can list every affected endpoint, show what's on them, push a fix, and prove it worked?
If your answer involves CSV exports, three consoles, and a quiet hope that the inventories line up, that's not a staffing problem or a skills problem. It's an architecture problem — and it's the one problem unified RMM was invented to eliminate. One agent, one console, one timeline: the alert, the action, and the proof, living together.
The attackers will keep being unsurprising. Your tooling doesn't have to be.
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.