Red-Team-Tagebuch: Von einer einzigen Phishing-Mail zum Domänenadministrator in sechs Tagen

Repräsentatives Engagement. Kundendetails anonymisiert und Einzelheiten unter NDA verändert.

Ein einziger Nutzer klickte an einem Dienstagnachmittag auf einen Link. Am darauffolgenden Montag kontrollierten wir ihr Active Directory, hatten den Gehaltsabrechnungs-Export gelesen und einen Screenshot davon in unserem Loot-Ordner liegen. Auf ihrer Seite bemerkte es niemand bis zum fünften Tag.

Dieser Kunde war stolz auf seinen Perimeter, und ehrlich gesagt hatte er allen Grund dazu. Gehärtetes VPN, EDR auf jedem Laptop, MFA überall. Als er dieses Red-Team-Assessment definierte, war der Auftrag unmissverständlich: Behandelt uns nicht länger wie einen Schwachstellenscan. Behandelt uns wie einen Angreifer, der etwas Bestimmtes will. Startet ohne jeden Zugang, gelangt zum Domänenadministrator, und mal sehen, wer es merkt.

Hier ist das Tagebuch, Tag für Tag. Namen und Zahlen sind verändert. Der Weg ist genau der, den wir gegangen sind.

Die wichtigsten Erkenntnisse

• Eine einzige abgephishte Anmeldeinformation reicht in der Regel aus, um ins interne Netzwerk zu gelangen. Der nach außen gerichtete Perimeter ist selten das, was Sie rettet.
• Der schnellste Weg zum Domänenadministrator ist fast nie ein Exploit. Es sind aufeinandergestapelte Fehlkonfigurationen: überprivilegierte Konten, wiederverwendete lokale Administratorpasswörter und schwache Active-Directory-Delegierung.
• Wenn EDR eine Payload abfängt, bedeutet das nicht, dass Ihr SOC darauf reagiert. Wir sind häufig laut und bleiben trotzdem tagelang unbeantwortet.
• Kerberoasting, gemeinsam genutzte lokale Administrator-Anmeldedaten und verbliebene privilegierte Sitzungen sind die drei Findings, die wir bei fast jedem internen Engagement melden.
• Ein Red-Team-Assessment misst Erkennung und Reaktion, nicht nur, ob eine Lücke existiert. Genau das unterscheidet es von einem herkömmlichen Penetrationstest.

Was ist ein Red-Team-Assessment, und warum nicht einfach einen Pentest durchführen?

Ein Red-Team-Assessment ist eine zielgerichtete Simulation eines echten Angreifers, die sich gleichzeitig gegen Ihre Menschen, Prozesse und Technik richtet. Das Ziel ist nicht “jeden Bug in dieser App finden”. Es ist etwas, das ein Krimineller tatsächlich wollen würde: das Postfach des CFO lesen, die Kundendatenbank exfiltrieren, eine Änderung in die Produktion einspielen. Wir wählen einen Weg und bewegen uns leise darauf zu.

Ein Penetrationstest beantwortet, wo die Lücken sind. Ein Red Team beantwortet, was passiert, wenn jemand durch eine davon hindurchgeht. Beide haben ihre Berechtigung. Aber wenn Sie bereits einige Pentests durchgeführt haben und Ihr Vorstand fragt, ob Sie einen gezielten Einbruch überstehen würden, ist der Pentest nicht mehr das richtige Werkzeug. Sie brauchen jemanden, der auf Sieg spielt, unter Zeitdruck, während Ihre Verteidiger nichts vom Timing wissen.

Tag 1: Die Mail, auf die geklickt wurde

Wir haben nicht Tausende von Nachrichten verschickt. Gezieltes Red-Team-Phishing ist von Natur aus leise. Der erste Nachmittag ging für Open-Source-Recherche drauf: LinkedIn, der Unternehmensblog, ein Konferenzvortrag, den einer ihrer Ingenieure gehalten hatte, ein paar Adressen aus alten Breach-Dumps. Das lieferte uns die Namenskonvention für E-Mail-Adressen ([email protected]) und genug Kontext, um etwas zu formulieren, das ein vielbeschäftigter Ingenieur ohne nachzudenken öffnen würde.

Der Vorwand war ein geteiltes Dokument über eine interne Tooling-Migration, gerichtet an das Plattform-Team. Nicht an den CEO. Ingenieure haben breiteren Zugang und klicken auf mehr Links. Die Landing-Page war ein sauberer Klon ihrer Microsoft-Anmeldung, ausgeliefert über eine Lookalike-Domain, die wir registriert und zwei Wochen hatten reifen lassen, damit sie nicht wie frisch angelegt wirkte. Wir betrieben sie hinter einem Reverse-Proxy im evilginx-Stil, das heißt, wir fingen das Passwort und das Session-Cookie ab. Dieses Cookie spaziert direkt an MFA vorbei.

Zwei Klicks in der ersten Stunde. Eine abgeschlossene Anmeldung. Wir hielten nun eine gültige Sitzung und gültige Anmeldedaten eines Ingenieurs mittlerer Ebene. Lässt sich sauber auf MITRE ATT&CK T1566 (Phishing) und T1078 (Valid Accounts) abbilden, und genau hier beginnen die meisten unserer Engagements tatsächlich.

Tag 2: Fuß fassen und sich umsehen

Gestohlene Zugangsdaten sind schön. Codeausführung auf einem internen Host ist besser. Wir ritten die Sitzung bis zu ihrem VPN-Portal, landeten in einer Position mit niedrigen Rechten und fassten Fuß auf der Workstation des Ingenieurs. Das ändert das ganze Spiel. Jetzt können wir die Domäne von innen enumerieren.

Unser erster Schritt in jedem internen Netzwerk ist leise Aufklärung mit BloodHound. Sitzungsdaten, ACLs und Gruppenmitgliedschaften sammeln und dann den Graphen zeigen lassen, wo der kürzeste Pfad zum Domänenadministrator verläuft. Es ist fast nie eine gerade Linie. Es gibt fast immer eine Linie.

# Collect Active Directory data from the foothold (low and slow)
SharpHound.exe --collectionmethods DCOnly,Session --stealth

# Then in the BloodHound UI: mark our compromised user as Owned,
# and run "Shortest Paths to Domain Admins from Owned Principals"

Der Graph leuchtete auf. Unser kompromittierter Ingenieur saß in einer Gruppe mit lokalen Administratorrechten auf einem Cluster von Build-Servern. Genau die Art überberechtigter Gruppe, an deren Vergabe sich niemand erinnert und die seither niemand überprüft hat. Das war unsere Auffahrt.

Tag 3: Kerberoasting und Offline-Cracking

Jeder Domänenbenutzer kann Kerberos-Servicetickets für Konten anfordern, die einen Service Principal Name gesetzt haben. Diese Tickets sind mit dem Passwort-Hash des Dienstkontos verschlüsselt. Also fordert man sie an, zieht sie herunter und knackt sie offline, wo keine Sperrrichtlinie und kein Alarm einen erreichen kann. Das ist Kerberoasting (T1558.003), und es ist der zuverlässigste Trick, den wir in internen Netzwerken haben.

# Request roastable service tickets with Impacket
GetUserSPNs.py acme-corp.example/j.doe -request -dc-ip 10.10.0.5 -outputfile roast.txt

# Crack offline with Hashcat (mode 13100 = Kerberos TGS-REP)
hashcat -m 13100 roast.txt rockyou.txt -r best64.rule

Ein Dienstkonto in unter einer Stunde geknackt. Das Passwort war Summer2023!, von einem Menschen gesetzt, auf einem Konto mit einer Richtlinie ohne Ablauf und, wie sich herausstellte, mit Mitgliedschaft in einer privilegierten Gruppe. Das ist überall das Muster: Ein Dienstkonto wird einmal aufgesetzt, bekommt “zur Sicherheit” mehr Rechte, als es braucht, und dann rührt es vier Jahre lang niemand an.

Tag 4: Laterale Bewegung und Abgreifen von Anmeldedaten

Lokale Administratorrechte auf den Build-Servern bedeuteten, dass wir uns lateral bewegen konnten. Wir gingen hier bewusst vor. Das ist die Phase, in der lautes Tooling Teams auffliegen lässt und in der ein kompetentes SOC hätte aufwachen müssen. Wir vermieden es, Mimikatz auf die Festplatte zu schreiben, und zogen zwischengespeicherte Anmeldedaten im Prozess aus dem Speicher, um dann den Hash des lokalen Administrators wiederzuverwenden und uns anderswo zu authentifizieren.

Dieses lokale Administratorpasswort war auf jedem Server im Segment identisch. Ein Hash. Pass-the-Hash (T1550.002). Dutzende Hosts. Auf einem von ihnen hatte ein Administrator eine RDP-Sitzung angemeldet gelassen, und das Abgreifen dieses Tokens verschaffte uns den Kontext eines Domänenadministrators, ohne dass wir je das Passwort erfuhren. Wiederverwendete lokale Administrator-Anmeldedaten und vergessene privilegierte Sitzungen sind nach unserer Erfahrung die beiden Dinge, die am häufigsten aus einem eingedämmten Fuß in der Tür einen Totalverlust machen.

Tag 5: Domänenadministrator und der erste Anruf

Am fünften Tag hielten wir ein Domänenadministrator-Token. Um die Auswirkung nachzuweisen, ohne etwas zu beschädigen, führten wir einen kontrollierten DCSync (T1003.006) durch, um den Hash des krbtgt-Kontos zu ziehen – den Schlüssel, mit dem ein Angreifer Golden Tickets fälschen und mehr oder weniger für immer persistent bleiben kann. Wir bauten das Golden Ticket nicht in der Produktion. Wir dokumentierten die Fähigkeit und hörten dort auf.

Das war auch der Tag, an dem das SOC endlich unseren Ansprechpartner anrief. Unsere laterale Bewegung vom Vortag hatte einen EDR-Alarm ausgelöst. Die Payload wurde markiert. Aber der Alarm lag den Großteil eines Tages in einer Warteschlange, bevor ihn jemand triagierte. Die Technik funktionierte. Die Reaktion nicht. Genau diese Lücke zu messen, dafür existiert ein Red-Team-Assessment, und kein Scanner wird sie je finden.

Tag 6: Das Ziel erreichen

Das vereinbarte Ziel war Zugang zu sensiblen Finanzdaten. Mit Domänenadministrator war dieser Teil trivial. Wir mounteten die Finanz-Dateifreigabe, fanden einen Gehaltsabrechnungs-Export und einen Ordner mit unverschlüsselten Kunden-PII, sicherten Beweise, versahen alles mit Zeitstempeln und zogen uns zurück. Keine Daten verließen ihre Umgebung. Gesamte verstrichene Zeit vom ersten Klick bis zum Ziel: sechs Tage, den Großteil davon bewusst langsam unterwegs, um zu testen, ob jemand zusah.

Was wir fanden: die echten Grundursachen

Nichts davon brauchte einen Zero-Day. Nicht eine einzige CVE war beteiligt. Die gesamte Kette bestand aus Konfiguration und Hygiene:

• MFA, die den Session-Diebstahl nicht überlebte. Ihre MFA hielt gegen Password-Spraying gut stand und war nutzlos gegen ein Reverse-Proxy-Phishing, das das Session-Cookie stiehlt. Phishing-resistente MFA mit FIDO2-Hardwareschlüsseln bricht die Kette schon am ersten Tag.
• Ein kerberoastbares Dienstkonto mit einem schwachen, statischen Passwort. Ein verwaltetes Geheimnis mit über 25 Zeichen oder ein Group Managed Service Account, und es lässt sich nicht mehr knacken.
• Gemeinsam genutzte lokale Administratorpasswörter. Windows LAPS randomisiert das lokale Administratorpasswort pro Maschine. Damit endet unser Pass-the-Hash-Streifzug bei genau einem Host.
• Erkennung ohne Reaktion. Der Alarm existierte. Das Runbook, um ihn in Minuten zu bearbeiten, nicht.

Wie man das typischerweise stoppt

Jetzt der unangenehme Teil. Mehr Geld für Präventionswerkzeuge auszugeben hätte diesem Kunden wenig geholfen. Er hatte bereits gute Werkzeuge. Was ihm fehlte, waren Konfigurationshygiene und ein Reaktionsprozess, der unter Druck getestet worden war. Rotieren Sie die Anmeldedaten von Dienstkonten und legen Sie sie in einem Tresor ab. Rollen Sie LAPS aus. Verlagern Sie privilegierte Konten auf phishing-resistente MFA. Stufen Sie Ihre Administratorkonten so, dass ein kompromittierter Arbeitsplatz kein Domänenadministrator-Token erreichen kann. Und vor allem: Führen Sie Live-Tests gegen Ihr SOC durch, bis aus einem Alarm eine Aktion wird statt eines Warteschlangeneintrags.

Wie CyberXplore hilft

Das ist die Arbeit, die wir das ganze Jahr über machen. Unser Service Red-Team-Assessment führt zielgerichtete Angreifersimulationen durch, die widerspiegeln, wie echte Eindringlinge vorgehen: Phishing, Fuß in der Tür, Active-Directory-Angriffspfade und leise laterale Bewegung, damit Sie erfahren, wie weit jemand kommt und ob Ihr Team es rechtzeitig bemerkt. Sie erhalten eine Angriffserzählung wie die obige, jeden Schritt auf MITRE ATT&CK abgebildet, dazu Gegenmaßnahmen, die Ihre Ingenieure am Montagmorgen umsetzen können. Wenn Sie wissen möchten, wie sich Ihre Umgebung schlägt, fordern Sie ein Angebot an und sagen Sie uns, was Ihre Kronjuwelen sind.

FAQ

Wie lange dauert ein Red-Team-Assessment?

Die meisten Engagements laufen von Anfang bis Ende drei bis sechs Wochen, je nach Umfang und gewünschtem Grad an Tarnung. Der aktive Einbruch in diesem Tagebuch dauerte sechs Tage, aber echte Red Teams bewegen sich oft bewusst langsam, um die Erkennung über die Zeit zu testen. Aufklärung, Reporting und ein Debrief-Workshop kommen noch zum Kalender hinzu.

Wie unterscheidet sich ein Red-Team-Assessment von einem Penetrationstest?

Ein Penetrationstest enumeriert und weist Schwachstellen in einem definierten Umfang nach, meist im Wissen der Verteidiger, dass er stattfindet. Ein Red-Team-Assessment ist zielgetrieben und verdeckt. Es testet Menschen, Prozesse und Erkennung zusammen, und Erfolg bedeutet, ein Ziel wie Domänenadministrator oder Datenexfiltration zu erreichen. Wenn Sie noch nie einen Pentest durchgeführt haben, fangen Sie dort an. Red Teaming setzt ein vernünftiges Reifegrad-Grundniveau voraus.

Wird ein Red-Team-Assessment unsere Produktivsysteme stören?

Nein. Wir arbeiten unter strengen, im Voraus vereinbarten Rules of Engagement, vermeiden destruktive Aktionen und stimmen uns mit einer kleinen, vertrauenswürdigen Gruppe auf Ihrer Seite ab. Nachweisschritte wie DCSync werden kontrolliert durchgeführt, und wir entfernen niemals echte Daten aus Ihrer Umgebung. Sicherheit und Umkehrbarkeit sind im Umfang festgeschrieben.

Müssen wir unserem Sicherheitsteam sagen, dass es stattfindet?

Normalerweise kennt nur eine kleine “White Cell” vertrauenswürdiger Beteiligter das Timing, damit die Reaktion des SOC echt ist. Genau das ist der Sinn der Sache. Wenn die Verteidiger nach Ihnen Ausschau halten, lernen Sie nichts über die Erkennung in der realen Welt. Wir vereinbaren im Voraus ein Codewort und Eskalationskontakte, damit niemand einen Fehlalarm in eine Krise hineinjagt.

Was erhalten wir am Ende?

Eine vollständige Angriffserzählung, jeden Schritt auf MITRE ATT&CK abgebildet, Beweise für jedes Finding, einen priorisierten Gegenmaßnahmenplan, den Ihre Ingenieure umsetzen können, und ein Debrief für technisches wie auch für Führungspublikum. Der Wert liegt nicht in der Liste der Probleme. Er liegt in der Geschichte, wie sie sich zu einer Kette verbanden und was die Kette bricht.

Wie oft sollten wir eines durchführen?

Für die meisten Organisationen jährlich, oder nach einer größeren Veränderung wie einer Fusion, einer Cloud-Migration oder dem Aufbau eines neuen SOC. Umgebungen driften, Personal wechselt, und die Fehlkonfigurationen, die uns hereingelassen haben, schleichen sich tendenziell wieder ein. Ein regelmäßiges Red-Team-Assessment hält Ihre Erkennung und Reaktion ehrlich.