La botnet NadMesh, escrita en Go, busca servicios de IA expuestos para robar credenciales de AWS y privilegios de Kubernetes. Aunque utiliza vulnerabilidades de MCP y otros servicios, gran parte de su tráfico se dirige a APIs de Docker y consolas de Jenkins. Se recomienda proteger los puertos de herramientas como Ollama y ComfyUI tras autenticación y revisar archivos temporales en busca de persistencia.





Una botnet de Go llamada NadMesh apareció a principios de julio buscando servicios de IA expuestos, y el propio panel del operador afirma tener 3.811 claves de AWS únicas.

Un recolector de Shodan mantiene la cola de escaneo abastecida con ComfyUI, Ollama, n8n, Open WebUI, Langflow y Gradio: los generadores de imágenes, ejecutores de modelos locales y constructores de flujos de trabajo que los equipos despliegan rápido y protegen con firewall demasiado tarde.

El flujo de inteligencia detrás de ese contador muestra 47 capturas de credenciales y 41 inventarios de modelos en sus últimos 100 registros. Esos inventarios llevan identificadores de DeepSeek, GLM y Kimi etiquetados como :cloud, lo que sugiere que lo que los bots catalogan va más allá de la propia máquina.

XLab de QiAnXin publicó un informe el viernes, nombrando al malware según la cadena "n4d mesh controller" en su código fuente, y mostró capturas del panel. Las cifras en él son del propio operador, capturadas el 10 de julio, y no coinciden entre sí.

Un contador que indica 17.700 despliegues totales se sitúa sobre un embudo que afirma 95.700 en las últimas 24 horas. Un recuadro dice 16 bots activos; el siguiente dice 12. El número de credenciales es al menos el único que aparece dos veces. Los propios sensores de XLab dan una medida externa, y tampoco es un recuento de bots: las IPs de origen distintas que impulsan NadMesh estaban cerca de cero hasta finales de junio, y luego subieron verticalmente en la primera semana de julio hasta unos 139 al día.

Lo que un bot envía a casa son claves de nube extraídas de variables de entorno, tokens de cuentas de servicio de k8s y el contenido de ~/.aws/config, .env y ~/.docker/config.json.

Los investigadores lo dicen claramente: el operador no busca "el host en sí, sino las credenciales de la nube y los privilegios del clúster de Kubernetes" que haya en él. El acceso a modelos y las herramientas MCP llamables completan la lista.

MCP encabeza el orden de prioridad de explotación del controlador, por encima de Kubernetes, la API de Docker y Redis, y el vector que registra XLab a su lado es una llamada tools/call de JSON-RPC para ejecutar execute_command. No hay ningún CVE asociado a esa línea y el informe no afirma que exista uno.

La primera especificación de MCP puso la autenticación totalmente fuera del protocolo central, y el flujo de autorización añadido en marzo de 2025 sigue siendo opcional según sus propias palabras. Muchos despliegues lo omiten. Censys contó 12.520 servicios MCP alcanzables en 8.758 direcciones IP el 28 de abril, más de 21.000 para el 6 de mayo, y aproximadamente 90 anunciando una herramienta que ejecuta comandos.

En 39 de esos, la herramienta se llamaba execute_command, la llamada exacta en la parte superior de la tabla de NadMesh. Los propios contadores de MCP de la botnet no cuadran: 12.100 servicios MCP listados como explotables, 21 vulnerabilidades de MCP en general, y ninguna en los 100 registros de inteligencia en pantalla.

Luego está lo que XLab realmente vio que lanzaba. La firma trazó el tráfico de exploits que observó, y docker_containers_api_rce representa el 30,31%, jenkins_scripttext_rce otro 22,28%. Las contraseñas débiles de Telnet representan el 10,36%, y Redis el 8,29%.



mcp_cmd_execute aparece en el gráfico, por lo que el vector está en el tráfico observado por XLab, pero se encuentra en la cola sin etiqueta por debajo de la porción más pequeña que alguien se molestó en etiquetar, con un 0,78%. Las etiquetas del gráfico no coinciden con las cadenas de estado del controlador, por lo que es la vista de intentos de los sensores de XLab, no el libro de éxitos del operador.

Así que el objetivo de la IA es real en la entrada y en el botín, aunque la mayor parte del tráfico de exploits sigue yendo a los sockets de Docker y consolas de Jenkins.

El escaneo se alimenta a sí mismo. Las subredes que producen aciertos se vuelven a muestrear con más densidad cada cinco minutos; las IPs marcadas como peligrosas en las últimas 24 horas vuelven cada cuarto de hora como reescaneos /32 con los puertos de IA primero; un barrido completo vuelve a subir todo lo marcado como peligroso en los últimos siete días.

Cualquier objetivo que absorba diez intentos de despliegue sin devolver nunca un resultado es bloqueado automáticamente en una lista negra como sospecha de honeypot. XLab toma esto como una señal de que el autor sabe que los investigadores están vigilando. Si la cola se vacía, los bots generan un /24 aleatorio y continúan.

Cinco versiones de compilación se ejecutan simultáneamente, once bots en 33.8-GO-TITAN y los rezagados en la 30.0. Un endpoint canario prepara nuevas compilaciones para una parte de la flota, con 5.448 respuestas servidas y 84.024 nulas. Un embudo rastrea las tareas a través de los despliegues hasta los hosts activos.



La propia nota al pie del panel es la clave: el éxito se puntúa en una lista de permitidos de resultados que excluye explícitamente la recolección de Ollama y AWS. El marcador del operador no cuenta lo que el operador se está llevando.

La eliminación está diseñada para fallar. El agente persiste de tres maneras a la vez, por lo que eliminar uno deja que los otros lo recuperen. Cada compilación pasa por ofuscación Garble, empaquetado UPX -9 y relleno aleatorio, lo que significa que no hay dos agentes que compartan un hash. El hash de la muestra publicada capturará esa compilación y perderá el resto.