XLL-Phishing-Taktiken
Mit der jüngsten Ankündigung von Microsoft bezüglich der Blockierung von Makros in Dokumenten, die aus dem Internet stammen (E-Mail UND Web-Download), haben Angreifer begonnen, aggressiv andere Optionen zu erkunden, um einen benutzergesteuerten Zugriff (UDA) zu erreichen. Bei der Suche nach einer praktikablen Phishing-Methode für den Zugriff sind mehrere Überlegungen abzuwägen und auszubalancieren:
Dies sind die wichtigsten Fragen, es gibt jedoch sicherlich noch mehr. Die Dinge werden komplexer, wenn man erkennt, dass sich diese Faktoren gegenseitig verstärken; wenn ein Kunde beispielsweise einen Web-Proxy hat, der das Herunterladen von ausführbaren Dateien oder DLLs verbietet, müssen Sie Ihr Payload möglicherweise in einen Container (ZIP, ISO usw.) packen. Das kann später bei der Erkennung zu weiteren Problemen führen. Robustere Abwehrmaßnahmen erfordern komplexere Kombinationen von Techniken, um sie zu überwinden.
Dieser Artikel wird mit einer fiktiven Zielorganisation im Hinterkopf geschrieben; diese Organisation hat mehrere defensive Maßnahmen ergriffen, darunter E-Mail-Filterregeln, das Blockieren bestimmter Dateitypen beim Herunterladen, Anwendungszulassungslisten auf Endpunkten und Microsoft Defender for Endpoint als EDR-Lösung.
Reale Organisationen beschäftigen möglicherweise keine, einige oder sogar noch mehr Abwehrmaßnahmen, was die in dieser Forschung dargelegten Techniken vereinfachen oder verkomplizieren kann. Wie immer: Kennen Sie Ihr Ziel.
XLLs sind DLLs, die speziell für Microsoft Excel entwickelt wurden. Für das ungeübte Auge sehen sie wie normale Excel-Dokumente aus.
XLLs bieten eine sehr attraktive Option für UDA, da sie von Microsoft Excel ausgeführt werden, einer sehr häufig in Kundennetzwerken vorkommenden Software; ein zusätzlicher Bonus: Da sie von Excel ausgeführt werden, umgeht unser Payload mit ziemlicher Sicherheit die Anwendungszulassungslisten, da eine vertrauenswürdige Anwendung (Excel) sie ausführt. XLLs können in C, C++ oder C# geschrieben werden, was eine wesentlich größere Flexibilität und Leistungsfähigkeit (und Übersichtlichkeit) als VBA-Makros bietet, was sie noch wünschenswerter macht.
Der Nachteil ist natürlich, dass es nur sehr wenige legitime Anwendungen für XLLs gibt, daher sollte es für Organisationen sehr einfach sein, das Herunterladen dieser Dateierweiterung sowohl per E-Mail als auch per Web-Download zu blockieren. Leider sind viele Organisationen Jahre hinter der Kurve, sodass XLLs noch einige Zeit eine brauchbare Phishing-Methode darstellen werden.
Es gibt eine Reihe verschiedener Ereignisse, die zur Codeausführung innerhalb einer XLL verwendet werden können, das bekannteste ist xlAutoOpen. Die vollständige Liste kann hier eingesehen werden:
Nach einem Doppelklick auf eine XLL wird der Benutzer mit diesem Bildschirm begrüßt:
Dieses einzelne Dialogfeld ist alles, was zwischen dem Benutzer und der Codeausführung steht; mit relativ dünnem Social Engineering ist die Codeausführung so gut wie sicher.
Ein wichtiger Punkt, den man beachten muss: XLLs sind als ausführbare Dateien architekturspezifisch. Das bedeutet, dass Sie Ihr Ziel kennen müssen; die Version von Microsoft Office/Excel, die die Zielorganisation verwendet, bestimmt (normalerweise), für welche Architektur Sie Ihr Payload erstellen müssen.
Es gibt einen ziemlich klaren Bruch in den Office-Versionen, der als Faustregel verwendet werden kann:
Office 2016 oder älter: x86
Office 2019 oder neuer: x64
Es sollte beachtet werden, dass es möglich ist, die jeweils andere Architektur für jedes Produkt zu installieren, jedoch sind dies die standardmäßig installierten Architekturen, und in den meisten Fällen sollte dies eine zuverlässige Entscheidungsgrundlage dafür sein, für welche Architektur Sie Ihre XLL erstellen. Je nach Zustellungsmethode und Vorwand, der im Rahmen der Phishing-Kampagne verwendet wird, ist es natürlich möglich, beide Versionen bereitzustellen und darauf zu vertrauen, dass das Opfer die für sein System geeignete Version auswählt.
Das XLL-Payload, das während dieser Forschung erstellt wurde, basierte auf diesem Projekt von edparcell. Sein Repository enthält gute Anleitungen für den Einstieg mit XLLs in Visual Studio, und ich habe seinen Code als Ausgangspunkt verwendet, um eine bösartige XLL-Datei zu entwickeln.
Eine nennenswerte Abweichung von seinem Repository ist, dass Sie, falls Sie Ihr eigenes XLL-Projekt erstellen möchten, das neueste Excel SDK herunterladen und dann den Anweisungen des zuvor verlinkten Repos folgen müssen, wobei Sie diese Version anstelle der in der README erwähnten SDK-Version von 2010 verwenden.
Die Zustellung des Payloads ist im Kontext von UDA eine ernstzunehmende Überlegung. Wir werden uns auf zwei primäre Methoden konzentrieren:
Entweder durch Anhängen einer Datei oder durch Einfügen eines Links zu einer Website, von der eine Datei heruntergeladen werden kann, ist E-Mail ein kritischer Teil des UDA-Prozesses. Im Laufe der Jahre haben viele Organisationen (und E-Mail-Anbieter) ihre Maßnahmen ausgebaut und Regeln durchgesetzt, um Benutzer und Organisationen vor bösartigen Anhängen zu schützen. Die Erfolge variieren, aber Organisationen haben jetzt die Möglichkeit:
Das Austesten der E-Mail-Regeln einer Organisation kann ein wichtiger Teil eines Engagements sein, jedoch muss immer darauf geachtet werden, nicht zu verraten, dass ein Red-Team-Einsatz läuft und aktiv Informationen gesammelt werden.
Für die Zwecke dieses Artikels wird angenommen, dass die Zielorganisation robuste E-Mail-Anhangsregeln hat, die die Zustellung eines XLL-Payloads verhindern. Wir werden umschwenken und uns die Web-Zustellung ansehen.
E-Mail wird in diesem Angriffsvektor weiterhin verwendet, jedoch wird sie anstelle eines Anhangs verwendet, um einen Link zu einer Website zu senden. Web-Proxy-Regeln und Netzwerk-Maßnahmen, die die erlaubten Datei-Download-Typen kontrollieren, können sich von denen unterscheiden, die für E-Mail-Anhänge gelten. Für die Zwecke dieses Artikels wird angenommen, dass die Organisation das Herunterladen von ausführbaren Dateien (MZ-Header) aus dem Web verhindert. In diesem Fall lohnt es sich, Packer/Container zu erkunden.
Die Grundidee ist, dass wir unsere ausführbare Datei möglicherweise in einen anderen Dateityp verpacken und an den Richtlinien der Organisation vorbeischmuggeln können. Eine wichtige Überlegung hierbei ist die native Unterstützung für den Dateityp; 7Z-Dateien beispielsweise können von Windows nicht geöffnet werden, ohne Drittanbieter-Software zu installieren, daher sind sie keine gute Wahl. Formate wie ZIP, ISO und IMG sind attraktive Optionen, da sie nativ von Windows unterstützt werden, und als zusätzlicher Bonus fügen sie dem Opfer nur sehr wenige zusätzliche Schritte hinzu.
Die Organisation blockiert leider das Herunterladen von ISO- und IMG-Dateien aus dem Web; darüber hinaus können Benutzer aufgrund von Data Loss Prevention (DLP) keine externen Speichergeräte einbinden, zu denen ISO- und IMG-Dateien gezählt werden.
Glücklicherweise erlaubt die Organisation, obwohl sie das Herunterladen von MZ-Header-Dateien verhindert, das Herunterladen von Zip-Dateien, die ausführbare Dateien enthalten. Diese Zip-Dateien werden aktiv auf Malware gescannt, einschließlich der Aufforderung an den Benutzer, das Passwort für passwortgeschützte Zip-Dateien einzugeben; da die ausführbare Datei jedoch gezippt ist, wird sie nicht von der ansonsten pauschalen Ablehnung von MZ-Dateien blockiert.
Zip-Dateien wurden als Container für unser XLL-Payload ausgewählt, weil:
Praktischerweise öffnet ein Doppelklick auf eine ZIP-Datei unter Windows diese Zip-Datei im Datei-Explorer:
Weniger praktisch: Ein Doppelklick auf die XLL-Datei aus dem gezippten Speicherort löst Windows Defender aus; selbst mit dem Standardprojekt von edparcell, das keinerlei bösartigen Code enthält.
Betrachtet man die Windows Defender-Warnung, so handelt es sich nur um eine allgemeine "Wacatac"-Warnung:
Jedoch gibt es etwas Merkwürdiges; die als bösartig identifizierte Datei befand sich in c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip, nicht in C:\users\user\Downloads\ZippedXLL, wo wir sie doppelgeklickt haben. Ein Blick auf die Excel-Instanz im ProcessExplorer zeigt, dass Excel die XLL tatsächlich aus appdata\local\temp ausführt, nicht aus der ZIP-Datei, in der sie kam:
Dies scheint eine Eigenheit von ZIP-Dateien zu sein, nicht von XLLs. Das Öffnen einer TXT-Datei aus einer Zip heraus mit Notepad führt ebenfalls dazu, dass die TXT-Datei nach appdata\local\temp kopiert und von dort geöffnet wird. Während das Öffnen einer Textdatei von diesem Speicherort in Ordnung ist, scheint Defender jede Art von tatsächlicher Codeausführung an diesem Ort als bösartig zu identifizieren.
Wenn ein Benutzer die XLL aus der ZIP-Datei extrahieren und dann ausführen würde, würde sie ohne Probleme ausgeführt; aber es gibt keine Möglichkeit zu garantieren, dass ein Benutzer dies tut, und wir können wirklich nicht auf das Glück hoffen, AV/EDR auszulösen, falls er sie nicht extrahiert. Außerdem ist es viel einfacher, auf die ZIP zu doppelklicken und dann auf die XLL zu doppelklicken, und ein Opfer wird diese einfachen Aktionen eher vollständig ausführen, als sich die Mühe zu machen, die ZIP zu extrahieren.
Dieses Problem brachte mich dazu, über einen anderen Payload-Typ als XLL nachzudenken; ich begann, VSTOs zu erkunden, das sind Visual Studio-Vorlagen für Office. Ich empfehle Ihnen dringend, diesen Artikel zu lesen.
VSTOs rufen letztendlich eine DLL auf, die entweder lokal zusammen mit der .XLSX-Datei, die alles initiiert, gespeichert oder remote gehostet und von der .XLSX über http/https heruntergeladen werden kann. Die lokale Option bietet keine wirklichen Vorteile (und tatsächlich mehrere Nachteile, da mit einem VSTO-Angriff mehrere Dateien verbunden sind), und die Remote-Option erfordert leider ein Code-Signing-Zertifikat oder dass der entfernte Standort ein vertrauenswürdiges Netzwerk ist. Da wir kein gültiges Code-Signing-Zertifikat haben, mildern VSTOs keines der Probleme in diesem Szenario, auf die unser XLL-Payload stößt.
Wir scheinen wirklich in einer Sackgasse zu stecken. Das Ausführen der XLL selbst ist in Ordnung, aber die XLL kann dem Opfer weder per E-Mail-Anhang noch per Web-Download direkt zugestellt werden, aufgrund der Unternehmensrichtlinie. Die XLL muss in einen Container verpackt werden, aber aufgrund von DLP sind Formate wie ISO, IMG und VHD nicht brauchbar. Das Opfer muss den Container nativ ohne Drittanbieter-Software öffnen können, was ZIP als Option übrig lässt; aber wie bereits besprochen, führt das Ausführen der XLL aus einem gezippten Ordner dazu, dass sie nach appdata\local\temp kopiert und von dort ausgeführt wird, was AV auslöst.
Ich habe viele Stunden damit verbracht, Ideen zu sammeln und Dinge zu testen, bin das VSTO-Kaninchenloch hinuntergegangen, habe alle denkbaren Optionen erkundet, bis ich schließlich beschloss, etwas so Dummes zu versuchen, dass es vielleicht funktioniert.
Dieses Mal erstellte ich einen Ordner, legte die XLL hinein und zippte dann den Ordner:
Ein Klick in den Ordner zeigt die XLL-Datei:
Ein Doppelklick auf die XLL zeigt die Add-In-Eingabeaufforderung von Excel. Beachten Sie, dass die XLL immer noch nach appdata\local\temp kopiert wird, jedoch gibt es eine zusätzliche Ebene aufgrund des zusätzlichen Ordners, den wir erstellt haben:
Ein Klick auf "Aktivieren" führt unseren Code aus, ohne Defender auszulösen:
Prima! Codeausführung. Was nun?
Die Vorwände, die verwendet werden, um ein Opfer zum Herunterladen und Ausführen der XLL zu bewegen, variieren stark je nach Organisation und Zustellungsmethode; Themen könnten Gehaltsdaten von Mitarbeitern, Berechnungstools für die Vergütung basierend auf Qualifikationen, Informationen zu einem Projekt, eine Teilnehmerliste für eine Veranstaltung usw. sein. Was auch immer der Köder ist, unser Angriff wird viel effektiver sein, wenn wir dem Opfer tatsächlich das geben, was ihm versprochen wurde. Ohne Nachverfolgung könnten Opfer misstrauisch werden und das Dokument ihren Sicherheitsteams melden, was den Angreifer schnell verraten und den Zugriff auf das Zielsystem einschränken kann.
Die XLL allein hinterlässt nach Abschluss unseres Codes nur ein leeres Excel-Fenster; es wäre viel besser für uns, die Excel-Tabelle bereitzustellen, nach der das Opfer sucht.
Wir können unser XLSX als Byte-Array in der XLL einbetten; wenn die XLL ausgeführt wird, legt sie das XLSX neben der XLL auf der Festplatte ab, woraufhin es geöffnet wird. Wir benennen das XLSX genauso wie die XLL, der einzige Unterschied ist die Erweiterung.
Da unsere XLL in C geschrieben ist, können wir einige der Fähigkeiten aus einem früheren Artikel von mir über Payload-Fähigkeiten in C einbringen, nämlich die Selbstlöschung. Die Kombination dieser beiden Techniken führt dazu, dass die XLL von der Festplatte gelöscht wird und das XLSX mit demselben Namen an ihrer Stelle abgelegt wird. Für das ungeübte Auge scheint es, als wäre das XLSX die ganze Zeit dort gewesen.
Leider ist der Ort, an dem die XLL gelöscht und das XLSX abgelegt wird, der appdata\temp\local-Ordner, nicht das ursprüngliche ZIP; um dies zu beheben, können wir ein zweites ZIP erstellen, das nur das XLSX enthält, und es ebenfalls als Byte-Array in die XLL einlesen. Bei der Ausführung könnte die XLL zusätzlich zu den genannten Aktionen versuchen, die ursprüngliche ZIP-Datei in c:\users\victim\Downloads\ zu lokalisieren und zu löschen, bevor sie das zweite ZIP mit nur dem XLSX an ihrer Stelle ablegt. Dies könnte natürlich fehlschlagen, wenn der Benutzer die ursprüngliche ZIP an einem anderen Ort oder unter einem anderen Namen gespeichert hat, jedoch sollte sie in den meisten Fällen automatisch im Downloads-Ordner des Benutzers landen.
Dieser Screenshot zeigt im unteren Bereich den in appdata\local\temp erstellten temporären Ordner mit der XLL und dem abgelegten XLSX, während der obere Bereich das ursprüngliche Datei-Explorer-Fenster zeigt, aus dem die XLL geöffnet wurde. Beachten Sie im unteren Bereich, dass die XLL die Größe 0 hat. Dies liegt daran, dass sie sich während der Ausführung selbst gelöscht hat, jedoch wird die XLL-Datei erst vollständig aus dem appdata\local\temp-Speicherort verschwinden, wenn der obere Bereich geschlossen wird. Selbst wenn das Opfer erneut auf die XLL klicken würde, ist sie jetzt inert und existiert nicht wirklich.
Wenn das Opfer das geöffnete ZIP im Datei-Explorer verlässt (entweder durch Schließen oder Navigieren zu einem anderen Ordner) und dann erneut auf spreadsheet.zip klickt, wird es jetzt feststellen, dass der test-Ordner importantdoc.xlsx enthält; die XLL wurde also an beiden Stellen, an denen sie auf der Festplatte existierte, entfernt und durch das harmlose XLSX ersetzt.
Dieses GIF demonstriert das Herunterladen und Ausführen der XLL auf einer MDE-Test-VM. Beachten Sie, dass Excel hier aus irgendeinem Grund zwei Instanzen öffnet; auf meinem Heimcomputer öffnete es nur eine, daher bin ich mir nicht ganz sicher, woran der Unterschied liegt.
Wie immer fragen wir: "Was sieht MDE?"
Ein schneller Screenshot-Dump als Beweis, dass ich dies tatsächlich auf dem Ziel ausgeführt und einen Beacon auf TestMachine11 zurückerhalten habe:
Zunächst einmal: null Warnungen:
Was erfasst die Zeitleiste/das Ereignisprotokoll?
Huch. Um ehrlich zu sein, habe ich keine Ahnung, woher die Warnungen zu Keylogging, Verschlüsselung und Entschlüsselung von Anmeldeinformationen kommen, da mein Code nichts davon tut. Unsere Aktionen sehen sicherlich verdächtig aus, wenn sie so dargestellt werden, aber ich möchte noch einmal darauf hinweisen, wie viele Daten von MDE auf einem einzelnen Endpunkt gesammelt werden, geschweige denn auf Hunderten, Tausenden oder Hunderttausenden, die eine Organisation an das EDR angeschlossen haben könnte. Solange wir keine tatsächlichen Warnungen auslösen, sind wir wahrscheinlich in Ordnung.
Der Moment, auf den die meisten wahrscheinlich gewartet haben: Ich stelle ein Codebeispiel meines entwickelten XLL-Runners zur Verfügung, beschränkt auf die Teile, die hier im Abschnitt "Taktik" besprochen wurden. Es liegt am Leser, den Code tatsächlich in eine XLL zu integrieren und ihn in Verbindung mit dem Rest seines Runners zu implementieren. Wie immer: Fügen Sie keinen Schaden zu, haben Sie die Erlaubnis, eine Organisation zu phishieren usw.
Ich habe den Quellcode für ein Programm beigefügt, das eine Datei einliest und Hex ausgibt, der in die im Ausschnitt definierten Byte-Arrays kopiert werden kann. Verwenden Sie dies für das XLSX, das Sie dem Benutzer präsentieren möchten, sowie für die ZIP-Datei, die den Ordner mit diesem selben XLSX enthält, und speichern Sie sie in ihren jeweiligen Byte-Arrays. Kompilieren Sie diesen Code mit:``` gcc -o ingestfile ingestfile.c
Ich hatte einige Probleme, meine XLLs mit MingW auf einer Kali-Maschine zu kompilieren, also dachte ich, ich poste die Befehle hier:
**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/
Nachdem Sie kompiliert haben, möchten Sie einen neuen Ordner erstellen und die XLL in diesen Ordner kopieren. Dann zippen Sie es mit:```
zip -r <myzipname>.zip <foldername>/
Beachten Sie, dass für die in diesem Beitrag beschriebene Vorgehensweise zur Funktionsweise einige Variablen im Code-Snippet an die Namen der XLL- und ZIP-Datei angepasst werden müssen.
Da die Dominanz von Office-Makros zu Ende geht, stellen XLLs eine attraktive Option für Phishing-Kampagnen dar. Mit etwas Kreativität können sie in Verbindung mit anderen Techniken eingesetzt werden, um viele Sicherheitsebenen zu umgehen, die von Organisationen und Sicherheitsteams implementiert wurden. Vielen Dank fürs Lesen und ich hoffe, Sie haben etwas Nützliches gelernt!