Attackers Hijack MikroTik Routers Through Internet-Exposed SSH Without Authentication

1. Executive summary

Attackers are hijacking MikroTik routers whose SSH service is reachable from the internet, gaining full administrative control without authentication, per a CERT Polska warning published 5 September 2026. Successful attacks date to at least 2 September. The chain — dubbed "MikroTrick" by CERT Polska — combines two vulnerabilities; neither CERT's warning nor the disclosure identifies which two CVEs are involved or how they combine, and no verified reference data resolved for this item, so no CVSS, severity, or CISA-KEV status can be stated. No victim count or attacker identity is available; attribution is unconfirmed. MikroTik has shipped fixed RouterOS releases which CERT states prevent the observed attacks; immediate patching of internet-exposed MikroTik estate is the priority for EMEA financial services, particularly branch/edge and third-party-managed deployments.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 24: digital operational resilience testing — general requirements	The affected devices are internet-exposed edge routers whose management-plane exposure enabled unauthenticated takeover — a configuration-level weakness that external attack-surface testing would have surfaced.	Include internet-exposed MikroTik/RouterOS management interfaces (SSH, WWW/WWW-SSL, bandwidth-test) explicitly in the testing scope and threat-led testing cycle; verify exposure findings are remediated, not just reported.
DORA Art. 28: ICT third-party risk — general principles	MikroTik edge routers are commonly deployed or managed by connectivity/ISP third parties, and the vendor's own fix channel (RouterOS downloads) is the remediation path — the incident runs through both supplier patching and supplier-managed device configuration.	Confirm with network/connectivity providers which RouterOS versions they operate on your behalf, that they have applied the fixed releases, and that management-plane exposure restrictions are contractually required; capture this in third-party risk assessments.
DORA Art. 17: ICT-related incident management process	CERT Polska's guidance prescribes a specific incident workflow — evidence preservation before factory reset, configuration rebuild from trusted sources, credential rotation — that must be executed on suspected-compromised routers.	Ensure the incident runbook covers network-equipment compromise: log/config export and preservation, isolation, factory restore with verified rebuild, and rotation of device credentials and keys.

No NIS2 or UK NIS article is directly engaged by the specific facts of this item beyond generic incident/patching duties.

3. Technical analysis & attack chain

Confirmed steps (per CERT Polska, relayed via The Hacker News)

Reconnaissance/exposure: Attacker locates a MikroTik router with the SSH remote-access service reachable from the internet. Note: MikroTik's default firewall configuration blocks public access to management ports on home devices — exposed devices in the wild have had default rules altered or removed, or are non-default deployments.
Initial access: Attacker exploits the "MikroTrick" two-vulnerability combination against the exposed SSH service and gains full administrative control without authentication.
Post-compromise actions (per CERT's investigation guidance): Attacker activity observable via unexpected highly privileged "ops" accounts and account-creation log entries containing the string ssh:-2@.
Detection by the device: RouterOS's "Flagged" mechanism may fire when startup checks detect suspicious configuration; flagged entries are disabled and certain functions restricted.

What is and is not known

The vulnerabilities themselves are not identified. Neither CERT Polska's warning nor its vulnerability disclosure names the two CVEs forming the chain or explains how they combine to yield unauthenticated administrative control. No CVSS scores, CISA-KEV status, or affected-version list is present in the source material, and no verified reference data resolved for this item. Treat any third-party CVE attribution circulating elsewhere as unconfirmed until CERT or MikroTik publish specifics.
Zero-day status is unverified. The 7.25beta3 release notes carry a 2 September changelog date and the beta plus other initial fixes were announced 3 September; successful attacks date to at least 2 September. These dates do not establish whether a fix was publicly available before the attacks began.
No malware, C2, lateral movement, or exfiltration detail is present in the source material. Do not assume data theft; the confirmed impact is administrative takeover of the router.
No victim count and no attacker identity are given. Attribution is unconfirmed; no MITRE ATT&CK actor profile is available.

Confidence caveat: This advisory rests on a single vendor/CERT source (CERT Polska, relayed by The Hacker News). The two-flaw chain, the ssh:-2@ log artefact, and the fix efficacy claim are single-sourced; verify against CERT Polska's original advisory (Polish/English) before enforcement actions such as mass device isolation.

4. Mitigation & containment

P1 — within 24 hours

Inventory and patch. Identify all MikroTik RouterOS devices (including third-party/ISP-managed) and update to the fixed RouterOS releases listed in MikroTik's security update, using official RouterOS downloads. CERT states the fixes prevent the observed attacks. Note: 7.23.5 is a regression fix addressing an IPv6 DHCP problem introduced in 7.23.4 while retaining the security update — devices on 7.23.4 should move to 7.23.5, not stay on 7.23.4.
Kill management-plane exposure now if patching is delayed. On every internet-reachable MikroTik device, disable exposed services or restrict access to trusted management networks — specifically SSH, WWW/WWW-SSL, and bandwidth-test. These temporary restrictions cover the broader vulnerability set and do not replace the update.
Restrict outbound TLS/SSH from unpatched devices. Do not initiate TLS connections or use RouterOS's built-in SSH client from an unpatched device (per CERT guidance — implies the vulnerability set may extend beyond inbound SSH).

P2 — within 72 hours

Post-patch compromise check. After updating, check logs and run: /system/device-mode/print to inspect Flagged status. Even without a warning, inspect configuration for unknown users, scripts, and other unrecognised changes. Investigate any unexpected highly privileged ops accounts and account-creation log entries containing ssh:-2@.

P3 — within 7 days

Compromise recovery (if warning, logs, or configuration suggest compromise). Do not clear Flagged before preserving evidence and completing analysis: - Isolate the router from the network; preserve logs and configuration before resetting (CERT's preservation guide, in Polish, covers export/download). - Restore factory settings and rebuild from a trusted, verified configuration. Do not blindly restore a full backup from the potentially compromised device. - Change passwords, keys, and other secrets in use.
Harden the estate. Enforce management-access restriction to trusted networks as standing policy for all edge devices; add MikroTik RouterOS version currency to asset-management and third-party contract requirements.

5. Indicators of compromise

No atomic indicators of compromise (IPs, domains, hashes, filenames) are available in the source material. The source describes observable behaviours only.

Behavioural indicators

Behaviour	Where to observe	Confidence
Unexpected highly privileged "ops" accounts on the router	RouterOS user configuration (`/user print`)	High — direct CERT guidance
Account-creation log entries containing the string `ssh:-2@`	RouterOS system logs	High — direct CERT guidance
RouterOS "Flagged" status — startup checks detected suspicious configuration; flagged entries disabled, certain functions restricted	`/system/device-mode/print`; device logs	High — vendor-documented mechanism cited by CERT
Unknown users, scripts, or unrecognised configuration changes	RouterOS configuration review post-update	Medium — general compromise-check guidance

6. Detection

No file, network, or process artefacts suitable for YARA are present in the source material. The log string below supports a Sigma-style rule for organisations centralising RouterOS syslog.

title: MikroTik RouterOS Suspicious SSH Account Creation (MikroTrick)
id: 7c2f1a44-9b3e-4d86-a1f2-5e6b8c0d9a71
status: experimental
description: Detects account-creation log entries flagged by CERT Polska as indicative of MikroTrick SSH hijack compromise.
references:

  - https://thehackernews.com/2026/09/attackers-hijack-mikrotik-routers.html
author: Adverse Trace
date: 2026-09-06
logsource:
  category: application
  product: mikrotik_routeros
detection:
  selection:
    message|contains: 'ssh:-2@'
  condition: selection
falsepositives:

  - Unknown; treat any match on a MikroTik device as compromise until investigated.
level: high

Note: the ssh:-2@ string is single-sourced (CERT Polska via The Hacker News). Validate against your own RouterOS log formats before deploying to production.

7. Sources

The Hacker News — "Attackers Hijack MikroTik Routers Through Internet-Exposed SSH Without Authentication" — https://thehackernews.com/2026/09/attackers-hijack-mikrotik-routers.html — 2026-09-06
CERT Polska attack warning (referenced; published 2025-09-05 per source — original advisory not directly reviewed) — via The Hacker News, above
MikroTik security update, default firewall explanation, and Flagged status guidance (referenced) — via The Hacker News, above

8. Adverse Trace position

Severity cannot be scored from the available material — no CVE identifiers, CVSS scores, or CISA-KEV status are published for the "MikroTrick" chain, and we will not invent them; operationally, however, unauthenticated full administrative takeover of internet-exposed edge routers with confirmed in-the-wild attacks since at least 2 September warrants P1 response regardless of score. Client impact concentrates on any MikroTik RouterOS device with SSH, WWW/WWW-SSL, or bandwidth-test reachable from the internet — including ISP- or partner-managed branch connectivity — where a compromised router sits on the trust boundary and can intercept, redirect, or originate traffic. The entire technical picture is single-sourced (CERT Polska via The Hacker News): the two-flaw chain is unnamed, zero-day status is unverified, and attribution is unconfirmed. We will update this advisory when CERT Polska or MikroTik publish the constituent CVEs, affected-version ranges, and any IoCs; until then, act on exposure reduction and patching, which are effective regardless of the underlying mechanism.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.