Evasión de defensa: carga lateral de DLL

Las bibliotecas de enlaces dinámicos (DLL) contienen código ejecutable que se carga al ejecutar un programa. Los atacantes pueden sustituir una DLL maliciosa para llenar el espacio de un archivo DLL normal ausente en un dispositivo. Luego pueden comprometer dicho dispositivo o escalar los privilegios actuales, dependiendo del tipo de ejecutable y si se está ejecutando como un servicio o programa normal. Los proveedores de software a menudo no corrigen estas vulnerabilidades porque se requiere permiso local para instalar DLL, y muchos proveedores no ven los ataques de DLL como un riesgo.

Comprobador de integridad de suma de comprobación de archivos Versión 2.05 "fciv.exe"

Durante las pruebas, Axon Technologies se centró en la explotación de un ejecutable portátil vulnerable para entregar la carga útil fácilmente en un entorno. El 4 de julio de 2019, hyp3rlinx lanzó públicamente una vulnerabilidad en el File Checksum Integrity Verifier. Axon Technologies determinó mediante pruebas que en Windows 10, la única DLL que funciona es USEREN.dll, por lo que cargar esta DLL nos permitió ejecutar con éxito la carga útil que desarrollamos.

PoC de Ataque

La demostración de tal ataque utilizando estas vulnerabilidades sin parches requiere un plan sofisticado y bien organizado:

1 - Saltear cualquier AV al portar un shell inverso limpio como Dynamic Link Library

Para lograr este paso, codificamos un archivo DLL que omitiría la mayoría de los motores AV y luego se ejecutaría con éxito mientras se carga en fciv.exe. Utilizamos C ++ Visual Studio para compilar la DLL definiendo MAIN_DLL con DLL_PROCESS_ATTACH y llamando a la función executepayload () para que cuando esta DLL se adjunte a cualquier proceso, se ejecute la carga maliciosa.

Código DLL Enlace al código
Este archivo DLL compilado omitirá con éxito la mayoría de los motores AV.

2 - Utilizar la técnica de flanqueo de macros Excel 4.0 XLM

XLM Macro es una tecnología de 27 años que se considera una muy buena alternativa a las macros VBA. XLM se ha convertido en una solución preferida para los teamers rojos, ya que XLM puede ser difícil de analizar para las soluciones antivirus; Esto se debe a que en XLM, los datos se almacenan en OLE Streams en contenedores como Workbook OLE Streams. XLM aún es compatible con las versiones más recientes de Microsoft Office. De este modo, pudimos ejecutar el ejecutable fciv vulnerable con un archivo DLL cargado lateralmente utilizando el código de macro XLM.

Código Macro:

3 - Entrega el paquete

El último paso para demostrar el ataque es combinar los dos pasos anteriores junto con una mentalidad de hacker para comprometer el dispositivo sin ser detectado. Como fciv.exe es un ejecutable portátil firmado por Microsoft, lo entregamos con el código de macro XLM guardado como .xls (formato Excel 97–2003).
Después de que se ejecuta el archivo XLS, recibimos con éxito un shell inverso a nuestro terminal atacante.
Utilizando la combinación de la técnica de macro XLM y la vulnerabilidad sin parche del verificador de integridad de la suma de comprobación de archivos, eludimos las soluciones AV y la solución EDR de Carbon Black. También aprendimos que muchos proveedores de soluciones desconocen esta técnica y sus implicaciones.

Análisis de Carbon Black Detección y Respuesta de punto final (EDR)

El análisis del comportamiento sospechoso es una de las principales fortalezas de cualquier operación de seguridad cibernética. Después de la ejecución del documento XLM Macro, encontramos que Carbon Black EDR, con sus fuentes de búsqueda de amenazas habilitadas, no detectó este tipo de ataque. Creemos que la mayoría de los ataques de secuestro de DLL no se pueden detectar. Para analizar qué detectó EDR de Carbon Black y qué se perdió, utilizamos los siguientes pasos y el diagrama de árbol de proceso:

1. Vaya a Búsqueda de procesos y escriba: nombre del proceso: fciv.exe
2. Haga clic en Proceso para mostrar información detallada de nuestra investigación.
3. Vea en el diagrama de árbol anterior que fciv.exe se está ejecutando como un proceso secundario de Excel y que hay un tipo de ejecución de Macro.
4. Obtenga información relacionada (que se enumera debajo del diagrama de árbol) para ver que Carbon Black EDR mostró qué proceso cruzado secundario se ejecutó con una conexión de red activa, pero no señaló un ataque malicioso.

Como se muestra arriba, podemos ver que el ejecutable fciv cargó nuestra DLL maliciosa. Al observar de cerca el orden del árbol de ejecución, observamos que cmd.exe comenzó con PID 2304 directamente con una conexión de red activa al dispositivo atacante.

Indicadores de compromiso (IOC) y detección del ataque

Axon Technologies desarrolló su propio IOC para detectar este tipo de ataque en Carbon Black EDR. El desarrollo de los IOC requiere análisis profundos para evitar falsos positivos y garantizar que el IOC detecte exactamente la técnica de ataque utilizada. La detección de esta técnica de ataque específica en Carbon Black EDR requiere la creación de una alerta de observación con la siguiente consulta del IOC:

cb.urlver = 1 & q = (nombre_proceso: fciv.exe AND (nombre_programa_propietario: rundll32.exe 
 O nombre_programa infantil: cmd.exe O nombre_programa hijo: powershell.exe) Y 
 (modload: CRYPTSP.dll O modload: USERENV.dll))

Axon Technologies desarrolla de manera proactiva y continua las consultas de IOC que se publican en su página de Github (Enlace).

Traducción: Raúl Batista de la Redacción de Segu-Info
Autor: Lawrence Amer
Fuente: Medium - Axon Technologies