Everyone read the same advisory last week and reached for the same verb: patch. Do it — I’m not going to talk you out of a patch. But if internet-facing SSH on your MikroTik was reachable at any point before you upgraded, treating the new firmware as the end of the incident is the exact mistake that gets you paged again in six months, at 2 a.m., over a router you were certain you’d already dealt with.
Here’s the situation as reported by SANS ISC: MikroTik has shipped a fix for a critical SSH authentication bypass in RouterOS. Unauthenticated. Remote. On a device whose entire purpose is to sit at the edge of your network wearing a routable address like a target. Exploitation is active — this is happening now, not a proof-of-concept somebody might weaponise later. And the part that actually matters for you: the interesting move isn’t the initial access. It’s what the intruders do the moment they’re in. They create user accounts. Sometimes they drop SSH keys. That persistence is deliberately designed to survive the very patch you’re about to feel good about applying.
The patch-now people are right about the wrong half
Let me steelman the standard advice properly, because it isn’t stupid. Patching closes the bypass. An unauthenticated auth bypass on an edge router is about as bad as it gets — no credentials, no phishing, no user interaction, just a reachable port and full control of your routing, DNS, and NAT. Upgrading to the fixed build is non-negotiable and it should happen today. If you do nothing else this week, do that. The advice to patch immediately is correct.
It’s also incomplete in a way that will cost people. An authentication bypass is a door. Once someone has walked through it, patching only replaces the lock. It does nothing about the fact that they’ve already been inside, opened the windows, and — in this case — cut themselves a fresh key that works on the new lock too. A new local account isn’t affected by the SSH fix. It’s just a legitimate credential now. You handed it validity the instant the account was created.
That’s the reframe: this is an assume-breach scenario for any device that was exposed, not a patch-and-forget one.
What a decade of watching these logs taught me
I’ve kept SSH and the RouterOS log verbose on border MikroTiks for years, mostly out of paranoia earned the hard way. The thing you learn is that the noisy attacks — the brute-force floods, the constant knocking on 22 and 8291 — are almost comforting. They’re loud, they fail, they show up in every graph. The compromises that actually hurt are quiet. One clean login. One new account with a boring name that looks like it belongs. No repeated failures, because they didn’t need to guess anything. RouterOS persistence, when it’s done by someone competent, looks like configuration you might plausibly have written yourself six months ago and forgotten about. That’s the trap.
And RouterOS gives an attacker a rich toolbox for staying put. It’s not just /user. It’s the scheduler that can re-create a deleted account on a timer. It’s netwatch scripts. It’s a SOCKS proxy quietly turned on. It’s a firewall NAT rule that forwards a high port straight back to management. It’s the cloud backup and DDNS features. Deleting one rogue user and calling it clean is how you end up doing this twice.
The hunt, in the order I actually run it
These are read-only RouterOS console commands — print shows state, it doesn’t change it. Run them over a trusted channel (Winbox on the LAN, or serial), not the internet-facing SSH you’re trying to clear. Compare everything against a known-good config, not against your memory.
One example: say /user print detail shows an account you don’t recognize, group full, and /user ssh-keys print detail shows a key attached to it. That key is what survives the patch. Now check /system scheduler print detail — if there’s a scheduled script that runs /user add or re-imports a key on an interval, deleting the account alone just resets a timer. You have to pull the scheduler entry, the script, the account, and the key together, in that order, or it grows back like a weed.
One honest caveat: RouterOS logging is small and volatile by default, and on many boxes it lives in RAM. If you never shipped logs off the device, the login that let them in is probably already gone. Absence of evidence in /log print is not evidence you’re clean — it’s evidence you weren’t logging. Treat exposure, not log entries, as your trigger for the full hunt.
What to actually do, and how fast
Immediate — today: Upgrade to the fixed RouterOS build. Pull the exact patched version straight from MikroTik’s advisory rather than trusting a number from a blog (this one included); check both the stable and long-term trains, because the build you need depends on which you’re running. While you’re there, get SSH off the public internet entirely — restrict /ip service for ssh to a management subnet or VPN, and change the default port only as noise reduction, never as your control.
Immediate, same maintenance window — the part people skip: Run the audit above on every device that had SSH reachable. Any exposed box is guilty until proven innocent. Delete rogue accounts, strip unrecognized SSH keys, kill hostile scheduler/script entries, and diff the full /export against a trusted baseline. Then rotate credentials for the legitimate accounts too — the attacker had root-equivalent access, so assume they read your config, including any secrets in it.
This week: Ship RouterOS logs somewhere off-box (a syslog target), so next time you’re not investigating a device that has already forgotten what happened to it. Enable it now; you’ll want the history you don’t have yet.
Next cycle: Get management planes off the edge as a standing rule, not a scramble. If an unauthenticated bypass can only reach a service that isn’t internet-facing, the next advisory like this one is a shrug instead of a fire.
Patch the router, yes. Then go find out who else has a key to it. The upgrade protects you from the next attacker. It does absolutely nothing about the one who was already in.
