Adaptarse o pagar: un análisis del marco AdaptixC2

Introducción

Como se destacó en nuestra publicación anterior sobre el marco Mythic, los actores maliciosos adoptan rápidamente tecnologías y marcos emergentes. Un claro ejemplo de esta tendencia es AdaptixC2, un marco de código abierto relativamente nuevo para actividades posteriores al abuso que rápidamente captó la atención de la comunidad de seguridad ofensiva. Su popularidad se debe a su naturaleza de código abierto y a su alta extensibilidad; el marco es compatible con los archivos Beacon Object File (BOF, por sus siglas en inglés), incluidos los asincrónicos, y cuenta con un ecosistema cada vez mayor de módulos, extensiones y colecciones de archivos BOF de terceros. Cada vez observamos más casos de AdaptixC2 en la práctica, particularmente en ataques APT y campañas de ransomware, sobre los que informamos regularmente.

Para minimizar su huella, AdaptixC2 emplea diversas técnicas de comunicación de red y de actividades posteriores al abuso diseñadas para eludir herramientas de control de tráfico como las soluciones IDS y NDR. A pesar de estas tácticas de evasión, la detección a nivel de red sigue siendo uno de los métodos más efectivos para identificar la presencia y la actividad del agente, ya que muchas de las técnicas posteriores al abuso basadas en el host del marco tienen como objetivo complicar el análisis forense basado en artefactos. En consecuencia, las medidas defensivas estándar pueden resultar insuficientes, lo que hace necesario un control avanzado de los endpoint mediante soluciones EDR.

Este artículo detalla formas de detectar el marco AdaptixC2 mediante el análisis de su tráfico de comando y control y su actividad en los endpoint.

El marco AdaptixC2

AdaptixC2 es un marco de comando y control (C2) diseñado para actividades posteriores al abuso y la interacción sigilosa con sus agentes maliciosos desplegados en sistemas en riesgo. A diferencia de muchas plataformas C2 de propósito general, AdaptixC2 se enfoca en la comunicación avanzada entre agentes y el servidor C2, así como en técnicas específicas de evasión diseñadas para eludir las herramientas de seguridad modernas, incluidas las soluciones EDR y NDR.

Desarrollada en Go y C++, la arquitectura de AdaptixC2 sigue un modelo que separa el componente del lado del servidor de los agentes implementados en los hosts en riesgo. Este enfoque permite la administración centralizada de los agentes, el seguimiento de la ejecución de comandos y respalda las actividades posteriores al abuso. Se hace especial hincapié en la flexibilidad de las comunicaciones de red y en la capacidad de modificar los canales de comunicación. Esto permite adaptar el comportamiento de los agentes a entornos específicos y complica la detección por parte de las herramientas de control.

El marco brinda la flexibilidad para desarrollar agentes personalizados, al tiempo que incluye implementaciones estándar de agentes en Go y C++ para Windows, macOS y Linux.

Además, admite un enfoque modular para ampliar su funcionalidad. Se pueden agregar características en forma de módulos que usan BOF. Este enfoque permite a los operadores implementar nuevas capacidades posteriores al abuso sin necesidad de recompilar el agente principal. También agiliza el desarrollo y la integración de módulos personalizados.

Desde la perspectiva de un defensor, la actividad de AdaptixC2 puede manifestarse en diversas etapas de la vulneración de la infraestructura. Se alinea con múltiples fases de la Unified Kill Chain y se corresponde con varias tácticas y técnicas de MITRE ATT&CK, principalmente aquellas asociadas con el control de sistemas en riesgo, la ejecución de comandos y el mantenimiento de un canal C2 persistente.

• El comando y control (TA0011) implica establecer y mantener la comunicación entre el operador y los hosts en riesgo para transmitir comandos, recuperar resultados y controlar el estado del agente. AdaptixC2 ofrece una amplia gama de métodos de comunicación C2.
• El acceso a credenciales (TA0006) es la táctica de recolección de credenciales. AdaptixC2 Extension Kit implementa un amplio conjunto de métodos para obtener credenciales, desde el volcado estándar de LSASS hasta el abuso más sofisticado de ADCS y los ataques basados en Kerberos.
• La evasión de defensas (TA0005) es la táctica diseñada para eludir la detección por parte de los controles de seguridad. AdaptixC2 cuenta con un sofisticado conjunto de herramientas con métodos avanzados para implementar esta táctica.
• El movimiento lateral (TA0008) se refiere a los métodos que permiten al adversario desplazarse dentro de la infraestructura de destino. De estos, AdaptixC2 es compatible con PsExec y WinRM.

En este artículo, ampliamos nuestro enfoque más allá de la detección de la comunicación de red para analizar los métodos de detección de la actividad de los agentes en los endpoints.

Indicadores de red de AdaptixC2

Al momento de escribir este artículo, AdaptixC2 admite la transmisión de datos a través de HTTP/S, TCP/mTLS, SMB, DNS y DoH.

El marco cuenta con dos enfoques distintos de comunicación:

• Externo (egress): los agentes se comunican directamente con el servidor C2 usando HTTP/S, TCP y DNS/DoH.
• Interno (P2P): los agentes se comunican con agentes adyacentes, estableciendo una cadena que remite a un host que se conecta directamente con el servidor C2. Este enfoque usa TCP y SMB.

Egress (comunicaciones externas)

La comunicación directa entre el agente y el servidor se facilita a través de los siguientes protocolos:

• HTTP(S)
• TCP
• DNS

De la lista proporcionada, HTTP es el protocolo más común para la comunicación entre el agente y el C2. TCP es menos frecuente, mientras que el módulo de transporte DNS presenta varios problemas técnicos y rara vez se encuentra en la práctica. A pesar de ello, analizaremos la implementación del transporte DNS y destacaremos los factores clave que facilitan la detección de la actividad del agente en el tráfico de red.

HTTP

Debido a la omnipresencia de HTTP, el tráfico de red del agente puede mezclarse con el flujo de las solicitudes HTTP ordinarias. Además, configurar el servidor del receptor HTTP teniendo en cuenta los principios de seguridad operativa (OPSEC, por sus siglas en inglés) permite que esta actividad se enmascare como un intercambio de red legítimo, lo que reduce significativamente la probabilidad de detección.

El servidor identifica al agente mediante un valor único transmitido en un encabezado de solicitud HTTP, conocido como el encabezado Heartbeat. Este valor está vinculado al identificador del agente y a otros datos técnicos que el agente necesita para funcionar. Antes de la transmisión, estos datos se cifran usando el algoritmo RC4 y luego se codifican en Base64. La clave de cifrado se regenera cada vez que se crea un servidor HTTP.

De manera predeterminada, el encabezado que contiene este valor se denomina X-Beacon-Id. Este nombre se establece automáticamente, pero se puede cambiar si es necesario.

Otro parámetro predeterminado es el encabezado User-Agent. Su valor inicial es:
Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0.

A continuación se muestra un ejemplo de tráfico de red de AdaptixC2 a través de HTTP, usando los valores predeterminados de los campos.

El valor User-Agent usado aquí no es único y puede encontrarse en el tráfico de red legítimo. El encabezado X-Beacon-Id sirve como un indicador de red más distintivo que puede apuntar a la presencia del marco AdaptixC2.

El agente cifra la carga útil usando el algoritmo RC4 y la transmite dentro del cuerpo de una solicitud POST. Debido a este cifrado, el contenido de la solicitud no puede descifrarse sin la clave correspondiente; por lo tanto, generalmente es difícil desarrollar una lógica de detección confiable basada únicamente en estos datos.

La siguiente captura de pantalla muestra cómo el módulo NDR de Kaspersky Anti Targeted Attack detecta la comunicación entre el agente y el servidor a través de HTTP cuando se usan encabezados estándar. Esta actividad activa una alerta Backdoor.AdaptixC2.HTTP.C&C.

El marco también permite personalizar el encabezado Heartbeat, lo que le permite al operador asignarle cualquier nombre arbitrario. Por ejemplo, identificamos muestras que imitan los tokens de autorización e identificadores usados por plataformas populares.

A continuación se muestra un ejemplo del tráfico de red de AdaptixC2 a través de HTTP usando encabezados personalizados.

Dadas las restricciones sobre los caracteres permitidos en los encabezados HTTP y considerando que el contenido de X-Beacon-Id consiste en datos codificados en Base64, se puede desarrollar una regla basada en firmas para detectar solicitudes iniciadas por el agente a través de este protocolo. Además, la lógica de detección puede incorporar condiciones relacionadas con el orden específico y la presencia de encabezados HTTP, así como la frecuencia de estas solicitudes. En este caso, la implementación de reglas para los métodos GET y POST diferiría solo ligeramente, manteniendo todas las técnicas descritas anteriormente.

La combinación de estos indicadores permite desarrollar un mecanismo de detección capaz de identificar la actividad del agente incluso cuando este se personalizó y enmascaró como una fuente de tráfico de red legítimo.

A continuación se muestra un ejemplo de tráfico de red del agente AdaptixC2 encontrado en un entorno real y que usa HTTP con encabezados personalizados. Aquí, X-Beacon-Id se transmite dentro del campo Cookie, mientras que el User-Agent y el endpoint intentan imitar la actividad legítima de Windows Update.

La respuesta del servidor sigue una estructura estándar y se transmite en formato JSON, con los campos status, data y metrics. La carga útil se encuentra dentro del campo data y está cifrada mediante el algoritmo RC4. Los campos restantes prácticamente no se usan y solo sirven para crear una estructura de respuesta que parezca verosímil.

Esta estructura imita las respuestas de servicios y plataformas que manejan diversas métricas. Sin embargo, incluso con estas técnicas de enmascaramiento, este formato de respuesta puede servir como un indicador de red altamente confiable. Es susceptible a la detección basada en firmas, especialmente cuando se complementa con un análisis de los intervalos de comunicación y el recuento de paquetes, al tiempo que se excluyen las plataformas legítimas conocidas que usan formatos similares.

Según nuestros hallazgos y los ejemplos proporcionados, la personalización se aplica con mayor frecuencia en el lado del cliente, mientras que las respuestas del servidor suelen ser estándar. Sin embargo, estas también pueden modificarse. El formato de respuesta del servidor está limitado únicamente por la imaginación del desarrollador y la necesidad de transmitir la carga útil cifrada con RC4.

A continuación se muestran ejemplos de tráfico de red HTTP del agente AdaptixC2 detectado en entornos reales que usa una respuesta de servidor personalizada. En un caso, se modificaron los campos JSON; en otro, se eliminaron por completo, dejando solo la carga útil cifrada.

La siguiente captura de pantalla ilustra cómo el módulo NDR detecta la comunicación entre el agente y el C2 a través de HTTP. En este caso, el tráfico de red del agente imita la actividad legítima de un servicio y carece de los campos estándar. KATA genera una alerta Backdoor.AdaptixC2.HTTP.C&C.

HTTPS

Los agentes de AdaptixC2 también pueden interactuar con el servidor de control a través de HTTPS usando un módulo de transporte específico. En este caso, los datos transmitidos se cifran mediante TLS, lo que complica significativamente el análisis de contenido y reduce la eficacia de los enfoques directos basados en firmas.

Sin embargo, incluso con el cifrado activo, dicha actividad de red puede identificarse mediante una combinación de indicadores indirectos asociados con el establecimiento y mantenimiento de la conexión. En ciertos casos, las características específicas de la configuración del canal seguro, exclusivas de AdaptixC2, sirven como factores adicionales que simplifican la detección.

A continuación se muestra un ejemplo de detección del agente AdaptixC2 basado en su tráfico. En este caso, se activó una regla al establecerse una conexión HTTPS con parámetros TLS distintivos.

TCP

El marco AdaptixC2 también implementa un método para la comunicación entre el agente y el C2 basado en el principio reverse shell. Este enfoque elude diversas restricciones de red, ya que las políticas de seguridad suelen permitir las conexiones salientes. La conexión tipo reverse shell se establece a través del protocolo TCP: el agente se conecta al servidor C2 usando sockets TCP.

De manera predeterminada, después de que el agente inicia la conexión, el servidor C2 responde con un banner estándar: AdaptixC2 server. Una vez recibido este banner, comienza la inicialización interna del agente, seguida del intercambio de datos de servicio.

A continuación se muestra un ejemplo de tráfico de red TCP en el que el servidor devuelve el banner estándar.

Si el servidor no reconoce al agente, usa otra respuesta predeterminada: Connection error…. Estos artefactos pueden identificarse mediante un análisis del tráfico de red basado en firmas.

Sin embargo, los valores pueden modificarse al crear un listener (oyente) en el lado del operador. Por lo tanto, basarse únicamente en ellos no es una solución sólida para desarrollar una lógica de detección.

Una vez que el cliente recibe el banner, toda la comunicación posterior entre el agente y el servidor C2 se cifra usando el algoritmo RC4. En consecuencia, el contenido del tráfico suele ser resistente al análisis basado en firmas. En estos casos, los siguientes indicadores de comportamiento pueden servir como señales de actividad sospechosa:

• Interacción atípica, no observada anteriormente, del host con un servidor externo.
• Un flujo de datos cifrados persistente con alta entropía, similar a los valores característicos del tráfico cifrado con RC4.

A continuación se muestra una captura de pantalla de una alerta de KATA que detecta la actividad del agente AdaptixC2 en el tráfico de red TCP en modo Egress.

El módulo de transporte en cuestión opera sobre TCP y proporciona de manera independiente el cifrado del tráfico entre el agente y el servidor.

mTLS

Para una mayor discreción durante la transmisión de datos TCP, AdaptixC2 es compatible con el protocolo Mutual TLS (mTLS). Se trata de una versión ampliada del protocolo TLS estándar que implementa la autenticación mutua. A diferencia del esquema TLS tradicional con su proceso de autenticación unidireccional (el cliente verifica la identidad del servidor a través de su certificado), mTLS requiere que el servidor también solicite y verifique un certificado de cliente antes de establecer una conexión segura.

Debido a la verificación mutua de certificados tanto del lado del cliente como del servidor, interceptar y descifrar este tráfico es significativamente más difícil.

Para capturar la carga útil descifrada, se realizaron modificaciones en el código del módulo de transporte mTLS, agregando la capacidad de registrar los datos transmitidos antes del cifrado y después del descifrado.

A continuación se muestra un ejemplo de un registro que contiene la comunicación del agente a través del protocolo mTLS, junto con su parte descifrada.

El análisis de la carga útil transmitida a través de Mutual TLS (mTLS) muestra que es idéntica a los datos encontrados en sesiones que usan módulos de transporte TLS y TCP. La estructura de los comandos, el formato de encapsulación de datos y los algoritmos de cifrado se mantienen consistentes independientemente de la capa de transporte subyacente.

Sin embargo, la implementación de la autenticación mutua (mTLS) limita sustancialmente la eficacia de las herramientas de control de red para detectar la actividad del agente. Cuando no es factible descifrar el tráfico a nivel de red, identificar la actividad del agente se vuelve un reto y, por regla general, solo se puede lograr usando soluciones EDR en el endpoint.

DNS

AdaptixC2 admite la transmisión de datos y comandos desde C2 tanto a través del DNS tradicional sobre UDP como del DNS sobre HTTPS (DoH).

Este método de comunicación permite ocultar el canal de comunicación entre el agente y el servidor. Al usar el DNS estándar sobre UDP, la carga útil se encapsula dentro de solicitudes legítimas de resolución de nombres de dominio; en el modo DNS sobre HTTPS, el intercambio de datos se disfraza aún más como tráfico HTTPS de rutina.

DNS sobre UDP

El DNS sobre UDP es un protocolo estándar para la resolución de nombres de dominio que los atacantes aprovechan con frecuencia para establecer canales de comunicación encubiertos.

En AdaptixC2, este protocolo sirve como medio de transporte principal para Beacon DNS. Facilita la entrega de comandos y la transferencia de datos recopilados entre el agente desplegado en un sistema en riesgo y el servidor C2, que en este caso es el servidor DNS autoritativo del dominio asociado.

Beacon DNS admite cuatro operaciones principales, que se identifican sin ambigüedad mediante el segundo elemento (de izquierda a derecha) dentro de la estructura de la solicitud DNS.

A cada tipo de operación se le asigna un identificador de cadena específico:

• Inicialización (www/hi): registro del agente con el servidor C2 y el protocolo de enlace inicial.
• Transferencia de datos (cdn/put): envío de fragmentos de datos (por ejemplo, resultados de comandos o datos exfiltrados).
• Recuperación de datos (api/get): descarga de tareas, comandos y configuraciones desde el servidor.
• Heartbeat (hb): mantenimiento de la actividad de la sesión, consulta periódica de tareas pendientes y confirmación de descargas de datos exitosas.

A pesar de las diferencias en la lógica de procesamiento, todos los tipos de paquetes se ajustan a una estructura jerárquica unificada de nombres de dominio. Cada subdominio delimitado por puntos tiene una semántica estrictamente definida y es interpretado por el manejador correspondiente en el servidor C2. La siguiente captura de pantalla muestra un fragmento del tráfico del agente que usa el protocolo DNS.

El paquete inicial realiza la inicialización del agente usando el identificador de operación www. Las solicitudes posteriores mantienen la comunicación entre el agente y el servidor usando el identificador hb.

El análisis del tráfico de red revela solicitudes DNS anómalas que presentan una estructura jerárquica distintiva de subdominios.

En el volcado de paquetes proporcionado, las solicitudes DNS siguen este formato:

Analicemos más de cerca la estructura de un paquete de inicialización con un ejemplo específico:

Descomposición de campos:

• Session ID (base[0]): un identificador de sesión único de 8 bytes (en este ejemplo, 39912991). Se usa para identificar de manera consistente todas las solicitudes de un agente específico dentro de una misma sesión.
• Operation identifier (base[1]): especifica el tipo de operación, como el registro del agente, la señal de heartbeat o el procesamiento de tareas. Se representa como una cadena ASCII.
• Sequence number (base[2]): un número de secuencia de paquete de 8 bytes, cifrado mediante XOR. Sirve como defensa contra ataques de repetición, asegurando que cada solicitud sea única incluso cuando los datos sean idénticos.
• Unused (base[3]): el manejador no usa este campo.
• Encrypted data (base[4]): la carga útil, codificada en Base32 y cifrada con el algoritmo RC4. En el paquete de inicialización, este campo tiene datos críticos: detalles del sistema operativo (versión, compilación y arquitectura x86/x64), el nombre del proceso que aloja el agente, el nombre del host, las credenciales de usuario, información del entorno de red y más.

Esta estructura de solicitud de DNS presenta varias características típicas del túnel DNS:

1. Alto nivel de anidamiento de subdominios: una solicitud contiene más de ocho niveles de subdominios, lo cual es atípico para el tráfico DNS legítimo.
2. Alta entropía de nombres: los subdominios consisten en secuencias de caracteres pseudoaleatorias, como cadenas hexadecimales o codificaciones similares a Base32/Base64.
3. Codificación estructurada de datos: subdominios como 2HNLIUOKKYKFYML3KIJDPOBHLO67TE5PKSWA indican el uso de algoritmos de codificación para encapsular una carga útil.

Esta técnica permite a los atacantes eludir los controles de seguridad perimetrales tradicionales, ya que el tráfico DNS (puerto 53/UDP) rara vez se somete a una inspección profunda de paquetes y, por lo general, se permite de manera predeterminada para las conexiones salientes.

El uso de cadenas literales como www, cdn, api y hb, combinado con una jerarquía de subdominios estrictamente estructurada y longitudes de campo predecibles, crea un indicador de red distintivo para identificar la actividad de los agentes. Otros indicadores de compromiso incluyen lo mencionado anteriormente: nombres de dominio anormalmente largos (que superan los 100 caracteres) junto con una alta entropía de subdominios, un número excesivo de niveles de anidamiento (más de cinco subdominios) y la frecuencia de las solicitudes, como heartbeats periódicos dirigidos al mismo dominio.

La combinación de estas características permite la detección efectiva de los agentes AdaptixC2 que usan DNS sobre UDP como canal de comando y control y de exfiltración de datos.

La siguiente captura de pantalla muestra cómo el módulo NDR detecta la comunicación entre el agente y el servidor realizada a través del protocolo DNS. Esta actividad activa una alerta de Backdoor.AdaptixC2.DNS.C&C.

DNS sobre HTTPS

Para implementar Beacon DNS, el agente AdaptixC2 también es compatible con el protocolo DNS sobre HTTPS (DoH). Este mecanismo encapsula las consultas DNS estándar dentro de mensajes HTTP transmitidos a través de una conexión TLS segura. Desde la perspectiva del análisis de red, DoH enmascara la actividad del agente como tráfico web legítimo, lo que dificulta significativamente que las herramientas de control diseñadas para analizar tráfico sin cifrar detecten acciones maliciosas.

A continuación se muestra una captura de pantalla del tráfico de red durante la inicialización del agente, sin descifrado TLS.

El tráfico de red generado por el agente revela no solo conexiones al servidor C2, sino también intentos de resolución de nombres a través de solucionadores públicos confiables especificados durante la fase de creación del agente. En particular, el tráfico analizado incluye consultas DNS dirigidas a los siguientes solucionadores públicos:

• https://dns.google/dns-query
• https://cloudflare-dns.com/dns-query
• https://dns.quad9.net/dns-query

El uso de estos servicios permite a los atacantes ocultar el tráfico malicioso dentro del flujo general de solicitudes legítimas dirigidas a servicios de infraestructura populares.

Al crear un agente, el User-Agent predeterminado es Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0. Vale la pena señalar que la versión 20.0 de Firefox está obsoleta y era compatible con sistemas operativos como Windows 7/8, Windows Server 2003 y Windows XP.

Tras descifrar la sesión TLS, la estructura del paquete se presenta de la siguiente manera:

Características del funcionamiento del agente a través de DoH:

1. Método de transmisión: se usa el método POST para enviar consultas DNS a través del mecanismo DoH.
2. Encabezados de contenido: la presencia de los dos encabezados, a saber, Content-Type: application/dns-message y Accept: application/dns-message cumple con la especificación RFC 8484 y es un rasgo distintivo del tráfico DoH.
3. Estructura de la carga útil: el cuerpo de la solicitud POST reproduce íntegramente la estructura de los paquetes de DNS sobre UDP. La cadena de subdominio de alta entropía (codificada en Base32 y luego cifrada con RC4) se transmite sin modificaciones y se encapsula en un mensaje DNS binario, que luego se incluye en la solicitud HTTPS.

A pesar del uso del cifrado HTTPS, la implementación de DoH en AdaptixC2 presenta varios indicadores de red constantes que permiten una detección efectiva. Estos indicadores incluyen el uso de una versión obsoleta de Firefox en el encabezado User-Agent, solicitudes POST regulares al endpoint /dns-query y una estructura de nombres de dominio repetitiva con longitudes de subdominio predecibles. En conjunto, estas características forman un perfil de comportamiento distintivo del tráfico DoH del agente AdaptixC2.

La imagen a continuación muestra la interfaz de KATA con una alerta que detecta la actividad del agente AdaptixC2 durante su inicialización a través de DNS sobre HTTPS usando el descifrado de tráfico. Se activó la regla Backdoor.AdaptixC2.HTTP.C&C.

P2P (comunicación interna)

AdaptixC2 ofrece capacidades de pivotaje a través de tuberías SMB con nombre y sockets TCP. Para identificar la actividad del agente en modo P2P, examinaremos su tráfico de red y destacaremos las características y patrones específicos que permiten la detección de estas acciones maliciosas.

SMB

Para establecer la comunicación entre agentes a través del protocolo SMB, el marco usa tuberías con nombre. El nombre del canal se puede personalizar con cualquier valor al crear el oyente.

Los mensajes transmitidos entre agentes se cifran usando el algoritmo RC4, lo que hace que su contenido sea resistente al análisis basado en firmas. Sin embargo, durante la comunicación SMB, se pueden identificar características distintivas, no solo dentro de los propios paquetes, sino también en su secuencia y frecuencia. Estas anomalías permiten detectar la actividad de los agentes dentro de la red.

La captura de pantalla a continuación ilustra cómo aparece en Wireshark una sesión de establecimiento de conexión entre agentes.

Durante la inicialización del agente, nos enfocamos en la siguiente secuencia de comandos:

• GetInfo Response
• Ioctl Response: STATUS_BUFFER_OVERFLOW
• Read Response

De estos comandos, Read Response está directamente relacionado con la actividad del agente. La respuesta tiene el tamaño del paquete siguiente como un único valor DWORD (4 bytes), que varía entre 100 y 140 en decimal. El siguiente paquete tiene información técnica para el registro del agente, cifrada con RC4. A continuación se muestra un ejemplo de una Read Response.

Por sí solos, estos comandos no son particularmente notables; sin embargo, su orden estricto y su ubicación al inicio del flujo de datos SMB son elementos clave para la lógica de detección.

Otra característica de comportamiento de la comunicación que usa este transporte es el tráfico generado mientras el agente está inactivo. Cada N segundos, el agente verifica si hay nuevos comandos mediante la lectura de la tubería con nombre.

La frecuencia de estas verificaciones de comandos a través de SMB se hereda del intervalo de sondeo del módulo de transporte principal en modo Egress, a través del cual se transmiten los comandos al servidor C2. Dependiendo de los valores de Sleep y Jitter, estas solicitudes se ejecutarán a intervalos variables.

Si el agente está inactivo y no hay comandos presentes, su tráfico con el agente principal se verá de la siguiente manera:

A continuación se presenta la estructura de Ioctl Request:

Dado el tipo específico de solicitud y los indicadores característicos del protocolo (Command: Ioctl (11), Function: FSCTL_PIPE_PEEK), así como la secuencia estricta de paquetes durante el modo inactivo, la actividad del agente AdaptixC2 a través del transporte SMB puede identificarse con métodos basados en firmas.

La imagen a continuación muestra la interfaz de KATA con una alerta que detecta la operación del agente AdaptixC2 en modo P2P a través del protocolo SMB. En este caso, la regla se activó al detectar la actividad del agente durante su fase de inicialización.

TCP

Además de los canales de comunicación con nombre, AdaptixC2 ofrece la capacidad de pivotaje a través de TCP.

Este transporte se basa en sockets TCP sin procesar e implementa un modelo de transmisión de datos cliente-servidor. Para complicar la detección, el marco permite el parámetro Prepend data; datos personalizados que deben agregarse al inicio de cada mensaje del agente.

En la configuración predeterminada, el puerto está establecido en 9000 y Prepend data completado previamente con el valor \x12\xabSimple\x20word\xa. Sin embargo, es imposible crear un oyente con este valor específico, ya que provoca un error de sintaxis. Por lo tanto, es imposible encontrar una carga útil que use este valor predeterminado de Prepend data en un caso real.

Además, el análisis reveló que el agente en realidad no usa este campo durante la comunicación y que no tiene ningún impacto funcional en el flujo de tráfico.

La captura de pantalla a continuación muestra el tráfico de red durante la inicialización del agente y la comunicación posterior.

En consonancia con el comportamiento del protocolo SMB, el primer mensaje transmite la longitud de los datos (que suele oscilar entre 100 y 140 en formato decimal) como un DWORD (4 bytes) en formato big-endian. Este valor representa el tamaño del paquete siguiente, que tiene los metadatos de servicio del agente. Toda la comunicación entre agentes se cifra mediante el algoritmo RC4, lo que la hace resistente al análisis de firmas basado en el contenido.

No obstante, se pueden identificar varias características que indican una alta probabilidad de actividad del agente AdaptixC2 a través de TCP. Estas características no solo se refieren a los paquetes individuales, sino también a su secuencia específica dentro del flujo de datos.

Uno de los principales métodos para detectar la actividad del agente es identificar la comunicación de red entre hosts internos en el puerto 9000, que este protocolo de transporte usa de manera predeterminada. Además, la propia estructura del intercambio de datos es muy reveladora, ya que contiene elementos idénticos a los que se encuentran en el protocolo SMB: el tamaño característico del paquete inicial y el valor que contiene, el algoritmo de cifrado usado y la secuencia de mensajes. Todas las comunicaciones posteriores siguen un patrón similar, con la excepción de que las restricciones del paquete de carga útil se flexibilizan para adaptarse a la amplia gama de comandos y a los tamaños de salida correspondientes.

La captura de pantalla a continuación ilustra el proceso de inicialización del agente, seguido de la transmisión de varios comandos.

Al tomar en cuenta estas características específicas, es posible construir una firma de flujo capaz de detectar la actividad del agente tras la ejecución de tan solo unos pocos comandos.

La imagen a continuación muestra la interfaz de KATA con un ejemplo de detección de un agente AdaptixC2 en modo P2P sobre TCP, usando una regla basada en la lógica descrita anteriormente.

En resumen, los indicadores basados en la red permiten la detección efectiva de AdaptixC2 durante la fase de interacción entre un agente, su infraestructura C2 y otros agentes. Sin embargo, las capacidades de detección no se limitan a esto. El endpoint sigue siendo una fuente crítica de telemetría, donde se puede identificar la ejecución de módulos específicos y comportamientos típicos posteriores al abuso. Por lo tanto, la siguiente sección se enfocará en analizar la actividad del agente en el host y las oportunidades de detección que brindan las soluciones EDR.

Detección de la actividad posterior al abuso usando los módulos de AdaptixC2 como ejemplo

Examinemos las capacidades del agente AdaptixC2 usando como ejemplo una cadena de ataque típica posterior al abuso. Esta cadena refleja los casos más característicos de la progresión de un ataque en un host en riesgo, lo cual puede servir como base para desarrollar la lógica de detección. Ten en cuenta que las acciones que se describen a continuación pueden servir como indicadores no solo de AdaptixC2, sino también de otras actividades posteriores al abuso dentro de la infraestructura.

Acceso a credenciales

Después de obtener acceso a un host, un atacante normalmente necesita credenciales. Para extraerlas, puede usar varios módulos de AdaptixC2. Consideremos los casos más probables para su aplicación.

Si el atacante cuenta con los permisos necesarios, puede llevar a cabo un ataque contra el sistema LAPS para obtener acceso al atributo que almacena la contraseña de la cuenta de administrador local.

Esta actividad puede detectarse controlando las solicitudes de acceso a los atributos de Active Directory relacionados con LAPS, ya que estos almacenan contraseñas locales administradas e información administrativa sobre su rotación. El acceso no autorizado a dicha información puede indicar un intento de obtener credenciales privilegiadas.

Kaspersky EDR (KEDR) Expert detecta esta actividad con las siguientes reglas: computer_discovery_via_ldap, laps_passwords_scan_via_ldap y not_signed_process_ldap_request.

Además, para obtener acceso a las credenciales, un atacante puede intentar extraer información confidencial directamente de la memoria del proceso lsass.exe. Este proceso es responsable de la autenticación y almacena temporalmente hash de contraseñas, tickets de Kerberos y otras credenciales que usa el sistema para autenticar a los usuarios y servicios. Este tipo de actividad en un host en riesgo suele ir acompañada de la apertura del proceso con derechos de acceso elevados, el uso de mecanismos de volcado de memoria o la llamada a las API del sistema para leer regiones de memoria protegidas. Estas acciones son anómalas para la mayoría de los procesos de usuarios y aplicaciones, y constituyen un fuerte indicador de que el sistema está en riesgo.

Por lo tanto, para detectar esta actividad, el control debe centrarse en los procesos que acceden a la memoria de lsass.exe, ya que estos eventos identifican acciones maliciosas con precisión.

KEDR Expert detecta esta actividad con la regla suspicious_lsass_memory_access.

Además, los atacantes pueden intentar extraer credenciales de registros que almacenan parámetros de autenticación, datos en caché y valores de configuración que afectan el funcionamiento de los mecanismos de seguridad. En conjunto, estas acciones pueden aprovecharse para una posterior escalada de privilegios o movimiento lateral dentro de la red.

Para identificar esta actividad, es necesario controlar el acceso a los registros críticos. Esto permite rastrear las solicitudes que se originan en procesos atípicos o sospechosos.

KEDR Expert detecta esta actividad con la regla registry_key_sam_users_queried.

Uno de los métodos más comunes para obtener credenciales consiste en acceder a directorios que contienen datos de los usuarios del navegador. Los navegadores modernos almacenan una cantidad significativa de información confidencial en los perfiles locales, incluyendo nombres de usuario y contraseñas guardadas, cookies de sesión, tokens de autenticación, historial de navegación y datos de relleno automático de formularios. Al obtener acceso a los directorios de perfiles, un atacante puede extraer credenciales para servicios web corporativos, sistemas de correo electrónico y plataformas en la nube, así como usar cookies de sesión activas para eludir la autenticación y los mecanismos de autenticación multifactorial (MFA).

En algunos casos, estos datos están protegidos por herramientas del sistema operativo; sin embargo, cuando se accede a ellos en el contexto del usuario o con privilegios elevados, pueden descifrarse y aprovecharse para avanzar en el ataque. Obtener acceso a los datos del navegador suele servir como punto de partida para el movimiento lateral, el compromiso de cuentas adicionales y el establecimiento de persistencia dentro de la infraestructura.

Para detectar esta actividad, es necesario controlar el acceso a los directorios que contienen datos confidenciales del navegador. Es importante considerar no solo el acceso a los catálogos de perfiles en sí, sino también la naturaleza de las operaciones realizadas: lectura masiva de archivos de base de datos, copia de estos a directorios temporales, creación de archivos comprimidos y ejecución de procesos que normalmente no interactúan con los perfiles de usuario.

Se debe prestar especial atención a los casos en los que estas acciones se realizan fuera de una sesión interactiva de usuario; por ejemplo, desde el contexto de procesos con privilegios elevados o cuentas de servicio. Esto puede indicar un intento de recolección centralizada de credenciales. También resulta útil correlacionar los eventos de archivos con la actividad de red, ya que los datos extraídos a menudo se preparan para su exfiltración a recursos externos.

KEDR Expert detecta esta actividad con la regla credentials_from_web_browsers.

Además, la obtención de credenciales también se basa en gran medida en ataques al protocolo Kerberos. Las configuraciones incorrectas en este mecanismo de autenticación pueden permitir que un atacante obtenga acceso a cuentas con privilegios elevados, lo que crea las condiciones para que el ataque avance. AdaptixC2 cuenta con módulos especializados diseñados para aprovechar características específicas del protocolo Kerberos.

Para identificar esta actividad, la auditoría de Active Directory para Kerberos debe estar configurada correctamente. Esto permite detectar ataques mediante el análisis de los eventos de seguridad de Windows, específicamente los ID de evento 4768 y 4769, que registran la emisión y el uso de tickets de autenticación.

KEDR Expert detecta este comportamiento con la regla possible_asreproasting_via_preauth_value.

Evasión de defensas

Durante las operaciones maliciosas, los atacantes suelen intentar minimizar los indicios sospechosos para evadir los controles de seguridad. Una técnica común para lograrlo es inyectar código malicioso en el espacio de direcciones de un proceso legítimo.

En consecuencia, la carga útil se ejecuta bajo la identidad de un sistema confiable o de un proceso de usuario, lo que complica significativamente la detección tanto por parte de los mecanismos de seguridad basados en firmas como de los basados en el comportamiento.

Para detectar esta actividad, los defensores deben controlar el uso de funciones de WinAPI frecuentemente asociadas con la inyección de procesos. Entre ellas se incluyen llamadas que permiten obtener acceso a un proceso remoto, asignar memoria dentro de su espacio de direcciones, escribir código arbitrario e iniciar la ejecución.

Por lo general, estas acciones ocurren de manera secuencial, formando una cadena característica: abrir un proceso de destino, asignar memoria, escribir datos e iniciar un nuevo hilo o modificar el contexto de ejecución. Dichas secuencias (especialmente cuando ocurren entre procesos con niveles dispares de privilegios o confianza) son fuertes indicadores de un intento de inyección de procesos.

Otra señal de alerta es cuando un proceso de usuario estándar inicia estas operaciones contra procesos del sistema o procesos legítimos de uso generalizado. Los atacantes prefieren este enfoque para enmascarar la actividad maliciosa y eludir las capas de defensa tradicionales.

Movimiento lateral

La progresión posterior de un ataque suele implicar un movimiento lateral dentro de la red, una capacidad totalmente integrada en AdaptixC2.

Analicemos las técnicas de detección del movimiento lateral usando como ejemplo principal el abuso del servicio WinRM (Administración remota de Windows).

Para detectar esta actividad, los defensores deben controlar los procesos característicos de WinRM, ya que estos facilitan la ejecución remota de comandos. Por lo general, los procesos que atienden las sesiones de WinRM actúan como procesos principales para cualquier proceso nuevo que se inicie mediante la administración remota. En consecuencia, los comandos ejecutados a través de WinRM generan procesos secundarios que pueden parecer iniciados localmente, pero su árbol de procesos revela un proceso principal vinculado a la infraestructura de WinRM. Esta cadena específica es un indicio clave para descubrir el uso indebido de la administración remota.

Además, el lanzamiento de shells de comandos, utilidades administrativas o herramientas de reconocimiento a través de WinRM se considera altamente sospechoso, especialmente si este comportamiento es anómalo para el host específico.

KEDR Expert detecta esta actividad con la regla suspicious_processes_spawned_by_winrm.

Conclusión

El marco posterior al abuso AdaptixC2 sigue evolucionando y ganando terreno. A medida que surgen nuevos agentes y mecanismos de persistencia sigilosos, también se amplía el repertorio de técnicas usadas para establecer un punto de apoyo, realizar funciones de comando y control, y moverse lateralmente. Sin embargo, a pesar de la diversidad de protocolos compatibles, las comunicaciones de red de AdaptixC2 conservan varias características persistentes. Es por eso que las soluciones NDR son capaces de detectar agentes de manera efectiva basándose en el análisis del tráfico de red. Los productos de Kaspersky ofrecen dicha funcionalidad en Kaspersky Anti Targeted Attack.

KATA está diseñado para identificar amenazas modernas dentro de la infraestructura de red, detectando marcos comunes posteriores al abuso a través de sus firmas de comunicación distintivas. Incluso cuando un agente emplea técnicas avanzadas de evasión, enmascaramiento u ofuscación en el endpoint, debe mantener una conexión con su servidor C2 para recibir comandos, exfiltrar resultados y coordinar las etapas posteriores del ataque. Por lo tanto, el control del tráfico de red sigue siendo un método vital y eficaz para descubrir la actividad de AdaptixC2.

Como complemento a la detección en la capa de red, es importante brindar visibilidad sobre la actividad en las estaciones de trabajo y los servidores mediante una potente solución de detección y respuesta de endpoints, como Kaspersky EDR Expert. Un paquete como ese permite capturar cadenas de acciones específicas posteriores al abuso y correlacionar eventos aislados de los hosts en un contexto de ataque unificado. El uso combinado de KATA y KEDR mejora la cobertura de detección, identificando tanto las manifestaciones de la red del marco como las maniobras internas del agente. Este enfoque de múltiples capas es fundamental para contrarrestar los ataques modernos y sofisticados que se basan en herramientas posteriores al abuso y en la administración encubierta.

Veredictos de la solución de Kaspersky (Kaspersky Anti Targeted Attack)

Backdoor.AdaptixC2.TLS.C&C
Backdoor.AdaptixC2.TCP.C&C
Backdoor.AdaptixC2.SMB.C&C
Backdoor.AdaptixC2.HTTP.C&C
Backdoor.AdaptixC2.DNS.C&C