Hackerangriff auf Kaseya VSA-Server: Hätte man ihn abwenden können?

Um es kurz zu machen: Trotz der vorhandenen Kaseya Schwachstelle hätte eine geeignete Endpoint Security Lösung Schlimmeres verhindern können. Die Malware wäre im äußersten Falle zwar installiert worden; die Security Lösung hätte aber deren Ausführung - und damit auch die Verschlüsselung der Endpoints - verhindert.

Aber der Reihe nach. In vielen Medien war kürzlich zu lesen: "Hacker-Angriff über IT-Dienstleister Kaseya trifft Hunderte Unternehmen". So liest man beispielsweise bei heise online „Bei der jüngsten Attacke mit Erpressungssoftware haben Hacker auf einen Schlag hunderte Unternehmen ins Visier genommen. Sie nutzten eine Schwachstelle beim amerikanischen IT-Dienstleister Kaseya, um dessen Kunden mit einem Programm zu attackieren, das Daten verschlüsselt und Lösegeld verlangt. Folgen waren bis nach Schweden zu spüren, wo die Supermarkt-Kette Coop fast alle Läden schließen musste. (…) IT-Sicherheitsexperten hatten die Attacke anhand des Software-Codes der Hackergruppe REvil zugeordnet, die in Russland verortet wird". Selbst eine schwäbische Regionalzeitung schreibt, dass ein Unternehmen mit 70 Mitarbeitern im Raum Stuttgart Opfer dieses Angriffs wurde. (Waiblinger Zeitung, 6.7.2021) 

Daran sehen wir, dass es nicht nur die großen, sondern auch die kleinen und mittelständischen Unternehmen trifft.

Wir wissen zum Zeitpunkt eines Angriffs bei einem Zero Day Exploit – also beim gezielten Ausnutzen einer bekannten oder unbekannten Schwachstelle in einer Software – noch nichts über die Angriffstaktik bzw. über die Angriffsvektoren. Wir wissen aber, dass wir uns vor dem Unbekannten schützen müssen. Deshalb geht es mir nicht so sehr um die Schwachstelle in der Kaseya Infrastruktur an sich, sondern vielmehr darum, wie wir erfolgreich das Ausnutzen sämtlicher Schwachstellen verhindern können und Unternehmen somit glimpflich davonkommen.

Ich fasse die teils komplexen Abläufe zusammen und zeige am Schluss auf, an welcher Stelle jeweils die DriveLock Lösung hätte helfen können, Schlimmeres zu vermeiden. Für die folgenden Abschnitte verweise ich auf die Sophos-News Website.

REvil war es möglich, seinen Dropper ohne Prüfung über den Kaseya Agenten bei sämtlichen Kunden lokal einzusetzen und auszuführen. Bestimmte Verzeichnisse auf dem Endpoint werden durch Ausschlüsse bewusst und gewollt vom Kaseya Agenten ignoriert. Damit war der Weg frei für eine bösartige Payload agent.crt Datei, die in das Arbeits-Verzeichnis des VSA-Agenten für Updates geschrieben wurde. Nach der Bereitstellung der Payload führte der Kaseya Agent dann die folgenden Windows-Shell-Befehle aus, die zu einer einzigen Zeichenfolge verkettet wurden:

Quelle / Bild

• Durch den Ping wurde zunächst eine Art Countdown von ca. 94 min. initiiert, bevor es losging.
  
  
• Der nächste Teil der Befehlszeichenfolge ist ein PowerShell-Befehl, der versucht, die wichtigsten Malware- und Anti-Ransomware-Schutzfunktionen von Microsoft Defender zu deaktivieren.

Bereits hier hätte die DriveLock Lösung das Deaktivieren des Defender Antivirus durch einen Event erkannt und sofort den Status Quo durch eine EDR-Response auf dem Endgerät wieder hergestellt. Ggf. hätte Defender später den Missbrauch einer bekannten und veralteten Datei verhindert.

• Die schadhafte Payload-Datei agent.crt wird dekodiert und in die ausführbare Datei agent.exe im Kaseya Arbeitsordner geschrieben. Danach werden die Dateien gelöscht und somit die Spuren verwischt.
  
  
• Schließlich wird Kaseya agent.exe gestartet (mit System-Privilegien) - und das eigentliche Droppen der Ransomware beginnt.
  
  
• agent.exe kopiert die unerwartete Datei msmpeng.exe und legt zusätzlich eine bösartige Datei namens mpsvc.dll neben der ausführbaren Datei msmpeng.exe ab. msmpeng.exe ist eine veraltete und abgelaufene Version der ausführbaren Datei von Microsofts Antimalware Service. Dies ist eine gutartige, aber anfällige Anwendung von Windows Defender.
  
  
• Diese Version von msmpeng.exe ist bekanntermaßen anfällig für Side-Loading-Angriffe. Bei einem Side-Loading-Angriff wird bösartiger Code in eine Dynamic Link Library (DLL) eingefügt, die so benannt ist, wie es das Executable erwartet. agent.exe führt dann msmpeng.exe aus, das die bösartige Datei mpsvc.dll erkennt und sie in seinen eigenen Speicherbereich lädt.
  
  
• Sobald die DLL in den Speicher geladen ist, wird sie von der Malware von der Festplatte gelöscht.
  
  
• Die msmpeng.exe, die nun unter der Kontrolle der bösartigen mpsvc.dll steht, beginnt, die lokale Festplatte, angeschlossene Wechsellaufwerke und zugeordnete Netzlaufwerke zu verschlüsseln, und das alles von einer von Microsoft signierten Anwendung aus, der die Sicherheitskontrollen normalerweise vertrauen und die ungehindert ausgeführt werden kann.

Die DriveLock Endpoint Security Lösung kann die Ausführung der Datei msmpeng.exe verhindern. Diese Anwendung wäre nie Teil der Whitelist gewesen und somit hätte das Modul DriveLock Application Control die Ausführung verweigert.

DriveLock beinhaltet ebenso out-of-the-box „Microsoft blocking rules“, wo es alte Versionen wie z.B. BGinfo.exe blockt, da diese Schwachstellen enthalten. Genau so hätten wir via Blacklisting die alte MSPENG.exe gesperrt, bzw. nur aktuelle Versionen dieser Anwendung erlauben können.

Wenn der Angriff an irgendeiner Stelle darauf basiert, dass Angreifer eigene Binaries (exe oder dll) zur Ausführung bringen, dann werden sie geblockt, weil sie nicht auf der Whitelist stehen.

Ebenso kann das Laden von DLLs mit DriveLock gesteuert und kontrolliert werden. Somit hätte auch kein Programm mpsvc.dll geladen.

Selbst wenn diese Mechanismen nicht gegriffen hätten, kann DriveLock Application Behavior Control das normale Verhalten eines Programms erlernen und nach abgeschlossener Lernphase alle Abweichungen von der Norm blockieren. D.h., wenn ein Programm während der Lernphase die Anwendung msmpeng.exe (oder PowerShell et al.) nicht gestartet hat, dann wird es das danach nicht mehr können, weil es vom erlernten Verhalten abweichen würde. Selbst dann nicht, wenn der Administrator noch nie etwas von dieser Anwendung gehört hat. Das ist Schutz vor dem Unbekannten!

Stellen Sie sich Application Control wie eine Gästeliste vor. Nur wer auf der Liste steht, darf auf die Party. Stellen Sie sich Application Behavior Control wie einen Verhaltenskodex vor. Nicht gewolltes Verhalten wird unterdrückt, selbst wenn der Gast schon auf der Party ist.

DriveLock verwaltet mit seinem Native Security Modul auch Microsoft Defender Antivirus. Eine Response als Folge einer DriveLock EDR-Regel startet den Defender Antivirus unmittelbar wieder.

• Die Ransomware machte aber noch mehr. Sie führt einen NetShell-Befehl (netsh) aus, um die Firewall-Einstellungen so zu ändern, dass das lokale Windows-System von anderen Computern im lokalen Netzwerk erkannt werden kann (netsh advfirewall firewall set rule group="Network Discovery" new enable=Yes ). Dann beginnt es, Dateien zu verschlüsseln.

Auch hier erkennt DriveLock durch das neue Native Security Feature zum Managen der lokalen Firewall ein Event und kann als Response gleich wieder die DriveLock Policies zum Setzen der Firewall Settings erzwingen! Weitere Endpoints im Unternehmensnetzwerk wären unentdeckt geblieben und das sogenannte lateral  movement ausgeblieben.

Wie Sie sehen, sprechen wir hier mit all den genannten Maßnahmen sogar von einem stufengestaffelten Schutz-Mechanismus. Deshalb ist der Einsatz der DriveLock Zero Trust Plattform so wichtig.

DriveLock verbindet die Elemente Data Protection, Endpoint Protection, Endpoint Detection & Response und Identity & Access Management.