Rootkit sigiloso de Linux hallado en libertad tras pasar desapercibido durante 2 años

Control del tráfico saliente y de egress

• Varios comentarios se centran en los puertos salientes ocultos del malware y señalan que la mayoría de los entornos restringen mucho el tráfico entrante, pero permiten casi todo el tráfico saliente.
• Mitigaciones sugeridas:
  • Registrar y establecer una línea base de los puertos salientes comunes, luego bloquear el resto y ver qué se rompe.
  • Reducir el “ruido de fondo” (por ejemplo, pings DNS constantes, NTP externo) y mover los servicios al interior.
  • Aplicar reglas de firewall según la hora del día para que nada hable con Internet durante la noche, pero con anulaciones de emergencia.
• Algunos sostienen que muchos incidentes (por ejemplo, la explotación de Log4Shell) habrían sido mucho menos dañinos con políticas de egress más estrictas.

Canales de comando y control (C2)

• Varios comentarios dicen que el malware del mundo real suele ocultar el C2 sobre HTTPS en el puerto 443 y a través de grandes proveedores (Cloudflare, grandes nubes, servicios de Google).
• Propuestas como “permitir solo HTTPS hacia FAANG o Cloudflare” son criticadas por ineficaces, porque los atacantes pueden encauzar el C2 a través de esos mismos proveedores.
• Hay informes y ejemplos de Cloudflare Workers y una infraestructura similar usada para C2 y DDoS, con afirmaciones de que los derribos son lentos; otros replican pidiendo evidencia concreta, que se aporta parcialmente mediante informes enlazados.
• El domain fronting, el uso de Google Drive/Docs/Apps Script y “protocolos raros” (por ejemplo, SCTP) se citan como técnicas de evasión de C2.

Vectores de infección y objetivos

• Según se informa, los investigadores del artículo no conocen la vía inicial de infección; entre los posibles vectores se enumeran la explotación de vulnerabilidades, el robo/descifrado de credenciales y instaladores/actualizaciones troyanizados.
• Otras vías probables: SSH débil o sin autenticación en dispositivos Linux IoT y fallos en aplicaciones web/frameworks.
• Algunos sugieren que este RAT es un mecanismo de persistencia de fase tardía tras una intrusión previa, lo que hace difícil reconstruir la entrada original años después.
• El hecho de que apunte a telecomunicaciones y use protocolos novedosos lleva a algunos a especular con actores estatales; otros señalan que también podría tratarse de “fruta al alcance de la mano” o de delincuencia comercial.

Rootkits y técnicas de persistencia

• Los comentaristas señalan que los patrones de rootkits en Linux no han cambiado mucho desde finales de los años 90: reemplazo de binarios, enganche de syscalls del kernel y enganche en userland (por ejemplo, LD_PRELOAD).
• Mantener rootkits de kernel a través de muchas versiones del kernel se describe como una pesadilla; algunos operadores prefieren backdoors más simples en userland.
• Entre los trucos mencionados están renombrar procesos mediante prctl para que parezcan hilos del kernel y crear artefactos de sistema de archivos difíciles de ver (por ejemplo, directorios ...).
• Secure Boot, salvo que esté configurado de forma muy estricta, se considera insuficiente una vez que los atacantes ya tienen ejecución en ring-0.

Postura de seguridad del escritorio Linux

• Hay debate sobre si Linux de escritorio es “más fácil” para actores estatales porque muchos usuarios carecen de AV/EPP e instalan software con curl | sudo bash o gestores de paquetes específicos del lenguaje.
• Varios argumentan que el AV es en gran medida ineficaz contra rootkits/APT desconocidos y que sobre todo detecta patrones conocidos; los atacantes pueden recompilar trivialmente para evadir firmas.
• Otros replican que la Protección de Endpoint moderna usa heurística/ML e indicadores de comportamiento, bloquea muchas cargas útiles commodity y eleva el listón, especialmente en Windows.
• Múltiples comentarios destacan debilidades estructurales de los escritorios Linux típicos:
  • X11 permite keylogging global.
  • Cualquier app que se ejecute como el usuario normalmente tiene acceso total al directorio home.
  • No existe un modelo de permisos por aplicación, moderno y fácil de usar, como en macOS/Windows.
• Una vez que el malware puede escribir en el home del usuario, puede modificar archivos de arranque del shell, envolver sudo, robar claves SSH o secuestrar configuraciones, haciendo que la elevación a root sea a menudo solo cuestión de tiempo o innecesaria para el robo de datos.

Antivirus / EPP en Linux

• Hay desacuerdo sobre si merece la pena ejecutar AV/EPP en escritorios Linux.
  • Críticos: el AV debe ejecutarse con privilegios muy altos, aumentando la superficie de ataque, y ofrece poca defensa frente a adversarios capaces.
  • Defensores: la seguridad es por capas; aunque imperfecto, el EPP puede atrapar muchas cargas útiles conocidas y toolkit comunes (Metasploit, binarios recodificados) y tiene un coste de fricción relativamente bajo en escritorios.
• Se menciona el soporte de Ubuntu para ClamAV; sin embargo, se lo caracteriza como mayoritariamente basado en firmas y centrado en malware conocido (a menudo de Windows), con valor limitado frente a amenazas nuevas en Linux.

Gestión de paquetes y riesgo de cadena de suministro

• Varios comentarios contraponen los gestores de paquetes de las distribuciones (con repositorios firmados con GPG) a herramientas del ecosistema como pip/npm/cpan, que a menudo dependen solo de TLS y tienen un linaje de procedencia más débil.
• Se considera más difícil y más visible comprometer repositorios de distribuciones (muchas claves, validación GPG, posible uso de Certificate Transparency), mientras que los paquetes a nivel de lenguaje pueden secuestrarse o reemplazarse con más facilidad.
• Se plantea el riesgo de actualizaciones maliciosas o paquetes abandonados (incidentes estilo “left-pad”); los lockfiles ayudan, pero también retrasan los parches de seguridad.
• Para adversarios de alto nivel, se menciona como preocupación la interceptación mediante certificados TLS falsos, pero la firma GPG y los logs de CT complican esos ataques.

Herramientas de detección y arquitecturas alternativas

• Herramientas tradicionales como chkrootkit se consideran de utilidad moderna limitada; el malware sofisticado puede evadir escáneres simples basados en firmas.
• Algunos miran hacia soluciones arquitectónicas:
  • Qubes OS (aislamiento fuerte por VM para cada tarea/app), aunque la adopción y el tamaño de la base de código preocupan.
  • ChromeOS por su modelo cerrado, aunque estrechamente ligado a Google.
  • Debian “Minimax” con la mayoría de las apps de usuario ejecutándose dentro de VMs dedicadas.