La búsqueda de amenazas o TH es una búsqueda proactiva de rastros de piratería o el funcionamiento de malware que no son detectados por medios de protección estándar. Hoy hablaremos sobre cómo funciona este proceso, qué herramientas se pueden usar para buscar amenazas y qué tener en cuenta al formular y probar hipótesis.
¿Qué es la caza de amenazas y por qué es necesaria?
En el proceso de búsqueda de amenazas, el analista no espera hasta que se activen los sensores de los sistemas de protección, sino que busca rastros de compromiso a propósito. Para hacer esto, desarrolla y verifica suposiciones sobre cómo los atacantes podrían haber penetrado en la red. Dichos controles deben ser consistentes y regulares.
La correcta implementación del proceso debe tener en cuenta los principios:
- Debe suponerse que el sistema ya ha sido comprometido. El objetivo principal es encontrar rastros de penetración.
- Para buscar, necesita una hipótesis sobre cómo se vio comprometido exactamente el sistema.
- La búsqueda debe llevarse a cabo de forma iterativa, es decir, después de probar la siguiente hipótesis, el analista presenta una nueva y continúa la búsqueda.
A menudo, las defensas automáticas tradicionales omiten ataques dirigidos sofisticados . La razón es que tales ataques a menudo se extienden a lo largo del tiempo, por lo que las herramientas de seguridad no pueden correlacionar las dos fases de un ataque. Al mismo tiempo, los atacantes reflexionan detenidamente sobre los vectores de penetración y desarrollan escenarios para acciones en la infraestructura. Esto les permite no realizar acciones de desenmascaramiento y pasar su actividad como legítima. Los atacantes mejoran constantemente sus conocimientos, compran o desarrollan nuevas herramientas.
Los problemas de identificación de ataques dirigidos son especialmente relevantes para organizaciones que fueron pirateadas previamente. De acuerdo con el informeFireEye M-Trends, el 64% de las organizaciones anteriormente comprometidas fueron atacadas nuevamente. Resulta que más de la mitad de las empresas pirateadas aún están en riesgo. Esto significa que es necesario aplicar medidas para la detección temprana de los hechos de compromiso; esto se puede lograr con la ayuda de TH.
La búsqueda de amenazas ayuda a los especialistas en seguridad de la información a reducir el tiempo para detectar una infracción, así como a actualizar el conocimiento sobre la infraestructura protegida. TH también es útil cuando se usa la inteligencia de amenazas (TI), especialmente cuando se usan indicadores de TI al hacer una hipótesis.
Cómo formar hipótesis para probar
Dado que al realizar TH, a priori se supone que el atacante ya ha penetrado en la infraestructura, lo primero que debe hacer es localizar la ubicación de la búsqueda de rastros de piratería. Se puede determinar presentando una hipótesis sobre cómo ocurrió la penetración y qué confirmación de esto se puede encontrar en la infraestructura. Habiendo formulado una hipótesis, el analista verifica la verdad de su suposición. Si la hipótesis no se confirma, el experto procede a desarrollar y probar una nueva. Si, como resultado de probar la hipótesis, se encuentran rastros de piratería o se establece la presencia de malware, comienza una investigación.
Figura 2. Esquema de la caza de amenazas
La idea de una hipótesis puede nacer de la experiencia personal del analista, pero existen otras fuentes para su construcción, por ejemplo:
- threat intelligence (TI-). , : X, MD5- Y.
- , (TTPs). TTPs MITRE ATT&CK. : .
- . . , asset management . .
- , .
threat hunting
Después de formular una hipótesis, es necesario identificar las fuentes de datos que pueden contener información para probarla. A menudo, tales fuentes contienen demasiados datos, entre los cuales necesita encontrar información relevante. Por lo tanto, el proceso TH se reduce a investigar, filtrar y analizar una gran cantidad de datos sobre lo que está sucediendo en la infraestructura. Considere las fuentes en las que se puede encontrar información para probar la hipótesis de búsqueda:
Figura 3. Clasificación de las fuentes de información para realizar TH
La mayor cantidad de información relevante está contenida en los registros y el tráfico de red. Los productos de las clases SIEM (información de seguridad y gestión de eventos) y NTA (análisis de tráfico de red) ayudan a analizar la información de ellos. Las fuentes externas (como las fuentes de TI) también deben incluirse en el proceso de análisis.
Cómo funciona en la práctica
El objetivo principal de TH es detectar una brecha que no ha sido detectada por las herramientas de seguridad automatizadas.
Por ejemplo, considere probar dos hipótesis. En la práctica, mostraremos cómo los sistemas de análisis de tráfico y análisis de registro se complementan entre sí en el proceso de prueba de hipótesis.
Hipótesis No. 1: un atacante ingresó a la red a través de una estación de trabajo e intenta obtener control sobre otros nodos en la red, utilizando la ejecución de comandos WMI para avanzar.
Los atacantes obtuvieron las credenciales de un usuario root. Después de eso, intentan tomar el control de otros nodos en la red para llegar al host con datos valiosos. Uno de los métodos para iniciar programas en un sistema remoto es usar la tecnología de Instrumental de administración de Windows (WMI). Ella es responsable de la gestión centralizada y el monitoreo de las diversas partes de la infraestructura informática. Sin embargo, los creadores previeron la posibilidad de aplicar este enfoque a los componentes y recursos de no solo un único host, sino también una computadora remota. Para esto, se implementó la transmisión de comandos y respuestas a través del protocolo DCERPC.
Por lo tanto, para probar la hipótesis, debe examinar las consultas DCERPC. Vamos a mostrar cómo se puede hacer esto usando análisis de tráfico y un sistema SIEM. En la Fig. 4 muestra todas las interacciones de red DCERPC filtradas. Por ejemplo, hemos elegido el intervalo de tiempo de 06:58 a 12:58. Figura 4. Sesiones filtradas de DCERPC . 4 vemos dos tableros. A la izquierda están los nodos que iniciaron las conexiones DCERPC. A la derecha están los nodos a los que los clientes se han conectado. Como puede ver en la figura, todos los clientes en la red acceden solo al controlador de dominio. Esta es una actividad legítima, ya que los hosts unidos en un dominio de Active Directory usan el protocolo DCERPC para contactar a un controlador de dominio para la sincronización. Se consideraría sospechoso en el caso de dicha comunicación entre los hosts del usuario.
Dado que no se ha identificado nada sospechoso para el período de tiempo seleccionado, avanzando a lo largo de la línea de tiempo, seleccionamos las siguientes 4 horas. Ahora es un intervalo de 12:59 a 16:46. En él, notamos un cambio extraño en la lista de hosts de destino (ver Fig. 5). Figura 5. Después de cambiar el intervalo de tiempo, aparecieron dos nuevos nodos en la lista de servidores : en la lista de hosts de destino, hay dos nuevos nodos. Considere el que no tiene un nombre DNS (10.125.4.16). Figura 6. Refinamiento del filtro para averiguar quién se conectó a 10.125.4.16 Como puede ver en la fig. 6, el controlador de dominio 10.125.2.36 accede a él (ver Figura 4), lo que significa que esta interacción es legítima.
A continuación, debe analizar quién se conectó al segundo nodo nuevo, en la Fig. 5 es win-admin-01.ptlab.ru (10.125.3.10). Del nombre del nodo se deduce que esta es la computadora del administrador. Después de refinar el filtro, solo quedan dos nodos de origen de sesión. Figura 7. Refine el filtro para averiguar quién se conectó a win-admin-01 De manera similar al caso anterior, uno de los iniciadores fue un controlador de dominio. Estas sesiones no son sospechosas, ya que son comunes en un entorno de Active Directory. Sin embargo, el segundo nodo (w-user-01.ptlab.ru), a juzgar por el nombre, es la computadora del usuario; tales conexiones son anomalías. Si va a la pestaña Sesiones con este filtro, puede descargar el tráfico y ver los detalles en Wireshark. Figura 8. Descarga de sesiones relevantes
En el tráfico, puede ver una llamada a la interfaz IWbemServices, que indica el uso de una conexión WMI. Figura 9. Llamada a la interfaz IWbemServices (Wireshark) Además, las llamadas transmitidas están encriptadas, por lo que se desconocen los comandos específicos. Figura 10. El tráfico DCERPC está encriptado, por lo que el comando transmitido no es visible (Wireshark) Para confirmar finalmente la hipótesis de que dicha comunicación es ilegítima, debe verificar los registros del host. Puede ir al host y ver los registros del sistema localmente, pero es más conveniente usar un sistema SIEM. En la interfaz SIEM, introdujimos una condición en el filtro que dejaba solo los registros del nodo de destino al momento de establecer una conexión DCERPC, y vimos la siguiente imagen:
Figura 11. Registros del sistema win-admin-01 en el momento de establecer una conexión DCERPC
En los registros, vimos una coincidencia exacta con el tiempo de inicio de la primera sesión (ver Fig. 9), el iniciador de la conexión es el host w-user-01. Un análisis más detallado de los registros muestra que se conectaron bajo la cuenta PTLAB \ Admin y ejecutaron el comando (ver Fig. 12) para crear el usuario john con la contraseña contraseña !!!: net user john password !!! / add. Figura 12. Comando ejecutado durante la conexión
Descubrimos que desde el nodo 10.125.3.10 alguien que usa WMI en nombre de la cuenta PTLAB \ Admin agregó un nuevo usuario al host win-admin-01.ptlab.ru. Cuando se realiza TH real, el siguiente paso es averiguar si se trata de una actividad administrativa. Para hacerlo, debe ponerse en contacto con el propietario de la cuenta PTLAB \ Admin y averiguar si realizó las acciones descritas. Como el ejemplo considerado es sintético, asumiremos que esta actividad es ilegítima. Además, al realizar un TN real, en caso de revelar el uso ilegal de la cuenta, debe crear un incidente y realizar una investigación detallada.
Hipótesis No. 2: un atacante ha penetrado en la red y se encuentra en la etapa de exfiltración de datos, utilizando túneles de tráfico para generar datos.
Tráfico de túneles: organizar un canal de tal manera que los paquetes de un protocolo de red (posiblemente en una forma modificada) se transmitan dentro de los campos de otro protocolo de red. Un ejemplo común de tunelización es la construcción de tuberías cifradas como SSH. Los canales encriptados aseguran la confidencialidad de la información transmitida y son comunes en las redes corporativas modernas. Sin embargo, hay opciones exóticas como los túneles ICMP o DNS. Dichos túneles son utilizados por los ciberdelincuentes para disfrazar su actividad como legítima.
Comencemos por encontrar la forma más común de canalizar el tráfico a través del protocolo SSH. Para hacer esto, filtraremos todas las sesiones utilizando el protocolo SSH: Figura 13. Búsqueda de sesiones DNS en el tráfico
En la figura, puede ver que no hay tráfico SSH en la infraestructura, por lo que debe elegir el siguiente protocolo que podría usarse para hacer túneles. Dado que el tráfico DNS siempre está permitido en las redes corporativas, lo consideraremos a continuación.
Si filtra el tráfico por DNS, puede ver que uno de los nodos tiene una cantidad anormalmente grande de consultas DNS.
Figura 14. Widget con estadísticas de sesiones de clientes DNS
Después de filtrar las sesiones por fuente de solicitudes, aprendimos a dónde se envía esta cantidad anómala de tráfico y cómo se distribuye entre los nodos de destino. En la Fig. La Figura 15 muestra que parte del tráfico va al controlador de dominio, que actúa como el servidor DNS local. Sin embargo, una gran proporción de las solicitudes van a un host desconocido. En una red corporativa construida en Active Directory, las computadoras de los usuarios para la resolución de nombres DNS no deben usar un servidor DNS externo para evitar el corporativo. Si se detecta dicha actividad, debe averiguar qué se transmite en el tráfico y dónde se envían todas estas solicitudes. Figura 15. Búsqueda de tráfico para sesiones SSH
Si va a la pestaña "Sesiones", puede ver lo que se transmite en las solicitudes al servidor sospechoso. El tiempo entre solicitudes es bastante corto y hay muchas sesiones. Tales parámetros son poco comunes para el tráfico DNS legítimo.
Figura 16. Parámetros de tráfico DNS
Después de abrir cualquier tarjeta de sesión, vemos una descripción detallada de las solicitudes y respuestas. Las respuestas del servidor no contienen errores, pero los registros solicitados parecen muy sospechosos, ya que los hosts suelen tener nombres DNS más cortos y significativos. Figura 17. Solicitud de registro de DNS sospechosa El análisis de tráfico mostró que se está produciendo actividad sospechosa al enviar solicitudes de DNS en el host win-admin-01. Es hora de analizar los registros del nodo de red, la fuente de esta actividad. Para hacer esto, vaya a SIEM.
Necesitamos encontrar los registros del sistema win-admin-01 y ver qué sucedió alrededor de las 17:06. Puede ver que se estaba ejecutando un script sospechoso de PowerShell al mismo tiempo. Figura 18. Ejecución de PowerShell al mismo tiempo que se envían solicitudes sospechosas Los registros registran qué script se estaba ejecutando. Figura 19. Cómo corregir el nombre del script en ejecución en los registros El nombre del script ejecutado admin_script.ps1 sugiere legitimidad, pero los administradores generalmente dan el nombre a los scripts para una función específica, y aquí el nombre es general. Además, el script se encuentra en la carpeta de archivos temporales. Es poco probable que un script administrativo importante termine en una carpeta que se pueda vaciar en cualquier momento.
Entre los eventos descubiertos se encontraba la creación de una clase criptográfica inusual de la biblioteca Logos.Utility. Esta biblioteca es rara y ya no es compatible con el desarrollador, por lo que crear sus clases es inusual. Intentemos encontrar proyectos que lo usen. Figura 20. Creación de una clase criptográfica personalizada Si usa la búsqueda, puede encontrar una utilidad que organice un túnel DNS y use esta clase usando el segundo enlace. Figura 21. Búsqueda de información sobre un script por nombre de clase Para finalmente asegurarnos de que esta es la utilidad que necesitamos, busquemos signos adicionales en los registros. Entonces la evidencia salió a la luz. El primero es ejecutar la utilidad nslookup usando un script. Figura 22. Ejecución de la utilidad nslookup por el script
La utilidad nslookup.exr se usa durante el diagnóstico de red y rara vez es ejecutada por usuarios normales. El inicio es visible en los códigos fuente de la utilidad. Figura 23. Código para iniciar la utilidad nslookup (GitHub) La segunda prueba es una cadena bastante única para generar valores aleatorios. Figura 24. Generando valores aleatorios por el script Si usa la búsqueda en los códigos fuente, puede ver esta misma línea. Figura 25. Código para generar un valor aleatorio Se confirmó la hipótesis del túnel, pero la esencia de las acciones realizadas no quedó clara. Durante el análisis posterior de los registros, notamos dos lanzamientos de procesos. Figura 26. Búsqueda de documentos de oficina para mayor exfiltración
Las líneas de lanzamiento de los procesos encontrados indican la búsqueda de documentos para descargar. Por lo tanto, la hipótesis se confirmó por completo, los atacantes realmente usaron túneles de tráfico para descargar datos.
conclusiones
Como muestran los últimos informes de investigación , el tiempo promedio que los atacantes permanecen en la infraestructura sigue siendo largo. Por lo tanto, no espere las señales de las defensas automatizadas: actúe de manera proactiva. Estudie su infraestructura y métodos modernos de ataque, y utilice la investigación realizada por los equipos de TI ( FireEye , Cisco , PT Expert Security Center ).
No estoy pidiendo el abandono de las protecciones automatizadas. Sin embargo, no se debe suponer que la instalación y la configuración correcta de dicho sistema es el punto final. Este es solo el primer paso necesario. A continuación, debe supervisar el desarrollo y el funcionamiento del entorno de red controlado, mantener el dedo en el pulso.
Los siguientes consejos te ayudarán:
- . . , .
- . , .
- . , . . , TH , .
- Automatice las tareas de rutina para que tenga más tiempo para ser creativo y probar soluciones creativas.
- Simplifique el proceso de análisis de grandes cantidades de datos. Para hacer esto, es útil usar herramientas que ayudan al analista a ver lo que está sucediendo en la red y en los nodos de la red como una sola imagen. Estas herramientas incluyen una plataforma para el intercambio de indicadores de TI , un sistema de análisis de tráfico y un sistema SIEM .
Publicado por Anton Kutepov, PT Expert Security Center en Positive Technologies.
Todo el análisis se realizó en el sistema de análisis de tráfico PT Network Attack Discovery y el sistema de gestión de eventos de seguridad MaxPatrol SIEM.