La nueva botnet NadMesh busca servicios de inteligencia artificial expuestos para claves de nube y tokens de Kubernetes – CYBERDEFENSA.MX

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

Un recolector Shodan mantiene la cola de escaneo abastecida con ComfyUI, Ollama, n8n, Open WebUI, Langflow y Gradio: los generadores de imágenes, los ejecutores de modelos locales y los creadores de flujos de trabajo que los equipos resisten rápidamente y cortan el firewall tarde.

La información de inteligencia detrás de ese mostrador muestra 47 lances de credenciales y 41 inventarios de modelos en sus últimos 100 registros. Esos inventarios llevan identificadores DeepSeek, GLM y Kimi etiquetados como: nube, lo que sugiere que lo que el catálogo de bots llega más allá de la caja misma.

Laboratorio XL de QiAnXin publicado un informe del viernes nombró al malware según la cadena «controlador de malla n4d» en su fuente y tomó una captura de pantalla del panel. Las cifras que contiene son del propio operador, capturadas el 10 de julio, y no concuerdan entre sí.

Un contador que indica 17.700 despliegues en total se encuentra encima de un embudo que afirma 95.700 en las últimas 24 horas. Un mosaico dice 16 bots activos; el siguiente dice 12. El número de credencial es al menos el que dice dos veces. Los propios sensores de XLab dan una medida externa, y tampoco es un recuento de bots: las distintas IP de origen que impulsaron NadMesh permanecieron cerca de cero hasta finales de junio, luego se volvieron verticales en la primera semana de julio a alrededor de 139 por día.

Ciberseguridad

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

Los investigadores lo expresaron claramente: el operador busca «no el host en sí, sino las credenciales de la nube, los privilegios del clúster de Kubernetes». El acceso a modelos y las herramientas MCP invocables completan la lista.

MCP encabeza el orden de prioridad de explotación del controlador, por encima de Kubernetes, Docker API y Redis, y los registros vectoriales XLab al lado son una herramienta/llamada JSON-RPC para ejecutar_comando. No se adjunta ningún CVE a esa línea y el informe no lo reclama.

MCP primera especificación poner la autenticación fuera del protocolo central por completo, y el flujo de autorización agregado en marzo de 2025 sigue siendo opcional en las propias palabras de la especificación. Muchas implementaciones lo omiten. censys contó 12,520 servicios MCP accesibles en 8,758 direcciones IP al 28 de abril, más de 21,000 al 6 de mayo y aproximadamente 90 anunciaban una herramienta que ejecuta comandos.

En 39 de ellos, la herramienta se llamó ejecutar_command, la llamada exacta en la parte superior de la tabla de NadMesh. Los propios contadores de MCP de la botnet no se concilian: 12.100 servicios de MCP enumerados como explotables, 21 vulnerabilidades de MCP en general y ninguna entre los 100 registros de inteligencia en pantalla.

Luego está lo que XLab realmente vio arrojar. La empresa registró el tráfico de exploits que observó y docker_containers_api_rce se lleva el 30,31 % del mismo, y jenkins_scripttext_rce otro 22,28 %. Las contraseñas débiles de Telnet se llevan el 10,36%, Redis el 8,29%.

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

Por lo tanto, el objetivo de la IA es real en la entrada y en el botín, y la mayor parte del tráfico de exploits todavía se dirige a los sockets Docker y las consolas Jenkins.

El escaneo se retroalimenta. Las subredes que producen visitas se vuelven a muestrear con mayor densidad cada cinco minutos; Las IP marcadas como peligrosas en las últimas 24 horas regresan cada cuarto de hora cuando /32 vuelve a escanear con los puertos AI primero; Un barrido completo arrastra de nuevo a la cima todo lo que ha sido marcado como peligroso en los últimos siete días.

Cualquier objetivo que absorba diez intentos de despliegue sin arrojar ningún resultado se incluye automáticamente en la lista negra como sospechoso de trampa. XLab lo toma como una señal de que el autor sabe que los investigadores están observando. Si la cola se agota, 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 30.0. Un punto final canario prepara nuevas compilaciones para una porción de la flota, 5448 respuestas atendidas y 84 024 nulas. Un embudo rastrea las tareas a través de implementaciones en hosts activos.

La propia nota a pie de página del panel es reveladora: el éxito se califica en una lista de resultados permitidos que excluye explícitamente la cosecha de Ollama y AWS. El marcador del operador no cuenta lo que el operador está tomando.

La eliminación está hecha para fallar. El agente persiste de tres maneras a la vez, por lo que, al tirar de uno, los demás lo recuperan. 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 muestra publicado captará esa compilación y perderá el resto.

Si ejecuta algo de esto

La mayor parte de lo que lanza NadMesh está dirigido a servicios expuestos y funcionalidades de administración que se pueden llamar: una API Docker abierta en 2375, una consola de script Jenkins, Redis no autenticado, Telnet débil y contraseñas SSH. Ningún parche cierra ninguno de ellos.

Consígalos detrás de la autenticación o fuera de la Internet pública, comenzando con los cuatro puertos que el trabajo de reexploración coloca primero: 8188 (ComfyUI), 11434 (Ollama), 7860 (Gradio) y 5678 (n8n).

También hay una cola de parches, y no todo es antiguo. El gráfico incluye CVE-2026-39987, el RCE previo a la autenticación en los portátiles Marimo anteriores a la 0.23.0. CISA lo puso en KEV en abril después de que fuera explotado pocas horas después de su divulgación.

Ciberseguridad

Junto a él se encuentra CVE-2026-41176, que permite a una persona que llama no autenticada cambiar rc.NoAuth en servidores rclone RC desde 1.45.0 hasta 1.73.5 que se iniciaron sin autenticación HTTP. Las configuraciones de rclone son credenciales de la nube. Las entradas más antiguas necesitan que se verifiquen sus condiciones antes de que entre en pánico: CVE-2022-22947 con un 6,48% solo afecta si el punto final del Spring Cloud Gateway Actuator está habilitado y expuesto sin seguridad, y CVE-2017-12611 con un 4,15% es la falla de la etiqueta Struts Freemarker.

Luego verifique las rutas de caída:

  • ~/.ssh/authorized_keys, para claves que nadie recuerda haber agregado
  • /dev/shm/.a, /var/tmp/.a, /tmp/.a
  • /etc/cron.d/.sys_monitor, /etc/cron.d/.s

Si surge algo de eso, aísle el host y revoque todas las credenciales que pueda ver de inmediato: claves de AWS, tokens de clúster, contenidos .env, inicios de sesión de registro. Revocar no es rotar. Tire de la persistencia antes de emitir reemplazos, o las nuevas claves seguirán el mismo camino que las antiguas.

Luego revise dónde se usaron los antiguos mientras estaban activos. Los indicadores de XLab son un C2 en 209.99.186[.]235, el dominio cdnorigin[.]net y una muestra de agente, SHA1 31c69b3e12936abca770d430066f379ec1d997ec.

Hacker News cubrió a un operador diferente que trabajaba con la misma clase objetivo en abril: Censys había descubierto que estaba cultivando ComfyUI expuesto para la GPUMonero y Conflux, además de un nodo proxy de Hysteria para reventa. Tres meses después, NadMesh barre una red mucho más amplia, pero ComfyUI y Docker expuestos en 2375 se encuentran en ambas listas de objetivos.

Lo que cambió es la recompensa: el operador de abril quería la GPU y NadMesh quiere aquello en lo que la caja puede iniciar sesión. Censys finalizó su censo de MCP con una suposición del resultado menos malo para todas esas herramientas de shell expuestas, y el host terminó siendo «parte de alguna futura botnet o infraestructura de abuso». Eso fue el 27 de mayo. XLab publicó una botnet con mcp_cmd_execute en su tabla de exploits siete semanas después.

Una falla sin parche en el servidor de repositorio de Argo CD podría permitir a los atacantes apoderarse de los clústeres de Kubernetes

CD Argouna herramienta ampliamente utilizada para implementar software en Kubernetes, tiene una falla sin parchear en su componente de servidor de repositorio que permite que un atacante no autenticado ejecute código, siempre que pueda alcanzar el puerto de red interno del componente.

sinácticoque encontró el error, dice que puede conducir a una toma de control total del clúster. No hay solución ni CVE. La empresa dice que informó la falla a los encargados de mantenimiento de Argo CD en enero de 2025; Aproximadamente dieciocho meses después, sigue sin parchear, por lo que publicó los detalles para advertir a los usuarios.

El error se encuentra en el servidor de repositorio, el componente de CD de Argo que lee los repositorios de Git y crea manifiestos de Kubernetes, los archivos que definen lo que implementa el clúster.

Su servicio gRPC interno no tiene autenticación; cualquiera que pueda acceder a él puede enviar una solicitud diseñada para ejecutar un comando. Synacktiv demostró el ataque contra Argo CD v2.13.3 y no informa ninguna versión parcheada; no publicó una lista completa de las versiones afectadas.

La técnica abusa personalizaruna herramienta estándar que ejecuta Argo CD para convertir archivos del repositorio en manifiestos. Kustomize tiene una opción –helm-command que apunta al binario de helm al que debe llamar.

Ciberseguridad

Synacktiv descubrió que una solicitud no autenticada al servicio GenerateManifest del servidor de repositorio puede establecer esa opción en un script, extraído de un repositorio Git controlado por un atacante. Cuando se ejecuta kustomize, ejecuta el script en lugar de helm.

Pero «interno» no significa aislado por defecto. CD Argo envía políticas de red de Kubernetes que separan el servidor de repositorio de todo excepto de sus propios componentes.

Synacktiv encontró el gráfico Helm, una forma común de instalar Argo CD, deja esas políticas desactivadas de forma predeterminadacon networkPolicy.create establecido en false. En esa configuración, un atacante que comprometa un solo pod en el clúster puede llegar al servidor de repositorio y desencadenar el error.

Ejecutar código en el servidor de repositorio no es el final. Synacktiv usó ese acceso para leer la contraseña de Redis del clúster desde una variable de entorno, conectarse al caché de Redis de Argo CD y envenenar los datos de implementación almacenados. En la siguiente sincronización automática, Argo CD implementó una carga de trabajo proporcionada por el atacante.

Ese paso revive CVE-2024-31989Cycode encontró una falla en 2024 donde Redis de Argo CD no tenía contraseña, lo que permitió que cualquier pod en el clúster envenenara el caché de implementación. Argo CD solucionó el problema agregando una contraseña de Redis, pero el caché en sí aún no está firmado, por lo que robar la contraseña vuelve a abrir el mismo ataque.

que hacer

No existe una versión parcheada, por lo que la defensa es el aislamiento de la red. Active las políticas de red de Kubernetes para que solo los componentes propios de Argo CD puedan llegar al servidor de repositorio y a los puertos de Redis. Argo CD proporciona los archivos de políticas; Los usuarios de Helm tienen que habilitarlos porque el gráfico los deja fuera.

Comprueba qué está activo con: kubectl obtiene la política de red -A. Una instalación saludable muestra una política de red por componente, incluido el servidor de repositorio y Redis. Si faltan esas políticas, se puede acceder al servidor de repositorio y a los puertos de Redis desde el resto del clúster.

Ciberseguridad

Synacktiv creó una herramienta, argo-cdown, que automatiza el ataque completo. Está reteniendo la herramienta por ahora para darles tiempo a los defensores para bloquear sus políticas de red, y dice que la publicará en GitHub más adelante para que los administradores puedan probar sus propias implementaciones.

Esta no es la primera vez que Argo CD expone sus propios componentes internos. En septiembre de 2025, parchó CVE-2025-55190donde un token API con solo acceso de lectura básico podría recuperar las credenciales del repositorio Git de un proyecto, una falla que The Hacker News señaló en ese momento.

En mayo de 2026, otro error, CVE-2026-42880permitió a los usuarios de solo lectura leer secretos de Kubernetes en texto sin formato. Es difícil pasar por alto el patrón: Argo CD concentra el acceso al clúster y los secretos del repositorio, y sus superficies internas siguen entregándolos, a una solicitud no autenticada en un error y a un token de privilegios bajos en el siguiente.

Hasta que se envíe un parche, tratar la red del clúster como hostil es la única defensa real.

Trivy Hack difunde Infostealer a través de Docker, Triggers Worm y Kubernetes Wiper – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han descubierto artefactos maliciosos distribuidos a través de Docker Hub luego del ataque a la cadena de suministro de Trivy, destacando el creciente radio de explosión en los entornos de desarrolladores.

La última liberación limpia conocida de trivia en Docker Hub es 0.69.3. Desde entonces, las versiones maliciosas 0.69.4, 0.69.5 y 0.69.6 se eliminaron de la biblioteca de imágenes del contenedor.

«Las nuevas etiquetas de imagen 0.69.5 y 0.69.6 se publicaron el 22 de marzo sin las correspondientes versiones o etiquetas de GitHub. Ambas imágenes contienen indicadores de compromiso asociados con el mismo ladrón de información de TeamPCP observado en etapas anteriores de esta campaña», dijo el investigador de seguridad de Socket, Philipp Burckhardt. dicho.

El desarrollo se produce a raíz de un compromiso de la cadena de suministro de Trivy, un popular escáner de vulnerabilidades de código abierto mantenido por Aqua Security, que permite a los actores de amenazas aprovechar una credencial comprometida para impulsar a un ladrón de credenciales dentro de versiones troyanizadas de la herramienta y dos acciones de GitHub relacionadas «aquasecurity/trivy-action» y «aquasecurity/setup-trivy».

Ciberseguridad

El ataque ha tenido impactos posteriores, ya que los atacantes aprovecharon los datos robados para comprometer docenas de paquetes npm y distribuir un gusano autopropagante conocido como CanisterWorm. Se cree que el incidente es obra de un actor de amenazas rastreado como TeamPCP.

Según el equipo de OpenSourceMalware, los atacantes han desfigurado los 44 repositorios internos asociados con Aqua Security.aquasec-com» organización GitHub cambiando el nombre de cada uno de ellos con el prefijo «tpcp-docs-«, estableciendo todas las descripciones en «TeamPCP posee Aqua Security» y exponiéndolas públicamente.

Se dice que todos los repositorios se modificaron en una ráfaga programada de 2 minutos entre las 20:31:07 UTC y las 20:32:26 UTC del 22 de marzo de 2026. Se ha evaluado con alta confianza que el actor de amenazas aprovechó una cuenta de servicio «Argon-DevOps-Mgt» comprometida para este propósito.

«Nuestro análisis forense de la API de GitHub Events apunta a un token de cuenta de servicio comprometido, probablemente robado durante el compromiso anterior de Trivy GitHub Actions de TeamPCP, como vector de ataque», dijo el investigador de seguridad Paul McCarty. dicho. «Esta es una cuenta de servicio/bot (ID de GitHub 139343333, creada el 12 de julio de 2023) con una propiedad crítica: une ambas organizaciones de GitHub».

«Un token comprometido para esta cuenta le da al atacante acceso de escritura/administración a ambas organizaciones», agregó McCarty.

El desarrollo es la última escalada de un actor de amenazas que se ha ganado una reputación por apuntar a infraestructuras de nube, mientras construye progresivamente capacidades para exponer sistemáticamente las API de Docker, los clústeres de Kubernetes, los paneles de Ray y los servidores Redis para robar datos, implementar ransomware, realizar extorsión y extraer criptomonedas.

Su creciente sofisticación se ejemplifica mejor con la aparición de un nuevo malware de limpieza que se propaga a través de SSH a través de claves robadas y explota las API de Docker expuestas en el puerto 2375 en toda la subred local.

Se ha descubierto que una nueva carga útil atribuida a TeamPCP va más allá del robo de credenciales y borra clústeres completos de Kubernetes (K8) ubicados en Irán. El script de shell utiliza el mismo recipiente ICP vinculado a CanisterWorm y luego ejecuta comprobaciones para identificar los sistemas iraníes.

Ciberseguridad

«En Kubernetes: implementa DaemonSets privilegiados en cada nodo, incluido el plano de control», investigador de seguridad de Aikido, Charlie Eriksen. dicho. «Los nodos iraníes se borran y se reinician a la fuerza a través de un contenedor llamado ‘kamikaze’. Los nodos no iraníes instalan la puerta trasera CanisterWorm como un servicio systemd. Los hosts iraníes que no son K8 obtienen ‘rm -rf / –no-preserve-root’».

Dada la naturaleza continua del ataque, es imperativo que las organizaciones revisen su uso de Trivy en las canalizaciones de CI/CD, eviten el uso de versiones afectadas y traten cualquier ejecución reciente como potencialmente comprometida.

«Este compromiso demuestra la larga cola de ataques a la cadena de suministro», dijo OpenSourceMalware. «Una credencial obtenida durante el compromiso de Trivy GitHub Actions hace meses fue utilizada como arma hoy para desfigurar toda una organización interna de GitHub. La cuenta de servicio Argon-DevOps-Mgt, una única cuenta de bot que une dos organizaciones con un PAT de larga duración, era el eslabón débil».

«Desde la explotación de la nube hasta los gusanos de la cadena de suministro y los limpiadores de Kubernetes, están creando capacidades y apuntando al propio ecosistema de proveedores de seguridad. La ironía de que una empresa de seguridad en la nube se vea comprometida por un actor de amenazas nativo de la nube no debe pasar desapercibida para la industria.