Arte del Phishing XLL
Con el reciente anuncio de Microsoft sobre el bloqueo de macros en documentos provenientes de internet (tanto por correo electrónico como por descarga web), los atacantes han comenzado a explorar agresivamente otras opciones para lograr el acceso impulsado por el usuario (UDA). Hay varias consideraciones a sopesar y equilibrar al buscar un método viable de phishing para obtener acceso:
Estas son las preguntas principales, aunque ciertamente hay más. Las cosas se vuelven más complejas al darse cuenta de que estos factores se combinan entre sí; por ejemplo, si un cliente tiene un proxy web que prohíbe la descarga de ejecutables o DLL, es posible que debas meter tu payload dentro de un contenedor (ZIP, ISO, etc.). Hacerlo puede presentar problemas más adelante en cuanto a la detección. Defensas más robustas requieren combinaciones más complejas de técnicas para ser superadas.
Este artículo estará escrito pensando en una organización objetivo ficticia; esta organización ha implementado varias medidas defensivas, incluyendo reglas de filtrado de correo electrónico, bloqueo de ciertos tipos de archivo en las descargas, listas blancas de aplicaciones en los endpoints y Microsoft Defender para Endpoint como solución EDR.
Las organizaciones reales pueden no implementar ninguna de estas, algunas, o incluso más defensas, lo que puede simplificar o complicar las técnicas descritas en esta investigación. Como siempre, conoce a tu objetivo.
Los XLL son DLL, específicamente diseñados para Microsoft Excel. A simple vista, se parecen mucho a los documentos normales de Excel.
Los XLL ofrecen una opción muy atractiva para UDA dado que son ejecutados por Microsoft Excel, un software muy común en las redes de clientes; como beneficio adicional, debido a que son ejecutados por Excel, nuestro payload casi con toda seguridad eludirá las reglas de listas blancas de aplicaciones porque una aplicación confiable (Excel) lo está ejecutando. Los XLL se pueden escribir en C, C++ o C#, lo que proporciona mucha más flexibilidad, potencia (y cordura) que las macros VBA, lo que los convierte en una opción deseable.
La desventaja, por supuesto, es que hay muy pocos usos legítimos para los XLL, por lo que DEBERÍA ser una casilla muy fácil de marcar para que las organizaciones bloqueen la descarga de esa extensión de archivo tanto por correo electrónico como por descarga web. Lamentablemente, muchas organizaciones están años por detrás de la curva y, como tal, los XLL siguen siendo un método viable de phishing durante algún tiempo.
Hay una serie de eventos diferentes que se pueden utilizar para ejecutar código dentro de un XLL; el más notable es xlAutoOpen. La lista completa se puede ver aquí:
Al hacer doble clic en un XLL, el usuario se encuentra con esta pantalla:
Este único cuadro de diálogo es todo lo que se interpone entre el usuario y la ejecución de código; con una ingeniería social bastante débil, la ejecución de código está prácticamente asegurada.
Algo que se debe tener en cuenta es que los XLL, al ser ejecutables, son específicos de la arquitectura. Esto significa que debes conocer tu objetivo; la versión de Microsoft Office/Excel que utiliza la organización objetivo (generalmente) dictará la arquitectura para la que debes construir tu payload.
Hay una división bastante clara en las versiones de Office que se puede usar como regla general:
Office 2016 o anterior: x86
Office 2019 o posterior: x64
Cabe señalar que es posible instalar la otra arquitectura para cada producto, sin embargo estas son las arquitecturas predeterminadas instaladas y, en la mayoría de los casos, esta debería ser una forma confiable de decidir qué arquitectura usar para tu XLL. Por supuesto, dependiendo del método de entrega y el pretexto utilizado como parte de la campaña de phishing, es posible proporcionar ambas versiones y confiar en que la víctima seleccione la versión adecuada para su sistema.
El payload XLL que se construyó durante esta investigación se basó en este proyecto de edparcell. Su repositorio tiene buenas instrucciones para comenzar con XLL en Visual Studio, y usé su código como punto de partida para desarrollar un archivo XLL malicioso.
Una desviación notable de su repositorio es que, si deseas crear tu propio proyecto XLL, necesitarás descargar el último SDK de Excel y luego seguir las instrucciones del repositorio enlazado anteriormente usando esta versión en lugar de la versión 2010 del SDK mencionada en el README.
La entrega del payload es una consideración importante en el contexto de UDA. Nos centraremos en dos métodos principales:
Ya sea adjuntando un archivo o incluyendo un enlace a un sitio web donde se pueda descargar un archivo, el correo electrónico es una parte crítica del proceso de UDA. Con los años, muchas organizaciones (y proveedores de correo electrónico) han madurado y aplicado reglas para proteger a los usuarios y organizaciones de archivos adjuntos maliciosos. El resultado variará, pero las organizaciones ahora tienen la capacidad de:
Probar las reglas de correo electrónico de una organización puede ser una parte importante de un engagement, sin embargo siempre se debe tener cuidado para no revelar que una operación de Red Team está en curso y que se está recopilando activamente información.
Para los propósitos de este artículo, se asumirá que la organización objetivo tiene reglas robustas de adjuntos de correo electrónico que impiden la entrega de un payload XLL. Nos desviaremos y veremos la entrega web.
El correo electrónico aún se utilizará en este vector de ataque, sin embargo, en lugar de enviar un adjunto, se utilizará para enviar un enlace a un sitio web. Las reglas del proxy web y las mitigaciones de red que controlan los tipos de archivos permitidos para descargar pueden diferir de las aplicadas a los adjuntos de correo electrónico. Para los propósitos de este artículo, se asume que la organización impide la descarga de archivos ejecutables (encabezados MZ) desde la web. Siendo este el caso, vale la pena explorar packers/contenedores.
La premisa es que podríamos colocar nuestro ejecutable dentro de otro tipo de archivo y pasarlo de contrabando por las políticas de la organización. Una consideración importante aquí es el soporte nativo para el tipo de archivo; los archivos 7Z, por ejemplo, no pueden abrirse en Windows sin instalar software de terceros, por lo que no son una buena opción. Formatos como ZIP, ISO e IMG son opciones atractivas porque Windows los soporta de forma nativa y, como beneficio adicional, agregan muy pocos pasos adicionales para la víctima.
Desafortunadamente, la organización bloquea la descarga de ISO e IMG desde la web; además, debido a que emplean Prevención de Pérdida de Datos (DLP), los usuarios no pueden montar dispositivos de almacenamiento externos, que es como se consideran los ISO e IMG.
Por suerte para nosotros, aunque la organización impide la descarga de archivos con encabezados MZ, sí permite la descarga de archivos zip que contengan ejecutables. Estos archivos zip se escanean activamente en busca de malware, incluyendo solicitar al usuario la contraseña de archivos zip protegidos; sin embargo, debido a que el ejecutable está comprimido, no se bloquea por la denegación general de archivos MZ.
Se eligieron los archivos zip como contenedor para nuestro payload XLL porque:
Convenientemente, al hacer doble clic en un archivo ZIP en Windows, se abre ese archivo zip en el Explorador de archivos:
Menos convenientemente, al hacer doble clic en el archivo XLL desde la ubicación comprimida se activa Windows Defender; incluso usando el proyecto estándar de edparcell que no contiene ningún tipo de código malicioso.
Al observar la alerta de Windows Defender, vemos que es solo una alerta genérica "Wacatac":
Sin embargo, hay algo extraño; el archivo que identificó como malicioso estaba en c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip, no en C:\users\user\Downloads\ZippedXLL\ donde hicimos doble clic. Al observar la instancia de Excel en ProcessExplorer, se muestra que Excel está ejecutando realmente el XLL desde appdata\local\temp, no desde el archivo ZIP del que proviene:
Esto parece ser una arruga asociada con los archivos ZIP, no con los XLL. Abrir un archivo TXT desde dentro de un zip usando el bloc de notas también resulta en que el archivo TXT se copie a appdata\local\temp y se abra desde allí. Si bien abrir un archivo de texto desde esta ubicación está bien, Defender parece identificar cualquier tipo de ejecución de código real en esta ubicación como maliciosa.
Si un usuario extrajera el XLL del archivo ZIP y luego lo ejecutara, se ejecutará sin ningún problema; sin embargo, no hay forma de garantizar que un usuario haga esto, y realmente no podemos arriesgarnos a que salte el AV/EDR si no lo extraen. Además, hacer doble clic en el ZIP y luego en el XLL es mucho más simple y es más probable que una víctima complete estas acciones simples que tomarse la molestia de extraer el ZIP.
Este problema me llevó a considerar un tipo de payload diferente al XLL; comencé a explorar VSTO, que son Plantillas de Visual Studio para Office. Te recomiendo encarecidamente que leas ese artículo.
Los VSTO finalmente llaman a una DLL que puede estar ubicada localmente con el .XLSX que inicia todo, o alojada de forma remota y descargada por el .XLSX a través de http/https. La opción local no proporciona ventajas reales (y de hecho tiene varias desventajas, ya que hay varios archivos más asociados con un ataque VSTO), y la opción remota desafortunadamente requiere un certificado de firma de código o que la ubicación remota sea una red de confianza. Al no tener un certificado de firma de código válido, los VSTO no mitigan ninguno de los problemas en este escenario que nuestro payload XLL está encontrando.
Realmente parece que estamos acorralados. Ejecutar el XLL en sí está bien, sin embargo, el XLL no puede entregarse solo a la víctima, ya sea mediante un adjunto de correo electrónico o una descarga web debido a la política de la organización. El XLL debe empaquetarse dentro de un contenedor, pero debido a DLP, formatos como ISO, IMG y VHD no son viables. La víctima debe poder abrir el contenedor de forma nativa sin software de terceros, lo que realmente deja ZIP como la opción; sin embargo, como se discutió, ejecutar el XLL desde una carpeta comprimida hace que se copie y ejecute desde appdata\local\temp, lo que activa el AV.
Pasé muchas horas pensando y probando cosas, yendo por el camino del VSTO, explorando todas las opciones concebibles hasta que finalmente decidí probar algo tan tonto que podría funcionar.
Esta vez creé una carpeta, coloqué el XLL dentro y luego comprimí la carpeta:
Al hacer clic en la carpeta, se revela el archivo XLL:
Al hacer doble clic en el XLL, aparece el mensaje de complemento de Excel. Observa que el XLL todavía se copia a appdata\local\temp, sin embargo, hay una capa adicional debido a la carpeta extra que creamos:
Al hacer clic en habilitar, se ejecuta nuestro código sin activar Defender:
¡Bien! Ejecución de código. ¿Y ahora qué?
El pretexto involucrado en lograr que una víctima descargue y ejecute el XLL variará enormemente según la organización y el método de entrega; los temas podrían incluir datos salariales de empleados, calculadoras de compensación basada en habilidades, información sobre un proyecto, una lista de asistentes a un evento, etc. Sea cual sea el señuelo, nuestro ataque será mucho más efectivo si realmente le proporcionamos a la víctima lo que se le prometió. Sin un seguimiento, las víctimas pueden sospechar e informar el documento a sus equipos de seguridad, lo que puede delatar rápidamente al atacante y restringir el acceso al sistema objetivo.
El XLL por sí solo dejará una ventana de Excel en blanco después de que nuestro código termine de ejecutarse; sería mucho mejor para nosotros proporcionar la hoja de cálculo de Excel que la víctima está buscando.
Podemos incrustar nuestro XLSX como una matriz de bytes dentro del XLL; cuando el XLL se ejecute, colocará el XLSX en el disco junto al XLL, después de lo cual se abrirá. Nombraremos el XLSX igual que el XLL, siendo la única diferencia la extensión.
Dado que nuestro XLL está escrito en C, podemos incorporar algunas de las capacidades de un artículo anterior que escribí sobre Capacidades de payload en C, específicamente la Autoeliminación. Combinar estas dos técnicas da como resultado que el XLL se elimine del disco y el XLSX con el mismo nombre se coloque en su lugar. Para el ojo no entrenado, parecerá que el XLSX estuvo allí todo el tiempo.
Desafortunadamente, la ubicación donde se elimina el XLL y se coloca el XLSX es la carpeta appdata\temp\local, no el ZIP original; para solucionar esto, podemos crear un segundo ZIP que contenga solo el XLSX y también leerlo en una matriz de bytes dentro del XLL. En la ejecución, además de las acciones mencionadas anteriormente, el XLL podría intentar localizar el archivo ZIP original en c:\users\victim\Downloads\ y eliminarlo antes de colocar el segundo ZIP que contiene solo el XLSX en su lugar. Esto podría fallar si el usuario guardó el ZIP original en una ubicación diferente o con un nombre diferente, sin embargo, en muchos/la mayoría de los casos, debería caer automáticamente en la carpeta de descargas del usuario.
Esta captura de pantalla muestra en el panel inferior la carpeta temporal creada en appdata\local\temp que contiene el XLL y el XLSX colocado, mientras que el panel superior muestra la ventana original del Explorador de archivos desde la que se abrió el XLL. Observa en el panel inferior que el XLL tiene tamaño 0. Esto se debe a que se eliminó a sí mismo durante la ejecución, sin embargo, hasta que se cierre el panel superior, el archivo XLL no desaparecerá por completo de la ubicación appdata\local\temp. Incluso si la víctima hiciera clic en el XLL nuevamente, ahora está inerte y realmente no existe.
De manera similar, tan pronto como la víctima salga del ZIP abierto en el Explorador de archivos (ya sea cerrándolo o navegando a una carpeta diferente), si vuelve a hacer clic en spreadsheet.zip, ahora encontrará que la carpeta test contiene importantdoc.xlsx; por lo tanto, el XLL ha sido eliminado y reemplazado por el XLSX inofensivo en ambas ubicaciones donde existía en el disco.
Este GIF demuestra la descarga y ejecución del XLL en una máquina virtual de prueba MDE. Ten en cuenta que, por alguna razón, Excel abre dos instancias aquí; en mi computadora de casa solo abrió una, así que no estoy seguro de por qué difiere.
Como siempre, preguntaremos: "¿Qué ve MDE?"
Un rápido volcado de capturas de pantalla para demostrar que ejecuté esto en el objetivo y recibí un beacon de vuelta en TestMachine11:
En primer lugar, cero alertas:
¿Qué captura la línea de tiempo/registro de eventos?
Vaya. Para ser sincero, no tengo idea de dónde provienen las alertas de keylogging, cifrado y descifrado de credenciales, ya que mi código no hace nada de eso. Nuestras acciones ciertamente parecen sospechosas cuando se presentan así, pero nuevamente comentaré cuántos datos recopila MDE en un solo endpoint, y mucho menos en cientos, miles o cientos de miles que una organización puede tener conectados al EDR. Mientras no estemos generando ninguna alerta real, probablemente estemos bien.
El momento que la mayoría probablemente estaba esperando: proporciono una muestra de código de mi runner XLL desarrollado, limitado solo a las partes discutidas aquí en la sección de Técnica operativa. Quedará a cargo del lector llevar el código a un XLL e implementarlo junto con el resto de su runner. Como siempre, no hagas daño, ten permiso para hacer phishing a una organización, etc.
He incluido el código fuente de un programa que ingiere un archivo y produce hexadecimal que se puede copiar en las matrices de bytes definidas en el fragmento. Úsalo en el XLSX que deseas presentar al usuario, así como en el archivo ZIP que contiene la carpeta que contiene ese mismo XLSX, y almacénalos en sus respectivas matrices de bytes. Compila este código usando:``` gcc -o ingestfile ingestfile.c
Tuve algunos problemas al compilar mis XLL con MingW en una máquina Kali, así que pensé en publicar los comandos aquí:
**x64**```
x86_64-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/x64/XLCALL32.LIB -o importantdoc.xll -s -Os -DUNICODE -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
x86``` i686-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/XLCALL32.LIB -o HelloWorldXll.xll -s -DUNICODE -Os -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
Después de compilar, querrás crear una nueva carpeta y copiar la XLL en esa carpeta. Luego comprímelo usando:```
zip -r <myzipname>.zip <foldername>/
Note que para que el arte del espionaje descrito en esta publicación funcione, necesitará hacer coincidir algunas variables en el fragmento de código con el nombre que le dé al XLL y al archivo zip.
Con el declive del dominio de las macros de Office, los XLL representan una opción atractiva para las campañas de phishing. Con un poco de creatividad, se pueden utilizar junto con otras técnicas para eludir muchas capas de defensas implementadas por organizaciones y equipos de seguridad. ¡Gracias por leer y espero que haya aprendido algo útil!