Angriffssimulationen durch Red Teams Anatomie eines simulierten Cyberangriffs

Ein Red-Team ist eine Gruppe von Security-Experten, die Unternehmen durch Angriffs­simulation beim Aufdecken von Schwachstellen unterstützt. Auf Basis der gewonnenen Erkenntnisse können Unternehmen dann adäquate Verbesserungen umsetzen und Abwehrmaßnahmen ergreifen. Am Beispiel des Red-Team von CyberArk zeigen wir, wie ein solches Team bei einer Angriffssimulation im Detail vorgeht!

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Arvato Systems

Keeper Security EMEA Ltd.

CyberArk Software (DACH) GmbH

Ein größeres Unternehmen hat bereits mehrere Millionen US-Dollar in Sicherheit investiert, vor allem in die Perimeter- und Endpunkt-Sicherheit. Die meisten vertraulichen Daten, etwa Finanz-, Personal- und Kundendaten – das heißt seine zentralen Geschäftsdaten – hatte es im Rahmen einer DevOps-Ausrichtung in die Public Cloud migriert. Das Unternehmen hat CyberArks Red-Team beauftragt, einen Angriff auf die Public-Cloud-Infrastruktur zu simulieren, um Zugang zu diesen zentralen Geschäftsdaten zu erhalten. Es bestand darauf, dass CyberArk „praktisch aus dem Nichts“ startet, das heißt von außerhalb des Unternehmens.

Das Red-Team begann mit Phishing und dem Klonen des E-Mail-Portals des Unternehmens. Einige Mitarbeiter gaben daraufhin ihre Zugangsdaten auf der Phishing-Seite ein; damit gelangte CyberArk ins Netzwerk, allerdings noch limitiert hinsichtlich der Zugriffsmöglichkeiten. Deshalb sammelte das Red-Team zunächst Informationen aus dem Active Directory: Welche privilegierten Accounts gibt es? Wer hat welchen Zugang im Unternehmen? Womit sind diese privilegierten Accounts verbunden?

Das Team ermittelte, dass die Zugangsdaten eines von ihm kompromittierten Rechners auch auf anderen Rechnern im Netzwerk genutzt wurden, sodass es sich seitwärts dazu bewegen konnte. Ein Gerät war die Workstation eines IT-Mitarbeiters, auf der ein Domain-Admin-Account vorhanden war. In On-Premises-Unternehmen könnte dies bereits eine „Game-Over"-Situation sein, denn an diesem Punkt könnte ein Angreifer jede andere Maschine im Netzwerk kompromittieren und Zugriff auf alle verfügbaren zentralen Geschäftsdaten erhalten.

Das Unternehmen hatte seine zentralen Geschäftsdaten aber in die Cloud verlagert. Die Herausforderung bestand nun darin, vom On-Premises-Zugang zur Public-Cloud-Infrastruktur zu gelangen.

Unter Nutzung der neu erworbenen Domain-Admin-Privilegien war das nächste Ziel des Red-Teams die Entwicklungsabteilung. Es verwendete dabei einen nativen Remote-Zugang, um Malware auf dem Rechner eines DevOps-Ingenieurs auszuführen. Darauf fanden die Analysten ein Verwaltungstool, das zur Verbindung mit einem Remote-Server genutzt wurde – und zwar mit einem in der Cloud-Infrastruktur. Zudem wurde ein privilegierter Zugang in Form eines SSH-Keys entdeckt, der lokal auf dem Rechner gespeichert war. Diesen SSH-Key nutzte das Red-Team für die Verbindung mit einem Rechner in der Public-Cloud-Infrastruktur des Unternehmens. Es hatte damit zwar immer noch nicht die zentralen Geschäftsdaten, aber bewiesen, auf die Cloud zugreifen zu können – und an diesem Punkt nutzten sie die nächste Schwachstelle.

Cloud-Anbieter ermöglichen Unternehmen, Cloud-Ressourcen bestimmte Berechtigungen zuzuweisen. Dies erlaubt zum Beispiel die Kommunikation eines Rechners mit einem Storage-Gerät. Allerdings werden diese Berechtigungen als Cloud-native API-Keys gespeichert und sind damit zugänglich für jeden User mit Zugriffsmöglichkeit auf das Betriebssystem des Rechners.

Das Red-Team nutzte seinen Zugang zu dem Cloud-Rechner, um auf solche Cloud-APIs zuzugreifen. Das gab ihm die volle Kontrolle über die Umgebung und Zugriff auf das Ziel. Die CyberArk-Mitarbeiter machten ein Back-up von allen Servern, die das Unternehmen nutzte – insgesamt 375 – und verbanden sie mit einem neuen Account, den sie beim selben Public-Cloud-Provider angelegt hatten. Das Unternehmen bekam nicht einmal mit, dass seine gesamte Umgebung „gestohlen“ wurde. Alles, was für das Kopieren der Umgebung benötigt wurde, war der Zugriff auf einen einzigen Server mit dem richtigen API-Zugang.

Doch wie hätte das Red-Team gestoppt werden können? Zu Beginn hätte die Umsetzung von Least-Privilege-Prinzipien auf allen Endpunkten des Unternehmens den „Spielraum“ bereits stark einschränkt. Die mehrfache Verwendung derselben Zugangsdaten in der On-Premises-Umgebung führte dazu, dass eine „Seitwärts-Bewegung“ unterstützt wurde; dies sollte niemals der Fall sein. Die auf dem Anwenderrechner gespeicherten SSH-Keys ermöglichten dann, von der On-Premises-Infrastruktur auf die Cloud-Umgebung zu gelangen. Schließlich erlaubten die Cloud-API-Keys, die uneingeschränkte Zugriffe boten, die Kontrolle über die gesamte Cloud-Infrastruktur zu übernehmen. An diesem Punkt findet sich vielfach ein Trugschluss auf Unternehmensseite: Die Sicherung dieser Keys ist nicht die Aufgabe des Cloud-Providers, sondern des Cloud-Nutzers, der die Cloud-Umgebung als Erweiterung seiner internen Infrastruktur betrachten und entsprechend sichern muss, das heißt, das auslagernde Unternehmen bleibt für den Schutz seiner Daten verantwortlich. Deshalb muss es auch alle privilegierten Zugangsdaten zur Cloud-Infrastruktur – insbesondere auch SSH- und API-Schlüssel – adäquat verwalten, sichern und überwachen. Damit wäre auch der CyberArk-Angriff schnell gestoppt worden.

Der Diebstahl privilegierter Zugangsdaten ist ein entscheidendes Element für die Durchführung von Cyber-Angriffen. Das Red-Team von CyberArk hilft Unternehmen deshalb bei der Ermittlung aller mit privilegierten Accounts verbundenen potenziellen Gefahren und unterstützt bei der Einführung adäquater Sicherheitsmaßnahmen.

Über den Autor: Shay Nahari ist Head of Red-Team Services bei CyberArk.

(ID:45622325)