Red Teaming für DORA: Aufbruch zu neuen Angriffsszenarien! TIBER und Threat Led Penetration Test (TLPT)
Schwerpunkt: Threat Intelligence. . Wurde Ihr Unternehmen bereits von Ihrer zuständigen Finanzaufsichtsbehö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.. Neben den allgemeinen Anforderungen für das Testen der digitalen operationalen Resilienz im Rahmen des Testprogramms von Finanzunternehmen, führt DORA ebenfalls erweiterte Tests von IKT Tools, -Systemen und -Prozessen auf Basis des sogenannten Threat Led Penetration Test (TLPT) ein. TLPT basiert auf dem TIBER EU Rahmenwerk. In einer aktuellen Publikation, fordert die EZB Unternehmen und Regulatoren dazu auf TIBER als Methode zur Umsetzung von DORA TLPT zu verwenden. Damit sind Dienstleister, welche bereits TIBER Tests durchgeführt haben, bestens vorbereitet, 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 zum Beispiel der deutschen Bundesbank, validiert. . 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 Login Seiten. Wir haben Glück und finden sowohl eine Citrix Login Seite, die interessant werden kann, sobald wir gültige Credentials haben, als auch einige Login Seiten, die gegebenenfalls für Userenumeration genutzt werden können. 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 Login Seiten, 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 zum Beispiel 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.”Sie hörten einen Beitrag von “Markus Koplin, Teamlead Pentester SEC Consult/aj”
Sie finden diesen Artikel im Internet auf der Website: https://itfm.link/217413
Wurde Ihr Unternehmen bereits von Ihrer zuständigen Finanzaufsichtsbehö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
Neben den allgemeinen Anforderungen für das Testen der digitalen operationalen Resilienz im Rahmen des Testprogramms von Finanzunternehmen, führt DORA ebenfalls erweiterte Tests von IKT-Tools, -Systemen und -Prozessen auf Basis des sogenannten Threat Led Penetration Test (TLPT) ein. TLPT basiert auf dem TIBER-EU-Rahmenwerk. In einer aktuellen Publikation, fordert die EZB Unternehmen und Regulatoren dazu auf TIBER als Methode zur Umsetzung von DORA TLPT zu verwenden. Damit sind Dienstleister, welche bereits TIBER-Tests durchgeführt haben, bestens vorbereitet, 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.
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 Login-Seiten. Wir haben Glück und finden sowohl eine Citrix-Login-Seite, die interessant werden kann, sobald wir gültige Credentials haben, als auch einige Login-Seiten, 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 Login-Seiten, 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
Sie finden diesen Artikel im Internet auf der Website: https://itfm.link/217413
Schreiben Sie einen Kommentar