MikroTik RouterOS SSH Authentication Bypass Under Active Exploitation — Assume Compromise, Hunt for Rogue Accounts

Late last week, MikroTik released a patch for a critical SSH authentication bypass vulnerability in RouterOS — and according to the SANS Internet Storm Center, exploitation was already underway before the fix shipped. That sequencing matters enormously for defenders: this is not a "patch and move on" event. The guidance from the front lines is unambiguous — assume compromise.

The post-exploitation behavior being observed makes this worse. Attackers who gained access to vulnerable devices are creating new local user accounts on the routers. This is a classic persistence play: even after you patch the vulnerability and close the SSH bypass, the attacker's planted credentials still work. A patched device with a rogue admin account is still an attacker-owned device.

If you operate MikroTik gear anywhere in your environment — and given its prevalence in ISP, MSP, hospitality, and SMB edge deployments, many enterprises have MikroTik devices they don't even know about — this is a drop-everything triage event. Edge routers are high-value targets: they see all your traffic, they can redirect or intercept it, and they are almost never covered by EDR.

Technical Analysis

What the Vulnerability Enables

The flaw is an SSH authentication bypass in RouterOS. An attacker with network reachability to the SSH service (TCP/22, or a custom port if you've moved it) can authenticate without valid credentials, gaining access to the device. RouterOS is Linux-based, and administrative access to a MikroTik router effectively means full control: traffic interception and redirection, firewall manipulation, DNS tampering, packet capture, and a pivot point into internal networks.

Exploitation Status

• Confirmed active exploitation in the wild. The SANS ISC reports the vulnerability was being exploited before the patch was available.
• Persistence mechanism observed: creation of new local accounts on compromised devices to survive patching.
• No CVE identifier was included in the initial reporting at time of writing; track the SANS ISC diary entry and MikroTik's release notes for formal assignment.

The Attack Chain

1. Reconnaissance: Mass internet scanning for exposed MikroTik SSH services (MikroTik devices are trivially fingerprintable via banner and TCP/IP stack behavior).
2. Initial access: SSH authentication bypass against unpatched RouterOS.
3. Persistence: Creation of a new local user account (often in the full group) with attacker-controlled credentials or an SSH key.
4. Post-exploitation: Firewall/NAT manipulation, traffic redirection, DNS poisoning, or use of the device as a proxy/C2 node — consistent with historical MikroTik botnet activity (Mēris, TrickBot infrastructure, VPNFilter-class operations).

Why "Patch Now" Is Only Step One

The critical defensive insight in this campaign is that remediation and eradication are separate operations. Patching closes the door; it does not evict anyone already inside. Any device that was internet-exposed and unpatched during the exploitation window must be treated as compromised until proven otherwise. That means account auditing at minimum, and ideally a full configuration export, review, and — for high-confidence compromise — a factory reset with clean configuration restore and credential rotation.

Detection & Response

The most reliable detection surface here is the RouterOS device itself: user account inventories, SSH login logs, and configuration changes. Forward RouterOS syslogs to your SIEM — if you aren't doing this today, that gap is part of the problem.

Sigma Rules

The following rules target Sysmon/network visibility around SSH to MikroTik devices and RouterOS syslog events ingested into a SIEM. The second rule assumes RouterOS logs are ingested via a generic syslog channel — adapt the logsource to your pipeline.

---
title: Suspicious SSH Connection to MikroTik Edge Device from External Source
id: 8b2f4a71-3c9e-4d58-a761-9e0b2c4f6a11
status: experimental
description: Detects inbound SSH connections to identified MikroTik routers from non-management IP addresses, consistent with exploitation of the RouterOS SSH authentication bypass.
references:
  - https://isc.sans.edu/diary/rss/33314
  - https://attack.mitre.org/techniques/T1021/004/
author: Security Arsenal
date: 2026/09/07
tags:
  - attack.lateral_movement
  - attack.initial_access
  - attack.t1021.004
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort:
      - 22
      - 2222
    Initiated: 'true'
  filter_management_hosts:
    SourceIp|cidr:
      - '10.0.0.0/8'
      - '192.168.0.0/16'
  condition: selection and not filter_management_hosts
falsepositives:
  - Legitimate remote administration over SSH — maintain an allowlist of approved management source IPs and tune the filter
level: high
---
title: RouterOS User Account Creation via Syslog
id: 3f7c1d92-8a45-4e6b-b209-5d8e3a7c2b44
status: experimental
description: Detects RouterOS syslog events indicating creation of a new local user account — the observed persistence mechanism in active MikroTik SSH bypass exploitation.
references:
  - https://isc.sans.edu/diary/rss/33314
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/09/07
tags:
  - attack.persistence
  - attack.t1136
logsource:
  product: linux
  service: syslog
detection:
  selection:
    Message|contains:
      - 'user added'
      - 'added by'
      - 'user '
    Message|contains:
      - 'add'
  condition: selection
falsepositives:
  - Legitimate administrator account provisioning — correlate with change tickets and expected admin sessions
level: critical

KQL — Microsoft Sentinel / Defender

This query hunts across ingested RouterOS syslog (via CEF/Syslog connector) and network session data for the two key behaviors: anomalous SSH logins to MikroTik devices and user account creation events.

let Lookback = 14d;
// Part 1: RouterOS syslog events indicating user account creation or suspicious login activity
let AccountEvents =
Syslog
| where TimeGenerated > ago(Lookback)
| where ProcessName has_any ("system", "account") or SyslogMessage has "user"
| where SyslogMessage has_any ("user added", "added by", "logged in")
| project TimeGenerated, Computer, HostIP, SyslogMessage, SeverityLevel;
// Part 2: Inbound SSH sessions to network devices from external/rare sources (requires firewall or CEF feed)
let SshSessions =
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where DestinationPort in (22, 2222)
| where DeviceAction in ("permit", "allow", "accept") or isnull(DeviceAction)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), ConnectionCount=count()
  by SourceIP, DestinationIP, DestinationPort
| where SourceIP !startswith "10." and SourceIP !startswith "192.168."
| extend SshAnomaly = true;
AccountEvents
| extend EventType = "RouterOS account/login event"
| union (SshSessions | extend EventType = "External SSH session to device")
| sort by TimeGenerated desc

Velociraptor VQL

Routers don't run Velociraptor, but jump boxes and management workstations do. If a compromised router was used to pivot internally, or an attacker used valid credentials harvested from a management host, hunt for unusual outbound SSH from endpoints toward network infrastructure.

-- Hunt for endpoints initiating SSH connections to network infrastructure,
-- which may indicate pivoting from compromised MikroTik devices or admin host misuse
SELECT Pid,
       Name,
       CommandLine,
       Username,
       Netstat.RemoteIP AS RemoteIP,
       Netstat.RemotePort AS RemotePort,
       Netstat.Status AS ConnStatus
FROM netstat()
WHERE RemotePort = 22
  AND ConnStatus =~ 'ESTABLISHED'
  AND NOT RemoteIP =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)'  -- flag non-RFC1918 SSH targets

Remediation & Verification Script

Run this against your RouterOS inventory via SSH or adapt for your RMM/config management. It audits local accounts, flags unexpected users, checks the RouterOS version, and dumps critical configuration surfaces for review. Establish your known-good account baseline first — the detection logic is only as good as your inventory.

#!/bin/bash
# MikroTik RouterOS compromise triage — run from a management host with SSH access
# Usage: ./mikrotik_triage.sh <router_ip> <admin_user>
# Requires: sshpass or key-based SSH auth to the device

TARGET="$1"
ADMIN="$2"
OUTDIR="mikrotik_triage_${TARGET}_$(date +%Y%m%d)"
mkdir -p "$OUTDIR"

echo "[+] Collecting RouterOS version and identity..."
ssh "${ADMIN}@${TARGET}" '/system resource print; /system identity print' > "$OUTDIR/version.txt"

echo "[+] Dumping local user accounts — REVIEW FOR UNAUTHORIZED USERS..."
ssh "${ADMIN}@${TARGET}" '/user print detail' > "$OUTDIR/users.txt"

echo "[+] Dumping SSH keys bound to accounts (common persistence vector)..."
ssh "${ADMIN}@${TARGET}" '/user ssh-keys print detail' > "$OUTDIR/ssh_keys.txt"

echo "[+] Checking for suspicious scheduled tasks and scripts (persistence)..."
ssh "${ADMIN}@${TARGET}" '/system scheduler print detail' > "$OUTDIR/scheduler.txt"
ssh "${ADMIN}@${TARGET}" '/system script print detail' > "$OUTDIR/scripts.txt"

echo "[+] Reviewing recent login history in logs..."
ssh "${ADMIN}@${TARGET}" '/log print where message~"logged in" or message~"user"' > "$OUTDIR/login_log.txt"

echo "[+] Checking firewall/NAT for attacker-added redirect rules..."
ssh "${ADMIN}@${TARGET}" '/ip firewall nat print detail; /ip firewall filter print detail' > "$OUTDIR/firewall.txt"

echo "[+] Checking DNS settings for tampering (static entries, rogue resolvers)..."
ssh "${ADMIN}@${TARGET}" '/ip dns print; /ip dns static print detail' > "$OUTDIR/dns.txt"

echo "[+] Checking active connections and listening services..."
ssh "${ADMIN}@${TARGET}" '/ip service print detail' > "$OUTDIR/services.txt"

echo ""
echo "====================================================="
echo " TRIAGE COMPLETE. Review output in: $OUTDIR"
echo " NEXT STEPS:"
echo "  1. Compare users.txt against your known-good baseline"
echo "  2. Any unknown account/key/script = assume compromise"
echo "  3. Upgrade RouterOS to the latest patched release NOW"
echo "  4. If compromised: export config, netinstall/factory reset,"
echo "     restore known-good config, rotate ALL credentials"
echo "  5. Restrict SSH to a management ACL and disable if unused"
echo "====================================================="

Remediation

Immediate Actions (Today)

1. Inventory every MikroTik device in your environment, including unmanaged/shadow deployments. Scan your own public IP space for RouterOS fingerprints — assume the attackers already have.
2. Upgrade RouterOS to the latest patched release from MikroTik's official download page and release notes. Do not delay — exploitation predates the patch.
3. Audit all local user accounts on every device. Remove any account you cannot attribute to a documented administrative action. Check for attacker-added SSH keys under /user ssh-keys — keys persist independently of password changes.
4. Review /system scheduler and /system script for persistence. Historical MikroTik compromises have abused both to survive reboots and firmware upgrades.

If Compromise Is Suspected

Per the ISC guidance — assume compromise — for any device that was internet-exposed and unpatched during the exploitation window:

• Export the current configuration for forensic preservation, not for blind restore.
• Perform a factory reset / Netinstall re-image of the device. Configuration-level "cleanup" on a router you don't trust is not eradication.
• Restore from a known-good configuration backup predating the exploitation window, or rebuild manually after line-by-line review.
• Rotate all credentials associated with the device and any credentials reachable from it (the router saw your management traffic).

Permanent Hardening

• Never expose RouterOS management interfaces (SSH, Winbox 8291, API, WebFig) to the internet. Restrict via input filter ACLs to dedicated management networks/VPN only.
• Disable unused services under /ip service. If you don't need SSH, turn it off.
• Forward RouterOS syslog to your SIEM and alert on account creation, login anomalies, and configuration changes.
• Implement automated configuration drift monitoring — an unexpected diff on an edge device is often the first and only signal.

References

• SANS Internet Storm Center: Critical MikroTik Vulnerability
• MikroTik official download portal and RouterOS changelog (check for the specific patched version applicable to your release train — current/long-term)

Edge infrastructure is the soft underbelly of most security programs — no EDR, rarely logged, always internet-facing. This campaign is the latest reminder that your perimeter devices need the same lifecycle rigor as your endpoints: inventory, patching, telemetry, and a plan for what to do when patching isn't enough.

Related Resources

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