Un hacker ejecuta el agente de inteligencia artificial de Hermes sin supervisión para su posterior explotación en el Ministerio de Finanzas tailandés

Alguien instaló un popular asistente de inteligencia artificial en un servidor alquilado, desactivó la configuración que le hace pedir permiso antes de ejecutar comandos arriesgados y apuntó al Ministerio de Finanzas de Tailandia, que gestiona la tesorería y la recaudación de impuestos del país.

Luego, el agente trabajó solo a través de la red del ministerio, verificando los hosts en busca de formas de obtener acceso raíz, buscando en los sistemas de archivos y rastreando una carpeta de registros de personal que se remontaba a 2012.

El operador dejó los propios registros del agente en un servidor web con el listado de directorios activado, donde la firma de inteligencia de amenazas Hunt.io y el investigador Bob Diachenko los encontraron, junto con 585 archivos y 470 MB de herramientas de ataque.

La herramienta es Hermesun asistente de código abierto de Nous Research que las personas instalan para administrar su correo, realizar tareas domésticas y recibir instrucciones a través de Telegram o Slack. No es una herramienta de piratería y no hay ningún defecto en ella.

El modo que utilizó el operador, llamado YOLO, es una característica documentada con su propio indicador de línea de comando. Eso es lo que separa este caso de los ataques asistidos por IA de los que se ha informado hasta ahora.

Cuando Antrópico revelado un grupo chino que utilizó Claude Code para espionaje en noviembre pasado, los atacantes tuvieron que engañar al modelo para que cooperara y Anthropic prohibió sus cuentas una vez que se dio cuenta. Hermes funciona en la propia máquina del operador. Ningún proveedor estaba mirando y no había ninguna cuenta que prohibir.

Ciberseguridad

El operador ya estaba dentro antes de que comenzara el agente. Hunt.io recuperó un shell web oculto instalado en un servidor web del ministerio, scripts escritos en sistemas Hadoop internos con nombre y contraseñas de buzones de correo robadas codificadas en un script de prueba de correo.

Nada en los archivos recuperados muestra datos que salen de la red y se desconoce cómo entró el operador por primera vez. El 15 de julio se notificó al CERT nacional de Tailandia y a la agencia de ciberseguridad; ninguno había publicado nada cuando The Hacker News lo revisó el 24 de julio.

Para todos los demás, el detalle útil es para qué fueron creados los scripts del operador: un servicio de base de datos Hadoop que acepta cualquier contraseña de forma predeterminada.

El humano hizo las partes que requieren conocer el objetivo. El artículo de Hunt.io muestra una lista de contraseñas creada a partir de las abreviaturas de los propios departamentos del ministerio en lugar de un diccionario, y un código shell que lleva rutas codificadas a la intranet del ministerio.

El agente hizo la parte repetitiva: ejecutar un análisis, leer el resultado, decidir qué comprobar a continuación y ejecutar otro. Nada en el material recuperado muestra que haya encontrado una nueva vulnerabilidad o elegido el objetivo.

Ninguna de las órdenes era exótica. LinPEASun script estándar que busca rutas de escalada de privilegios en Linux. Una búsqueda de archivos con permisos elevados. Un rastreo de directorio. Una persona escribiría las mismas cosas. Lo que cambió es que nadie tenía que aprobar cada uno.

Hermes ofrece esa configuración de tres maneras: un indicador –yolo en el inicio, un comando /yolo a mitad de sesión o una variable de entorno HERMES_YOLO_MODE=1. el proyecto guía de configuración dice «usar esto sólo en entornos seguros y aislados».

Una capa sobrevive: una lista de bloqueo de línea dura que todavía rechaza comandos que borrarían la máquina en la que se está ejecutando el agente. Lo que el operador desconectó fue el control humano, no todas las salvaguardias.

Lo que hizo el agente

Cinco archivos llamados call_00_*.txt mantienen los turnos del agente: escaneo de vulnerabilidades del kernel contra un host ministerial, una segunda ejecución de LinPEAS, un barrido de binarios con permisos elevados, un listado del sistema de archivos y un rastreo recursivo de la raíz web perteneciente a la Oficina del Secretario Permanente.

Esa carpeta contenía documentos de Office, evaluaciones de desempeño y registros de personal que datan de 2012. Los registros muestran al agente leyendo el directorio. Ninguno de ellos muestra los archivos que lo abandonan.

El script de escaneo que le entregaron no era original. Un linpeas.sh personalizado comprobó cuatro fallas del kernel de Linux 2026 en tres familias: Copy Fail (CVE-2026-31431), Dirty Frag (CVE-2026-43284 y CVE-2026-43500) y clon sucio (CVE-2026-43503).

Cada uno entrega una raíz de usuario local donde se cumplen sus requisitos previos, lo que para Dirty Frag y DirtyClone significa CAP_NET_ADMIN. Todos tenían semanas de antigüedad cuando el operador los preparó, y nada recuperado nombra una versión del kernel del ministerio ni muestra que alguno de los cuatro se haya ejecutado.

La propia sesión SSH del operador en el servidor provisional provino de 103.97.0[.]57 en Hong Kong. La contraseña de la interfaz web del agente contiene la palabra china Leishen, dios del trueno, y junto a ella se encuentra una clave para FOFA, un servicio chino de búsqueda de activos.

El mismo servidor anteriormente alojaba un controlador ShadowPad y ahora ejecuta un escucha de comando y control VShell. Hunt.io evalúa con confianza baja a media que el operador habla chino o domina el idioma, y ​​no nombra ningún grupo. La empresa y Diachenko siguen siendo la única fuente pública de las conclusiones específicas del ministerio.

La ruta hacia Hadoop

La mayor parte del código personalizado se envió al clúster Hadoop del ministerio, donde almacena y consulta grandes volúmenes de datos. Un script llamado hive_rce_py2.py se conecta a HiveServer2, la interfaz SQL de ese clúster, en una máquina interna en el puerto 10000, y envía una contraseña.

Documentación propia de Apache. dice que el modo de autenticación predeterminado es NINGUNO, que acepta cualquier contraseña que se le proporcione sin verificarla.

Una vez conectado, el script instala un complemento Java malicioso llamado HiveCmd.jar como una función definida por el usuario, que le permite ejecutar comandos del sistema operativo a través de consultas ordinarias de bases de datos y leer los resultados. Cloudera advierte que cualquiera que pueda instalar dicha función puede ejecutar código arbitrario como la cuenta de servicio de Hive y acceder a datos confidenciales.

Ciberseguridad

También se presenta en el servidor: un implante Go no documentado anteriormente que el operador llama Hades, creado para Windows y Linux en 62 copias. Hunt.io analizó uno de cada uno y encontró la misma base de código; los otros 60 no fueron examinados individualmente.

Sus direcciones codificadas vinculan el servidor de prueba con un segundo servidor de Hong Kong, aunque ningún artefacto recuperado muestra a Hades llegando a una máquina del ministerio. Secuencias de comandos separadas probaron las credenciales predeterminadas en una consola interna GlassFish, sin que se confirmara ninguna implementación, junto con código de explotación para tres fallas más antiguas en polkit, sudo e IIS 6.0.

que hacer

  • Compruebe si HiveServer2 se está ejecutando con la autenticación configurada en NINGUNA y restrinja quién puede instalar funciones definidas por el usuario. Ese valor predeterminado es en el que se escribió el script del operador.
  • Alerta cuando un proceso de servidor web abre una conexión a puertos internos de Hadoop como 10000 o 50070. Merece la pena echarle un vistazo a un servidor web que llega a un nodo de Hadoop.
  • Busque raíces web de forma recursiva en busca de archivos PHP con nombres de puntos iniciales que imiten los cachés del sistema. Este se encontraba en /storage/Counter/nine/.journald-cache.php y no aparece en una lista de directorio normal.
  • Parche los kernels contra las cuatro fallas de 2026 anteriores, además de sudo a 1.9.5p2 o posterior, polkit para CVE-2021-4034 y cualquier IIS 6.0 WebDAV restante.

El agente deja su propio rastro. El panel web de Hermes devuelve un encabezado del servidor HermesWebUI, y una búsqueda en esa cadena arrojó aproximadamente 5.900 eventos de escaneo durante un mes, según el informe de Hunt.io del 23 de julio, contando avistamientos en lugar de máquinas distintas.

El mejor gancho es donde el agente escribe sus resultados: una carpeta /hermes-results/ consistente con nombres de archivos predecibles, que arrojó 575 visitas en el índice de directorios expuestos de Hunt.io el mismo día, cada uno de los cuales es un par de host y nombre de archivo. Ningún control de seguridad expuso a este operador. Una lista de directorio lo hizo.

El punto final ve los mismos comandos de shell y las mismas herramientas en ambos sentidos. Nada en una línea de comando ordinaria anuncia que no hay nadie frente al teclado.

Tu MTTD se ve genial. Su brecha posterior a la alerta no – CYBERDEFENSA.MX

Anthropic restringió su modelo Mythos Preview la semana pasada después de que encontró y explotó de forma autónoma vulnerabilidades de día cero en todos los principales sistemas operativos y navegadores. Wendi Whitmore, de Palo Alto Networks, advirtió que capacidades similares están a semanas o meses de proliferar. El Informe sobre amenazas globales de 2026 de CrowdStrike sitúa el tiempo medio de inicio de los delitos electrónicos en 29 minutos. M-Trends 2026 de Mandiant muestra que los tiempos de transferencia del adversario se han reducido a 22 segundos.

La ofensiva es cada vez más rápida. La pregunta es dónde exactamente los defensores son lentos, porque no es donde sugieren la mayoría de los paneles de SOC.

Las herramientas de detección han mejorado sustancialmente. Las plataformas EDR, seguridad en la nube, seguridad del correo electrónico, identidad y SIEM se entregan con una lógica de detección incorporada que lleva el MTTD cerca de cero para técnicas conocidas. Esto es un progreso real y es el resultado de años de inversión en ingeniería de detección en toda la industria.

Pero cuando los adversarios operan en plazos medidos en segundos y minutos, la pregunta no es si las detecciones se realizan con la suficiente rapidez. Es lo que sucede entre que se activa la alerta y que alguien realmente la detecta.

La brecha posterior a la alerta

Después de que se activa la alerta, el reloj sigue corriendo. Un analista tiene que verlo, recogerlo, reunir el contexto de todo el conjunto, investigar, tomar una determinación e iniciar una respuesta. En la mayoría de los entornos SOC, esa secuencia es donde realmente vive la mayor parte de la ventana operativa del atacante.

El analista está a mitad de una investigación sobre otra cosa. La alerta entra en una cola. El contexto se distribuye en cuatro o cinco herramientas. La investigación en sí requiere consultar el SIEM, verificar los registros de identidad, obtener telemetría de los puntos finales y correlacionar los cronogramas. Para una investigación exhaustiva, una que resulte en una determinación defendible, no en un cierre visceral, son de 20 a 40 minutos de trabajo práctico, suponiendo que el analista comience de inmediato, lo que rara vez hace.

En una ventana de fuga de 29 minutos, la investigación aún no había comenzado cuando el atacante se movió lateralmente. En un traspaso de 22 segundos, es posible que la alerta todavía esté en la cola.

MTTD no captura nada de esto. Mide la rapidez con la que se activa la detección y, en ese frente, la industria ha logrado avances genuinos. Pero esa métrica se detiene en la alerta. No dice nada sobre cuánto duró realmente la ventana posterior a la alerta, cuántas alertas recibieron una investigación real versus un vistazo rápido, o cuántas se cerraron de forma masiva sin un análisis significativo. MTTD informa sobre la parte del problema en la que la industria ya ha logrado avances reales. La exposición posterior (la brecha de investigación posterior a la alerta) no se refleja en ninguna parte.

¿Qué cambia cuando la IA se encarga de la investigación?

Una investigación impulsada por IA no mejora la velocidad de detección. MTTD es una métrica de ingeniería de detección y sigue siendo la misma. Lo que la IA comprime es la línea de tiempo posterior a la alerta, que es exactamente donde vive la exposición real.

La cola desaparece. Cada alerta se investiga a medida que llega, independientemente de la gravedad o la hora del día. El ensamblaje del contexto que le tomó a un analista 15 minutos de cambio de pestañas ocurre en segundos. La investigación en sí (razonar a través de la evidencia, girar en función de los hallazgos y llegar a una determinación) se completa en minutos en lugar de una hora.

Esto es lo que construimos Profeta AI hacer. Investiga cada alerta con la profundidad y el razonamiento de un analista senior, a la velocidad de una máquina: planifica la investigación de forma dinámica, consulta las fuentes de datos relevantes y produce una conclusión transparente respaldada por evidencia. La brecha posterior a la alerta no existe en este modelo porque no hay cola ni tiempo de espera. Para los equipos que trabajan para lograr este punto de referencia, hemos publicado Pasos prácticos para reducir el tiempo de investigación a menos de dos minutos..

La misma restricción estructural se aplica al MDR. Los analistas de MDR enfrentan el mismo cuello de botella posterior a la alerta porque todavía están limitados por la capacidad de investigación humana. El cambio de la investigación humana subcontratada a la investigación con IA elimina ese límite por completo. cambiar lo que se vuelve medible sobre el rendimiento real de su SOC.

Las métricas que importan ahora

Una vez que la ventana post-alerta colapsa, las métricas de velocidad tradicionales dejan de ser los indicadores más informativos. El MTTI de dos minutos es significativo en el primer trimestre en el que lo informa. Después de eso, todo está en juego. La pregunta pasa de «¿qué tan rápido somos?» a «¿cuánto más fuerte se está volviendo nuestra postura de seguridad con el tiempo?»

Cuatro métricas capturan esto:

  1. Tasa de cobertura de la investigación. ¿Qué porcentaje del total de alertas recibe una investigación completa consistente en una línea completa de interrogatorio con pruebas? En un SOC tradicional, este número suele oscilar entre el 5 y el 15 por ciento. El resto se omite, se cierra de forma masiva o se ignora. En un SOC impulsado por IA, debería ser del 100 por ciento. Esta es la métrica más importante para comprender si su SOC realmente ve lo que sucede en su entorno.
  2. Cobertura de la superficie de detección. Cobertura de la técnica MITRE ATT&CK asignada a su biblioteca de detección, con brechas identificadas y rastreadas a lo largo del tiempo. Esto significa mapear continuamente la superficie de detección, identificar técnicas con cobertura débil o nula y marcar puntos únicos de falla o escenarios donde una sola regla de detección es lo único entre la organización y la ceguera total ante una técnica. Ingeniería de detección en un SOC impulsado por IA requiere repensar cómo se mantiene esta superficie.
  3. Velocidad de retroalimentación falsa positiva. ¿Con qué rapidez los resultados de la investigación influyen en el ajuste de la detección? En la mayoría de los SOC, este bucle se ejecuta en la memoria humana y en ciclos de revisión trimestrales. El objetivo es continuo: los resultados de la investigación deben fluir directamente hacia la optimización de la detección, la supresión del ruido y la mejora de la señal sin esperar una revisión programada.
  4. Tasa de creación de detección basada en la búsqueda. ¿Cuántas detecciones permanentes se crearon a partir de hallazgos de caza proactivos en comparación con la respuesta a incidentes? Esto mide si su programa de caza está ampliando su superficie de detección o simplemente genera informes. Las implementaciones más sólidas vinculan la búsqueda directamente con las brechas de detección en las que se ejecutan búsquedas basadas en hipótesis contra las técnicas con la cobertura más débil y luego se convierten los hallazgos confirmados en reglas de detección permanentes.

Estos las mediciones sólo importan una vez que la IA está realizando un trabajo de investigación realpero representan una visión fundamentalmente diferente del rendimiento del SOC que se orienta en torno a los resultados de seguridad en lugar del rendimiento operativo.

La revelación de Mythos cristalizó algo que la industria de la seguridad ya sabía pero no había interiorizado del todo: la IA está acelerando la ofensiva a un ritmo que hace insostenible la investigación a velocidad humana. La respuesta no es entrar en pánico por los exploits generados por la IA. Se trata de cerrar la brecha en la que los defensores son realmente lentos (la ventana de investigación posterior a la alerta) y comenzar a medir si esa brecha se está reduciendo.

Los equipos que pasen de informar sobre la velocidad de detección a informar sobre la cobertura de la investigación y la mejora de la detección tendrán una imagen más clara de su postura de riesgo real. Cuando los atacantes tienen IA trabajando para ellos, esa claridad importa.

La plataforma Agentic AI SOC de Prophet Security investiga cada alerta con la profundidad de un analista senior, optimiza continuamente las detecciones y ejecuta búsquedas de amenazas dirigidas contra brechas de cobertura. Visita Profeta Seguridad para ver cómo funciona.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.