Warlock Disabled Security on 40 Hosts in Two Hours. Your Monitoring Tool Would've Said Nothing.

Warlock ransomware operators didn't need weeks inside their victim's network. In one recent intrusion targeting an on-premises SharePoint deployment, they disabled security software on at least 40 hosts in roughly two hours, then deployed ransomware to at least 33 of them. The victims — water utilities, telecom providers, government bodies, schools — look a lot like the estates most IT departments and MSPs support every day.

Now look at that timeline from the defender's side. Two hours. Forty hosts. That is a fleet-wide operation executed faster than most IT teams can answer a much simpler question: "Which of our servers even run SharePoint, and are they patched?"

If answering that question would take you a day — or three — this article is for you. Not because you need another lecture on zero-days, but because the tooling gap that makes a two-hour attack possible is the same gap behind your slow 2am response times, your stale patch reports, and your SLA dashboards that nobody trusts.

What Happened, in Ops Terms

Forget the malware names for a moment. Strip the intrusion down to what actually happened operationally:

1. Attackers got in through known on-premises SharePoint vulnerabilities.
2. Using credentials and scripting, they moved laterally and disabled security tooling across 40+ hosts in about two hours.
3. They deployed ransomware to at least 33 systems.

Here's the part that should keep you up at night: during those two hours, if the victim's estate was monitored the way most estates are monitored, every dashboard was green. Hosts were up. Ping was fine. CPU and memory looked normal. Nothing in an up/down monitoring world flags "the same service quietly stopped on 40 machines in sequence," because that's a fleet-level pattern and most monitoring tools don't think at fleet level.

That's not a security product failure. It's a visibility architecture failure — and it's the same failure that makes your daily work harder than it should be.

The Problem: Everyone Watches Hosts. Nobody Watches the Fleet.

Look at the typical stack in a mid-size IT shop, or in any given MSP client environment:

• Uptime/infrastructure monitoring — PRTG, Zabbix, Nagios, or SolarWinds. Answers one question: is the host reachable and within resource thresholds.
• Endpoint security console — a separate product, separate login, separate alerting silo.
• Patching — a WSUS box half the servers quietly stopped reporting to, or SCCM if you're lucky.
• RMM — maybe ConnectWise or NinjaOne, if the budget survived the year.
• Helpdesk — Jira Service Management, Freshservice, or a shared inbox pretending to be one.

Five tools. Five databases. Zero joins. The most valuable question in IT — "what is the exact state of my entire fleet, right now?" — cannot be answered in real time, because the answer is scattered across five exports and a CMDB spreadsheet last touched before the last audit.

Run the numbers on that two-hour window. Disabling security tooling on 40 hosts in 120 minutes means roughly one host every three minutes. Now compare that to your fleet-wide visibility cadence: a patch compliance report that runs weekly, an AV console you check when something feels off, an inventory nobody has verified in months. The attackers were operating at a tempo orders of magnitude faster than the defenders' tooling could even form the question.

And the blast radius this creates isn't hypothetical:

• Downtime measured in weeks. Ransomware across 33 servers means restore-from-backup, forensic cleanup, and rebuilds — not a Tuesday reboot.
• Helpdesk meltdown. Every affected user becomes a ticket. Your queue goes from 40 open tickets to 900 overnight, and the month's SLA numbers are dead on arrival.
• Morale damage. Your best techs spend two weeks doing forensic archaeology across five tools' logs, reconstructing a timeline that should have been one query.
• For MSPs: the client's trust, the contract, and potentially the liability conversation. "We didn't have visibility" is not a sentence anyone wants to say out loud.

Why do these gaps exist? Not because anyone is lazy. Point solutions were bought at different times by different managers. MSP stacks got assembled through acquisitions. Each tool technically has an API, but nobody has six months of integration engineering budget to glue them together. So the fleet-level question stays unanswerable — until the day it gets answered for you, painfully.

How AlertMonitor Changes the Equation

AlertMonitor was built on a simple bet: infrastructure monitoring, RMM, patch management, helpdesk, and network topology belong in one platform, on one agent, with one timeline. Against an intrusion pattern like Warlock's — and against your ordinary Tuesday — that bet pays off in very concrete ways:

1. Device groups turn fleet questions into one-click answers. Tag your SharePoint servers once. From then on, every script run, patch report, service check, and alert can be scoped to that group. "Which hosts run SharePoint and what version?" stops being a two-day research project and becomes a two-minute script run.

2. Script execution across device groups — with results in the timeline. From the same console you monitor in, you push a PowerShell script to 200 Windows servers, results stream back live, and every execution is logged next to the alerts and tickets for those hosts. No RDP roulette. No CSV stitching. And because script output feeds back into monitoring data, automated remediations and manual technician actions both live in one audit-ready record.

3. Service-state monitoring, not just host-state monitoring. AlertMonitor watches whether critical services — SharePoint Timer Service, IIS, SQL Agent, your endpoint security services — are actually running, and alerts the moment one stops. A host can be up while the thing that matters on it is dead; fleet-wide service state is exactly the class of signal that up/down monitoring misses.

4. Patch management in the same database as everything else. When the next SharePoint vulnerability hits the news, compliance status is a filtered report against a device group — not a WSUS export cross-referenced by hand at midnight.

5. Automated remediation with a paper trail. A service stops, AlertMonitor triggers a remediation script, the service restarts, and the action lands in the same timeline the ticket lives in. Your post-incident report writes itself from real data instead of reconstructed memory.

Old workflow vs. AlertMonitor workflow:

What You Can Do Today

You don't need Warlock at your door to justify fleet-wide visibility. These are the checks worth standardizing this week — all of them run as scripts against a device group in AlertMonitor, all of them returning structured results straight into your timeline.

1. Answer "where is SharePoint?" in one pass

Run this against your All Windows Servers device group. You'll have a definitive SharePoint inventory before your coffee is ready:

# Run against your "All Windows Servers" device group in AlertMonitor
# Reports whether SharePoint is installed on each host
$product = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -like "*SharePoint*" } |
    Select-Object -First 1

if ($product) {
    [PSCustomObject]@{
        Host      = $env:COMPUTERNAME
        Product   = $product.DisplayName
        Version   = $product.DisplayVersion
        Installed = $product.InstallDate
    }
} else {
    [PSCustomObject]@{
        Host      = $env:COMPUTERNAME
        Product   = "None"
        Version   = "N/A"
        Installed = "N/A"
    }
}

Two minutes later, your SharePoint device group is built — and every future question about those servers starts from an answer instead of a guess.

2. Verify critical services are actually running

Hosts stay "up" while critical services die quietly. This check tells you which services are actually doing their job on each host:

# Verify critical services are running on each host
$critical = @("WinDefend", "W3SVC", "SPTimerV4", "MSSQLSERVER")

foreach ($name in $critical) {
    $svc = Get-Service -Name $name -ErrorAction SilentlyContinue
    if ($svc) {
        [PSCustomObject]@{
            Host      = $env:COMPUTERNAME
            Service   = $name
            Status    = $svc.Status
            StartType = $svc.StartType
        }
    }
}

Anything reporting Stopped or Disabled shows up in the results — and in AlertMonitor, that's exactly the kind of result you can promote to an alert condition on the spot.

3. Check patch recency per host

"When did each server last get patched?" is the question every auditor, every boss, and every incident responder eventually asks:

# Report the most recent hotfix and days since last patch
$latest = Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1

if ($latest -and $latest.InstalledOn) {
    $days = (New-TimeSpan -Start $latest.InstalledOn -End (Get-Date)).Days
    Write-Output "$env:COMPUTERNAME last patched $days days ago ($($latest.HotFixID))"
} else {
    Write-Output "$env:COMPUTERNAME: no hotfix data available"
}

Run this fleet-wide and sort the results — the stragglers are your real patch backlog, not the tidy one in the WSUS console.

4. Sweep disk usage while you're in there

Because the outage you're most likely to prevent this quarter isn't ransomware — it's a full volume on the database server:

# Pull disk usage for all local fixed drives
Get-CimInstance Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object DeviceID,
        @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
        @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
        @{n='FreePct';e={ if ($_.Size) { [math]::Round($_.FreeSpace/$_.Size*100,1) } }}

5. Turn the repeat fixes into automated remediation

You already know which services die quietly and which servers run hot. Let AlertMonitor trigger a script the moment a monitored service stops, and let the action record itself:

# Self-healing example: restart a critical service if it stopped
$svc = Get-Service -Name "SPTimerV4" -ErrorAction SilentlyContinue
if ($svc -and $svc.StartType -ne "Disabled" -and $svc.Status -ne "Running") {
    Start-Service -Name "SPTimerV4"
    Write-Output "$env:COMPUTERNAME: SPTimerV4 was stopped and has been restarted automatically."
}

The technician who would have found that service down at 9am gets their morning back. The action is in the timeline. The ticket, if one is needed, links to the same record. That is the entire alert-to-resolution loop in one platform — no tab switching, no export, no mystery about what happened or who did it.

The Takeaway

The Warlock operators ran a fleet-wide operation in two hours because their tooling works at fleet speed. Your operations — and your incident response — should work at fleet speed too, whether the trigger is a SharePoint zero-day or a Tuesday morning disk alert on the file server.

The difference between a two-hour disaster and a two-minute fix is almost never skill. It's whether your monitoring, RMM, patching, and helpdesk are one system with one timeline — or five tabs and a prayer.

Related Resources

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