The offensive post walked through owning a RouterOS box. This is the defender's half: the log topics, flow patterns, and baseline diffs that catch Winbox exploitation, brute force, config theft, and the tell-tale signs of an attacker living in the router — because on a compromised box, the local log is the one thing you can't trust.
The single most important idea for detecting RouterOS compromise: an attacker who owns the router owns its local logs. So detection lives off the box — the remote syslog copy, the Traffic-Flow export, and a known-good config baseline you diff against. Each technique in Attacking MikroTik Gear maps to a signal in one of those three feeds.
The prerequisite is that those feeds exist and are shipped somewhere the router can't reach to tamper with. Then the account topic catches logins, Traffic-Flow catches exfil and pivoting, and a config diff catches the persistence an attacker leaves behind. Detection is the safety net under hardening — for the exposed box you missed, or the next Winbox-class bug.
/export01
Winbox exploitation, credential reuse, and brute force all end in a login. The account topic records every one — who, from where — and a burst of failures is the brute-force signature.
# The account topic logs every login attempt with user + source address. # Ship it to remote syslog and alert on: # - success from an UNEXPECTED source address/geo # - a burst of failures from one source (brute force) > /system logging add topics=account action=syslog ... user admin logged in from 203.0.113.9 via winbox -> expected? ... login failure for user admin from 45.x.x.x via winbox (x50) -> BRUTE # Firewall input-drop logging shows the knock BEFORE the login: > /ip firewall filter set [find action=drop chain=input] log=yes log-prefix="IN-DROP" ... IN-DROP ... dst-port=8291 -> someone probing Winbox from the WAN
After hardening, the WAN can't reach 8291/8728 at all — so a dropped-input log for those ports from the internet means someone is scanning you, and it's a free early-warning that you're on someone's list. Even better: it confirms your firewall is doing its job. If you ever see a successful Winbox login sourced from outside your management network, treat it as compromise, not a curiosity — that's the CVE-2018-14847-class scenario.
02
An attacker who gets in exports the config (every key and credential) and may turn the router into a pivot. Traffic-Flow and connection state show the router doing things routers don't do.
| Signal | What it means |
|---|---|
| Router sourcing an outbound file transfer | Config/backup exfil to the attacker |
| New long-lived connections from the router itself | Reverse shell / C2 beacon — check /ip firewall connection |
| SOCKS proxy traffic patterns | Router used as a pivot — /ip socks should be off |
| A spike in router-CPU / sniffer running | Passive interception — check /tool sniffer state |
| Fetch/tool activity to unknown hosts | Malware pulling a payload via /tool fetch |
On a compromised RouterOS box, /ip firewall connection, the logs, even /tool sniffer status can be manipulated or the attacker can hide their tooling. That's why the authoritative view is the Traffic-Flow export at the collector and the syslog copy on the server — data the router shipped out before anyone could tamper with it. If the off-box flow shows the router talking to a host the on-box tools deny, believe the flow. Detection that relies only on the suspect device is detection an attacker can switch off.
03
The clearest signal of compromise is what the attacker leaves: a hidden user, an added scheduler/script, a SOCKS proxy, an injected DNS static. A config diff against a known-good baseline surfaces all of it.
# Pull a fresh /export on a schedule and diff it against the baseline. # Any of these appearing is a persistence red flag: + /user add name=... # hidden/extra account + /system scheduler add ... # beaconing / persistence + /system script add ... + /ip socks set enabled=yes # pivot enabled + /ip dns static add ... # traffic redirection + /ip firewall nat/mangle ... # traffic hijack # A weekly "diff the fleet against baseline" job catches slow, quiet # persistence that no single alert would. See the fleet + backup posts.
This pairs with fleet management — pull every router's /export centrally and diff against its committed baseline, so a change nobody made is a finding. It's the RouterOS version of Cisco's config-archive detection.
Takeaways
account topic catches every login — alert on success from unexpected sources and failure bursts (brute force).NOCTIS builds off-box detection for MikroTik and Cisco across Crete — login alerting, flow-based exfil detection, and baseline config diffing — so a compromised router raises a flag instead of quietly working for someone else.
Book a Discovery Call →