Cobalt Strike es un software comercial de simulación de adversarios que se comercializa a los equipos rojos (Red Team), pero también es robado y utilizado activamente por una amplia gama de actores de amenaza, desde operadores de ransomware hasta amenazas persistentes avanzadas (APT) centradas en el espionaje. Muchos equipos de defensa de red han visto payloads de Cobalt Strike utilizadas en intrusiones, pero para aquellos que no han tenido la oportunidad de usar Cobalt Strike como operador, puede ser un desafío comprender los muchos componentes y características incluidos en este software.

En esta publicación de blog, recorreremos definiciones y conceptos importantes para ayudar a los defensores a comprender Cobalt Strike y, con suerte, identificar nuevas formas de buscar, responder y atribuir actores maliciosos que utilizan esta herramienta.

Este contenido se basa en una combinación de documentación oficial, investigación pública y la propia experiencia de Mandiant tanto por la ejecución de evaluaciones de equipo rojo, como por la respuesta a intrusiones en las que los actores de amenazas han utilizado Cobalt Strike. Debido a que Cobalt Strike se utiliza tanto para pruebas legítimas como para intrusiones, en esta publicación nos referiremos a todos los usuarios de Cobalt Strike, independientemente de la motivación, como "operadores" por simplicidad.

Si bien esta publicación de blog se centra en explicar los artefactos de Cobalt Strike y BEACON para ayudar al análisis de los defensores, también hemos incluido referencias a varios recursos para aprender más sobre Cobalt Strike y cómo detectar la actividad común de BEACON en varias etapas del ciclo de vida del ataque.

Componentes importantes

Cobalt Strike, BEACON, Team Server. ¡Oh no!

Es posible que haya escuchado los nombres Cobalt Strike, BEACON e incluso team server utilizados indistintamente, pero hay algunas distinciones importantes entre todos ellos.

Cobalt Strike es una aplicación de comando y control (C2) en sí misma. Esto tiene dos componentes principales: el team server y el cliente. Ambos están contenidos en el mismo ejecutable Java (archivo JAR) y la única diferencia se basa en los argumentos que utiliza un operador para ejecutarlo.

• Team server es la parte del servidor C2 de Cobalt Strike. Puede aceptar conexiones de cliente, devoluciones de llamada BEACON y solicitudes web generales. 
  • De forma predeterminada, acepta conexiones de cliente en el puerto TCP 50050.
  • Team Server solo permite su ejecución en sistemas Linux. 
• El cliente es la forma en que los operadores se conectan a un team server.
  • Los clientes pueden ejecutarse en el mismo sistema que un team server o conectarse de forma remota.
  • El cliente se puede ejecutar en sistemas Windows, macOS o Linux. 

BEACON es el nombre del payload de malware predeterminada de Cobalt Strike utilizada para crear una conexión con el team server. Las sesiones activas de devolución de llamada de un objetivo también se denominan "beacons". (Aquí es donde la familia de malware obtuvo su nombre). Hay dos tipos de BEACON:

• El Stager es una payload BEACON opcional. Los operadores pueden "organizar" su malware enviando una pequeña payload inicial de shellcode BEACON que sólo realiza algunas comprobaciones básicas y luego consulta el C2 configurado para la puerta trasera con todas las funciones.
• La puerta trasera completa se puede ejecutar a través de un stager de BEACON, por una familia de malware cargador ("loader") o ejecutando directamente la exportación DLL predeterminada "ReflectiveLoader". Esta puerta trasera se ejecuta en memoria y puede establecer una conexión con el team server a través de varios métodos.

Los loader no son BEACON. BEACON es la puerta trasera en sí misma y generalmente se ejecuta con algún otro cargador, ya sea la puerta trasera por etapas o la puerta trasera completa. Cobalt Strike viene con cargadores predeterminados, pero los operadores también pueden crear los suyos propios usando PowerShell, .NET, C ++, GoLang o realmente cualquier cosa capaz de ejecutar shellcode. 

Todo está conectado

Los oyentes (“listeners”) son el componente Cobalt Strike que las payload, como BEACON, utilizan para conectarse a un team server. Cobalt Strike admite varios protocolos y admite una amplia gama de modificaciones dentro de cada tipo de oyente. Algunos cambios en un oyente requieren un "reinicio del oyente" y la generación de una nueva payoad. Algunos cambios requieren un reinicio completo del team server. 

• HTTP / HTTPS es, con mucho, el tipo de oyente más común.
  • Si bien Cobalt Strike incluye un certificado TLS predeterminado, esto es bien conocido por los defensores y bloqueado por muchos productos empresariales ("firmado"). Por lo general, los operadores generarán certificados válidos, como con LetsEncrypt, para que sus dominios C2 se mezclen.
  • Gracias a los perfiles maleables (discutidos más adelante en la publicación), los operadores pueden configurar en gran medida cómo se verá el tráfico de red BEACON y pueden disfrazarse de conexiones HTTP legítimas.
  • Los operadores pueden proporcionar una lista de dominios/IP al configurar un oyente, y el team server aceptará conexiones BEACON de todos ellos (consulte "Redirectors"). Los operadores también pueden especificar valores de encabezado de host (consulte "Fronting de dominio").
• Los oyentes de DNS establecen sesiones en un team server mediante solicitudes DNS para dominios, para los que el team server tiene autoridad. Los agentes de escucha DNS admiten dos modos:
  • Híbrido (DNS + HTTP) es el predeterminado y utiliza DNS para un canal de baliza y HTTP para un canal de datos.
  • También se puede utilizar únicamente DNS para usarlo tanto para las balizas como para los canales de datos. Esto aprovecha las solicitudes regulares de registro A para evitar el uso de HTTPS y proporcionar un método de comunicación más sigiloso, aunque más lento.
• SMB es un oyente de estilo de enlace y se usa con mayor frecuencia para encadenar balizas. Los oyentes de enlace abren un puerto local en un sistema de destino y esperan una conexión entrante de un operador. Consulte "Conceptos importantes > balizas de encadenamiento" para obtener más información. 
• RAW TCP es un oyente de estilo de enlace (más nuevo) y también se puede utilizar para encadenar balizas. Consulte "Conceptos importantes > balizas de encadenamiento" para obtener más información.

Los dos últimos oyentes son menos comunes, pero proporcionan compatibilidad con otros tipos de payload.

• Los oyentes extranjeros permiten conexiones desde la puerta trasera Meterpreter de Metasploit para simplificar el paso de las sesiones entre el marco de Metasploit y el marco de Cobalt Strike.
• Los oyentes C2 externos proporcionan una especificación que los operadores pueden usar para conectarse a un team server con un oyente TCP inverso. Los oyentes inversos se conectan de regreso y establecen una conexión externa con un operador, en lugar de esperar una conexión entrante, como con los oyentes de tipo enlace ("bind").

Todo (casi) es personalizable

Los kits de arsenal están disponibles para su descarga, con una licencia válida, y para su uso en instalaciones con licencia (o crackeadas) solamente. Los kits de arsenal a veces se distribuyen con copias pirata de Cobalt Strike. La lista completa de estuches (a partir de octubre de 2021) es:

• Kit Applet/PowerApplet permite a los operadores modificar las payload java applet integradas de Cobalt Strike. Este kit fue el primero en ser añadido al arsenal y ya no es ampliamente utilizado.
• Kit de artefactos permite a los operadores modificar las plantillas de todos los ejecutables, DLL y shellcode de Cobalt Strike. Este kit se agregó en enero de 2014 y todavía se usa.
• Kit de elevación permite a los operadores integrar sus explotaciones de vulnerabilidades para la escalada de privilegios como comandos de Cobalt Strike. Este kit fue lanzado en diciembre de 2016. A diferencia de otros kits, este es público y, esencialmente, es solo un script de agresor que permite agilizar la carga de los propios scripts de PowerShell, binarios, etc. en una sesión BEACON (consulte "Scripts de agresor").
• Kit de Mimikatz permite a los operadores actualizar su versión de Mimikatz sin esperar una actualización de software de Cobalt Strike. Este kit se agregó en julio de 2021.
• Kit de recursos permite a los operadores modificar las plantillas de script que utiliza Cobalt Strike (principalmente como cargadores). Este kit se agregó en mayo de 2017 y todavía se usa.
• Kit de antifaz para dormir permite a los operadores modificar la ofuscación en memoria que BEACON utiliza para evitar métodos de detección como estos. Este kit se agregó en agosto de 2021. Para obtener un tutorial sobre cómo se puede usar este kit para afectar la detección de BEACON en memoria, consulte esta publicación de blog.
• El kit de cargadores reflectantes definidos por el usuario permite a los operadores personalizar la funcionalidad del cargador reflectante utilizada por BEACON. Este kit se agregó en agosto de 2021.

Perfil maleable es la parte final del kit de arsenal, y permite a los operadores modificar ampliamente cómo funciona su instalación de Cobalt Strike. Es la forma más común en que los operadores personalizan Cobalt Strike y, por lo tanto, ha sido ampliamente documentado.

• Los cambios en un perfil maleable requieren un reinicio del team server y, dependiendo del cambio, pueden requerir la regeneración de payload y la regeneración de las sesiones de baliza.
• Hay varios proyectos robustos de código abierto que generan perfiles aleatorios que pueden dificultar la detección. Aun así, los operadores a menudo reutilizan los perfiles (o solo los modifican ligeramente) lo que permite una detección más fácil y una posible agrupación de atribución.
• Al analizar muestras, consulte GitHub y otras fuentes públicas para ver si el perfil es de código abierto.

Los scripts agresores son macros que los operadores pueden escribir y cargar en su cliente para optimizar su flujo de trabajo. Estos se cargan y ejecutan dentro del contexto del cliente y no crean una nueva funcionalidad BEACON, sino que automatizan los comandos existentes. Están escritos en un lenguaje basado en Perl llamado "Sleep" que Raphael Mudge (el creador de Cobalt Strike) escribió. Para ver un ejemplo, consulte la sección "Vista de un operador". 

Los scripts de agresor sólo se cargan en el cliente local de un operador. No se  cargan en los clientes de otros operadores, el team server o las sesiones BEACON (hosts víctimas). La principal oportunidad de detección para estos scripts es revisarlos en busca de valores predeterminados estáticos que se puedan usar en reglas de detección o búsqueda.

Execute-Assembly es un comando BEACON que permite a los operadores ejecutar un programa .NET en memoria en un host de destino. BEACON ejecuta estos archivos generando un proceso temporal e inyectando el ensamblador en él. A diferencia de los scripts agresores, execute-assembly permite a los operadores ampliar la funcionalidad de BEACON. Los programas ensamblados que se ejecutan de esta manera seguirán siendo analizados por AMSI de Microsoft si se encuentra habilitado.

Los Beacon Object Files (BOFs) son una característica bastante reciente de Cobalt Strike que permite a los operadores ampliar la funcionalidad de post-explotación de BEACON. Los BOF son programas C compilados que se ejecutan en memoria en un host de destino. A diferencia de los scripts agresores, los BOF se cargan dentro de una sesión BEACON y pueden crear nuevas capacidades BEACON. Además, en comparación con otros comandos de post-explotación BEACON como execute-assembly, los BOF son relativamente sigilosos ya que se ejecutan dentro de una sesión BEACON y no requieren una creación de procesos o de su inyección.

Vista de un operador

Cuatro de los componentes mencionados anteriormente (el cliente, los scripts agresores, los BOF y los perfiles maleables) son las principales formas en que los operadores interactúan y personalizan su team server. Aquí se incluye un ejemplo de cada uno para mostrar estos componentes desde la perspectiva de un operador.

Un operador que acceda a un team server a través del cliente Cobalt Strike tendrá una vista como la siguiente. El panel superior muestra una lista de sesiones de baliza activas con metadatos básicos, incluidos el usuario actual, el ID de proceso, las direcciones IP internas y externas, y la última vez que el host se registró con el team server. El panel inferior incluye una pestaña para cada sesión donde los operadores pueden enviar comandos a los hosts víctimas y ver un registro de comandos y resultados anteriores. La interfaz de cliente también permite a los operadores crear payload, ejecutar complementos y generar informes.

Dentro del cliente, los operadores pueden importar scripts de agresor para personalizar sus comandos, opciones de menú e interfaz. Los scripts agresores varían en complejidad, desde agregar un nuevo acceso directo al menú hasta encadenar múltiples pasos del ataque. El siguiente es un extracto de credpocalypse.cna, un script de agresor que comprueba las sesiones de baliza activas de manera programada y ejecuta Mimikatz, un volcador de credenciales de código abierto, cuando un nuevo usuario inicia sesión.

Tenga en cuenta que esto no está agregando funcionalidad a Cobalt Strike. En este caso, el script utiliza la funcionalidad BEACON integrada para enumerar procesos y ejecutar Mimikatz, y utiliza las API de Cobalt Strike para ejecutarse de manera programada. Eso significa que las detecciones existentes para el módulo Mimikatz de BEACON también detectarán esto.

Beacon Object Files son programas C de un solo archivo, que se ejecutan dentro de una sesión BEACON. Se espera que los BOF sean pequeños y se ejecuten por un corto tiempo. Dado que las sesiones BEACON son de un solo subproceso, los BOF bloquearán cualquier otro comando BEACON mientras se ejecutan. A continuación, se muestra un ejemplo de la documentación de Cobalt Strike que utiliza la resolución de función dinámica para realizar una búsqueda en el dominio actual.

Finalmente, los perfiles maleables permiten a los operadores personalizar una amplia gama de configuraciones cuando lanzan por primera vez su team server. El fragmento que se desprende de un perfil público es un ejemplo de cómo un operador podría hacer que el tráfico BEACON parezca que está relacionado con Amazon. Las partes en azul (la línea que establece el uri y el bloque de cliente), definen cómo se comporta una payload de BEACON. Algunos de estos valores se pueden extraer de una muestra BEACON. Consulte "Interpretación de artefactos > solicitudes GET y POST" para obtener más información.

Conceptos importantes

Stagers

Anteriormente, mencioné que hay "dos tipos de BEACON", uno de ellos es un stager. Los operadores pueden tener stagers para múltiples tipos de oyentes (por ejemplo, un stager DNS, un stager SMB, un stager HTTPS). En esos casos, cuando se ejecuta el shellcode del stager, extraerá la payload final de BEACON sobre el protocolo relevante y lo ejecutará, estableciendo una conexión utilizando el método oyente definido.

Una nota importante para los defensores es que, de forma predeterminada, pueden descargar una payload de Cobalt Strike HTTP/S stager desde un team server, incluso si el operador no está utilizando payload por etapas en sus operaciones. Esto permitirá a los defensores 1. Confirmar que se está alojando un team server con un agente de escucha en ese puerto y 2. Extraer artefactos de configuración adicionales desde la payload. 

Esto funciona dado que Cobalt Strike fue diseñado para ser compatible con las payload Meterpreter de Metasploit. Metasploit (y por lo tanto Cobalt Strike) servirá para un stager HTTPS cuando se reciba una solicitud de URL válida. Una URL válida es cualquier valor alfanumérico de 4 caracteres con una checksum de 8 bits válida, calculada agregando los valores ASCII de los 4 caracteres. 

Los operadores pueden evitar que los defensores recuperen stagers estableciendo el valor host_stage en el perfil maleable con el valor de "falso". Más comúnmente, pueden usar proxies inversos para filtrar el tráfico no deseado, como las solicitudes de stager. Como característica de protección, Cobalt Strike ignorará las solicitudes web con agentes de usuario en la lista negra, como curl o wget. A partir de Cobalt Strike 4.4, los operadores también pueden incluir agentes de usuario en la lista blanca con la opción .http-config.allow_useragents definida en  el perfil maleable. Es importante recordar estas advertencias, ya que es posible que un team server no siempre funcione como esperan los analizadores que automatizan las solicitudes de stager.

Como nota de seguridad operativa, los operadores también pueden detectar cualquier solicitud web a un team server, ya que será visible para el operador en sus registros.  También podrán ver en la vista "Web Log" si se ha extraído un stager, junto con todos los detalles de la solicitud HTTP, como la IP de origen.

Prueba vs Licenciado vs Piratas

Cobalt Strike no se encuentra legítimamente disponible de forma gratuita. Las copias del team server/cliente no se pueden descargar como una copia de prueba o con licencia de Help Systems, la empresa propietaria de Cobalt Strike, a menos que el operador lo solicite y haya sido aprobado. Desafortunadamente, las pruebas y las copias pirata (incluidas la mayoría, si no todas, las funciones con licencia) se han filtrado y se siguen filtrando y distribuyendo públicamente para casi todas las versiones recientes.

• Las versiones de prueba de Cobalt Strike están fuertemente firmadas e incluyen muchos valores predeterminados obvios, destinados a ser capturados en un entorno de producción. (Por ejemplo, incorpora la cadena EICAR en todas las payload). Esto es para garantizar que el operador realmente lo esté usando como prueba y eventualmente pague si lo usa con fines profesionales.
• Las versiones con licencia de Cobalt Strike incluyen más funciones (por ejemplo, los kits de arsenal) y menos artefactos integrados (¡no más EICAR!). Una marca de agua relacionada con la licencia de Cobalt Strike asociada todavía está integrada en las payload y se puede extraer utilizando la mayoría de los analizadores de configuración BEACON. Hay muchas advertencias con ese valor, consulte "Interpretación de artefactos> Marcas de agua" más adelante en la publicación.
  • Las licencias se pueden robar; sin embargo, si se revoca una licencia, los operadores ya no podrán usarla para actualizar una instalación. Si los operadores conservan el "archivo de autorización" (consulte "Interpretación de artefactos > Marcas de agua"), la instalación existente seguirá funcionando hasta que caduque.
• Las versiones piratas de Cobalt Strike se distribuyen en varios foros. Por lo general, estos son el resultado de que alguien modifique un archivo JAR de prueba para omitir la verificación de licencia y reconstruir el JAR, o al crear un archivo de autorización con una ID de licencia falsa y distribuirlo con el JAR.

Puede ser difícil diferenciar las versiones piratas de Cobalt Strike de las versiones con licencia legítima. Si la marca de agua se definió estáticamente como parte del proceso de piratería, es posible vincularla a una copia compartida/distribuida. Algunas copias piratas de Cobalt Strike también contienen puertas traseras para proporcionar acceso de terceros a un team server. En estos casos, los analistas de malware pueden identificar copias ilegítimas a través de análisis estáticos.

Redirectores

En lugar de que las balizas se conecten directamente a un team server, los operadores a veces usan un dispositivo de redireccionamiento (o varios) que acepta conexiones y las reenvía al team server. Esto tiene varias ventajas para los operadores, incluida la posibilidad de:

• Iterar múltiples dominios para una sola conexión BEACON
• Reemplazar los redirectores detectados/bloqueados sin tener que reemplazar el team server subyacente
• Usar dominios con alta (mejor) reputación que ayuden a que el tráfico de BEACON se mezcle y evite la detección

Los operadores también pueden usar redirectores para filtrar el tráfico "sospechoso", como escáneres o herramientas de cacería, para proteger el team server; sin embargo, todavía suele haber formas sencillas de rastrear los redirectores y los team servers. Consulte la sección "Buscando team servers" para obtener más detalles. 

¿Qué pasa con la fachada de dominio?

A veces, los "redirectores" son tan simples como una instancia en la nube con un proxy nginx, pero otro método de redirector muy efectivo es la "fachada de dominio". La fachada de dominio es una técnica mediante la cual un operador puede ocultar el verdadero destino de una conexión de red redirigiéndola a través de la infraestructura de una red de entrega de contenido (CDN). La técnica se documentó por primera vez como un medio para eludir la censura de Internet y también ha sido utilizada por actores de amenazas, como APT 29, para disfrazar el tráfico C2.

Cuando se enmascara una solicitud HTTPS, la conexión se establece directamente con un dominio acreditado y alojado por la CDN. Este es el dominio de "fachada". La solicitud cifrada contendrá un identificador único, a menudo contenido en el encabezado HTTP "Host", que la CDN utiliza para enrutar la solicitud a un servidor controlado por el operador. Debido a que el tráfico de dominio se envía inicialmente a la CDN, utilizará el certificado SSL/TLS legítimo de la CDN cuando lo observe un defensor.

En esta situación, para bloquear el tráfico hacia el dominio del operador, un defensor necesitaría descifrar el tráfico para descubrir el verdadero destino dentro de una conexión HTTPS, pero esto no siempre es práctico. Además de consumir muchos recursos, es posible descifrar el tráfico de algunas CDN. Por ejemplo, algunas CDN aplican la fijación de certificados en sus certificados SSL/TLS para evitar la interceptación y el descifrado del tráfico mediante un certificado raíz de confianza proporcionado por la organización. 

Fachada de dominio vs Enmascaramiento

El tráfico enmascarado está diseñado para parecerse a un servicio legítimo, pero en realidad es una conexión directa al servidor de un operador, mientras que el tráfico de fachada de dominio se envía a un servicio legítimo (CDN) y se reenvía desde allí al operador.

Si el valor del encabezado Host y el dominio de destino son los mismos, esto es sólo una conexión HTTP normal y directa.

Si el encabezado Host y el dominio de destino son diferentes y el encabezado Host es

• Un dominio legítimo (por ejemplo, en el top 1M de Alexa), entonces es probable que se trate de enmascaramiento de dominio
• Un dominio utilizado para los puntos finales de CDN (por ejemplo, *.azureedge.net), entonces puede ser la fachada de dominio.

Hay varias guías públicas para probar si un dominio puede ser utilizado como fachada. Este repositorio incluye una lista pre compilada de dominios utilizados como fachada  por proveedores de CDN. Tenga en cuenta que las listas públicas pueden estar desactualizadas y es probable que la validación manual siga siendo necesaria.

Balizas de encadenamiento

Otra forma en que los operadores pueden establecer conexiones es encadenando balizas. Una vez que un operador tiene un solo sistema comprometido, por ejemplo, conectándose a un oyente HTTPS, puede pivotar internamente a otros sistemas.

La razón más común por la que un operador encadenará balizas es para eludir la segmentación de red y las restricciones establecidas. Si se dirigen a un servidor que no tiene acceso saliente a Internet, pueden realizar un proxy de su conexión a través de otra baliza con conectividad de red al sistema de destino y recibir la devolución de llamada en su team server. Si el operador pierde el acceso al sistema principal, también perderá el acceso a las balizas encadenadas. 

Los oyentes de SMB y las balizas desplegadas para SMB fueron el método original para encadenar. Cobalt Strike ahora también es compatible con un oyente TCP sin procesar. En entornos donde se detecta el stager SMB (cada vez más común para los productos endpoint Detection and Response), un operador puede utilizar una cadena TCP sin procesar a través del puerto 445. Esto les permitirá seguir aprovechando el hecho de que SMB rara vez se bloquea entre hosts internos, al mismo tiempo evitando el uso del oyente SMB, que es detectado por un  mayor número de firmas.

En la captura de pantalla de la sección "Vista de un operador", la IP externa de la primera sesión coincide con la IP interna de la sesión 2. Esto indica que se está encadenando a través de la segunda sesión. Un icono doble infinito/cadena junto a la IP también muestra que está encadenada. Si el sistema pierde la conexión con su host principal, ese icono de cadena se desconectará. 

La siguiente captura de pantalla muestra la vista "Gráfico dinámico" de un cliente de Cobalt Strike. En este gráfico, cada BEACON está representado por un icono de computadora. Las sesiones encadenadas se identifican mediante flechas a sus sesiones secundarias, y el icono del firewall representa una conexión externa al C2 del operador.

Si responde a una intrusión con payload BEACON utilizando stager SMB o TCP, busque otros hosts comprometidos que comiencen con las direcciones IP configuradas como "C2" para las payload entregadas por stager.

Cacería de team server

El equipo de prácticas avanzadas de Mandiant escanea regularmente Internet en busca de servicios de C2, incluidos los servidores del equipo Cobalt Strike. Si un operador no protege adecuadamente su team server, los analistas pueden identificar la infraestructura maliciosa sin conocimiento previo de si se está utilizando o dónde se está utilizando y proporcionar advertencia y cobertura avanzadas para los clientes. Para obtener más detalles sobre cómo identificamos los C2 como Cobalt Strike, consulte nuestra publicación de blog, "SCANdalous! (Detección externa mediante datos de escaneo de red y automatización)."

Interpretación de artefactos

Registros de Team Server y cliente

Los registros de Cobalt Strike son invaluables para comprender las actividades realizadas con un team server. Es posible que los defensores no tengan acceso con frecuencia a estos datos de registro, pero en el caso de que los registros estén disponibles, es útil comprender qué datos se pueden extraer de ellos.

Cobalt Strike almacena los registros en dos formatos principales: registros de balizas de texto plano completos y contenedores serializados de Java. Estos se almacenan en el directorio de trabajo del team server y se duplican en los directorios de trabajo del cliente, cuando un cliente está conectado a un team server. También se actualizan cuando cambian los elementos, como la captura de nuevas credenciales.

El directorio cobaltstrike/logs/ incluye una estructura de directorios del formato [fecha]/[ip interna del host balizado]/[beacon id].log. Cada archivo es un registro de texto sin formato de cada comando de baliza y la salida asociada. Esto refleja lo que un operador vería en la consola de balizas Cobalt Strike.

Las carpetas cobaltstrike/screenshots/ y cobaltstrike/downloads/ contienen respectivamente todas las capturas de pantalla o archivos que un operador ha descargado de balizas.

• Un directorio de trabajo  de operador/cliente individual sólo contendrá descargas que ese operador sincronizó con su sistema local, y estas podrían ser de múltiples conexiones al team server.
• Un directorio de trabajo de team server contendrá capturas de pantalla / descargas de cualquier operador en ese team server. 

Debajo de cada directorio cobaltstrike/logs/[fecha], también hay un archivo eventos.log y un  archivo web.log.

• Eventos.log es un espejo de la consola de "eventos" para el team server que, como mínimo, incluirá la fecha / hora en que cada operador se conecta al servidor y cada devolución de llamada de baliza inicial.
• Web.log mostrará un registro de cada solicitud web al team server, incluidas las solicitudes de payload preconfiguradas o archivos alojados en el team server.

Los archivos alojados en un team server y servidos a través de la función Web de Cobalt Strike se guardan en el directorio cobaltstrike/uploads/. Un directorio de trabajo individual de operador/cliente sólo contendrá archivos que ese operador cargó.

El directorio cobaltstrike/data incluye varios archivos .bin que son objetos Java serializados de diferentes modelos de datos utilizados por Cobalt Strike para rastrear su estado. Los datos de los registros de .bin serializados de Cobalt Strike se pueden extraer como CSV utilizando este script.

Para la mayoría de los analistas, sessions.bin, listeners.bin y las credentials.bin serán de mayor interés. Los registros .bin contienen los datos más concentrados y fáciles de analizar para identificar qué sistemas y usuarios se vieron comprometidos utilizando un team server determinado.

• Sessions.bin enumera todas las sesiones de balizas activas e históricas del team server junto con algunos metadatos básicos (por ejemplo, usuario, IP interna y externa, nombre de host, arquitectura).
• Listeners.bin detalla todos los  oyentes activos para el team server.
• Credentials.bin incluye cualquier credencial (texto sin cifrar, hash, etc.) que se volcó automáticamente con un módulo de credenciales incorporado (como Mimikatz) o se agregó manualmente (como después de descifrar una contraseña sin conexión).

Marcas de agua

Las marcas de agua de Cobalt Strike  son un valor único generado y vinculado a un archivo "CobaltStrike.auth" determinado. Este valor se incrusta como los últimos 4 bytes para todos los escenarios BEACON y en la configuración integrada para muestras BEACON de puerta trasera completa.

El archivo CobaltStrike.auth es un archivo de configuración utilizado por Cobalt Strike para determinar el ID de licencia y la caducidad. Cuando se ejecuta, Cobalt Strike verificará que la licencia sea válida y no haya expirado. El archivo CobaltStrike.auth es necesario para iniciar versiones modernas de Cobalt Strike, y se renueva al actualizar Cobalt Strike y al ingresar una licencia (ya sea por primera vez o como reentrada).

Una marca de agua coincidente significa que dos payload provienen de un team server que utiliza el mismo archivo CobaltStrike.auth. Esto no significa necesariamente que provenga del mismo operador. Alguien puede copiar todo el directorio de Cobalt Strike, incluido el archivo de autenticación, e instalarlo en otro servidor que luego tendría la misma marca de agua hasta que expirara la licencia.

Llaves públicas

Cobalt Strike utiliza 4 tipos diferentes de almacenes de llaves:

• Los oyentes pueden tener almacenes de llaves personalizadas que son especificadas en los perfiles maleables.
• La firma de código se puede configurar con almacenes de llaves personalizadas especificadas en los perfiles maleables.
• Las conexiones de cliente utilizan el archivo cobaltstrike.store para cifrar las comunicaciones de cliente.
• Las conexiones de baliza utilizan un almacén de llaves generado por el team server para cifrar los datos de BEACON y manejar otras características de seguridad.

Las llaves de BEACON y otras características de seguridad se discuten en la capacitación de Raphael Mudge "Advanced Threat Tactics: Infrastructure". Estas llaves solo se utilizan en la puerta trasera BEACON completa, no en los stagers. Según lo identificado por NCCGroup, estas llaves se almacenan en un archivo serializado denominado ".cobaltstrike.beacon_keys" en el directorio de trabajo del team server.

Una llave pública coincidente significa que dos payload provienen de uno o más team server que utilizan el mismo almacén de llaves .cobaltstrike.beacon_keys. Esto NO significa NECESARIAMENTE que provenga del mismo team server. Una vez más, alguien podría copiar todo el directorio de Cobalt Strike, incluido el almacén de llaves, como a veces se hace con las copias distribuidas o piratas.

Direcciones IP y URL de C2

Los analizadores BEACON también suelen extraer IP, dominios y URL C2 de las muestras. Algunos de estos pueden ser dominios legítimos, por ejemplo, si el operador está utilizando la fachada o enmascaramiento de dominio.

Hay algunos consejos para tener en cuenta al intentar agrupar la actividad BEACON con fines de atribución. Por ejemplo, los siguientes casos no significan necesariamente que esté buscando diferentes team server.

• Dos muestras se conectan a diferentes direcciones IP: esto podría ser el resultado de cambiar los redirectores o de la definición de varios dominios/hosts en un oyente.
• Dos muestras se refieren a diferentes rutas de URL: los operadores pueden especificar varias rutas de URL al definir perfiles maleables. Cada vez que un operador genera BEACON shellcode, Cobalt Strike seleccionará un valor aleatorio de esta lista. Si dos muestras tienen direcciones URL diferentes, es posible que sigan haciendo referencia al mismo servidor. 

Solicitudes GET y POST

Las configuraciones de BEACON pueden incluir encabezados HTTP personalizados, cookies, etc. para solicitudes HTTP GET y POST. Esos campos son representaciones de cómo un operador ha configurado su team server (utilizando el perfil maleable o los valores predeterminados) para construir y disfrazar el tráfico de red de BEACON. Esto no es un 1 a 1 directo para lo que estará en una payload. Los perfiles maleables aceptan varios valores para varios campos, y sólo uno de ellos puede aparecer en una payload determinada. Si las solicitudes GET o POST no coinciden exactamente, eso no es necesariamente una indicación de que es de un servidor diferente.

“Spawn to”

Cada payload de BEACON se configurará con dos procesos "spawn to", uno para tareas de 32 bits y otro para tareas de 64 bits. Estos valores son los que BEACON generará como procesos temporales para varios comandos posteriores a la explotación. BEACON lanza el proceso, lo inyecta (con cualquier técnica que el operador haya especificado), ejecuta la tarea posterior a la explotación y finaliza el proceso. Como ejemplo de los comandos a los que esto puede afectar, consulte esta guía: Consideraciones de Opsec para comandos de baliza. El nuevo proceso predeterminado es rundll32.exe, pero esto se puede modificar de dos maneras. 

• El perfil maleable permite a los operadores modificar los procesos spawn_to predeterminados (si se utiliza una versión con licencia o pirata). Cambiar estos valores requerirá reiniciar el team server y regenerar nuevas payload BEACON para usar los nuevos valores. 
• El cliente permite a los operadores modificar interactivamente los procesos spawn_to una vez que se establece una sesión BEACON. Estos se pueden cambiar tantas veces como se desee y no requieren un reinicio, aunque sólo afectará a la sesión BEACON actual.

Canalizaciones (Named Pipes)

Las canalizaciones con nombre son una característica de Windows que se usa para la comunicación entre procesos (IPC). Cobalt Strike utiliza la canalización con nombre de varias maneras:

• Payload: se utilizan para cargar la puerta trasera en la memoria y se pueden modificar a través del perfil maleable y/o el kit de artefactos.
• Trabajos posteriores a la explotación: se utilizan para una variedad de comandos de Cobalt Strike que necesitan generar e inyectar en un proceso.
• Uso de Stager - Se utiliza para con el stager y en el encadenamiento SSH/SMB BEACON

La publicación de Raphael Mudge, "Aprenda a colocar canalizaciones para todos sus proyectos ofensivos", tiene algunos detalles adicionales útiles sobre esta característica.

Sleeptime

El valor "sleeptime" en una configuración BEACON es el tiempo base utilizado para los intervalos de devolución de llamada. BEACON aleatorizará las devoluciones de llamada dentro de un rango determinado por el porcentaje de "fluctuación". Por ejemplo, un sleeptime de 10 segundos y una fluctuación del 50%, producirán devoluciones de llamada cada 5 a 15 segundos. Este valor no es constante para hacer que la detección de red sea más desafiante.

En perfil maleable, los operadores pueden especificar un sleeptime en milisegundos. Después de crear una sesión, los operadores pueden cambiar interactivamente los valores de sleeptime y fluctuación, pero ambos deben ser enteros y el sleeptime debe definirse en segundos.

Killdate

El valor "killdate" de una muestra de BEACON dicta si debe conectarse a un team server después de una fecha determinada. Esto es utilizado por los operadores del equipo rojo para garantizar que las payload no se ejecuten accidentalmente después de que se complete un trabajo. También puede ser utilizado por actores de amenaza para limitar la ejecución exitosa de sandbox y frustrar los esfuerzos de análisis retroactivo.

Este valor se define mediante un argumento de línea de comandos cuando se inicia el team server y no se puede modificar mediante comandos de perfil maleable o BEACON interactivos. De forma predeterminada, no se especifica ninguna fecha killdate.

Conclusión

Cobalt Strike sigue siendo el marco de elección C2 tanto para los especialistas de seguridad legítimos como para los actores de amenaza. Nuestra esperanza es que con una comprensión más profunda de las capacidades del marco y el uso común, los defensores estarán más equipados para encontrar nuevas formas de cazar, responder y realizar la atribución de actores maliciosos utilizando esta herramienta.

Referencias

Guías de detección

• Cobalt Strike, a Defender’s Guide (Informe DFIR)
• Full-Spectrum Cobalt Strike Detection (Recorded Future)
• Detecting Cobalt Strike with memory signatures (Elastic)

Recursos de análisis

• Open-source Cobalt Strike Parser (Sentinel One)
• Strike Back at Retired Cobalt Strike (NCCGroup)
• Understanding Cobalt Strike Profiles (ZeroSec)
• Deep Dive into Malleable C2 (Specter Ops)

Tutoriales y ejemplos

El creador de Cobalt Strike, Raphael Mudge, creó un curso de YouTube de nueve partes, Red Team Ops con Cobalt Strike, que muestra cómo usar Cobalt Strike. Vale la pena revisarlo para ver cómo se ve el producto y cómo usar las diversas características discutidas en esta publicación de blog (+ algunas características).

• Cobalt Strike Documentation (Raphael Mudge + Help Systems)
• Malleable Profile Examples (Raphael Mudge)
• Community Kit (Assorted) – A “central repository of extensions … to extend … Cobalt Strike”
• Sleeping with a Mask On (Adam Svoboda)
• Domain Fronting Lists (Vincent Yiu)

Agradecimientos

Un agradecimiento especial a Tyler Dean, Jae Young Kim, Matthew Dunwoody y Chris King por su experiencia técnica y revisión.