MikroTik RouterOS SSH Exploitation (MikroTrick Chain): Detecting Rogue User "-2" and Emergency Remediation Guide

If you run MikroTik RouterOS with SSH (TCP/22) reachable from the internet, stop reading and go check your user list right now. Security researcher Costin Raiu has published a detailed technical breakdown of an actively exploited RouterOS SSH attack chain — dubbed MikroTrick — that has been a live security issue since September 2. Attackers are gaining shell access to edge routers and, in confirmed intrusions, leaving behind a telltale artifact: an SSH user literally named -2.

I've led IR engagements where compromised MikroTik and other edge devices served as the initial foothold, the C2 relay, and the persistence layer — all three at once. Edge routers are the perfect hide: no EDR, rarely logged centrally, implicitly trusted, and almost never rebuilt. If your RouterOS device was running a vulnerable version with SSH exposed during this campaign window, assume compromise until you prove otherwise. That means credential rotation, config review, and a hunt for unauthorized users — not just a firmware upgrade and a pat on the back.

What We Know: The MikroTrick Attack Chain

Affected products: MikroTik RouterOS devices (CHR, x86, ARM, MIPS — the full RouterBOARD/CCR/CRS/RB line running RouterOS) with the SSH service enabled and reachable by attackers.

Patched versions (upgrade immediately):

• RouterOS 7.24.2 (v7 current track)
• RouterOS 7.23.5 (v7 long-term track)
• RouterOS 6.49.21 (v6 long-term track)

No CVE identifier has been published in the public reporting for this chain as of this writing. Do not wait for one. Active exploitation does not pause for MITRE's assignment queue, and MikroTik has a long history of device-level flaws being mass-exploited within days of disclosure.

How the attack works (defender's view): The MikroTrick chain targets the RouterOS SSH daemon. Exploitation results in unauthorized interactive access to the device, after which operators establish persistence — the most visible artifact being a rogue local account named -2. That username is not accidental: a leading-dash username is a classic Unix parsing trick. Tools and scripts that pass the username as an argument without proper quoting or -- terminators can misinterpret -2 as a flag, causing enumeration and cleanup commands to silently fail or behave unpredictably. It's a small, deliberate piece of tradecraft designed to frustrate sloppy administrators and automated hygiene scripts.

Post-exploitation on compromised MikroTik devices in prior campaigns has typically included:

• Creation of backdoor admin accounts and SSH key injection (/user ssh-keys import)
• Scheduled scripts (/system scheduler) that re-fetch payloads or re-open access
• SOCKS proxy configuration turning the router into a traffic relay for the operator's broader operations
• Packet sniffer and firewall rule modifications for traffic interception and covert channels
• Modification of /ip firewall and /ip proxy to blend malicious flows into legitimate traffic

Exploitation status: Confirmed active exploitation in the wild since at least September 2, with public technical analysis available. Treat public analysis as a green light for copycat mass scanning — the window between "detailed breakdown published" and "internet-wide opportunistic exploitation" for edge devices is routinely measured in hours.

Why Edge Devices Demand a Different IR Posture

Your routers don't run your EDR agent. They don't forward process telemetry to Sentinel. Most organizations ship, at best, syslog — and many MikroTik deployments don't even have remote logging configured, meaning the evidence of compromise lives only in volatile device memory and dies on reboot.

This is exactly why attackers love them, and exactly why your response must be evidence-driven and fast:

1. Capture state before you patch. Upgrading RouterOS reboots the device and can destroy forensic artifacts. Export the config, dump the user list, firewall rules, scheduler jobs, scripts, and logs first.
2. Check for the -2 user — but don't stop there. Mature operators will have rotated to less obvious account names. Audit every account, every SSH key, every scheduler entry.
3. Rotate everything. Any credential, API secret, or private key that ever lived on or transited that device is suspect.

Detection & Response

Sigma Rules

These rules target the two highest-fidelity observables: SSH authentication events involving the -2 account, and RouterOS log lines indicating user creation or SSH key import. Deploy them against your syslog pipeline (any SIEM ingesting MikroTik remote syslog or Linux auth.log from jump hosts that touch the routers).

---
title: MikroTik MikroTrick - SSH Authentication as Rogue User -2
id: 9c1e4a72-3b6d-4f58-a2c7-7d8e9f0a1b2c
status: experimental
description: Detects SSH authentication events for the username '-2', a known persistence artifact of the MikroTrick RouterOS exploitation chain. Matches sshd logs on any host and forwarded MikroTik syslog.
references:
  - https://securityaffairs.com/198538/security/your-mikrotik-router-may-already-be-compromised-look-for-ssh-user-2.html
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.t1136.001
  - attack.t1078
logsource:
  product: linux
  service: sshd
detection:
  selection:
    - 'user -2'
    - 'user "-2"'
    - 'for -2 from'
    - "Invalid user -2"
  condition: selection
falsepositives:
  - None expected; a literal '-2' username is not legitimate in any standard deployment
level: critical
---
title: MikroTik RouterOS Account or SSH Key Manipulation via Syslog
id: 4f2b8d61-9a3e-4c17-b5d2-6e7f8a9b0c1d
status: experimental
description: Detects RouterOS syslog events indicating local user creation, user modification, or SSH key import - common persistence actions following MikroTrick exploitation.
references:
  - https://securityaffairs.com/198538/security/your-mikrotik-router-may-already-be-compromised-look-for-ssh-user-2.html
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.t1136.001
  - attack.t1098
logsource:
  product: linux
  service: syslog
detection:
  selection_user:
    - 'user added'
    - 'user changed'
    - 'added user'
  selection_keys:
    - 'ssh-keys'
    - 'ssh key'
    - 'public key added'
  selection_schedule:
    - 'scheduler'
    - 'script added'
    - 'script changed'
  condition: 1 of selection_*
falsepositives:
  - Legitimate RouterOS administration; alert only when source user or time window is unexpected, or when correlated with new/unknown accounts
level: high

A note on tuning: the second rule will fire on legitimate administration. That's acceptable — the value is in correlation. A user-creation event on a router that hasn't been touched in six months, at 03:00 local time, from a source you don't recognize, is your breach. Enrich with your CMDB's expected admin source IPs.

Sentinel / Defender KQL

MikroTik logs arrive in Sentinel via the Syslog or CommonSecurityLog (CEF) tables depending on your collector. This query hunts both the -2 artifact and broader persistence signals across both schemas:

let Lookback = 30d;
let MikroTrickPatterns = dynamic(["user -2", "for -2 from", "Invalid user -2", "ssh-keys", "user added", "user changed", "script added", "scheduler"]);
union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(Lookback)
    | where SyslogMessage has_any (MikroTrickPatterns)
    | extend Indicator = tostring(extract(@"(-2|ssh-keys|user added|user changed|script added|scheduler)", 1, SyslogMessage))
    | project TimeGenerated, Computer, HostIP, ProcessName, Indicator, SyslogMessage
    | extend SourceTable = "Syslog"),
    (CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where Message has_any (MikroTrickPatterns) or AdditionalExtensions has "-2"
    | extend Indicator = tostring(extract(@"(-2|ssh-keys|user added|user changed|script added|scheduler)", 1, Message))
    | project TimeGenerated, DeviceName=Computer, SourceIP, DestinationIP, Indicator, Message
    | extend SourceTable = "CEF")
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count(), SampleMessage=any(SyslogMessage) by Computer, Indicator, SourceTable
| order by LastSeen desc

Run this back at least 90 days if your retention allows it. The campaign has been live since September — a 30-day window will miss early-stage compromises that are now quietly persistent.

Velociraptor VQL

Velociraptor can't run on the router itself, but it absolutely can hunt your syslog collectors and jump hosts for evidence of -2 authentication and operator sessions to MikroTik devices. Deploy this artifact against Linux syslog servers and admin workstations:

-- Hunt syslog and auth logs for MikroTrick artifacts: rogue user -2 and RouterOS persistence strings
LET log_globs = '/var/log/{auth.log,auth.log.*,syslog,syslog.*,messages,messages.*,remote/**.log}'

SELECT FullPath, Line, LineNumber,
       parse_string_with_regex(string=Line,
          regex='(?P<Indicator>-2|ssh-keys|user added|user changed|script added)').Indicator AS Indicator
FROM foreach(
    row={ SELECT FullPath FROM glob(globs=log_globs) },
    query={
        SELECT FullPath, Line, LineNumber
        FROM parse_lines(filename=FullPath)
        WHERE Line =~ 'user -2|for -2 from|Invalid user -2|ssh-keys|user added|user changed|script added'
    })
ORDER BY FullPath, LineNumber

On jump hosts that administer MikroTik devices, also pull pslist() and bash/PowerShell history for unexpected outbound SSH sessions — compromised routers are frequently used as pivots back into the management plane.

Remediation & Triage Script

This script triages a MikroTik device over SSH: it captures version, users, SSH keys, scheduler jobs, scripts, and recent logs into a local evidence bundle, flags the -2 user and other anomalies, then prints the exact upgrade path. Run the evidence capture before upgrading.

#!/usr/bin/env bash
# MikroTik MikroTrick triage - capture evidence, detect rogue accounts, prep upgrade
# Usage: ./mikrotik_triage.sh <router_ip> <admin_user>
set -euo pipefail

ROUTER="${1:?Router IP required}"
ADMIN="${2:?Admin username required}"
OUTDIR="mikrotik_evidence_${ROUTER}_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUTDIR"

echo "[*] Capturing device state from ${ROUTER} -> ${OUTDIR}/"

# Full config export and key state dumps - capture BEFORE any reboot/upgrade
ssh "${ADMIN}@${ROUTER}" '/export show-sensitive'                    > "$OUTDIR/config_export.rsc"
ssh "${ADMIN}@${ROUTER}" '/system resource print; /system package print' > "$OUTDIR/version.txt"
ssh "${ADMIN}@${ROUTER}" '/user print detail'                        > "$OUTDIR/users.txt"
ssh "${ADMIN}@${ROUTER}" '/user ssh-keys print detail'               > "$OUTDIR/ssh_keys.txt"
ssh "${ADMIN}@${ROUTER}" '/system scheduler print detail'            > "$OUTDIR/scheduler.txt"
ssh "${ADMIN}@${ROUTER}" '/system script print detail'               > "$OUTDIR/scripts.txt"
ssh "${ADMIN}@${ROUTER}" '/ip firewall filter print; /ip firewall nat print; /ip proxy print' > "$OUTDIR/firewall.txt"
ssh "${ADMIN}@${ROUTER}" '/log print'                                > "$OUTDIR/device_log.txt"
ssh "${ADMIN}@${ROUTER}" '/file print'                               > "$OUTDIR/files.txt"

echo "[*] Checking for MikroTrick indicators..."

# Indicator 1: rogue '-2' account (or any dash-prefixed username)
if grep -Eq 'name="?-[0-9]' "$OUTDIR/users.txt"; then
  echo "[!!!] CRITICAL: dash-prefixed user account found (MikroTrick artifact):"
  grep -E 'name="?-[0-9]' "$OUTDIR/users.txt"
fi

# Indicator 2: SSH keys on accounts that shouldn't have them
echo "[*] SSH keys present (verify each against your records):"
grep -v '^$' "$OUTDIR/ssh_keys.txt" || echo "    none"

# Indicator 3: scheduled jobs / scripts fetching remote content
if grep -Ei 'fetch|http://|https://|/tool fetch' "$OUTDIR/scheduler.txt" "$OUTDIR/scripts.txt" 2>/dev/null; then
  echo "[!!] WARNING: scheduler/script fetches remote content - review above"
fi

# Version check against patched releases
VER=$(grep -oE 'version: [0-9]+\.[0-9]+(\.[0-9]+)?' "$OUTDIR/version.txt" | head -1 | awk '{print $2}')
echo "[*] Running RouterOS version: ${VER:-unknown}"

cat <<'EOF'

[+] NEXT STEPS - UPGRADE IMMEDIATELY to a patched release:
    v7 current track : 7.24.2
    v7 long-term     : 7.23.5
    v6 long-term     : 6.49.21

    On the device (after evidence capture):
      /system package update set channel=upgrade
      /system package update check-for-updates
      /system package update install

    Or download the .npk from https://mikrotik.com/download and upload + reboot.
EOF

echo "[*] Evidence bundle written to ${OUTDIR}/ - retain for IR before rebooting."

Remediation: The Full Playbook

Patching alone does not evict an attacker who has been inside since September. Execute in this order:

1. Contain first if indicators are present. If you find the -2 user, unknown SSH keys, or unexplained scheduler jobs: block inbound/outbound at the upstream firewall, preserve the evidence bundle from the script above, and treat the device as a live IR scene. Do not factory-reset before capturing state — you'll destroy the only evidence you have.
2. Remove malicious persistence. Delete rogue accounts (/user remove [find name="-2"]), remove unauthorized SSH keys, delete suspicious scheduler entries and scripts, and review /ip firewall, /ip proxy, and /ip socks for attacker-added rules. Given the dash-username parsing trick, use print with numeric IDs and remove <id> rather than name-based removal where tools choke on the leading dash.
3. Patch to 7.24.2, 7.23.5, or 6.49.21. Pull packages only from https://mikrotik.com/download or the in-device upgrade channel. Verify the running version post-reboot.
4. Rotate all credentials. Every RouterOS account password, every SSH keypair used to administer the device, any RADIUS/TACACS+ secrets configured on it, and any credentials for downstream systems that transited or were stored on the router (PPPoE secrets, VPN credentials, API tokens).
5. Lock down the management plane permanently.
   • /ip service set ssh address=<management_subnet>/32 — SSH should never be internet-exposed. If remote management is required, front it with a VPN.
   • Disable unused services: /ip service disable telnet,ftp,www,api,api-ssl (and winbox from WAN).
   • Enforce key-only SSH auth and disable password login where operationally feasible.
   • Enable remote syslog (/system logging action add target=remote remote=<siem_ip>) so the next incident has evidence that survives a reboot.
6. Hunt downstream. A compromised router sees everything. Review NetFlow/firewall logs for sessions that traversed the device to unexpected destinations during the exposure window, and check whether the router's identity was used to authenticate elsewhere (VPN concentrators, management jump boxes).
7. If compromise is confirmed, rebuild. Config export, forensic review, factory reset, firmware reinstall, restore a known-good, sanitized config. For edge devices with confirmed attacker dwell time, a rebuild is cheaper than the doubt.

The Bigger Lesson

MikroTik devices keep showing up in nation-state and criminal infrastructure for a reason: they're powerful, cheap, everywhere, and operated with consumer-grade hygiene on enterprise-grade attack surface. The -2 account is a gift — an unusually crisp indicator in a campaign where most artifacts are subtle. Use it. Hunt your logs back to September, inventory every RouterOS device in your environment (including the ones nobody remembers deploying at branch sites), and move edge-device patching into the same emergency change lane as your internet-facing applications. Your perimeter is only as trustworthy as the least-patched box sitting on it.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub