MikroTik Routers Hijacked via Internet-Exposed SSH Without Authentication — Detection and Remediation Guide

On September 5, 2026, CERT Polska published an urgent warning: attackers are actively compromising MikroTik routers whose Secure Shell (SSH) remote-access service is reachable from the public internet — and they are doing it without authentication. Successful intrusions date back to at least September 2. Once inside, the attackers gain full administrative control of the device. At the time of the warning's publication, no confirmed victim count was available, which typically means the campaign is either early-stage or under-reported.

If you operate MikroTik RouterOS devices — as an ISP, MSP, enterprise edge gateway, VPN concentrator, or branch router — treat this as an active-compromise scenario, not a patching reminder. Edge devices sit at the trust boundary of your network. A hijacked router means intercepted traffic, redirected DNS, credential theft from transit sessions, lateral movement staging, and a persistent foothold that most EDR platforms cannot see.

This post breaks down what we know, how to hunt for compromise, and exactly how to remediate.

Technical Analysis

What Is Affected

• Product: MikroTik RouterOS devices (routers, switches, and CPE hardware running RouterOS).
• Affected component: The SSH remote-access service (/ip service ssh) when exposed to the internet.
• Attack prerequisite: The device must have its SSH service reachable from an untrusted network. Devices with SSH restricted to management VLANs or disabled entirely are not exposed to this attack path as described.
• Impact: Full administrative control without authentication. At the time of CERT Polska's warning, no CVE identifier or specific RouterOS version range had been published. Until MikroTik issues an advisory with fixed version numbers, assume any RouterOS version with internet-exposed SSH is at risk.

How the Attack Works — Defender's View

Based on the CERT Polska reporting, the attack chain looks like this:

1. Discovery: Attackers scan the internet (or leverage scan datasets like Shodan/Censys) for MikroTik devices with TCP/22 open. MikroTik SSH banners are fingerprintable, and MikroTik has historically been one of the most-scanned edge device families on the internet.
2. Authentication bypass: Rather than brute-forcing credentials, attackers exploit a flaw in the SSH service to gain administrative access without any valid credentials. This distinguishes the campaign from the routine password-spraying and botnet-enlistment activity MikroTik devices face daily.
3. Post-compromise: With full admin control, attackers can create new accounts, add SSH public keys, modify firewall rules, enable the packet sniffer or proxy, schedule persistent scripts, and pivot into the internal network. Historical MikroTik botnets (e.g., the large-scale RouterOS conscription campaigns of past years) demonstrate that attackers commonly use compromised devices as proxy infrastructure and C2 relays.

Exploitation Status

• Confirmed active exploitation in the wild — CERT Polska confirmed successful attacks beginning at least September 2, 2026.
• No CVE assigned as of the warning's publication. Do not wait for a CVE identifier to act.
• CISA KEV status: Not listed at the time of writing; monitor the KEV catalog daily, as MikroTik flaws are historically added quickly once weaponized.

The absence of an assigned CVE and patch details means your only reliable mitigations right now are exposure reduction and compromise detection.

Detection & Response

Where to Look

MikroTik devices are network appliances — you will not get EDR telemetry from them. Your detection strategy depends on:

1. RouterOS remote syslog forwarded to your SIEM (configure /system logging action to send to your collector if you have not already — this is non-negotiable for forensic readiness).
2. Firewall/NetFlow telemetry for connections to and from the router.
3. RouterOS configuration state — user accounts, SSH keys, scheduled scripts, firewall rule changes.

SIGMA Rules

The following rules assume RouterOS syslogs are being ingested (as generic syslog or via a MikroTik parser). Tune field names to your pipeline.

---
title: MikroTik RouterOS Login from External or Untrusted Source
tid: 3f8c2a91-7b44-4e1d-9a53-2c1d8f6b4e77
tstatus: experimental
description: Detects successful SSH or administrative logins to MikroTik RouterOS devices from non-management source addresses. Relevant to the September 2026 CERT Polska warning on unauthenticated SSH hijacking of internet-exposed MikroTik routers.
references:
  - https://thehackernews.com/2026/09/attackers-hijack-mikrotik-routers.html
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/09/08
tags:
  - attack.initial_access
  - attack.t1078
  - attack.t1133
logsource:
  product: mikrotik
  service: system
detection:
  selection:
    Message|contains:
      - 'logged in'
      - 'login failure'
  filter_mgmt_subnets:
    Message|contains:
      - 'from 10.0.'
      - 'from 10.10.'
      - 'from 192.168.'
  condition: selection and not filter_mgmt_subnets
falsepositives:
  - Legitimate remote administration from unapproved subnets — tighten your allowed source list
level: high
---
title: MikroTik RouterOS New User Account or SSH Key Added
tid: 9d4e1b72-3a58-4c2f-b861-7f3a9d2c5e18
tstatus: experimental
description: Detects creation of new user accounts or addition of SSH public keys on RouterOS devices, a common persistence mechanism following router compromise via exposed SSH.
references:
  - https://thehackernews.com/2026/09/attackers-hijack-mikrotik-routers.html
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/09/08
tags:
  - attack.persistence
  - attack.t1136.001
  - attack.t1098
logsource:
  product: mikrotik
  service: system
detection:
  selection:
    Message|contains:
      - 'user added'
      - 'added by'
      - 'ssh key'
      - 'imported'
  condition: selection
falsepositives:
  - Legitimate administrator provisioning — correlate with change tickets
level: high
---
title: MikroTik RouterOS Scheduler or Script Created for Persistence
tid: 5b2f7e34-1c96-4d3a-a248-8e6b1c4f9a32
tstatus: experimental
description: Detects creation of RouterOS scheduler entries or system scripts, a known persistence and execution mechanism abused after router compromise.
references:
  - https://thehackernews.com/2026/09/attackers-hijack-mikrotik-routers.html
  - https://attack.mitre.org/techniques/T1053/
author: Security Arsenal
date: 2026/09/08
tags:
  - attack.persistence
  - attack.execution
  - attack.t1053
logsource:
  product: mikrotik
  service: system
detection:
  selection:
    Message|contains:
      - 'script'
      - 'scheduler'
      - 'scheduled'
  filter_known_admin:
    Message|contains:
      - 'by admin from 192.168.'
  condition: selection and not filter_known_admin
falsepositives:
  - Backup or monitoring scripts deployed by administrators
level: medium

KQL — Microsoft Sentinel / Defender

Assuming RouterOS syslogs are ingested into the Syslog or CommonSecurityLog table (via a Linux syslog collector with the Azure Monitor agent), this hunt surfaces successful logins to MikroTik devices from outside your management ranges, plus persistence indicators. Adjust the management prefix list to your environment.

// Hunt: MikroTik RouterOS logins from untrusted sources + persistence artifacts
// Relevant to CERT Polska Sept 2026 warning — unauthenticated SSH hijack of MikroTik routers
let mgmt_prefixes = dynamic(["10.0.", "10.10.", "192.168."]);
let lookback = 14d;
Syslog
| where TimeGenerated > ago(lookback)
| where Computer has_any ("mikrotik", "router") or ProcessName has_any ("mikrotik", "routeros") or SyslogMessage has "MikroTik"
| where SyslogMessage has "logged in"
| extend SourceIP = extract(@'from ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})', 1, SyslogMessage)
| where isnotempty(SourceIP)
| where not(SourceIP has_any (mgmt_prefixes))
| project TimeGenerated, Computer, SourceIP, SyslogMessage
| order by TimeGenerated desc
;
// Persistence hunt: user/key/script creation on RouterOS devices
Syslog
| where TimeGenerated > ago(lookback)
| where SyslogMessage has_any ("user added", "ssh key", "scheduler", "script")
| where Computer has_any ("mikrotik", "router") or SyslogMessage has "MikroTik"
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc

If your MikroTik devices sit behind firewalls logging to CommonSecurityLog (CEF), hunt inbound SSH connection attempts to the routers as well:

// Inbound internet SSH connections destined for MikroTik edge devices
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationPort == 22
| where DeviceProduct has_any ("firewall", "paloalto", "fortigate", "checkpoint")
| where SourceIP !startswith "10." and SourceIP !startswith "192.168." and SourceIP !startswith "172.16."
| summarize ConnectionCount = count(), DistinctSources = dcount(SourceIP) by DestinationIP, DestinationPort, DeviceAction
| order by ConnectionCount desc

Velociraptor VQL

Use VQL against your syslog collectors or jump hosts to hunt for MikroTik compromise artifacts in forwarded router logs, and to identify endpoints that have recently established outbound SSH sessions to routers (useful for scoping admin access that may have been abused).

-- Hunt syslog collector logs for MikroTik compromise indicators
-- (untrusted logins, user creation, SSH key import, scheduler creation)
LET log_glob = 'C:/Logs/Network/**/*.log'
SELECT FullPath, Line,
       parse_string_with_regex(string=Line,
         regex='from (?P<Src>[0-9.]+)').Src AS SourceIP
FROM foreach(
  row={ SELECT FullPath FROM glob(globs=log_glob) },
  query={
    SELECT FullPath, Line
    FROM parse_lines(filename=FullPath, accessor='auto')
    WHERE Line =~ 'logged in|user added|ssh key|scheduler|script added'
})
WHERE SourceIP AND NOT (SourceIP =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)')

-- Identify endpoints with recent outbound SSH connections to router IPs
SELECT Pid, Name, Path, DestIp, DestPort, State
FROM netstat()
WHERE DestPort = 22
  AND State =~ 'ESTAB'
  AND NOT (DestIp =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)')

Remediation / Verification Script

Run this from a management workstation with SSH access to each RouterOS device (or via Winbox terminal). It audits exposure, accounts, persistence artifacts, and applies hardening. Review before running in production — the hardening section restricts SSH to a management subnet.

#!/bin/bash
# MikroTik RouterOS SSH Exposure Audit & Hardening
# Context: CERT Polska Sept 2026 — unauthenticated SSH hijack of internet-exposed MikroTik routers
# Usage: adjust ROUTER_IP, ADMIN_USER, and MGMT_SUBNET, then run against each device.

ROUTER_IP="192.0.2.1"
ADMIN_USER="netadmin"
MGMT_SUBNET="10.10.99.0/24"

SSH="ssh -o BatchMode=yes ${ADMIN_USER}@${ROUTER_IP}"

echo "===== 1. Current RouterOS version and identity ====="
$SSH "/system resource print; /system identity print"

echo "===== 2. Audit IP services — SSH, Winbox, API, WWW exposure ====="
$SSH "/ip service print detail"

echo "===== 3. Audit user accounts for unknown/unauthorized entries ====="
$SSH "/user print detail"

echo "===== 4. Audit SSH keys for unauthorized imports ====="
$SSH "/user ssh-keys print detail"

echo "===== 5. Audit persistence: scheduler, scripts, files ====="
$SSH "/system scheduler print detail"
$SSH "/system script print detail"
$SSH "/file print"

echo "===== 6. Check recent logins in local log ====="
$SSH "/log print where message~\"logged in\""

echo "===== 7. HARDEN: restrict SSH to management subnet only ====="
$SSH "/ip service set ssh address=${MGMT_SUBNET} port=22"

echo "===== 8. HARDEN: disable unused management services ====="
$SSH "/ip service disable telnet,ftp,www,api,api-ssl,www-ssl"

echo "===== 9. HARDEN: restrict Winbox to management subnet ====="
$SSH "/ip service set winbox address=${MGMT_SUBNET}"

echo "===== 10. HARDEN: input filter — drop WAN-side SSH before service rules ====="
$SSH "/ip firewall filter add chain=input protocol=tcp dst-port=22 in-interface-list=WAN action=drop comment=\"Block WAN SSH - SecArsenal Sept2026\" place-before=0"

echo "===== 11. Enable remote syslog for forensic readiness ====="
$SSH "/system logging action add name=siem-remote target=remote remote=10.10.99.10 remote-port=514"
$SSH "/system logging add topics=system,info action=siem-remote"
$SSH "/system logging add topics=critical action=siem-remote"

echo "===== 12. Check for and apply RouterOS updates ====="
$SSH "/system package update check-for-updates"
# Uncomment to install after reviewing available version:
# $SSH "/system package update install"

echo "===== Audit and hardening complete for ${ROUTER_IP} ====="

Remediation

Given that CERT Polska's warning does not yet map to a published CVE or fixed version, prioritize in this order:

1. Remove internet exposure of SSH immediately. This is the single most effective control and fully mitigates the attack as described. Either disable the SSH service outright if you do not need it, or bind it to a management subnet via /ip service set ssh address=<mgmt-subnet> and enforce a WAN-side input filter drop for TCP/22. Defense in depth matters — service binding and firewall rules should both be in place.
2. Inventory your exposure now. Query Shodan/Censys for your public IP ranges on port 22 with MikroTik fingerprints. Do not assume you know what is exposed — MSP and ISP environments routinely discover forgotten CPE.
3. Treat every previously internet-exposed device as potentially compromised. Because exploitation requires no authentication, there are no failed-login breadcrumbs. Audit user accounts, SSH keys, scheduler entries, scripts, firewall rule changes, and unexpected files. If anything is unexplained, export the config, factory-reset the device, and rebuild from a known-good backup — do not attempt in-place cleaning of a network device.
4. Update RouterOS. Check /system package update and apply the latest stable release. MikroTik historically ships fixes quickly once exploitation is public; monitor https://mikrotik.com/download and MikroTik's security announcements for the advisory addressing this issue.
5. Enable remote syslog on every RouterOS device and forward to your SIEM. Without centralized logs, you cannot retrospectively scope this campaign.
6. Rotate all credentials and SSH keys on any device that was internet-reachable on TCP/22 since September 2, 2026, including any credentials that transited the device (RADIUS secrets, PPPoE credentials, VPN pre-shared keys).
7. Monitor for follow-on activity. Compromised routers are used as proxies and C2 relays. Hunt your egress telemetry for the router initiating outbound connections it never made before — routers should almost never originate internet sessions on behalf of themselves.

Watch the CERT Polska advisory (cert.pl) and the CISA Known Exploited Vulnerabilities catalog for a CVE assignment and any federal remediation deadline. MikroTik flaws have a well-documented history of rapid mass exploitation once details leak — the window between disclosure and botnet conscription is measured in days.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub