RemoteMonologue: DCOM als Waffe für NTLM-Authentifizierungszwang

Die Zeiten, in denen man mit Mimikatz mühelos Zugangsdaten erwerben konnte, gehen wohl oder übel zu Ende. Wenn Microsoft die Verteidigung gegen den Diebstahl von Zugangsdaten verstärkt und Endpoint Detection and Response (EDR)-Lösungen weiterentwickelt, geraten traditionelle Red-Team-Techniken wie Lateralbewegung, Payload-Ausführung und direkter Zugriff auf den Local Security Authority Subsystem Service (LSASS) unter zunehmende Beobachtung. Infolgedessen war die Red Team-Community gezwungen, alternative Methoden zu erkunden, um Zugangsdaten auf Windows-Systemen zu sammeln.

Stellen Sie sich vor, Sie könnten vergleichbare Ergebnisse erzielen, ohne dass Sie eine „erweiterte“ Nutzlast oder einen Zugriff auf LSASS benötigen, indem Sie einfach mit dem arbeiten, was da ist, und nicht ausgelastete COM-Objekte (Component Object Model) nutzen. Wenn dich das begeistert, bleib dran, denn dieser Blog steckt voller lustiger Tricks, die du bei deinem nächsten Engagement anwenden kannst.

Wir werden kurz die Grundlagen von COM und seinem verteilten Gegenstück, dem Distributed Object Model der Komponenten (DCOM), behandeln, uns mit der RunAs-Einstellung und den Auswirkungen von Authentifizierungsumwandlungen befassen und ein neues Tool zum Sammeln von Zugangsdaten vorstellen – RemoteMonologue.

Das Komponenten-Objektmodell (COM) ist eine der ältesten und am weitesten verbreiteten Technologien in Windows und arbeitet still und leise hinter den Kulissen alltäglicher Anwendungen und Dienste. Trotz seines Alters ist COM nach wie vor eine wertvolle Ressource für Angreifer, da es alternative Möglichkeiten bietet, laterale Bewegungen, Rechteeskalation und Persistenz zu erreichen. Dennoch hat seine inhärente Komplexität dazu geführt, dass ein Großteil seiner Angriffsfläche untererforscht ist.

Für diesen Blog sind folgende Schlüsselbegriffe wichtig:

• COM: Eine Kerntechnologie von Windows, die es Softwarekomponenten ermöglicht, über Prozessgrenzen hinweg miteinander zu interagieren. COM ermöglicht es Programmen, Funktionen aus anderen Programmen wiederzuverwenden, ohne diese zu duplizieren. Ein Programm könnte beispielsweise ein COM-Objekt verwenden, um Systemprotokolle auszulesen oder neue Einträge zu einer Excel-Datei hinzuzufügen, ohne diese Funktionen selbst zu implementieren.
• Verteiltes Komponentenobjektmodell (DCOM) Eine Erweiterung von COM, die netzwerkbasierte Kommunikation ermöglicht. Mit DCOM kann ein Prozess, der auf einer Maschine läuft, Funktionen auf einem COM-Objekt aufrufen, das sich auf einer anderen Maschine befindet. Diese netzwerkbasierte Fähigkeit hat DCOM zu einem wertvollen Tool für Lateralbewegung gemacht. Für den Zugriff auf DCOM-Objekte sind in der Regel lokale Administratorrechte auf dem Remote-System erforderlich.

Im Prinzip kann man sich COM-Objekte als in sich geschlossene Einheiten mit zwei Hauptkomponenten vorstellen:

• Eigenschaften: Diese stellen den Zustand oder die Konfiguration des Objekts dar.
• Methoden: Diese stellen Aktionen dar, die das Objekt ausführen kann. Ein COM-Objekt könnte beispielsweise eine Methode besitzen, um einen Prozess zu starten, eine Datei zu erstellen oder eine Authentifizierungsanforderung zu initiieren.

Angreifer können diese Methoden missbrauchen, um eine Lateralbewegung zu erleichtern und, wie wir in Kürze zeigen werden, entfernte NTLM-Authentifizierungen für Passwort-Cracking- und Relay-Angriffe zu erzwingen.

Bevor wir uns auf die unterhaltsamen Dinge einlassen, muss eine wichtige Komponente von COM näher besprochen werden. Ein Anwendungs-Identifikator (AppID) in COM dient als Schlüsselmechanismus zur Verwaltung der Sicherheit, Identität und Laufzeitverhaltens von COM-Anwendungen, insbesondere in Szenarien mit DCOM oder Anwendungen, die spezielle Sicherheitskontexte erfordern. Wenn eine COM-Klasse mit einer AppID registriert wird, erbt sie die für diese AppID definierten Sicherheitseinstellungen.

Die besonders interessante Sicherheitseinstellung ist der RunAs-Schlüssel , der angibt, welches Benutzerkonto bei der Instanziierung ein DCOM-Objekt ausführen soll. Den RunAs-Schlüssel finden Sie in der Registrierung unter:

• HKEY_CLasseS_ROOT\AppID\{AppID_GUID}

Beim Durchsehen von Microsofts Dokumentation zu DCOM und dem RunAs-Schlüssel fiel ein besonderer Wert auf: Interaktiver Benutzer. Dieser Wert konfiguriert das DCOM-Objekt so, dass es unter dem Sicherheitskontext des aktuell in der System-Konsolensitzung angemeldeten Benutzers ausgeführt wird. Aus offensiver Sicht ist dies interessant, da es uns ermöglichen könnte, DCOM-Objekte zu nutzen, um als ein anderer Benutzer zu agieren, ohne die Zugangsdaten des betroffenen Benutzers zu kennen.

Nicht alle DCOM-Objekte mit einer AppID haben einen RunAs-Wert auf Interactive User gesetzt. Tatsächlich ist bei etwa der Hälfte der AppIDs überhaupt kein RunAs-Wert gesetzt. Was aber, wenn der Wert von RunAs hinzugefügt oder so angepasst werden könnte, dass er unseren Zwecken entspricht?

Standardmäßig wird eine AppID im Register mit einer Discretionary Access Control List (DACL) gesichert, die TrustedInstaller Eigentumsrechte gewährt und lokale Administratoren auf Schreibzugriff beschränkt, wie in Abbildung 1 dargestellt.

Lokale Administratoren erhalten jedoch das SeTakeOwnershipPrivilege-Privileg , das es ihnen erlaubt, Systemobjekte, einschließlich Registrierungsschlüssel, zu übernehmen. Dieses Privileg ist für diesen Angriff relevant, da es uns ermöglicht, den Besitz einer AppID zu ändern. Sobald der Besitz geändert wurde, können wir uns Full Control Berechtigungen über die AppID erteilen und anschließend deren Einstellungen anpassen, um den RunAs-Wert hinzuzufügen oder zu ändern.

Sobald der RunAs-Wert auf Interaktiver Benutzer geändert wurde, wird der Angriff unkompliziert. Dadurch können wir ein DCOM-Objekt im Kontext einer anderen aktiven Sitzung ausführen lassen. Der Erfolg dieses Angriffs hängt jedoch letztlich von den Eigenschaften und Methoden ab, die das betreffende DCOM-Objekt offenlegt.

Nachdem wir nun wissen, dass es möglich ist, ein DCOM-Objekt in ein Session-Hijacking-Tool umzuwandeln, besteht der nächste Schritt darin, die Methoden und Eigenschaften zu identifizieren, die genutzt werden können, um den Hijack durchzuführen. Im Rahmen dieser Forschung habe ich geprüft, ob eine Kompromittierung des Nutzers ohne Ausführung einer Payload erreicht werden kann – ein anderer Ansatz als die meisten öffentlichen DCOM-Techniken zur Lateralbewegung.

Ich habe mich darauf konzentriert, vergleichbare Ergebnisse in einem „dateilosen“ Format zu erzielen, was bedeutet, dass keine Nutzdaten auf das Zielsystem übertragen oder ausgeführt werden müssen. Diese Unterscheidung ist wichtig, da das Übertragen und Ausführen von Nutzdaten auf einem Zielsystem bei Red-Team-Operationen oft als „teure“ Maßnahme angesehen wird. Durch den Wegfall dieses Schritts wird das Risiko der Auslösung gängiger Sicherheitskontrollen erheblich verringert. Daher war es mein Ziel, die Konten entfernter Benutzer durch Erzwingen einer NTLM-Authentifizierung über DCOM zu kompromittieren.

Die erzwungene NTLM-Authentifizierung bietet gegenüber herkömmlichen Lateral-Movement-Techniken mehrere entscheidende Vorteile:

• Erfassen Sie NTLMv1/NTLMv2-Hashes und versuchen Sie, diese offline zu knacken.
• Leiten Sie NTLMv1- oder WebDAV NTLMv2-Hashes an andere Netzwerkdienste wie LDAP oder SMB weiter, um Aktionen als der betroffene Benutzer auszuführen
• Vermeiden Sie es, eine Nutzlast auf das Zielsystem zu übertragen und dort auszuführen, was in der Regel eine genauere Prüfung durch Sicherheitstools nach sich zieht.
• Vermeiden Sie jegliche Berührung des LSASS-Prozesses, um die Erkennungsrisiken zu verringern.

Zum Zeitpunkt der Erstellung dieses Artikels sind LDAP-Signierung und Kanalbindung nicht erforderlich und werden auf den meisten Domain-Controllern standardmäßig durchgesetzt. Diese Sicherheitsfunktionen sind nur auf Windows Server 2025 verpflichtend. Das heißt, wenn wir eine NTLMv1- oder WebDAV-Authentifizierung vom Zielsystem erzwingen können, können wir sie an LDAP weiterleiten und als der betroffene Benutzer Aktionen ausführen. Ebenso ist die SMB-Signatur auf Windows-Servern standardmäßig nicht erforderlich, mit Ausnahme von Domänencontrollern.

Ein weiterer wichtiger Aspekt ist, dass NTLMv1-Hashes mit Rainbow-Tabellen trivial geknackt werden können, die seit Dezember 2024 von Nic Losby öffentlich geteilt wurden. Diese Tabellen reduzieren den Zeit- und Arbeitsaufwand für die Wiederherstellung von NTLM-Zugangsdaten aus NTLMv1-Hashes drastisch. Um einen NTLMv1-Hash anstelle eines NTLMv2-Hashes zu erhalten, ändern wir den folgenden Registrierungsschlüssel auf dem Zielsystem:

• HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Wenn LmCompatibilityLevel auf einen Wert von 2 oder weniger gesetzt wird, wird das System gezwungen, für die Authentifizierung auf NTLMv1 zurückzugreifen. Diese Änderung ist mit lokalen Administratorrechten möglich und wird allgemein als „NetNTLMv1-Downgrade-Angriff“ bezeichnet.

Alternativ können wir eine WebDAV-Authentifizierung erfassen und an LDAP weiterleiten, da HTTP-basierte Authentifizierungen an diesen Dienst weitergeleitet werden können. Wenn der WebClient-Dienst nicht bereits mit privilegiertem Zugriff ausgeführt wird, können wir ihn per Fernzugriff auf dem Zielsystem aktivieren. Nach der Aktivierung können wir eine WebDAV-NTLM-Authentifizierung für unseren Listener erzwingen, indem wir den NetBIOS-Namen des Rechners im UNC-Pfad angeben. Einige Beispiele:

• \\MYHACKERBOX@80\giveme\creds.txt

Für weitere Informationen zu NTLM-Relay-Angriffen und den Protokollen, die an verschiedene Endgeräte weitergeleitet werden können, siehe die folgende Ressourcen hier.

Während meiner Forschung habe ich das ServerDataCollectorSet -DCOM-Objekt analysiert, das die CLSID {03837546-098B-11D8-9414-505054503030} enthält, um Methoden und Eigenschaften zu identifizieren, die für die Authentifizierung genutzt werden können. Eine Eigenschaft, die besonders auffiel, war DataManager, und glücklicherweise enthält dieses COM-Objekt eine Typbibliothek, in der seine Methoden und Eigenschaften detaillierter definiert sind.

Mit OleView.NET habe ich die Typbibliothek des ServerDataCollectorSet überprüft und festgestellt, dass die DataManager-Eigenschaft eine Extract-Methode enthält, die zwei Parameter erwartet:

1. CabFilename – Der Name einer CAB-Datei, die extrahiert werden soll.
2. DestinationPath – Der Pfad zur Extraktion des Inhalts der CAB-Datei.

Das Vorhandensein des CabFilename-Parameters war besonders interessant, da es die Möglichkeit nahelegte, einen UNC-Pfad bereitzustellen, der zu einer Netzwerk-Authentifizierungsaktion führen könnte.

Um diese Theorie zu testen, habe ich einen UNC-Pfad für den Parameter CabFilename angegeben, der auf mein System(172.22.164.58) zeigt laufender Responder, wie in Abbildung 4 gezeigt. Das Ergebnis? Erfolg! Wir konnten einen NTLMv2-Hash erfassen, wie in Abbildung 5 dargestellt.

Als Nächstes habe ich getestet, ob es möglich ist, Anmeldedaten eines anderen Benutzers auf einem entfernten System (172.22.166.170) zu erfassen, indem ich den RunAs-Schlüssel des ServerDataCollectorSet modifiziere. Um dies zu erreichen, habe ich die Remote-Registry verwendet. Dienst zum {03837503-098B-11D8-9414-505054503030} Hinzufügen des interaktiven Benutzerwerts für die AppID .

Nachdem ein anderer Benutzer im Zielsystem angemeldet war (in diesem Fall GALAXY\yoda), griff ich als GALAXY\Administrator auf das ServerDataCollectorSet DCOM-Objekt zu und führte die gleiche Extract- Methode aus, die in Abbildung 6 gezeigt wird. Wieder einmal konnte ich eine Authentifizierung erfolgreich abfangen; diesmal jedoch aus GALAXY\yoda, wie in Abbildung 7 gezeigt. Dies zeigt, dass die Änderung des RunAs-Schlüssels zu Interactive User uns ermöglicht, DCOM-Objekte zu nutzen, um Sitzungen anderer Nutzer zu kapern.

Dieser Angriffsfluss ist im untenstehenden Diagramm dargestellt.

Ein weiteres interessantes DCOM-Objekt, das für Authentifizierungszwang anfällig ist, ist FileSystemImage, das das CLSID- {2C941FC5-975B-59BE-A960-9A2A262853A5}besitzt. Dieses Objekt ist besonders einzigartig, da der Zwang einfach durch die Änderung einer Eigenschaft ausgelöst wird, anstatt eine Methode zu aktivieren – eine weniger verbreitete Technik bei DCOM-basierten Angriffen.

Die betreffende Eigenschaft ist WorkingDirectory, das standardmäßig auf den %TEMP%- Ordner des interaktiven Benutzers verweist. Durch die Änderung des WorkingDirectory-Werts in einen UNC-Pfad, der auf unseren Listener zeigt, ist es jedoch möglich, eine NTLMv2-Authentifizierung zu erfassen, wie in den Abbildungen 9 und 10 dargestellt.

Um die Fähigkeiten zur Sitzungsübernahme zu überprüfen, habe ich dies remote getestet, indem ich den RunAs-Schlüssel für die AppID {2C941FD1-975B-59BE-A960-9A2A262853A5} auf Interactive User gesetzt habe. Diese Konfiguration veranlasste das FileSystemImage DCOM-Objekt, im Sicherheitskontext des aktiven Benutzers auf dem Zielsystem ausgeführt zu werden. Und wie erwartet, konnte ich den NTLMv2-Hash für diesen Benutzer erfassen.

Diese Technik zeigt, dass Authentifizierungserzwingungen sowohl durch die Modifizierung von Eigenschaften als auch von Methoden erreicht werden können, wodurch die potenzielle Angriffsfläche von DCOM-Objekten erweitert wird.

Ein letztes DCOM-Objekt, das es wert ist, geteilt zu werden, ist UpdateSession, das die CLSID {4CB43D7F-7EEE-4906-8698-60DA1C38F2FE} hat. Bei der Durchsicht der Typbibliothek fiel die Methode AddScanPackageService besonders auf, da sie ein serviceName- Argument und, was noch interessanter war, ein scanFileLocation- Argument erforderte. Das Vorhandensein von scanFileLocation deutete darauf hin, dass es möglicherweise einen UNC-Pfad akzeptiert.

Beim Testen dieser Theorie haben wir erfolgreich eine NTLMv2-Authentifizierung erfasst, aber anstatt die Anmeldedaten des Benutzerkontos zu erhalten, erhielten wir die Anmeldedaten des Maschinenkontos, wie unten dargestellt.

Diese Erkenntnis ist besonders interessant, da das UpdateSession DCOM-Objekt selbst nach Hinzufügen eines RunAs-Schlüssels und Einstellung auf Interactive User weiterhin Netzwerkoperationen als Maschinenkonto durchführte. Warum passiert das? Die einfache Antwort lautet, dass das DCOM-Objekt selbst zwar im Sicherheitskontext des instanziierenden oder interaktiven Benutzers läuft, die Netzwerkoperationen jedoch von einem separaten Prozess durchgeführt werden: svchost.exe. Der UNC-Pfad wird an svchost.exe weitergegeben, das für diese Vorgänge immer das Konto SYSTEM verwendet. Daher hat die RunAs-Schlüsseleinstellung keinen Einfluss auf dieses Verhalten.

Obwohl der RunAs-Schlüssel keinen Einfluss auf das für Netzwerkoperationen verwendete Konto hat, ist das Erfassen der Anmeldeinformationen des Maschinenkontos für verschiedene Angriffsszenarien dennoch wertvoll:

1. Zugriff auf interessante DACL-Berechtigungen in Active Directory:
   Maschinenkonten (z. B. DOMAIN\MACHINE$) könnten Berechtigungen für bestimmte Objekte im Active Directory besitzen, die für die laterale Bewegung oder die Rechteausweitung nützlich sein können.
2. Silbertickets fälschen für zusätzliche Ausweichmöglichkeiten:
   Wir können den NTLM-Hash eines Maschinenkontos verwenden, um ein Silver Ticket zu fälschen, sodass wir jeden Benutzer im System nachahmen und Aktionen mit reduziertem Risiko der Erkennung ausführen können.

Dieser Angriff wurde als RemoteMonologue bezeichnet, da er ähnlich wie InternalMonologue funktioniert, mit dem entscheidenden Unterschied, dass er den Angriff aus der Ferne ausführt. Das Tool wurde in Python unter Verwendung der Impacket-Bibliothek entwickelt und automatisiert den Angriffsprozess.

RemoteMonologue bietet die Möglichkeit, eines der drei oben genannten DCOM-Objekte(-dcom) zu verwenden, um einen Authentifizierungszwang gegenüber einem bestimmten Listener(-auth-to) durchzuführen. Darüber hinaus verfügt es über ein Sprühmodul (-spray), um Zugangsdaten über mehrere Systeme hinweg zu validieren, mit dem zusätzlichen Nutzen, Zugangsdaten zu erfassen. Das Tool unterstützt auch einen NetNTLMv1-Downgrade-Angriff (-downgrade) und bietet die Option, den WebClient-Dienst zu aktivieren, um HTTP-Authentifizierungen zu ermöglichen (-webclient). Schließlich enthält das Tool ein Abfragemodul (-query), um Benutzer mit einer aktiven Sitzung auf dem Zielsystem aufzuzählen.

Nachfolgend ein Beispiel für die Ausführung von RemoteMonologue mit dem NetNTLMv1-Downgrade-Angriff unter Verwendung von Responder als Listener. Wenn keine DCOM-Option angegeben ist, verwendet das Tool standardmäßig das DCOM-Objekt ServerDataCollectorSet.

Nachfolgend ein weiteres Beispiel. Diesmal wird der Angriff mit dem FileSystemImage DCOM-Objekt ausgeführt und ermöglicht es dem WebClient-Service, eine HTTP-Authentifizierung zu erhalten, die dann über ntlmrelayx an LDAP weitergeleitet wird.

Zum Schutz vor und zur Erkennung der in diesem Blog beschriebenen Techniken können mehrere Präventions- und Erkennungsmaßnahmen ergriffen werden.

Vorbeugende Maßnahmen:

1. Aktivieren Sie LDAP-Signierung und Kanalbindung: Konfigurieren Sie die Erzwingung der LDAP-Signierung und die Kanalbindung auf Domänencontrollern, um den LDAP-Endgerät vor Relay-Angriffen zu schützen. Hinweis: Diese Einstellungen werden ab Windows Server 2025 standardmäßig erzwungen.
2. Upgrade auf die neuesten Windows-Versionen: Upgrade der Server auf Windows Server 2025 und Workstations auf Windows 11 Version 24H2, um NetNTLM-Downgrade-Angriffe zu mindern, da NTLMv1 in diesen Versionen entfernt wurde.
3. SMB-Signing erzwingen: SMB-Signing auf Windows-Servern aktivieren und erzwingen, um SMB-Relay-Angriffe zu verhindern.
4. Implementieren Sie strenge Passwortrichtlinien: Setzen Sie strenge Passwortanforderungen durch, um Angriffe zum Knacken von Passwörtern zu erschweren.

Erkennungsmöglichkeiten:

1. Überwachen Sie den Remote-Zugriff auf DCOM-Objekte: Verfolgen Sie den Zugriff auf die betroffenen DCOM-Objekte und ihre spezifischen Eigenschaften und Methoden, um ungewöhnliche Aktivitäten zu identifizieren.
2. Überwachung von Registry-Änderungen: Überwachen Sie Änderungen an den Registry-Schlüsseln RunAs und LmCompatibilityLevel.
3. WebClient-Dienstaktivität verfolgen: Überwachen Sie Fälle, in denen der WebClient-Dienst remote aktiviert wird, da dies zur Erleichterung von HTTP-basierten NTLM-Authentifizierungen verwendet wird.

Der RemoteMonologue-Angriff zeigt, wie untergenutzte DCOM-Objekte zu heimlichen, dateilosen Authentifizierungs-Zwangsangriffen eingesetzt werden können. Durch die Änderung spezifischer Eigenschaften und die Nutzung von Techniken wie NetNTLMv1 Downgrade können Angreifer Benutzerkonten kompromittieren und Rechte eskalieren, ohne Payloads bereitzustellen oder direkt auf sensible Prozesse wie LSASS zuzugreifen.

Durch die Fokussierung auf die Absicherung wichtiger Systeme, wie beispielsweise die Durchsetzung von LDAP-Signaturen und SMB-Signaturen sowie die Deaktivierung von Altlast-Protokollen wie NTLMv1, können die Verteidiger die Angriffsfläche erheblich reduzieren. Darüber hinaus kann eine robuste Überwachung von Änderungen an der Registrierung, DCOM-Aktivitäten und Änderungen am Remote-Service dazu beitragen, diese Techniken in einem frühen Stadium zu erkennen und ihre Auswirkungen zu mildern.