Detección eficaz de balizas C2

Introducción

Los atacantes están incorporando capacidades nuevas y sofisticadas de comando y control (C2) a su malware, que evaden fácilmente las defensas estáticas comunes basadas en firmas IPS o listas de bloqueo de IP/dominios/URL mediante el uso de herramientas de frameworks C2 comunes y ampliamente disponibles, como Cobalt Strike, Brute Ratel, Mythic, Metasploit, Sliver y Merlin. Estas herramientas proporcionan capacidades posteriores a la explotación, como comando y control, escalada de privilegios y acciones en el host, y originalmente se diseñaron para pruebas de penetración y operaciones de equipos rojos.

Sin embargo, los atacantes han secuestrado e integrado estos mismos kits de herramientas con fines maliciosos, ya que muchos productos son de código abierto, como Mythic y Merlin, mientras que otros productos comerciales, como Cobalt Strike y Brute Ratel, han sido robados por atacantes mediante copias pirateadas o filtraciones de código fuente. Esto ha convertido, en la práctica, esas mismas herramientas en frameworks C2 adversarios para actividades maliciosas posteriores a la explotación.

Las herramientas pueden configurar y modificar fácilmente numerosos parámetros de las comunicaciones C2, lo que permite que el malware eluda las defensas actuales aún más fácilmente y durante periodos más prolongados, causando mayores daños en las redes de las víctimas, entre ellos: robo de más datos, descubrimiento de datos más valiosos, indisponibilidad de aplicaciones o servicios empresariales y mantenimiento de acceso oculto a las redes para causar daños futuros.

Los enfoques actuales para detectar el malware más reciente que utiliza frameworks C2 emplean firmas e indicadores estáticos, incluida la detección de ejecutables de implantes, firmas IPS para detectar tráfico C2 y filtros de IP/URL que resultan inadecuados para hacer frente a los perfiles dinámicos y maleables de las herramientas de frameworks C2 ampliamente disponibles.

Se necesita un nuevo enfoque que no esté vinculado de manera tan rígida a ataques conocidos, sino que se base en la detección de anomalías mediante un conjunto integral de señales introducidas en modelos entrenados de aprendizaje automático, con un seguimiento detallado del riesgo de dispositivos y usuarios. Este enfoque complementará los enfoques existentes, pero puede aumentar considerablemente las tasas de detección, mantener un nivel bajo de falsos positivos y ofrecer preparación para el futuro frente a patrones cambiantes de tráfico C2 que estas mismas herramientas de frameworks C2 permiten implementar fácilmente.

Este documento analiza las deficiencias de los enfoques actuales y la mayor eficacia derivada del uso de un enfoque específico de aprendizaje automático con señales de red adicionales y métricas de riesgo detalladas basadas en modelos a nivel de usuario y organización. También analizamos algunos de los principales desafíos al probar la eficacia de cualquier solución de detección de balizas C2.

Frameworks C2 adversarios

Cobalt Strike, Metasploit, Mythic y Brute Ratel son algunas de las herramientas comerciales y de código abierto para la simulación de adversarios que se diseñaron originalmente para que los equipos rojos probaran la detección de malware. En ocasiones, estos kits de herramientas se denominan herramientas de emulación de amenazas o frameworks C2, ya que ofrecen un amplio conjunto de funciones (Gill) para simular actividad real de amenazas durante operaciones de equipos rojos, con especial atención a las partes de comando y control posteriores a la explotación de la cadena de ataque.

Es posible que utilicemos algunos de estos términos indistintamente a lo largo del documento, pero en general emplearemos frameworks C2 para destacar que actores maliciosos utilizan estas herramientas para afectar a entornos de producción y que el problema que debe resolverse va mucho más allá de las simulaciones o emulaciones realizadas por equipos rojos internos de confianza.

Estas herramientas de frameworks C2 se han integrado, pirateado o robado, y han sido utilizadas por numerosos atacantes (“Cobalt Strike: una operación internacional de las fuerzas del orden aborda los usos ilegales de la «navaja suiza» de las herramientas de pruebas de penetración”), incluidos actores estatales como el APT29 de Rusia en SolarWinds (“El ataque a la cadena de suministro de SolarWinds utiliza la puerta trasera SUNBURST”) y el TA415 de la República Popular China (Larson y Blackford), con el fin de mejorar y desarrollar las capacidades de comunicación sigilosa de diversos RAT, botnets y malware habilitado para C2.

Cobalt Strike es la herramienta de framework C2 más popular y la utilizamos como ejemplo específico en todo este documento, aunque las observaciones se aplican a todas las herramientas similares. El siguiente diagrama de arquitectura de alto nivel de Cobalt Strike muestra sus componentes básicos (Rahman) y el flujo de ataque en tiempo de ejecución.

Cobalt Strike y kits de herramientas similares permiten configurar de forma sencilla y muy amplia el tráfico HTTP/S, lo que produce tráfico C2 que a menudo parece benigno, se asemeja al tráfico HTTP/web normal y es similar al tráfico de navegadores web o aplicaciones populares. Las herramientas incluyen configuraciones predeterminadas que emulan tanto malware conocido como aplicaciones válidas conocidas.

Aunque DNS también es compatible como protocolo C2, centraremos el análisis en C2 sobre HTTP/S, ya que representa la mayor parte del tráfico de red entrante y saliente de una organización, es más complejo debido a la variedad de aplicaciones que utilizan HTTP/S y atrae a la mayoría de los actores maliciosos que intentan ocultarse entre el ruido de la red, incluidas las balizas C2 legítimas y benignas.

Los kits de herramientas son altamente configurables mediante perfiles maleables y pueden modificar fácilmente el tiempo, la frecuencia, el volumen, los protocolos de aplicación, las IP o los dominios de destino, los agentes de usuario, los encabezados HTTP, los verbos HTTP, los URI, los parámetros, los certificados SSL/TLS, el retraso de las balizas con fluctuación aleatoria y la carga útil o el contenido. Las herramientas de frameworks C2 también permiten ejecutar una gran cantidad de acciones posteriores a la explotación, que se cifran, descargan y ejecutan en memoria, lo que dificulta enormemente la detección de la actividad posterior a la intrusión en los endpoints.

Nos centraremos en las capacidades específicas de comunicación C2 de las herramientas de frameworks C2 —por ejemplo, las balizas C2—, en la facilidad con la que se modifican las comunicaciones —por ejemplo, mediante los C2 Malleable Profiles de Cobalt Strike— y en los desafíos a los que se enfrentan las organizaciones al intentar detectar malware sigiloso.

Existen varios recursos útiles que analizan la funcionalidad de los Malleable Profiles de Cobalt Strike (Gill), pero destacaremos algunas de las funciones utilizadas habitualmente. A continuación se muestra un fragmento del perfil maleable para imitar la aplicación Gmail del navegador en Cobalt Strike (Mudge):

Algunas de las funciones y áreas clave del perfil son:

# Use an existing certificate or generate a self-signed certificate as seen in the above example.

# These global options below set the C2 beacon sleep time to 60 seconds with a
# random jitter of +/- 15%, showing the ability to vary the call-home timing to avoid
# easy detection.
set sleeptime “60000”;
set jitter “15”;

# Other global options specify on-host post-exploit action parameters such as the
# process name spawned to execute commands using in-memory injection or the
# pipename used for IPC communications. These are not relevant to C2.
set pipename “interprocess_##“;
set spawnto “userinit.exe”;

# The uri path used for beacon->server communications can be varied with a list
set uri “//scs/mail-static//js/”;

# Client (beacon->server) communications including cookies, headers, and encoding
# can all be specified and varied easily at the HTTP protocol level
client {
    metadata {}
    header {}
}

# Similarly, server->beacon communications can also be varied at the HTTP
# protocol level
server {
    header {}
}

# Cobalt Strike allows shaping of the 2-way communications flow between the
# Beacon client and C2 Team Server (“A Beacon HTTP Transaction Walk-through”):
# 0. http-stager {}    optional stager to download full Beacon
# 1. http-get {client}  client  — call home -> server
# 2. http-get {server}  server  — cmds -> client
# 3. http-post {client} client  — cmd output -> server
# 4. http-get {server}  server  — confirm -> client

Como puede observarse, unas modificaciones sencillas de estos perfiles pueden cambiar fácilmente el comportamiento de las comunicaciones C2 para imitar aplicaciones comunes, sus balizas y el tráfico web. Existen más de 240 perfiles maleables públicos solo para Cobalt Strike, disponibles para su uso inmediato o que pueden modificarse con facilidad.

Enfoques de detección actuales

Los enfoques actuales para detectar tráfico C2 malicioso suelen comparar firmas de bytes codificadas de forma rígida o utilizar expresiones regulares para encontrar coincidencias en la carga útil o los encabezados —firmas IPS—, o bien se basan en la comparación con listas de IP/dominios/URL. Estos enfoques son estáticos y pueden evadirse fácilmente debido a la naturaleza dinámica y configurable de los kits de herramientas de frameworks C2 integrados por los atacantes.

Firmas IPS

Para ilustrar los desafíos de las soluciones IPS, a continuación se muestra una de las reglas de Snort para detectar el troyano Zeus (Snort):

Snort y muchas soluciones IPS permiten diversas coincidencias de contenido o encabezados en las capas 3 y 4, así como en el nivel de aplicación, como indican los verbos de acción de la regla. Muchas coincidencias, como la opción de regla content, son comparaciones estáticas de bytes o caracteres, mientras que la opción de regla pcre es una comparación mediante expresiones regulares.

Al observar en paralelo tanto el lado del adversario —por ejemplo, el C2 Malleable Profile para gmail visto anteriormente— como el lado defensivo —por ejemplo, la regla de Snort para Zeus—, quedan claras la fragilidad y la naturaleza estática de las coincidencias codificadas de forma rígida. Imagine que un atacante hubiera creado e implementado una nueva variante de Zeus que utilizara Cobalt Strike y que un IPS de Snort tuviera implementada la regla anterior de Zeus, que detectara eficazmente el nuevo malware. El atacante podría cambiar fácilmente un carácter del perfil, por ejemplo, añadir un espacio en MSIE para evitar la coincidencia: content:"|3B 20|MSIE|20|"; de este modo, el malware podría evadir la firma IPS.

Aunque existe conocimiento del contexto y seguimiento del estado, el enfoque de las firmas IPS está limitado de manera inherente debido a sus coincidencias estáticas, lo que genera falsos negativos y facilita la evasión —literalmente, cambiar un carácter de un campo podría eludir una regla IPS—.

Esto no significa que las soluciones IPS no sean útiles. Por el contrario, las firmas IPS deben conservarse, ya que constituyen una defensa perimetral útil que bloquea numerosos exploits de red conocidos de forma rápida y eficiente. En este caso, incluso si un IPS solo lograra tasas de detección del 60 %, ese 60 % podría bloquearse o generar alertas fácilmente, evitando un costoso procesamiento posterior.

Listas de bloqueo de IP/URL

Otros enfoques tradicionales, como el uso de listas de bloqueo —de IP o URL—, suelen aplicarse para intentar impedir el acceso inicial o la descarga de malware durante la navegación web, así como para bloquear posible tráfico C2.

Un problema habitual de las listas de bloqueo es que suelen estar desactualizadas, lo que provoca falsos positivos, y son reactivas, ya que se actualizan después de que el objetivo n.º 1 o paciente cero haya sufrido una intrusión.

Esto se agrava debido a las técnicas de redirección de IP/dominios utilizadas para ocultar el dominio o la dirección IP del servidor C2. Cobalt Strike dispone de redirectores, que pueden ser tan sencillos como proxies IP, para ofuscar el verdadero dominio o la IP del servidor C2. También existen otras técnicas, como el domain fronting mediante CDNs o la suplantación de dominios, que aprovechan las discrepancias entre TLS (SNI) y HTTPS (host) para ocultar el dominio malicioso final a algunos filtros de seguridad de URL.

Heurística del tráfico de red

Un enfoque diferente implica el uso de heurística, aplicada normalmente a patrones de tráfico de red basados en el volumen o el tiempo. El ejemplo clásico consiste en detectar comunicaciones salientes periódicas —por ejemplo, cada 60 minutos—, quizá hacia una dirección IP sin un registro DNS A registrado.

Para evadir la detección, los kits de herramientas de frameworks C2 permiten configurar fácilmente un factor aleatorio en el retraso de las balizas mediante el ajuste de fluctuación de un Cobalt Strike Malleable Profile:

Figura 4: Configuración de C2 Malleable Profile (temporización de balizas)

Esta configuración especifica un intervalo de comunicación con el servidor de origen de 60 segundos +/- 15 %, lo que significa que el intervalo real oscilará entre 51 y 69 segundos, eludiendo las comprobaciones sencillas de balizas recurrentes a intervalos constantes.

Eficacia

El problema de los enfoques actuales es que no detectan eficazmente las comunicaciones C2 maleables y pueden evadirse con facilidad incluso cuando se ajustan específicamente. Cumplen una función al detectar de manera eficiente técnicas de ataque estáticas con indicadores bien conocidos, pero no detectan ataques más dinámicos o sofisticados, o bien generan una gran cantidad de falsos positivos.

Como dato de referencia, al probar los Cobalt Strike C2 Malleable Profiles más comunes de repositorios públicos, las soluciones IPS listas para usar, como Snort y Suricata, detectaron bastante menos del 20 % de las comunicaciones C2 de los kits de herramientas de frameworks C2 más comunes.

Incluso después de añadir específicamente reglas para buscar coincidencias con tantos perfiles públicos como fuera posible y optimizar para esta prueba concreta, la cobertura solo pudo aumentar razonablemente hasta aproximadamente el 60 % sin introducir falsos positivos significativos, que resultarían muy problemáticos en un entorno de producción.

Existen numerosos problemas de eficacia: no solo un mayor número de falsos positivos, sino que la configuración resultante está construida rígidamente para la prueba específica en cuestión y puede evadirse con facilidad mediante pequeños ajustes en los perfiles. En última instancia, aproximadamente el 40 % de los perfiles sigue sin detectarse, lo que representa una tasa muy alta de falsos negativos. Esto sin mencionar los falsos negativos adicionales ocasionados por un atacante decidido que personalice los perfiles C2 para imitar aplicaciones existentes y conocidas de una forma ligeramente diferente.

Nuevo enfoque de detección

Se necesita un enfoque más eficaz que no se base exclusivamente en indicadores estáticos, sino en modelos específicos de aprendizaje automático capaces de detectar anomalías en el tráfico de red mediante una multitud de señales de red que indiquen actividad sospechosa de comando y control, en comparación con el comportamiento habitual de las aplicaciones válidas para usuarios concretos de una organización específica. Además, deben supervisarse métricas de riesgo detalladas a nivel de usuario para aplicar las medidas de mitigación más precisas y eficaces. Se necesitan innovaciones en estas tres áreas para lograr mejoras importantes en la detección de balizas C2 sigilosas procedentes de herramientas de frameworks C2:

Señales integrales

Se necesita un conjunto integral de señales que debe incluir características del origen, el destino y el tráfico, como los certificados SSL/TLS utilizados tanto en el origen —el malware dentro del entorno— como en el destino —el servidor C2—, el dominio/IP/URL, características del origen como las del agente de usuario o del proceso, tamaño, variabilidad y patrones del tráfico, encabezados HTTP, carga útil y URI, por citar solo algunas.

Al observar distintas señales relacionadas con el tiempo, el volumen, las capas de red y la caracterización general del tráfico, la detección de comportamientos puede proporcionar un mecanismo general y eficaz para detectar el malware más reciente mediante actividad sospechosa y maliciosa de balizas C2.

Los tipos de señales tienen varias dimensiones:

• Flujo de red: atributos de origen y destino, así como patrones de tráfico
• Capas de red: diferentes señales desde la capa 3 hasta la 7 —anomalías en encabezados TCP/IP, huellas digitales SSL/TLS, encabezados y cargas útiles HTTP, y contenido de nivel de aplicación—
• Tiempo: frecuencia y patrones temporales anómalos para detectar actividad infrecuente y lenta
• Datos: contenido y volumen —tamaños de paquetes anómalos, ráfagas y estadísticas acumuladas—

Además, existen varios tipos de señales:

• Basadas en patrones de tráfico —volumen, tiempo y contenido—, incluidas las balizas repetidas en combinación con un agente de usuario o dominio inusual.
• Heurística —por ejemplo, registradores sospechosos o huellas digitales SSL maliciosas conocidas—
• Anomalías —dominio, agentes de usuario o huellas digitales SSL inusuales—

Un aspecto importante es que algunas de las señales anteriores forman parte de los enfoques actuales y de las soluciones existentes. Esto refuerza la idea de que una señal concreta, como un pico de tráfico —gran volumen—, no es buena ni mala, eficaz ni ineficaz por sí sola. Por el contrario, el contexto y el procesamiento de la señal son los factores determinantes. Cuando se utiliza en el perímetro de una red para bloquear o permitir tráfico, una señal propensa a falsos positivos puede causar problemas operativos graves. Sin embargo, cuando se introduce en un sistema de detección de anomalías que incorpora esa señal a una métrica de riesgo granular —analizada a continuación— y a un modelo bien entrenado, puede ser extremadamente eficaz para detectar nuevas amenazas de manera sólida y con pocos falsos positivos.

Detección de anomalías

La detección eficaz de balizas C2 procedentes de kits de herramientas de frameworks C2 requiere modelos de aprendizaje automático basados en una gama más completa de señales para identificar los kits de herramientas de frameworks C2 actuales y futuros comportamientos de red sospechosos que podrían indicar actividad C2.

La detección de anomalías debe basarse en modelos a nivel de usuario o dispositivo, función y organización. Es decir, las anomalías presuponen que disponemos de una referencia válida de actividad o comportamiento «normal» con la cual realizar una comparación. La detección de actividad sospechosa puede producirse en diferentes circunstancias. Existen anomalías basadas en las acciones de un usuario frente a su referencia histórica «normal», frente a la referencia «normal» de la organización o frente a las personas que desempeñan funciones similares. Todos estos modelos tienen casos de uso válidos que no cubren los demás, y un buen enfoque incorporará varios modelos con distintos ámbitos.

Datos de entrenamiento

Los conjuntos de datos de entrenamiento deben incluir tráfico tanto malicioso como benigno:

• El tráfico malicioso puede simularse mediante herramientas generales de pruebas C2, pruebas específicas de balizas C2 adversarias basadas en configuraciones disponibles públicamente de herramientas de frameworks C2, así como configuraciones personalizadas desde la perspectiva de un equipo rojo y ejercicios oficiales de equipos rojos.
• El tráfico benigno o válido se recopila mejor a partir de una cantidad significativa de usuarios reales de organizaciones reales durante un periodo suficiente para normalizar los sesgos de los usuarios y de la organización.

Los conjuntos de datos de entrenamiento son la otra cara de los conjuntos de datos de prueba, y debe dedicarse mucho tiempo a analizar y validar datos adecuados de entrenamiento y prueba. Algunos de los factores necesarios para crear buenos conjuntos de datos de prueba se analizan en una sección posterior.

Métricas de riesgo granulares

El resultado de la detección de anomalías es fundamental. El mejor enfoque no realiza determinaciones sencillas de bloqueo/permiso o alerta/silencio a partir de una señal sin procesar, sino que supervisa y ajusta métricas de riesgo detalladas a nivel de usuario, función y organización, que posteriormente pueden utilizarse para aplicar medidas correctivas como alertas, formación o bloqueo.

Este enfoque para supervisar el riesgo y actuar en función de él es fundamentalmente diferente al que se utiliza habitualmente en la actualidad. La mayoría de las defensas perimetrales preventivas, que normalmente bloquean, generan alertas o permiten el tráfico, suelen ser estáticas y propensas a altas tasas de falsos positivos. El resultado neto es que estas soluciones se habilitan con una política conservadora para bloquear riesgos ciertos y conocidos, lo que a su vez genera un gran número de falsos negativos. Con los firewalls, observamos problemas de falsos positivos provocados por acciones de bloqueo excesivamente agresivas basadas en inteligencia de amenazas de IP. Con las soluciones IPS, hemos analizado los problemas de falsos positivos de las firmas estáticas que intentan detectar tráfico C2 altamente configurable y dinámico.

Sin embargo, los falsos positivos de una capa perimetral pueden resultar muy útiles como señal para una capa más inteligente. En este escenario, no la utilizaríamos para una evaluación binaria —permitir/bloquear, alertar/ignorar—, sino como una métrica de riesgo detallada que se ajusta con el tiempo —por ejemplo, una puntuación de riesgo del usuario—, con un umbral calibrado antes de tomar medidas. Una métrica de riesgo granular, por ejemplo, una puntuación de riesgo de 1000 —sin riesgo— a 0 —riesgo extremo— para un usuario, dispositivo o incluso una dirección IP, permite modelar el espectro de grises asociado con las amenazas del mundo real, donde rara vez existen evaluaciones claramente maliciosas al 100 % o benignas al 100 %.

Conceptualmente, esto se representa en la siguiente ilustración, donde podrían detectarse tres señales diferentes que, por sí solas, serían propensas a falsos positivos. Sin embargo, cuando se asocian con un riesgo incremental y se evalúan mediante un modelo calibrado de aprendizaje automático, las mismas señales permiten evaluar el riesgo acumulado a lo largo del tiempo y, en última instancia, proporcionan una detección de anomalías con un alto nivel de confianza.

Tenga en cuenta que las señales de este ejemplo pueden no ser tan sencillas como las señales estáticas. Por ejemplo, un «dominio inusual, agente de usuario no reconocido y certificado SSL/TLS» podría constituir una anomalía al compararlo con la referencia «normal» del tráfico anterior de ese usuario específico, con usuarios que desempeñan funciones similares o con toda la organización. Un «registrador sospechoso» puede ser una combinación de la reputación del dominio correlacionada a lo largo del tiempo. Y las «balizas periódicas» ya no consisten en una simple coincidencia con una frecuencia o duración fija, sino que pueden detectar actividad anómala, aunque regular y repetida, dentro de un intervalo temporal, similar a la actividad de bots en contraposición a las comunicaciones externas válidas de los daemons de aplicaciones.

En la práctica, esto nos permite ajustar una puntuación de riesgo de manera incremental y adecuada a partir de una señal de baja fidelidad. No se produce ninguna acción de bloqueo ni alerta hasta que la puntuación de riesgo acumulada supera un umbral alto y calibrado. Esto permite capturar casos en los que existen numerosos indicadores de baja fidelidad y ligeramente arriesgados que, al combinarse con un indicador de mayor fidelidad y riesgo para un usuario o dispositivo concreto, generan de forma acumulativa una alerta de riesgo crítico y una acción con una probabilidad de falsos positivos drásticamente inferior.

Evaluación y pruebas

Un nuevo enfoque puede ser sólido en teoría y fracasar estrepitosamente en la práctica, y la prueba suele depender de los datos o de las pruebas realizadas. Los proveedores de soluciones y las organizaciones que buscan soluciones necesitan un enfoque sólido para probar nuevas amenazas y evaluar soluciones. Para obtener resultados precisos, es esencial realizar pruebas con un conjunto de datos diverso que incluya tráfico tanto malicioso como benigno.

Tráfico benigno

El tráfico benigno debe ser realista, integral y similar al de producción en cuanto al número de usuarios y la actividad. El tráfico adecuado, que a menudo depende del usuario, debe estudiarse con una muestra amplia de usuarios y durante un periodo razonable. Este conjunto de datos de prueba medirá las tasas de falsos positivos (FP). Las principales variaciones de los conjuntos de datos serán las señales del cliente, como las aplicaciones, los agentes de usuario y los certificados SSL/TLS del cliente utilizados; las señales de destino observadas en los dominios o direcciones IP de destino; y las señales de patrones de tráfico en los encabezados, la carga útil, el tamaño y el tiempo.

La buena noticia es que el tráfico benigno adecuado puede recopilarse fácilmente a partir de las operaciones diarias de los usuarios de la organización; la mala noticia es que debe validarse como benigno. El enfoque práctico consiste en tomar una muestra estadística del tráfico benigno con un factor de confianza razonable y, después, dedicar la mayor parte del tiempo a las alertas de la solución de detección C2 que se está probando, verificándolas como verdaderos positivos o falsos positivos. En otras palabras, primero se toman muestras y se verifican para establecer una referencia, se presupone que el conjunto de datos benignos está limpio y, a continuación, se procede a identificar falsos positivos mediante las pruebas.

Tráfico malicioso

El uso de perfiles públicos de herramientas de frameworks C2 populares proporciona una base sólida para probar el tráfico malicioso. Estos perfiles representan configuraciones prácticas y utilizadas con frecuencia que evaden las defensas, y ayudan a medir las tasas de falsos negativos (FN). Sin embargo, debe prestarse mucha atención a la creación de un conjunto de datos representativo de «tráfico malicioso», ya que potencialmente existen varios niveles de cobertura y diferentes aspectos evaluados por los conjuntos de datos, como se muestra en el siguiente diagrama:

1. Herramientas de simulación de intrusiones y ataques, como SafeBreach, son excelentes para realizar pruebas de cobertura y pruebas repetidas. Sus casos de prueba C2 suelen incluir al menos alguna simulación de actividad de frameworks C2. La ventaja es que se dispone de una amplia gama de funciones, incluidos ataques generales de malware, con GUI y arquitecturas bien diseñadas, así como procedimientos de prueba e informes repetibles. Estas herramientas pueden proporcionar una gran variedad de escenarios, entre ellos: actividad lenta y de bajo volumen, infraestructura IaaS/CSP, tráfico HTTP y no HTTP, tráfico SSL/HTTPS y suplantación de diversos agentes de usuario.
2. Herramientas de frameworks C2 (perfiles públicos). Las pruebas exhaustivas de frameworks C2 requieren un trabajo específico. Un enfoque consiste en crear un conjunto de datos de prueba basado en los perfiles públicos específicos de las herramientas de frameworks C2, por ejemplo, Cobalt Strike. Estos perfiles maleables públicos suelen compartirse ampliamente y son utilizados por muchos usuarios y actores maliciosos, ya que incluyen emulaciones útiles de aplicaciones benignas como gmail. Este enfoque suele proporcionar pruebas más completas de los frameworks C2 específicos.
3. Herramientas de frameworks C2 (perfiles personalizados). La personalización interna de los C2 Malleable Profiles puede proporcionar pruebas aún más realistas de los frameworks C2. Estas configuraciones personalizadas pueden realizarse durante operaciones internas de equipos rojos. Esto requiere más trabajo e inversión, ya que los operadores de los equipos rojos deben dominar las herramientas de frameworks C2.
4. Ataques realistas. Las pruebas más realistas implican pruebas de caja negra mediante pruebas de penetración externas o programas de recompensas por errores. En estos escenarios, los requisitos del ejercicio se diseñan cuidadosamente para exigir o incentivar exploits POC reales que utilicen herramientas específicas de frameworks C2 o cualquier comportamiento de balizas C2, con la condición de evitar la detección durante un periodo determinado. Los objetivos de los ejercicios no solo consisten en probar los vectores de acceso inicial, como es habitual, sino también en centrarse en la actividad posterior a la intrusión demostrando la capacidad de instalar una carga útil de puerta trasera con actividad C2 comprobada. Esto enriquece el conjunto de datos de prueba más allá de los frameworks C2, permite probar código POC de puertas traseras con comunicaciones C2 personalizadas y también constituye una prueba excelente de la resiliencia de cualquier herramienta de detección frente a un «atacante» experto que utilice TTP diferentes o personalizadas.

Las pruebas pueden implicar uno o varios enfoques, pero deben tomarse decisiones explícitas sobre cómo crear, recopilar y validar los conjuntos de datos de prueba y cómo medir los resultados esperados. Crear y recopilar los conjuntos de datos de prueba es muy importante para que las pruebas puedan automatizarse y repetirse fácilmente.

También es fundamental medir todas las métricas durante las pruebas: verdaderos y falsos positivos, verdaderos y falsos negativos. Aunque recopilar todas las métricas parece obvio, resulta difícil definirlas con precisión y establecer una metodología de medición clara y repetible, lo que puede generar resultados engañosos.

Objetivos de falsos positivos y falsos negativos

En el caso de las nuevas amenazas evasivas creadas mediante frameworks C2, ninguna solución de detección más reciente tendrá tasas de FP y FN ampliamente aceptadas. Sin embargo, es esencial definir objetivos de FP y FN. Con conjuntos de datos de prueba de calidad conocida, pueden establecerse referencias para el entorno actual y sus usuarios o dispositivos, lo que permite definir objetivos razonables en relación con dichas referencias.

Por ejemplo, supongamos que una organización que solo dispone de un IPS comienza a evaluar nuevas soluciones de detección C2 y no está claro qué tasas de FP/FN son aceptables. La organización aún puede establecer objetivos razonables siguiendo una metodología de pruebas como la siguiente:

• Crear datos de prueba de calidad para el tráfico benigno a partir de datos de producción y para el tráfico malicioso a partir de, por ejemplo, perfiles maleables C2 públicos de Cobalt Strike, y validar manualmente muestras de esos conjuntos de datos.
• Crear una metodología de pruebas clara y repetible mediante la definición de herramientas de prueba y medición.
• Medir todas las métricas (TP/TN/FP/FN) durante las pruebas.
• Probar nuevas soluciones y comparar las métricas. Por ejemplo, el IPS podría ajustarse específicamente para mejorar las tasas de TP del tráfico malicioso, pero debe garantizarse que las tasas de FP/TN/FN también se midan y validen. De este modo, puede evaluarse correctamente la eficacia de distintas soluciones, especialmente en lo relativo al impacto total sobre la organización, como se describe en la sección sobre impacto que aparece más adelante.
• Probar nuevos conjuntos de datos y compararlos. Procure personalizar los conjuntos de datos para reflejar ajustes razonables realizados por un atacante. Existen varias formas de hacerlo.
  • Por ejemplo, al probar Cobalt Strike, sus C2 Malleable Profiles pueden modificarse fácilmente para emular aplicaciones benignas de forma ligeramente diferente o aplicaciones benignas completamente nuevas que se utilicen dentro de la organización específica. Esto puede hacerse capturando tráfico HTTP/S saliente mediante un proxy.
  • Pruebe no solo una herramienta de framework C2, sino varias, ya que difieren en cuanto a capacidades y técnicas. El uso de una herramienta de framework C2 distinta también supone un buen cambio, puesto que la configuración de su tráfico C2 será diferente.
  • Crear una carga útil de prueba personalizada con comunicaciones C2 propias codificadas manualmente es otra forma de modificar los conjuntos de datos de prueba, pero requiere la mayor cantidad de tiempo e inversión.

Pruebas de resiliencia

Al realizar pruebas con nuevos conjuntos de datos en distintas soluciones, también obtenemos información valiosa sobre la rigidez frente a la resiliencia de las diferentes soluciones. En este documento hemos señalado que los enfoques codificados de forma rígida y basados en firmas no solo son menos eficaces para detectar frameworks C2, sino que también son rígidos, lo que genera altas tasas de FP/FN y permite eludirlos fácilmente mediante cambios sencillos en los ataques, como modificaciones de perfiles maleables.

La resiliencia de cualquier solución puede probarse garantizando que los conjuntos de datos se modifiquen dentro de límites razonables —es decir, que permanezcan dentro de la misma categoría de TTP—. En otras palabras, podemos realizar una prueba de resiliencia realista modificando las comunicaciones C2 del conjunto de datos de tráfico malicioso mediante perfiles maleables C2 y supervisando las tasas de TP/TN/FP/FN. Observamos cómo varía la cobertura y también comprendemos qué cambios deben realizarse en la solución de detección para mantener la cobertura de determinados objetivos de TP/TN/FP/FN.

Volver a realizar pruebas con conjuntos de datos modificados de este modo equivale a que un atacante cambie sus TTP. Esto permite evaluar la resiliencia y eficacia de la nueva solución de detección, ya que podemos comprobar si aún es capaz de detectar cambios dentro de la misma categoría de técnica de amenaza —comunicaciones C2 sobre HTTP/S—.

Impacto de los falsos positivos y falsos negativos

Medir las tasas de FP/FN es útil y permite comprobar mejoras relativas, pero también es necesario medir o, al menos, estimar el impacto de los FP y FN; de lo contrario, resulta imposible evaluar la verdadera utilidad de cualquier solución de detección. En otras palabras, una tasa de FP del 1 % o una mejora del 5 % en la tasa de FP carece de contexto, a menos que podamos medir de algún modo el impacto de ese 1 % o +5 % de una forma que resulte comprensible para quienes toman decisiones sobre presupuestos de seguridad.

A continuación se presentan dos enfoques que pueden ayudar a traducir las tasas de TP/TN/FP/FN en un impacto más cuantificable:

1. Impacto sobre el usuario a lo largo del tiempo: examine el número absoluto de falsos positivos equivalente a las tasas de FP y normalícelo como una tasa por usuario a lo largo del tiempo. Se trata de una medida cualitativa, pero a menudo tiene más sentido que las tasas porcentuales o las cifras absolutas. Por ejemplo, en lugar de un 1 % de FP o 2437 falsos positivos, puede resultar más sencillo evaluar el impacto de 0,1 falsos positivos por usuario al día. Si se tratara de una gateway web segura, alguien de la organización podría determinar si un objetivo concreto de FP es aceptable en función del impacto sobre los usuarios a lo largo del tiempo. En este caso, el malware habilitado mediante frameworks C2 provoca intrusiones, y el impacto sobre el usuario se caracteriza más bien como tiempo de inactividad o pérdida de datos por usuario durante un periodo. Tenemos una probabilidad del N % de perder $X por usuario cada año. A menudo se trata de estimaciones aproximadas, pero cualquier punto de partida resulta útil, ya que puede revisarse y mejorarse mediante iteraciones periódicas. Si el impacto se evalúa en términos de usuarios a lo largo del tiempo, resulta sencillo evaluar soluciones de detección o protección, cuyo precio suele basarse en el número de usuarios por año.
2. Impacto sobre las operaciones de seguridad en términos de tiempo, dinero y probabilidad de intrusión. Además del impacto sobre los usuarios finales, debe evaluarse el impacto administrativo, especialmente sobre el personal de operaciones, que suele dedicar tiempo a gestionar alertas de detección. El tiempo dedicado a responder a alertas ruidosas puede traducirse directamente en costes salariales de FTE. El factor adicional de fatiga por alertas representa un impacto real que puede estimarse en términos de eficacia —tiempo de respuesta— y, lo que es más importante, como pérdida de tiempo y atención que deberían dedicarse a amenazas realmente más importantes, pero que se pierden o no se investigan. Este último impacto se convierte en un factor del impacto de las intrusiones: es más probable que estas se produzcan cuando las operaciones de seguridad tienen demasiados falsos positivos que investigar y eliminar.

Una evaluación del impacto suele ser la única forma de obtener información fundamental, como el coste real derivado de la eficacia de la detección. Por ejemplo, una solución de detección excesivamente agresiva, configurada con pocos FN y muchos FP, resulta inútil y perjudicial porque las operaciones de seguridad desperdician una cantidad desproporcionada de tiempo respondiendo a alertas de baja fidelidad, en lugar de realizar actividades de mayor valor. Del mismo modo, una solución de detección excesivamente conservadora, con pocos FP pero muchos FN, expone a la organización a un riesgo elevado de posible intrusión, lo que puede resultar inaceptable desde la perspectiva de una evaluación general del riesgo.

El impacto debe estimarse y evaluarse al mismo tiempo que las métricas principales de TP/FP/TN/FN.

Pruebas realistas

Utilice equipos rojos formados por personas, no solo herramientas automatizadas de intrusión o pruebas de penetración. Se recomienda encarecidamente utilizar no solo usuarios y entornos de producción para probar soluciones de balizas C2, sino también escenarios adversarios realistas, como pruebas de penetración o recompensas por errores. Al ajustar los importes de las recompensas y los requisitos para demostrar explícitamente la implantación y la ejecución satisfactoria de acciones posteriores a la explotación de kits de herramientas de frameworks C2 populares, podemos hacer que el «tráfico malicioso» sea real y medible. Esto podría ampliarse a cualquier actividad de balizas C2, incluido código personalizado para probar la resiliencia de la solución de detección, y el requisito de prueba debería incluir la demostración de actividad diaria satisfactoria de balizas y ejecución de comandos durante una semana sin ser detectadas.

Si se repite una prueba de penetración externa o un programa de recompensas por errores, las diferencias en las tasas de detección podrán medirse y serán útiles para evaluar la eficacia y el ROI.

Con un enfoque riguroso de las pruebas, no solo se medirá de forma integral su eficacia, sino que también podrán crearse objetivos y metas continuos en relación con una referencia actual o histórica. Y, desde luego, si se realizan las mismas pruebas y mediciones para varias soluciones, resulta trivial comparar su rendimiento y tomar decisiones de compra o implementación.

Consideraciones de diseño

La investigación y el diseño relacionados con estos conceptos y con el enfoque general se analizan con más detalle en: Sistemas y métodos de seguridad para detectar comando y control maleables (Mulugeta).

Beneficios

Detección de anomalías de amenazas nuevas y desconocidas

Este enfoque mitiga eficazmente las amenazas desconocidas mediante modelos de aprendizaje automático entrenados con el comportamiento de las aplicaciones específico de los usuarios de una organización. La métrica granular de riesgo del usuario reduce significativamente los falsos positivos.

Por el contrario, los enfoques reactivos existentes dependen de identificar a una primera víctima o paciente cero —un sacrificio por el bien común—, seguido de análisis e investigaciones del proveedor que pueden tardar días o incluso meses antes de que este publique una nueva firma o regla para bloquear la nueva amenaza para aquellos clientes que aún no han sido atacados. Por diseño, este enfoque es ineficaz para bloquear amenazas maleables nuevas y emergentes.

Un enfoque de detección de anomalías que utilice modelos específicos y calibrados de aprendizaje automático puede detectar de forma exclusiva comportamientos sospechosos sin necesidad de un ciclo de análisis, publicación y actualización. El enfoque mantiene su solidez incluso a medida que evolucionan las tácticas de las amenazas.

Análisis integral de señales

La detección de anomalías en un conjunto integral de señales, como tiempo, volumen, comunicaciones TCP/IP, huellas digitales SSL/TLS y cargas útiles de protocolos de aplicación, puede detectar eficazmente comunicaciones C2 maleables y sofisticadas.

Detección de kits de herramientas de adversarios

Este enfoque puede detectar eficazmente el uso de las herramientas de frameworks C2 y los frameworks C2 más recientes, así como actividad de balizas C2 nueva y sospechosa, mediante la detección de anomalías basada en una amplia variedad de señales de red específicas de los usuarios del entorno y su comparación con el tráfico válido y benigno del entorno.

Eficacia de la detección

Los enfoques actuales —firmas IPS y bloqueos de IP/dominios/URL— no detectan una gran proporción de las comunicaciones C2 avanzadas del malware más reciente —entre el 40 % y el 80 %, según los escenarios de prueba—.

Mediante un nuevo enfoque con un modelo calibrado de aprendizaje automático, detección de anomalías de un amplio conjunto de señales y una métrica de riesgo granular, puede detectarse más del 85-95 % de estos ataques que actualmente logran evadirse.

Esto produce una tasa general de detección de verdaderos positivos superior al 95 %, con un nivel mínimo de falsos positivos.

Conclusión

Los kits de herramientas de frameworks C2 han proporcionado a los atacantes técnicas sofisticadas para evadir la detección de comando y control (C2). En particular, kits de herramientas ampliamente disponibles como Cobalt Strike, Brute Ratel y Mythic son accesibles como código abierto o como código comercial pirateado o robado.

Los enfoques estáticos tradicionales, que dependen en gran medida de firmas e indicadores estáticos, como listas de bloqueo de IP/URL, presentan graves limitaciones y estas amenazas cambiantes pueden eludirlos con facilidad.

Para abordar este desafío, se necesita un enfoque fundamentalmente diferente que utilice modelos de aprendizaje automático. Estos modelos incorporan un conjunto integral de señales de red y se entrenan específicamente tanto a nivel de usuario como de organización. Además, utilizan métricas detalladas de riesgo del usuario para reducir los falsos positivos y medir la zona gris que suele estar asociada a las amenazas.

Los usuarios deben evaluar cuidadosamente la eficacia de los enfoques de aprendizaje automático. Es esencial realizar pruebas rigurosas con un entorno de pruebas sólido que incluya tráfico malicioso y benigno para determinar su eficacia al detectar y mitigar estas nuevas amenazas.

Referencias

1. «Cobalt Strike: una operación internacional de las fuerzas del orden aborda los usos ilegales de la “navaja suiza” de las herramientas de pruebas de penetración». The Record from Recorded Future News, 3 de julio de 2024, https://therecord.media/cobalt-strike-law-enforcement-takedown. Consultado el 23 de agosto de 2024.
2. Gill, Andy. «Comprender los perfiles de Cobalt Strike: actualizado para Cobalt Strike 4.6». ZSEC Blog, 13 de abril de 2022, https://blog.zsec.uk/cobalt-strike-profiles/. Consultado el 23 de agosto de 2024.
3. Larson, Selena, y Daniel Blackford. «Cobalt Strike: herramienta APT favorita para el crimeware». Proofpoint, 29 de junio de 2021, https://www.proofpoint.com/us/blog/threat-insight/cobalt-strike-favorite-tool-apt-crimeware.
4. Mudge, Raphael. «Malleable C2 Profiles: gmail». Malleable-C2-Profiles normal gmail.profile, rsmudge, 28 de febrero de 2018, https://github.com/rsmudge/Malleable-C2-Profiles/blob/master/normal/gmail.profile.
5. Mulugeta, Dagmawi. «Sistemas y métodos de seguridad para detectar comando y control maleables». Free Patents Online, 20 de agosto de 2024, https://www.freepatentsonline.com/12069081.html.
6. Rahman, Alyssa. «Cobalt Strike | Definición de los componentes de Cobalt Strike y BEACON». Google Cloud, 10 de diciembre de 2021, https://cloud.google.com/blog/topics/threat-intelligence/defining-cobalt-strike-components/.
7. Snort. «SID 1:25050». Regla de Snort: conexión saliente de la variante MALWARE-CNC Win.Trojan.Zeus, https://www.snort.org/rule_docs/1-25050.
8. «El ataque a la cadena de suministro de SolarWinds utiliza la puerta trasera SUNBURST». Google Cloud, 13 de diciembre de 2020, https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor/.