Wir bei der NSIDE haben uns ein Ziel gesetzt: Realistische Angriffssimulationen durchzuführen und damit reale, greifbare Risiken aufzeigen. Dies zieht sich durch jeden unserer Pentests. Wir sind der Meinung: was nicht nachgewiesen werden kann landet auch nicht im Bericht (außer natürlich es gibt eindeutige Indikatoren, dass es trotzdem problematisch sein kann oder es sind Verstöße gegen Best-Practices).

Mit einer immer stärkeren Verbreitung von Cloud-Infrastruktur und einem Shift von klassischer On-Premises-Infrastruktur hin zu großen Cloudanbietern hat sich auch die Art und Weise geändert, wie wir Pentests durchführen.

Klassische Pentests

Unsere Pentests des internen Netzes und Active Directory laufen für gewöhnlich so ab: wir lassen uns von unserem Kunden einen Laptop zuschicken und senden selber unsere sogenannte Pentest-Box an den Kunden. Diese Box wird genutzt, um einen Angreifer mit Zugang zum internen Netz zu simulieren. Der Laptop simuliert die Infektion eines Mitarbeitenden-Laptops mit Schadsoftware (z.B. durch Phishing oder Diebstahl). Hierdurch lassen sich zwei übliche und häufig vorkommende Angriffsszenarien abbilden. Von hier aus werden übliche Tools wie Bloodhound und Nmap genutzt, um eine Übersicht über sowohl das Active Directory als auch das interne Netz zu bekommen. Normalerweise ergeben sich hier einige Angriffspfade, die (erstaunlich häufig) zur vollständigen Kompromittierung des Netzwerkes führen.

Dies ist dem Grund geschuldet, dass Active Directory und die verwendeten Protokolle (LDAP, NTLM, Kerberos, …) in einer Zeit entworfen wurden, wo an Zero-Trust noch nicht zu denken war. So kann jeder Nutzer üblicherweise beispielsweise alle Computer des Active Directories auflisten und, wenn sie nicht netzwerkseitig separiert sind, kontaktieren. Alleine dieser Fakt bietet eine unglaublich große Angriffsoberfläche, ausgehend von einem einzigen infizierten System.

Zusätzlich gibt es Angriffe, die als Voraussetzung nur eine Line-of-Sight zum Domain Controller und ein gültiges Nutzerkonto brauchen (z.B. Kerberoasting). In manchen Umgebungen ist dies bereits ausreichend, um Domain Admin zu werden.

Was die Cloud besser macht

Auf der anderen Seite stehen heutzutage moderne Cloud-Architekturen. Alle großen Cloud-Anbieter haben ihre Dienste nach dem Zero-Trust Prinzip und dem Least-Privilege-Prinzip entworfen. Das bedeutet beispielsweise im Azure-Kontext, dass ein Nutzer nicht einmal Informationen über eine Ressource auslesen kann, ohne explizit eine Reader-Rolle zugewiesen bekommen zu haben. Ähnliche Konzepte existieren auch bei andern Cloud-Providern. Für den Angreifer bedeutet das wiederum: er hat keine Möglichkeit zu unterscheiden, ob eine Ressource existiert oder ob das aktuelle Nutzerkonto einfach nicht die benötigten Berechtigungen besitzt.

Wichtig ist hierbei: dies bezieht sich nur auf die eigentlichen Azure-Ressourcen (beispielsweise Key Vaults, Storage Accounts, virtuelle Maschinen, etc.). So kann z.B. ein Nutzer im Entra-ID standardmäßig Informationen über alle anderen Nutzer auslesen.

Der bisherige Ansatz „wir lassen uns in die Umgebung werfen und schauen, wohin wir kommen“ funktioniert also in modernen Cloud-Umgebungen in dieser Form heutzutage nicht mehr. Für uns haben sich in letzter Zeit zwei Ansätze etabliert, die ich etwas näher beleuchten möchte.

  1. Ein Whitebox-Ansatz (ein Audit) mit einem Reader-Account
  2. Eine was-wäre-wenn Simulation mehrerer Service Principals und/oder Nutzer mit vorhergehendem Threat Modelling.

Der Whitebox-Ansatz

In dieser Analyse bekommen wir als Pentester einen Account, der jene notwendigen Reader-Berechtigungen hat. Von hier wird aus der Vogelperspektive auf die Infrastruktur geschaut und Fehlkonfigurationen werden über die üblichen administrativen Werkzeuge ermittelt. Die Vorteile scheinen zunächst klar auf der Hand zu liegen: mit lesendem Zugriff auf alle Ressourcen können (theoretisch) alle sicherheitsrelevanten Konfigurationen eingesehen werden.

Doch was sind die daraus wirklich erkennbaren Risiken und welche Maßnahmen lassen sich aus so einem Audit-Test wirklich ableiten? Jeder, der Defender for Cloud oder den Azure Secure Score schon genutzt hat weiß, dass üblicherweise eine Flut von Alerts aufgrund einzelner Fehlkonfigurationen aufkommen. Eine Priorisierung ist hier genauso notwendig wie eine Abschätzung, welche Fehlkonfigurationen einen wirklichen Security-Impact haben. Diesen Teil übernehmen wir natürlich in diesem Ansatz, aber einen wirklich realistischen Angreifer kann man hierdurch nicht abbilden. Deswegen gibt es auch noch den zweiten Ansatz:

Der Was-Wäre-Wenn-Test

Eine deutlich realistischere Abbildung von Angreifern lässt sich erreichen, wenn echte Angriffsketten erkannt und simuliert werden. Während wir in klassischen On-Premises-Tests diese Informationssammlung (wie weiter oben bereits angesprochen) selber durchführen konnten, ist dies hier aus oben genannten Gründen nicht mehr realisierbar. Deswegen nutzen wir eine andere Vorgehensweise: wir setzen uns mit unserem Kunden zusammen und analysieren gemeinsam mögliche Einfallstore, beispielsweise:

  • Was wäre, wenn Ihre CI/CD-Pipeline durch einen Supply-Chain-Angriff kompromittiert wird?
  • Was wäre, wenn es eine Sicherheitslücke in der Webanwendung gibt und ein Angreifer Code auf dem Kubernetes-Cluster ausführen kann?
  • Was kann passieren, wenn dieser S3-Bucket aus Versehen anonymen Zugriff erlaubt?
  • Wäre es möglich, kritische Daten abfließen zu lassen, wenn das O365-Konto eines Mitarbeiters kompromittiert wird?
  • Und viele, viele weitere Szenarien…

Anhand dieser Szenarien kann dann ein tatsächlicher Pentest durchgeführt werden, der genau diese Fragen beantwortet. Als Startpunkt dienen die vorher definierten Ausgangsszenarien. So wird zum Beispiel ein Dienstkonto für den Test mit denselben Berechtigungen, wie das echte Dienstkonto hat, angelegt. Folglich lässt sich nach Abschluss der Tests ganz konkret die Frage beantworten: Was kann passieren, wenn unsere Webanwendung/Kubernetes/etc-Umgebung kompromittiert wird?

Das Beste aus beiden Welten

Ein hybrider Ansatz kann hier natürlich das Beste aus beiden Welten bedeuten. Zunächst wird mit einem „was-wäre-wenn“-Szenario gestartet. Wenn sich herausstellt, dass es für Angreifer an dieser Stelle nicht weitergeht, kann in einen Whitebox-Ansatz übergegangen werden. So können Risiken erkannt werden, die zum aktuellen Zeitpunkt nicht ausnutzbar sind, in der Zukunft aber gefährlich werden können.

Wenn Sie Interesse an einem Test (sowohl Ihrer On-Premises- als auch Ihrer Cloud-Umgebung) haben, kommen Sie gerne auf uns zu. Wir freuen uns von Ihnen zu hören.