XLL : Techniques de phishing
Avec la récente annonce de Microsoft concernant le blocage des macros dans les documents provenant d'Internet (courrier électronique ET téléchargement web), les attaquants ont commencé à explorer agressivement d'autres options pour parvenir à un accès piloté par l'utilisateur (UDA). Plusieurs considérations doivent être pesées et équilibrées lors de la recherche d'une méthode viable de phishing pour l'accès :
Ce sont les questions principales, mais il y en a certainement d'autres. Les choses deviennent plus complexes lorsque l'on réalise que ces facteurs se cumulent ; par exemple, si un client dispose d'un proxy web qui interdit le téléchargement d'exécutables ou de DLL, vous devrez peut-être placer votre charge utile à l'intérieur d'un conteneur (ZIP, ISO, etc.). Cela peut présenter d'autres problèmes par la suite en matière de détection. Des défenses plus robustes nécessitent des combinaisons de techniques plus complexes pour être contournées.
Cet article sera rédigé en ayant à l'esprit une organisation cible fictive ; cette organisation a mis en place plusieurs mesures défensives, notamment des règles de filtrage des e-mails, le blocage de certains types de fichiers lors du téléchargement, la liste blanche des applications sur les postes de travail et Microsoft Defender for Endpoint comme solution EDR.
Les organisations réelles peuvent n'employer aucune de ces mesures, certaines, ou même davantage de défenses, ce qui peut simplifier ou compliquer les techniques décrites dans cette recherche. Comme toujours, connaissez votre cible.
Les XLL sont des DLL, spécialement conçues pour Microsoft Excel. Pour l'œil non averti, elles ressemblent beaucoup à des documents Excel normaux.
Les XLL offrent une option très attrayante pour l'UDA étant donné qu'elles sont exécutées par Microsoft Excel, un logiciel très courant dans les réseaux clients ; en bonus supplémentaire, parce qu'elles sont exécutées par Excel, notre charge utile contournera presque assurément les règles de liste blanche des applications car une application de confiance (Excel) l'exécute. Les XLL peuvent être écrites en C, C++ ou C#, ce qui offre beaucoup plus de flexibilité, de puissance (et de santé mentale) que les macros VBA, ce qui en fait un choix souhaitable.
L'inconvénient, bien sûr, est qu'il y a très peu d'utilisations légitimes pour les XLL, donc cela DEVRAIT être une case très facile à cocher pour les organisations afin de bloquer le téléchargement de cette extension de fichier à la fois par courrier électronique et par téléchargement web. Malheureusement, de nombreuses organisations ont des années de retard et, par conséquent, les XLL restent une méthode viable de phishing pour quelque temps.
Il existe une série d'événements différents qui peuvent être utilisés pour exécuter du code dans une XLL, le plus notable étant xlAutoOpen. La liste complète peut être consultée ici :
En double-cliquant sur une XLL, l'utilisateur est accueilli par cet écran :
Cette simple boîte de dialogue est tout ce qui sépare l'utilisateur de l'exécution de code ; avec un ingénierie sociale assez mince, l'exécution de code est presque assurée.
Il faut garder à l'esprit que les XLL, étant des exécutables, sont spécifiques à l'architecture. Cela signifie que vous devez connaître votre cible ; la version de Microsoft Office/Excel utilisée par l'organisation cible dictera (généralement) l'architecture pour laquelle vous devez construire votre charge utile.
Il existe une rupture assez nette dans les versions d'Office qui peut être utilisée comme règle empirique :
Office 2016 ou antérieur : x86
Office 2019 ou ultérieur : x64
Il convient de noter qu'il est possible d'installer l'autre architecture pour chaque produit, mais ce sont les architectures par défaut installées et dans la plupart des cas, cela devrait être un moyen fiable de décider quelle architecture utiliser pour votre XLL. Bien sûr, selon la méthode de livraison et le prétexte utilisé dans le cadre de la campagne de phishing, il est possible de fournir les deux versions et de compter sur la victime pour sélectionner la version appropriée pour son système.
La charge utile XLL construite lors de cette recherche était basée sur ce projet par edparcell. Son dépôt contient de bonnes instructions pour démarrer avec les XLL dans Visual Studio, et j'ai utilisé son code comme point de départ pour développer un fichier XLL malveillant.
Une divergence notable par rapport à son dépôt est que si vous souhaitez créer votre propre projet XLL, vous devrez télécharger le dernier SDK Excel puis suivre les instructions du dépôt précédemment lié en utilisant cette version plutôt que la version 2010 du SDK mentionnée dans le README.
La livraison de la charge utile est une considération sérieuse dans le contexte de l'UDA. Nous nous concentrerons sur deux méthodes principales :
Que ce soit en joignant un fichier ou en incluant un lien vers un site web où un fichier peut être téléchargé, l'e-mail est une partie essentielle du processus UDA. Au fil des ans, de nombreuses organisations (et fournisseurs de messagerie) ont mûri et imposé des règles pour protéger les utilisateurs et les organisations contre les pièces jointes malveillantes. Les résultats varieront, mais les organisations ont désormais la capacité de :
Tester les règles de messagerie d'une organisation peut être une partie importante d'un engagement, mais il faut toujours faire attention à ne pas révéler qu'une opération Red Team est en cours et que des informations sont activement collectées.
Pour les besoins de cet article, nous supposerons que l'organisation cible dispose de règles robustes concernant les pièces jointes aux e-mails qui empêchent la livraison d'une charge utile XLL. Nous allons pivoter et examiner la livraison par le web.
L'e-mail sera toujours utilisé dans ce vecteur d'attaque, mais plutôt que d'envoyer une pièce jointe, il sera utilisé pour envoyer un lien vers un site web. Les règles de proxy web et les mesures réseau contrôlant les types de fichiers téléchargeables peuvent différer de celles appliquées aux pièces jointes des e-mails. Pour les besoins de cet article, on suppose que l'organisation empêche le téléchargement de fichiers exécutables (en-têtes MZ) depuis le web. Dans ce cas, il vaut la peine d'explorer les packers/conteneurs.
Le principe est que nous pourrions coller notre exécutable à l'intérieur d'un autre type de fichier et le faire passer en contrebande au-delà des politiques de l'organisation. Une considération majeure ici est la prise en charge native du type de fichier ; les fichiers 7Z par exemple ne peuvent pas être ouverts par Windows sans installer un logiciel tiers, ce n'est donc pas un bon choix. Les formats comme ZIP, ISO et IMG sont des choix attrayants car ils sont pris en charge nativement par Windows, et en bonus, ils ajoutent très peu d'étapes supplémentaires pour la victime.
L'organisation bloque malheureusement les ISO et IMG lors du téléchargement depuis le web ; de plus, parce qu'elle utilise la prévention des pertes de données (DLP), les utilisateurs ne peuvent pas monter de périphériques de stockage externes, ce que sont considérés les ISO et IMG.
Heureusement pour nous, même si l'organisation empêche le téléchargement de fichiers avec en-tête MZ, elle autorise le téléchargement de fichiers zip contenant des exécutables. Ces fichiers zip sont activement scannés pour les logiciels malveillants, y compris en demandant le mot de passe à l'utilisateur pour les fichiers zip protégés par mot de passe ; cependant, comme l'exécutable est zippé, il n'est pas bloqué par le refus général autrement appliqué aux fichiers MZ.
Les fichiers Zip ont été choisis comme conteneur pour notre charge utile XLL car :
De manière pratique, double-cliquer sur un fichier ZIP sous Windows ouvrira ce fichier zip dans l'Explorateur de fichiers :
Moins pratique, double-cliquer sur le fichier XLL depuis l'emplacement zippé déclenche Windows Defender ; même en utilisant le projet standard d'edparcell qui ne contient aucun code malveillant.
En regardant l'alerte de Windows Defender, on voit qu'il s'agit simplement d'une alerte générique "Wacatac" :
Cependant, il y a quelque chose d'étrange ; le fichier identifié comme malveillant se trouvait dans c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip, pas dans C:\users\user\Downloads\ZippedXLL\ où nous l'avons double-cliqué. En regardant l'instance d'Excel dans ProcessExplorer, on voit qu'Excel exécute en fait la XLL depuis appdata\local\temp, pas depuis le fichier ZIP d'origine :
Cela semble être un pli associé aux fichiers ZIP, pas aux XLL. Ouvrir un fichier TXT depuis un zip avec le Bloc-notes entraîne également la copie du fichier TXT dans appdata\local\temp et son ouverture à partir de là. Bien que l'ouverture d'un fichier texte depuis cet emplacement soit acceptable, Defender semble identifier n'importe quel type d'exécution de code à cet emplacement comme malveillant.
Si un utilisateur devait extraire la XLL du fichier ZIP puis l'exécuter, elle s'exécutera sans problème ; mais il n'y a aucun moyen de garantir que l'utilisateur le fasse, et nous ne pouvons vraiment pas jouer à pile ou face sur la détection AV/EDR s'il ne l'extrait pas. De plus, double-cliquer sur le ZIP puis sur la XLL est bien plus simple et une victime est bien plus encline à effectuer ces actions simples qu'à prendre la peine d'extraire le ZIP.
Ce problème m'a amené à envisager un type de charge utile différent de la XLL ; j'ai commencé à explorer les VSTO, qui sont des modèles Visual Studio pour Office. Je vous encourage vivement à consulter cet article.
Les VSTO appellent finalement une DLL qui peut être située localement avec le .XLSX qui initie tout, ou hébergée à distance et téléchargée par le .XLSX via http/https. L'option locale n'offre aucun avantage réel (et en fait plusieurs inconvénients car il y a plusieurs fichiers supplémentaires associés à une attaque VSTO), et l'option distante nécessite malheureusement un certificat de signature de code ou que l'emplacement distant soit un réseau de confiance. N'ayant pas de certificat de signature de code valide, les VSTO n'atténuent aucun des problèmes posés par notre charge utile XLL dans ce scénario.
Nous semblons vraiment coincés dans un coin. Exécuter la XLL elle-même est acceptable, mais la XLL ne peut pas être livrée seule à la victime, que ce soit par pièce jointe e-mail ou téléchargement web en raison de la politique de l'organisation. La XLL doit être emballée dans un conteneur, mais en raison du DLP, les formats comme ISO, IMG et VHD ne sont pas viables. La victime doit pouvoir ouvrir le conteneur nativement sans logiciel tiers, ce qui ne laisse que le ZIP comme option ; mais comme discuté, exécuter la XLL depuis un dossier zippé entraîne sa copie et son exécution depuis appdata\local\temp, ce qui déclenche l'AV.
J'ai passé de nombreuses heures à réfléchir et à tester des choses, à descendre dans le terrier du lapin VSTO, à explorer toutes les options concevables jusqu'à ce que je décide finalement d'essayer quelque chose de si stupide que cela pourrait bien fonctionner.
Cette fois, j'ai créé un dossier, placé la XLL à l'intérieur, puis zippé le dossier :
En cliquant sur le dossier, on révèle le fichier XLL :
Double-cliquer sur la XLL affiche l'invite de complément d'Excel. Notez que la XLL est toujours copiée dans appdata\local\temp, mais il y a une couche supplémentaire à cause du dossier supplémentaire que nous avons créé :
Cliquer sur Activer exécute notre code sans déclencher Defender :
Bien ! Exécution de code. Et maintenant ?
Le prétexte utilisé pour amener une victime à télécharger et exécuter la XLL variera considérablement en fonction de l'organisation et de la méthode de livraison ; les thèmes peuvent inclure les données salariales des employés, des calculatrices de rémunération basées sur les compétences, des informations sur un projet, une liste de participants pour un événement, etc. Quel que soit l'appât, notre attaque sera beaucoup plus efficace si nous fournissons effectivement à la victime ce qui lui a été promis. Sans suivi, les victimes pourraient devenir méfiantes et signaler le document à leurs équipes de sécurité, ce qui peut rapidement trahir l'attaquant et restreindre l'accès au système cible.
La XLL seule ne laissera qu'une fenêtre Excel vide après l'exécution de notre code ; il serait bien mieux pour nous de fournir le tableur Excel que la victime recherche.
Nous pouvons intégrer notre XLSX sous forme de tableau d'octets dans la XLL ; lorsque la XLL s'exécute, elle dépose le XLSX sur le disque à côté de la XLL, après quoi il sera ouvert. Nous nommerons le XLSX du même nom que la XLL, la seule différence étant l'extension.
Étant donné que notre XLL est écrite en C, nous pouvons inclure certaines des capacités d'un précédent article que j'ai écrit sur les Capacités de charge utile en C, à savoir l'auto-suppression. La combinaison de ces deux techniques permet de supprimer la XLL du disque et de déposer le XLSX du même nom à sa place. Pour un œil non averti, il semblera que le XLSX était là depuis le début.
Malheureusement, l'emplacement où la XLL est supprimée et le XLSX est déposé est le dossier appdata\temp\local, pas le ZIP d'origine ; pour remédier à cela, nous pouvons créer un deuxième ZIP contenant uniquement le XLSX et aussi le lire dans un tableau d'octets dans la XLL. Lors de l'exécution, en plus des actions susmentionnées, la XLL pourrait tenter de localiser le fichier ZIP d'origine dans c:\users\victim\Downloads\ et le supprimer avant de déposer le deuxième ZIP contenant uniquement le XLSX à sa place. Cela pourrait bien sûr échouer si l'utilisateur a enregistré le ZIP d'origine dans un emplacement différent ou sous un nom différent, mais dans la plupart des cas, il devrait atterrir automatiquement dans le dossier des téléchargements de l'utilisateur.
Cette capture d'écran montre dans le panneau inférieur le dossier temporaire créé dans appdata\local\temp contenant la XLL et le XLSX déposé, tandis que le panneau supérieur montre la fenêtre originale de l'Explorateur de fichiers à partir de laquelle la XLL a été ouverte. Remarquez dans le panneau inférieur que la XLL a une taille de 0. C'est parce qu'elle s'est supprimée lors de l'exécution, mais jusqu'à ce que le panneau supérieur soit fermé, le fichier XLL ne disparaîtra pas complètement de l'emplacement appdata\local\temp. Même si la victime clique à nouveau sur la XLL, elle est désormais inerte et n'existe pas vraiment.
De même, dès que la victime quitte le ZIP ouvert dans l'Explorateur de fichiers (en le fermant ou en naviguant vers un autre dossier), si elle clique à nouveau sur spreadsheet.zip, elle trouvera maintenant que le dossier test contient importantdoc.xlsx ; ainsi la XLL a été supprimée et remplacée par le XLSX inoffensif dans les deux emplacements où elle existait sur le disque.
Ce GIF illustre le téléchargement et l'exécution de la XLL sur une machine virtuelle d'essai MDE. Notez que pour une raison quelconque, Excel ouvre deux instances ici ; sur mon ordinateur personnel, il n'en a ouvert qu'une, donc je ne sais pas exactement pourquoi cela diffère.
Comme toujours, nous demanderons "Que voit MDE ?"
Un petit dump de captures d'écran pour prouver que j'ai bien exécuté cela sur la cible et récupéré un beacon sur TestMachine11 :
D'abord, zéro alertes :
Que capture la chronologie/le journal des événements ?
Aïe. Pour être honnête, je n'ai aucune idée d'où viennent les alertes de keylogging, de chiffrement et de déchiffrement d'identifiants car mon code ne fait rien de tout cela. Nos actions semblent certainement suspectes présentées de cette façon, mais je vais à nouveau souligner la quantité de données collectées par MDE sur un seul point de terminaison, sans parler des centaines, milliers ou centaines de milliers qu'une organisation peut avoir connectés à l'EDR. Tant que nous ne déclenchons pas d'alertes réelles, nous sommes probablement en sécurité.
Le moment que la plupart attendent probablement, je fournis un exemple de code de mon exécuteur XLL développé, limité aux seules parties discutées ici dans la section Tradecraft. Il incombera au lecteur de réellement intégrer le code dans une XLL et de l'implémenter conjointement avec le reste de son exécuteur. Comme toujours, ne causez pas de dommages, ayez l'autorisation de phisher une organisation, etc.
J'ai inclus le code source d'un programme qui ingère un fichier et produit du hex qui peut être copié dans les tableaux d'octets définis dans l'extrait. Utilisez-le sur le XLSX que vous souhaitez présenter à l'utilisateur, ainsi que sur le fichier ZIP contenant le dossier qui contient ce même XLSX et stockez-les dans leurs tableaux d'octets respectifs. Compilez ce code en utilisant :``` gcc -o ingestfile ingestfile.c
J'ai eu quelques problèmes pour compiler mes XLL en utilisant MingW sur une machine Kali, donc j'ai pensé poster les commandes ici :
**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/
Après avoir compilé, vous voudrez créer un nouveau dossier et copier le XLL dans ce dossier. Ensuite, compressez-le en utilisant :```
zip -r <myzipname>.zip <foldername>/
Notez que pour que les techniques décrites dans cet article fonctionnent, vous devrez faire correspondre certaines variables dans l'extrait de code avec le nom que vous donnez au fichier XLL et au fichier zip.
Avec la fin de la domination des macros Office, les XLL présentent une option attrayante pour les campagnes de phishing. Avec un peu de créativité, ils peuvent être utilisés en conjonction avec d'autres techniques pour contourner de nombreuses couches de défenses mises en œuvre par les organisations et les équipes de sécurité. Merci d'avoir lu et j'espère que vous avez appris quelque chose d'utile !