PowerShell-Malware: Tipps zum Aufspüren und Neutralisieren
Zu den Vorzügen der PowerShell zählt zweifelsohne der weitreichende Zugriff auf Windows-Systeme. Das sehen weniger redliche Naturen genauso und missbrauchen sie für Angriffe.
Lokale Server in den eigenen Rechenzentren sind in vielen Unternehmen nach wie vor trotz aller Cloud-Angebote eine der tragenden Säulen der eigenen IT-Infrastruktur. Und genau diese Server sind auch für potenzielle Angreifer ein durchaus attraktives Ziel.
Böswillige Akteure richten ihre Angriffe sehr gezielt auf diese Server in den Rechenzentren der Unternehmen, um dann die dort reichlich vorhandene Leistung und Bandbreite für ihre Zwecke zu missbrauchen. Nachfolgend betrachtet dieser Beitrag exemplarisch wie eine PowerShell-Malware, die ihr Werk nach einem bestimmten Zeitplan verrichtet hat, entdeckt und deaktiviert wurde.
Stark abfallende Systemleistung als Indiz
Das etwas nicht in Ordnung war, konnte man auch ohne große Recherche und Tools erkennen. Die Leistung der Systeme fiel dramatisch ab, beinahe bis zum augenscheinlichen Stillstand der Maschinen. Zumindest was deren eigentliche Aufgaben betraf. Im Task-Manager von Windows war zu erkennen, dass mehrere Instanzen der PowerShell liefen, und diese so viel CPU-Leistung vereinnahmten, wie überhaupt nur möglich.
Wir haben die Prozesse der powershell.exe beendet. Dies war allerdings nur eine vorübergehende Lösung, denn wir mussten erkennen, dass die Prozesse alle zwei Stunden neu gestartet wurden, um dann wieder Krypto-Währungen zu schürfen.
Um die automatisierte Ausführung der PowerShell-Malware zu beenden, haben wir folgenden Befehl verwendet:
taskkill /IM PowerShell.exe /F
Ein Blick in die Aufgabenplanung von Windows lieferte keine offensichtlichen Hinweise auf die Malware. Häufig verändert Schadsoftware eine vorhandene Windows-Datei oder erstellt ähnliche und agiert mit versteckten Ordnern. In diesem Fall existierten keine versteckten Verzeichnisse und bei einer Überprüfung schienen alle Systemdateien in Ordnung zu sein.
Um die Ursache der Probleme etwas eingehender zu betrachten, haben wir die PowerShell-Protokollierung über die Gruppenrichtlinien mit administrativen Vorlagen aktiviert. Die Einstellungen hierzu finden sich im Editor für Gruppenrichtlinien unter Computerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Windows PowerShell/. Bereits nach einer halben Stunde ließ sich anhand der Protokolle erkennen, dass der Rechner mit mehreren externen IP-Adressen Kontakt aufgenommen hatte.
Nachdem wir die externen IP-Adressen identifiziert hatten, haben wir eine neue statische Route eingerichtet, um den Traffic entsprechend umzuleiten. Dazu haben wir eine Eingabeaufforderung mit Administrationsrechten gestartet und den folgenden Befehl ausgeführt, der X.X.X.X. durch die Standard-Gateway-Adresse ersetzt:
route ADD 105.27.177.210 MASK 255.255.255.255 X.X.X.X if 1 -p
Den gleichen Befehl haben wir für die anderen IP-Adressen ausgeführt, die wir über die besagten Protokolle ermittelt hatten. Als die PowerShell-Malware nun versuchte zu starten, wurde sie sofort angehalten, da sie nicht mit dem Internet kommunizieren konnte.
Von jenen Servern, die nicht mit dem Internet kommunizieren müssen, haben wir das Standard-Gateway entfernt. Dies hatte den gleichen Effekt wie das Null-Routing der IP-Adresse und sorgte dafür, dass der Prozess unmittelbar nach dem Start wieder beendet wurde.
Die Schadsoftware aus der WMI-Datenbank entfernen
Während der hohen CPU-Auslastung beim Start der powershell.exe landeten viele WMI-Warnmeldungen im Ereignisprotokoll von Windows. Grund genug, WMI (Windows Management Instrumentation) einer etwas näheren Betrachtung zu unterziehen.
Mit den folgenden PowerShell-Befehlen kann man nach einer beschädigten oder infizierten WMI-Datenbank suchen. Dabei ist -gwmi der Alias für Get-WmiObject.
gwmi -Namespace "root/subscription" -class __FilterToConsumerBinding -Filter "Filter = ""__EventFilter.Name='SCM Event Filter'"""
gwmi -Namespace "root/subscription" -Class __EventFilter | Where Name -eq "SCM Event Filter"
gwmi -Namespace "root/subscription" -Class __EventConsumer | Where Name -eq "SCM Event Consumer"
Wenn etwas nicht stimmt, erscheint ein verschlüsselter Text. Aufgrund dieser Verschleierung erkennt das Betriebssystem die PowerShell-Malware möglicherweise nicht als Bedrohung.
Um die Malware zu entfernen, mussten die entsprechenden Einträge aus der WMI-Datenbank mit Remove-Object gelöscht werden:
gwmi -Namespace "root/subscription" -class __FilterToConsumerBinding -Filter "Filter = ""__EventFilter.Name='SCM Event Filter'""" | Remove-WMIObject
gwmi -Namespace "root/subscription" -Class __EventFilter | Where Name -eq "SCM Event Filter" | Remove- WMIObject
gwmi -Namespace "root/subscription" -Class __EventConsumer | Where Name -eq "SCM Event Consumer" | Remove- WMIObject
Wir haben zudem bemerkt, dass die Malware IPv6 verwendet, um den Datenverkehr zu IPv4 zu tunneln. Falls man Server verwendet, die IPv6 nicht benötigen, wäre es eine Möglichkeit selbiges zu deaktivieren. Dass kann über ein Update der Registry erfolgen sowie durch die Entfernung des Passthrough:
reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 0xFF /f
Get-NetAdapterBinding -ComponentID "ms_tcpip6" | disable-NetAdapterBinding -ComponentID "ms_tcpip6" -PassThru
Nach einem Neustart des Servers wurden die multiplen Instanzen von powershell.exe gestoppt.
Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!
