NadMesh el botnet Go que roba credenciales en la nube y facilita el acceso a IA y Kubernetes

Un nuevo botnet escrito en Go, apodado NadMesh por los investigadores, ha cambiado el blanco tradicional de cripto-minería por algo más valioso para la economía actual: credenciales y accesos a servicios de IA y herramientas de gestión rápidas de desplegado. En lugar de centrarse en la potencia bruta del GPU, este operador busca claves de nube, tokens de Kubernetes y credenciales que permitan al atacante pivotar desde una máquina comprometida hasta servicios gestionados y modelos.

El cuadro que muestran los análisis públicos refleja una campaña que combina escaneo masivo con extracción selectiva de secretos: escáneres tipo Shodan rellenan la cola con instancias de ComfyUI, Ollama, n8n, Open WebUI, Langflow y Gradio —servicios que muchos equipos arrancan con rapidez y que a menudo quedan expuestos por defecto—, mientras que los agentes intentan sacar ~/.aws/config, variables de entorno, tokens de servicio k8s y ficheros de configuración de registries. El objetivo no es “la caja” sino lo que la caja sabe o puede autenticarse a través de ella.

El vector técnico incluye viejos favoritos (socket de Docker expuesto, consola de Jenkins, Redis sin autenticar, Telnet con contraseñas débiles) y llamadas a herramientas remotas: en los datos observados prevalecen intentos al Docker API y a Jenkins, pero también aparece una llamada mcp_cmd_execute hacia servicios que implementan MCP, un protocolo cuya especificación histórica dejó la autenticación fuera del flujo principal y cuya adopción parcial deja muchas instancias sin protección adecuada. La existencia de servicios MCP abiertos y de herramientas que permiten ejecutar comandos en remoto amplifica el riesgo para quienes exponen interfaces de administración sin control.

La campaña muestra sofisticación operativa: múltiples versiones del agente en paralelo, ofuscación y empaquetado con Garble y UPX para que cada binario tenga firma distinta, mecanismos de persistencia redundante y una lógica de reescan y priorización que evita honeypots autoexcluyéndolos tras intentos fallidos. Por eso, firmas estáticas tradicionales y hashes únicos son insuficientes para detección y remediación a gran escala.

Las implicaciones son claras y prácticas. Comprometer una máquina con acceso a la nube no es simplemente pérdida de esa máquina: es posible el uso fraudulento de servicios cloud, extracción de modelos, abuso de tokens para moverse lateralmente dentro de clústeres Kubernetes y la exposición de secretos que permiten provisionar nueva infraestructura a costa de la víctima. Un host expuesto puede transformarse en pasarela hacia cientos o miles de recursos en la nube si no se actúa con rapidez y criterio.

Las medidas defensivas inmediatas no requieren parches milagrosos: lo prioritario es aislar y proteger las interfaces administrativas. Cerrar al público los puertos que la campaña rescanea primero (por ejemplo 8188, 11434, 7860 y 5678), bloquear el socket Docker en 2375 de acceso remoto, asegurar consolas de Jenkins y exigir autenticación en Redis y n8n reduce enormemente la superficie de ataque. Además, aplicar control de acceso en servicios MCP y habilitar cualquier mecanismo de autenticación y autorización disponible debe ser tratado como urgente en despliegues expuestos.

Si sospecha compromiso, la respuesta debe seguir un orden concreto: aislar el host afectado, buscar rastros de persistencia en ubicaciones como /dev/shm, /var/tmp, /tmp, /etc/cron.d y en ~/.ssh/authorized_keys, y solamente después de eliminar todas las trazas de persistencia proceder a revocar credenciales y tokens. Revocar sin retirar primero las puertas traseras es regalar las nuevas credenciales al atacante.

La detección debe complementarse con telemetría: monitoree patrones de reescaneo, picos de intentos desde IPs que vuelven a aparecer con frecuencia y llamadas a endpoints de ejecución remota. Dado que el operador evita contar públicamente ciertos robos y que los binarios cambian de huella, use indicadores de comportamiento y de red junto con listas de IOCs públicas (por ejemplo, IPs de C2 o dominios asociados) y herramientas de detección en la nube para correlacionar actividad anómala. Para referencia sobre el alcance que puede tener el escaneo de servicios remotos y censos de exposición vea Censys: https://censys.io.

En la capa de gobierno y arquitectura, la lección dura es aplicar el principio de menor privilegio, rotación y separación de credenciales (evitar dejar claves largas en variables de entorno o ficheros de configuración), y auditar el uso de herramientas que habilitan ejecución remota sin autenticar. La documentación de Kubernetes sobre RBAC y cómo acotar permisos de cuentas de servicio es un buen punto de partida para reducir el alcance de tokens comprometidos: https://kubernetes.io/docs/reference/access-authn-authz/rbac/.

También conviene vigilar listas y catálogos de vulnerabilidades explotadas de forma activa y priorizar parches para las piezas que sí admiten explotación remota preautenticada. Para mantenerse actualizado sobre vulnerabilidades con explotación conocida, la referencia consolidada de CISA es útil: https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

Finalmente, la observación operativa del informe apunta a un cambio de negocio criminal: extraer acceso a la nube y a modelos es más rentable y más difícil de revertir que robar ciclos de GPU o minar criptomonedas en el host. Defensores que traten las máquinas como meros endpoints en lugar de como llaves hacia sistemas mayores seguirán perdiendo la carrera. Inventario activo, segmentación de la administración, autenticación obligatoria y respuesta coordinada ante incidentes (aislar, eliminar persistencia, revocar y revisar uso) son las acciones que más rápidamente reducen el riesgo tangible que NadMesh y campañas similares ponen sobre las organizaciones.