Erkennen Sie mit Sysmon in WMI versteckte Malware
Von Randy Franklin Smith
Sicherheit ist ein immer eskalierendes Wettrüsten. Die Guten sind besser darin geworden, das Dateisystem auf Artefakte fortgeschrittener Bedrohungsakteure zu überwachen. Sie wiederum meiden das Dateisystem und graben sich tiefer in Windows ein, um Speicherorte für ihren Malware-Code zu finden und dessen Ausführung zuverlässig auszulösen, um zwischen Neustarts Persistenz zu erreichen.
Jahrzehntelang waren die Schlüssel „Run“ und „RunOnce“ in der Registrierung beliebte Speicherorte für die Persistenz von Angreifern, aber wir wissen, dass wir sie mithilfe der Windows-Überwachung für Sysmon überwachen können. Aus diesem Grund sind eingeweihte Angreifer auf WMI umgestiegen.
WMI ist im Guten wie im Schlechten ein so mächtiger Bereich von Windows. Tatsächlich haben die Bösewichte effektive Möglichkeiten gefunden, Malware in WMI zu verstecken und dauerhaft zu speichern. In diesem Artikel zeige ich Ihnen eine besonders ausgefeilte Möglichkeit, Malware mit WMI-Ereignisfiltern und -Verbrauchern dauerhaft zu speichern.
Mit WMI können Sie diese beiden Objekte verknüpfen, um eine benutzerdefinierte Aktion auszuführen, wenn in Windows bestimmte Dinge passieren. WMI-Ereignisse beziehen sich auf die Ereignisse im Ereignisprotokoll, sind aber allgemeiner als diese, die wir alle kennen und lieben. Zu den WMI-Ereignissen gehören Systemstart, Zeitintervalle, Programmausführung und viele, viele andere Dinge. Sie können einen __EventFilter definieren, der im Grunde eine WQL-Abfrage ist, die angibt, welche Ereignisse Sie in WMI abfangen möchten. Dies ist ein permanentes Objekt, das im WMI-Repository gespeichert ist. Es ist passiv, bis Sie einen Verbraucher erstellen und ihn mit einer Bindung verknüpfen. Der WMI-Ereigniskonsument definiert, was das System mit allen vom Filter erfassten Ereignissen tun soll. Es gibt verschiedene Arten von Ereigniskonsumenten für Aktionen wie das Ausführen eines Skripts, das Ausführen einer Befehlszeile, das Senden einer E-Mail oder das Schreiben in eine Protokolldatei. Schließlich verknüpfen Sie den Filter und den Verbraucher mit einer __FilterToConsumerBinding. Nach dem Speichern der Bindung ist nun alles aktiv und immer wenn Ereignisse auftreten, die dem Filter entsprechen, werden sie an den Verbraucher weitergeleitet.
Wie würde ein Angreifer also dafür sorgen, dass seine Malware bei jedem Windows-Neustart gestartet wird? Erstellen Sie einfach einen Filter, der ein Ereignis abfängt, das kurz nach dem Start auftritt. Folgendes verwendet PowerSploit zu diesem Zweck:
Anschließend erstellen Sie einen WMI-Ereigniskonsumenten, bei dem es sich um ein weiteres permanentes Objekt handelt, das im WMI-Repository gespeichert ist. Hier ist ein VB-Code, der aus dem WMIPersistence.vbs-Skript von mgeeky auf Github übernommen wurde. Es ist unvollständig, aber aus Gründen der Übersichtlichkeit bearbeitet. Wenn Sie mit dieser Funktionalität spielen möchten, lesen Sie https://gist.github.com/mgeeky/d00ba855d2af73fd8d7446df0f64c25a:
Jetzt haben Sie einen Filter, der sucht, wann das System kürzlich gestartet wurde, und einen Verbraucher, der c:badmalware.exe ausführt, aber nichts passiert, bis sie wie folgt verknüpft sind:
An diesem Punkt verfügen Sie über einen Filter, der sucht, wann das System kürzlich gestartet wurde, und über einen Consumer, der c:badmalware.exe ausführt.
Wie fängt man als guter Kerl (oder gutes Mädchen) so etwas an? Es gibt keine Ereignisse im Windows-Sicherheitsprotokoll, aber glücklicherweise hat Sysmon 6.10 drei neue Ereignisse zum Abfangen von WMI-Filter- und Verbraucheraktivitäten sowie der Bindung hinzugefügt, die sie aktiv macht.
- Sysmon Event ID
Beispiel
- 19 – WmiEventFilter activity detected
WmiEventFilter-Aktivität erkannt:
EventType: WmiFilterEvent
UtcTime: 2018-04-11 16:26:16.327
Vorgang: Erstellt
Benutzer: LABrsmith
EventNamespace: „root\cimv2“
Name: „MyFilter“
Abfrage: „SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 200 AND TargetInstance.SystemUpTime < 320“- 20 – WmiEventConsumer activity detected
WmiEventConsumer-Aktivität erkannt:
EventType: WmiConsumerEvent
UtcTime: 2018-04-11 16:26:16.360
Vorgang: Erstellt
Benutzer: LABrsmith
Name: „MyConsumer“
Typ: Befehlszeile
Ziel: „c:\bad\malware.exe“- 21 – WmiEventConsumerToFilter activity detected
WmiEventConsumerToFilter-Aktivität erkannt:
EventType: WmiBindingEvent
UtcTime: 2018-04-11 16:27:02.565
Vorgang: Erstellt
Benutzer: LABrsmith
Consumer: „CommandLineEventConsumer.Name=“MyConsumer“ ”
Filter: „__EventFilter.Name=“MyFilter““
Wie Sie sehen, liefern die Ereignisse vollständige Details, sodass Sie die WMI-Vorgänge analysieren können, um festzustellen, ob sie legitim oder böswillig sind. An der Ereignis-ID 19 kann ich erkennen, dass der Filter nach einem Systemstart sucht. Ereignis-ID 20 zeigt mir den Namen des Programms, das ausgeführt wird, und ich kann anhand der Ereignis-ID 21 erkennen, dass sie verknüpft sind.
Wenn Sie diese Ereignisse zu Ihrer Überwachung hinzufügen, sollten Sie die Aktivitäten eine Zeit lang analysieren, um die regulären, legitimen Erzeuger dieser Ereignisse in Ihrer speziellen Umgebung auf die Whitelist zu setzen.
Das ist für Sie Persistenz über WMI, aber Sie haben vielleicht bemerkt, dass wir zu diesem Zeitpunkt nicht dateilos sind; Meine Malware ist nur eine herkömmliche Exe-Datei in c:bad. Um sich vom Dateisystem fernzuhalten, haben Kriminelle auf die Erstellung neuer WMI-Klassen zurückgegriffen und ihre Logik in einem PowerShell-Skript in einer Eigenschaft dieser Klasse gespeichert. Anschließend richten sie einen Filter ein, der einen kurzen PowerShell-Befehl auslöst, der ihren größeren Code aus der benutzerdefinierten WMI-Klasse und den Aufrufen abruft. Normalerweise wird dies mit etwas Verschleierung wie Base64-Kodierung und möglicherweise auch Verschlüsselung kombiniert.