Hackers utilizan agentes de IA ARTEX para automatizar ataques a Active Directory, Kerberoasting y movimiento lateral
Descubre cómo ARTEX utiliza agentes de inteligencia artificial para automatizar ataques a Active Directory, Kerberoasting, DCSync y movimiento lateral. Conoce los riesgos, IoC y medidas de protección para AWS, Microsoft 365 y entornos empresariales.
Introducción: la inteligencia artificial acelera los ciberataques
La inteligencia artificial está transformando el panorama de la ciberseguridad, pero no solamente desde el punto de vista defensivo. Los ciberdelincuentes también están aprovechando los avances en IA generativa para automatizar operaciones ofensivas que tradicionalmente requerían conocimientos técnicos especializados, herramientas diferentes y muchas horas de trabajo.
Uno de los ejemplos más preocupantes es ARTEX, una plataforma de pentesting ofensivo basada en múltiples agentes de inteligencia artificial que está siendo utilizada por actores maliciosos para automatizar diferentes fases de una intrusión informática.
Según una investigación publicada el 30 de octubre de 2026 por Google Cloud Threat Intelligence Group (GTIG) y Mandiant, diferentes grupos de amenazas han utilizado ARTEX y otros frameworks similares durante operaciones reales contra organizaciones de distintos sectores.
La herramienta puede realizar reconocimiento de redes Windows, enumerar objetos de Active Directory, identificar cuentas de servicio, ejecutar ataques Kerberoasting, intentar escalar privilegios y desplegar técnicas de movimiento lateral. Todo ello mediante agentes especializados que reciben objetivos y coordinan la ejecución de comandos.
La principal diferencia respecto a los ataques tradicionales es la velocidad: algunas secuencias de actividad se ejecutan en apenas unos segundos.
Esto supone un cambio importante para los equipos de seguridad. Ya no basta con detectar herramientas maliciosas o bloquear indicadores de compromiso conocidos. Ahora es necesario identificar comportamientos anómalos, limitar los privilegios de las identidades y reducir la capacidad de movimiento de un atacante incluso cuando utiliza credenciales legítimas.
¿Qué es ARTEX y cómo funcionan sus agentes de inteligencia artificial?
ARTEX es una plataforma de pentesting automatizado y mando y control (C2), desarrollada en Go, que utiliza una arquitectura multiagente basada en modelos de lenguaje (LLM).
Su objetivo es convertir instrucciones de alto nivel en acciones técnicas ejecutables dentro de una infraestructura objetivo.
En lugar de depender de un operador que tenga que ejecutar manualmente cada herramienta, interpretar los resultados y decidir el siguiente paso, ARTEX distribuye las tareas entre diferentes agentes especializados.
El atacante puede proporcionar un objetivo y credenciales previamente comprometidas. A partir de ahí, el framework puede investigar el entorno, identificar oportunidades de escalada de privilegios y probar diferentes rutas de acceso.
Entre sus capacidades observadas destacan:
- Reconocimiento automatizado de Active Directory.
- Enumeración de usuarios, grupos y cuentas de servicio.
- Identificación de configuraciones vulnerables de Active Directory Certificate Services (AD CS).
- Ejecución de ataques Kerberoasting.
- Obtención de información privilegiada mediante técnicas DCSync.
- Movimiento lateral mediante WinRM, Pass-the-Hash y Pass-the-Ticket.
- Reconocimiento de permisos y recursos en AWS y Azure.
- Preparación de mecanismos de persistencia.
- Automatización de la recopilación y posible exfiltración de información.
El framework ARTEX y la arquitectura multiagente
La investigación de Google describe ARTEX como un sistema organizado en seis subagentes especializados que coordinan distintas operaciones ofensivas.
Esta arquitectura permite dividir objetivos complejos en tareas más pequeñas, ejecutar acciones en paralelo y adaptar los siguientes pasos a los resultados obtenidos.
Es importante destacar que ARTEX no representa una nueva vulnerabilidad de Windows ni un nuevo protocolo de ataque. Su peligrosidad reside en la automatización y coordinación de técnicas que ya existen.
El framework original fue retirado de GitHub por su autor en octubre de 2026 debido al abuso detectado. Sin embargo, el código continúa circulando mediante forks comunitarios, como ScopeWeaver, y versiones comerciales como ARTEX PRO.
Por tanto, la eliminación del repositorio original no significa que la amenaza haya desaparecido.
ARTEX en ataques reales: organizaciones bajo amenaza
Google Cloud y Mandiant han observado el uso de ARTEX desde finales de agosto de 2026 durante diferentes investigaciones de incidentes de seguridad.
Las organizaciones afectadas pertenecen a sectores estratégicos, entre ellos:
- Administraciones públicas y organismos gubernamentales.
- Empresas tecnológicas.
- Industria química y de materiales.
- Fabricación y manufactura.
- Telecomunicaciones.
- Entornos industriales y empresariales.
Uno de los casos más relevantes está relacionado con la actividad identificada por Google como UNC7228, que presenta solapamientos con el actor identificado por Microsoft como STORM-0940, vinculado a China.
La investigación también describe operaciones en las que los atacantes utilizaron credenciales legítimas previamente comprometidas para facilitar el acceso inicial y delegar en ARTEX las siguientes fases de la intrusión.
Esto demuestra que los agentes de IA no necesitan necesariamente explotar una vulnerabilidad nueva para resultar efectivos. En muchos escenarios, basta con disponer de una cuenta válida y suficientes permisos para comenzar a explorar la infraestructura.
Cómo ARTEX automatiza los ataques a Active Directory
Active Directory continúa siendo uno de los objetivos más importantes para los atacantes porque centraliza la autenticación, las identidades, los grupos y buena parte de los permisos de una organización.
Cuando un atacante consigue acceso a una cuenta del dominio, puede intentar utilizarla para descubrir usuarios privilegiados, cuentas de servicio, relaciones de confianza y sistemas críticos.
ARTEX automatiza buena parte de este reconocimiento mediante scripts de PowerShell y herramientas nativas de Windows.
Durante los incidentes analizados, los investigadores observaron:
- Enumeración masiva de usuarios y grupos.
- Identificación de cuentas administradas y Group Managed Service Accounts (gMSA).
- Análisis de relaciones de confianza entre bosques.
- Revisión de plantillas de certificados AD CS.
- Consultas contra controladores de dominio y servidores de federación.
- Identificación de cuentas con privilegios administrativos.
En uno de los incidentes, ARTEX llegó a recopilar más de 110.000 objetos de Active Directory y obtuvo información sobre el grupo Domain Admins.
Esta capacidad permite construir rápidamente un mapa de la infraestructura corporativa y localizar las identidades que pueden facilitar una escalada de privilegios.
Kerberoasting: robo de tickets de servicio para recuperar contraseñas
Una de las técnicas más relevantes observadas en estas operaciones es Kerberoasting.
Este ataque aprovecha el funcionamiento de Kerberos para solicitar tickets de servicio (TGS) asociados a cuentas que tienen configurado un Service Principal Name (SPN).
Los tickets pueden ser obtenidos por usuarios autenticados del dominio y posteriormente sometidos a ataques de fuerza bruta o diccionario fuera de línea para intentar recuperar la contraseña de la cuenta de servicio.
El riesgo aumenta cuando estas cuentas utilizan contraseñas débiles, antiguas o privilegios excesivos.
ARTEX automatiza la identificación de cuentas susceptibles de ser atacadas, la solicitud de tickets y la preparación de los datos para su análisis.
Medidas de protección frente a Kerberoasting:
- Utilizar Group Managed Service Accounts (gMSA) siempre que sea posible.
- Establecer contraseñas largas, aleatorias y resistentes para las cuentas de servicio que no puedan migrarse a gMSA.
- Evitar que las cuentas de servicio tengan privilegios administrativos innecesarios.
- Revisar periódicamente las cuentas que tienen configurados SPN.
- Monitorizar eventos de Windows relacionados con solicitudes de tickets Kerberos, especialmente el evento 4769.
- Investigar solicitudes anómalas de tickets para múltiples SPN en intervalos muy cortos.
- Evaluar el uso de cifrado AES y retirar configuraciones RC4 heredadas cuando sea compatible con la infraestructura.
La monitorización debe tener en cuenta el comportamiento habitual de cada cuenta y no depender únicamente de un umbral fijo de solicitudes.
DCSync: cuando el atacante intenta obtener los secretos del dominio
Después de una fase de reconocimiento y escalada de privilegios, ARTEX también ejecutó scripts relacionados con DCSync.
DCSync es una técnica que abusa de los permisos de replicación de Active Directory para solicitar información de credenciales a un controlador de dominio, simulando el comportamiento de otro controlador legítimo.
Entre la información que puede obtenerse se encuentran los hashes de contraseñas, incluido el hash de la cuenta krbtgt.
La cuenta krbtgt es especialmente sensible porque participa en la generación y validación de tickets Kerberos. Si un atacante obtiene su material criptográfico y consigue las condiciones necesarias, puede intentar realizar ataques Golden Ticket para suplantar identidades dentro del dominio.
En los incidentes investigados, Google observó intentos de obtener:
- El material criptográfico de
krbtgt. - Credenciales utilizadas por mecanismos de sincronización entre Active Directory y servicios cloud.
- Hashes de cuentas de controladores de dominio.
La obtención de estos datos puede comprometer gravemente la seguridad del dominio y facilitar ataques posteriores.
Remediaciones frente a DCSync:
- Revisar los permisos de replicación del directorio.
- Limitar los derechos
DS-Replication-Get-ChangesyDS-Replication-Get-Changes-Alla las identidades que realmente los necesitan. - Auditar los grupos Domain Admins, Enterprise Admins y Administrators.
- Supervisar los eventos 4662 y las operaciones de replicación sospechosas.
- Detectar solicitudes de replicación procedentes de equipos que no sean controladores de dominio autorizados.
- Proteger las cuentas de sincronización y los secretos asociados.
- Si existe evidencia de compromiso de
krbtgt, ejecutar un procedimiento de recuperación controlado que contemple dos restablecimientos de la contraseña, con la separación temporal y las comprobaciones necesarias para evitar invalidar tickets legítimos antes de tiempo.
Movimiento lateral: cómo ARTEX intenta alcanzar los controladores de dominio
Una vez obtenida información sobre las cuentas y los permisos disponibles, el siguiente objetivo consiste en ampliar el acceso dentro de la infraestructura.
ARTEX ha utilizado scripts y técnicas orientadas al movimiento lateral, entre ellas:
- Pass-the-Hash: reutilización de hashes NTLM para autenticarse sin conocer la contraseña original.
- Pass-the-Ticket: reutilización de tickets Kerberos previamente obtenidos.
- WinRM: utilización de Windows Remote Management para ejecutar operaciones remotas.
- Kerberos Relay: técnicas de retransmisión de autenticación para aprovechar configuraciones vulnerables.
En uno de los incidentes descritos por Google, parte de la actividad fue bloqueada por las restricciones de privilegios de los servicios de Windows y los mecanismos de protección de los endpoints.
Esto demuestra que los controles de seguridad del sistema operativo, las políticas de autenticación y la segmentación pueden impedir que una cuenta comprometida se convierta automáticamente en un acceso total al dominio.
La velocidad de los ataques automatizados: 27 eventos en 23 segundos
Uno de los aspectos más preocupantes del informe es la velocidad de ejecución.
Google observó secuencias de actividad de ARTEX que se desarrollaban en ráfagas de aproximadamente 2 a 25 segundos.
En uno de los casos se registraron 27 eventos en apenas 23 segundos.
También se documentó cómo el framework adaptaba scripts demasiado grandes, los reducía y volvía a ejecutarlos en aproximadamente diez segundos.
En otra investigación, ARTEX generó alrededor de 240 eventos de registro mientras intentaba explotar funcionalidades de una aplicación basada en MySQL para escribir web shells JSP.
Estos comportamientos revelan dos características importantes:
- La IA puede acelerar significativamente la investigación y ejecución de rutas de ataque.
- La automatización todavía puede generar errores, actividad repetitiva y rastros forenses que los sistemas de detección pueden aprovechar.
El principal problema para los defensores es que las operaciones pueden avanzar más rápido que los procesos tradicionales de análisis y respuesta a incidentes.
¿Por qué ARTEX supone un riesgo para AWS y los entornos cloud?
Aunque buena parte de la investigación se centra en Active Directory, ARTEX también puede explorar permisos y recursos de infraestructura cloud.
Google observó operaciones de reconocimiento contra AWS y Azure, incluyendo comprobaciones de permisos, enumeración de recursos y actividades relacionadas con almacenamiento y credenciales.
En AWS, un atacante que consiga credenciales IAM válidas puede intentar identificar qué operaciones tiene permitidas, consultar recursos EC2, acceder a snapshots EBS o explorar servicios de almacenamiento.
El problema no es exclusivo de ARTEX: cualquier framework automatizado capaz de utilizar credenciales válidas puede aprovechar una política IAM demasiado permisiva.
Por ello, proteger las aplicaciones expuestas a Internet no es suficiente. También hay que proteger las identidades, las API de administración, los servicios internos y las comunicaciones entre cargas de trabajo.
Remediaciones: cómo proteger una organización frente a ARTEX y los ataques automatizados con IA
La defensa frente a ARTEX debe plantearse mediante varias capas de seguridad. No existe una regla de firewall, un antivirus o un indicador de compromiso capaz de detener por sí solo una intrusión que utiliza credenciales válidas y herramientas administrativas legítimas.
Las siguientes medidas permiten reducir la superficie de ataque y dificultar que un acceso inicial termine comprometiendo toda la infraestructura.
1. Protección de aplicaciones web con AWS WAF
AWS Web Application Firewall (AWS WAF) puede ayudar a proteger las aplicaciones web expuestas a Internet frente a solicitudes maliciosas, explotación de vulnerabilidades web, automatización abusiva y determinados intentos de acceso no autorizado.
Es especialmente importante cuando las aplicaciones corporativas, API o portales de administración están publicados mediante Amazon CloudFront, Application Load Balancer o Amazon API Gateway.
Sin embargo, hay que tener en cuenta una limitación fundamental: AWS WAF inspecciona solicitudes HTTP/HTTPS. No bloquea directamente Kerberoasting, DCSync, LDAP, SMB, WinRM o Pass-the-Hash dentro de una red Windows. Para esas amenazas se necesitan controles de identidad, endpoint y segmentación.
Configuración recomendada de AWS WAF:
| Control | Configuración recomendada | Objetivo |
|---|---|---|
| AWSManagedRulesCommonRuleSet | Activar | Bloquear patrones de ataques web comunes. |
| AWSManagedRulesKnownBadInputsRuleSet | Activar | Detectar entradas asociadas a ataques conocidos. |
| AWSManagedRulesSQLiRuleSet | Activar | Reducir ataques de inyección SQL. |
| AWSManagedRulesAmazonIpReputationList | Activar | Bloquear solicitudes desde IP con mala reputación. |
| AWSManagedRulesAnonymousIpList | Evaluar su activación | Identificar tráfico procedente de proxies y redes anónimas. |
| Rate-based rules | Configurar | Limitar solicitudes excesivas desde un mismo origen o agrupación. |
| AWS WAF Logging | Activar | Registrar solicitudes permitidas, bloqueadas y evaluadas. |
Los grupos administrados deben probarse inicialmente en modo Count cuando sea necesario ajustar las excepciones y evitar falsos positivos. Después de validar su comportamiento, se pueden aplicar acciones de bloqueo.
Ejemplo de implementación con AWS CLI:
Para asociar un grupo de reglas administradas a una Web ACL existente, se puede utilizar una estructura como la siguiente:
aws wafv2 update-web-acl \
--name "Corporate-Web-ACL" \
--scope REGIONAL \
--id "WEB_ACL_ID" \
--lock-token "LOCK_TOKEN" \
--default-action Allow={} \
--visibility-config \
SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=CorporateWAF \
--rules file://rules.jsonEl archivo rules.json debe contener las reglas completas de la Web ACL, incluidos sus grupos administrados, prioridades y configuraciones de visibilidad. Hay que recuperar el LockToken y la configuración actual antes de actualizar una ACL existente, para no sobrescribir accidentalmente las protecciones ya desplegadas.
Ejemplo de regla administrada para Common Rule Set:
{
"Name": "AWSManagedRulesCommonRuleSet",
"Priority": 1,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet"
}
},
"OverrideAction": {
"None": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "AWSCommonRuleSet"
}
}Esta configuración es un ejemplo de una regla dentro de una Web ACL, no una configuración completa lista para desplegar sin adaptación.
Protección adicional mediante Rate-Based Rules
Una regla basada en tasas permite limitar solicitudes cuando un origen supera un volumen establecido durante una ventana de evaluación.
Es recomendable utilizarla en:
- Formularios de autenticación.
- Portales de administración.
- API que permiten operaciones sensibles.
- Endpoints de recuperación de contraseñas.
- Servicios que permiten consultar o modificar información.
- Aplicaciones con funcionalidades de búsqueda intensiva.
Hay que ajustar los límites al tráfico legítimo de cada aplicación. Una regla de limitación de peticiones no sustituye la autenticación ni impide que un atacante utilice credenciales válidas desde otro servicio.
Documentación oficial: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html
2. Protección de identidades y permisos en AWS
Los ataques automatizados pueden aprovechar credenciales IAM comprometidas para enumerar recursos, comprobar permisos y acceder a información sensible.
Para reducir este riesgo:
IAM (Identity and Access Management)
- Aplicar el principio de mínimo privilegio.
- Eliminar usuarios y claves de acceso que no se utilicen.
- Evitar claves IAM permanentes cuando sea posible.
- Priorizar roles IAM y credenciales temporales mediante AWS STS.
- Exigir MFA para las identidades humanas con privilegios.
- Restringir las relaciones de confianza entre roles.
- Revisar periódicamente políticas IAM demasiado permisivas.
- Evitar permisos comodín (
*) cuando no sean estrictamente necesarios.
AWS CloudTrail
Activar y centralizar CloudTrail para registrar las operaciones realizadas sobre la infraestructura.
Es especialmente importante supervisar operaciones como:
CreateAccessKeyCreateLoginProfileAttachUserPolicyAttachRolePolicyPutUserPolicyPutRolePolicyAssumeRoleCreateSecurityGroupAuthorizeSecurityGroupIngressRunInstancesCreateSnapshotModifySnapshotAttributeGetCallerIdentity
Las operaciones anteriores son ejemplos de actividad que conviene correlacionar; no todas son maliciosas por sí mismas.
También es recomendable habilitar los eventos de datos de CloudTrail para los buckets S3 sensibles, porque el registro predeterminado de eventos de administración no proporciona visibilidad completa sobre todas las operaciones de lectura y escritura de objetos.
Amazon GuardDuty
Activar GuardDuty para identificar comportamientos sospechosos en cuentas y cargas de trabajo AWS.
Complementar sus alertas con Security Hub y un SIEM centralizado para facilitar la correlación de eventos.
AWS IAM Access Analyzer
Utilizar IAM Access Analyzer para detectar recursos compartidos externamente y revisar políticas que puedan permitir accesos no previstos.
AWS Organizations y SCP
En entornos multiaccount, utilizar Service Control Policies (SCP) para establecer límites de permisos a nivel organizativo y evitar operaciones de alto riesgo que no estén autorizadas.
3. Protección de Active Directory frente a Kerberoasting y DCSync
Active Directory debe considerarse un activo crítico, ya que su compromiso puede permitir el control de una parte importante de la infraestructura corporativa.
Las medidas prioritarias son:
- Utilizar gMSA para servicios compatibles.
- Revisar todas las cuentas que tengan configurado un SPN.
- Eliminar cuentas de servicio obsoletas.
- Utilizar contraseñas largas y aleatorias.
- Retirar RC4 y otros cifrados heredados cuando sea viable.
- Auditar los permisos de replicación del directorio.
- Restringir las cuentas con privilegios Domain Admin.
- Proteger los controladores de dominio mediante segmentación de red.
- Evitar inicios de sesión interactivos innecesarios en controladores de dominio.
- Revisar las plantillas y permisos de AD CS.
- Activar auditoría avanzada de Windows.
Eventos de Windows que conviene supervisar:
| Evento | Descripción | Interés defensivo |
|---|---|---|
| 4769 | Solicitud de ticket de servicio Kerberos | Identificar patrones compatibles con Kerberoasting. |
| 4768 | Solicitud de ticket TGT Kerberos | Investigar autenticaciones anómalas. |
| 4662 | Operación sobre un objeto de Active Directory | Detectar actividad de replicación sospechosa, si está correctamente auditada. |
| 4624 | Inicio de sesión correcto | Correlacionar accesos y movimiento lateral. |
| 4648 | Inicio de sesión con credenciales explícitas | Investigar uso de credenciales alternativas. |
| 4672 | Privilegios especiales asignados a un nuevo inicio de sesión | Supervisar sesiones privilegiadas. |
| 4720 | Creación de una cuenta de usuario | Detectar persistencia mediante nuevas cuentas. |
| 4728 | Incorporación a un grupo global de seguridad | Identificar elevaciones de privilegios. |
| 4732 | Incorporación a un grupo local de seguridad | Detectar cambios de permisos. |
| 7045 | Instalación de un servicio | Investigar posibles mecanismos de ejecución remota. |
La auditoría de eventos 4662 requiere configurar correctamente la auditoría de acceso a objetos del directorio y las SACL correspondientes. No basta con habilitar el evento de forma genérica.
Microsoft Defender for Identity es una herramienta especialmente interesante para este escenario porque permite supervisar actividades como replicación del directorio, consultas LDAP, recuperación de contraseñas gMSA, ejecución remota de PowerShell y posibles movimientos laterales.
4. Protección frente al movimiento lateral
Una de las mejores formas de frenar ARTEX es impedir que una cuenta comprometida pueda desplazarse libremente por la red.
Se recomienda:
- Segmentar las redes de usuarios, servidores, administración y controladores de dominio.
- Restringir WinRM a los equipos y administradores autorizados.
- Limitar SMB entre segmentos.
- Aplicar reglas de firewall interno.
- Restringir RDP y PowerShell Remoting.
- Habilitar Windows Defender Firewall en todos los perfiles.
- Utilizar Windows LAPS para administrar las contraseñas de administradores locales.
- Implementar Windows Defender Credential Guard cuando sea compatible.
- Utilizar estaciones de trabajo de administración privilegiada (PAW).
- Evitar que las cuentas administrativas se utilicen para navegar o consultar correo.
- Aplicar políticas de control de aplicaciones y reducción de superficie de ataque.
El objetivo es que un servidor comprometido no pueda comunicarse libremente con todos los equipos del dominio.
5. Protección de Microsoft 365 y Microsoft Entra ID
Los ataques que utilizan credenciales robadas también pueden extenderse a entornos cloud y servicios SaaS.
Por ello, las organizaciones que utilizan Microsoft 365 deben revisar:
- MFA resistente al phishing para cuentas privilegiadas.
- Conditional Access para restringir ubicaciones, dispositivos y niveles de riesgo.
- Protección de cuentas de emergencia.
- Restricciones sobre aplicaciones OAuth y consentimientos de terceros.
- Revisión de roles administrativos de Entra ID.
- Rotación y eliminación de secretos de aplicaciones obsoletos.
- Supervisión de inicios de sesión no interactivos.
- Alertas por accesos desde ubicaciones o infraestructuras inusuales.
- Revisión de ConnectWise y otras plataformas de acceso remoto.
- Protección de Microsoft Entra Connect y sus credenciales de sincronización.
También es recomendable revisar los registros de auditoría de Microsoft 365 y las actividades administrativas que puedan indicar una toma de control de cuentas.
6. Detección de ARTEX mediante SIEM y EDR
Las soluciones SIEM y EDR deben adaptarse a una realidad en la que los atacantes pueden ejecutar decenas de acciones en pocos segundos.
No es suficiente buscar un archivo llamado ARTEX o una firma concreta. Es necesario correlacionar comportamientos.
Reglas y comportamientos que deberían investigarse:
| Comportamiento | Posible actividad maliciosa |
|---|---|
| Solicitudes masivas de tickets Kerberos | Kerberoasting. |
| Consultas LDAP de gran volumen | Reconocimiento de Active Directory. |
| Replicación del directorio desde equipos no autorizados | DCSync. |
| Ejecución remota de PowerShell | Movimiento lateral. |
| Uso inesperado de WinRM | Acceso remoto no habitual. |
| Creación de cuentas administrativas | Persistencia y escalada de privilegios. |
| Ejecución de curl desde servidores Windows o Linux | Descarga o envío de información. |
| Conexiones repetidas a webhook.site | Posible canal de comunicación o transferencia de resultados. |
| Creación de instancias EC2 t3.micro no autorizadas | Posible infraestructura de persistencia. |
| Creación y modificación de reglas de seguridad AWS | Posible preparación de infraestructura. |
Se recomienda utilizar correlación temporal, análisis de comportamiento de usuarios y entidades (UEBA), telemetría de endpoints y registros de red.
Las detecciones deben considerar tanto el volumen como el contexto: una consulta administrativa legítima puede ser normal, mientras que cientos de consultas en segundos desde un servidor que nunca ha realizado esas operaciones pueden representar un incidente.
Indicadores de compromiso (IoC) asociados a ARTEX
Google Cloud y Mandiant documentan diferentes indicadores técnicos relacionados con la actividad investigada.
La siguiente tabla recoge los artefactos incluidos en la información publicada.
| Tipo | Indicador | Contexto |
|---|---|---|
| Hashes SHA256/MD5 | No publicados | No se dispone de hashes confirmados en el informe. |
| Dominio | webhook.site | Envío de resultados mediante solicitudes curl a 491 URL rotativas. |
| Patrón de archivos | artex-probe-* | Archivos de prueba con numeración incremental de cinco dígitos. |
| Web shells | cl1217.jsp | Archivo JSP observado durante la actividad. |
| Web shells | f1219a.jsp | Archivo JSP observado durante la actividad. |
| Web shells | z1219.jsp | Archivo JSP observado durante la actividad. |
| Cuentas | ArtexProbe | Patrón de nombres de cuentas creadas durante la operación. |
| Atributo de cuenta | is_admin=true | Indicador observado en la creación de cuentas administrativas en una aplicación. |
| SQL | SET GLOBAL general_log_file | Configuración de MySQL utilizada en el intento de escritura de web shells. |
| SQL | SET GLOBAL general_log = 1 | Activación del registro general de MySQL. |
| AWS | t3.micro | Tipo de instancia EC2 utilizado en intentos de establecer infraestructura persistente. |
| Google SecOps | Suspicious Webhook.Site Interaction | Detección de interacción sospechosa con webhook.site. |
| Google SecOps | Suspicious Curl Invocation | Detección de invocaciones sospechosas de curl. |
| Google SecOps | Cmd Launching Curl | Detección de procesos CMD que ejecutan curl. |
| Google SecOps | AWS Cloud Accounts Getcalleridentity | Detección relacionada con consultas de identidad en AWS. |
Importante: estos indicadores no deben utilizarse como única fuente de detección. Un dominio como webhook.site puede tener usos legítimos y una instancia EC2 t3.micro no implica necesariamente actividad maliciosa.
Los indicadores deben correlacionarse con el contexto del equipo, la identidad, el momento de ejecución y el resto de los eventos.
No se han publicado hashes de archivos que permitan construir una detección basada exclusivamente en SHA256 o MD5.
Los indicadores de dominio deben tratarse en plataformas de inteligencia de amenazas como MISP, VirusTotal o el SIEM corporativo. No es recomendable acceder directamente a infraestructuras sospechosas desde equipos de producción.
Plan de respuesta ante una posible intrusión con ARTEX
Si una organización detecta actividad compatible con ARTEX, debe actuar rápidamente. La velocidad de ejecución de estos frameworks hace especialmente importante disponer de procedimientos de respuesta previamente definidos.
Fase 1. Contención
- Aislar los endpoints afectados mediante EDR.
- Bloquear temporalmente las cuentas comprometidas.
- Revocar sesiones, tokens y credenciales sospechosas.
- Deshabilitar claves IAM expuestas.
- Restringir la conectividad de los sistemas comprometidos.
- Bloquear indicadores externos confirmados en los controles de salida.
Fase 2. Investigación
- Revisar los registros de Active Directory.
- Analizar los eventos Kerberos 4769.
- Investigar posibles operaciones DCSync mediante los registros 4662.
- Revisar PowerShell, WinRM, SMB y RDP.
- Examinar CloudTrail y los eventos de autenticación IAM.
- Comprobar instancias EC2, snapshots y cambios en grupos de seguridad.
- Buscar cuentas nuevas, servicios, tareas programadas y mecanismos de persistencia.
- Analizar posibles transferencias de datos hacia servicios externos.
Fase 3. Erradicación
- Eliminar mecanismos de persistencia confirmados.
- Corregir permisos excesivos.
- Rotar contraseñas y secretos afectados.
- Revisar credenciales de cuentas de servicio.
- Sustituir claves IAM comprometidas.
- Revisar las relaciones de confianza y las aplicaciones OAuth.
- Recuperar los sistemas desde imágenes o copias verificadas cuando sea necesario.
Si existe evidencia de compromiso de las credenciales de replicación o de la cuenta krbtgt, la recuperación del dominio debe realizarse mediante un procedimiento especializado de recuperación de Active Directory. No debe limitarse a cambiar la contraseña de una cuenta administrativa.
Fase 4. Recuperación y vigilancia
- Restaurar los servicios desde sistemas confiables.
- Validar la integridad de los controladores de dominio.
- Comprobar las políticas IAM y las configuraciones de seguridad.
- Incrementar temporalmente la monitorización.
- Investigar posibles accesos residuales.
- Documentar las técnicas utilizadas y actualizar las reglas de detección.
Conclusión: los ciberataques autónomos obligan a evolucionar la defensa
La aparición de ARTEX demuestra que la inteligencia artificial está pasando de ser una herramienta de apoyo para los ciberdelincuentes a convertirse en un componente operativo de sus campañas.
La posibilidad de automatizar el reconocimiento, la enumeración de Active Directory, el Kerberoasting, la escalada de privilegios y el movimiento lateral reduce considerablemente el tiempo necesario para comprometer una organización.
Sin embargo, el problema de fondo sigue siendo conocido: credenciales comprometidas, permisos excesivos, redes poco segmentadas, servicios expuestos y una monitorización insuficiente.
La diferencia es que ahora los atacantes pueden encadenar esas debilidades a una velocidad que dificulta enormemente la respuesta humana tradicional.
Para los responsables de ciberseguridad, administradores de sistemas y equipos SOC, la prioridad debe ser reducir los privilegios, proteger las identidades, aislar los sistemas críticos y detectar comportamientos anómalos en tiempo real.
La seguridad ya no puede depender únicamente de detectar herramientas maliciosas. Debe ser capaz de limitar lo que un atacante puede hacer incluso cuando dispone de credenciales legítimas y utiliza herramientas administrativas normales.
ARTEX es un ejemplo de cómo la automatización ofensiva está cambiando las reglas del juego. La respuesta debe combinar inteligencia de amenazas, protección de identidades, segmentación, EDR, SIEM y controles cloud para reducir las posibilidades de que una intrusión inicial termine convirtiéndose en un compromiso completo de la organización.
Preguntas frecuentes sobre ARTEX y los ataques con IA
¿Qué es ARTEX en ciberseguridad?
ARTEX es una plataforma ofensiva multiagente desarrollada en Go que utiliza modelos de inteligencia artificial para automatizar tareas de pentesting, reconocimiento, escalada de privilegios, movimiento lateral y otras fases de una intrusión.
¿ARTEX puede comprometer Active Directory?
Puede automatizar diferentes técnicas contra Active Directory, incluyendo enumeración de usuarios, reconocimiento de cuentas de servicio, Kerberoasting y operaciones DCSync, siempre que disponga de las condiciones de acceso y permisos necesarios.
¿Qué es el Kerberoasting y por qué es peligroso?
Es una técnica que permite solicitar tickets Kerberos asociados a cuentas de servicio y tratar de recuperar sus contraseñas mediante ataques fuera de línea. Puede facilitar el acceso a cuentas privilegiadas cuando existen contraseñas débiles o configuraciones inseguras.
¿AWS WAF protege frente a ARTEX?
AWS WAF puede proteger aplicaciones web frente a determinados ataques HTTP/HTTPS y automatización abusiva. No protege directamente Active Directory, Kerberos, DCSync o el movimiento lateral dentro de una red. Debe complementarse con IAM, CloudTrail, GuardDuty, controles de red y protección de endpoints.
¿Cómo detectar ataques ARTEX?
La detección debe combinar eventos Kerberos, operaciones de replicación de Active Directory, actividad PowerShell, conexiones WinRM, cambios de privilegios, accesos cloud anómalos y comunicaciones externas sospechosas.
¿La eliminación de ARTEX de GitHub ha detenido la amenaza?
No. Aunque el repositorio original fue retirado en octubre de 2026, el código y sus modificaciones continúan circulando mediante forks y otras distribuciones.
¿Los ataques con agentes de IA sustituyen a los ciberdelincuentes?
No necesariamente. Los operadores siguen definiendo objetivos, proporcionando accesos y tomando decisiones estratégicas. Sin embargo, los agentes pueden ejecutar una parte considerable de las tareas técnicas con una intervención humana mucho menor.