JunOS y RedPenguin

El 13 de marzo de 2025, Juniper publicó un interesante artículo sobre una infección de malware encontrada en un conjunto de routers Juniper MX de la que tuvieron conocimiento en julio de 2024. Bautizaron la campaña como "RedPenguin". Este incidente era fascinante porque parecía increíblemente avanzado y requería un profundo conocimiento del sistema operativo de los routers Juniper (JunOS).

Utilizando credenciales de inicio de sesión comprometidas, estos atacantes instalaron varios demonios que modifican la memoria, establecen canales de comunicación para la administración remota, limpian registros y ponen en marcha diversos mecanismos IPC.

Lo que llamó la atención de inmediato fueron los métodos de comunicación de red. Por ejemplo, la RAT instalada llamada "jdosd" (Junos Denial of Service Daemon) se comunica con un servidor C2 para ejecutar comandos y leer y escribir archivos en el router. Utilizando un listener UDP en el puerto 33512, implementa un protocolo de framing bastante básico que un escáner de red no podría encontrar fácilmente.

A diferencia de TCP, donde el servidor debe enviar de vuelta un SYN/ACK o SYN/RST, UDP es sin conexión, lo que lo hace difícil de escanear ya que tienes dos opciones para determinar si un socket UDP remoto está escuchando cuando el servidor no inicia la transmisión de datos:

1. Puedes construir un paquete que obtenga una respuesta del servidor remoto. (por ejemplo, enviar una consulta DNS al puerto 53)
2. Busque mensajes ICMP de puerto no alcanzado procedentes del servidor remoto.
   1. Esto es muy poco fiable debido al filtrado estándar y a la configuración del host.

Así que, con UDP, a menos que puedas construir un paquete en el que el servidor responda con datos, es casi imposible saber si hay algo en el otro extremo. El protocolo UDP para este proceso "jdosd" requiere que un servidor C2 se conecte a él (un proceso inverso al de la mayoría de las operaciones C2 en las que el dispositivo comprometido se conecta de nuevo al C2) y envía un paquete especialmente diseñado que incluye alguna información de autenticación. Una vez completado este apretón de manos, el proceso "jdosd" comenzará a leer comandos del socket.

Desafortunadamente, en el momento de redactar este blog, no pudimos obtener una muestra para observar el handshake de conexión de primera mano, por lo que escanear ciegamente UDP/33512 en busca de dicho servicio fue inútil. Incluso si pudiéramos escanearlo, sólo podríamos hablar de quién fue comprometido en lugar de quiénes son los atacantes, dado que los atacantes se conectan a los routers en lugar de viceversa.

Pero este no es el caso de todo el malware que se instaló; se identificó que los servicios "/usr/sbin/appid" y "/usr/sbin/to" eran una versión modificada de una puerta trasera de código abierto llamada Tiny SHell en la que se encontraron varias direcciones IP codificadas. El router se conectará a una de estas direcciones IP en el puerto 22 y escuchará comandos para ejecutar localmente. Estas son las direcciones IP codificadas conocidas:

• "/usr/sbin/appid"
  • 129.126.109.50
  • 116.88.34.184
  • 223.25.78.136
  • 45.77.39.28
• "/usr/sbin/to"
  • 101.100.182.122
  • 118.189.188.122
  • 158.140.135.244
  • 8.222.225.8

Una cosa a tener en cuenta aquí es que esto fue reportado en julio del año pasado, y ni siquiera tenemos una fecha exacta para este informe, sólo un rango genérico. Esto significa que mirar a los hosts tal y como son actualmente puede no ser lo mismo que mirarlos desde ese punto en el tiempo.

8.222.225.8 (arriba) tenía constantemente sólo dos servicios en ejecución entre el 1 de junio de 2024 y el 1 de agosto de 2024; el más notable es el servicio que escucha en el puerto 22 (el puerto al que se conecta el malware TinySHell), que se anunciaba como un servidor OpenSSH estándar de uso cotidiano. La existencia de este servicio específico significa que este no era el puerto al que se conectaba originalmente el malware, o bien que se trata de un servidor TinySHell altamente modificado y hecho para parecer un servidor OpenSSH real.

La única vez que 45.77.39.28 tuvo algún servicio ejecutándose en este rango de tiempo fue a finales de julio, concretamente el 29 de julio de 2024. Al igual que el host anterior, un servidor OpenSSH escuchaba en el puerto 22 y fue eliminado dos días después, el 31 de julio de 2024.

116.88.34.184 tuvo constantemente seis servicios diferentes ejecutándose a lo largo de julio de 2024, excepto el 02 de julio, cuando un extraño servicio desconocido se inició en el puerto 3265 y se detuvo el 04 de julio. Fuera de esta anomalía, el host era un servidor multimedia doméstico que ejecutaba Plex, un NAS Synology y una página de administración ASUS ZenWiFI AX Mini (que puede haber sido vulnerable a CVE-2024-3080). Al igual que los dos hosts anteriores, el servicio que escuchaba en el puerto 22 era un servidor SSH legítimo que ejecutaba Dropbear en lugar de OpenSSH.

118.189.188.122 sólo prestó dos servicios durante el mes de julio . 2024: una interfaz de administración ASUS RT-AX82U en el puerto 8443 (que puede haber sido vulnerable a CVE-2022-35401) y un servidor SSH Dropbear en el puerto 22 (que siguen funcionando el 13 de marzo de 2025). De nuevo, no hay señales de ningún servicio único como TinySHell ejecutándose en el puerto 22.

129.126.109.50 tenía dos servicios en ejecución a lo largo de julio de 2024: un servicio SSH de Dropbear en el puerto 22 y un ASUS RT-AX55 (que puede haber sido vulnerable a un RCE reportado por el CERT taiwanés).

158.140.135.244 ha estado ejecutando el mismo número de servicios desde julio de 2024. El puerto 22 es otro servidor OpenSSH, y junto a un montón de diferentes sitios web ASP, encontramos otra página de administración del router ASUS (RT-AX58U) en el puerto 8443, que puede haber sido vulnerable a un exploit del que informamos en junio de 2024.

223.25.78.136, en la actualidad, no es el mismo host físico que en julio de 2024. A partir del 07 de julio de 2024, observamos cinco servicios diferentes: un servidor Dropbear SSH en el puerto 22, un servidor VPN IKE en UDP 500, un servicio OpenVPN en el puerto 1194, un servicio serie a red (ser2net) en el puerto 5000, y otra página de administración del router ASUS RT-AX58U en el puerto 8443.

En cuanto a 101.100.182.122no teníamos ningún servicio en funcionamiento en julio de 2024, e incluso miramos unos meses antes; podría ser que nuestro escáner pasara algo por alto.

Destacamos estas interfaces de administración ASUS porque si Mandiant está en lo cierto al evaluar que estos ataques se llevaron a cabo a través de una red ORB (Operational Relay Box), entonces muchos de los servicios que verás en los hosts de origen parecerán dispositivos residenciales de grado SOHO (como routers ASUS). La realidad es que lo más probable es que estos dispositivos estén (o hayan estado) comprometidos y se estén utilizando como proxies. Y dado que sabemos que ASUS ha sido objetivo de varias campañas de pirateo a gran escala, probablemente sea una apuesta segura decir que estos dispositivos eran propiedad de personas inocentes pero estaban controlados por partes malintencionadas. Es una coincidencia demasiado extraña que casi todos estos servidores C2 utilizaran routers ASUS.