Ransomware – eine latente Bedrohung [Teil 1]

Ransomware ist zwar schon lange ein Thema, jedoch alles andere als nur ein vorübergehendes Phänomen – im Gegenteil. Daher hielt Stephan Berger, Senior Cyber Security Analyst bei InfoGuard, an der diesjährigen Swiss Cyber Storm einen Vortrag zum Thema Ransomware und die aktuelle Bedrohungslage. In zwei Blogartikeln werden die wichtigsten Punkte seines Talks aufgezeigt und detailliert erklärt.

Beobachtungen, Erfahrungen und Learnings aus vergangenen Incidents sind enorm wichtig für die Arbeit des Incident-Response-Teams der InfoGuard. Bei Untersuchungen von kompromittierten Netzwerken sehen wir in vielen Fällen dieselben Muster, wodurch sich Angreifer initialen Zugriff in das Netzwerk verschaffen.

1) Phishing & MalDocs – oder das Stehlen von Zugangsdaten und Ausführen von bösartigen Dokumenten

Auch wenn User Awareness Trainings und Phishing-Kampagnen inzwischen bei vielen Firmen (teils sogar regelmässig) durchgeführt werden, gehören Phishing – also das Stehlen von legitimen Zugangsdaten – und das Ausführen von bösartigen Dokumenten, sogenannten «Malicious Documents» (MalDocs), immer noch zu den gängigsten Angriffsmethoden, um sich Zugang zum Firmennetzwerk zu verschaffen. Der Erfolg dieser Techniken erklärt sich unter anderem durch geschickte Täuschung der Benutzer, wie ich an der Swiss Cyber Storm an einem realen Case aufzeigte.

In Abbildung 1 (linkes Bild) erhielt ein Benutzer eine E-Mail von der Firma «Transfer24 GmbH». Darin schreibt die Firma, dass ein Paket zugestellt wird inklusive einem Link, wo die entsprechenden Dokumente abgelegt sind. Besonders trickreich: Die Angreifer haben nicht nur ein gezieltes Phishing-E-Mail gesendet, sondern auch telefonisch Kontakt aufgenommen, was Vertrauen schaffte. In (akzentfreiem) Deutsch wurde darauf hingewiesen, dass für den Empfang des Paketes die Bestätigung via Link in der E-Mail notwendig sei, ebenso wie die Installation der dazugehörigen Software («Track a Package»). Natürlich war die Software reine Tarnung. Mit dem Download wurde ein Trojaner installiert, wodurch die Angreifer einen ersten Fuss im Netzwerk hatten.

Abb. 1: Zwei Beispiele von bösartigen E-Mails resp. Dateien

Das rechte Bild in Abbildung 1 zeigt ein anderes Szenario; wiederum eine E-Mail. Nun könnte man denken, dass sensibilisierte Benutzer in der Lage sein sollten, diese E-Mail als verdächtig einzustufen, nicht? Einige vermutlich schon, andere aus durchaus nachvollziehbaren Überlegungen heraus nicht. In diesem Fall haben die Angreifer das E-Mail-Konto einer externen Firma übernommen und eine real vorhandene E-Mail-Konversation missbraucht, um präparierte Dokumente (Abbildung im OneDrive) an die Zielfirma zu senden. Hinzu kommt, dass OneDrive zum Austausch von Dokumenten mit Partnern gängig war, auch mit dem vermeintlichen Absender, und dadurch nicht verdächtig. Durch das Öffnen des präparierten Dokuments erhielten die Angreifer nun einen ersten Zugang in das Zielnetzwerk – und dies, komplett unbemerkt.

Schwachstellen als Achillesferse

Besonders in diesem Jahr wurden viele kritische Schwachstellen veröffentlich, mit denen sich Angreifer Zugang in Netzwerke verschafft haben. Eine populäre und stark ausgenützte Schwachstelle war «ProxyLogon» im Exchange Server, mit welcher Angreifer Code auf dem Server ausführen konnten. Eine der Empfehlungen von Microsoft war, neben dem zügigen Einspielen der Security Patches, das Scannen der Exchange Server mit dem «Microsoft Security Scanner».

Unser Team untersuchte im Zuge dieser Schwachstelle dutzende von potenziell gehackten Exchange Servern in der Schweiz sowie im Ausland. Vor der Kontaktaufnahme mit InfoGuard haben die Kunden in vielen Fällen den Microsoft Scanner schon auf den Systemen gestartet. Dabei wurden viele Web-Shells von Angreifern bereits erkannt und gelöscht – doch längst nicht in jedem Fall, wie das nächste Beispiel zeigt.

In Abbildung 2 sieht man den Pfad zu einer Web-Shell (in orange), die durch einen Angreifer auf dem Exchange Server mittels der ProxyLogon-Schwachstelle abgelegt wurde. Der Kunde hat vor der Kontaktaufnahme mit uns den Microsoft Scanner auf dem Server ausgeführt. Offensichtlich konnte der Scanner jedoch nicht alle Angriffsspuren erkennen und entfernen.

Abb. 2: Web-Shell innerhalb vom Exchange Pfad (Roter Kasten: Erstellungsdatum der Datei)

Bei der Analyse der platzierten Web-Shell wurden zwei Punkte deutlich (Abb. 3):

• Die Web-Shell war als «hidden» markiert. Die Datei konnte im Windows Explorer somit nicht gefunden werden, ausser, man aktiviert explizit das Anzeigen von versteckten Dateien.
• Die Datei konnte initial nicht gelöscht werden (siehe rote Fehlermeldung). Dies war erst möglich, nachdem die Dateiattribute angepasst wurden.

Abb. 3: Das Löschen der Web-Shell war erschwert. (Roter Kasten: Directory Listing – Verzeichnisanzeige vom Exchange-Verzeichnis. Oranger Kasten: Fehlgeschlagener Löschversuch der bösartigen Datei.)

Mit dem Problem hängt vermutlich auch der Microsoft Scanner zusammen. Dieser konnte die Datei zwar finden, jedoch nicht löschen. Dieser Punkt zeigt deutlich, dass man sich nur bedingt auf automatische Prüfungen verlassen kann und für eine tiefere Analyse in vielen Fällen auf ein Spezialisten-Team wie unseres angewiesen ist.

Ausweiten des Perimeters in die Cloud

In Abbildung 4 ist ein Screenshot der Schwachstellen-Suchmaschine «shodan.io» abgebildet. Darauf ist ersichtlich, dass ein Server in der Azure Cloud den Remote Desktop Protocol Port (RDP – Port 3389) im Internet exponierte.

Abb. 4: Exponierter RDP-Port im Internet

Der exponierte Zugang wurde von einer grösseren Schweizer Firma als Jump-Host für externe Consultants in das interne Netzwerk eingerichtet. Die Schwachstelle hier: Es gab keinen zweiten Authentisierungs-Faktor, wodurch die Angreifer das Passwort des Administrator-Kontos knacken konnten. Nach erfolgreich Login in den Jump-Host entwendeten die Angreifer weitere Passwörter. Zudem war der Azure Host mit dem internen On-Prem-Netzwerk verbunden, was zu einer kompletten Kompromittierung des Netzwerks führte.

Key Points & Lessons Learned

• Einsatz von Multi-Faktor-Authentifizierung (MFA): Jeder externe Zugang zum Netzwerk muss mit einem zweiten Faktor geschützt werden (VPN, Citrix, TeamViewer etc.). Dies verringert die Gefahr von abgeflossenen Credentials durch Phishing.
• «Assume breach» – auch, nachdem Patches eingespielt wurden: Am Beispiel der Exchange Server ist ersichtlich, dass Systeme schon vor dem Einspielen von Security Patches gehackt worden sein könnten. Eine Prüfung durch Spezialisten ist somit in einigen Fällen unausweichlich.
• Regelmässige Überprüfung der Cloud-Systeme: Alle grossen Cloud Provider bieten API und Command-Line-Zugänge an, mit denen eine einfache Übersicht aller Cloud-Systeme mit exponierten Ports erstellt werden kann.

2) Persistenzen und Hintertüren

In zahlreichen Untersuchungen fand unser InfoGuard CSIRT – neben den offensichtlich bösartigen Backdoors wie eingerichteten Scheduled Tasks oder AutoRuns-Einträgen – auch weitere, nicht als potenziell bösartig zu erkennende Backdoors von Angreifern. Innerhalb kurzer Zeit nach der initialen Kompromittierung des Netzwerkes haben Angreifer auf verschiedenen Server im Netzwerk legitime Remote-Desktop-Lösungen wie «AnyDesk» oder «Splashtop» installiert.

Abb. 5: Remote-Desktop-Lösungen

Für den System-Administrator ist auf den ersten Blick nicht ersichtlich, dass eine dieser Remote-Desktop-Lösungen von Angreifern als Backdoor installiert wurde. Solche Installationen haben für Angreifer den Vorteil, dass Anti-Virus-Lösungen diese Produkte nicht als bösartig erkennen und bei vielen Netzwerken im Einsatz sind. Auch nach einem Passwort-Wechsel der betroffenen Benutzer sowie einer gezielten Beseitigung des platzierten Angreifer-Codes, würde durch die Installation der Remote-Desktop-Lösungen immer noch ein Netzwerkzugang bestehen.

Wenig erstaunlich, hat unser Team in beinahe allen untersuchten Fällen Spuren des bekannten Angriff-Frameworks «Cobalt Strike» gefunden. Zig Personen und Unternehmen scannen das Internet nach bekannten Cobalt-Strike-Team-Servern ab und publizieren die gefundenen Informationen öffentlich, um dagegen anzukämpfen (siehe Abbildung 6). Security Teams können diese frei verfügbaren Quellen verwenden, um ihre Proxy- und Firewall-Logs auf Spuren von Cobalt Strike hin zu durchsuchen, um so eine Netzwerk-Kompromittierung durch Angreifer nachzuweisen.

Abb. 6: Eine Liste von Cobalt-Strike-Team-Servern im Internet (Quelle: The DFIR Report)

Key Points & Lessons Learned

• Überwachung von Verbindungen zu bekannten Remote-Desktop-Anbietern: Innerhalb der Proxy- und Firewall-Logs kann nach Verbindungen zu bekannten Remote-Desktop-Providern gesucht werden. Wenn ein kritischer Server beispielsweise eine AnyDesk-Verbindung aufbaut, könnte dies Zeichen einer tieferen Kompromittierung sein.
• Verwendung von frei verfügbaren Informationen: Im Internet werden viele IP- und Domain-Listen veröffentlicht, die für das Tracken und Suchen von Angreifern im eigenen Netz verwendet werden können.
• Verbindungsdaten von Remote-Desktop-Produkten: Verschieden Produkte wie AnyDesk und TeamViewer schreiben Verbindungsdaten, zu welcher Zeit sich welcher Benutzer eingeloggt hat. Diese Daten können bei der Aufklärung helfen, ob die Installation eines Produktes legitim ist oder ob ein potenzielles Backdoor eingerichtet wurde. Im Falle eines Incidents können diese Verbindungsdaten wertvolle Informationen liefern, zu welchen Zeitpunkten sich die Angreifer in das Netzwerk eingeloggt haben.

Sie merken: Ransomware ist eine komplexe Thematik, die Erfahrung und Fachwissen erfordert. Im zweiten Teil erfahren Sie vier weitere spannende Insights und Take-outs rund um Ransomware und aus unserem Alltag im CSIRT. Wenn Sie diesen sowie weitere Artikel nicht verpassen wollen, abonnieren Sie jetzt unsere Blog-Updates! Damit erhalten Sie wöchentlich den neusten Artikel direkt in Ihre Mail-Box.