La cadena de zero-day MikroTrick permite a los atacantes tomar el control de administrador de los routers MikroTik

Los dispositivos MikroTik RouterOS que exponen SSH a internet están siendo atacados activamente mediante una cadena de vulnerabilidades conocida como MikroTrick. La campaña puede llevar a un atacante desde un acceso SSH sin autenticación hasta el control administrativo total de un router vulnerable.

La cadena combina CVE-2026-67276, una vulnerabilidad crítica que permite eludir la autenticación mediante claves RSA, con una puntuación CVSS de 9,2, y CVE-2026-86060, un fallo de escalada de privilegios en sesiones SSH. CERT Polska ha confirmado varias intrusiones, incluida la creación de una cuenta no autorizada llamada ops.

El investigador de seguridad Costin Raiu informó de que la explotación podría haber comenzado el 2 de septiembre de 2026, un día antes de que MikroTik publicara las correcciones correspondientes. Esta secuencia convierte a MikroTrick en una campaña de zero-day, no en una explotación iniciada únicamente después de que se analizaran públicamente los parches.

La explotación precedió a las actualizaciones de seguridad de MikroTik

Los registros publicados en un foro polaco de seguridad muestran aparentes intentos de explotación fechados el 2 de septiembre. CERT Polska confirmó por separado ataques exitosos que comenzaron, como mínimo, ese mismo día.

MikroTik publicó correcciones para RouterOS 7.25beta3, 7.24.2, 7.23.4 y 6.49.21 el 3 de septiembre de 2026. RouterOS 7.23.5, publicado el 4 de septiembre de 2026, también figura como corregido.

Raiu publicó su análisis técnico el 5 de septiembre de 2026. Ese mismo día, CERT Polska emitió un aviso en el que advertía de que varias vulnerabilidades críticas de RouterOS estaban siendo explotadas activamente y urgía a los clientes a actualizar de inmediato.

La cronología sugiere que los atacantes podrían haber sabido que las correcciones eran inminentes y haber comenzado a escanear o explotar dispositivos antes de que los administradores tuvieran los parches disponibles. La mayor parte de la actividad observada se originó desde una única dirección, lo que apunta a una operación capaz de atacar routers expuestos a gran escala.

MikroTik también envió avisos sobre las vulnerabilidades a través de su aplicación móvil oficial. Según se ha informado, era la primera vez que la empresa utilizaba ese canal para una alerta de seguridad.

No se ha divulgado ninguna entrada de estas vulnerabilidades en el catálogo de vulnerabilidades explotadas conocidas de CISA ni ningún plazo federal de corrección asociado. Sin embargo, la explotación confirmada demuestra que el riesgo es operativo, no meramente teórico.

Cómo la cadena MikroTrick elude la autenticación SSH

CVE-2026-67276 afecta a la validación que realiza RouterOS de las claves públicas RSA durante la autenticación SSH. Un atacante que conozca un nombre de usuario válido y el componente público de su clave RSA puede construir una clave fraudulenta que RouterOS acepte sin disponer de la clave privada correspondiente.

Esto rompe un principio fundamental de seguridad de SSH. Las claves públicas deben identificar las credenciales autorizadas, mientras que la clave privada demuestra que la parte que se conecta es su propietaria legítima. Las versiones vulnerables de RouterOS pueden ser engañadas para aceptar la autenticación sin esa prueba.

A continuación, el acceso no autorizado se combina con CVE-2026-86060, que permite escalar privilegios dentro de una sesión SSH. La combinación de ambos fallos puede proporcionar a un atacante remoto y no autenticado el control administrativo total.

Para ejecutar el ataque, el servicio SSH de RouterOS debe ser accesible desde la red del atacante. Los routers que exponen SSH directamente a internet presentan el mayor riesgo, aunque un dispositivo también podría ser atacado desde otra red no confiable o ya comprometida.

Las dos vulnerabilidades forman parte de un conjunto de seis fallos de RouterOS cuya identificación y divulgación coordinó CERT Polska. No se han divulgado los rangos exactos de versiones vulnerables. Por ello, los administradores deben comparar sus instalaciones con las versiones corregidas de la rama correspondiente, en lugar de asumir que una versión ligeramente anterior es segura.

Las versiones corregidas identificadas son:

• RouterOS 7.25beta3
• RouterOS 7.24.2
• RouterOS 7.23.5
• RouterOS 7.23.4
• RouterOS 6.49.21

Tanto 7.23.4 como 7.23.5 se han presentado como versiones corregidas. Los operadores deben instalar la versión corregida compatible más reciente de su rama y verificar la versión instalada después de reiniciar o completar el proceso de actualización.

El acceso administrativo expone todo el perímetro de red

Un router comprometido proporciona a los atacantes mucho más que un punto de apoyo en un único dispositivo. El acceso administrativo puede permitirles modificar el enrutamiento, debilitar las políticas del firewall, capturar tráfico, redirigir conexiones, establecer túneles o configurar el dispositivo como proxy.

Los atacantes también pueden añadir usuarios y claves SSH, crear tareas programadas, desplegar scripts o modificar la configuración de los servicios para mantener el acceso. Las funciones de captura de paquetes podrían exponer el tráfico y las credenciales que atraviesan el router, mientras que una configuración manipulada del enrutamiento o de servicios relacionados con DNS podría dirigir a los usuarios hacia infraestructura controlada por los atacantes.

Las instalaciones de MikroTik con muchos años de antigüedad están especialmente expuestas cuando reciben un mantenimiento limitado. Los routers pueden permanecer operativos durante años, por lo que los dispositivos olvidados y las implementaciones no gestionadas en sucursales son candidatos probables a recibir los parches con retraso.

Se considera que los dispositivos que utilizan la configuración de firewall predeterminada de MikroTik y no exponen SSH a internet probablemente están protegidos frente a esta vía concreta de acceso remoto. Esto no demuestra que estén parcheados ni que no hayan sido comprometidos por otros medios. Aun así, es necesario verificar su exposición de gestión y sus versiones de software.

Los registros y el historial de configuración pueden revelar una intrusión

Un intento fallido de MikroTrick puede generar una entrada en el registro de autenticación con el nombre de usuario -2. No es un nombre de cuenta normal, por lo que debe investigarse si aparece en los registros de RouterOS.

La actividad exitosa puede registrarse en /system history con un formato similar a:

ssh:-2@<IP>

Los equipos de respuesta deben correlacionar ese evento con las acciones administrativas posteriores. Entre los cambios sospechosos pueden encontrarse:

• Creación o modificación de usuarios y claves SSH
• Scripts y entradas del planificador nuevos o modificados
• Cambios en los servicios habilitados
• Modificación de reglas del firewall o de enrutamiento
• Activación de proxies o túneles
• Configuración de captura de paquetes
• Otros cambios de configuración no explicados

La cuenta no autorizada ops es un indicador confirmado de la campaña. Su presencia debe activar de inmediato una investigación de respuesta a incidentes.

La ausencia de una entrada -2 no demuestra que el router esté limpio. Los registros pueden haberse rotado, sobrescrito o borrado por un atacante. Un evento histórico que muestre ssh:-2@<IP> seguido de una acción de configuración debe tratarse como una intrusión confirmada, salvo que proceda de una prueba de seguridad autorizada.

Los investigadores deben revisar tanto el estado actual como los registros históricos. Es necesario inspeccionar los usuarios, las claves, los scripts, los planificadores, los servicios, las políticas del firewall, los proxies, los túneles, la configuración de captura de paquetes y las reglas de acceso a la gestión.

Infraestructura de la campaña e indicadores de archivos

La mayoría de los ataques observados procedieron de 82.192.72[.]4, una dirección alojada por Leaseweb. Una segunda dirección, 103.102.31[.]18, también se ha asociado con la campaña.

La dirección principal alojaba cuatro archivos:

• Una compilación para MIPS del binario oficial precompilado de BusyBox 1.16.1, compilado en 2010
• ftpsrv.py
• launch.sh
• serve.py

Tres de los archivos proporcionados no tenían detecciones en VirusTotal en el momento de su análisis. Un nivel de detección bajo o inexistente no debe interpretarse como una prueba de que sean benignos en este contexto operativo.

Los equipos defensivos pueden buscar estos archivos y datos de telemetría mediante los siguientes hashes SHA-256:

Archivo	SHA-256
ftpsrv.py	6e95f70fdbabb57881b3f5b2c8465d4b17ba901100704efb1278bb3386e6729d
launch.sh	972b474b896f9fac3cd6b5b8476b410b8f39fbedee8a3b0c745d6e3b328d7dcd
serve.py	6dca83338d60467b65b7789d4d59754e40a7aaa36f40ea2da57538367ac9b89e

No se ha divulgado el hash del binario BusyBox. Deben revisarse los datos históricos de red en busca de conexiones entrantes o salientes relacionadas con ambas direcciones IP notificadas.

Aplicar primero el parche y después investigar los routers expuestos

Los administradores deben actualizar de inmediato a la versión corregida de RouterOS que corresponda y confirmar que la actualización se ha completado correctamente. SSH debe deshabilitarse o restringirse siempre que sea accesible desde internet o desde otra red no confiable.

El acceso de gestión debe limitarse a rutas administrativas confiables, direcciones de origen estrictamente controladas o mecanismos de acceso interno protegido. Filtrar las dos direcciones de la campaña resulta útil, pero no puede sustituir la aplicación de parches, ya que los atacantes pueden trasladarse a nueva infraestructura.

Cualquier dispositivo RouterOS con SSH accesible desde internet debe considerarse potencialmente comprometido hasta que se hayan revisado sus registros, el historial de configuración, los usuarios, las claves y la configuración activa.

Si se detecta actividad administrativa no autorizada, los equipos de respuesta deben aislar el router, conservar los registros y las evidencias de configuración, cambiar las contraseñas y las claves SSH, eliminar los mecanismos de persistencia y validar las políticas de enrutamiento y del firewall. Puede ser necesario reconstruir o restaurar el dispositivo mediante un proceso confiable.

Hasta el 5 de septiembre no se había informado de ninguna prueba de concepto pública funcional. Raiu estimó que podría aparecer en GitHub en uno o dos días, aunque la explotación activa ya estaba en curso sin ella. Por tanto, esperar a que se publicara el código del exploit no ofrecería a los defensores ningún margen de seguridad significativo.