DEV Community

Anoymask
Anoymask

Posted on

MikroTrick: Active Exploitation of MikroTik RouterOS SSH Authentication Bypass and Privilege Escalation

#security #threatintel

1. Basic Information

2. Summary

Attackers actively hijack internet-exposed routers running MikroTik RouterOS. They chain an SSH authentication bypass caused by incomplete RSA public key validation with privilege escalation via a crafted username.

3. Attack Flow

  1. The attacker identifies an internet-facing RouterOS SSH service. Exploitation requires knowledge of the target username and the modulus of its registered RSA public key; how the attackers obtained these details remains unconfirmed.
  2. The attacker exploits CVE-2026-67276 to authenticate as the target account using a different RSA key without holding the valid private key.
  3. The attacker exploits CVE-2026-86060 with a crafted username to obtain full administrative privileges for the SSH session.
  4. The attacker adds an administrative user. They can use the obtained privileges to modify DNS, VPN, and other settings; however, analysts must verify individually whether traffic interception or internal lateral movement occurred.

CVE-2026-67277 is a separate Bandwidth Test vulnerability, and analysts have not observed its inclusion in this SSH attack chain.

4. Attacker Location and Execution Context

  • Unauthenticated remote attacker who can reach the RouterOS SSH or Bandwidth Test services.
  • To bypass SSH authentication, the attacker must know the target username and the modulus of the registered RSA public key.

5. Visibility to Victims and Administrators

Victims

  • Regular user interaction is not required. Users may only notice communication anomalies or connection drops.

Administrators

  • Indicators include SSH log entries such as login failure for user -2 and user <name> added by ssh:-2@<ip>, as well as unknown users and configuration diffs. The absence of new Flagged indicators does not guarantee that the device is uncompromised.

6. Conditions for Success and Failure

Conditions for Success

  • The SSH service is exposed externally and runs a vulnerable version.
  • The attacker obtains the target username and the modulus of the public RSA key.
  • Security controls do not block abnormal SSH authentication and administrative operations.

Failure Conditions / Risk Mitigation

  • Update to version 7.25beta3, 7.24.2, 7.23.4, 6.49.21, or later.
  • Disable SSH, WWW, and Bandwidth Test services, or restrict them to management networks and allowed source IPs.
  • If you suspect compromise, do not trust the configuration alone. Preserve logs, factory-reset and rebuild the device, and rotate all keys and credentials.

7. Impact of Successful Attack

The following includes potential consequences of administrative takeover, not only activity confirmed in the reported attacks.

  • Complete administrative takeover of the router.
  • Unauthorized changes to DNS, routing, VPN, and firewall settings.
  • Traffic interception, credential theft, lateral movement into internal networks, and loss of availability.

8. Observable Logs

Inference: Below are the data sources used during investigations and their scope of verification.

  • Email: Not used for direct verification in this incident.
  • Proxy/SWG/DNS: Not used for direct verification in this incident.
  • Endpoint/EDR: Review RouterOS system logs and configuration exports for failures and user additions related to user -2, unknown administrators, scripts, schedulers, and key modifications. This does not assume typical host-based EDR collection.
  • Identity/IdP: Not used for direct verification in this incident.
  • SaaS/Cloud: Not used for direct verification in this incident.
  • Network: Check the source IPs of SSH connections in firewall logs and flow records. Reports note 82.192.72.4 in successful cases and 103.102.31.18 in attempts. An IP match alone does not confirm compromise. Cross-reference any DNS, route, NAT, or VPN modifications with device configuration history.

9. Determining Attack Success

Inference: Below are criteria for internal investigations. They do not mean that every stage of damage occurred in all reported incidents.

  • Attack Attempt Observed (Success Unconfirmed): Unusual SSH requests or login failure for user -2 serve as an investigation trigger. Authentication failure alone does not indicate successful execution.
  • Malware Execution or Authentication Success Confirmed: Confirm this when you detect unauthorized SSH authentication or management sessions. user <name> added by ssh:-2@<ip> serves as evidence of account addition; cross-reference this with authorized change records.
  • Post-Exploitation Confirmed: Confirm this when you observe unauthorized configuration changes or operations against internal devices. Gaining administrative rights alone does not prove traffic interception or lateral movement.

10. Investigation Playbook

Inference: This investigation procedure is based on the prerequisites established in public disclosures.

  • Trigger: SSH failures or user additions involving user -2, unknown administrative logins, or configuration export diffs.
  • Initial Verification: Identify target versions, configurations, and exposure scope, then preserve logs with reliable timestamps and configuration states.
  • Device: Compare RouterOS users, SSH keys, scripts, schedulers, proxies, and tunnels against known-good baselines.
  • Authentication / Cloud: Verify added or modified administrators and key owners, then identify other devices that share the same credentials.
  • Follow-on Activity: Track outbound traffic, data access, persistence, privilege escalation, and lateral movement.
  • Containment: Update to version 7.25beta3, 7.24.2, 7.23.4, 6.49.21, or later. Disable SSH, WWW, and Bandwidth Test services, or restrict them to management networks and allowed source IPs. If you suspect compromise, do not trust the configuration alone; preserve logs, factory-reset and rebuild the device, and replace keys and credentials.
  • Classification: Separate events into authentication failure, authentication success, unauthorized administrative action, and compromise of other devices.

11. Defense and Detection Ideas

Inference: Below are suggestions for operational implementation.

  • Single Events: SSH failures or user additions involving user -2, unknown administrative logins, and configuration export diffs.
  • Timeline Correlation: Correlate unusual SSH attempts, user additions, configuration modifications, and internal traffic sequentially using device logs and upstream flow records.
  • Threat Hunting: Start from reported source IPs and user -2 to hunt for suspicious administrators, schedulers, and tunnels. Do not exclude devices from investigation merely because they lack a Flagged status.
  • Log Gaps: On-device logs can be altered or lost; therefore, forward logs to external systems and maintain known-good configuration backups.
  • Priority Measures: Update to version 7.25beta3, 7.24.2, 7.23.4, 6.49.21, or later. Disable SSH, WWW, and Bandwidth Test services, or restrict them to management networks and allowed source IPs. If you suspect compromise, do not trust the configuration alone; preserve logs, factory-reset and rebuild the device, and rotate all keys and credentials.

12. Facts / Inference / Hypothesis

Facts

  • CERT Polska confirmed that attackers actively used an exploit chain named MikroTrick, which combines CVE-2026-67276 and CVE-2026-86060, against internet-facing SSH services.
  • In CVE-2026-67276, RouterOS does not compare the full RSA public key; therefore, an attacker who knows the username and public key modulus can authenticate via SSH using a different key without the corresponding private key.
  • In CVE-2026-86060, using a crafted username that starts with an invalid character assigns full administrative permissions to the SSH session.
  • CVE-2026-67277 is an uninitialized buffer and integer underflow flaw in unauthenticated handling within the Bandwidth Test service, leading to kernel memory leaks or remote Denial of Service (DoS).
  • Patched versions are 7.25beta3, 7.24.2, 7.23.4, and 6.49.21. Reports identified successful exploits from 82.192.72.4 and attempts from 103.102.31.18.

Inference

  • Organizations can prioritize patching by checking public key exposure together with administrative service exposure, because the authentication bypass requires both the username and the RSA public key modulus.

Hypothesis

No additional hypotheses. Items that remain unconfirmed are listed in "Gaps and Next Steps."

13. MITRE ATT&CK Mapping

Inference: Mappings are based on public threat intelligence.

  • T1190 Exploit Public-Facing Application (High): Exploiting vulnerabilities in internet-exposed RouterOS services.
  • T1078 Valid Accounts (High): Operating as the target account after bypassing SSH authentication.
  • T1098 Account Manipulation (High): Adding unauthorized administrator accounts as reported.

14. Gaps and Next Steps

  • Total number of actively exploited devices and threat actor attribution.
  • The extent of post-exploitation configuration changes, traffic interception, and internal network compromise.
  • Specific channels attackers used to obtain the public key moduli.

15. Impact on SOCs and Organizations

Organizations operating MikroTik devices should verify SSH and Bandwidth Test service exposure using both asset inventories and external scans, and upgrade to patched releases. Do not use the absence of a Flagged status as proof that a system is safe. Instead, investigate SSH logs, user accounts, keys, configuration exports, and DNS or routing changes chronologically. If you identify signs of compromise, perform a full factory reset, rebuild the device, and rotate all credentials.

16. Role-Specific Summaries

  • For SOCs: Do not assume compromise based solely on SSH authentication failures; track subsequent user additions and configuration changes. Treat the Bandwidth Test vulnerability separately from the SSH exploit chain.
  • For Administrators: Update to version 7.25beta3, 7.24.2, 7.23.4, 6.49.21, or later. Disable SSH, WWW, and Bandwidth Test services, or restrict them to management networks and allowed source IPs.
  • For End Users: Normal user interaction is not required; users may only notice communication anomalies or service disruptions.

Top comments (0)