La creación de consultas para la infraestructura de malware puede ser un paso valioso en el ciclo de vida de la seguridad. Lamentablemente, hay pocos recursos sobre cómo empezar y qué indicadores se pueden utilizar para crear consultas. Hoy pretendemos llenar este vacío mostrando métodos accesibles y de gran valor que pueden utilizarse para buscar infraestructuras de malware.
¿Qué es la creación de consultas para la infraestructura de malware?
La creación de consultas es el proceso de observar infraestructuras sospechosas o maliciosas conocidas y crear consultas para identificar el patrón de configuración que ha utilizado el creador de la infraestructura. Dado que los actores de amenazas suelen reutilizar la misma configuración o una similar en varios servidores desplegados, a menudo existe un patrón que puede utilizarse para identificar varios servidores a partir de un único indicador inicial.
Una consulta bien construida permite a un analista identificar servidores adicionales relacionados con la infraestructura del actor. A continuación, el analista puede bloquear, investigar o llevar a cabo de forma proactiva cualquier acción adicional necesaria para limitar el compromiso y recopilar información.
¿Por qué realizar consultas sobre la infraestructura de malware?
La creación de consultas en Malware Infrastructure puede ser un medio muy eficaz de obtener IOC para el bloqueo y la caza.
Los medios tradicionales para listar infraestructuras de malware implican obtener un gran conjunto de muestras únicas de malware y extraer IOC individuales de cada archivo.
Esto puede ser un proceso muy tedioso y técnico que requiere un ingeniero inverso dedicado a deconstruir una muestra, desarrollar y probar una regla de caza de Yara, adquirir nuevas muestras y, a continuación, desarrollar y aplicar un extractor de configuración para obtener COI individuales.
Esta capacidad de ingeniería inversa implica una cantidad significativa de conocimientos técnicos que la mayoría de los equipos subcontratan a fuentes de inteligencia sobre amenazas. La subcontratación de fuentes de inteligencia sobre amenazas puede ser eficaz y hay buenas fuentes de pago disponibles, pero a menudo son caras y pueden variar significativamente en calidad y puntualidad.
Ventajas de las consultas sobre infraestructuras de edificios
Al desarrollar sus propias consultas de infraestructura con fines de caza, puede establecer una lista mucho mayor de IOC de malware con un conjunto significativamente menor de muestras de malware, experiencia técnica y coste global. También puede aprovechar las consultas para ampliar las alertas de su propio entorno, lo que le permitirá establecer una lista de IOC relacionados con el malware conocido que afecta a su organización.
Utilizando las técnicas mostradas en este post, puede identificar potencialmente docenas de IOC e infraestructuras de malware actuales con una sola muestra o alerta disponible.
¿Cuáles son los indicadores que podemos utilizar?
Una única dirección IP maliciosa contiene una gran cantidad de información que puede utilizarse para identificar servidores adicionales. Esto se debe a patrones únicos relacionados con el software y la configuración desplegados por un actor.
Dado que los autores de las amenazas suelen reutilizar el mismo software y las mismas configuraciones en múltiples instancias de la infraestructura maliciosa, se puede utilizar un único patrón para identificar otros servidores.
Algunos de los indicadores más comunes que los actores de amenazas reutilizarán son:
- Información del certificado - Campos dentro de los certificados TLS y SSL. Los valores codificados se suelen reutilizar.
- Cabeceras de servidor - Los actores que despliegan software personalizado pueden olvidar cambiar las cabeceras por defecto que contienen indicadores.
- Datos en las respuestas HTTP - Software personalizado que contiene valores únicos en las respuestas HTTP
- Ubicación, ASN y proveedores de alojamiento - Los actores reutilizan los proveedores de alojamiento para la infraestructura. Servidores similares pueden alojarse en la misma ASN.
- JA3 Hashes - Los actores que despliegan configuraciones de software poco comunes pueden ser identificados mediante firmas JA3.
- Configuraciones de puertos - Los actores suelen dejar abiertos los mismos puertos en toda la infraestructura.
- Expresiones Regulares - Los actores pueden desplegar valores únicos con una estructura altamente similar que puede ser capturada con Expresiones Regulares.
Ahora que ya hemos cubierto los conceptos clave, vamos a sumergirnos en algunos ejemplos.
Infraestructura de caza con certificados TLS
Los actores de amenazas y los desarrolladores de malware utilizan certificados TLS para cifrar las comunicaciones y establecer conexiones entre un host objetivo y una infraestructura maliciosa.
Por muchas razones, los actores rara vez despliegan certificados únicos para cada muestra desplegada. Esto hace que los valores de un único certificado TLS estén presentes en muchos otros servidores, lo que introduce patrones sencillos que se pueden firmar y consultar.
Ejemplo 1: Caza de AsyncRAT con certificados TLS
La familia de malware de AsyncRAT contiene un certificado TLS hardcoded dejado por el desarrollador. Este certificado contiene el valor de nombre común de sujeto codificado de AsyncRAT Server.
Tomemos por ejemplo una dirección IP de 91.109.176[.]4. La consulta de esta IP en Censys Search confirma un valor de nombre común (CN) de asunto de AsyncRAT Server en el puerto 8808.
Ampliando la información del host y localizando el campo exacto donde se almacena el valor del Servidor AsyncRAT services.tls.certificates.leaf_data.subject_dn, podemos construir una consulta para localizar servidores adicionales.
En este caso, se puede utilizar el campo subject_dn o issuer_dn, ya que ambos contienen el mismo valor codificado.
Buscando AsyncRAT Server en cualquiera de estos campos, podemos localizar 110 servidores adicionales con el mismo valor de certificado.
Ejemplo 2: Caza de Cobalt Strike con certificados TLS
El infame conjunto de herramientas Cobalt Strike también puede rastrearse utilizando los valores del certificado TLS.
Esto se debe principalmente a un nombre común por defecto de la asignatura Mayor Huelga de Cobalto
Tomemos por ejemplo la dirección IP 23.98.137[.]196 con el siguiente certificado en el puerto 50050.
Hay varios valores codificados que se pueden utilizar, pero para simplificar utilizaremos el nombre común del emisor de Huelga importante de cobalto.
Podemos ampliar de nuevo la vista detallada del host para determinar el nombre exacto del campo. Services.tls.certificates.leaf_data.issuer.common_name.
La consulta de este valor devuelve 236 resultados. La probabilidad de que un software legítimo contenga "Major Cobalt Strike" es muy baja, por lo que es probable que se trate de todas las implantaciones activas de Cobalt Strike.
Infraestructura de caza con títulos de respuesta HTTP
Los desarrolladores de servidores de control de malware suelen dejar cadenas únicas e identificativas en los datos de las páginas web.
Lo más habitual es encontrarlos en los títulos HTML y en los cuerpos HTTP.
Es útil tener en cuenta que estos valores pueden cambiarse, pero muchos actores no hacen este esfuerzo y dejan intactas las cadenas identificativas.
Ejemplo 1: Marco mítico C2
El marco Mythic C2 es utilizado a menudo por los actores de amenazas y contiene un título HTML predeterminado de Mythic.
Mirando la IP 89.223.66[.]195, podemos confirmar la cadena Mythic presente en el título HTML.
Buscando la cadena Mythic dentro de services.http.response.html_title, podemos localizar un total de 75 servidores.
Muchos de estos servidores ya han sido marcados como servidores C2 por la plataforma Censys . (Puede localizar otros C2 con la consulta labels:C2).
Infraestructura de caza con banderas de servicio
Los actores de amenazas y los desarrolladores de malware suelen dejar cadenas identificativas dentro de los banners de servicios. El autor suele dejarlas intencionadamente para limitar el uso indebido del software.
Pueden identificarse, consultarse y rastrearse utilizando métodos similares a los de los Títulos HTML.
Tenga en cuenta que es posible que las pancartas de servicio no se muestren de forma predeterminada, y es posible que tenga que abrir la vista detallada del host para verlas.
Ejemplo 1: Marco Havoc C2
Tomemos como ejemplo el marco C2 Havoc. Havoc es un marco C2 de código abierto desarrollado por C5pider que ha sido aprovechado por los actores de amenazas debido a su implementación de alta calidad de técnicas ofensivas modernas.
Con la configuración por defecto , el Havoc Team Server contiene la cadena X-Havoc dentro del banner del servicio. El autor lo ha dejado intencionadamente para limitar el uso indebido del software.
La búsqueda de services.banner con la cadena X-Havoc devuelve un total de 71 resultados.
Una cadena como esta es específica y es poco probable que tenga falsos positivos. Por tanto, es muy probable que se trate de implantaciones activas de Havoc.
Ejemplo 2: Caza de DarkComet con banners de servicio
Un segundo ejemplo de caza con banners de servicios puede verse con el malware DarkComet.
Mirando la dirección IP 187.135.84[.]89, podemos observar un banner de servicio de aspecto único de BF7CAB464EFB en el puerto 2000
Podemos buscar services.banner con el valor BF7CAB464EFB para identificar un total de 25 servidores.
Resumen - Infraestructura de caza con banderas de servicio
Los actores de amenazas suelen trabajar con prisas y evitan cambiar las cadenas predeterminadas en el software personalizado o de código abierto. Cuando investigues un host, asegúrate de comprobar todos los banners de servicio en busca de cadenas únicas o interesantes.
Estas cadenas por defecto son grandes indicadores para la construcción de consultas y usted debe absolutamente utilizarlos para su ventaja.
Si quieres comprobarlo por ti mismo, aquí tienes una consulta preconstruida tanto para Havoc como para DarkComet.
Caza con localizaciones y proveedores ASN
Los actores de amenazas suelen reutilizar los mismos proveedores de alojamiento cuando despliegan múltiples servidores con fines maliciosos.
A menudo se hace para evitar retiradas e investigaciones. Otras veces se hace porque es más fácil conseguir proveedores de alojamiento en el país de origen del actor.
Independientemente de las razones, los actores suelen reutilizar proveedores y podemos utilizar esto en nuestro beneficio para localizar servidores maliciosos y afinar las consultas existentes sobre otros indicadores.
Ejemplo 1: Amadey Bot Servers
Veamos la dirección IP 185.215.113[.]68. Esta dirección IP tiene un cuerpo de respuesta HTTP relativamente único de ninguno.
Centrándose en la consulta de services.http.response.body="none"Tenemos un resultado inicial de 84 servidores. Muchos de estos servidores se encuentran en Estados Unidos y no parecen ser de naturaleza maliciosa.
Volviendo a los resultados iniciales de la página de host para 185.215.113[.]68, podemos ver que el servidor está alojado en Moscú con un número de sistema autónomo de 51381.
Podemos añadir este número como filtro adicional para afinar los resultados de nuestra consulta.
Al añadir autonomous_system.asn=51381 a nuestra búsqueda, hemos limitado nuestra búsqueda a sólo 4 resultados. La consulta de estos resultados en Virustotal muestra que todos están relacionados con el malware Amadey Bot.
Resumen - A la caza de ubicaciones y proveedores de alojamiento
Los actores de las amenazas suelen utilizar los mismos proveedores de alojamiento cuando despliegan infraestructuras. El proveedor de alojamiento no es necesariamente un indicador en sí mismo, pero puede combinarse con otros indicadores para producir una consulta muy eficaz.
Cuando investigue un COI y descubra que tiene demasiados resultados de búsqueda. Pruebe a añadir la ubicación física del servidor o el número ASN para afinar la búsqueda.
Puede experimentar con el ejemplo de Amadey utilizando esta consulta preconstruida.
Infraestructura de caza con directorios abiertos
Los actores de amenazas a menudo alojan el malware y el software de apoyo en directorios abiertos que están expuestos a la Internet pública. Estos directorios suelen desplegarse de forma que el malware pueda recuperar fácilmente archivos adicionales para facilitar su explotación.
Para localizar directorios abiertos, podemos buscar títulos comunes de directorios como Listado de directorios o Índice de.
Alternativamente, podemos buscar servidores preetiquetados con la etiqueta open-dir proporcionada por Censys.
Ejemplo 1: Búsqueda de directorios abiertos con nombres de archivo comunes
Sólo la búsqueda de directorios abiertos puede arrojar cientos de miles de resultados. Muchos de los cuales son benignos y no maliciosos.
Para identificar casos maliciosos, podemos combinar la búsqueda con un nombre de archivo específico relacionado con software sospechoso.
Tomemos por ejemplo nc.exe, que es un nombre de archivo común para la herramienta netcat.
Investigando una de las primeras direcciones devueltas de 123.57.56[.]129, podemos observar un directorio abierto que contiene nc.exe así como referencias a Hacktools y un script .bat con caracteres extranjeros. Esta información es suficiente para suponer que la IP es altamente sospechosa.
Con estos indicadores identificados, podemos intentar recuperar los archivos para realizar análisis adicionales y confirmar la malicia, o podemos utilizar los nuevos nombres de archivo para refinar la consulta e identificar servidores adicionales.
Por ejemplo, podemos aprovechar la cadena recién identificada de hacktools para crear una nueva consulta.
Podemos hacerlo con labels:open-dir y cuerpos de respuesta que contengan hacktools.
En este caso sólo se devuelve un único resultado, pero esto demuestra el concepto de utilizar los resultados iniciales para establecer nuevas consultas. Esta consulta podría volver a ejecutarse fácilmente en una fecha posterior para identificar nuevas instancias del servidor sospechoso.
Ejemplo 2: Abrir directorios que contienen Procdump.exe
Para seguir demostrando el concepto, podemos buscar directorios abiertos que contengan referencias a la herramienta de volcado de procesos procdump.exe.
Uno de los resultados es un servidor que aloja procdump.exe, beacon.exe y shell.exe.
Podemos utilizar estos resultados para identificar nuevas cadenas y pivotar para abrir directorios que contengan beacon.exe.
Esto identifica un nuevo servidor con IP 62.204.41[.]104. Este servidor contiene referencias a `beacon.exe` pero no al netcat o procdump inicial. Resaltando la utilidad de construir nuevas consultas basadas en los resultados iniciales.
Resumen - Cazar directorios abiertos
La búsqueda de directorios abiertos puede ser un medio útil para buscar servidores sospechosos. Esto es particularmente útil cuando se trata de malware Downloader que ha llamado a un servidor con un directorio abierto.
Al crear consultas, utilice la etiqueta open-dir predefinida y aproveche los nombres de archivo conocidos. A continuación, añade nuevos nombres de archivo y cadenas en función de los resultados.
Hemos incluido aquí algunas consultas preconstruidas para beacon.exe, procdump.exe y nc.exe.
Incorporación de expresiones regulares a las consultas de caza
Los actores de amenazas avanzadas suelen evitar el uso de valores codificados en varios servidores.
Cuando se despliegan valores únicos, a menudo se hace mediante scripts y programas automatizados. Esto significa que, aunque los valores sean únicos, la "estructura" de los valores se repite a menudo y puede firmarse utilizando expresiones regulares.
Veamos algunos ejemplos de valores únicos que pueden firmarse con expresiones regulares. Tenga en cuenta que la búsqueda mediante expresiones regulares es una función de pago de Censys Search.
Ejemplo 1: Detección de servidores Qakbot con expresiones regulares
Un gran ejemplo de valores únicos con la misma estructura es con Qakbot.
Qakbot utiliza un sistema automatizado para desplegar y refrescar valores únicos de certificados TLS a través de los servidores. Pero estos valores tienen una estructura similar que se puede consultar con expresiones regulares.
Podemos ver dos de estos certificados en las siguientes capturas de pantalla.
Observando los dos valores del certificado, podemos ver que son muy diferentes en sus valores. Sin embargo, siguen un patrón similar que puede detectarse con expresiones regulares.
Podemos verificarlo copiando los valores e introduciéndolos en Cyberchef. Esto nos permite crear un prototipo de expresión regular y confirmar que podemos hacer coincidir ambos valores.
Repitiendo este proceso tanto para el emisor y campos temáticos del certificado TLS, podemos desarrollar una consulta que capture un total de 64 servidores.
Para comprobar que los resultados coinciden con lo previsto, podemos generar un informe Censys sobre los resultados devueltos. Esto nos permite listar todos los valores de certificado devueltos en una lista fácil de leer.
A continuación se muestra un breve fragmento de los resultados, lo que confirma que la consulta funciona según lo previsto.
Ejemplo 2: Detección de servidores BianLian con expresiones regulares
El malware BianLian es otro ejemplo de valores de certificado TLS únicos que contienen una estructura y un formato idénticos.
A continuación podemos observar dos certificados. Tanto el asunto como el emisor contienen únicamente los campos "C", "O" y "OU". (Esto contrasta con un certificado "típico", que contendría también los campos "ST" y "L")
Cada valor contiene exactamente 16 caracteres sin espaciado ni uso de caracteres especiales.
Llevando los dos valores del emisor a Cyberchef, podemos crear un prototipo de expresión regular que capture los valores de ambos certificados.
Ahora podemos buscar en services.tls.certificate.parsed.issuer_dn con nuestra expresión regular. Esto devuelve un total de 24 servidores.
Podemos seguir adelante y generar otro informe de búsqueda en services.tls.certificate.parsed.issuer_dn para confirmar que los resultados coinciden con lo previsto.
Ejemplo 3: Servidores Viper con certificados TLS y expresiones regulares
Para mostrar un ejemplo más, podemos echar un vistazo a una IP de 139.155.90[.]81 que fue marcada como Viper Malware en ThreatFox.
Podemos ver la información del certificado TLS en Censys. Mostrando los campos de asunto y emisor que tienen exactamente 8 caracteres de longitud y sólo contienen letras minúsculas y números.
Al introducir uno de los valores en Cyberchef, podemos crear de nuevo un prototipo de expresión regular para que coincida con la estructura identificada.
A continuación, podemos buscar esta expresión regular en el campo services.tls.certificates.leaf_data.issuer_dn. Esto devuelve un total de 1593 resultados.
Al generar otro informe de búsqueda se comprueba que muchos de estos resultados contienen la misma estructura TLS que el servidor inicial.
Resumen - Infraestructura de caza con expresiones regulares
Habrá casos en los que los valores codificados no basten para cazar infraestructuras.
Muchas de estas situaciones pueden resolverse identificando la estructura de valores aparentemente únicos e incorporando expresiones regulares a las consultas.
Si no estás familiarizado con las expresiones regulares, hay un gran recurso gratuito en regexone que te ayudará a empezar.
¿Cómo puedo empezar?
Todas las consultas (excepto las expresiones regulares) pueden realizarse con una cuenta de la comunidad de búsqueda Censys . Puedes registrarte hoy mismo y empezar a cazar amenazas, recopilar información y crear listas de COI.
Para obtener los IOC iniciales, recomendamos utilizar repositorios públicos de IOC como ThreatFox y URLHaus y empezar la búsqueda desde ahí. También podemos recomendar el aprovechamiento de consultas pre-construidas como las compartidas por drb_ra y Michael Koczwara.
Conclusión
Ya hemos visto varios indicadores que pueden utilizarse para identificar infraestructuras maliciosas. Puedes y debes utilizarlos todos a tu favor cuando investigues una dirección IP o realices una caza de amenazas.
Los actores de amenazas varían en calidad y sofisticación, algunos serán más difíciles de rastrear que otros. Pero en muchos casos se puede rastrear a los actores utilizando únicamente las técnicas que se muestran hoy aquí.
