„Die Botschaft, die Sie sich [aus diesem Vortrag] unbedingt mitnehmen sollten, lautet: Wenn Sie Ihr Netzwerk wirklich schützen wollen, müssen Sie Ihr Netzwerk wirklich kennen.“ Leiter der TAO, NSA, USENIX Enigma 2016
Ein wesentlicher Bestandteil des „Kenntnisses Ihres Netzwerks“ ist die Verfolgung von Persistenzmechanismen auf Endgeräten – also der unzähligen Möglichkeiten, auf die ein Betriebssystem Code automatisch laden und ausführen kann. Seit über einem Jahrzehnt gehören Hintergrunddienste zu den am häufigsten genutzten Speicherorten für persistente Daten unter Windows. Dienste, die bereits seit der Zeit von Windows NT und XP verfügbar sind, bieten eine zuverlässige Möglichkeit, Prozesse und Bibliotheken beim Systemstart, bei der Benutzeranmeldung oder bei bestimmten Auslösebedingungen unauffällig im Hintergrund zu laden. Zwar wird oft viel Aufmerksamkeit auf die Erfassung neuartiger, verdeckter Persistenztechniken gerichtet, doch ist es wichtig, die Grundlagen nicht aus den Augen zu verlieren – insbesondere angesichts der Tatsache, dass dienstbasierte Malware nach wie vor weit verbreitet ist.
Früher war es eine schier unmögliche Aufgabe, die im gesamten Unternehmen laufenden Systemdienste genau im Blick zu behalten. Vor zwei Jahren galt als Stand der Technik eine monatliche Prüfung mit umfangreicher manueller Analyse zur Aufdeckung von Unregelmäßigkeiten. Heute lässt sich dies mithilfe der Tanium-Plattform und ihres Moduls „Incident Response“ kontinuierlich und automatisiert durchführen.
Fernzugriffstools (RATs) und andere Schadprogramme können auf drei verschiedene Arten als Dienste fortbestehen: als eigenständige Dienst-Executables, als gehostete Dienstmodule und als COM+-Komponenten. In diesem Beitrag werde ich die verschiedenen Methoden erläutern, mit denen Angreifer Windows-Dienste missbrauchen, und darlegen, wie Tanium Ihnen dabei helfen kann, diese zu erkennen.
Einzelne Dienstleistungen
Standalone-Dienste führen eine ausführbare Datei oder einen Befehl aus, die bzw. der im Wert „ImagePath“ innerhalb ihrer jeweiligen Konfigurationsschlüssel in der Registrierungsdatenbank angegeben ist. Die Windows-Registrierung enthält die Konfigurationseinstellungen für alle laufenden Dienste unter dem übergeordneten Schlüssel „HKLM\System\CurrentControlSet\Services“.
Tanium bietet seit langem die Möglichkeit, Windows-Dienste in großem Umfang (über den gesamten Windows-Bestand hinweg) zu überwachen. Der Sensor „Dienststatus mit MD5 -Hash“ erfasst und vergleicht beispielsweise den Dienstnamen, den Status (läuft, gestoppt usw.), die Befehlszeile, den ImagePath-Hash sowie den Benutzerkontext, unter dem der Dienst ausgeführt wird. Das bedeutet, dass eigenständige Dienste bei einer geringen Häufigkeit auffallen, wenn ihre Konfiguration oder ihr Zustand ungewöhnlich ist oder sich bei Instanzen mit identischem Namen unterscheidet. Tanium-Anwender haben diesen Sensor genutzt, um falsch konfigurierte, aber legitime Dienste anhand ihres Status (wie z. B. angehaltene Antiviren-Dienste) sowie unerwünschte Dienste anhand ihres Namens, des Benutzerkontexts, der Befehlszeile oder abweichender ImagePath-Hashes bei gleichnamigen Dienstinstanzen zu identifizieren.
Aus Sicht eines Angreifers sind eigenständige Dienste weniger beliebt, da der Pfad zur ausführbaren Datei mithilfe des Task-Managers, von „tasklist.exe“ oder Abfragen im Dienststeuerungs-Manager leicht ermittelt werden kann. Stellen Sie sich einen Angreifer vor, der Malware unter dem Namen des legitimen Dienstes „Druckspooler“ tarnen möchte. Dieser Dienst hat den Pfad zur ausführbaren Datei „c:\windows\system32\spoolsv.exe“. Eine manipulierte Instanz des Dienstes könnte eine schädliche Binärdatei laden, deren Dateiname oder Speicherort geringfügig verändert wurde, beispielsweise „c:\windows\spoolsv.exe“ oder „c:\windows\system32\spoolsvc.exe“. Diese Technik kann Malware zwar wirksam vor einer „auf den ersten Blick“ durchgeführten Analyse verbergen, lässt sich jedoch durch statistische Auswertung des ImagePath oder der Befehlszeile leicht durchschauen. Tanium-Sensoren wie „Servicestatus mit Hash MD5 “ werden diese Ausreißer zügig an den Rand der Gruppe verschieben, damit sie im Rahmen einer Folgeanalyse und Untersuchung näher untersucht werden können.
Gehostete Dienste und COM+-Anwendungen
Hosted-Dienste werden als Bibliotheken – in der Regel als Dynamic Link Libraries (DLLs) – und nicht als eigenständige ausführbare Dateien implementiert. Sie werden in der Regel vom Windows-Dienst-Hosting-Prozess „svchost.exe“ geladen. Der folgende Screenshot zeigt die Ausgabe des Tanium-Sensors „Service Status with MD5 Hash“ für verschiedene gehostete Dienste, wie beispielsweise „Application Management“ und „Base Filtering Engine“. Bei jedem Dienst handelt es sich bei dem angegebenen Hash um den von „svchost.exe“ und nicht um den der gehosteten DLL.
Woher weiß Windows, welche DLL für einen bestimmten gehosteten Dienst geladen werden muss? Die Registrierungskonfiguration für jeden dieser Dienste enthält einen Unterschlüssel und einen Wert namens „\Parameters\ServiceDLL“, der auf die zu ladende DLL verweist. Aus Gründen der Effizienz und Sicherheit lädt Windows gehostete Dienste zudem in Gruppen unter gemeinsam genutzten Instanzen des Hosting-Prozesses (anstatt für jeden einzelnen eine eigene Instanz von „svchost.exe“ zu starten).
Hosted-Service-Gruppen werden unter dem Registrierungsschlüssel „HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost“ konfiguriert. Jede Gruppe gewährt unterschiedliche Zugriffsrechte; „netsvcs“ ist eine der Gruppen mit den höchsten Berechtigungen für Dienste mit Netzwerkzugriff und wird daher häufig von Angreifern ausgenutzt. Der Wert „netsvcs“ ist ein Zeichenfolgenarray mit den Namen der Dienste, die in dieser Gruppe geladen werden sollen, wie in der folgenden Abbildung dargestellt.
Angreifer können gehostete Dienste auf verschiedene Weise missbrauchen, um eine schädliche DLL zu laden. Ein Ansatz besteht darin, einen Namen für einen gehosteten Dienst zu wählen, der „unbenutzt“ ist – d. h., für den unter „HKLM\SYSTEM\CurrentControlSet\services“ kein Dienst konfiguriert ist. Malware-Dropper könnten diese ungenutzten Einträge nacheinander durchlaufen, die erforderlichen Registrierungsschlüssel (einschließlich eines „ServiceDLL“-Parameters) erstellen und auf diese Weise ihre Persistenz als gehosteter Dienst aufrechterhalten. Beispielsweise nahmen Angreifer bei älteren Windows-Versionen häufig den Dienst „ “6to4” “ ins Visier, der zwar zur Gruppe „netsvcs“ gehört, jedoch ohne entsprechende Konfiguration oft inaktiv ist. Der Angreifer könnte diesen Dienst so konfigurieren, dass er auf einen plausibel wirkenden DLL-Namen verweist, beispielsweise „c:\windows\system32\6to4svc.dll“, und damit eine visuelle Überprüfung wahrscheinlich bestehen würde. Ein weiterer Ansatz besteht darin, den „ServiceDLL“-Parameter eines bereits vorhandenen, aber deaktivierten Windows-Dienstes einfach zu ändern und diesen anschließend so zu konfigurieren, dass er automatisch gestartet wird.
COM+-Systemdienste stellen eine weitere Variante im Zusammenhang mit gehosteten Diensten dar, die schädliche DLLs laden können. In diesem Fall lädt der Prozess „dllhost.exe“ die COM+-Anwendung, die aus mehreren Komponenten in Form von DLLs bestehen kann. So ist beispielsweise der im folgenden Screenshot aufgeführte ComSysApp-Dienst für das Hosten von COM+-Anwendungen zuständig. In der Befehlszeile werden der Pfad zu „dllhost.exe“ sowie eine „Processid“-GUID angezeigt, die die COM+-Anwendung identifiziert; im Code können die „Komponenten“ aufgelistet werden. Bei den Komponenten handelt es sich um DLLs, die zur Implementierung der Anwendung verwendet werden.
Zusammenfassend lässt sich sagen, dass gehostete Dienste und COM-Dienste eine verdeckte und weit verbreitete Methode darstellen, um RATs und andere Malware dauerhaft zu etablieren. Analysten müssen über die einfache Prozessüberwachung oder die Überprüfung von Dienstnamen und ImagePaths hinausgehen, um Dienste zu erkennen, die schädliche DLLs laden.
Erkennung von unerwünschten Dienst-DLLs mit Tanium
Tanium bietet verschiedene Sensoren, mit denen Sie Service-DLLs auf Unternehmensebene problemlos erkennen und analysieren können. Zunächst möchten wir Ihnen einen neuen Sensor namens „Service Module Details“ vorstellen, der Ende des Monats in der kommenden Version 3,0 unserer Incident-Response-Lösung enthalten sein wird. Der folgende Screenshot zeigt einen Ausschnitt aus der Ausgabe dieses Sensors (die Spalte „count“ wurde weggelassen).
Dieser Sensor bietet einen übergreifenden Überblick über alle drei oben beschriebenen Dienstarten. Beachten Sie, dass neben dem Dienstnamen und dem ImagePath nun auch eine Spalte „Modulpfad“ enthalten ist. In den ersten beiden Zeilen dieses Beispiels wird der Pfad zu zwei Komponenten-DLLs für die COM+-Anwendung mit dem Namen „COMSysApp“ angezeigt. Die übrigen Ergebnisse werden alle von „svchost.exe“ gehostet und enthalten den Pfad zur jeweiligen Dienst-DLL. Die Stack-Analyse dieser Daten erfolgt, wie bei allen Tanium-Sensoren, in Echtzeit. Das bedeutet, dass Sie innerhalb von Sekunden auf Zehn- oder Hunderttausenden von Systemen Ausreißer identifizieren können, bei denen Dienste unerwünschte DLLs laden.
Identifizierung von unberechtigtem Mitgliedern in Gruppen von gehosteten Diensten
Im letzten Quartal umfasste das Update der Incident-Response-Lösung von Tanium einen weiteren Sensor zur Dienstanalyse mit der Bezeichnung „Hosted Service Name Audit“. Der folgende Screenshot zeigt ein Beispiel für die Ausgabe für die Gruppe „netsvcs“.
Die Ausgangsdaten dieses Sensors eignen sich zur schnellen Überprüfung der in Servicegruppen zusammengefassten Dienste in großem Maßstab. Für jede Gruppe enthält die Spalte „Sortierte Liste der Namen der gehosteten Dienste“ eine alphabetisch geordnete Liste der Dienstnamen. Dadurch wird sichergestellt, dass sich die Ergebnisse der einzelnen Systeme „überlagern“; Systeme, die einen innerhalb einer Gruppe ungewöhnlichen Dienst enthalten, werden somit als Ausreißer herausgefiltert. Natürlich können Systeme je nach Betriebssystem und Rolle unterschiedliche Dienstgruppen aufweisen, doch wir haben festgestellt, dass sich die Sensorausgaben in Clustern gruppieren, die sich nach Betriebssystemversion und Plattformtyp richten. Tanium-Anwender können die „Drill-Down“-Funktion nutzen, um Systeme mit Ausreißerwerten auf einfache Weise zu untersuchen, oder zu Tanium Trace wechseln, um die historischen forensischen Daten im Zusammenhang mit der Erstellung eines nicht autorisierten Dienstes zu überprüfen.
Möchten Sie Tanium in Aktion erleben? Vereinbaren Sie unter eine individuelle Vorführung oder nehmen Sie an unserem wöchentlichen Webinar teil. Sprechen Sie mit unseren Tanium-Experten bei unseren bevorstehenden Veranstaltungen im Rahmen der „ “ unter.
