Anatomie einer Red-Team-Übung - Kapitel 3

Wichtiger Hinweis vorab: Die einzelnen Phasen sind nicht vollständig beschrieben und die hier angegebenen Informationen dienen der Veranschaulichung der Zusammenhänge und dem besseren Verständnis dieses Textes, wobei einige Details fehlen – wir bitten dies zu entschuldigen.

Dieser Artikel ist das dritte Kapitel einer Serie, die im Technical Corner von ictexpertsluxembourg.lu veröffentlicht wurde.

Szenario 2: Hinzufügen eines Raspberry-Geräts

Wie im vorangegangenen Szenario beschrieben, haben wir mehrere Raspberry-Geräte mit einem 4G-Modem ausgestattet, so dass wir das Gerät fernsteuern können, ohne in unmittelbarer Nähe sein zu müssen.

Bei der letzten Erkundung stellten wir fest, dass sich im Erdgeschoss Schulungsräume befinden (siehe Kapitel 2 dieser Blogserie). Da wir sehen konnten, dass in diesen Räumen mehrere Systeme angeschlossen sind, nutzten wir die Gelegenheit, ein Raspberry-Gerät anzuschließen, um einen weiteren Zugang zum Zielnetzwerk zu erhalten.

Dieses Szenario wurde auf der Grundlage unserer anfänglichen physischen Erkundung ausgewählt, um uns Zugang zum Netzwerk zu verschaffen.

Der Raspberry ist ein kleines, kostengünstiges und verbrauchsarmes Gerät auf der Basis eines ARM-Prozessors, das leicht mit elektronischen Komponenten erweitert werden kann und auf dem Linux-basierte Betriebssysteme laufen. All diese Eigenschaften machen es zu einem sehr guten Kandidaten für den Aufbau von benutzerdefinierten Netzwerkimplantaten, die in verschiedenen Situationen eingesetzt werden können, in denen ein physischer Zugang zu einem interessanten Netzwerk erreicht wird.

Um diese Anforderungen zu erfüllen, haben wir ein maßgeschneidertes Raspberry-Setup mit den folgenden Zielen entwickelt:

• Die Möglichkeit des Fernzugriffs auf das Raspberry-Gerät, auch wenn es an isolierte Netzwerke oder an Air-gapped-Systeme angeschlossen ist. Dies wird durch die Verwendung eines 4G-Modems mit einer VPN-Verbindung zu unseren Steuer- und Kontrollsystemen erreicht;
• Sie sind standardmäßig völlig passiv und erzeugen keinen unerwünschten Datenverkehr, um nicht von Zugangskontrollen auf Netzwerkebene entdeckt oder blockiert zu werden, bevor sie nützliche Informationen abgreifen können;
• Unterstützung mehrerer Netzwerkkonfigurationen, um sich an potenzielle Anwendungsfälle anzupassen (in Serverräumen, in gemischten VoIP-LANs, in Netzwerken mit Zugangskontrolle) und flexibel genug, um von potenziellen Switch-Konfigurationsfehlern zu profitieren;
• Unterstützung von physischen Man-in-the-Middle-Konfigurationen, die es ermöglichen, das Zielgerät zu fälschen, um komplexere Konfigurationen mit IP-Filterung oder Netzwerkzugangskontrolle (NAC/802.1x) zu umgehen, ohne die Konnektivität des Zielgeräts zu beeinträchtigen.

Da das Raspberry-Gerät klein ist, kann es auch als allgemeines Netzwerkgerät getarnt werden, indem es in ein benutzerdefiniertes Gehäuse gesteckt wird.

Aus Faulheit und weil wir es wie ein elektronisches Gerät im Rohzustand aussehen lassen wollten, haben wir uns entschieden, das Aussehen der Raspberry-4G-Elektronikplatine, die dem Raspberry-Gerät hinzugefügt wurde, zu nutzen und es mit einer Bandantenne offen zu halten.

Da es Verdacht erregen kann, sollte auf der Vorderseite des Geräts ein Zettel mit der Aufschrift „Dieses Gerät immer eingeschaltet lassen!“ angebracht werden, um die elektronischen Komponenten leicht zu verdecken. Dies lässt paradoxerweise das Vorhandensein eines solchen Geräts berechtigt erscheinen (weil es zerbrechlich aussieht).

Nachdem wir uns Zugang zu einem der Schulungsräume verschafft hatten, schalteten wir als erstes den Raspberry ein und versuchten, ihn mit einem freien Netzwerkanschluss zu verbinden:

Da auf dem Netzwerkstecker kein Datenverkehr zu beobachten war und die Zeit knapp war, entschieden wir uns, ihn in einer „Man-in-the-Middle“-Position anzuschließen, d. h. physisch zwischen einem Laptop im Schulungsraum und seinem Netzwerk-Patch, während wir das Raspberry-Gerät in der Falltür versteckten.

Passive Netzwerkangriffe

Von dort aus konnte der Netzwerkverkehr beobachtet und die Verwendung von Network Access Control (NAC) auf der Grundlage der 802.1X-Radius-Authentifizierung (unter Verwendung des EAP-Protokolls) schnell festgestellt werden.

Wenn NAC auf dem Switch aktiv ist, besteht die Möglichkeit, dass die Generierung von Datenverkehr ohne ordnungsgemäße Authentifizierung einen Alarm auslöst oder sogar den Switch-Port abschaltet. Da das Raspberry-Gerät bereits vor Ort war, ferngesteuert wurde und mit einem funktionierenden Netzwerk verbunden war, ist es in diesem Szenario am besten, den Netzwerkverkehr des Opfers mehrere Tage lang passiv zu überwachen, anstatt Netzwerkverkehr zu erzeugen und zu riskieren, erwischt zu werden (außerdem hatten wir zu diesem Zeitpunkt bereits einen anderen funktionierenden Zugang zum Zielnetzwerk).

Das Raspberry-Gerät verwendet zwei Netzwerkschnittstellen, die als Bridge (wie ein Switch) konfiguriert sind, so dass der Layer-2-Verkehr transparent weitergeleitet werden kann. Die einzige Einschränkung wird durch den Linux-Kernel verursacht, der IEEE 802.1d reservierte Adressen blockiert, die für 802.1x NAC verwendet werden. Dazu muss eine Maske konfiguriert werden, die IEEE 802.1d-Multicast-MAC-Adressen [1] durchlässt, genauer gesagt die EAP-MAC-Adresse 01-80-C2-00-00-03:

Dank dieser Konfiguration war das Zielsystem in der Lage, sich ordnungsgemäß im Netzwerk zu authentifizieren. [1]

Auf der Suche nach Zielen

Natürlich wurde ein Packet Sniffer gestartet, sobald das Gerät angeschlossen war. Nach einer Wartezeit von weniger als einem Tag wurde eine erste Analyse des Netzwerkverkehrs direkt auf dem Gerät mit Hilfe von Skripten durchgeführt, die auf dem Tool tshark basieren (wir wollen die Analyse lokal durchführen, ohne das gesamte PCAP aus einem 4G-Netz herunterladen zu müssen – vor allem, wenn das Signal schwach ist).

• Die Ausführung von tshark-IP-Statistiken ermöglichte die Ermittlung häufig verwendeter interner System-IP-Adressen und einiger Netzwerkbereiche:
• Die Suche nach Multicast-Verkehr offenbarte mehrere Host-Namen, insbesondere Windows-Clients oder -Server, die im selben Netzwerk wie das Opfer senden:

Auf der Suche nach Passwörtern

Zu diesem Zeitpunkt wäre die Ermittlung brauchbarer Zugangsdaten für die anderen Angriffsszenarien sehr nützlich. Dafür gibt es fortgeschrittene tshark-Befehle oder spezielle Tools:

• Die Suche nach Klartextpasswörtern oder HTTP-Passwörtern kann interessant sein:
• Ebenso könnten einige Passwörter in HTML-Formularen offengelegt werden, die unverschlüsselt (über HTTP) übermittelt werden.
• Wenn keine Klartextpasswörter gefunden werden können, können NetNTLM-Authentifizierungs-Handshakes abgerufen werden, mit denen Passwörter geknackt werden können, wenn sie schwach genug sind. Der folgende Befehl ermöglicht das Abrufen all dieser Handshakes in json mit ausreichenden Informationen, um zu versuchen, die zum „Signieren“ dieser Handshakes verwendeten Passwörter zu knacken, und unterstützt die meisten für die NetNTLM-Authentifizierung verwendeten Netzwerkprotokolle:???????

Nach einem Tag Netzwerk-Sniffing stellten wir fest, dass das Opfer jedes Mal, wenn eine Webseite besucht wird, einen NTLM-Handshake durchführt. Dies liegt daran, dass der Web-Proxy für jede einzelne Seite eine Authentifizierung verlangt und dass die Proxy-Authentifizierung während der HTTP-CONNECT-Tunnelanforderung durchgeführt wird, wobei diese Anforderung im Klartext erfolgt und den NetNTLM-Handshake offenlegt.

Dies ermöglichte das Abrufen von Authentifizierungs-Handshakes von mehreren Verbindungen, die im Folgenden zusammengefasst sind:???????

Die Logik hinter diesen Benutzern ist interessant, da dieselbe Benutzerkennung 73 entweder für einen nicht privilegierten Benutzer (beginnend mit usr) oder für einen privilegierten Benutzer (beginnend mit adm) verwendet wird. Damit wird in IT-Umgebungen üblicherweise verhindert, dass privilegierte Benutzer auf E-Mails oder andere Unternehmensressourcen zugreifen.

Die Authentifizierungs-Handshakes für diese Konten wurden extrahiert, um mit bekannten oder geleakten Passwort-Wörterbüchern geknackt zu werden – ohne Erfolg.

In einem zweiten Schritt wurde eine intelligentere Cracking-Sitzung auf der Grundlage von Passwortmustern gestartet. Das Testen einfacher Muster war jedoch nicht erfolgreich, selbst als wir unsere GPU-Anlage mehrere Tage lang laufen ließen, bis wir einige von Mitarbeitern verwendete Passwortmuster entdeckten.

Auf der Suche nach Dateien

Windows-Dateifreigaben werden in den meisten Unternehmen entweder aus IT-Gründen oder für den Austausch oder die Archivierung von Unternehmensdateien intensiv genutzt.

Seit 20 Jahren empfehlen IT-Sicherheitsunternehmen, keine Klartextprotokolle zu verwenden, da diese leicht Informationen an Parteien weitergeben, die in der Lage sind, den Netzwerkverkehr abzufangen. Dies ist jedoch bei dem Windows-Dateifreigabeprotokoll, bei dem die Kommunikation nur selten verschlüsselt wird, nur selten der Fall, was in der derzeitigen Situation eine große Chance darstellt.

Erstens konnten viele Dateien im Zusammenhang mit den Windows-Gruppenrichtlinien entdeckt werden, da diese Dateien regelmäßig mit dem Domain Controller ausgetauscht werden. Dazu gehörten auch Dateien mit Passwörtern, z. B. Richtlinien zur Benutzererstellung:

Dieses Passwort konnte entschlüsselt werden und war mit einem IT-Anbieter verknüpft, so dass es möglicherweise an anderer Stelle im Netz oder in anderen Netzwerken, die von demselben IT-Anbieter verwaltet werden, verwendet werden konnte.

Es basierte auf einem Muster, das auch zum Knacken anderer Passwörter verwendet werden könnte:

Natürlich wurden zu diesem Zeitpunkt auch andere Dateien erlangt, einschließlich vertraulicher Dokumente und Finanzdaten (Excel-Dateien...), die vom Desktop-Konto usr00073 des Opfers verwendet wurden und die vollkommen unbemerkt direkt aus dem 4G-Netz exfiltriert werden konnten.

Beharrlichkeit

Nach dieser Entdeckung beschlossen wir, den Datenverkehr eine ganze Woche lang zu überwachen, während andere Angriffsszenarien liefen.

Ein paar Tage nach der ersten Analyse wurde das gesamte Windows-Profil des Benutzers usr00073 synchronisiert, da der Benutzer für die Verwendung eines Remote-Profils konfiguriert war. Auch hier wurden viele Konfigurationsdateien gefunden, die von Windows-Anwendungen verwendet werden, darunter auch Firefox-Profile.

Die folgenden Dateinamen tauchten während der Windows-Profilsynchronisierung auf, was die Synchronisierung von zwei Firefox-Profilen anzeigt:???????

Die Datei logins.json enthält Zugangsdaten, die mit einem in key4.db gespeicherten Schlüssel und optional mit einer Master-Passphrase verschlüsselt werden; eine Einschränkung von Firefox ist jedoch, dass es nicht automatisch die Erstellung einer solchen Passphrase anfordert.

Bei der Datei key4.db handelt es sich um eine SQLite-Datenbank, deren Wiederherstellung schwierig war, da aufgrund von Leistungsproblemen des Raspberry Pi viele Pakete verloren gingen, vor allem als das gesamte Remote-Benutzerprofil synchronisiert wurde (wir empfehlen interessierten Lesern, die Puffergröße zu überprüfen, wenn sie tcpdump ausführen, und verworfene Pakete zu überwachen, indem sie regelmäßig das Signal SIGUSR1 an tcpdump senden).

Dennoch war es möglich, eine der SQLite-Dateien key4.db mit nur drei von vier Chunks zu rekonstruieren, indem der fehlende Chunk durch Nullbytes ersetzt wurde. Dieses Profil enthielt nur ein Webkonto, das zweite Dutzende von Konten:

Zu diesem Zeitpunkt gibt es keine Garantie, dass dieses Webkonto dasselbe Passwort verwendet wie das Domain-Benutzerkonto. Unserer Erfahrung nach ist dies jedoch häufig der Fall, entweder aufgrund der Verwendung von Domain-Authentifizierungsdelegierung (die Website authentifiziert Benutzer durch Verbindung mit dem Active Directory LDAP) oder weil Benutzer ihre Passwörter bei mehreren Diensten des Unternehmens (manchmal sogar bei Web-Diensten außerhalb des Unternehmens) wiederverwenden.

Noch mal Passwörter knacken

Aus den gesammelten Passwörtern konnten interessante Passwortmuster abgeleitet werden, um erneut zu versuchen, die erhaltenen Authentifizierungs-Handshakes zu knacken.

Passwörter folgen oft einem ähnlichen Muster, weil Benutzer gewöhnlich nur ein Passwort generieren, um die Passwortrichtlinien einzuhalten; in unserem Fall:

• Ein Name, der mit Großbuchstaben beginnt
• Ein optionales Sonderzeichen
• Ein Datum
• Ein optionales Sonderzeichen

Der folgende Vorgang zum Passwortknacken zeigt, dass solche Passwörter mit guter Hardware und einem guten Namenswörterbuch in weniger als einer Minute wiederhergestellt werden können:???????

n diesem Fall konnten wir zwar erfolgreich die Passwörter knacken, was uns allerdings nicht weiterbrachte, da die erlangten Passwörter ohnehin direkt einem Wörterbuch hätten hinzugefügt werden können. Hier wäre es angebracht gewesen, den gesunden Menschenverstand zu nutzen.

Wir hatten nun ohne Erzeugung jeglichen Datenverkehrs im Netzwerk zwei Passwörter erhalten und nachgewiesen, dass eines davon für ein Benutzerkonto gültig ist, das in der Windows-Domain offenbar privilegiert ist.

Dies hat auch gezeigt, dass die Gewohnheit der Wiederverwendung von Passwörtern Sicherheitsdomänen-Paradigmen durchbrechen kann, da das aus einer Domain mit geringem Risiko entwendete Passwort ausreicht, damit ein Angreifer Zugang zu einer Domain mit höherem Risiko erhält.

Aktive Netzwerkangriffe

Bisher wurden nur passive Aktivitäten auf dem Raspberry PI-Gerät durchgeführt, um sicherzustellen, dass unsere Aktivitäten nicht entdeckt werden können. Um weiter einzudringen, muss man sich jedoch Netzwerkzugriff verschaffen.
Der Zugriff auf das Netzwerk erfordert jedoch die Ermittlung einer gültigen IP-Adresse und die Umgehung der NAC. Dies ist möglich, indem wir die Netzwerkadresse des Laptops im Schulungsraum fälschen, da unser Raspberry-System zwischen diesem Laptop und dem Netzwerk angeschlossen ist.

Das Blind-Spoofing von Netzwerkadressen kann oft zu einer Unterbrechung des Netzwerks auf dem Laptop des Opfers führen. Um nicht durch Netzwerkunterbrechungen aufzufallen, verfolgten wir eine Strategie, die in einem DEFCON-19-Papier von 2011 beschrieben wurde.

Diese Strategie umfasst:

• Verwendung einer Bridge und korrekten Konfiguration des Linux-Kernels, um EAP-Pakete durchzulassen (was bereits früher vorgestellt wurde);
• Spoofing der Ziel-MAC-Adresse mit einer POSTROUTING-Regel mit EBTables;
• Spoofing der Ziel-IP-Adresse mit Hilfe einer IPTables Source NAT-Adressübersetzung;
• Erzwingung der Registrierung der MAC-Adresse des Routers in den ARP-Tabellen und manuelle Erstellung einer Route zum richtigen IP-Bereich des lokalen Netzwerks (da wir die IP-Adresse des Ziels fälschen, weiß das Linux-System nicht, dass es Datenverkehr an den lokalen IP-Bereich des Ziels weiterleiten kann, und kennt auch das lokale Gateway nicht).
• Hinzufügen von Routen, um den Datenverkehr zu anderen Netzwerken des Unternehmens zu leiten (keine unüberlegte Erstellung einer eine Standardroute, da dies den Zugang zu unserem Steuer- und Kontrollserver unterbrechen kann, der die Standardroute des 4G-Modems verwendet).

Für jeden dieser Schritte wurden Skripte geschrieben, um den Spoofing-Aufbau genau kontrollieren zu können. Der schwierigste Teil ist jedoch oft, zunächst die Netzwerkumgebung und vor allem Folgendes zu ermitteln:

• Die IP- und MAC-Adresse des Ziels
• Die IP- und MAC-Adresse des Routers
• Den IP-Bereich des Netzwerks
• Potenzielle DNS-Serveradressen, die verwendet werden

Am einfachsten ist es, eine Liste von IP/MAC-Zuordnungen der Hosts zu erstellen, die im Netzwerkverkehr festgestellt wurden, und eine Analyse auf der Grundlage der folgenden Fakten durchzuführen:

1. Der häufigste Datenverkehr findet zwischen der IP-Adresse des Ziel-Laptops und der MAC-Adresse des Routers statt
2. Die MAC-Adressen sind für jedes System des lokalen Netzwerks unterschiedlich, wodurch die Größe des lokalen Netzwerks ermittelt werden kann
3. Alle Pakete in Richtung von IP-Adressen der anderen Netzwerke verwenden die MAC-Adresse des Routers

Der endgültige Aufbau für das Spoofing sah so aus:

Die Überprüfung dieser Variablen ermöglichte die Ausführung der verschiedenen Spoofing-Skripte. Dieses Set-up wurde durch den Versuch, die proxy.pac-Datei vom Raspberry-Gerät abzurufen, auf seine Funktionsfähigkeit (einschließlich DNS) hin überprüft (was auch die Erkennung gängiger Internetnutzungen des Unternehmens ermöglicht):???????

Ab hier war es möglich, mit dem Raspberry-Gerät auf das Firmennetzwerk zuzugreifen und gleichzeitig die MAC- und IP-Adresse des Opfers zu fälschen.

Wir hätten an dieser Stelle auch die Zugangsdaten des zuvor identifizierten Benutzers verwenden können, entschieden uns aber stattdessen für die Zugangsdaten, die wir im Szenario 4 erhalten hatten.

Beim Abschluss der Mission wurde der Laptop im Schulungsraum vom blauen Team als kompromittiert betrachtet, da von diesem Laptop aus Verbindungen mit einem Forest-Administrator festgestellt wurden. Der Laptop wurde daraufhin aus dem Netzwerk entfernt.

Allerdings wurde das Raspberry-Gerät während der Intervention des blauen Teams nicht gefunden, d. h. wir konnten zwar immer noch aus der Ferne auf das Gerät zugreifen, verloren aber den Zugriff auf das Netzwerk, weil kein Ziel da war, das wir ausspionieren konnten, während es die NAC-Authentifizierung für uns durchführte.

Wir beschlossen daher zu warten, bis das Ziel oder ein anderer Laptop mit dem Netzwerkkabel verbunden ist, erreichten jedoch kurz darauf das Ende der Mission des roten Teams. Wir verrieten schließlich, dass der Laptop im Schulungsraum nicht kompromittiert gewesen war, sondern dass ein Raspberry-Gerät verwendet wurde, um direkt auf das Netzwerk zuzugreifen.

Szenario 3: Gezieltes Phishing (simuliert)

Wie im vorangegangenen Kapitel erwähnt, wurden Phishing-Kampagnen im Rahmen der Vorbereitung von dieser Übung ausgeschlossen.

Da dieser Angriffsvektor jedoch ein breites Spektrum darstellt und in der Praxis aktiv genutzt wird, empfahl das Red Team von POST, zumindest eine erfolgreich durchgeführte Kampagne zu simulieren, um die gesamte Kette zu bewerten und das Risiko bestmöglich abzudecken und dieser Übung einen größeren Mehrwert zu verleihen, indem Folgendes geprüft wird:

• Die Wirksamkeit der E-Mail-Gateway-Filterung;
• Ob ein Angreifer Code auf einem Standard-Arbeitsplatzrechner ausführen kann (Härtung);
• Die AV/EDR-Auflösungslimits;
• Die Fähigkeit des ausgeführten Schadcodes, sich über die Web-Gateway-Richtlinien (Proxy) mit dem Internet zu verbinden;
• Die Alarmierung und, im Falle eines Alarms, die Reaktionen und Prozesse vor Ort – Reaktion auf einen Vorfall;
• Das Risiko für den KUNDEN, durch diesen Angriffsvektor kompromittiert zu werden.

Wie in Kapitel 2 beschrieben, haben wir bereits eine angepasste PowerShell-Stufe ohne Reverse-HTTPS-Payload unter Umgehung von Sophos AV und AMSI erstellt. Wir kombinierten sie mit HTA für die Zustellung und schickten eine E-Mail an unser Ziel, die den Schadlink zu unserer Website enthielt.

Das Opfer klickte auf den Link, um unsere Website mit dem Microsoft Edge-Webbrowser zu öffnen. Auf der Grundlage eines einfachen JS-Fingerprinting-Skripts wird das Opfer mit Edge oder IE auf unsere HTML-Seite umgeleitet, die das .HTA-Skript zur Ausführung bereitstellt. Wie im folgenden Screenshot der Webserver-Protokolle zu sehen ist, besuchte das Opfer die Seite und öffnete die HTA, die ausgeführt wurde, als die PowerShell-Payload heruntergeladen wurde. Dann sehen wir die Anfrage auf „/cs/jsquery“, was bedeutet, dass unsere PowerShell-Payload erfolgreich ausgeführt wurde und eine Verbindung zurück zu unserem Steuer- und Kontrollserver besteht:???????

Abbildung 1 – Dropper und Payload erfolgreich ausgeführt

Unsere Remote-Shell auf dem Zielcomputer war geöffnet:

Nun konnten wir mit der Post-Exploitation-Phase beginnen, indem wir das Netzwerk aufspürten und aufzählten.

Wir begannen zunächst mit der Auflistung von Domaininformationen wie Benutzern, Computern und Gruppen, um interessante Server und Benutzer mit Domain- oder Unternehmens-Administratorrechten zu identifizieren. Dann suchten wir auf dem Host, mit dem wir verbunden waren, nach interessanten Ordnern und Dateien einschließlich Browser-Datenbanken, um nach Dateien mit Passwörtern zu suchen. Mit der Sitzung eines Domainbenutzers konnten wir problemlos auf Netzwerkressourcen zugreifen.

Wir stellten schnell fest, dass es nur sehr wenige Domain-Admin-Benutzer und nur ein Unternehmens-Admin-Konto gibt. Wir fanden auch mehrere KeePass-Dateien, die uns vermuten ließen, dass dieses Unternehmen KeePass als Haupt-Passwortverwaltungssoftware verwendet. Wenn der Benutzer das KeePass-Master-Passwort anstelle einer Schlüsseldatei zum Schutz der KeePass-Datenbankdateien verwendet, kann das Master-Passwort in KeePass-Konfigurationsdateien gespeichert werden.

Deshalb benutzten wir die harmj0y-Aggressor-Skripte von Cobalt Strike, um Informationen über Master-Passwörter zu sammeln. So konnten wir das unverschlüsselte Passwort der KeePass-Datenbank des Benutzers finden:
???????

In dieser KeePass-Datenbankdatei fanden wir das Administratorkonto für die Software „Password Manager Pro“ (PMP). Nachdem wir den SOCKS-Tunnel von Cobalt Strike konfiguriert hatten, konnten wir als Administrator darauf zugreifen und die Administratorkennwörter aller Server abrufen, einschließlich des Passworts des Domain Controllers und des Passworts des Unternehmensadministrators.

Wir konnten uns dann erfolgreich mit dem Domain Controller unter Verwendung des Kontos des Unternehmensadministrators verbinden und auf alle auf den Dateiservern gespeicherten Daten zugreifen ... Game over!

Flagge: „Verschaffen Sie sich Unternehmens-Administratorrechte im Unternehmensnetzwerk“ – erledigt!

Szenario 4: Physisches Eindringen in die Firmenzentrale (Serverraum)

Die letzte Flagge war das Eindringen in das Rechenzentrum. Unsere Befürchtung, dass es sich beim Rechenzentrum unseres Kunden um ein Tier-3- oder Tier-4-Rechenzentrum handeln könnte, wurde schnell zerstreut, als wir im Internet einen Artikel fanden, in dem erklärt wurde, dass dieses Rechenzentrum kürzlich an den Hauptsitz unseres Kunden verlegt worden war.

Mit diesen Informationen begaben wir uns auf das Firmengelände unseres Kunden, um den Standort im Gebäude zu finden. Wir konzentrierten uns auf die unteren Etagen, weil sich dort aus technischen Gründen (niedrigere Temperatur im Untergeschoss, leichteres Verschieben von Racks in den unteren Etagen, Platzersparnis für Büros im Obergeschoss...) sehr oft die Technikräume befinden. Außerdem hatten wir die oberen Etagen bereits erkundet, als wir uns die vorherige Flagge holten. Es schien nur Büros zu geben, die Technikräume waren zu klein für ein ganzes Rechenzentrum.

Während unseres Besuchs entdeckten wir mehrere Technikräume in den verschiedenen Untergeschossen. Mit Blick auf die Gebäudekonfiguration hatten wir nur drei Technikräume identifiziert, die groß genug für ein Rechenzentrum waren.

Nach einigen Erkundungen gingen wir mit einem einfachen Türöffnungswerkzeug ans Werk. Aus Erfahrung wissen wir, dass zum Verlassen eines Technikraums aus praktischen Gründen in den meisten Fällen keine Zugangskarte erforderlich ist.

Abbildung 2 – Öffnen der Tür von unten

Während unserer Erkundungen stellten wir fest, dass einer der drei Technikräume, die wir ausfindig gemacht hatten, offenbar stärker überwacht wird als die anderen, da eine Kamera direkt auf die Tür gerichtet war.
Um unsere Theorie jedoch in die Praxis umzusetzen, testeten wir sie an einem der weniger überwachten Technikräume. Nach ein paar Sekunden gelang es uns, die Tür zu diesem Raum zu öffnen und so unseren PoC zu bestätigen.

Anschließend kehrten wir zum ursprünglich anvisierten Technikraum zurück, um zu überprüfen, ob unsere Intuition bezüglich des Standorts des Rechenzentrums richtig war. Wir versuchten, auch diese Tür mit unserem Werkzeug zu öffnen, dieses Mal mit Überwachung durch eine Kamera, die direkt auf die Tür gerichtet war.

Nach ein paar Sekunden konnten wir die Tür öffnen.

Nach der ersten Tür gelangten wir in einen Gang, der zu einer weiteren Tür führte. Das Lüftungsgeräusch, das aus dieser zweiten Tür kam, und das daneben liegende Register mit den Namen, Daten und Zeiten der Besuche ließen vermuten, dass wir am richtigen Ort waren. Wir benutzten auch hier unser Werkzeug, um die Tür zum Rechenzentrum zu öffnen, und standen kurz darauf im Serverraum.

In dem Raum holten wir uns die Flagge ab. Allerdings gab es da noch einen weiteren Raum, der uns interessant erschien, da alle Serverkabel dort hinein verliefen. Auch diese Tür öffneten wir mit demselben Werkzeug und konnten so auf das Backbone des Kunden zugreifen.

Abbildung 6 – Rechenzentrum

Wir beschlossen, ein Raspberry-Gerät in diesem Serverraum anzuschließen, und konnten das Rack problemlos öffnen, weil viele Schlüssel vorhanden waren. Die Schlösser an den Racks sind Standardschlösser, und wenn sie nicht einzeln ausgetauscht werden, kann man mit einem Schlüssel alle Schlösser öffnen.???????Wir beschlossen, ein Raspberry-Gerät in diesem Serverraum anzuschließen, und konnten das Rack problemlos öffnen, weil viele Schlüssel vorhanden waren. Die Schlösser an den Racks sind Standardschlösser, und wenn sie nicht einzeln ausgetauscht werden, kann man mit einem Schlüssel alle Schlösser öffnen.

Abbildung 7 – Offener Schlüsselkasten

Es ist wichtig anzumerken, dass dieses Gerät angeschlossen wurde, um die Flagge zu erhalten. Es fand jedoch keine Interaktion mit ihm statt, zum einen wegen der Empfindlichkeit des Geräts, an das es angeschlossen war, zum anderen, weil alle Flaggen bereits zuvor erhalten worden waren.

Flagge: „Zugang zum Rechenzentrum und Anschluss eines böswilligen Geräts im Serverraum“ – erledigt!???????

Schlussfolgerung:

Alles in allem kann man sagen, dass unsere Kunden oft der Meinung sind, dass die Firmenzentrale, das Rechenzentrum und die Serverräume sicher sind, weil sie sich innerhalb von Gebäuden befinden und durch Kameras und Zugangskarten gesichert sind. Wir haben jedoch erfolgreich drei der vier unten aufgeführten Flaggen erreicht:

• Flagge 1: IT-Sicherheitsziel [ABGESCHLOSSEN]
  • Erhalt von Unternehmens-Administratorrechten im Unternehmensnetzwerk;
• Flagge 3: Vollständiges Szenario: [ABGESCHLOSSEN]
  • Identifizierung der Mitglieder des Verwaltungsrats;
  • Lokalisierung ihrer Büros;
  • Betreten des Büros;
  • Zugriff auf ein vertrauliches Dokument und/oder Herausfiltern der Daten;
• Flagge 4: Vollständiges Szenario [ABGESCHLOSSEN]
  • Betreten des Hauptrechenzentrums;
  • Betreten Sie den Bereich der Server-Racks;
  • Ablegen eines böswillige Gerätes, um die Möglichkeit eines andauernden Angriffs zu demonstrieren, und Zugriff auf Daten innerhalb der Infrastruktur, ohne entdeckt zu werden.