Aus dem Tagebuch eines Red Teams – Teil 10

Die Anleitung zum Erfolg (Teil 1/2)

In diesem Red-Teaming-Projekt starteten wir erneut ohne jegliche Hilfestellung des Kunden. Doch am Ende schrieb der Kunde unbeabsichtigt selbst die Anleitung, mit der wir das Projekt-Ziel erreichten.

Die Erzählung zu diesem Red-Teaming-Projekt gliedert sich in zwei Blog-Artikel, dies ist der erste davon. Der zweite erscheint am 01.05.2023. In diesem Artikel starten wir oben links in der Grafik und werden den Weg bis zum VPN-Server als Tür zur internen Infrastruktur gehen. Im zweiten Artikel näheren wir uns dann Schritt für Schritt dem Domänen-Admin unten rechts, was gleichbedeutend zur vollständigen Übernahme der Infrastruktur ist.

Analysieren der Angriffsfläche

Auf Basis des Kundennamens begannen wir mit unserer Recherche, um mögliche Angriffswege ins interne Firmennetz zu identifizieren. Dabei sind für uns alle Informationen relevant, die sich im Kontext des Kunden finden lassen, denn am Ende weiß man nie, wie sich einzelne kleine Puzzlestücke plötzlich zu einem Angriffsweg zusammensetzen lassen. Dazu gehören technische Informationen angefangen von Domänen, die zum Kunden gehören, über Indizien zu eingesetzter Software bis hin zu Namen und Jobbeschreibungen von Mitarbeitenden.

Obwohl wir eine Vielzahl an Domänen fanden, so war die technische Angriffsfläche zu unserer Enttäuschung doch ziemlich übersichtlich.

Anders verhielt es sich mit der Präsenz von Mitarbeitenden auf öffentlichen Plattformen. Nach dem Erstellen einer Liste mit allen dem Kunden zuordenbaren Mitarbeitenden und deren Jobbeschreibungen überlegten wir, wie wir daraus eine passende Gruppe für eine gezielte Phishing-Mail zusammenstellen könnten.

Das Ergebnis war eine Gruppe bestehend aus 15 Mitarbeitenden der Personal-Abteilung. Als Thema entschieden wir uns für einen Newsletter im Namen eines bekannten Schulungs-Anbieters. Die Empfänger wurden in der Mail freundlich auf einen Link hingewiesen, über den sie Informationen zu rechtlichen Änderungen im Personalwesen zum Jahreswechsel einsehen können. Um die Empfänger zur Preisgabe ihrer Microsoft-Zugangsdaten zu verleiten, schrieben wir, die Informationen seien derzeit noch geschützt und ausschließlich nach Anmeldung mit einem Microsoft-Konto verfügbar.

Ein Passwort reicht (uns)

Der Aufbau der Phishing-Umgebung war schließlich fertig, die Mail ein letztes Mal auf Plausibilität und Rechtschreibfehler geprüft. Nach dem Versenden der Mail warteten wir gefühlt Stunden, obwohl auf der Uhr nur wenige Minuten vergingen. Und, siehe da, unsere Systeme meldeten, dass ein Empfänger Zugangsdaten eingegeben hatte! Dies sollte übrigens die einzige Person bleiben, die in dieser Phishing-Kampagne Zugangsdaten preisgeben würde – aber am Ende reicht ein solches Passwort häufig aus, um in die gesamte Infrastruktur zu gefährden.

Mit den Zugangsdaten hatten wir nun Zugriff auf alle genutzten M365-Ressourcen des Benutzers. Besonders spannend war die Zugriffsmöglichkeit auf Dateien, die in SharePoint und OneDrive gespeichert waren. Das dort integrierte Suchfeld lieferte den perfekten Ausgangspunkt, um nach für uns interessanten Dateien zu suchen.

Da das Ziel war, in das interne Netzwerk zu gelangen, suchten wir nach IT-Begriffen wie „Netzwerkplan“, um uns besser orientieren zu können, allerdings mit mäßigem Erfolg. Anders sollte es beim Suchbegriff „Passwort“ sein – als erstes Suchergebnis wurde uns eine Datei namens „Anleitung VPN-Verbindung.pdf“ vorgeschlagen!

Schritt-für-Schritt-Erklärung

Nach dem Herunterladen der Datei scrollten wir durch eine detaillierte Anleitung zum Einrichten einer VPN-Verbindung ins Kundennetzwerk. Der Hersteller der VPN-Software war auf Abbildungen erkennbar. Glücklicherweise stand die VPN-Client-Software zudem auf der Webseite des Herstellers zum Herunterladen bereit. Nach der Installation konfigurierten wir alle Einstellungen gemäß der Anleitung.

Als letztes fehlten nur noch Zugangsdaten. Dass der Benutzername in Form einer Mail-Adresse eingegeben werden musste, war praktischerweise ebenso in der Anleitung erkennbar. Bisher kannten wir genau eine Kombination von Mail-Adresse und Passwort, also fiel die Wahl für den ersten Verbindungs-Versuch nicht schwer.

Wir bangten, ob nach dem Klicken auf „Verbinden“ wohl noch ein zweiter Faktor zur Authentifizierung abgefragt werden würde. Dies würde unser Vorhaben erheblich erschweren, wenn nicht sogar verhindern. Und wieder einmal vergingen die Sekunden wie Minuten und wir hielten den Atem an, während sich auf unserem Monitor ein Fortschrittsbalken für den Verbindungs-Aufbau langsam füllte. Schließlich ging unten rechts im Bildschirm eine Windows-Benachrichtigung auf, wir seien nun mit dem Netzwerk verbunden – aufatmen, Projektziel erreicht!

Fleißpunkte sammeln

Von nun an war alles „Bonus“, was wir erreichten. Wie weit wir im internen Netz noch (unerkannt) vorankamen und sich die Schritte in der Grafik weiter füllten, erzählen wir im nächsten Blog-Artikel.

Wie hätten wir bisher gestoppt werden können?

Bemerkenswert ist, dass beim Aufbau der VPN-Verbindung kein zweiter Faktor zur Authentifizierung abgefragt wurde. Weiterhin lässt sich technisch einschränken, von welchen Geräten aus VPN-Verbindungen überhaupt aufgebaut werden dürfen. Wäre solch ein Sicherheitsmechanismus in Verwendung gewesen, hätte ein unbekanntes System, wie unseres, keine VPN-Verbindung aufbauen dürfen.

Muss Phishing denn immer sein?

Wie regelmäßige LeserInnen der Serie vielleicht schon bemerkt haben: Phishing-Angriffe sind ein effektives Mittel, um einen ersten Schritt in Richtung der internen Infrastruktur eines Unternehmens zu gehen. Doch in Red-Teaming-Projekten muss Phishing nicht immer sein.

Neben dem Ausgangspunkt, von außen ohne jegliche Informationen zu starten, bieten wir auch Red-Teaming-Projekte im sogenannten Assumed-Breach-Ansatz an. In diesem Szenario starten wir direkt aus dem internen Firmennetz, beispielweise nach Bereitstellung eines VPN-Zugriffs, sodass diese Projekte einen anderen Fokus haben und mehr Zeit in das (unerkannte) Ausbreiten im internen Netzwerk fließt. Dies ist im Vergleich zum Ansatz von außen ein zeiteffizienteres Vorgehen, da ein Angreifer meist auf irgendeine Weise – ob physisch vor Ort (siehe Artikel 2, Artikel 3, Artikel 5), per Phishing (Artikel 6) oder über technische Schwachstellen – früher oder später einen Weg in die interne Infrastruktur findet. Der Assumed-Breach-Ansatz ist auch dann sinnvoll, wenn die Effektivität des internen Monitorings getestet werden soll oder wenn Angreifer simuliert werden sollen, die konkrete Ziele verfolgen, wie beispielsweise das Kompromittieren von Systemen, die sensible Daten speichern, um unbemerkt große Datenmengen zu exfiltrieren.

Und nach dem ersten Schritt in die Firmeninfrastruktur stellen sich viele spannende Fragen:

1. Würde die IT-Abteilung einen Angreifer bemerken und falls ja, wie schnell?
2. Wie „laut“ müsste ein Angreifer sein, um bemerkt zu werden?
3. Wie einfach könnte ein Angreifer sich ausbreiten? Könnte er auch eventuelle Backup-Systeme finden, um diese beispielsweise im Zuge eines Ransomware-Angriffs auch zu verschlüsseln?
4. Welche Schritte würde das Unternehmen nach dem Erkennen eines Angriffs einläuten und gäbe es dabei Schlupflöcher für den Angreifer?

Sollten Sie Interesse an einem Red-Teaming-Projekt haben, melden Sie sich gerne – wir beraten Sie natürlich auch in der Frage, welcher Ausgangspunkt für das Red Team im Fall Ihres Unternehmens am sinnvollsten wäre.

Telefon: +49 731 20 589-26
E-Mail: pentests@it-sec.de

Nina Wagner im Namen des Red Teams der it.sec
Senior IT-Security Consultant / Penetration Testing