Una cadena de vulnerabilidades críticas en MikroTik RouterOS permite tomar el control administrativo de routers con SSH expuesto a Internet sin disponer de las credenciales privadas válidas del usuario. CERT Polska ha bautizado el ataque como MikroTrick y confirma que ya se está explotando activamente. El problema combina un fallo en la validación de claves RSA con una segunda vulnerabilidad de escalada de privilegios, por lo que los administradores deberían actualizar RouterOS y revisar los dispositivos potencialmente expuestos.
Las claves de MikroTrick en 20 segundos
- MikroTrick combina CVE-2026-67276 y CVE-2026-86060, ambas críticas.
- La primera vulnerabilidad permite eludir la autenticación SSH con determinadas claves RSA.
- La segunda puede convertir esa sesión en acceso administrativo completo.
- Hay ataques observados desde al menos el 02/09/2026.
- Los administradores deben actualizar RouterOS y buscar indicadores como
-2y la cuentaops.
El riesgo afecta especialmente a routers cuyo servicio SSH puede alcanzarse directamente desde Internet o desde redes que no deberían tener acceso al plano de administración. Un MikroTik protegido por reglas de firewall que limiten SSH a una red de gestión concreta presenta una superficie de ataque muy inferior, aunque la actualización continúa siendo recomendable.
La relevancia del incidente está en que el ataque ya no es puramente teórico. CERT Polska ha confirmado explotación real y existen registros de actividad anteriores incluso a la publicación de los parches, lo que ha llevado a considerar la cadena como un caso de día cero.
CVE-2026-67276 rompe la autenticación SSH basada en RSA
El primer componente de MikroTrick es CVE-2026-67276, con una puntuación CVSS de 9,2.
El fallo se encuentra en el proceso con el que RouterOS verifica determinadas claves públicas RSA durante una conexión SSH. En una autenticación correctamente implementada, el servidor no debería limitarse a comprobar que una clave pública coincide con la configurada para el usuario. También debe verificar criptográficamente que el cliente posee la correspondiente clave privada.
Según el análisis técnico difundido sobre la vulnerabilidad, RouterOS no validaba correctamente todos los parámetros implicados en esa comprobación.
El escenario descrito requiere que el atacante conozca:
- un nombre de usuario válido;
- información pública correspondiente a la clave RSA autorizada de ese usuario;
- acceso de red al servicio SSH del router.
Con esos elementos, el atacante puede construir una clave manipulada que supera la comprobación realizada por RouterOS sin disponer de la clave privada original.
El resultado es una elusión de autenticación SSH.
Eso no significa que cualquier conexión anónima pueda entrar simplemente enviando una contraseña vacía. La vulnerabilidad depende del comportamiento defectuoso en la validación RSA y de disponer de determinados datos públicos asociados al usuario atacado.
| Vulnerabilidad | Componente | Resultado |
|---|---|---|
| CVE-2026-67276 | Validación RSA en SSH | Elusión de autenticación |
| CVE-2026-86060 | Gestión de privilegios en sesión SSH | Escalada de privilegios |
| MikroTrick | Combinación de ambas | Control administrativo |
La segunda pieza, CVE-2026-86060, permite escalar los permisos obtenidos inicialmente.
Una vez encadenados ambos fallos, una sesión creada mediante la primera vulnerabilidad puede terminar disponiendo de privilegios suficientes para modificar prácticamente toda la configuración del router.
Eso abre la posibilidad de crear usuarios adicionales, añadir claves SSH, modificar el firewall, instalar scripts, activar proxies, configurar túneles o alterar el encaminamiento del tráfico.
Los ataques dejan rastros peculiares en RouterOS
Uno de los aspectos más útiles para los equipos de seguridad es que la explotación observada hasta ahora puede dejar indicadores relativamente reconocibles.
Entre ellos aparece un usuario anómalo:
-2
Un intento fallido puede quedar registrado con una entrada similar a:
login failure for user -2 from <IP> via ssh
En otros casos puede aparecer una modificación dentro de /system history asociada a una sesión del tipo:
ssh:-2@<IP>
El valor -2 no corresponde a una cuenta convencional que un administrador esperaría encontrar en una instalación normal de RouterOS.
Su aparición, especialmente asociada a cambios de configuración, debería considerarse un indicador que requiere investigación inmediata.
Los ataques confirmados también han incluido la creación de una cuenta denominada:
ops
No basta, sin embargo, con buscar esos dos nombres y asumir que un router está limpio si no aparecen.
Los registros pueden haber rotado, haberse borrado o no conservar ya las entradas correspondientes al momento de la intrusión. Por eso la revisión debería extenderse a la configuración completa del sistema.
Entre los elementos que conviene inspeccionar están:
/user, para detectar cuentas desconocidas;- claves SSH asociadas a usuarios;
- scripts y schedulers;
- reglas de firewall nuevas o modificadas;
- servicios habilitados recientemente;
- proxies y túneles;
- configuración de sniffing;
- cambios inesperados de routing;
- configuraciones persistentes que permitan recuperar acceso posteriormente.
También se han asociado a la campaña las direcciones 82.192.72[.]4 y 103.102.31[.]18.
La primera habría alojado además varios archivos utilizados durante la actividad observada, incluidos ftpsrv.py, launch.sh y serve.py.
Estos indicadores pueden ayudar en la búsqueda histórica dentro de logs, SIEM y sistemas de monitorización, pero no deberían emplearse como único criterio para descartar un compromiso.
Qué versiones corrigen MikroTrick y qué hacer después de actualizar
MikroTik publicó las correcciones durante los primeros días de septiembre.
Las ramas que deberían utilizarse como referencia mínima son:
| Rama | Versión corregida |
|---|---|
| RouterOS 7.24 | 7.24.2 |
| RouterOS 7.23 | 7.23.4 o posterior |
| RouterOS 6.x | 6.49.21 |
| Beta | 7.25beta3 |
RouterOS 7.23.5, publicada posteriormente, también contiene las correcciones correspondientes.
La prioridad para un administrador que mantenga SSH públicamente accesible debería ser actualizar a una versión corregida o posterior compatible con el dispositivo.
Pero el parche únicamente corrige la vulnerabilidad. No elimina automáticamente la persistencia que un atacante haya podido configurar antes de la actualización.
Un router que ya haya sido comprometido podría continuar bajo control del atacante aunque la vulnerabilidad original deje de ser explotable.
Por ese motivo, ante evidencias de intrusión, la respuesta debería ser más amplia:
- Aislar el dispositivo de redes no confiables.
- Conservar logs y configuración si se necesita análisis forense.
- Revisar usuarios, claves, scripts, reglas y servicios.
- Cambiar las credenciales y secretos que hayan podido quedar expuestos.
- Restablecer el router a valores de fábrica cuando exista un compromiso confirmado.
- Reconstruir la configuración desde una fuente conocida y fiable.
- Aplicar posteriormente las últimas actualizaciones de RouterOS.
Restaurar automáticamente una copia completa del propio router comprometido puede ser peligroso si esa copia ya contiene usuarios, scripts o cambios introducidos por el atacante.
Mientras no pueda aplicarse la actualización, la mitigación inmediata pasa por eliminar el acceso SSH desde Internet y limitarlo únicamente a direcciones o redes de administración controladas.
Lo mismo debería plantearse para otros servicios administrativos innecesariamente expuestos, incluidos WWW/WWW-SSL y funcionalidades como bandwidth-test.
Desde el punto de vista arquitectónico, el incidente vuelve a mostrar el riesgo de publicar directamente interfaces de administración de infraestructura.
SSH es un protocolo diseñado para administración remota segura, pero eso no convierte automáticamente en seguro cualquier servicio SSH accesible desde todo Internet. Una vulnerabilidad previa a la autenticación puede eliminar de golpe las garantías que ofrecen contraseñas fuertes o claves criptográficas.
Restringir el plano de gestión mediante VPN, listas de control de acceso, firewalls y redes independientes reduce considerablemente la exposición incluso cuando aparece un fallo crítico en el software.
MikroTrick es especialmente preocupante porque combina precisamente las dos capacidades que un atacante busca en un equipo perimetral: entrada sin autenticación válida y escalada hasta administración completa.
Y un router comprometido ocupa una posición privilegiada dentro de una red. Puede observar tráfico, redirigir conexiones, modificar DNS, crear túneles hacia infraestructuras externas o convertirse en punto de entrada para otros sistemas internos.
Por eso, en este caso, actualizar RouterOS debería ser únicamente la primera parte de la respuesta. La segunda consiste en determinar si alguien llegó antes.
Preguntas frecuentes
¿Qué es MikroTrick?
MikroTrick es la cadena de ataque identificada por CERT Polska que combina CVE-2026-67276 y CVE-2026-86060. Juntas permiten saltarse la autenticación SSH y obtener privilegios administrativos sobre RouterOS.
¿Qué routers MikroTik están más expuestos?
Los dispositivos con SSH accesible directamente desde Internet o desde redes no confiables presentan el mayor riesgo. Los equipos cuyo firewall limita el acceso administrativo a una red específica reducen considerablemente la superficie de ataque.
¿Qué significa encontrar ssh:-2 en RouterOS?
El identificador -2 se ha observado durante la explotación de MikroTrick. Si aparece asociado a cambios de usuarios, claves, firewall, scripts, túneles u otras acciones administrativas, el equipo debería considerarse potencialmente comprometido.
¿Es suficiente actualizar a RouterOS 7.24.2?
La actualización corrige la vulnerabilidad conocida, pero no elimina posibles cambios realizados previamente por un atacante. Si existen evidencias de compromiso, es necesario revisar la configuración y valorar un restablecimiento completo del dispositivo.
