CVE-2018-14847: Is Your MikroTik Still Backdoored?

CVE-2018-14847 was a path traversal flaw in the Winbox service that let an unauthenticated attacker read files from the router — including the user database. It was patched in 2018. That part is old news.

The part that is not old news: patching closed the door, but it never undid what came through it. Devices exploited during that window had accounts added, scheduled scripts installed, and proxies enabled. All of that is ordinary configuration. It survives a RouterOS upgrade, because an upgrade is supposed to preserve your configuration and it has no way to know which parts you did not write.

So a router patched in 2019 can still be running someone else’s scheduler entry today.

Am I in scope?

If the device has ever run RouterOS below 6.42.1 or 6.40.8 with Winbox reachable from an untrusted network, assume it was scanned. This was mass exploitation, not targeted work — scanners swept the entire address space repeatedly for well over a year.

/system package print
/system history print

Current version tells you nothing about exposure. What matters is what the device was running when it was last reachable, which the history may or may not still hold.

The six checks

1. Accounts you did not create

/user print detail

Look for anything you cannot account for. Names in the wave were frequently plausible rather than obviously hostile.

Check the groups too — an account in a custom group with policy=...,write,policy is worth more scrutiny than the name is:

/user group print detail

2. Scheduler entries

/system scheduler print detail
/system script print detail

This is where persistence usually lived. A scheduler entry that runs on startup and calls /tool fetch against a remote address is re-downloading a payload every time the router boots. Read the on-event body of every entry, not just the names.

3. SOCKS proxy

/ip socks print
/ip socks access print

An enabled SOCKS proxy on a router nobody deliberately configured as one is the single strongest indicator on this list. It was turned on so the device could be used to relay someone else’s traffic.

4. NAT rules that redirect traffic

/ip firewall nat print detail
/ip firewall mangle print detail

Look for dst-nat or redirect rules on ports you did not intend, particularly 8080, 3128, or anything sending web traffic through the router’s own proxy.

5. Files that should not be there

/file print

Fetched payloads land in the filesystem. Anything unfamiliar next to your backups is worth explaining before you dismiss it.

6. The proxy and its cache

/ip proxy print
/ip proxy access print

Enabled web proxy, same reasoning as SOCKS.

If you find something

Do not clean it item by item. If any of the above turns up something you cannot explain, treat the credentials as disclosed — the vulnerability read the user database, so every password on that device from that era must be assumed known, along with any password reused elsewhere.

The reliable path is a rebuild:

1. Export the configuration for reference only, not for restoring.
2. Netinstall the device to wipe it completely.
3. Rebuild the configuration by hand from the export, reading each line as you go.
4. Set new credentials everywhere, including anything that shared a password.
5. Apply the hardening in the previous article before it goes back on the network.

Restoring a backup taken after the compromise restores the compromise. That is the mistake worth avoiding here.

If you find nothing

Good — but record what you checked and when. The value of this exercise is that it can be repeated identically across every device you run, and next year you want to know which ones were already cleared.