
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.