Version 2.0 — 14 September 2026

Supersedes Version 1.0 (24 October 2022). Prepared as part of the MikroTik Industry / Internet Security Public Health effort with the Shadowserver Foundation, FIRST.org and the M3AAWG Anti-DDoS SIG. Classification: TLP:CLEAR — may be freely redistributed.

URGENT — SEPTEMBER 2026: “MikroTrick” IS BEING EXPLOITED RIGHT NOW

CERT Polska disclosed six RouterOS vulnerabilities on 5 September 2026. Two of them chained together — CVE-2026-67276 (SSH authentication bypass, CVSS 9.2) and CVE-2026-86060 (SSH privilege escalation, CVSS 9.2) — give an attacker complete, unauthenticated administrative control of any RouterOS device whose SSH service is reachable from an untrusted network. A third, CVE-2026-67277 (bandwidth-test / btest, CVSS 8.8), allows unauthenticated kernel-memory disclosure and a remote restart.

Exploitation has been confirmed in the wild since at least 2 September 2026 — one day before the patch shipped. CISA added CVE-2026-67277 and CVE-2026-86060 to the Known Exploited Vulnerabilities catalog on 10 September 2026 under BOD 26-04, with a forensic-triage requirement attached to CVE-2026-86060.

Fixed RouterOS versions: 7.25beta3 (development) · 7.24.2 (stable) · 7.23.4 (long-term; deploy 7.23.5) · 6.49.21 (v6 long-term).

Patch first. Then investigate for compromise. If your router exposed SSH, WebFig, WinBox, or btest to the Internet before you patched, assume it is compromised and work through Step 12 before you trust it again. Do not expose SSH, WinBox, WebFig, API, or bandwidth-test to the Internet at all — use a VPN such as WireGuard.

Why this guide exists

MikroTik devices are wonderful networking tools. They offer flexibility and cost-effectiveness to solve networking problems. But the way we deploy MikroTiks in the industry keeps creating security risks:

Organizations deploying MikroTik devices are creating security risks inside their own organization.
ISPs that aren’t tracking MikroTik deployments on their customers create risk for their business, their network, and their other customers.
The industry that is not pushing for better “out of the box” MikroTik security is accepting massive DDoS attacks, gateways for ransomware crews, covert proxy networks, and a range of other abuse.

In 2022, this guide opened by calling MikroTik “the year’s most dangerous malware platform.” Four years later, the claim no longer needs rhetoric — it has measurements behind it.

Every day, the Shadowserver Foundation identifies roughly 3 million MikroTik devices on the Internet, sees about 2.6 million of them answering WinBox or bandwidth-test queries, and in early September 2026 saw just over 122,500 with SSH open to the world. In that same week, an unauthenticated takeover chain targeting that exact SSH exposure went into mass exploitation.

(Use this link to get the latest update from the Shadowserver Dashboard)

This guide helps engineers, administrators, ISPs, and organizations find, secure, clean up, and monitor MikroTik devices in their network.

How to use this guide

Version 1.0 mixes hardening with compromise investigation. The 2026 exploitation makes the order matter, so work in three phases. The numbered steps keep their Version 1.0 numbers, so the 2022 workshop slide deck still maps to them; Steps 14–17 are new.

Phase	What it answers	Steps
Phase A — Can I trust this router?	Version, exposure, Flagged state, logs, users, scripts, evidence preservation.	0, 1, 3, 12
Phase B — Establish a secure baseline	Patching, accounts, VPN-only management, firewall, device mode, service minimization, discovery / DNS / proxy controls.	2–11, 14, 16
Phase C — Prove and maintain the state	Netinstall where needed, logging, external validation with Shadowserver, ongoing monitoring, CPE program.	15, 17, FINAL, Monitoring

First, every network device has core principles that drive security and resiliency. They are general principles and apply to any network vendor. Second, this guide works through a basic MikroTik router connected to the Internet (see the figure). Lastly, if you go through these steps and find problems, ASSUME YOUR ROUTER IS COMPROMISED. At the end of this process, you will need to do a NETINSTALL, rebuild the device, and start from scratch.

WHY? When you can no longer trust a router’s integrity, trying to identify and surgically remove every attacker modification gives you far less assurance than rebuilding the device from known-good installation media. Modern compromises of MikroTik devices can reach the underlying Linux operating system, and RouterOS commands cannot reliably reach what lives below RouterOS.

The September 2026 MikroTik emergency

What happened

CERT Polska (CSIRT NASK, the Polish national CERT) identified and coordinated the disclosure of six vulnerabilities in MikroTik RouterOS. Combining two of them allows an attacker to take full control of a device without authentication, provided the device offers remote access over SSH. CERT Polska named the chain MikroTrick and confirmed it is being used in real attacks. Sławomir Rozbicki found the vulnerabilities using an AI-assisted research environment, and researchers independently verified every finding.

MikroTik shipped the fixes on 3 September 2026 without technical detail — deliberately, to give operators time to upgrade — and for the first time in the company’s history sent a push notification to phones running the MikroTik app. CERT Polska published the details on 5 September and confirmed that the released patches stop the observed attacks.

The six vulnerabilities

CVE	Affected function	CWE	Impact	Status
CVE-2026-67276 (CVSS 9.2)	SSH authentication	CWE-347	RouterOS matched an SSH public key on key type and RSA modulus but omitted the exponent. Someone who knows a username and that user’s authorized modulus can authenticate without the private key.	Half of the confirmed MikroTik takeover chain
CVE-2026-86060 (CVSS 9.2)	SSH login/privilege handling	CWE-88	A crafted username beginning with a disallowed character reaches a legacy login helper and changes the trusted RouterOS policy mask—escalating to full administrator.	Actively exploited · CISA KEV
CVE-2026-67277 (CVSS 8.8)	Bandwidth Test server (btest)	CWE-306	A “related” btest connection is accepted before the primary session finishes authenticating; an unauthenticated UDP test leaks an uninitialized kernel packet buffer, and an inverted size check underflows and can restart the kernel.	Actively exploited · CISA KEV
CVE-2026-67278	X.509 / TLS validation	CWE-347	Malformed RSA PKCS#1 v1.5 signatures are accepted. With a low-exponent root CA in the trust store, an on-path attacker can forge a trusted intermediate and impersonate a server on RouterOS’s outbound TLS.	Patch
CVE-2026-67279	SSH rekey / connection protocol	CWE-841	A client-requested rekey before authentication moves the daemon into the session protocol; an unauthenticated client can create or overwrite files in the RouterOS-managed namespace, including support and configuration files.	Patch
CVE-2026-67281	WebFig /jsproxy	CWE-824	A stale, uninitialized principal pointer plus path traversal allows unauthenticated reads of root-owned files, including credential stores.	Patch

One distinction to keep straight. Several write-ups have blurred this. CVE-2026-67277 is not the SSH takeover bug — it is the bandwidth-test flaw, and it leaks kernel memory or crashes the router rather than granting access. The confirmed takeover chain is CVE-2026-67276 plus CVE-2026-86060. Both matter; they affect different services.

Fixed versions (as of 2026-09-14)

Release channel	Fixed build	Operational note
Stable (v7)	7.24.2	Current features plus fixes. The right target for most enterprise and lab deployments.
Long-term (v7)	7.23.4 — but deploy 7.23.5	7.23.5 was released on 4 September to correct an IPv6 DHCP regression introduced in 7.23.4, and keeps the security fix. Long-term is the right default for ISP edge and CPE fleets that need predictability.
Long-term (v6)	6.49.21	Emergency remediation for the v6 line. Treat v6 as a transition platform: where the hardware supports it, plan a tested migration to v7.
Development/beta	7.25beta3	Listed by MikroTik for completeness. Do not run beta code in production.

Cloud Hosted Router (CHR) instances are affected on the same terms and are often more exposed, because cloud instances tend to carry a public address with SSH reachable. Patch them with the same priority as physical hardware, and check the cloud security-group rules and the RouterOS configuration.

Indicators of compromise

CERT Polska observed the following during exploitation. Treat them as investigation pivots, not a definitive test – their absence proves nothing.

Indicator	Type	What it means
login failure for user -2 from via ssh	Log	An attempt at CVE-2026-86060 argument injection.
user added by ssh:-2@	Log	A successful exploitation that created an account.
A highly privileged user named ops	Configuration	The persistence account observed in the campaign.
82.192.72.4	IP address	Source of confirmed successful attacks, including ops creation, since at least 2 September 2026.
103.102.31.18	IP address	Observed in exploitation attempts.
flagged: yes	Device state	RouterOS itself recognized known traces of unauthorized change. See below.

The “Flagged” marker — and its limits

The patched releases added something new. At startup, RouterOS scans the configuration for known signs of unauthorized change, turns off the suspicious entries it recognizes, writes a critical message to the log, and sets a Flagged marker. Check it with:

/system/device-mode/print ;# look for flagged: yes

/log print where message~”Flagged”

A “not flagged” result is not a clean bill of health. Both MikroTik and CERT Polska are explicit: the mechanism detects only selected traces left behind by the attacks they have seen. Custom persistence evades it. Do the manual hunt in Step 12 regardless.

Do not clear the Flagged marker before you preserve evidence and finish the analysis.

If you cannot patch today

These are temporary measures. They reduce the attack surface; they do not replace the patch.

The scale of the exposure

Shadowserver added MikroTik SSH identification to its daily scans on 4 September 2026. On 5 September, it saw at least 122,500 MikroTik devices with SSH accessible in a single 24-hour window — Brazil 11,300, the United States 7,100, Indonesia 7,100, the Czech Republic 6,300, Ukraine 5,100. Separately, the new Accessible MikroTik Service Report covers about 2.6 million instances a day exposing WinBox or btest, and the Device Identification Report sees roughly 3 million MikroTik devices daily.

SSH exposure is not the RouterOS default — every one of those 122,500 is a device where someone opened the management plane. Shadowserver does not test for the vulnerability, so these are exposure counts, not compromise counts.

Step-by-Step Guide for Securing your MikroTik Device

Step 0 — Assume your MikroTik is infected, owned, and controlled by a miscreant

The number of exposed, vulnerable, and known MikroTik devices is in the millions. Given that, assume a miscreant controls your device and uses it for criminal activity—activity that puts your network at risk.

In 2026, this is no longer a cautious posture; it is an evidence-based one. If a MikroTik device exposes SSH, WebFig, WinBox, or btest to an untrusted network while running a vulnerable RouterOS version, treat compromise as a credible possibility. Patching prevents known exploitation; it does not remove changes an attacker has already made. That distinction — patching versus incident remediation — runs through this whole document.

Through this guide, we continuously assume the device is compromised. Each step builds confidence in the configuration and deployment.

Step 1 — Back up your device (and preserve evidence)

Yes! First, back up your MikroTik device and copy the backup to a safe location. This is common sense before making any change to a device or a network. See MikroTik’s Backup documentation.

Take both forms every time:

/system backup save name=pre-change ;# binary backup

/export file=pre-change ;# plaintext .rsc export – reviewable

The plaintext export is the one you can actually read, diff, and audit. The binary backup restores state you cannot inspect.

Don’t depend on MikroTik Cloud Backup. Since RouterOS v6.44, you can store a backup on MikroTik’s cloud servers (see IP/Cloud). But what happens when you cannot reach it? Keep a local copy as well. Do both.

NEW IN 2.0 — routine backup is not incident response. If you suspect compromise, the export and the logs are evidence, not recovery media. Preserve them (and a /system sup-output name=supout.rif if you can) before you change anything — and then never restore that backup onto the rebuilt device. It will re-import the attacker’s users, scripts, schedulers, and tunnels. Rebuild from a known-good template instead. This is CERT Polska’s explicit guidance.

Step 2 — Upgrade WinBox

Ease of use is one of the core reasons so many MikroTik devices are deployed, and WinBox is a big part of that. It is a small utility that administers RouterOS through a fast, simple GUI that closely mirrors the console functions.

Updated for 2026: WinBox 4 is a native cross-platform application for Windows, Linux, and macOS — the old advice about running the Win32 binary under Wine is obsolete, and MikroTik now treats WinBox 3 as legacy. Move to the current WinBox 4 release, retire legacy installations, and leave “Secure mode” enabled. Download from the MikroTik download page.

Upgrading WinBox does not make WinBox safe to expose. TCP 8291 belongs on your management network, never on the Internet—roughly 2.6 million devices get that wrong today.

Step 3 — Upgrade RouterOS (and RouterBOOT)

Version 1.0 said “upgrade to the latest stable version” and described the upgrade as “not a security fix but a critical security step.” For MikroTik, that framing is wrong and dangerous. Patching is the fix. An authentication bypass isn’t slowed by a non-standard port, a strong password, or a clever firewall rule if the service is reachable. Either the code is patched, or the service is unreachable—ideally both.

Know your release trains:

/system package update set channel=stable ;# or long-term

/system package update check-for-updates

/system package update install ;# this reboots the device

Then upgrade RouterBOOT firmware. Version 1.0 omitted this entirely, and it is routinely forgotten in the field:

/system routerboard print ;# compare current-firmware vs upgrade-firmware

/system routerboard upgrade

/system reboot

After the reboot, confirm current-firmware matches the installed RouterOS version.

Fleet practice. Back up every device first; validate on a pilot group; roll out in topology-aware waves with a rollback path; keep a known-good .rsc export per device. Enable Safe Mode before remote changes (the WinBox “Safe Mode” button, or [F4] in the CLI) so a lockout auto-reverts.

Step 4 — Usernames, passwords and keys

MikroTik has historically shipped with the username “admin” and no password. Newer devices may instead carry a device-specific credential printed on the label, depending on model and configuration — check, don’t assume. Either way, the principle is unchanged: assume the miscreants know your default credentials, and replace them.

Change the admin user’s password on the device. Remember the new password.
Add named users to maintain the router — one per operator, least-privilege groups, no shared logins.
Test the new usernames and passwords to make sure you have access.
Test the WinBox configuration with the new credentials.
Delete the user “admin.”

/user add name=netops group=full password=”“

/user disable admin ;# then, once verified: /user remove admin

Test any new password against Have I Been Pwned to validate exposure.

NEW IN 2.0 — passwords are not the control that matters here. CVE-2026-67276 defeats SSH public-key authentication and CVE-2026-86060 defeats the privilege model. No password policy helps against either. Credential hygiene remains necessary; it is simply not sufficient.

SSH key hygiene. Prefer keys over passwords, and after the MikroTik audit, audit the keys you have imported. An independent analysis of the patch recommends removing any RSA key with public exponent e=3 and replacing it with Ed25519/ECDSA or RSA with e=65537, and removing the diagnostic/test policy from users who do not need it. This is prudent researcher guidance rather than a vendor requirement — treat it as defense in depth.

/ip ssh set strong-crypto=yes allow-none-crypto=no always-allow-password-login=no

/user ssh-keys print detail

Rotate passwords, SSH keys, VPN and IPsec secrets, RADIUS/TACACS secrets, SNMP communities, and API tokens after any suspected exposure.

Step 5 — Limit who can reach the router: the management plane

The world does not need to connect to your router. The world should not be telnetting in or running WinBox from anywhere. In Version 1.0 this step restricted source addresses; in Version 2.0 it becomes the primary architectural control, and the target is stronger: management services should not be directly reachable from the public Internet at all.

Preferred: VPN-only management. MikroTik’s own advisory says it plainly: use a strong VPN such as WireGuard to reach your router, and do not open management ports at all. IPsec is an acceptable alternative. Where you can, manage through a dedicated out-of-band path or serial console rather than the data path.

Fallback, where direct remote management is genuinely unavoidable: restrict the user and every service to known source addresses.

/user set [find name=”netops”] address=192.168.2.0/24

/ip service set winbox address=192.168.2.0/24

/ip service set ssh address=192.168.2.0/24

/ip service set www-ssl address=192.168.2.0/24

Express “management” and “WAN” once as interface lists and reuse them everywhere:

/interface list add name=WAN

/interface list add name=MGMT

/interface list member add list=WAN interface=ether1

Apply the same thinking to IPv6. A management plane that is closed on IPv4 and open on IPv6 is an open management plane.

Step 6 — Changing the SSH port: useful noise reduction, not a security boundary

CHANGED IN 2.0 — this step has been demoted. Version 1.0 presented moving SSH from 22 to 2200 as a primary control. Moving the port reduces the volume of automated password guessing. It does nothing against MikroTik: the authentication bypass works on whatever port the service is listening on, and scanners find non-standard ports easily. Do not let a port change give you false confidence.

The controls that actually matter, in order: (1) patch; (2) take SSH off the public Internet — VPN or management network only; (3) restrict it by source address on the service and in the firewall; (4) harden the crypto. If, after all of that, you still want the quieter logs:

/ip service set ssh port=2200

/ip ssh set strong-crypto=yes

Test the SSH connection on the new port before you turn off telnet.

Step 7 — Limit the services opened on the router

Once you know SSH works, you can turn off telnet:

/ip service print

/ip service disable telnet

/ip service print

The Best Common Practice for security on network devices is to turn off everything, then turn on the specific functions and services your network design requires. Minimize risk by minimizing what is running in the background on your network device.

Here is the full RouterOS management surface to work through. Disable what you don’t need; restrict what you do.

Service	Command	Note
Telnet	/ip service disable telnet	Never needed.
FTP	/ip service disable ftp	Never needed.
WWW (HTTP WebFig)	/ip service disable www	CVE-2026-67281 affects WebFig.
WWW-SSL (HTTPS WebFig)	/ip service set www-ssl address=	Or disable. CERT Polska names WWW/WWW-SSL among the services to close.
API	/ip service disable api	Restrict if your automation needs it.
API-SSL	/ip service disable api-ssl	As above.
WinBox (8291)	/ip service set winbox address=	~2.6M instances are exposed globally.
SSH (22)	/ip service set ssh address=	The MikroTik target. Patch and restrict.
Bandwidth Test server (btest)	/tool bandwidth-server set enabled=no	CVE-2026-67277 target — now in CISA KEV. Also a classic DDoS tool.
DNS cache/recursion	/ip dns set allow-remote-requests=no	Stops the router from being a DNS reflector. See Step 16.
SOCKS proxy	/ip socks set enabled=no	A favorite of proxy-network operators.
Web proxy	/ip proxy set enabled=no
UPnP	/ip upnp set enabled=no
IP Cloud / DDNS	/ip cloud set ddns-enabled=no update-time=no
MAC-Telnet server	/tool mac-server set allowed-interface-list=none	Or MGMT only. See Step 8.
MAC-WinBox	/tool mac-server mac-winbox set allowed-interface-list=none
MAC-ping	/tool mac-server ping set enabled=no
Neighbor discovery	/ip neighbor discovery-settings set discover-interface-list=none	Or MGMT only. See Step 9.
RoMON	/tool romon set enabled=no	If unused.

Outbound matters too. On unpatched devices, do not use /system ssh or /system ssh-exec toward untrusted hosts, and avoid initiating TLS from the router — CVE-2026-67278 (X.509) and CVE-2026-67279 (SSH rekey) are exploitable on connections the router makes.

v6 / v7 note. The /tool mac-server menu layout differs slightly between trains, and device-mode (Step 14) exists only in v7. On v6, service disabling and firewalling carry the whole load.

Step 8 — Turn off direct access via the MAC address

By default, the MAC server runs on all interfaces, which means anyone directly connected to the device can connect or MAC-telnet to it. That lets miscreants already inside the network reach the device at Layer 2, below your IP filtering.

/tool mac-server set allowed-interface-list=MGMT

/tool mac-server mac-winbox set allowed-interface-list=MGMT

/tool mac-server ping set enabled=no

Disable MAC connectivity everywhere first, then add back only the local management interface. Never leave it enabled on a WAN port. See MikroTik’s First Time Configuration guidance.

Step 9 — Turn off neighbor discovery.

MikroTik runs a neighbor discovery service covering MNDP, CDP, and LLDP in the Layer 2 broadcast domain. It advertises your hardware model and software version, and you can use it to map your network. Miscreants, malware, and APT actors already inside your network use it for that exact purpose.

The BCP is to turn discovery off by default. MikroTik turns it on by default, so it must be turned off manually:

/ip neighbor discovery-settings set discover-interface-list=none

/ipv6 nd print ;# review IPv6 neighbour discovery settings too

Step 10 — Limit WHO on the Internet can access your MikroTik

REWRITTEN IN 2.0. The Version 1.0 example accepted WinBox (8291) and SSH (22) from any source on the WAN interface. That example no longer matches the posture this guide teaches, and in the MikroTik era, it describes the exact exposure being exploited. It has been replaced.

The model to implement is: WAN to router management → DROP. Management VPN or VLAN → ALLOW. Trusted management source list → ALLOW, for the specific service required. Everything else → DROP.

/interface list add name=WAN

/interface list add name=LAN

/interface list member add list=WAN interface=ether1

/interface list member add list=LAN interface=bridge

/ip firewall address-list add list=mgmt address=192.168.2.0/24 comment=”NOC / jump hosts”

/ip firewall filter

add chain=input connection-state=established,related,untracked action=accept comment=”established, related, untracked”

add chain=input connection-state=invalid action=drop comment=”drop invalid”

add chain=input protocol=icmp limit=50/5s,5:packet action=accept comment=”rate-limited ICMP”

add chain=input src-address-list=mgmt protocol=tcp dst-port=8291,22 action=accept comment=”mgmt: WinBox + SSH from trusted sources only”

add chain=input in-interface-list=LAN action=accept comment=”trusted internal”

add chain=input action=drop comment=”DROP everything else”

Mirror the whole policy for IPv6 under /ipv6 firewall filter. Use raw rules (/ip firewall raw, chain prerouting) to drop bogons and obvious abuse before connection tracking, which saves CPU under DDoS. Maintain address lists for management origins and for blocklists.

MikroTik firewall references:

MikroTik — Securing your router — the current vendor baseline; replaces the legacy wiki page cited in Version 1.0
MikroTik — First Time Configuration, including the default firewall
Unimus — Validating the security of your MikroTik routers network-wide
Protecting Routers, Switches, and Network Devices — the underlying access-list principles

Step 11 — Don’t let your MikroTik be used as a “DDoS proxy”

MikroTik’s proxy, SOCKS, UPnP, and related services can be turned on accidentally—or deliberately, by whoever took the device—turning the router into a powerful DDoS weapon or a node in someone’s proxy network. Combined with other RouterOS capabilities, the device becomes a bot in a threat actor’s botnet.

DO NOT LET MISCREANTS USE YOUR MIKROTIK DEVICE FOR CRIMINAL ACTIVITY.

/ip proxy set enabled=no

/ip socks set enabled=no

/ip upnp set enabled=no

/ip cloud set ddns-enabled=no update-time=no

/tool romon set enabled=no

MikroTik turns off most of these by default. Check whether they are on and turn them off manually anyway — these are precisely the features an attacker re-enables after a takeover. Step 14 shows how to lock them at the platform level so they cannot be re-enabled silently.

Step 12 — Start cleaning up your “compromised” router

This is where you find out. Version 1.0 told you to copy and delete suspicious objects. With confirmed exploitation in progress, that is not enough — this is now an incident response workflow: preserve → isolate → investigate → rebuild.

12.1 — Check the Flagged / device-mode state (patched v7 builds):

/system/device-mode/print ;# look for flagged: yes

/log print where message~”Flagged”

Remember: not flagged is not clean.

12.2 — Hunt the indicators regardless of the Flagged state:

/user print detail ;# ‘ops’ or any account you did not create

/log print where message~”-2″ ;# ssh:-2@ , login failure for user -2

/system scheduler print detail ;# unknown scripts, especially with fetch()

/system script print detail

/file print ;# unknown files

/ip socks print ; /ip proxy print ; /ip upnp print

/interface l2tp-client print ; /interface pptp-client print ; /ip ipsec print

/ip firewall nat print ; /ip firewall filter print

/ip dns print ;# changed resolvers

/tool sniffer print ; /ip traffic-flow target print ;# rogue TZSP / NetFlow export

/user ssh-keys print detail ;# keys you did not import

Legacy campaign artifacts worth checking at the same time: an L2TP client named lvpn; a firewall hole on TCP 5678 (Mēris era); a dstnat rule redirecting 449 to 80 (TrickBot era); SOCKS quietly enabled as a TCP redirector.

12.3 — If the device is flagged, shows IoCs, or ever had SSH public: treat it as compromised.

Isolate the device — drop the WAN, manage over a dedicated local or out-of-band port.
Preserve evidence first. Export logs and configuration (/export file=pre_recovery_state, /system sup-output name=supout.rif). Do not clear the Flagged marker before evidence is secured.
Report to your national CSIRT, and to Shadowserver if the device is in your ASN reporting scope.
Netinstall and rebuild from a trusted, verified configuration. Never restore a binary backup from the suspect device—rebuild from an audited .rsc template.
Rotate every secret that touched the device: admin passwords, SSH keys, WireGuard/IPsec secrets, RADIUS and TACACS secrets, SNMP communities, API tokens, certificates and private keys.
Only then, after physical verification, lift the Flagged state:

/system/device-mode/update flagged=no ;# requires a power-cycle or reset-button press

Unimus has published a useful companion with scripted checks: Validating the security of your MikroTik routers network-wide.

Step 13 — Legacy threats: TrickBot, Mēris and the abuse history

Read this as history, not as today’s emergency. CVE-2018-14847 is a 2018 WinBox-era bug; TrickBot and Mēris are legacy campaigns. They are distinct from the 2026 SSH chain — do not conflate them. They are kept here because they explain why MikroTik devices are so persistently attractive, and because the artifacts still turn up on long-lived devices.

Mēris (2021) — record application-layer DDoS: 17.2M rps against a Cloudflare customer and 21.8M rps against Yandex on 5 September 2021, from an estimated ~250,000 devices, mostly MikroTik gateways and routers (Qrator Labs). Used L2TP tunnels and SOCKS on ports 5678/2000. See MikroTik’s own Mēris post.
Dvinis — a twin botnet in the same MikroTik population (NETSCOUT ASERT).
TrickBot — MikroTik routers used as C2 proxies. Microsoft’s Section 52 documented the pattern in Uncovering TrickBot’s use of IoT devices in command-and-control infrastructure. The crews used default credentials, brute force, and CVE-2018-14847 against RouterOS versions older than 6.42 to read user.dat. The telltale rule redirects TCP port 449 to port 80:

/ip firewall nat print

;# chain=dstnat action=dst-nat to-addresses= to-ports=80 protocol=tcp dst-port=449

/ip firewall nat remove numbers=

The pattern is consistent: compromised MikroTik devices get repurposed as DDoS sources, C2 relays, and residential or anonymizing proxy nodes. As of this revision, no confirmed public attribution links MikroTik-compromised devices to a specific named botnet or proxy network. Treat any such claim as speculative until it is corroborated.

Step 14 — Use device-mode to take capabilities away (NEW)

This did not exist when Version 1.0 was written. RouterOS device-mode restricts what the platform can do at all — scheduler, fetch, SOCKS, proxy, bandwidth-test, traffic generator, packet sniffer, PPTP/L2TP, RoMON, SMB, containers, ZeroTier, and more. Changing it requires physical access (a power-cycle or reset-button press), which is exactly what makes it valuable.

The principle: a router cannot be abused through a feature disabled at the platform policy level. A device-mode profile that forbids scheduler, fetch, and SOCKS removes the attacker’s most common persistence and monetization paths even after a successful takeover.

/system/device-mode/print

/system/device-mode/update mode=enterprise;# requires physical confirmation

Choose the profile deliberately before enabling high-risk functions, and record it in your golden template. Device-mode is also the mechanism behind the Flagged state described earlier. It is v7-only; on v6, the equivalent assurance comes from Steps 7, 10, and 11.

Step 15 — Logging and remote syslog (NEW)

Ship logs off-box so the indicators survive a wipe, a reboot, or an attacker clearing the local log. Local logging alone left many MikroTik victims with nothing to investigate.

/system logging action add name=remote target=remote remote= remote-port=514

/system logging add topics=info,error,warning,critical,account,system action=remote

(Note: Create separate remote logging rules for info, warning, error, critical, account, and/or system as required. This also makes the policy understandable and testable.)

Alert on the MikroTik markers specifically: login failure for user -2, user … added by ssh:-2@, creation of a user named ops, any critical “Flagged” entry, and any account creation or configuration change outside a change window.

Step 16 — Anti-spoofing, BCP38/uRPF and DNS hardening (NEW)

Two controls that stop your device from harming everyone else — which is the whole point of a public-health exercise.

Anti-spoofing (RFC 2827 / BCP38). Every ISP edge and CPE should prevent spoofed source addresses from leaving its network:

/ip settings set rp-filter=strict ;# use loose where routing is asymmetric/multihomed

For IPv6, implement source-address validation with appropriate IPv6 firewall/prefix policy. MikroTik’s /ipv6 settings has no rp-filter property.

Where strict uRPF is impractical, use explicit egress filters that permit only your assigned prefixes and drop the rest.

DNS. Don’t let the router be a DNS DDoS reflector. If it is not a resolver:

/ip dns set allow-remote-requests=no

If it must serve LAN clients, keep allow-remote-requests=yes but restrict UDP/TCP 53 to internal subnets in the firewall, and consider DoH with a pinned certificate.

“enable DoH certificate verification (verify-doh-cert=yes) using the RouterOS trust store or an explicitly imported trusted CA.”\

Step 17 — Secure-by-default CPE for ISPs (NEW)

If you hand MikroTik CPEs to subscribers, they won’t patch them. That makes the exposure yours.

Step FINAL — Netinstall and start from scratch

The final step is the reality check. When you can no longer trust a router’s integrity, trying to identify and surgically remove every attacker modification provides far less assurance than rebuilding the device from known-good installation media. Netinstall reformats the device storage and writes clean binaries from a trusted release.

Install a fixed release—7.24.2, 7.23.5, or 6.49.21—then rebuild from your audited text configuration, not the suspect backup, and rotate every secret. Only a device you rebuilt yourself is a device you can reason about.

Monitoring: Shadowserver’s free daily reports

The Shadowserver Foundation provides free daily network reports to network owners and national CSIRTs, scoped by ASN, CIDR, and country. This is how you find out that your externally visible configuration doesn’t match your intended policy—an internal inventory can say management exposure is prohibited while Internet measurement says otherwise.

Join the Shadowserver Alliance. Become part of the community that collaborates, invests, and takes joint action to work “altruistically behind the scenes to make the Internet more secure for everyone.”

A practical order of operations: inventory → determine RouterOS version → identify Internet-exposed services → preserve evidence if suspicious → patch → inspect Flagged/logs/configuration → rebuild if compromise is suspected → rotate secrets → harden the management plane → disable unnecessary capabilities → verify externally with Shadowserver → monitor continuously.

Tools to check your MikroTik devices

Current

RouterOS’s own Flagged check — /system/device-mode/print on a patched build, plus the manual IoC hunt in Step 12. This is the only tooling that looks for MikroTik traces.
Shadowserver daily reports — external validation of what you are actually exposing (above).
CISA KEV catalog — cisa.gov/known-exploited-vulnerabilities-catalog, for prioritization and for the BOD 26-04 forensic-triage requirement.

Historical and specialist

These target older campaigns and do not detect MikroTik. They remain useful for understanding historical compromise, but verify maintenance status before relying on them — and do not let a clean result from any of them reassure you about 2026.

Vendor

MikroTik — Securing your router — the primary companion to this guide
MikroTik — First Time Configuration
MikroTik Security Announcements — subscribe; do not rely on release notes alone.
MikroTik — September 2026 vulnerability advisory
MikroTik — Device-mode and Flagged status
MikroTik — Netinstall

CERT / CSIRT

CERT Polska — Critical vulnerabilities in MikroTik RouterOS are being actively exploited — essential reading: IoCs, Flagged behavior, interim mitigations, evidence preservation, recovery
CERT Polska — Vulnerabilities in MikroTik RouterOS software — the six CVEs with CWEs and affected version ranges
CISA — KEV additions, 10 September 2026 (CVE-2026-67277, CVE-2026-86060; BOD 26-04)
Canadian Center for Cyber Security — Alert AL26-020
NCSC Netherlands national advisory, 8 September 2026
CERT.LV (Latvia) — confirmed 12 compromised devices nationally out of several thousand exposed; critical infrastructure operators notified from 3 September

Independent research and community hardening

Nick Pratley — Reversing MikroTik’s silent patch — source of the e=3 key-hygiene advice
Senki — How to secure MikroTik devices — the operators’ security toolkit home for this guide
LinITX — Securing your MikroTik RouterOS
Manito Networks — MikroTik router hardening
routeros-hardening — community hard

Watch: securing MikroTik devices

There is a YouTube playlist for securing MikroTik devices: MikroTik Router Security — How to keep control over your MikroTik devices. It is helpful to watch and listen to peers secure their devices. Taking action to protect your network is the most critical element.

Change log

Version	Date	Summary
1.0	24 October 2022	Original 13-step guide, written for the Mēris / TrickBot / CVE-2018-14847 threat environment.
2.0	14 September 2026	MikroTrick update. Added the September 2026 emergency section (six CVEs, fixed versions, IoCs, Flagged/device-mode, interim mitigations, exposure telemetry). Patch guidance now names exact builds and adds RouterBOOT. SSH port change demoted. Step 10 firewall example rewritten to default-drop. Step 12 rebuilt as an IR workflow. New Steps 14 (device-mode), 15 (logging), 16 (BCP38/uRPF and DNS), 17 (ISP CPE). WinBox 4 currency. Shadowserver MikroTik reports added. Legacy tools re-labelled. Links repointed from the retired wiki to help.mikrotik.com. Five new figures.

Sources, confidence and caveats

Vendor-confirmed: MikroTik advisory of 3 September 2026 — fixed versions 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21; the Flagged and device-mode mechanism; the WireGuard and SSH-exposure guidance.
CERT-reported, high confidence: CERT Polska (six CVEs, CWEs, version ranges, the -2 and ops IoCs, attacker IPs, exploitation from at least 2 September, AI-assisted discovery); the CISA KEV listing of 10 September 2026 under BOD 26-04, with a forensic-triage requirement and a 13 September remediation date for federal agencies; CERT.LV’s 12 confirmed national compromises; the NCSC-NL advisory; Canadian Cyber Centre AL26-020.
Measurement: Shadowserver Foundation (122,500 SSH-exposed; ~2.6M WinBox/btest; ~3M device identifications; country breakdown of 5 September 2026). Exposure counts are not vulnerability or compromise counts.
Independent, lower confidence: Nick Pratley’s silent-patch reverse engineering and the e=3 RSA-key hygiene recommendation; Shodan population totals; the historical botnet figures for Mēris, Dvinis, Mikro Typo and the OVHcloud event.
Contradiction — patch date. MikroTik’s advisory is dated 3 September and most reporting follows it, but the 7.25beta3 changelog carries a 2 September date. Treat 3 September as the coordinated public-patch date, with the beta a day earlier. Whether this technically qualifies as a zero-day is still disputed; exploitation from 2 September is not.
Contradiction — CVE-2026-67276 version range. CERT Polska lists it as “from 7.9 below 7.23.4,” not naming the v6 line, while the chained CVE-2026-86060 and CVE-2026-67277 list “from 6.0.0 below 6.49.21.” MikroTik shipped a 6.49.21 fix regardless — patch v6 devices.
Not verified: no New Zealand, Singapore, or Australia specific device counts for this campaign exist in any public source, and no CERT NZ, CSA Singapore/SingCERT or AusCERT/ACSC advisory on MikroTik was found as of 14 September 2026. (A “CSA” MikroTik note exists at labs.cloudsecurityalliance.org — that is the Cloud Security Alliance, not the Cyber Security Agency of Singapore.) You can pull per-country numbers directly from the Shadowserver dashboard, filtered by the Accessible SSH MikroTik tag or Device Identification.
Scope. This document is defensive only: hardening, detection, and remediation. It contains no exploit code or proof-of-concept detail.