Blog Post

Der Solarwinds Hack – Eine Blaupause für Red Teams?

Der Solarwinds Hack ist in aller Munde, aber was so richtig passiert ist, wird aus den aktuellen Pressemeldungen oft nicht klar. Es fallen Begriffe wie „Advanced“ oder besonders guter „Operational Security“ (OPSEC). In diesem Artikel wollen wir ein paar interessante Einblicke geben und Quellen mit weiterführenden Informationen nennen, auch wenn dies bei der Komplexität des Themas sicher nicht vollumfänglich möglich ist. Die Attribution des Angriffs, wer jetzt wen mit welchen Interessen angegriffen hat, wollen wir alleine deshalb schon den Behörden überlassen.

Nun aber von vorne, was ist überhaupt passiert. Es wurde die IT-Firma SolarWinds Inc. Kompromittiert und in deren Produkt die „Orion Plattform“ eine Hintertür eingebaut. Diese Software wird für die Überwachung von Netzwerken genutzt. Unteranderem sind wohl Funktionen der Plattform wie etwa „Network Performance Monitor“ und „Server Configuration Monitor“ betroffen (Link: Orion Plattform, SolarWinds Security Advisory). Um die umfangreichen Aufgaben erfüllen zu können, wird von SolarWinds empfohlen, die Software mit administrativen Rechen zu betreiben, desweitern wird vom Hersteller empfohlen, dass der Ordner, in dem sich die Software befindet, von der Prüfung von Antivirensoftware ausgenommen ist. Die Backdoor wurde durch den regulären Update Prozess bei den Kunden installiert und war durch das digitale Zertifikat der Firma SolarWinds signiert (Link: Fireeye)

. Aktuell werden in der Presse vielen US-Behörden und Unternehmen als Opfer genannt. Die Liste der Opfer dürfte allerdings viel größer sein. Da jeder kompromittierte Server eine einzigartige Subdomain für die Kommunikation mit dem Kontrollserver nutzt, kann man die Anzahl der eventuell betroffenen Server relativ gut zählen. Der Anbieter Cloudflare hat eine Analyse ihrer DNS-Server veröffentlicht (Link: Cloudflare). Demnach sind von April bis September 2020 etwa 200-400 neue Opfer pro Woche hinzugekommen. Bis Oktober wurden etwa insgesamt 5.000 Server kompromittiert. Dies dürfte nur ein kleiner Teil der Opfer sein, da laut SolarWinds etwa 300.000 Firmen die Orion Plattform einsetzten. Dabei sind die Server keineswegs nur in den USA lokalisiert, sondern auf allen Kontinenten verteilt.

Wie konnte ein Angriff also in diesem Ausmaß und auf so viele Kunden verteilt so lange unentdeckt bleiben? Die Angreifer haben viel Aufwand betrieben, um unentdeckt zu bleiben, der hinzugefügte Programmcode (Link: Github) ist sehr unauffällig und unterstützt nur sehr rudimentäre Befehle (Link: Fireeye) etwa, um weiteren Code nachzuladen. Des weiteren überprüft der Code ob Antivirensoftware auf dem Server läuft und schränkt seine Aktivitäten entsprechend ein. Darüber hinaus nimmt der Code erst nach 12-14 Tagen das erste Mal Kontakt zu dem Kontrollserver auf (Link: Twitter). Dadurch wird versucht, Erkennungsversuche durch Sandboxsysteme und eventuelle Überwachung nach einem Softwareupdate zu umgehen. Die dann erfolgende Kommunikation imitiert die der SolarWinds Software mit deren Infrastruktur.

Mit dem erlangten Zugang wird nun Schadsoftware nachgeladen, welche unter anderem einen modifizierten Cobalt Strike Beacon im Arbeitsspeicher ausführt. Dadurch wird die Erkennung durch EDR  (Endpoint Detection and Response) Software weiter erschwert, darüber hinaus wurde diese wohl auch teilweise deaktiviert. Die Ausbreitung im Netzwerk und eine Persistenz scheint unter anderem durch die Kompromittierung von Schlüsseln welche den Login in Azure und on-premise Active Directory absichern zu erfolgen (Link: NSA). Welche Daten für die Angreifer interessant waren und welche kritischen Funktionen diese kompromittiert haben, ist bisher nur wenig öffentlich bekannt.

Die Anzahl der möglichen Opfer dürfte für die Angreifer auch zu groß sein, um diese in vertretbarer Zeit abzuarbeiten, daher kann nur spekuliert werden, dass hier bei einigen Opfern „nur“ eine Persistenz für einen eventuellen späteren Zugriff geschaffen wurde (Link: Microsoft).

All die genannten Methoden, wie etwa Custom Malware mit minimalen Funktionen, um eine Persistenz zu schaffen, das nachladen von Cobalt Strike oder einem anderen Command & Control Framework, die Vermeidung der Erkennung durch EDR Software simulieren wir auch in unseren Red Team Assessments. In der Vergangenheit lag hier der Fokus aber meistens auf einer Kompromittierung (Intial Access) durch Phishing eines Mitarbeiters oder falls möglich auch durch einen Angriff auf die externe Infrastruktur. Ein Angriff auf die Supply Chain von Software, welche legitim im Netzwerk genutzt wird, wurde bisher oft als abwegiges oder zu aufwendiges Szenario abgelehnt. Dies kann aber durchaus in einem Red Team Assessement simuliert werden. Natürlich können wir aus strafrechtlichen Gründen keine Zulieferer kompromittieren, dies kann aber durchaus simuliert werden, indem angepasste Malware auf einem entsprechenden System (Assumed Breach) platziert und die Kommunikation an das entsprechende Szenario anpasst wird.

Die Folgen und Umfang dieses Angriffs werden wohl noch weiter analysiert werden müssen. Sicher aber scheint es, dass dieser die Sicherheitsgemeinde und den Rahmen was man für ein realistisches Angriffsszenario gehalten hat langfristig verändern wird.

Related Posts