Su router MikroTik podría estar comprometido: busque el usuario SSH "-2"
Cualquier router MikroTik con acceso SSH expuesto a internet debe considerarse comprometido debido a una cadena de explotación activa denominada MikroTrick. La vulnerabilidad permite a los atacantes tomar el control total del dispositivo sin autenticación mediante el uso de fallos en la verificación de claves RSA.
Cualquier persona que gestione un router MikroTik con SSH expuesto a internet debe tratarlo como comprometido hasta que se demuestre lo contrario. El experto en ciberseguridad Costin Raiu publicó un desglose técnico detallado de la explotación activa el 5 de septiembre de 2026, el mismo día que CERT Polska emitió su aviso titulado: "Vulnerabilidades críticas en MikroTik RouterOS están siendo explotadas activamente. Se recomienda actualización inmediata."
Detalles de la cadena de ataque
"Si tienes un router MikroTik en internet con SSH abierto, es posible que ya esté comprometido", escribió Raiu en Medium. La cadena de ataque que se está explotando se denomina MikroTrick y combina dos de las seis vulnerabilidades que CERT Polska descubrió y reveló: CVE-2026-67276 (puntuación CVSS de 9.2), que es un bypass de autenticación SSH, y CVE-2026-86060, una escalada de privilegios de sesión SSH.
"El equipo de CERT Polska ha identificado y coordinado la divulgación de seis vulnerabilidades en MikroTik RouterOS. Combinar dos de ellas permite a un atacante tomar el control total del dispositivo sin autenticación si el dispositivo admite acceso remoto mediante el protocolo SSH. Para facilitar la identificación de esta cadena, le hemos dado un nombre común, MikroTrick", afirma CERT Polska. "En los últimos días hemos estado observando ataques contra dispositivos RouterOS accesibles desde internet."
Análisis técnico de las vulnerabilidades
La vulnerabilidad CVE-2026-67276 surge de cómo RouterOS verifica las claves públicas RSA. Si un atacante conoce un nombre de usuario válido y la parte pública de la clave RSA del usuario, puede crear una clave falsa e iniciar sesión sin la clave privada. Cuando se combina con el fallo de escalada de privilegios, el ataque puede otorgar a un atacante acceso completo de administrador a cualquier dispositivo RouterOS expuesto a internet con SSH habilitado.
"MikroTik ha lanzado correcciones en las versiones 7.25beta3, 7.24.2, 7.23.4 y 6.49.21 el 3 de septiembre; sin embargo, parece que la explotación comenzó tan pronto como el 2 de septiembre, lo que la convierte en una vulnerabilidad de día cero", añadió Raiu. "Esto parece sugerir que alguien obtuvo la noticia de que se lanzarían los parches y comenzó a explotarla a gran escala."
Un foro de seguridad polaco contenía registros que mostraban intentos de explotación el 2 de septiembre, y CERT Polska confirmó ataques exitosos que incluyeron la creación de una cuenta "ops" con fecha del 2 de septiembre o anterior.
Infraestructura y vectores de ataque
La mayoría de los ataques observados hasta ahora se originaron desde la IP 82.192.72[.]4, una IP de Leaseweb que alojaba un binario busybox (una compilación MIPS de 2010, idéntica al binario precompilado oficial BusyBox 1.16.1), junto con otros tres archivos: ftpsrv.py, launch.sh y serve.py. Una segunda IP, 103.102.31[.]18, también ha sido asociada con la campaña. Tres de los cuatro archivos alojados no tienen detecciones en VirusTotal hasta el momento de la redacción.
Los routers MikroTik son populares porque pueden funcionar durante años con poco mantenimiento. Pero eso también hace que las vulnerabilidades de SSH sean más peligrosas. Los dispositivos que no han recibido actualizaciones en años podrían no ser parcheados antes de que los atacantes comiencen a explotar un nuevo fallo.
Indicadores de compromiso (IoC)
Los defensores pueden detectar ataques buscando entradas específicas en los registros. Los intentos de inicio de sesión fallidos muestran el nombre de usuario -2, el cual no es una cuenta válida y no debería aparecer en los registros normales. Un ataque exitoso aparece en /system history como ssh:-2@<IP>, seguido de una acción como la creación de un usuario, la adición de una clave SSH, el cambio de reglas de firewall o la activación de un proxy o túnel.
"Cuando esto se asocia a una acción de configuración —especialmente la creación o modificación de usuarios, claves SSH, scripts, planificadores, servicios, reglas de firewall, proxies, túneles o configuraciones de captura de paquetes— trátelo como un compromiso confirmado a menos que provenga de una prueba de seguridad autorizada", concluyó Raiu. "No asuma que el dispositivo es seguro simplemente porque no aparezca un fallo de inicio de sesión -2: los registros pueden haber rotado o sido limpiados."
La creación de una cuenta llamada "ops" es un indicador de compromiso adicional confirmado en los ataques observados.
Raiu probó la reproducibilidad del exploit utilizando cuatro herramientas de IA diferentes. Astra se negó por motivos de seguridad y sugirió que solicitara una verificación de ciberseguridad. Las otras tres (Sol, Daybreak Blue, y GLM-5.3) estuvieron dispuestas a ayudar, pero ninguna pudo completar una implementación funcional. Esa brecha da a los defensores un tiempo estimado de uno a dos días antes de que aparezca públicamente un código de prueba de concepto (PoC) en GitHub, lo cual es mejor que nada, pero no por mucho dado que la explotación ya está ocurriendo a gran escala desde una sola IP.
CERT Polska señaló algo inusual: MikroTik envió notificaciones push a través de su aplicación móvil oficial para alertar a los usuarios sobre las vulnerabilidades, una primera para la empresa. Las versiones parcheadas son 7.25beta3, 7.24.2, 7.23.4, 7.23.5 (lanzada el 4 de septiembre) y 6.49.21. Es probable que los dispositivos que utilicen la configuración de firewall por defecto de MikroTik y que no expongan directamente SSH a la red pública estén protegidos, pero cualquier dispositivo con SSH accesible desde redes no confiables debe ser parcheado inmediatamente e inspeccionado en busca de los indicadores mencionados anteriormente.\n La lista completa de IoC del análisis de Raiu incluye: IPs 82.192.72[.]4 y 103.102.31[.]18; hashes de archivos 6e95f70fdbabb57881b3f5b2c8465d4b17ba901100704efb1278bb3386e6729d (ftpsrv.py), 972b474b896f9fac3cd6b5b8476b410b8f39fbedee8a3b0c745d6e3b328d7dcd (launch.sh), y 6dca83338d60467b65b7789d4d59754e40a7aaa36f40ea2da57538367ac9b89e (serve.py).
La vulnerabilidad subraya la importancia crítica de mantener los dispositivos de red actualizados y monitorear activamente los registros de acceso para detectar actividades sospechosas de manera oportuna.
Contenido traducido al español con fines informativos, cualquier cambio en la publicación original no será reflejada en esta entrada, favor referirse a la fuente para obtener el acceso a cualquier actualización del contenido. Para la traducción se utilizó un LLM, al ser una traducción automática puede contener errores gramaticales o de otro tipo, me pueden enviar un mensaje.
Comentarios
Publicar un comentario