Red-Team-Tests in der Praxis

Sprung über den Graben

Zu Beginn der Red-Team-Tests bekamen wir unser eigenes Büro, wo wir ungestört arbeiten konnten. Mit Ausnahme der eingeweihten Mitarbeitenden erhielt das gesamte Personal die Information, dass wir ein Audit im Zusammengang mit den Unternehmensabläufen durchführen würden.

Nach Inspektion der verfügbaren Netzwerk-Ports war uns schnell klar, dass bei unserem Kunden eine portbasierte Netzwerkzugangskontrolle (Port-based Network Access Control, PNAC) gemäß IEEE-Norm 802.1X implementiert war. Mit den geeigneten Konfigurationseinstellungen kann diese ein effizientes Tool sein, da sie Netzwerkzugriffe erkennen und blockieren kann. Wie jedoch bei allen Protokollen, gibt es auch in diesem Fall Schwächen. Die Zugangskontrolle kann am einfachsten umgangen werden, wenn wir uns Geräte ansehen, die mit Netzwerken verbunden sind und die diese Norm vermutlich nicht unterstützen. Da der Betrieb dieser Geräte trotzdem irgendwie sichergestellt werden muss, werden sie im Allgemeinen als Ausnahmen verwaltet. Im Laufe des Prozesses werden die Geräte anhand Ihrer MAC-Adressen identifiziert und dann können sie sich rechtmäßig mit dem Netzwerk verbinden, auch ohne angemessene Authentifizierung.

Bei einer überragenden Mehrheit an Netzwerkdruckern sind die NAC-Standards noch nicht umgesetzt, sodass diese attraktive Angriffsziele sein können. In einer der hinteren Ecken des Raumes fanden wir einen Netzwerkdrucker, der nur noch als Staubfänger diente. Durch die Verbindung zum nächsten Netzwerk-Port erhielt er sofort eine IP-Adresse vom DHCP-Server, was bedeutete, dass seine MAC-Adresse immer noch als Ausnahme auf dem Authentifizierungsserver vorhanden war.

Obwohl die MAC-Adresse nicht auf dem Bedienfeld des Druckers angezeigt wurde, konnten wir uns durch die Nutzung eines Hubs passiv zwischen den Drucker und das Netzwerk schalten. So konnten wir die Kommunikation zwischen Drucker und Netzwerk abhören und innerhalb kürzester Zeit eine gültige MAC-Adresse erhalten. Mit Kenntnis dieser MAC-Adresse konnten wir uns auch mit dem Netzwerk verbinden.

Die erste Verteidigungslinie war also erfolgreich durchbrochen. Da einige von uns gleichzeitig arbeiten wollten, wir aber nur eine gültige MAC-Adresse hatten, wandelten wir einen der Computer praktisch in einen Router um. Alle anderen Computer, die an der Analyse beteiligt waren, kommunizierten mit dem Netzwerk über diesen einen Host.

Mauern stürzen ein

Nachdem wir uns erfolgreich verbunden hatten, konnten wir beginnen, das Netzwerk zu erkunden. Wir mussten besonders darauf achten, keine Aufmerksamkeit auf uns zu ziehen. Wären unsere Aktivitäten aufgefallen, hätte das leicht das Ende des Projekts bedeuten können. Das hieß, dass wir praktisch die meisten Techniken der aktiven Aufklärung nicht nutzen durften. Deshalb versuchten wir zunächst, die gefährdeten Workstations und Server durch passives Abfangen des Netzwerkverkehrs zu identifizieren.

Nach kurzer Zeit hatten wir bereits einige Zugriffspfade von Dateifreigaben im Netzwerk sowie die IP-Adressen einiger Workstations, also begannen wir mit deren Analyse. Während wir die Datenfreigaben genauer analysierten, entdeckten wir etwas Interessantes.

Die Freigabe mit dem Namen ADBackupManager unterschied sich stark von allen anderen und war jedem frei zugänglich. In der Freigabe fanden wir eine ausführbare Datei, einige DLL-Dateien und auch eine Datenbankdatei. Dem Namen der Freigabe nach zu urteilen, dachten wir, es dürfte sich lohnen, diese Dateien gründlicher zu untersuchen. Mithilfe von Reverse-Engineering-Techniken gelang es uns, die Anwendung praktisch bis zum Quellcode zu entschlüsseln. Dabei fanden wir heraus, dass die Anwendung dazu diente, Backups für die Netzwerkfreigaben zu erstellen. Damit die Anwendung richtig funktioniert, ist auch ein Zugriff auf Domänenebene erforderlich. Dieser Zugriff war in verschlüsselter Form in der Datenbank gespeichert. Da der Entschlüsselungsalgorithmus und der notwendige Schlüssel im Quellcode der Anwendung fest codiert waren, konnten wir das verschlüsselte Passwort ganz leicht entschlüsseln.

Wir überprüften schnell den Zugriff und er war gültig. An diesem Punkt konnten wir auf authentifizierte Weise mit dem Domänenserver kommunizieren. Das war der nächste wichtige Meilenstein.

Festung erobert

Mit dem Zugriff konnten wir alle Benutzer der Domäne abfragen sowie deren Gruppen und gültige Access Control Lists (ACL). Der nächste Schritt war die Ausführung eines Kerberoasting-Angriffs, in dessen Verlauf wir mithilfe unseres gültigen Zugriffs Service-Tickets für die Service-Konten der Domäne anfragten. Jedes Ticket ist mit dem NTLM-Hash des jeweiligen Service-Kontos verschlüsselt. Wir können versuchen, die beschafften Tickets zu entschlüsseln, indem wir Millionen Passwörter offline ausprobieren. Wenn ein Ticket entschlüsselt werden kann, haben wir damit auch das Passwort des jeweiligen Service-Kontos. Unseren Erfahrungen zufolge können Service-Konten, die mit einem mittelstarken oder schwachen Passwort geschützt sind, auf diese Weise schnell geknackt werden.

Es gelang uns, ein Service-Ticket für ein Service-Konto anzufragen, das mit einem Admin-Flag versehen war. Service-Konten sind im Allgemeinen Domänenkonten mit besonderen Berechtigungen, das Admin-Flag deutete jedoch stark darauf hin, dass dieser Benutzer über noch mehr Berechtigungen verfügen könnte. Schließlich schafften wir es innerhalb nur Stunde, das Service-Ticket des Benutzers svc_backupmgr zu knacken. Nach einer schnellen Abfrage fanden wir außerdem heraus, dass dieser Benutzer zu der Gruppe »Backup Operators« gehört.

Als dieser Benutzer konnten wir uns über den Dienst »winrm« an einem der Domänencontroller anmelden. Der Privilege-Escalation-Angriff lag mit der Backup-Berechtigung quasi auf der Hand. Im ersten Schritt dieses Angriffs, fragten wir die SAM- und SYSTEM-Hives aus der Registry ab. Im nächsten Schritt zogen wir den NTLM-Hash des lokalen Administrators aus den Hives. Mit dem Hash und der Pass-the-Hash-Methode konnten wir uns am Server anmelden, auch ohne das Passwort zu kennen und dieses Mal sogar mit Administratorzugriff.

Mit den passenden Berechtigungen konnten wir ein Abbild des NTDS erstellen, das den Passwort-Hash aller Domänenbenutzer enthielt.

Zu diesem Zeitpunkt ließ sich sagen, dass die Domäne vollständig gefährdet war. Wir beschafften uns die Hashes von Tausenden Benutzern, einschließlich Administratoren der Domäne und des Unternehmens. Ausgestattet mit diesen Authentifizierungsdaten hätten wir die Berechtigungen gehabt, in mehreren Anlagen des Unternehmens beliebige Aktionen in der Domäne auszuführen.

Eine große Überraschung

Die Kombination aus folgenden gravierenden Schwachstellen ermöglichte einen erfolgreichen Angriff:

• mangelhafte physische Sicherheit (offene Netzwerk-Ports)
• vorhandene NAC-Ausnahmen (längst ungenutzte Geräte noch als Ausnahmen gelistet)
• Netzwerkfreigaben mit sensiblen Inhalten für jeden frei zugänglich
• Verwendung fest codierter Authentifizierungsdaten
• Service-Konto mit schwachem Passwort geschützt
• Service-Konto verfügt über zu viele Berechtigungen (Fernanmeldung über winrm)

Im Verlauf der Red-Team-Tests führten wir fast ausschließlich Aktionen aus, zu denen Benutzer der Domäne üblicherweise berechtigt sind. Dementsprechend verursachten wir keine Sicherheitsvorfälle oder Warnungen in den IDS- und IPS-Tools des Kunden.

Als wir den Entscheidungsträgern bei unserem Kunden nach nur wenigen Tagen unsere Ergebnisse präsentierten, waren diese völlig überrascht. Sie sagten, sie hätten die zuständigen Experten mehrfach gefragt, ob ihnen verdächtige Vorfälle aufgefallen seien, doch als Antwort erhielten sie wiederholt ein klares Nein.

Das Ergebnis bestärkte unseren Kunden darin, Sofortmaßnahmen zu ergreifen und parallel dazu eine vollumfängliche interne Analyse bei uns anzufragen. Im Verlauf der Read-Team-Tests wurden mehrere kritische Schwachstellen erkannt. Basierend auf den Ergebnissen aus mehren Runden gemeinsamer Arbeit kann festgehalten werden, dass das Sicherheitsniveau des Systems unseres Kunden kurz darauf deutlich verbessert wurde.