von Bhabesh Raj, Associate Security Analytics Engineer
Am Patch-Tuesday im Juni 2021 hat Microsoft die Print-Spooler-Schwachstelle CVE-2021-1675 in Windows behoben. Zeitgleich wurde eine ähnliche Schwachstelle mit dem Namen „PrintNightmare“ entdeckt, deren Proof-of-Concept (PoC) versehentlich veröffentlicht wurde. Aufgrund der Verwechslung dieser beiden Schwachstellen wurde PrintNightmare letztlich zu einem Zero-Day-Exploit. Inzwischen sind mehrere PrintNightmare PoC-Exploits im Umlauf, die es jedem authentifizierten Benutzer ermöglichen, SYSTEM-Rechte für Systeme zu erhalten, auf denen der Print Spooler-Dienst ausgeführt wird.
Ursprünglich als Privilege-Escalation-Schwachstelle von geringem Schweregrad eingestuft, erhöhte Microsoft am 28. Juni den Schweregrad von CVE-2021-1675 auf „kritisch“, da die Schwachstelle Remote-Code-Ausführungen (RCE: Remote Code Execution) ermöglicht. Zufälligerweise ermöglicht auch PrintNightmare Remote-Code-Ausführungen, was zur Verwechslung von CVE-2021-1675 und PrintNightmare führte.
Beide Schwachstellen sind sehr schwerwiegend, da der Print-Spooler-Dienst – mit Ausnahme von „Server Core“ – standardmäßig aktiviert ist. Domain-Controller sind und bleiben ein lohnendes Ziel für Angreifer, da sie die vollständige Kompromittierung einer Domäne ermöglichen können.
Die PrintNightmare-Schwachstelle entsteht dadurch, dass jeder authentifizierte Benutzer einen neuen Druckertreiber installieren und eine Treiberdatei angeben kann, die auf einem Server im Unternehmensnetzwerk gespeichert ist. So führt der Print-Spooler-Dienst Code in einer beliebigen DLL (getarnt als Druckertreiber) mit SYSTEM-Rechten aus. Bedrohungsakteure haben aufgrund der Verfügbarkeit mehrerer funktionierender PoCs vermutlich ihren großen Tag – und die Verwirrung in der Security-Community bezüglich CVE-2021-1675 und PrintNightmare macht es noch schlimmer.
Da kein Patch verfügbar ist, empfehlen wir, den Print Spooler-Dienst auf nicht benötigten Rechnern zu deaktivieren. Administratoren können die Einstellungen für die Gruppenrichtlinien (GPP: Group Policy Preferences) verwenden, um den Print-Spooler auf Rechnern in einer gesamten Domäne zu deaktivieren. Dabei gilt es zu beachten, dass kleine Unternehmen ihre Domain-Controller in der Regel so konfigurieren, dass sie auch als Print-Server fungieren. Für diese Unternehmen ist es nicht praktikabel, den Print-Spooler-Dienst zu deaktivieren, da dies ihre täglichen Geschäftsabläufe beeinträchtigen würde. Falls der Print-Spooler auf einigen Servern ausgeführt werden muss, können Administratoren die Aufgabe des Print-Servers vom Domain-Controller auf einen separaten Server auslagern. Das Risiko, den Print-Service auf Domain-Controllern auszuführen, ist zu hoch und nicht zu rechtfertigen.
Vorbereitung der Logdaten-Quellen
Einen stichhaltigen Beweis für die Ausnutzung der Schwachstelle liefern Events in den Protokollen „Microsoft-Windows-PrintServer/Admin“ und „Microsoft-Windows-PrintServer/Operational“. Letztere müssen Sie manuell aktivieren. Bereiten Sie zunächst Pläne mit den Administratoren vor, um mit der Weiterleitung der Logdaten aus den angeführten Quellen an LogPoint zu beginnen. Sollten Sie zudem Sysmon in Ihrer IT-Umgebung einsetzen, empfehlen wir Administratoren, die Konfiguration zu aktualisieren, um sicherzustellen, dass Sysmon die Artefakte von PrintNightmare erkennen kann. Letztlich können Sie auch IDS/IPS-Events nutzen, um die von PrintNightmare hinterlassenen Netzwerk-Artefakte zu erfassen.
Possible data sources requirements for detecting PrintNightmare
Erkennung von Exploit-Artefakten mit LogPoint
Sie können PrintNightmare-Artefakte entweder anhand von Endpunkt-Events oder Netzwerk-Events erkennen. Die zuverlässigste Methode zur Erkennung eines Exploits ist die Suche nach Event-IDs wie 808 und 316. Bei beiden Events können Sie den Namen der schadhaften DLL sehen, die von dem Print-Spooler-Dienst geladen wird. In unseren Tests wurde die Event-ID 808 nicht immer erzeugt. Aber wenn sie erzeugt wurde, wurde die schadhafte DLL erfolgreich geladen.
norm_id=WinServer event_source="Microsoft-Windows-PrintService" event_id=808
Sie können nach Events suchen, die den fehlgeschlagenen Ladeversuch eines Drucker-Plug-ins anzeigen.
norm_id=WinServer event_source="Microsoft-Windows-PrintService" event_id=316
Sie können nach Events suchen, die das Hinzufügen oder die Aktualisierung von Druckertreibern anzeigen.
Mithilfe der Sysmon-Events für die Dateierzeugung können Sie nach DLL-Drops im Treiberverzeichnis des Print-Spoolers suchen.
norm_id=WindowsSysmon event_id=11
path="C:\Windows\System32\spool\drivers\x64\3\*"
Sie können nach DLL-Drops im Treiberverzeichnis des Print-Spoolers suchen.
Die abgelegten DLLs werden anschließend vom Print-Spooler-Prozess (spoolsv.exe) geladen, wie aus den Image-Load-Events von Sysmon hervorgeht.
norm_id=WindowsSysmon label=Image label=Load
source_image="*\spoolsv.exe"
image="C:\Windows\System32\spool\drivers\x64\3\*"
Sie können nach dem Laden von DLLs aus dem Treiberverzeichnis von Print Spooler suchen.
Die geladenen DLLs erscheinen auch in den Registrierungspfaden des Druckerspoolers, wie aus den Registrierungsereignissen von Sysmon ersichtlich.
norm_id=WindowsSysmon label=Registry label=Set
target_object IN ["*\Configuration File*", "*\Data File"]
| chart count() by host, image, target_object, detail
Sie können im Treiberverzeichnis des Print-Spoolers nach den Ladevorgängen für DLLs suchen.
Schließlich werden die DLLs gelöscht, wie aus den Sysmon-Events für die Dateilöschung hervorgeht.
norm_id=WindowsSysmon event_id IN [23, 26]
source_image="*\spoolsv.exe" image="C:\Windows\System32\spool\drivers\x64\3\*"
Während die neue Sysmon-Konfiguration in die Umgebung übertragen wird, können Sie auch native Windows-Events nutzen, um nach einem möglichen Exploit zu suchen. Sie können entweder nach der Verbreitung von WerFault.exe durch den Print-Spooler-Dienst oder nach dem unerwarteten Beenden des Print-Spooler-Dienstes suchen. Die nativen Windows-Events können Sie verwenden, da der Print-Spooler-Dienst während des Ladens der Payload-DLL einen Fehler generiert. Dabei sollten Sie jedoch beachten, dass ein Side-Loading der DLL dieses Verhalten erfolgreich umgehen kann.
((norm_id=WindowsSysmon label="Process" label=Create
parent_image="*\spoolsv.exe" image="*\WerFault.exe")
OR (norm_id=WinServer channel=System event_id=7031
message="The Print Spooler service terminated unexpectedly"))
| timechart count() by event_id, host
Suchen Sie nach einem Fehler, der von dem Print-Spooler-Dienst generiert wurde. So können Sie eine erfolgreiche Ausnutzung der Schwachstelle erkennen und den Zeitrahmen eingrenzen, falls der Print-Service oder Sysmon keine Events zur Verfügung stellen.
Alternativ können Sie auch eine generische Exploit-Erkennung nutzen, indem Sie nach der Verbreitung verdächtiger Prozesse durch den Print-Spooler-Dienst suchen.
norm_id=WindowsSysmon label="Process" label=Create
parent_image="*\spoolsv.exe" image IN ["*\cmd.exe", "*\powershell.exe", "*\rundll32.exe"]
Auf Netzwerkseite müssen Sie nach der Übertragung der Payload-DLL via SMB suchen. Falls Sie eine IDS-/IPS-Lösung wie Snort und Zeek (Bro) in Ihrer IT-Umgebung einsetzen, ist das ganz einfach.
norm_id IN [Snort, SuricataIDS]
(message="ET POLICY SMB2 NT Create AndX Request For a DLL File - Possible Lateral Movement"
OR signature="ET POLICY SMB2 NT Create AndX Request For a DLL File - Possible Lateral Movement")norm_id=BroIDS event_category=files
(file="*.DLL" OR mime_type="application/x-dosexec")
Falls Sie eine IDS- oder IPS-Lösung einsetzen, können Sie nach der Übertragung von DLLs via SMB suchen.
Sie können die beiden oben stehenden Abfragen weiter eingrenzen, indem Sie konkret nach Domain-Controllern als Ziel suchen, aber das ist möglicherweise nicht immer der Fall.
Wir sollten daran denken, dass PrintNightmare auch für die lokale Rechteausweitung (LPE) verwendet werden kann, z.B. Administratoren wird empfohlen, nach neuen lokalen Benutzerkreationen Ausschau zu halten, nachdem eines der PrintNightmare-Artefakte wie unten gezeigt generiert wurde.
[ norm_id=WindowsSysmon label=Registry label=Set
target_object IN ["*\Configuration File*", "*\Data File"]]
as s1 followed by [ label=Create label=User ]
as s2 on s1.host=s2.host
| chart count() by s1.host, s1.image, s1.target_object, s1.detail, s2.target_user
Die Sysmon-Konfiguration ist der Schlüssel zur Erkennung eines Exploits
Wie Sie sehen Sie können, haben wir Sysmon genutzt, um die verschiedenen, von PrintNightmare erzeugten Artefakte zu erkennen. Sie sollten die Bedeutung von Sysmon in der heutigen Bedrohungslandschaft nicht außer Acht lassen. Sie können Sysmon nutzen, um die grundlegenden Windows-Event-Logs anzureichern, indem Sie bestehende Quellen wie die Logdaten zur Prozesserzeugung ergänzen sowie Unterstützung für neue Datenquellen wie die Erstellung von Pipes hinzufügen, die für die Erkennung von Bedrohungen unerlässlich sind. Die Konfiguration von Sysmon ist und bleibt jedoch ein heikler Balanceakt zwischen der Erkennung einer Vielzahl von relevanten Events und der Vermeidung von Log-Flooding – einer Überflutung von Logdaten. Letztlich läuft es darauf hinaus, die Richtlinien und Regeln in Sysmon passend zu konfigurieren – maßgeschneidert für die IT-Umgebung, in der Sie das Tool einsetzen.
Die Sysmon-Konfiguration von SwiftOnSecurity ist nach wie vor einer der besten Ausgangspunkte, um mit einer Konfiguration von Sysmon zu beginnen, die auf Ihre IT-Umgebung zugeschnitten ist. Die Sysmon-Konfiguration muss Regeln für die Erkennung wichtiger Events wie DLL-Droppings und EXE-Droppings umfassen. Gleichzeitig muss ein Ausschluss für zulässige, aber ressourcenintensive Anwendungen bedacht werden. Hierzu zählen integrierte Systemprozesse wie svchost, AVs, EDRs, Schwachstellen-Scanner und Datenbanken wie MSSQL. Beginnen Sie mit dem Einsatz der Basiskonfiguration auf ausgewählten Systemen und überwachen Sie das Logdaten-Volumen. Fahren Sie dann mit der Konfiguration fort und schließen Sie störende Events aus. Wiederholen Sie diesen Prozess so lange, bis der SIEM-Speicher das Logdaten-Volumen bewältigen kann, wenn das Tool auf allen Systemen in Ihrer IT-Umgebung eingesetzt wird.
Neue Sysmon-Versionen führen auch neue Events ein. Stellen Sie daher sicher, dass Sie eine Version von Sysmon einsetzen, die alle erforderlichen und für Sie relevanten Events erzeugen kann. Bevor Sie eine Erkennungstechnologie, die auf Sysmon basiert, einsetzen, sollten Sie prüfen, ob die bereitgestellte Konfiguration die für die Erkennung benötigten Events generieren kann. Blinde Flecken in einer Sysmon-Konfiguration können durchaus auftreten. Mit gründlichen Tests lässt sich dies vermeiden – noch vor einem umfassenden Einsatz in Ihrer IT-Umgebung.
Bereiten Sie sich auf Bedrohungsakteure und PrintNightmare vor
Da wir immer noch nicht wissen, wann Microsoft einen Patch für PrintNightmare veröffentlichen wird, müssen Sicherheitsverantwortliche in Unternehmen sowie SOCs wachsam bleiben. Wir gehen davon aus, dass Bedrohungsakteure aus verschiedenen Bereichen die Schwachstelle ausnutzen werden, um privilegierte Accounts zu erhalten, sobald sie sich Zugang zu Ihrer IT-Umgebung verschafft haben. Wir empfehlen, Events aus mehreren Quellen zu korrelieren, um eine zuverlässige Erkennung dieser Schwachstelle zu gewährleisten. Dies sollte für Unternehmen, die einen Defense-in-Depth-Ansatz verfolgen, kein Problem darstellen.
Wir raten Administratoren dringend dazu, eine unternehmensweite Suche nach Exploit-Versuchen ab Anfang Juni durchzuführen, die erforderlichen Gegenmaßnahmen umzusetzen, die entsprechenden Datenquellen zu nutzen und kontinuierlich nach künftigen Exploit-Versuchen durch Bedrohungsakteure zu suchen – bis Microsoft einen Patch veröffentlicht.
