In einem Red Team Assessment kommt es häufig vor, dass man Administratorrechte auf einem einzelnen Windows-Server erlangt. Meistens geschieht dies durch Kompromittieren der Zugangsdaten eines Administrators des Servers, aber auch ein veraltetes Betriebssystem oder eine Sicherheitslücke in einer Anwendung auf dem Server sind häufige Gründe. Zunächst einmal ein kleiner Erfolg für uns als simulierte Angreifer (also Red Teamer), der uns aber nicht notwendigerweise weiter bringt auf unserem Weg zu kritischen Funktionen des Zielunternehmens. Nach der initialen Überprüfung der defensiven Kapazitäten des Server (also Identifizierung der Antiviren- und EDR-Systeme sowie der aktiven Härtungsmaßnahmen wie AppLocker oder Constrained Language Mode) erfolgt als nächstes das „Looting“ des Servers, also das Suchen nach für uns wertvollen Informationen. Ob nun das Auslesen von Zugangsdaten aus dem Arbeitsspeicher mit Mimikatz oder dem Suchen von Zugangsdaten in der Registry bzw. auf der Festplatte, verschiedenste Techniken helfen uns auf unserem weiteren Weg im internen Netzwerk.

Was jedoch, wenn wir auf dem Server keine nützlichen Informationen finden? Oder wir gerne mehr hätten? Eine Technik, die in dieser Situation sehr hilfreich sein kann, ist das Anlocken eines (interessanten, da mit vielen Rechten ausgestatteten) Administrators auf den Server, z.B. per internem Phishing („Hi {admin}, die Anwendung auf dem Server xyz macht Probleme, kannst du mal kurz schauen was da los ist?“) oder durch tatsächliches Auslösen eines Fehlers auf dem Server bzw. in der Anwendung. Sobald sich das Opfer auf dem Server einloggt, idealerweise per RDP, können wir versuchen seine Zugangsdaten zu stehlen.

Klassisches Keylogging ist nun aber aus verschiedener Hinsicht für uns als Red Team problematisch: Zunächst einmal produziert es unter Umständen eine Menge unstrukturierter Daten, und das Heraussuchen von eingegebenen Zugangsdaten ist deshalb häufig aufwendig. Auch werden in der Regel alle Tastaturanschläge aufgezeichnet, was unter Umständen Persönlichkeits- oder Datenschutzrechtsverstöße verursachen kann. Auch die Frage „Wohin mit den ganzen Daten?“ ist nicht trivial gelöst: jeden Tastaturanschlag an unseren C2-Server zu senden produziert eine Menge auffälliger Kommunikation, das Abspeichern auf der Festplatte hinterlässt jedoch auch Spuren (und, falls unverschlüsselt, kann das Ergebnis von anderen Nutzern eingesehen werden).

In der Regel kann man nach erfolgter Anmeldung eines Administrators zwar zumindest seine Kerberos Session Keys / den NT-Hash, sowie das Ticket Granting Ticket auslesen und diese für (Over-)Pass-the-Hash (PtH) oder Pass-the-Ticket (PtT) nutzen, aber für uns ist es deutlich praktischer und vor allem auch weniger auffällig, wenn wir Zugriff auf das Klartextpasswort bekommen. Auf modernen Windows-Betriebssystemen, falls keine Fehlkonfiguration vorhanden ist, findet sich das jedoch nicht mehr im Arbeitsspeicher.

Ein bekannter Trick ist an dieser Stelle auf dem Server den Security Support Provider (SSP) Digest (WDigest.dll) zu aktivieren: (W)Digest war die Ursache, warum auf Windows 7- oder Windows Server 2008-Systemen in den meisten Fällen Klartextpasswörter zu finden waren. Microsoft veröffentlichte 2014 eine Anleitung zum Beheben des Problems. Auf aktuellen Windows-Systemen ist der Provider standardmäßig nicht aktiv und nur aus Legacy-Gründen überhaupt noch vorhanden. Durch Setzen eines Registry-Flags kann dies jedoch leicht geändert werden. PowerShell Empire (powershell/management/wdigest_downgrade) und Metasploit (windows/manage/wdigest_caching) haben beispielsweise Module für dieses Vorgehen. Durch die Bekanntheit ist jedoch auch die Erkennung des Vorgehens durch defensive Tools sehr gut (sh. z.B. Carbon Black: https://www.carbonblack.com/cbfeeds/cbcommunity_feed.xhtml#8).

Eine weniger bekannte Alternative, die jedoch ähnlich simpel und effektiv ist, findet sich bei der Untersuchung des Credential Security Support Provider (CredSSP):

The Credential Security Service Provider (CredSSP) provides a single sign-on (SSO) user experience when starting new Terminal Services and Remote Desktop Services sessions. CredSSP enables applications to delegate users‘ credentials from the client computer (by using the client-side SSP) to the target server (through the server-side SSP), based on the client’s policies. CredSSP policies are configured by using Group Policy, and the delegation of credentials is turned off by default.

Unter der Oberfläche nutzt Windows zum SSO für TSSSP (Terminal Services SSP) und den zugehörigen Authentication Provider tspkg.dll. Neben der Vereinfachung bei der Nutzung von RDP wird CredSSP außerdem häufig eingesetzt um das Double-Hop Problem in Kerberos zu umgehen.

Im regulären Betrieb muss für die Benutzung CredSSP sowohl auf dem Client als auch auf dem Server aktiviert werden. Dabei wird auf dem Client jedoch nach Aktivierung bei jedem folgenden Login das Klartextpasswort im Arbeitsspeicher gehalten, um zukünftige Logins ohne die Eingabe eins Passworts abwickeln zu können. Aktivieren wir nun die Client-Komponente, oder Teile davon, auf dem Server unter unserer Kontrolle, speichert CredSSP das Klartextpasswort jedes weiteren Logins im Arbeitsspeicher und hält dieses vor, bis die Sitzung beendet wird.

Vor der Aktivierung:

Aktivierung für RDP:

reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v AllowDefaultCredentials /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v ConcatenateDefaults_AllowDefault /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials /v 1 /t REG_SZ /d „TERMSRV/*“

Nach Aktivierung:

Natürlich hinterlässt dieses Vorgehen Spuren in Form der Registry-Einträge. Trotzdem haben es defensive Systeme in diesem Fall schwerer, da es sich hierbei um ein aktiv von Microsoft unterstütztes, und in vielen Unternehmen (leider) auch eingesetztes Feature handelt.

Verhindern lässt sich das Auslesen von Zugangsdaten z.B. durch Schützen des LSASS-Prozesses als Protected Process Light (PPL), durch Verwendung von Credential Guard oder durch Mitgliedschaft in der „Geschützte Benutzer“-Gruppe. Dies gilt übrigens auch für WDigest:

Credential delegation (CredSSP) will not cache the user’s plain text credentials even when the Allow delegating default credentials Group Policy setting is enabled.
Beginning with Windows 8.1 and Windows Server 2012 R2, Windows Digest will not cache the user’s plain text credentials even when Windows Digest is enabled.