CERT Polska has published details on MikroTrick, an exploit chain of two RouterOS vulnerabilities that lets an attacker take full control of a MikroTik router over SSH without authenticating. MikroTik has shipped patches for six flaws across the SSH server and client, the bandwidth-test service, X.509 certificate handling, and the WebFig interface. And per CERT Polska: attacks against internet-facing RouterOS devices are already being observed in the wild.
Read that again. Not a proof of concept. Not a threat for next quarter. Live exploitation of routers sitting on your perimeter right now.
If you run MikroTik gear — or you're an MSP running it across dozens of client sites — here's the uncomfortable question: do you actually know which RouterOS version is running on every device you're responsible for, at this moment?
If your answer involves a spreadsheet last touched in Q2, a Winbox session per device, or 'I think we got most of them in that maintenance window,' you're not alone. You're also exactly the kind of environment MikroTrick was built to eat. And the same blind spot that hides RouterOS versions from you is hiding failed patches, pending reboots, and stale firmware everywhere else in your stack.
The Problem in Depth: Your RMM Can't See Your Routers
Look at what your tooling actually covers. NinjaOne, ConnectWise Automate, Datto RMM — excellent at Windows and third-party patching, because an agent runs on the device and reports back. Your monitoring stack — PRTG, LibreNMS, whatever the firewall vendor bundled in — sees the router. But what does it see? A green dot. Uptime. Bandwidth graphs. It has no idea that the green dot is running a RouterOS build from 2019 with a public takeover chain.
That's the silo in one sentence: the tool that can update software doesn't watch the device, and the tool that watches the device can't update software.
Why the gap persists:
- No agent, no patching. RMM patch modules are agent-driven. Network gear doesn't run your RMM agent, so firmware silently falls out of patch scope and into 'manual process' territory — spreadsheets, tribal knowledge, and that one senior tech who 'handles the routers.'
- Firmware updates are scary in a way OS patches aren't. A bad RouterOS upgrade can brick a box that needs physical access or out-of-band console to recover. At a branch office four hours away, 'we'll do it during the next site visit' quietly becomes a two-year-old ticket.
- Version drift is invisible. Across a fleet you end up on five different RouterOS versions because each device got upgraded whenever somebody remembered. Nobody notices until an advisory lands.
- Vendor advisories arrive as PDFs and emails, not tickets. Someone has to manually correlate 'which devices are affected' against 'what versions are we running.' On a busy week, that correlation is exactly what falls through the cracks.
Now the real-world impact:
- A MikroTik router is not just a router. It's your perimeter firewall, NAT boundary, and frequently your VPN endpoint and DNS forwarder. Full takeover means attacker-controlled DNS for your users, traffic interception, a pivot point straight into the LAN, and historically — botnet recruitment at scale. The 2018 Meris botnet was built on roughly a quarter of a million hijacked MikroTik devices. This is not theoretical.
- Picture a mid-size MSP: 60 clients, four MikroTik routers per site on average. That's 240 RouterOS devices spread across five or more firmware versions, some on 6.x builds that predate the last three advisories. The day MikroTrick lands, leadership asks one question: 'Are we exposed?' Producing the answer means SSH sessions into 240 boxes, assuming credentials are even documented. Internet-wide scanners indexed most of those routers months ago.
- For internal IT, it's the internet-facing router at the branch office nobody has logged into since the person who configured it left. The cost of the inevitable incident isn't measured in hours of downtime — it's measured in how long it takes to rebuild trust with the business after users get DNS-hijacked or the site goes dark.
And the human cost: your best tech burns a weekend doing emergency firmware upgrades across sites instead of the project work you promised in the last planning meeting. Burnout isn't caused by hard problems. It's caused by preventable ones your tooling failed to surface.
How AlertMonitor Closes the Gap
MikroTrick is a firmware story, but the root cause is universal: you can't patch what you can't see, and you can't see anything when your tools don't share state. AlertMonitor is built on the opposite assumption — monitoring, RMM, patching, and helpdesk all read from the same inventory in one platform.
Concretely:
- Real-time patch status for every managed Windows device. Missing updates, failed patches, pending reboots — live, per device, per group. When a new advisory drops, your exposure question is answered in seconds, not spreadsheet-hours.
- Staged, scheduled deployments with rollback. Push updates in waves: pilot ring first, then department by department or site by site. If a patch breaks something, roll it back — no fire drill. MSPs stage by client, so Client A's patch wave never takes down Client B at the same time.
- Monitoring that understands patching. This is the one that kills the 2am mystery. When a device reboots after an update, the alert carries full context — tied to the patch job, marked as expected, and watched until the device comes back healthy. The NOC sees 'planned reboot, patch wave 2, device online again in four minutes' instead of paging someone. Nobody's phone rings. Your users never learn about the outage before you do at 8am.
- Network devices in the same pane of glass. Routers and switches are monitored on the same platform as everything else, so your perimeter isn't the part of the environment your tooling ignores. Version inventory and availability live in one place.
- Helpdesk that inherits the truth. A failed patch raises a ticket automatically with the device, the update, and the error context attached. No tech copy-pasting between three consoles at midnight.
The before and after: the old way is Winbox in one tab, PRTG in another, a spreadsheet in a third, the vendor advisory sitting in email, and a technician assembling the picture by hand. The AlertMonitor way is one console that shows you the outdated device, schedules the wave, watches the status flip live — and if anything misbehaves overnight, the alert already knows why.
Practical Steps You Can Take Today
1. Get an honest RouterOS inventory — today
Thirty minutes and a device list gets you the truth from every router:
# routers.txt: one user@host per line
while read -r target; do
echo "=== $target ==="
ssh -o ConnectTimeout=5 "$target" '/system resource print without-paging' 2>/dev/null \
| grep -E 'version|board-name|uptime'
done < routers.txt
Whatever comes back on an old 6.x build goes straight onto the upgrade list. Yes, even the boxes that 'have been fine for years.'
2. Back up every config before you touch anything
ssh admin@192.168.88.1 '/export hide-sensitive file=pre-upgrade'
scp admin@192.168.88.1:pre-upgrade.rsc ./backups/rtr-branch01-pre-upgrade.rsc
A config backup stored on the router you're bricking is not a backup. Store the exports off-device before the upgrade window opens.
3. Audit pending reboots across your Windows fleet
Half of 'patched but not really' is devices sitting on a pending reboot since last Patch Tuesday:
$servers = Get-Content .\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
$cbsPending = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
$wuPending = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
$lastPatch = (Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1).InstalledOn
[PSCustomObject]@{
Server = $env:COMPUTERNAME
RebootPending = ($cbsPending -or $wuPending)
LastPatch = $lastPatch
}
} | Sort-Object RebootPending -Descending | Format-Table -AutoSize
In AlertMonitor, pending-reboot state is tracked automatically and surfaced per device in the patch dashboard. Until you're there, run this weekly and schedule those reboots before they schedule themselves at the worst possible moment.
4. Verify the critical KB actually landed
Get-Content .\servers.txt | ForEach-Object {
[PSCustomObject]@{
Server = $_
Patched = [bool](Get-HotFix -ComputerName $_ -Id KB5044284 -ErrorAction SilentlyContinue)
}
}
Swap in your own KB number. A compliance report that says 100% means nothing until you've verified the specific update on the specific servers that matter.
5. Build the recurring workflow, not the heroic one
In AlertMonitor: group devices by site or department, define patch policies per group, stage deployment waves, and let failed patches open tickets automatically. The goal is simple — when the next MikroTrick drops (and there is always a next one), your response is 'already staged, deploying tonight' instead of a war room.
The Takeaway
MikroTrick will be patched on routers within weeks. The blind spot that made it dangerous — firmware nobody tracks, patches nobody schedules, tools that don't talk to each other — will still be there when the next advisory lands. Fix the process and the platform together, and the next disclosure email becomes a routine task instead of an incident.
Related Resources
AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.