Excerpt: Ransomware victims with no alert history and no ticket trail hire strangers to "fix it." AlertMonitor links alerts to tickets so IT responds with data, not desperation.
When the Phones Ring and Nobody Knows Anything
Federal prosecutors recently charged a man who ran a business as a ransomware "fixer" — the number desperate victims call when every file on the share ends in a stranger's extension and a countdown timer is ticking. According to the allegations, the model was elegant: charge clients a "recovery fee" bigger than the actual ransom demand, quietly pay the attackers yourself, hand over the decryptor, and pocket the difference. Clients thought they were paying a specialist. They were paying a middleman with a six-figure markup and zero accountability.
Every practitioner reading this has the same first reaction: who hires that guy? And then, if you're honest, the second reaction: I know exactly how an organization gets to that phone call.
Not because the leadership is stupid. Because at the moment of impact, they discover they have no idea what happened. No alert history. No timeline. No ticket trail. No verified backup they can point to. Just locked files, a panicking CFO, and a search engine. At that moment it isn't primarily a security failure — it's a visibility and process failure. It's what happens when monitoring lives in one console, the helpdesk lives in another, and neither one captured what happened before, during, or after.
This post is about the gap that turns a ransomware incident into a double loss — once to the attacker, once to the guy with the markup — and how an integrated helpdesk like AlertMonitor's closes it.
The Problem in Depth: Your Tools Know Nothing, Individually and Together
The first notification is a user, not a system. In most environments, ransomware is discovered by an end user calling the help desk — "I can't open the shared drive" — or worse, by an executive seeing the ransom note on a server console over RDP. By then, dwell time is measured in days or weeks. In teams without integrated monitoring, the ticket gets created manually at that point, and the response clock starts hours after the attack did. Whatever documentation exists begins at the moment of maximum panic.
The ticket has no context. Standalone helpdesks — a shared Outlook inbox, a generic ITSM tool, a ticket spun up from a phone call — know nothing about the machine in question. No health history. No recent alerts. No record that the backup job on that very server had been failing quietly for nine days (classic: monitoring saw it, nobody was watching the console, no ticket was ever created). The technician starts from zero at the worst possible moment of their career.
The tools don't talk, so there is no system of record. This is the structural failure:
- The RMM (NinjaOne, ConnectWise, Datto RMM — pick yours) has device data but no ticket.
- The helpdesk (Freshservice, a PSA, Zendesk) has the user's complaint but no device data.
- The monitoring tool has been firing alerts into a console — failed backups, stopped services, disk churn — that nobody correlates to anything, because alerts and tickets live in different databases with different IDs and different clocks.
- Patching state lives in a fourth place, so nobody can answer the post-incident question "were these systems even current?" without a week of spreadsheet archaeology.
When the incident review happens — or the cyber insurer, or the feds — nobody can state when the first alert fired, what it said, and who did what. Accountability dies in the gap between systems.
Then panic fills the vacuum. Leadership wants answers in 30 minutes. The team can't produce a timeline because no system recorded one. Enter the fixer: confident, expensive, "done this hundreds of times." When your own house has no documentation, the outsider who sounds certain wins the room. He'll charge more than the ransom, and you'll never know.
MSPs get the multiplier. When one client gets hit, every client's users call at once. A helpdesk without device and client context can't prioritize by real impact — only by who shouts loudest. Everything becomes P1, nothing is P1, and your SLA report for the quarter is fiction assembled from exports.
Numbers you'll recognize: mid-size teams drown in thousands of alerts a week with the critical ones lost in the noise. SMB downtime costs commonly run five figures per hour. A 200-person org can generate 100+ "is my stuff back?" tickets in the first 24 hours after an incident, with no way to track which systems are confirmed restored versus assumed restored. Now add a fixer's invoice on top.
How AlertMonitor Changes the Outcome
AlertMonitor's architecture answers the question this case exposes: when something goes wrong, does anyone actually know what happened, when, and what was done about it?
Alerts become tickets automatically. When a monitored alert fires — backup job failed, critical service stopped, disk crossed a threshold, endpoint offline — AlertMonitor creates a ticket, pre-assigned based on device, client, and alert type, before an end user calls. The backup that had been failing for nine days? That's nine daily tickets, not a surprise.
Every ticket carries full context. Technicians open a ticket and see the device's complete alert history, current health data, and one-click remote access into the box. No tab-hopping across five consoles, no reconstructing state from memory mid-incident.
There's a real timeline. Every alert and every action is timestamped in one database. First alert 02:14, ticket created 02:14:30, acknowledged 02:19, escalated 02:41, containment started 02:53. That's the document the incident review, the insurer, and the board need — produced as a side effect of working, not assembled afterward from memory.
End users stop being your monitoring system. User-reported tickets merge with alert-generated tickets for the same affected systems. Techs close "is it fixed yet?" in bulk through the ticket instead of fielding 40 phone calls, and the communication record lives where it belongs.
IT managers get real SLA data. Because alerts and tickets share one database: median alert-to-acknowledgment, alert-to-resolution, SLA breaches by client and device, response hours per incident. Actual reports — not spreadsheets stitched from five exports.
For MSPs: client and device context on every ticket means triage by actual blast radius when the phones light up, plus per-client SLA policies that hold up in a QBR.
The loop closes with RMM and patching. Post-incident work — verifying agent health, pushing missing patches, confirming configurations — runs from the same platform, tracked by tickets to completion. One system of record, start to finish.
Old way: user calls → manual ticket → tech RDPs blind → alerts pasted from another console into chat → timeline reconstructed after the fact. AlertMonitor way: alert fires → ticket exists with routing and context → tech works the ticket → timeline and SLA data exist automatically. During an incident, that difference is the difference between responding and guessing.
Practical Steps You Can Take Today
1. Stop trusting backups you haven't verified. The fixer only gets a phone call when restore tests never happened. Check the backup log on any Windows Server box right now:
# Last 10 Windows Server Backup events — Event ID 4 means a job completed successfully
Get-WinEvent -LogName "Microsoft-Windows-Backup" -MaxEvents 10 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message |
Format-Table -Wrap
If the most recent ID isn't 4 — or the log is empty — congratulations, you just found your first real ticket of the week.
2. Know your disk headroom fleet-wide. Full disks break backup jobs, broken backups create desperation, and desperation hires fixers:
# Disk free space across all servers — anything under 15% free needs a ticket today
$servers = Get-Content "C:\IT\prod-servers.txt"
$report = foreach ($s in $servers) {
Get-CimInstance -ComputerName $s -ClassName Win32_LogicalDisk `
-Filter "DriveType=3" -ErrorAction SilentlyContinue |
Select-Object @{N='Server';E={$s}},
@{N='Drive';E={$_.DeviceID}},
@{N='FreeGB';E={[math]::Round($_.FreeSpace/1GB,1)}},
@{N='PctFree';E={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}}
}
$report | Where-Object { $_.PctFree -lt 15 } | Sort-Object PctFree | Format-Table
3. Keep a one-command "are we functional" check. Service status across the fleet doubles as incident documentation:
# Verify critical services across servers — output pastes straight into an incident ticket
$servers = Get-Content "C:\IT\prod-servers.txt"
$critical = "Netlogon","DFSR","wuauserv"
Invoke-Command -ComputerName $servers -ScriptBlock {
Get-Service -Name $using:critical -ErrorAction SilentlyContinue |
Select-Object Name, Status, StartType
} | Select-Object PSComputerName, Name, Status, StartType |
Sort-Object PSComputerName, Name | Format-Table
4. Same discipline on Linux:
# Flag any filesystem over 80% full and show the most recent local backups
df -h --output=source,pcent,target | awk '$2+0 >= 80 {print "WARNING: "$0}'
ls -lht /var/backups 2>/dev/null | head -5
5. Wire alerts to tickets — permanently. In AlertMonitor:
- Map alert types to queues and priorities: backup failure → backup queue, P1. Disk ≥ 90% → infrastructure, P2. Endpoint offline > 15 minutes → endpoint queue, P3.
- Set per-client SLA policies so acknowledgment and resolution clocks are contractual, not aspirational.
- Merge end-user intake with alert-generated tickets on the same device, so one incident equals one tracked incident.
- Build your "first 30 minutes" runbook as a ticket template so the checklist executes under pressure.
- Schedule the weekly backup-compliance and patch-compliance reports — the two reports that would have kept the fixer's phone from ever ringing.
6. Test a restore this month. Not a backup check. A restore. Put it in a ticket, time it, attach the result. That ticket is worth more than any decryption promise.
The Takeaway
The ransomware fixer case is outrageous, but the vulnerability it exploits isn't exotic — it's the ordinary absence of visibility and documentation in IT teams whose tools don't share a database. Organizations that can answer "what happened, when, and what did we do" from one system don't make desperate phone calls. They run the incident, produce the report, restore from the backup they verified last month, and get back to work.
AlertMonitor puts monitoring, helpdesk, RMM, patching, and alerting in one platform, so every alert is a ticket and every ticket is a record. Your team responds faster because it already knows. Your users get answers because the answer already exists. And nobody — nobody — has to google "ransomware help" at 2 a.m.
Related Resources
AlertMonitor Helpdesk & End-User Support AlertMonitor Platform Overview Book a Demo Helpdesk & End-User Support Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.