Automatizar la detección de posibles rutas de interceptación de DLL (DLL Hijacks)

Hola, Khabrovites. Contratación para la nueva corriente del curso “Pentest. Práctica de prueba de penetración " . Anticipándonos al inicio del curso, compartimos con ustedes la traducción de material interesante.

Introducción

En este artículo, veremos el concepto de secuestro de DLL y cómo se puede usar para lograr la persistencia del área de usuario en los sistemas Windows. Este método se describe en MITRE ATT & CK en: "Interceptación del orden de búsqueda de DLL (T1038) ".



Los atacantes pueden utilizar la suplantación de DLL para muchos propósitos diferentes, pero este artículo se centrará en lograr la resistencia con aplicaciones de inicio automático. Por ejemplo, dado que Slack y Microsoft Teams se inician en el arranque (de forma predeterminada), la suplantación de DLL en una de estas aplicaciones permitiría al atacante obtener un acceso sólido a su objetivo, siempre que un usuario inicie sesión.



Después de presentar el concepto de DLL, orden de búsqueda de DLL y suplantación de DLL, lo guiaré a través del proceso de automatización de la detección de interceptación de DLL . Este artículo hablará sobre la detección de rutas de interceptación de DLL en Slack, Microsoft Teams y Visual Studio Code.



Finalmente, descubrí múltiples rutas de interceptación de DLL utilizadas por diferentes aplicaciones, investigué la causa raíz y descubrí que las aplicaciones que usan ciertas llamadas a la API de Windows son propensas a la interceptación de DLL cuando no se ejecutan desde C:\Windows\System32\.



Quiero agradecer a mi colega Josiah Massari ( @Airzero24) por ser el primero en descubrir algunas de estas intercepciones de DLL, explicar su metodología e inspirarme a automatizar la detección.

¿Qué es una DLL?

Una DLL es una biblioteca que contiene código y datos que pueden ser utilizados simultáneamente por más de un programa. ( Fuente ) La



funcionalidad de una DLL puede ser utilizada por una aplicación de Windows usando una de las funciones LoadLibrary*. Las aplicaciones pueden hacer referencia a archivos DLL diseñados específicamente para esas aplicaciones, o archivos DLL de Windows que ya están en el disco en System32. Los desarrolladores pueden cargar archivos DLL desde System32 para usar la funcionalidad ya implementada en Windows en sus aplicaciones sin tener que escribir esta funcionalidad desde cero.



Por ejemplo, un desarrollador que necesita realizar solicitudes HTTP puede usar la biblioteca WinHTTP ( winhttp.dll) en lugar de implementar solicitudes HTTP usando sockets sin formato.

Orden de búsqueda e interceptación de DLL

Dado que las DLL existen como archivos en el disco, es posible que se pregunte cómo una aplicación sabe desde dónde cargar la DLL. Microsoft ha documentado el orden de búsqueda de DLL en detalle aquí .



A partir de Windows XP SP2, el modo de búsqueda segura de DLL está habilitado de forma predeterminada ( HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode). Cuando el modo seguro está habilitado, el orden de búsqueda de DLL es el siguiente:

1. El directorio desde el que se cargó la aplicación.
2. Directorio del sistema. Utilice la función GetSystemDirectory para obtener la ruta a este directorio.
3. Directorio del sistema de 16 bits. No hay ninguna función que proporcione una ruta a este directorio, pero se busca.
4. Directorio de Windows. Utilice la función GetWindowsDirectory para obtener la ruta a este directorio.
5. Directorio actual.
6. , PATH. , , App Paths. App Paths DLL.

Un sistema puede contener varias versiones de la misma DLL. Las aplicaciones pueden controlar la elección de la ubicación desde la que se debe cargar la DLL especificando la ruta completa o utilizando otro mecanismo como un manifiesto. ( Fuente )



Si la aplicación no especifica desde dónde cargar la DLL, Windows usa el orden de búsqueda de DLL predeterminado que se muestra arriba. La primera posición en el orden de búsqueda de DLL (el directorio desde el que se carga la aplicación) es de interés para los atacantes.



Si el desarrollador de la aplicación tiene la intención de cargar la DLL desdeC:\Windows\System32, pero no lo escribió explícitamente en la aplicación, la DLL maliciosa ubicada en el directorio de la aplicación se cargará antes que la DLL legítima de System32. La carga de una DLL maliciosa se denomina suplantación de DLL (o interceptación) y los atacantes la utilizan para cargar código malicioso en aplicaciones confiables / firmadas.

Uso de la suplantación de identidad de DLL para lograr resiliencia

La suplantación de DLL se puede utilizar para lograr resistencia cuando se inicia una aplicación / servicio vulnerable y una DLL maliciosa se coloca en una ubicación vulnerable. Un colega mío @Airzero24descubrió la suplantación de DLL en Microsoft OneDrive, Microsoft Teams y Slack como userenv.dll.



Fueron estos programas los que se convirtieron en el objetivo de la interceptación, porque de forma predeterminada están configurados para iniciarse al inicio de Windows. Esto se puede ver a continuación en el Administrador de tareas:





Aplicaciones de Windows configuradas para inicio automático



Para probar la suplantación de DLL, creé un cargador de shellcode DLL que inició Cobalt Strike Beacon. Cambié el nombre de la DLL maliciosa userenv.dlly la copié en el directorio de la aplicación afectada. Abrí la aplicación y vi mi nueva devolución de llamada de Beacon.





Baliza de impacto de cobalto a través de la intercepción de DLL



usandoProcess Explorer , puedo verificar si mi DLL malicioso fue realmente cargado por una aplicación vulnerable.





Explorador de procesos que muestra la DLL maliciosa cargada

Detección automática del potencial de interceptación de DLL

Después de confirmar el secuestro de DLL previamente conocido, quería ver si podía encontrar otras capacidades de suplantación de DLL que pudieran explotarse.



El código utilizado en mi pago se puede encontrar aquí .

Usando Slack como ejemplo

Para iniciar este proceso, ejecuté Process Monitor (ProcMon) con los siguientes filtros:

• Nombre del proceso -slack.exe
• El resultado contieneNOT FOUND
• El camino termina con .dll.

Encuentre archivos DLL que faltan en ProcMon.



Luego, inicié Slack y examiné ProcMon en busca de cualquier DLL que Slack estuviera buscando pero no pudiera encontrar.





Posibles rutas de interceptación de DLL descubiertas por ProcMon Exporté



estos datos de ProcMon como un archivo CSV para facilitar el análisis en PowerShell.



Con mi DLL de cargador de shellcode actual, no pude averiguar fácilmente los nombres de DLL que Slack cargó con éxito. Creé una nueva DLL, que se usa GetModuleHandleEx, y GetModuleFileNamepara determinar el nombre de la DLL cargada y escribirla en un archivo de texto .



Mi siguiente objetivo era analizar el archivo CSV en busca de rutas DLL en la lista, ver esa lista, copiar mi DLL de prueba en la ruta especificada, iniciar el proceso de destino, detener el proceso de destino y eliminar la DLL de prueba. Si la DLL de prueba se cargó correctamente, escribirá su nombre en el archivo resultante.



Cuando finalice este proceso, tendré una lista de posibles secuestros de DLL (espero) escrita en un archivo de texto.



Toda la magia en mi proyecto DLLHijackTest se realiza mediante un script de PowerShell . Acepta la ruta al archivo CSV generado por ProcMon, la ruta a su DLL malicioso, la ruta al proceso que desea ejecutar y cualquier argumento que desee pasar al proceso.





Parámetros de





Get-PotentialDLLHijack Get-PotentialDLLHijack.ps1



Después de unos minutos, verifico el archivo de texto que aparece en mi DLL "malicioso" en busca de posibles secuestros de DLL. Encontré las siguientes posibles rutas de interceptación para Slack:

PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\slack\slack.exe"
C:\Users\John\AppData\Local\slack\app-4.6.0\WINSTA.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\LINKINFO.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\ntshrui.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\srvcli.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\cscapi.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\KBDUS.DLL

Usando Microsoft Teams como ejemplo

Realizamos de nuevo el proceso descrito anteriormente:

1. Utilice ProcMon para identificar posibles rutas de interceptación de DLL, exporte estos datos como un archivo CSV.
2. Determine la ruta para iniciar el proceso.
3. Defina los argumentos que desee pasar al proceso.
4. Ejecutar Get-PotentialDLLHijack.ps1con argumentos apropiados.

Encontré las siguientes posibles rutas de interceptación para Microsoft Teams:

PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\Microsoft\Teams\Update.exe" -ProcessArguments '--processStart "Teams.exe"'
C:\Users\John\AppData\Local\Microsoft\Teams\current\WINSTA.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\LINKINFO.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\ntshrui.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\srvcli.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\cscapi.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\WindowsCodecs.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\TextInputFramework.dll

Nota : Tuve que hacer pequeños cambios en el script de PowerShell para completar Teams.exe, ya que mi script está intentando terminar el proceso que estaba intentando iniciar, en este caso es Update.exe.

Usando Visual Studio Code como ejemplo

Al repetir el proceso anterior, encontré las siguientes posibles rutas de interceptación para Visual Studio Code:

PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\Programs\Microsoft VS Code\Code.exe"
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\WINSTA.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\LINKINFO.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\ntshrui.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\srvcli.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\cscapi.dll

Compartir archivos DLL

Noté que Slack, Microsoft Teams y Visual Studio Code comparten las siguientes DLL:

• WINSTA.dll
• LINKINFO.dll
• ntshrui.dll
• srvcli.dll
• cscapi.dll

Encontré esto interesante y quería entender qué causa este comportamiento.

Metodología: comprensión de las formas de interceptar archivos DLL compartidos

Vi pila cuando Tracy Una mala tratado de carga WINSTA.dll, LINKINFO.dll, ntshrui.dll, srvcli.dlly cscapi.dll.



DLL con carga diferida



me di cuenta de las similitudes en la pila al cargar Tracy WINSTA.dll, LINKINFO.dll, ntshrui.dlly srvcli.dll.





Seguimiento de pila cuando Code.exe intenta cargar WINSTA.dll





un seguimiento de pila al Teams.exeintentar cargar LINKINFO.dll,





seguimiento de pila cuando Slack intenta cargarntshrui.dll



un seguimiento de pila contiene constantemente una llamada _tailMerge_<dllname>_dll, delayLoadHelper2seguido LdrResolveDelayLoadedAPI. Este comportamiento fue el mismo para las tres aplicaciones.



He determinado que este comportamiento está relacionado con la carga lenta de DLL . Desde la pila de seguimiento en el arranqueWINSTA.dllPude ver que el módulo responsable de esta carga diferida era wtsapi32.dll.



Abrí wtsapi32.dllen Ghidra y usé Search -> For Strings -> Filter: WINSTA.dll. Haga doble clic en la línea encontrada y lo llevará a su ubicación en la memoria.





La línea " WINSTA.dll" enwtsapi32.dll



Haciendo clic derecho en una ubicación en la memoria, podemos encontrar cualquier referencia a esta dirección.





Enlaces aWINSTA.dll



Siguiendo los enlaces, podemos ver que la cadena WINSTA.dllse pasa a una estructura llamada ImgDelayDescr. Al mirar la documentación de esta estructura, podemos confirmar que está relacionada con DLL de carga diferida.

typedef struct ImgDelayDescr {
   DWORD        grAttrs;        // 
   RVA          rvaDLLName;     // RVA   dll 
   RVA          rvaHmod;        // RVA  
   RVA          rvaIAT;         // RVA IAT
   RVA          rvaINT;         // RVA INT
   RVA          rvaBoundIAT;    // RVA   IAT
   RVA          rvaUnloadIAT;   // RVA    IAT
   DWORD        dwTimeStamp;    // 0,   ,
                                // O.W. / DLL,   (Old BIND)
   } ImgDelayDescr, * PImgDelayDescr;

Esta estructura se puede pasar a __delayLoadHelper2, que utilizará LoadLibrary/ GetProcAddresspara cargar la DLL especificada y fijar la dirección de la función importada en la tabla de direcciones de importación de carga diferida (IAT).

FARPROC WINAPI __delayLoadHelper2(
   PCImgDelayDescr pidd,  //     ImgDelayDescr
   FARPROC * ppfnIATEntry //     IAT  
);

Al encontrar otras referencias a nuestra estructura ImgDelayDescr, podemos encontrar una llamada __delayLoadHelper2que luego llama ResolveDelayLoadedAPI. He cambiado el nombre de la función, los tipos y las variables para que sea más fácil de entender.





__delayLoadHelper2y ResolveDelayLoadedAPIen Ghidra



¡Excelente! Esto es consistente con lo que vimos en nuestro seguimiento de pila de ProcMon cuando Slack intentó cargar WINSTA.dll.





__delayLoadHelper2 y ResolveDelayLoadedAPIen ProcMon.



Este comportamiento fue uniforme para WINSTA.dll, LINKINFO.dll, ntshrui.dlly srvcli.dll. La principal diferencia entre cada DLL de carga diferida era la DLL "principal". En las tres aplicaciones:

• wtsapi32.dll diferido cargado WINSTA.dll
• shell32.dll vago cargado LINKINFO.dll
• LINKINFO.dll diferido cargado ntshrui.dll
• ntshrui.dll diferido cargado srvcli.dll

¿Notaste algo interesante? Parece que shell32.dlldescarga LINKINFO.dll, que descarga ntshrui.dll, que finalmente descarga srvcli.dll. Esto nos lleva a nuestra última opción potencial común DLL spoofing - cscapi.dll.

Sustitución de DLL en NetShareGetInfo y NetShareEnum

Seguí el seguimiento de la pila cuando Slack intentó cargar cscapi.dlly vi una llamada LoadLibraryExWque aparentemente provenía de srvcli.dll. Abrí el





seguimiento decscapi.dll



la pila al arrancarsrvcli.dll en Ghidra y usé Search -> For Strings -> Filter: cscapi.dll. Hacer doble clic en la línea encontrada y seguir los enlaces conduce a la LoadLibraryllamada esperada .





srvcli.dllllama a LoadLibrary paracscapi.dll



cambiar el nombre de la función que contiene la llamada LoadLibraryy siguiendo los enlaces, obtuve dos lugares donde se usa la función:

• NetShareEnum
• NetShareGetInfo

Descargas de NetShareEnum





cscapi.dll Descargas de NetShareGetInfocscapi.dll



Verifiqué esto con programas PoC que llamaron NetShareEnumy NetShareGetInfo:





NetShareEnum.exedescargas cscapi.dll





NetShareGetInfo.exedescargascscapi.dll

resultados

Las siguientes rutas de suplantación de DLL están disponibles en Slack:

C:\Users\John\AppData\Local\slack\app-4.6.0\WINSTA.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\LINKINFO.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\ntshrui.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\srvcli.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\cscapi.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\KBDUS.DLL

Las siguientes rutas de suplantación de DLL están disponibles en Microsoft Teams:

C:\Users\John\AppData\Local\Microsoft\Teams\current\WINSTA.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\LINKINFO.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\ntshrui.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\srvcli.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\cscapi.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\WindowsCodecs.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\TextInputFramework.dll

Las siguientes rutas de suplantación de DLL están disponibles en Visual Studio Code:

C:\Users\John\AppData\Local\Programs\Microsoft VS Code\WINSTA.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\LINKINFO.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\ntshrui.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\srvcli.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\cscapi.dll

Además, descubrí que los programas que usan NetShareEnumy NetShareGetInfobrindan la capacidad de reemplazar archivos DLL en el formulario cscapi.dlldebido a la llamada codificada LoadLibrary. He verificado este comportamiento con Ghidra y PoC.

Conclusión

Como recordatorio, la interceptación de DLL es un método mediante el cual los atacantes pueden interferir con la ejecución del código en aplicaciones firmadas / confiables. He creado herramientas para ayudar a automatizar la detección de rutas de interceptación de DLL. Con esta herramienta descubrí las rutas de intercepción de DLL en Slack, Microsoft Teams y Visual Studio Code.



Noté que las rutas de interceptación de DLL de estas tres aplicaciones se superponen e investigué la causa. Destaqué mi método para entender esta coincidencia. Aprendí acerca de las DLL de carga diferida y descubrí dos llamadas a la API que hacen posible interceptar las DLL en cualquier programa que las llame:

• NetShareEnum cargas cscapi.dll
• NetShareGetInfo cargas cscapi.dll

Gracias por tomarse el tiempo de leer este artículo, espero que haya aprendido un par de cosas sobre la API de Windows, Ghidra, ProcMon, DLL y la intercepción de DLL.

Enlaces

¡Un gran saludo a mis colegas Daniel Heinsen ( @hotnops), Lee Christensen ( @tifkin_) y Matt Hand ( @matterpreter) por ayudar con Ghidra / ProcMon!

---

Comprobación de PoC públicas para su uso en pentesting

---

Lee mas:

• Entonces, quieres convertirte en un analista de seguridad de redes ...
• JWT: ataque de firma digital contra ataque MAC
• Escape de los contenedores Docker privilegiados