SECURITY17. Oktober 2024

Bei Red Teaming für DORA ist alles erlaubt! TIBER ist tot, lang lebe Threat Led Penetration Test (TLPT)

Schwerpunkt: Threat Intelligence
Führt Red Teaming unter Dora: druch: Markus Koplin, SEC Consult
Markus Koplin, SEC ConsultSEC-Consult

Wurde Ihr Unternehmen bereits von Ihrer zuständigen Finanz­aufsichts­behörde aufgefordert, einen Threat Led Penetration Test (TLPT) im Rahmen von DORA durchzuführen?

Im Folgenden erläutern wir, was auf Sie zukommt, mit welchen Ressourcen Sie rechnen und welche Tätigkeiten Sie durchführen müssen … und was im Hintergrund läuft.

von Markus Koplin, Teamlead Pentester bei SEC Consult

TLPT ist eine mit DORA eingeführte Prüfmethode. Sie basiert im Grunde auf dem TIBER-EU-Rahmenwerk, enthält aber erweiterte Anforderungen. Die gute Nachricht ist, dass TIBER-DE und TIBER-AT schon heute strengere Vorgaben haben als TIBER-EU und im Vergleich zu TLPT nur minimale Unterschiede beinhalten. Das heißt, dass die TIBER-Serviceanbieter bereits bestens vorbereitet sind, um zukünftig TLPT durchführen zu können.

TLPT ist ein Rahmenwerk, welches die Taktiken, Techniken und Verfahren (engl. TTPs) realer Bedrohungsakteure (engl. APTs) nachahmt, die als echte Cyber-Bedrohung wahrgenommen werden. Damit kann ein kontrollierter, maßgeschneiderter und realitätsnaher Red Team Test der kritischen Live-Produktionssysteme eines Finanzinstituts durchgeführt werden (DORA Artikel 3(17)).”

Im Scope von TLPT sind mehrere oder alle kritischen oder wichtigen Funktionen eines Finanzunternehmens und der Test wird an Live-Produktionssystemen durchgeführt. Der genaue Umfang wird von den Finanzinstituten festgelegt und von den zuständigen Behörden, wie z.B. der deutschen Bundesbank, validiert.

Red Teaming: Testmethodik und Zusammenarbeit mit Behörden<q>c_SEC Consult
Testmethodik und Zusammenarbeit mit BehördenSEC Consult

Was ist Red Teaming?

Ein Red-Team-Assessment ist eine Angriffssimulation, bei der möglichst realistisch echte Angreifer simuliert werden sollen, damit man ein klares Bild darüber erlangt, wie gut ein Unternehmen bei einem solchen Angriff aufgestellt wäre. Dabei werden TTPs von den APTs kopiert und an den entsprechenden Kunden angepasst.

Und genau das ist der große Unterschied zu einem „normalen“ Penetrationstest. Bei einem Pentest sollen in einer Applikation oder einem Netzwerk nach Möglichkeit alle Schwachstellen gefunden werden.

Bei einem TLPT (also Red Teaming unter DORA) geht es darum, den Angreifer zu erkennen und Maßnahmen zu ergreifen, um diesen zu stoppen.”

Die Theorie ist jetzt bekannt, jedoch abstrakt. Deswegen machen wir anhand eines Red-Teaming-Projekts, welches genauso stattgefunden hat, das Ganze ein wenig greifbarer.

So läuft es – ein Beispiel:

Wir haben einen Kundennamen und fangen mit der Info-Gathering-Phase an. Zuerst werden die Subdomains mit AMASS enumeriert. Dann prüfen wir mit EyeWitness, welche Services erreichbar und nützlich sein können, wie beispielsweise Loginseiten. Wir haben Glück und finden sowohl eine Citrix-Loginseite, die interessant werden kann, sobald wir gültige Credentials haben, als auch einige Loginseiten, die gegebenenfalls für Userenumeration genutzt werden können.

Autor Markus Koplin, Teamlead-Pentester SEC Consult
Geboren 1987, absolvierte Markus Koplin zunächst eine Ausbildung zum Kaufmännischen Assistenten für Wirtschaftsinformatik und zusätzlich zum Fachinformatiker für Systemintegration, bevor er einen Bachelor of Science in IT-Security abschloss. Seit 2018 ist er als Penetrationstester tätig und spezialisierte sich auf Red Teaming. 2022 übernahm er die Rollen des Teamleads und des Product Owners für Red Teaming bei SEC Consult (Website). Als Teamlead leitet er ein Team von Pentest-Experten, während er als Product Owner für die Entwicklung des Red-Teaming-Produkts verantwortlich ist. Von 2020 bis 2022 war er außerdem externer Dozent für Offensive Sicherheitsmethoden.
Parallel dazu prüfen wir, ob es nützliche Infos auf den Social-Media-Kanälen gibt, und werden fündig: ein Link zu einem Git-Repo, in dem zwar keine Passwörter vorhanden sind, aber die AD-Usernames. Jetzt wissen wir, wie diese aussehen, und können uns eine Liste mit möglichen Benutzernamen erstellen. Diese verifizieren wir mit einer der vorher gefundenen Loginseiten, die uns freundlicherweise sagt, ob ein Benutzername existiert oder nicht.

Jetzt haben wir Benutzernamen, aber noch keine Passwörter. Um hier ein paar gültige Kombinationen aus Username und Passwort zu finden, nutzen wir eine SSO-Seite des Unternehmens, um dort Password Spraying durchzuführen. Wenn unsere Loginversuche erfolgreich sind, werden wir zu einem zweiten Authentifizierungsfaktor weitergeleitet. Was erst mal wie ein Problem klingt, ist hier keins, denn der zweite Faktor wird nur erzwungen, wenn ein User sich von außerhalb des Firmennetzwerks anmeldet. Da Mitarbeiter in der Regel einen Arbeitsrechner haben, trifft das auf die wenigsten zu und wir können einfach eine App für den zweiten Faktor hinterlegen und uns so problemlos einloggen.

Die gültigen Credentials testen wir jetzt auf der vorher identifizierten Citrix-Seite. Nachdem wir einen zweiten FA beim Login registriert haben, funktioniert das problemlos und wir starten mit der Client-Enumeration. Schnell stellen wir fest, dass die verwendete EDR-Lösung für Powershell eine generelle Ausnahme konfiguriert hat und nur lokal Warnungen erstellt werden. Das erleichtert unser Leben massiv. Wir bauen eine Verbindung zu unserem C2 auf und kramen unsere Powershell-Tools aus der Schublade, die seit 2020 eigentlich nicht mehr nutzbar sind, weil sie sofort detektiert werden.

Da uns dieser Client gar nicht so sehr interessiert und wir weiter ins Netzwerk vordringen wollen, lassen wir die Powershell-Version von Sharphound laufen, um das AD zu enumerieren. Wie sich herausstellt, gibt es einen Server, auf den (warum auch immer) JEDER Benutzer per RDP connecten kann. Wir springen also direkt auf den nächsten Host und bauen eine weitere Verbindung zu unserem C2 auf, damit wir unsere Tools gar nicht erst auf den Host bringen müssen, sondern über einen SOCKS5 tunneln können. Durch die Analyse der AD-Daten in Bloodhound wissen wir bereits, welche User die Rechte eines DAs haben. Auf dem RDP-Host finden wir einige dieser DA User, sprich: wenn wir hier eine Local Privilege Escalation hinbekommen, stehen die Chancen gut, dass wir direkt zum Domain Admin werden. Das System ist jedoch gepatcht und es scheint keine Low-hanging-Fruits zu geben, die wir direkt ausnutzen können. Aber ein Kollege hat gerade in einem anderen Projekt eine Zero-Day gefunden, die auf diverse MSI-Installer anwendbar ist. Passend dazu hat er bereits ein Tool geschrieben, das den Host auf vulnerable MSI-Installer checkt. Wir lassen es laufen, werden fündig, basteln uns unsere eigene LPE und bekommen so System-Rechte auf dem RDP-Host.

Und hier wird es dann wirklich einfach. Wir dumpen über unseren C2 mit Mimikatz LSASS, übernehmen die Session von einem DA, der eine aktive Session auf dem System hat, und erstellen uns unseren eigenen DA. Mit diesen Rechten kümmern wir uns um die restlichen Objectives, die vorher festgelegt wurden, wie z.B. das Übernehmen von unternehmenskritischen Systemen.  .

… Ihr Unternehmen gehört jetzt uns. Aber wir geben es Ihnen zurück, zusammen mit Empfehlungen, wie es Ihr Unternehmen bleibt.

Herzlich willkommen bei TLPT.”

Markus Koplin, Teamlead-Pentester SEC Consult/aj

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert