Tomada de la caricatura "Érase una vez un perro"
Entonces, las herramientas de monitoreo estándar no son suficientes. Varios factores contribuyen a esto:
- los indicadores de compromiso (hashes, direcciones IP y nombres de dominio) suelen ser de un solo uso, ya que cambiarlos es fácil para un atacante, especialmente en el caso de APT;
- los atacantes utilizan archivos ejecutables legítimos, herramientas estándar del sistema operativo, etc.;
- para navegar por la red, en la mayoría de los casos, no se utilizan exploits, sino credenciales legítimas robadas;
- en la práctica, a menudo se produce malware que no es detectado ni por antivirus ni por firmas de red;
- A medida que crece la infraestructura, se vuelve problemático actualizar las firmas y licencias a tiempo.
Incluso si el ataque se detecta con éxito, no tendrá suficiente información para responder de manera inequívoca a la pregunta: el incidente actual se ha agotado o se necesitan algunas otras medidas. Después de todo, muchos eventos simplemente no se rastrean: trabajar con el registro, crear archivos, cargar módulos en la memoria, línea de comando del proceso creado, etc.
El monitoreo de endpoints expande significativamente la capacidad de detectar y prevenir ataques: le permite pasar de detectar hashes, IP y dominios a detectar artefactos de host, herramientas y TTP (sí, la misma “pirámide del dolor”).
Algunos ejemplos de técnicas que se encuentran a menudo en la práctica y no se detectan sin la supervisión del host:
- Secuestro de DLL
- Viviendo de la tierra
- Usando Mimikatz
Se puede realizar un monitoreo adicional de endpoints utilizando herramientas integradas del sistema operativo (auditoría avanzada), utilidades gratuitas (como Sysmon) y soluciones comerciales (productos de clase EDR). Consideremos las ventajas y desventajas de estos enfoques utilizando ejemplos de detección de diversas variaciones de las técnicas anteriores.
Auditoría avanzada. Registro de eventos de Windows
Todos conocen la auditoría integrada. Como muestra la práctica, al incluir solo una colección de eventos de creación de procesos junto con la línea de comando, facilitará enormemente el proceso de monitoreo e investigación de incidentes (ley de Pareto en acción).
Con la configuración adecuada, cerramos algunas brechas en el enfoque estándar y vemos:
- hechos de iniciar procesos junto con la línea de comando;
- ejecutar scripts de PowerShell en forma decodificada (registro de bloques de script);
- parcialmente - trabajar con archivos y el registro;
- actividad relacionada con cuentas (crear / eliminar usuarios, etc.).
Tenemos la oportunidad de detectar nuevas técnicas:
- algunas opciones de secuestro de DLL para crear archivos con rutas específicas;
- usando LOLBin y Mimikatz por patrones en la línea de comando.
Sin embargo, un atacante todavía tiene la capacidad de evadir la detección. En el caso de LOLBin, esto puede ser copiar un archivo a otra carpeta con un nombre diferente y ofuscar la línea de comando. Y Mimikatz se puede recompilar con comandos y líneas modificados, lo que no permitirá la detección de su uso en la línea de comandos. Además, las opciones no estarán visibles cuando se coloque en la máquina un archivo binario legítimo sujeto a secuestro de DLL.
Código Mimikatz con líneas modificadas
Puede configurar la auditoría de Windows en cualquier sistema sin preinstalar software de terceros, pero también existen importantes inconvenientes:
1. Configuración incómoda y escasamente escalable.
Ejemplo: para monitorear una rama de registro específica, debe configurar por separado la ACL para ella. El mero hecho de tener que actuar, en la práctica, se traduce en problemas y retrasos, especialmente en el caso de grandes infraestructuras. Si esto se hace para expandir el monitoreo (por ejemplo, para detectar alguna forma de derivación de UAC), entonces el tiempo no es crítico. Pero si surge tal necesidad durante un incidente, complica el proceso de respuesta.
2. Falta de control.
Si los eventos dejan de registrarse o ingresar a los sistemas de monitoreo utilizados, lo más probable es que no sea posible comprender esto a tiempo, ya que no hay centralización.
3. Facilidad de oposición.
Incluso los atacantes poco cualificados saben cómo esconderse de las auditorías estándar. La única pregunta es qué tan efectiva e invisible lo harán.
Ejemplos de técnicas:
- Limpieza periódica de troncos. La probabilidad de una recuperación exitosa del evento depende de cuánto tiempo haya pasado desde la limpieza.
- Suspender los hilos del servicio de auditoría y luego realizar acciones maliciosas o eliminar eventos (por ejemplo, usando la herramienta github.com/QAX-A-Team/EventCleaner ).
- Ocultar eventos rompiendo la estructura del archivo .evtx correspondiente .
- Redirigir eventos temporalmente a un archivo separado. Escribimos sobre esta técnica en el artículo anterior .
4. Por sí solo, establecer una auditoría no brindará la oportunidad de organizar el monitoreo. Primero, deberá establecer una colección centralizada de eventos y luego utilizar herramientas adicionales, por ejemplo, SIEM, para analizarlos.
5. Bajo contenido informativo de los eventos. No hay posibilidad de obtener el hash del proceso iniciado, monitorear la carga de bibliotecas en la memoria del proceso, etc.
Similitudes entre Sysmon y EDR
Sysmon no es una solución EDR completa, ya que no brinda la capacidad de realizar acciones proactivas en el sistema. Pero el mecanismo para recopilar eventos es exactamente el mismo que en EDR comercial: funciona con dos tecnologías: devoluciones de llamada del kernel y ETW. No los describiremos en detalle, solo consideraremos cómo aparecen los eventos y quién es el iniciador de su creación.
• Devolución de llamada del kernel. Por ejemplo, PcreateProcessNotifyRoutine, PcreateThreadNotifyRoutine.
Dónde y cómo se llaman estas y otras devoluciones de llamada se puede ver en las funciones del kernel correspondientes. A continuación se muestra un ejemplo de devolución de llamada al crear un proceso:
El bucle de devolución de llamada en CreateProcessW → NtCreateUserProcess → PspInsertThread. Es decir, llama a estas devoluciones de llamada por el hilo del proceso padre que llamó a CreateProcess.
• Ventanas de seguimiento de eventos (ETW).
ETW funciona de manera similar para la ocurrencia de eventos. Veamos de nuevo el ejemplo de creación de procesos. Cuando se llama a CreateProcessW, el subproceso del proceso principal realiza las siguientes acciones (diagrama simplificado):
CreateProcessW (kernel32.dll)
NtCreateUserProcess (ntdll.dll, cambia al modo de kernel)
NtCreateUserProcess (ntoskrnl.exe, luego trabaja en modo de kernel)
PspInsertThread (las devoluciones de llamada también se llaman aquí ' i)
EtwTraceProcess
EtwpPsProvTraceProcess
EtwWrite
Por lo tanto, el hilo del proceso principal es el iniciador directo del evento ETW. La grabación de otros eventos, por ejemplo, eventos de red, funciona aproximadamente de la misma manera. A continuación se muestra un ejemplo de creación de eventos relacionados con la actividad de la red:
Función principal de EtwpNetProvTraceNetwork
De lo anterior se desprenden dos conclusiones:
- Tanto Sysmon como EDR usan solo capacidades nativas de Windows para recopilar eventos y garantizar un funcionamiento confiable.
- Un atacante podría usar técnicas de ofuscación que se aplicarían tanto a Sysmon como a EDR. Las devoluciones de llamada del kernel se pueden colocar en la memoria del kernel mediante un controlador firmado. Y conociendo el mecanismo de registro de eventos descrito, puede comprender por qué Sysmon y algunos EDR no pueden detectar ciertas técnicas de inyección en el proceso (por ejemplo, usando APC) o suplantación de PPID .
Sysmon
El uso de Sysmon le permite ampliar las capacidades de auditoría estándar. En este caso, los eventos se registran en un registro separado. Algunos ejemplos de información que no se encuentran en la auditoría de Windows, pero que están disponibles en Sysmon:
- información más detallada sobre los archivos ejecutables que se están lanzando (hash, nombre original, firma digital, etc.);
- carga de controladores y bibliotecas;
- cambiar el estado del servicio Sysmon;
- crear un hilo en otro proceso;
- acceso al proceso;
- hashes de archivos creados en flujos de datos alternativos;
- creación de tuberías.
Las ventajas de monitorear los procesos descritos anteriormente son obvias (existen muchas reglas y artículos sobre el tema de la detección de diversas técnicas en el dominio público). Además, es posible detectar nuevas variaciones de técnicas conocidas:
- la copia de LOLBin con un nombre diferente puede detectarse mediante la correspondencia de los campos OriginalFileName, Image y Hashes del evento de creación del proceso;
- puede detectar la carga de bibliotecas sin firmar, lo que en algunos casos le permite detectar el secuestro de DLL;
- Existe la posibilidad de detectar Mimikatz utilizando los métodos anteriores o mediante el evento ProcessAccess en el proceso lsass.exe.
La auditoría se configura mediante un archivo de configuración, que en el caso de la creación de archivos y eventos de registro es mucho más conveniente que la configuración de ACL.
En este caso, se deben tener en cuenta los siguientes puntos:
- La necesidad de herramientas adicionales. Dado que los eventos se registran, como en el caso de la auditoría avanzada de Windows, Sysmon debe usarse junto con otras herramientas, por ejemplo, SIEM.
- . , Sysmon . .
, . - -. , . , Sysmon . : , , .
Puede leer sobre formas de omitir algunas de las funciones de Sysmon aquí , aquí y aquí .
Detección y respuesta de endpoints
A medida que la infraestructura crece en tamaño y criticidad, las fallas de Sysmon se vuelven significativas. Los EDR de alta calidad tienen varias ventajas (no describiremos las capacidades específicas del producto):
1) Conjunto extendido de eventos registrados
Todo depende del producto específico. Por ejemplo, hay un registro de toda la entrada interactiva a la línea de comandos, lo que le permite detectar técnicas que no son visibles ni con la auditoría de Windows ni con Sysmon.
Vale la pena describir el caso de uso de Mimikatz que vimos durante una de nuestras investigaciones. Hay un archivo ejecutable que contiene Mimikatz cifrado en los recursos. Cuando se pasan la contraseña y el vector de inicialización correctos en la línea de comando, Mimikatz descifra correctamente y acepta comandos en la línea de comando interactiva. Al mismo tiempo, no aparecen comandos en los eventos de creación del proceso.
El registro de la entrada interactiva, a su vez, ayudará a detectar tal caso si no se vuelve a compilar Mimikatz (en nuestro caso, las líneas se dejaron intactas).
2) Gestión y configuración centralizadas
En una gran infraestructura, la capacidad de verificar de forma centralizada el estado y cambiar la configuración del agente es fundamental. Sin él, la respuesta puede demorarse horas o incluso días.
3) Autosuficiencia
En la mayoría de los casos, EDR es un producto independiente con su propia interfaz, que se puede utilizar no solo junto con otras herramientas, sino también por separado.
Puede ser posible escribir sus propias reglas de detección. Dado que el conjunto de datos es más grande que el de Advanced Auditing o Sysmon, los analistas tienen más oportunidades de detectar diferentes patrones de ataque.
4) Posibilidad de respuesta activa
Durante la respuesta a un incidente, la necesidad de actuar en varios sistemas casi siempre se convierte en un problema.
EDR le permite realizar muchas acciones en una forma interactiva conveniente:
- trabajar con archivos y registro
- bloquear conexiones de red
- terminar procesos
- escanear con las reglas de yara
- recopilar artefactos para un análisis posterior (por ejemplo, una imagen de memoria)
- Automatización de todo lo anterior en un grado u otro.
- y mucho más.
Dado que la clase de producto EDR se creó originalmente para proporcionar supervisión y respuesta de host, existen significativamente menos inconvenientes para tales soluciones en esta área. Todo depende de las capacidades de un producto en particular. También hay puntos ciegos, por ejemplo, no hay un análisis en profundidad de la actividad de la red (un problema que se resuelve con éxito con los productos NTA / NDR).
La práctica muestra que la presencia de EDR en la infraestructura expande significativamente las capacidades para identificar amenazas, además de acelerar la respuesta y facilitar la investigación de incidentes, permitiendo una reconstrucción más precisa de la cronología de eventos. Sysmon actúa como una medida a medias, y en el caso de una sola auditoría estándar, que es fácil de eludir, debe contentarse con artefactos menos informativos, incluidos los inusuales, sobre los que escribimos en el artículo anterior .
Publicado por Asker Jamirze, ingeniero técnico senior de investigación, departamento de investigación de incidentes, JSOC CERT