login failure for user -2 via ssh: triaging a compromised MikroTik RouterOS device

login failure for user -2 from <ip> via ssh

If that line is in a RouterOS log, someone pointed the MikroTrick chain at the device. It is not a mistyped password, not a bot guessing admin, and the word failure in it is actively misleading. This post covers what the malformed -2 is, how to triage a router you suspect, and why "patch it and move on" is the wrong answer on a box with this string in its log.

One thing up front, because it shapes everything below.

The exploitation details are omitted on purpose

CVE-2026-67276 is weaponised. Public proof-of-concept code for the authentication-bypass half of the chain has real traction on GitHub, and CISA added two of the six CVEs to its Known Exploited Vulnerabilities catalog on 2026-09-10 with a due date of 2026-09-13 — a three-day clock, which is CISA's way of saying this is already happening to people.

CERT Polska, who found and coordinated all six bugs, published with an explicit limit:

We limit the description to the information administrators need and do not publish exploit code or details that would make automating attacks easier.

This post holds the same line, and that is a stated choice rather than a gap you should wonder about. You will not find the vulnerable code path developed here: no request shapes, no key-forging recipe, nothing you could turn into a script. Every command below runs against a device you already own. Where the mechanism matters for reading a log correctly I explain it to exactly that depth and stop. NVD carries more than I reproduce, and that is the right place for it.

Why -2 is the tell

The three vulnerabilities that matter here:

CVE	What it is	CVSS 4.0 (CERT.PL)	CWE	KEV
CVE-2026-67276	SSH authentication bypass — the authorised-key comparison was not a comparison of the whole key	9.2 Critical	CWE-347	No
CVE-2026-86060	Privilege escalation via a crafted SSH username	9.2 Critical	CWE-88	Yes, 2026-09-10
CVE-2026-67277	Unauthenticated btest memory disclosure and remote DoS	8.8 High	CWE-306	Yes, 2026-09-10

The second is where the log artefact comes from. CWE-88 is improper neutralization of argument delimiters in a command, and CERT Polska describes the bug as RouterOS failing to "properly handle usernames beginning with a disallowed character in the SSH login mechanism." NVD and CISA describe the consequence identically: the trusted RouterOS policy mask gets changed, and the session ends up with full administrative privileges.

Put the CWE next to the description and the log line stops being mysterious. -2 is a username that begins with a hyphen, and a leading hyphen is the argument delimiter in every command-line convention there is — which is precisely what CWE-88 is about.

So -2 is not a user ID, not an internal error code, and not a number RouterOS computed. It is the username the attacker supplied, logged faithfully. The string looks malformed because it is malformed: you are looking at the shape of the input, echoed into your audit trail by a logger doing its job correctly.

That reading is mine — CERT Polska publishes the indicator without explaining it — but it is the only one consistent with CWE-88, with "usernames beginning with a disallowed character," and with the second published marker:

user <name> added by ssh:-2@<ip>

RouterOS attributes configuration changes in the form <service>:<username>@<source-ip>. So that line says an account was created, over SSH, by a user called -2. The injected argument is named as the actor in your own audit log.

Now read the two lines together, because the pair is the actual detection:

• Line one records an authentication failure.
• Line two records a privileged configuration change attributed to that same non-account.

That is not what brute force looks like. Brute force gives you a wall of failures and no configuration changes, or a success line followed by changes. A device that logs an authentication failure and then logs a new user added by the identity that just failed has had its authentication decision and its authorisation decision disagree. Hunt on that disagreement rather than either line alone: it is the part an attacker cannot tidy up without admin on the box, and by then the line is already written.

The published indicator set, and where each one lives

Indicator	Where to look	What a hit proves	What a miss proves
login failure for user -2 from <ip> via ssh	/log, or your syslog collector	The login path was reached with a crafted username	Nothing — see the buffer problem below
user <name> added by ssh:-2@<ip>	/log, /system history	A privileged config change succeeded	Nothing
A high-privilege user named ops	/user, /user group	Strong, but attacker-chosen	Nothing
flagged: yes	/system/device-mode/print	RouterOS found known tamper traces at boot	Nothing
82.192.72.4	Logs, firewall counters, connection tracking	Tied by CERT.PL to successful attacks including ops creation, since at least 2 September 2026	Nothing
103.102.31.18	Same	Tied to attempts against the chain	Nothing

The right-hand column says "nothing" six times. That is not hedging, it is CERT Polska's own position, stated twice — "the absence of the traces mentioned above does not rule out unauthorized activity," and on the vendor's marker, "the absence of the marker is not proof that the device is safe."

Three reasons a clean device can be a compromised device:

The log buffer is memory, and memory rotates. RouterOS logs to a fixed-size memory buffer by default. Exploitation has been running since at least 2 September. If the router has been up and busy since then, that evidence has almost certainly been overwritten by DHCP chatter. The string's absence tells you about your buffer size, not your router.

A reboot destroys it outright. Rebooting to "see if it comes back clean" throws away the only copy of the evidence you had.

ops is a plausible real account name. Plenty of shops have one legitimately. Finding it is a reason to check when and by whom it was created, not a verdict.

The order of operations matters more than the speed

This is the part underappreciated in the coverage of this bug, and it is the thesis of the post.

The fixed firmware ships MikroTik's Flagged mechanism. On startup, RouterOS scans the configuration for known signs of unauthorised change, disables the suspicious entries it recognises, writes a critical log message, and sets flagged: yes in device-mode.

That is good engineering and it will save a lot of routers. It is also an evidence-destroying event, and it fires on the boot that completes your upgrade. The scan only runs on fixed firmware, so flagged is a post-upgrade artefact — no point checking it on an unpatched box — which means the moment you learn the device was tampered with is the same moment the tampered configuration gets disabled and the reboot clears the memory log.

So on a device you actually suspect, the upgrade is not step one. Preservation is.

1. Isolate at the network layer. Firewall it off upstream, pull the uplink, move the port to a dead VLAN. Do not reboot it and do not reset it.
2. Get the configuration and logs off the box before anything else. CERT Polska is explicit that logs and configuration should be secured before a reset, and they publish a separate guide for doing it.
3. Then read the indicators using the checklist below.
4. Then upgrade, and only then check flagged.
5. Then decide the rebuild, which is not optional — see below.

If the device is one of a hundred and nothing points at this particular one, invert it: patch immediately, then investigate. The careful order is for the box that already looks wrong.

One detail before you touch device-mode: clearing the marker takes /system/device-mode/update flagged=no and a physical button press or hard power cycle to confirm. It cannot be cleared over the network — a deliberately sticky marker, which also means an attacker holding remote admin cannot quietly clear it. CERT Polska's instruction is to leave it set until your analysis is finished.

The triage checklist

Run this on a device you own. Every command is read-only except the export, which writes a file to the router's own storage.

# 0 — Preserve first. Export the running configuration to a file, then copy it off.
/export file=triage-evidence
/file print

# 1 — Am I even on a fixed build?
#     Fixed: 7.25beta3, 7.24.2, 7.23.4, 6.49.21
/system resource print
/system package print

# 2 — The Flagged marker. Meaningful only on fixed firmware, after a boot.
/system/device-mode/print

# 3 — The published log indicators, verbatim. The third line is deliberately
#     broad: it catches every account-creation attribution, not just "-2".
/log print where message~"login failure for user -2"
/log print where message~"added by ssh:-2@"
/log print where message~"added by"
/log print where topics~"critical"
/log print where topics~"system,error"

# 4 — Accounts, groups, live sessions, and authorised SSH keys.
/user print detail
/user group print detail
/user active print detail
/user ssh-keys print detail

# 5 — Who changed what. The 'by' field carries the attribution.
/system history print detail

# 6 — Persistence surfaces CERT.PL names explicitly.
/system script print detail
/system scheduler print detail
/ip socks print
/ip proxy print
/file print

# 7 — Management-plane exposure, and the btest service from CVE-2026-67277.
/ip service print detail
/ip ssh print
/tool bandwidth-server print
/ip firewall filter print

# 8 — Tunnels the attacker may have added to keep a path in.
/interface print detail

And on the syslog collector, where this search should actually happen:

grep -rF 'login failure for user -2' /var/log/
grep -rF 'added by ssh:-2@' /var/log/
grep -rEn '82\.192\.72\.4|103\.102\.31\.18' /var/log/

Use -F deliberately: the indicator contains a hyphen and you want a literal match, not a regex argument.

A flagged router is not repairable

If the indicators land, the device does not get cleaned. It gets rebuilt. The chain hands over full administrative privileges, and on a router that means scripts, schedulers, SOCKS and proxy services, tunnels, firewall rules, certificates, and the stored secrets of everything the router authenticates to. There is no subset of that you can audit back to trustworthy, and the vendor's own scan "detects only selected traces."

Concretely:

• Factory reset, once the evidence is off the box, then reconfigure from a trusted, verified configuration.
• Do not restore a backup from the device. CERT Polska's wording is "do not blindly restore a full configuration backup originating from a potentially compromised device." A binary backup carries the attacker's additions along with yours. Rebuild from a reviewed .rsc export or your source-of-truth config, read line by line.
• Every credential the router held or protected. Local passwords, SSH keys, SNMP communities, RADIUS secrets, VPN pre-shared keys, wireless passphrases, API credentials, and anything typed into a session that transited this device.
• Re-issue authorised SSH public keys, do not just re-check them. CVE-2026-67276 is a flaw in how authorised keys were matched; treat key material configured on a compromised router as burned.
• Fixed firmware before it rejoins the network, not after.
• Report it to the appropriate CSIRT, as CERT Polska asks.

Leave flagged: yes set until you are finished.

Scoping the rest of the fleet

Two rules, and the first one is the one people get wrong.

Do not run the sweep from a RouterOS device. CERT Polska's interim guidance says not to initiate TLS connections from an unpatched device and not to use the built-in SSH clients, /system ssh and /system ssh-exec, across untrusted networks. The SSH client and certificate handling are in scope here, not just the server. The instinct is to loop over the fleet from one convenient router; on this bug that turns your jump host into the next victim. Sweep from a patched workstation or your NMS.

Start off-box, where it is free. Grep the syslog collector before touching a single device. It costs nothing, contacts nothing, destroys no evidence, and covers every router configured to log remotely — which is also how you learn how many were not.

Then sort the inventory by exposure, not by importance. The filter that matters is whether SSH was reachable from an untrusted network, the precondition both CERT Polska and MikroTik put at the front of their advisories. A box with SSH bound to a management prefix is a different risk from an identical box with /ip service wide open, and the second list is the one you work first.

What made this reachable

MikroTik's own assessment is that "most configurations are not at risk," which is worth sitting with, because it is a statement about configuration rather than firmware. The chain needs the SSH service reachable. The devices being taken over are the ones whose management plane was on the internet.

In order of how much they buy you:

Patch. 7.25beta3, 7.24.2, 7.23.4, or 6.49.21. Nothing below substitutes for this.

Get the management plane off the internet. MikroTik's guidance is to ensure SSH "is not open to any untrusted networks" and to use "a strong VPN like Wireguard to access your router." On /ip service that means binding SSH, www and www-ssl to management prefixes with address or available-from, and disabling services you do not use. This is the control that would have made the whole chain unreachable, which is why it belongs above patching in your standards even though it sits below it in this incident.

Turn off btest. /tool bandwidth-server with enabled=no unless you genuinely use it. It is the surface for CVE-2026-67277, which is KEV-listed, and almost nobody needs it running permanently.

Log off-box before you need to. The reason half the answers in that table were "nothing" is the memory buffer. /system logging action with a remote target converts every future incident from guesswork into a grep. It is the cheapest item here and it decides whether you can answer the question at all next time.

If you cannot patch today, CERT Polska's interim measures are: block SSH, www/www-ssl and the bandwidth-test server from everything outside trusted management networks, and stop initiating TLS or SSH from unpatched devices. They are explicit that this reduces attack surface and does not replace the upgrade.

Take this away

login failure for user -2 from <ip> via ssh is not a failed login. It is your router transcribing an injected argument into the username field of its own audit log, and failure describes the authentication check, not the outcome of the attack. If it is followed by user <name> added by ssh:-2@<ip>, the attack worked.

And the marker that tells you so arrives on the same boot that disables the evidence. Preserve first, patch second, rebuild third.

Sources

• CERT Polska: Critical vulnerabilities in MikroTik RouterOS are being actively exploited — indicators, IPs, the ops account, recommendations
• CERT Polska: MikroTik RouterOS CVE details — all six CVEs and affected ranges
• MikroTik: September 2026 vulnerability bulletin — fixed versions, vendor guidance
• MikroTik documentation: Device-mode — the flagged field
• MikroTik documentation: Log — /log print filtering, remote logging
• MikroTik documentation: User — user, group and SSH-key menus
• NVD: CVE-2026-67276 · CVE-2026-86060 · CVE-2026-67277
• CISA Known Exploited Vulnerabilities Catalog — CVE-2026-86060 and CVE-2026-67277, added 2026-09-10