Seguimiento avanzado de infraestructuras persistentes

Introducción

La mayoría de las actividades cibernéticas de los actores maliciosos requieren infraestructuras como servidores en Internet. Cuanto mayor es la campaña, más servidores se necesitan. Algunos grupos APT utilizaron varios miles de servidores de Mando y Control (C2) a lo largo de los años. Para la Inteligencia de Amenazas esto ofrece oportunidades únicas para rastrear tales actividades, porque a menudo los servidores C2 necesitan ser configurados de una manera específica y muchos actores han desarrollado sus hábitos idiosincrásicos de configuración de servidores. Una ventaja esencial sobre las investigaciones puramente forenses de incidentes es que el análisis de la infraestructura puede a veces identificar servidores C2 incluso antes de que se hayan utilizado en un ataque. Los motores de búsqueda de Internet como Censys son cruciales en este tipo de análisis. Recopilan información sobre hosts en Internet y sus configuraciones, ahorrando así a los investigadores el esfuerzo de escanear ellos mismos grandes espacios de direcciones.

Este artículo explica por qué es posible el rastreo de infraestructuras, qué atributos pueden ser importantes para echar un vistazo, muestra dos ejemplos recientes así como un proceso de ejemplo y da algunas pistas para empezar con el análisis de infraestructuras. Ten en cuenta que este artículo sólo habla de métodos pasivos para encontrar y agrupar infraestructuras maliciosas. Los métodos activos, como escanear tú mismo en busca de hosts, introducen más posibilidades, como imitar el handshake de un malware para identificar servidores C2 o víctimas con gran confianza. Además, este artículo sólo cubre la infraestructura basada en HTTP(S).

Fondo

Existen múltiples razones por las que se pueden encontrar infraestructuras maliciosas a través de Censys y servicios similares, y la mayoría de ellas se deben a errores en la seguridad de las operaciones (OPSEC). Aunque el siguiente párrafo seguramente no es exhaustivo, menciona algunos puntos clave por los que se producen dichos errores. Algunos actores pueden no ser conscientes de sus errores, pero otros pueden incluso ser conscientes del impacto en la OPSEC. Sin embargo, como tienen que sacrificar OPSEC por eficacia, a veces parecen decidir correr el riesgo.

1. El ritmo de los ciberataques ha aumentado enormemente Mientras que hace unos años los ciberataques eran la excepción, hoy son algo habitual. Debido al creciente número de objetivos, también aumentó la demanda de infraestructura. Para ahorrar un tiempo valioso, se utiliza algún tipo de automatización de la infraestructura para instalar y configurar servidores. Algunos actores optan por la vía más sencilla, desplegando imágenes preparadas, mientras que otros parecen configurar los servidores C2 mediante algunos scripts.

2. Mientras que algunos operadores experimentados (que llevan a cabo los ataques reales) pueden conocer las trampas OPSEC, en algunos grupos la infraestructura es creada por otro equipo que desconoce las posibilidades técnicas para identificar sus servidores.

3. A menudo es necesario engañar a las víctimas para que piensen que la infraestructura utilizada es legítima. Esto puede ser para ocultarse en el tráfico general de la red o para que la víctima reconozca direcciones sospechosas en la barra de URL, por ejemplo, en campañas de phishing.

4. En general, muchos actores no parecen seguir un diseño OPSEC. En lugar de pensar de antemano cómo los analistas de Inteligencia de Amenazas podrían identificar sus servidores, parecen vivir por ensayo y error o, al menos, sólo mejoran su OPSEC después de haber sido descubiertos en un informe de Inteligencia de Amenazas.¹. Como no queremos dar consejos de OPSEC para amenazas recientes, esta entrada de blog sólo cubre infraestructuras ya conocidas sobre las que ya se ha escrito en blogs.

Criterios para la agrupación de hosts

Existen múltiples criterios que pueden utilizarse para encontrar y agrupar infraestructuras. Algunos de ellos se enumeran aquí incluyendo los atributos respectivos que pueden utilizarse para buscar este host - como antes, esta lista no es exhaustiva. En general, hay tres grupos de criterios: encabezado de respuesta, contenido de respuesta y certificados. Dado que algunos actores de amenazas utilizan software personalizado del lado del servidor o versiones específicas de librerías, las respuestas a las peticiones HTTP suelen incluir una combinación característica de cabeceras. Así, los hosts pueden agruparse por la ausencia de un encabezado o por cadenas de encabezados específicas. Más adelante veremos un ejemplo de agrupación de hosts por cabeceras de respuesta. Con las consultas a Censys , las cabeceras pueden filtrarse mediante

<port>.http(s).get.headers.

Además, el contenido de la respuesta puede contener artefactos característicos. Algunos servidores de Comando y Control intentan imitar a un servidor web específico y, por lo tanto, entregan algún tipo de página predeterminada como página de índice o de error. Un ejemplo bien conocido es el uso de la página web predeterminada de Microsoft Internet Information Service (IIS) como página de índice para Powershell Empire². Los servicios de exploración suelen acceder sólo a la página índice o reciben una página de error como respuesta si el servidor C2 espera que se acceda a una determinada ruta. En estos casos, a menudo se puede utilizar el valor hash del cuerpo de la respuesta para agrupar hosts.

Otros actores utilizan a veces una configuración por defecto, en la que primero se clona completamente otro sitio web y luego se modifica. En estos casos puede ser útil buscar recursos específicos en el sitio web, como favicons utilizados, fragmentos de javascript incrustados (y la red publicitaria o IDs de seguimiento que puedan estar ahí) o archivos css incluidos. El último grupo de criterios son los certificados. Filtrar por número de serie, huella digital o nombre distinguido (véase el ejemplo 2 a continuación) puede ser una forma útil de agrupar hosts por sus certificados. Los actores pueden tender a utilizar una autoridad de certificación específica a lo largo de términos bastante únicos en el nombre común o incluso reutilizar certificados autofirmados a lo largo de toda su infraestructura.
Ambos, el contenido de la respuesta y los certificados, a veces se crean de forma que parezcan legítimos a las víctimas potenciales y, por lo tanto, incluyen elementos específicos.

Ejemplo 1 - Seguimiento basado en cabeceras HTTP

Cobalt Strike (CS) es un kit de herramientas de pruebas de penetración comercial ampliamente conocido que no sólo utilizan los equipos rojos. A lo largo del tiempo, muchos actores de amenazas diferentes lo han utilizado (y probablemente lo sigan utilizando) como primera etapa. La respuesta típica del servidor para Cobalt Strike puede caracterizarse de la siguiente manera:

• HTTP 404 No encontrado
• Content-Type: text/plain
• Contenido-Longitud: 0
• Fecha Encabezado
• Sin encabezado de servidor

Con estos criterios, podemos encontrar fácilmente servidores utilizando la siguiente consulta Censys :

80.http.get.status_line: "404 No encontrado" 
AND 80.http.get.headers.content_type: "text/plain" 
AND 80.http.get.headers.content_length: 0 
NOT _exists_:80.http.get.headers.server

_{Censys consulta de instancias de Cobalt Strike en el puerto 80}

Tenga en cuenta que no todos los resultados que vea son necesariamente instancias de Cobalt Strike, pero es un buen indicador. Además, como ya habrá adivinado, Cobalt Strike no se limita al puerto 80. Aparte del certificado TLS por defecto utilizado por la herramienta, puede encontrar otras instancias que utilicen TLS buscando adicionalmente autoridades de certificación populares o certificados autofirmados.

87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c

_{Censys utilizando el hash SHA256 de la huella digital predeterminada del certificado Cobalt Strike}

Existe una enorme cantidad de infraestructura de Cobalt Strike disponible en línea, por lo que lo más probable es que necesite otro tipo de fuente de datos, como datos DNS pasivos, para poder agrupar correctamente las instancias encontradas.
Resultados de cabeceras típicas de Cobalt Strike en el puerto 80:

Ejemplo 2 - Seguimiento basado en datos de certificados

En julio de 2020, NCSC UK, la autoridad nacional de ciberseguridad del Reino Unido, publicó un aviso sobre la APT29 dirigida a la investigación de la vacuna^COVID-193. El grupo también conocido como "The Dukes" o "Cozy Bear" utilizó vulnerabilidades de Citrix y VPN para atacar a varias empresas relacionadas con el desarrollo de vacunas. En estas campañas, el grupo utilizó dos familias de malware personalizadas, WellMess y WellMail. La infraestructura utilizada por los autores incluía certificados autofirmados muy específicos que facilitaban su rastreo, según informaron varias fuentes. PwC publicó recientemente un informe sobre el software del lado del servidor utilizado por los perpetradores^4.

Emisor: C=Tunis, O=IT, CN=* Asunto: C=Tunis, O=IT

Utilizando los nombres distinguidos de los certificados que figuran en la tabla 1, podemos crear una consulta para encontrar infraestructuras recientes:

443.https.tls.certificate.parsed.subject_dn: "C=Tunis, O=IT" AND 443.https.tls.certificate.parsed.issuer_dn: "C=Tunis, O=IT, CN=*"

Con la consulta de la tabla 2, se pueden encontrar 20 hosts utilizando los detalles del certificado.

Ejemplo de proceso

Cuando empecé con el seguimiento de infraestructuras, escribí una sencilla herramienta en python que consultaba distintas fuentes de datos en función de una regla determinada.

La regla (véase la figura 3) incluía la consulta necesaria y el script enviaba los resultados a otros sistemas. Como al principio sólo se utilizaban como notificaciones, llamé a la sección "alertas". Una vez configurados los cronjobs para ejecutar los scripts, ya está todo listo, sin necesidad de una enorme pila de software. En caso de que necesite la respuesta en bruto de las fuentes consultadas, almaceno todas las respuestas de la API en un archivo JSON. De esta manera puedo crear una estructura de datos completamente nueva si es necesario,
sin perder datos.

Consejos para principiantes

Aunque cada uno desarrollará sus propios procedimientos para el seguimiento de la infraestructura, quiero dar algunos consejos para los que empiezan, esperando que los siguientes les resulten útiles.

1. Combinar diferentes recursos.

Para obtener la imagen más precisa de la infraestructura utilizada por los adversarios, resulta muy útil combinar varios servicios que ofrecen distintos tipos de información. Además de los datos de host (por ejemplo, de Censys o Shodan), el pivoteo a través de la infraestructura puede mejorarse mediante datos DNS pasivos (por ejemplo, RiskIQ o Domaintools) y datos de certificados (por ejemplo, Censys o crt.sh). Si estás consumiendo datos de diferentes proveedores, es posible que desees utilizar un modelo de datos común⁵.

2. Almacene los resultados de forma flexible y que permita realizar búsquedas.

Después de empezar con el seguimiento de la infraestructura, con el tiempo vas a tener un montón de datos en tus manos y definitivamente quieres ser capaz de buscar a través de esos datos muy rápidamente. Tener tus datos en un clúster elasticsearch o un almacenamiento de datos similar te ahorrará mucho tiempo. Cuando configures tu conjunto de herramientas, ten en cuenta que puede que quieras buscar en tus datos con expresiones regulares.

3. Conserve los resultados más antiguos.

No borre los resultados de búsquedas anteriores. Mantener y actualizar la información de los hosts permite descubrir patrones interesantes. Además, es muy útil disponer de las fechas de primera y última visita de los servidores C2.

4. Documente sus consultas.

El número cada vez mayor de consultas debe documentarse de alguna manera, de lo contrario, se perderá la visión de conjunto. Un buen punto de partida es crear un esquema2 que incluya metadatos como una descripción.

Conclusión

Los actores de amenazas están sujetos a limitaciones similares a las de los defensores de la red: tiempo, dinero, habilidades y pereza. Esto les lleva a cometer errores o a adoptar ciertos hábitos a la hora de configurar su infraestructura. Con algo de creatividad y herramientas, los defensores de la red pueden explotar esos errores y hábitos para rastrear la infraestructura maliciosa. La recompensa serán los IoC y el conocimiento de las actividades de los atacantes. Censys y otras herramientas proporcionan a los analistas una gran ventaja. La magia está en las consultas que se escriben. Espero que las técnicas y consejos anteriores te hayan resultado útiles. Estaré encantado de escuchar tus experiencias, puedes contactar conmigo a través de Twitter⁶ o Keybase⁷.

1. _{Compárese p. 75 Steffens, Timo (2020). Atribución de amenazas persistentes avanzadas.
   https:// doi.org/10.1007/978-3-662-61313-9}
2. _{Compara https://github.com/BCSECURITY/Empire/blob/master/lib/listeners/http.py#L262}
3. _{NCSC-UK (2020). APT29 apunta al desarrollo de la vacuna COVID-19.
   https://www.ncsc.gov.uk/files/Advisory-APT29-targets-COVID-19-vaccinedevelopment.pdf (consultado el 21 de septiembre de 2020)}
4. _{PwC Reino Unido (2020). Malware WellMess: análisis de su servidor de mando y control (C2).
   server. https://www.pwc.co.uk/issues/cyber-security-services/insights/wellmessanalysis-command-control.html (consultado el 21 de septiembre de 2020)}
5. _{Modelo de datos OSINT común para el análisis de infraestructuras:
   https://github.com/3c7/common-osint-model (consultado el 21 de septiembre de 2020)}
6. _{https:// twitter.com/0x3c7}
7. _{https://keybase.io/nkuhnert}