Techniken, die sowohl Persistenz als auch laterale Bewegungen ermöglichen, sind in Microsoft Windows wieder aufgetaucht. Dabei wird eine seit Langem bestehende DLL-Hijacking-Schwachstelle im Barrierefreiheitstool Sprachausgabe ausgenutzt.
Das bereits 2013 erstmals dokumentierte Problem besteht in Windows 10 und 11 fort und ermöglicht es Angreifern mit lokalen Administratorrechten, beliebigen Code auszuführen, unauffällige Persistenz aufrechtzuerhalten und sich möglicherweise lateral in Netzwerken zu bewegen.
Die Forscher von TrustedSec stellten fest, dass die Angriffstechnik „… lokalen Administratorzugriff auf das System erfordert, das Sie manipulieren.“
Vom Hilfstool zur Hintertür
Barrierefreiheitstools wie die Sprachausgabe werden mit erweiterten Berechtigungen ausgeführt und können so konfiguriert werden, dass sie vor der Benutzeranmeldung gestartet werden. Bei missbräuchlicher Ausnutzung des Ladeverhaltens erhalten Angreifer dadurch einen Ausführungskontext mit hohen Berechtigungen.
Besonders bedenklich ist dies für Organisationen, die Fernadministration oder RDP-Zugriff erlauben, denn ein Angreifer, der in Systempfade schreiben oder Registrierungswerte bearbeiten kann, kann eine harmlose Assistenztechnologie in ein dauerhaftes Implantat verwandeln, das gängigen Endpoint-Schutzmaßnahmen entgeht.
Die jüngsten Tests von TrustedSec, die auf früheren Arbeiten von Hexacorn aus dem Jahr 2013aufbauen, bestätigten, dass moderne Windows-Versionen weiterhin versuchen, eine bestimmte DLL der Sprach-Engine aus dem Systemverzeichnis zu laden.
Die ausführbare Datei der Sprachausgabe sucht die DLL der Sprach-Engine im Pfad %windir%\system32\speech_onecore\engines\tts. Ersetzt ein Angreifer die DLL durch eine bösartige Datei mit dem erwarteten Dateinamen, kann er bei jedem Start der Sprachausgabe Code ausführen.
Unauffällige Persistenz über Barrierefreiheits-DLLs
Bei der Technik handelt es sich um klassisches DLL-Hijacking, bei dem eine vertrauenswürdige Anwendung eine Bibliothek anhand ihres Namens aus einem vorhersehbaren Verzeichnis lädt. Wird dieser Name durch eine bösartige DLL ersetzt, führt das System den Code des Angreifers aus.
In diesem Fall führt die Sprachausgabe Code aus, der in der Initialisierungsroutine der DLL abgelegt ist. Für die Ausführung der Payload sind daher keine exportierten Funktionen erforderlich.
Die Forscher sorgten für zusätzliche Tarnung, indem sie die injizierte DLL den Hauptthread der Sprachausgabe anhalten ließen. So wurden während der unsichtbaren Ausführung der Payload Sprachausgabe und Bildschirmausgaben unterbunden, die einen Benutzer andernfalls gewarnt hätten.
Persistenz lässt sich über die Registrierungskonfiguration erreichen.
Wird unter HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Accessibility ein REG_SZ-Wert namens configuration angelegt und auf Narrator gesetzt, startet das Barrierefreiheitstool bei der Benutzeranmeldung und lädt die bösartige DLL.
Dieselbe Registrierungsänderung unter HKEY_LOCAL_MACHINE etabliert dagegen Persistenz auf SYSTEM-Ebene und startet die Sprachausgabe mit erweiterten Berechtigungen am Anmeldebildschirm.
Über den Fernzugriff auf die Registrierung können Angreifer außerdem RDP-Einstellungen ändern, etwa den Schutz durch SecurityLayer deaktivieren, und die Sprachausgabe am Anmeldebildschirm mit der Tastenkombination Strg+Win+Eingabetaste auslösen. Dadurch werden Payloads während der RDP-Anmeldung als SYSTEM ausgeführt.
Die Forscher demonstrierten außerdem einen Ansatz nach dem Prinzip „Bring Your Own Accessibility“: Sie legten eigene Barrierefreiheitstools in der Registrierung an, die auf beliebige Binärdateien, einschließlich Netzwerk-UNC-Pfaden, verweisen, und banden diese Tools anschließend in denselben Konfigurationsmechanismus ein, damit sie bei der Anmeldung oder beim Systemstart ausgeführt werden.
Windows gegen Hijacking härten
Um das Risiko von DLL-Hijacking und Persistenz über Windows-Barrierefreiheitstools zu verringern, sollten Unternehmen ihre Maßnahmen zur Systemhärtung und Überwachung verstärken.
- Prinzip der geringstmöglichen Rechte durchsetzen: Die Zahl lokaler Administratorkonten begrenzen und unerwartete Schreibzugriffe auf Systemverzeichnisse überwachen.
- Registrierungsänderungen überwachen: Bei neuen oder geänderten Werten unter den Windows-Registrierungsschlüsseln für Barrierefreiheit in HKCU und HKLM Alarm auslösen.
- Schreibzugriff auf DLL-Ladepfade beschränken: Sicherstellen, dass %windir%\system32\speech_onecore\engines\tts und zugehörige Verzeichnisse nur von Administratoren beschrieben werden können.
- Anwendungs-Allowlisting einsetzen: Nicht autorisierte DLLs und ausführbare Dateien mithilfe von Allowlisting-Lösungen blockieren.
- Fernadministration absichern: Den Fernzugriff auf die Registrierung beschränken sowie Änderungen an der RDP-Konfiguration und ungewöhnliches RDP-Anmeldeverhalten überwachen.
- Prozessinjektionen und das Anhalten von Threads erkennen: Eine hostbasierte Erkennung für Techniken einrichten, bei denen primäre Anwendungsthreads angehalten werden, während unbekannter Code ausgeführt wird.
Mit diesen Maßnahmen lässt sich die Fähigkeit von Angreifern einschränken, Barrierefreiheitsfunktionen für Persistenz oder eine Rechteausweitung auszunutzen. Durch die Kombination strenger Zugriffskontrollen, kontinuierlicher Überwachung und Allowlisting können Unternehmen gängige DLL-Hijacking-Vektoren schließen und die Sicherheit ihrer Endpoints insgesamt verbessern.
Alte Funktionen, neue Risiken
Die erneute Aufmerksamkeit für eine alte Technik unterstreicht eine anhaltende Wahrheit in der Cybersicherheit: Legacy-Funktionen und Komfortfunktionen überleben häufig die ursprünglichen Sicherheitsannahmen, auf denen sie basierten.
Bedrohungsakteure nutzen weiterhin vertrauenswürdige Systemkomponenten – etwa Barrierefreiheitstools, geplante Aufgaben und gängige DLL-Pfade – um der Erkennung zu entgehen und Persistenz aufrechtzuerhalten.
Diese Entwicklung müssen Verteidiger bekämpfen, indem sie Legacy-Funktionen genauso kritisch prüfen wie neuen Code und Prinzipien der geringstmöglichen Rechte, der kontinuierlichen Überwachung sowie des sicheren Designs durchsetzen, die davon ausgehen, dass jede Funktion eines Tages missbraucht werden könnte. Dieser Wandel unterstreicht die Notwendigkeit von
Zero-Trust-Tools, die nach dem Prinzip arbeiten, dass kein Benutzer, kein Gerät und kein Prozess ohne kontinuierliche Überprüfung von vornherein vertrauenswürdig sein sollte.