Malware-Analyse Die Rückkehr des Festi-Rootkit

Veraltete Software wird nicht unendlich verkauft, sondern irgendwann vom Markt genommen. Es macht auch keinen Sinn, sie später wieder auf den Markt zu bringen. Gleiches gilt eigentlich auch für Malware. Ist ein Angriffsvektor bekannt, sollten Unternehmen ihn schließen und der Schädling hätte keine Chance mehr. Leider passiert das nicht, dies zeigt die Geschichte von Festi, eines ehemals beliebten Rootkits.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

TXOne Networks

Check Point Software Technologies GmbH

Das Festi-Rootkit wurde hauptsächlich vom RIG Exploit-Kit verbreitet und geht zurück bis ins Jahr 2009. Damals diente es zur Bildung eines großen und erfolgreichen Botnetzes, das sowohl für DDoS als auch für die Verbreitung von Spam-Mails genutzt wurde. Die Firma ESET untersuchte, das Rootkit und veröffentlichte 2012 eine eingehende Analyse seiner internen Funktionsweise. Seither, und nach der Festnahme seines Autors und Betreibers Igor Artimovich durch die russischen Behörden, war Festi inaktiv. Die Festnahme erfolgte nach einer Untersuchung eines DDoS-Angriffs, der 2010 von dem Botnetz auf die Webseite von Aeroflot ausgeführt wurde. Igor, der in Untergrundforen unter dem Spitznamen „Angel“ bekannt war, wurde zu zweieinhalb Jahren Haft mit Entlassung im August 2016 verurteilt. Seit seiner Verhaftung war das Botnetz abgeschaltet.

Jetzt gibt es eine neue Variante von Festi, die für Attacken eingesetzt wird. Sie geht mit einem komplizierten neuen Dropper einher, der sich zur Rechteausweitung als Update des Adope Flash Players tarnt. Interessant ist auch, dass die neue Rootkit-Variante etliche Änderungen im Code enthält, was darauf schließen lässt, dass der aktuelle Betreiber Zugriff auf den Quellcode von Festi hat. Vor diesem Hintergrund wirft das plötzliche Wiederauftreten von Festi Fragen in Hinblick auf die Identität des Betreibers auf, der dahintersteckt. Um die Frage nach den Hintermännern zu beantworten, muss man den Schädling analysieren.

Bildergalerie

Bildergalerie mit 7 Bildern

Der Dropper

Der Dropper ist verantwortlich für die Entschlüsselung und Installation des integrierten, verschlüsselten Rootkit-Treibers. Besitzt der Dropper nicht die erforderlichen Rechte zur Installation des Treibers, nutzt er eine hinterhältige Social-Engineering-Technik, um seine Rechte zu erweitern und die UAC zu „umgehen“. Er zeigt ein authentisch aussehendes Adobe Flash Player Updater-Fenster, das den Nutzer dazu verleitet, auf „Installieren“ zu klicken, um über die UAC erweiterte Rechte anzufordern.

Diese Technik ist zwar nicht neu, aber das hier erlebte hohe Maß an Authentizität ist ziemlich beeindruckend. Das fingierte Installationsfenster enthält Links, wie „Siehe Details…“ und „Endnutzer-Lizenzvereinbarung“, die auf die echte Adobe-Webseite hindeuten. Und wenn der Nutzer auf „Später erinnern“ klickt, ist der Dropper da und löscht sich selbst, woraus sich schließen lässt, dass die Betreiber lieber vorsichtig sind, als sich weitere Infektionen zuzuziehen.

Das Festi-Rootkit

Das Rootkit selbst ist in C++ geschrieben und arbeitet als Kernel-Mode-Treiber, der beim Einschalten inmitten der Standard-Systemtreiber gestartet wird. Es ist ziemlich raffiniert, insbesondere für seine Zeit, denn es wendet Tricks zur Umgehung von Endpunktsicherheitsprodukten an. Durch seinen modularen Aufbau unterstützt es verschiedene Plugins, die eine individuelle Anpassung der Funktionalität ermöglichen.

Die zuletzt beobachteten Muster weisen im Vergleich zu den ersten Untersuchungen jedoch einige Veränderungen im Code auf. Anfangs ist es schwierig überhaupt Gemeinsamkeiten zu erkennen. Bei näherer Betrachtung scheint es jedoch, als sei die Core-Logik weitestgehend noch immer die gleiche. Die Abweichungen, die in Code-Teilen zu erkennen sind und in beiden Binärprogrammen dem gleichen Zweck dienen, deuten darauf hin, dass der Malware-Code mit hoher Wahrscheinlichkeit neu kompiliert wurde. Es gibt jedoch etliche Änderungen, die an der Funktionalität selbst vorgenommen wurden. Einige davon sind nachstehend erläutert.

Bildergalerie

Bildergalerie mit 7 Bildern

Betrachtet man zunächst einmal die DriverEntry-Funktion beider Binärprogramme, kann man einen ähnlichen Flow erkennen, wobei die Malware einige Initialisierungen vornimmt, die für ihre Funktionalität erforderlich sind. Dazu gehört die Entschlüsselung eines eingebetteten Konfigurationsabschnitts, die Zuordnung einer Versandroutine für alle wichtigen Funktionen, ein Anhang an das SystemRoot-Gerät, um einen IRP abzuhören, bevor er zu nachfolgenden Filtertreibern weitergeleitet wird, sowie die Initiierung des wichtigsten Worker Threads der Malware.

Allerdings gibt es einige Änderungen. Zum einen enthielt die ältere Version Anti-VM-Checks (einen für VMWare und einen weiteren für Virtual PC) sowie einen Check für das Vorhandensein des Network-Packet-Filter-Treibers (npf.sys), der von Wireshark verwendet wird. Diese sind in der neuen Version nicht enthalten. Man kann nur vermuten warum. Entweder wurde absichtlich auf sie verzichtet, oder bei der Erstellung der neuen Muster wurde eine ältere Codebasis verwendet.

Beide Versionen prüfen das Vorhandensein eines angeschlossenen Debuggers. Dieser erfolgt durch Untersuchung der globalen Variablen KD_DEBUGGER_ENABLED. Die ältere Version beinhaltet einen zusätzlichen Check, um zu testen, ob sie auf das Objekt \Driver\NTICE zugreifen kann das dem SoftICE-Debugger entspricht. Auch dieser Check ist in der neueren Version nicht enthalten.

Eine weitere Ähnlichkeit, die zu beobachten ist, liegt im Aufbau der DGA-Funktion, bei der es sich um einen Rückfallmechanismus für den Fall handelt, dass die fest codierte C&C-Domain nicht reagiert. Hier ist der Gesamtalgorithmus der gleiche. Bei näherer Betrachtung man aber erkennen, dass zwar die Reihenfolge der Aufrufe der Mapping-Funktionen die erhalten bleibt, die Reihenfolge der Seed-Argumente in der neuen Version jedoch verändert ist. Auch die Mappings selbst haben sich verändert. Schließlich beinhaltet die neuere Version eine zusätzliche Xor-Verknüpfung eines Stack DWORD. Das untermauert die Tatsache, dass diese spezielle Funktion neu kompiliert wurde.

Eine Funktion, die schließlich vollständig verändert wurde, ist die Verschlüsselungsfunktion des Konfigurationsbereichs. Dieser Bereich ist im Abschnitt .cdata im Treiber-Image eingebettet und wird während der Laufzeit entschlüsselt, um den Großteil der Strings, die von der Malware während ihrer Ausführung verwendet werden, zu hosten. Wie bereits erwähnt legen diese Veränderungen nahe, dass jemand im Besitz des ursprünglichen Quellcodes von Festi ist.

Bildergalerie

Bildergalerie mit 7 Bildern

Zusammenfassung

Die Rückkehr des Festi-Rootkit ist nach so langer Abwesenheit ziemlich überraschend. Das bisherige Vorgehen deutet darauf hin, dass der aktuelle Betreiber vorsichtig ist und lieber unter dem Radar agiert. Darüber hinaus weist die technische Analyse darauf hin, dass der aktuelle Betreiber möglicherweise im Besitz des Quellcodes ist. Es ist noch zu früh zu sagen, ob es sich lediglich um jemanden handelt, der mit einer alten Malware herumspielt, oder um ein völlig neues Kapitel für Festi.

Über den Autor: Andreas Müller ist Enterprise Manager bei Check Point.

(ID:45321507)