Stuxnet / Duqu: Evolution der Treiber
Von Alexander Gostev , Igor Soumenkov am 28. Dezember 2011 20.30 Uhr
Publikationen
Tweet
DUQU
Inhalt
Die "offizielle" Stuxnet Geschichte
Bisher unbekannte Driver
rtniczw.sys
rndismpc.sys
Das Bindeglied: mrxcls.sys -> jmidebs.sys -> Duqu-Treiber
Driver
Evolution
rndismpc.sys, rtniczw.sys und jmidebs.sys
Der Driver
Erstellungsprozess
Abschluss
Wir haben das Studium der Duqu Trojan seit zwei Monaten, zu erforschen, wie es
entstanden, wo sie verteilt und wie es funktioniert. Trotz des großen Volumens
der erhaltenen Daten (von denen die meisten noch nicht veröffentlicht), noch
fehlen uns die Antwort auf die grundsätzliche Frage - wer hinter Duqu ist?
Darüber hinaus gibt es noch andere Probleme, vor allem mit der Schaffung des
Trojaners, oder eher der Plattform zur Implementierung Duqu sowie Stuxnet zu
tun.
In Bezug auf Architektur, die Plattform verwendet, um Duqu und Stuxnet erstellen
ist die gleiche. Dies ist eine Treiberdatei, die ein Hauptmodul als
verschlüsselte Bibliothek entwickelt lädt. Zur gleichen Zeit gibt es eine
separate Konfigurationsdatei für die ganze Schadkomplex und einem
verschlüsselten Block in der System-Registry, die die Position des Moduls
definiert geladen und Namen des Prozesses zur Injektion.
Herkömmliche Plattform-Architektur für Stuxnet und Duqu
Diese Plattform kann konventionell benannt als "Tilded", wie die Autoren sind,
aus irgendeinem Grund ist, geneigt, Dateinamen, die mit "~ d" beginnen zu
verwenden.
Wir glauben, dass Duqu und Stuxnet wurden durch das gleiche Team von Entwicklern
unterstützt gleichzeitige Projekte.
Mehrere andere Details wurden aufgedeckt, die vorschlagen, es war vielleicht
zumindest eine weitere Spyware-Modul basiert auf der gleichen Plattform in den
Jahren 2007-2008, und einige andere Programme, deren Funktionalität war unklar,
zwischen 2008 und 2010.
Diese Fakten, die den bestehenden "offiziellen" Geschichte des Stuxnet deutlich
in Frage stellen. Wir werden versuchen, sie in dieser Publikation zu decken,
aber lassen Sie uns zunächst die Geschichte rekapitulieren so weit.
Die "offizielle" Stuxnet Geschichte
Lassen Sie mich mit einer Frage beginnen: Wie viele Stuxnet Treiber-Dateien
bekannt sind? Ab heute, wäre die richtige Antwort vier sein. Siehe unten für
weitere Informationen über diese.
Dateinamen Größe (Byte) Erstellungsdatum Wo und wann wurde es verwendet,
Digitale Signatur / Datum Unterschrift
Mrxcls.sys 19840 01.01.2009 Stuxnet (22.06.2009) Nicht
Mrxcls.sys 26616 01.01.2009 Stuxnet (01.03.2010 / 14.04.2010) Realtek,
25.01.2010
Mrxnet.sys 17400 25.01.2010 Stuxnet (01.03.2010 / 14.04.2010) Realtek,
25.01.2010
Jmidebs.sys 25552 14.07.2010 Vermutlich Stuxnet JMicron,
unbekannt
Die erste Änderung der Stuxnet-Wurm, im Jahr 2009 erstellt wurde, verwendet nur
eine Treiber-Datei - mrxcls.sys ohne digitale Signatur.
Im Jahr 2010 erstellte die Autoren der zweite Driver
mrxnet.sys und ausgestattet
mrxnet.sys und mrxcls.sys Driver
mit digitalen Zertifikaten von Realtek (auf
Komponentendateien des Wurms auf USB-Laufwerke zu verstecken). Die mrxnet.sys
Treiber ist nicht von großer Bedeutung für unsere Geschichte, denn es ist ein
separates Modul nicht in die allgemeine Architektur der Plattform enthalten.
Am 17. Juli 2010 festgestellt ESET einen anderen
Driver
"in the wild" -
jmidebs.sys - die sehr ähnlich zu den bereits bekannten mrxcls.sys war, aber
hatte nur drei Tage erstellt werden, bevor es entdeckt wurde. Dieser Zeit von
Jmicron - Dieser Treiber wurde mit einem neuen Zertifikat gesichert.
Bis vor kurzem war unklar, was der Zweck der Datei war, aber die öffentliche
Meinung entschieden, dass es zu Stuxnet verwandt. Eine Theorie ist, dass der
Stuxnet-C & C wurde versucht, die alte Version mit dem Realtek-Zertifikat mit
einem neuen zu ersetzen. Dabei wurden die Autoren des Wurms entweder in der
Hoffnung, damit es nicht durch Antivirus-Programme aufgenommen oder wurden ein
Zertifikat, das blockiert worden war, zu ersetzen.
Leider hat diese Theorie nicht bestätigt - Jmidebs.sys hat nie irgendwo
festgestellt worden. Eine neue Version von Stuxnet in der Lage, die Installation
der Datei auch nicht gefunden worden.
Dies ist die offizielle Geschichte des Stuxnet. Aber, wie ich oben erwähnt, im
Zuge unserer Forschung haben wir neue Beweise, die unten besprochen werden
entdeckt.
Bisher unbekannte Driver
rtniczw.sys
Während der Analyse eines Benutzers Zwischenfall mit Duqu, entdeckten wir etwas
Neues - etwas, das potenziell beeinflussen könnten die ganze Geschichte Stuxnet
wie wir es kennen.
Eine seltsame Datei auf Computer des Opfers, die von unserer Antivirus-Engine
als Rootkit.Win32.Stuxnet.a erkannt wurde entdeckt. Dieses Urteil sollte nach
den oben beschriebenen bekannten Datei mrxcls.sys entsprechen, aber die erkannte
Datei den Namen und die Prüfsumme waren anders!
Die Datei war rtniczw.sys, 26.872 Bytes groß, MD5
546C4BBEBF02A1604EB2CAAAD4974DE0.
Die Datei wurde ein wenig größer als mrxcls.sys, die eine digitale Signatur
Realtek hatte. Dies impliziert, dass rtniczw.sys hatte auch eine digitale
Signatur. Wir haben es geschafft, eine Kopie der Datei zu erhalten, und wir
waren erstaunt, dass es verwendet die gleiche Realtek-Zertifikat, aber mit einem
anderen Datei Unterzeichnung Datum mrxcls.sys: rtniczw.sys wurde am 18. März
2010 unterzeichnet, während der Driver
mrxcls hatte am 25. Januar desselben
Jahres unterzeichnet worden.
Darüber hinaus verwendet rtniczw.sys einen Registrierungsschlüssel und
Konfigurationsdatenblock, die nicht in Stuxnet verwendet wurde. Stuxnet nutzte
die Taste "MRxCls" und der Wert "Daten", während im Fall von rtniczw.sys, war
der Schlüssel "rtniczw" und der Wert war "Config".
Detaillierte Analyse des Codes in rtniczw.sys gefunden identifiziert keine
anderen Unterschiede von der "Referenz"-Treiber: Das war die gleiche mrxcls.sys
Datei, im selben Jahr erstellt, am gleichen Tag und Stunde - am 1. Januar 2009.
Wir suchten nach zusätzlichen Informationen über andere Benutzer, die die
gleiche Datei hatte, waren aber nicht in der Lage, etwas zu finden! Darüber
hinaus haben wir keine Informationen finden konnte, überhaupt über den Namen der
Datei (rtniczw.sys) oder dessen MD5 in einer Suchmaschine. Die Datei war erst
einmal identifiziert worden: es war für das Scannen zu Virustotal aus China Mai
2011 gesendet wurde.
Offenbar hatte das System, das wir studieren Ende August 2011 Es wird darauf
hingewiesen, dass wir eine Stuxnet-Infektion auf dem System nicht gefunden
werden infiziert: keine zusätzlichen Dateien aus dem Stuxnet-Kit gefunden worden
war. Allerdings haben wir zu finden Duqu-Dateien.
Wir kamen zu dem Schluss, dass es auch andere Treiberdateien ähnlich wie die
"Referenz"-Datei mrxcls.sys, die nicht unter den bekannten Varianten von Stuxnet
sind sein.
rndismpc.sys
Ein Scheck in unserem Malware Sammlung half bei der Identifizierung eine weitere
interessante Datei, die in der Sammlung vor mehr als einem Jahr aufgenommen
wurde. Die Datei heißt rndismpc.sys, es ist 19.968 Byte groß ist,
MD5 9AEC6E10C5EE9C05BED93221544C783E.
Dies erwies sich als ein anderer Treiber sein, mit der Funktionalität nahezu
identisch mit der mrxcls.sys abgesehen von den folgenden Ausnahmen:
rndismpc.sys verwendet einen Registrierungsschlüssel, die von den von beiden
mrxcls und rtniczw verwendeten Schlüssel ist - es ist der
Schlüssel "rndismpc" mit dem Wert "Action";
Es verwendet einen Verschlüsselungsschlüssel, der von der durch mrxcls / rtniczw
verwendet wird - 0x89CF98B1;
Datum der Datei Zusammenstellung ist 20. Januar 2008, also ein Jahr vor mrxcls /
rtniczw erstellt wurden.
Wie rtniczw.sys hatten die Datei rndismpc.sys nie auf Maschinen unserer Nutzer
aufgetreten. Wir wissen nicht, welche Schadprogramm oder das einem Hauptmodul es
angeblich mit installiert sein.
Das Bindeglied: mrxcls.sys -> jmidebs.sys -> Duqu-Treiber
Die gewonnenen Daten und die verfügbaren Informationen über die in Duqu
verwendet (siehe Das Geheimnis des Duqu, Treiber Part One und Part Two ) kann in
der folgenden Tabelle zusammengefasst werden:
Name Größe Zusammenstel-
nung Datum Hauptmodul Verschlüsselungsschlüssel Registrierungsschlüssel Wert
Gerät
Name
rndismpc.sys 19968 20.01.
2008 Unbekannt 0x89CF98B1 rndismpc "Action" "Rndismpc"
mrxcls.sys 19840 01.01.
2009 Stuxnet.a 0xAE240682 MRxCls "Daten" "MRxClsDvX"
mrxcls.sys (signiert) 26616 01.01.
2009 Stuxnet.b / .c 0xAE240682 MRxCls "Daten" "MRxClsDvX"
rtniczw.sys (signiert) 26872 01.01.
2009 Unbekannt 0xAE240682 rtniczw "Config" "RealTekDev291"
jmidebs.sys (signiert) 25502 14.07.
2010 Unbekannt 0xAE240682 jmidebs "IDE" {} 3093983-109232-29291
.sys * Anders 03.11.
2010 Duqu 0xAE240682 "FILTER" {} 3093AAZ3-1092-2929-9391
.sys * Anders 17.10.
2011 Duqu 0x20F546D3 "FILTER" {624409B3-4CEF-41c0-8B81-7634279A41E5}
* Bekannte Duqu-Treiber eindeutige Dateinamen für jede der Varianten. Ihre
Funktionalität ist jedoch absolut identisch.
Nach unserer Analyse, jmidebs.sys ist das Bindeglied zwischen mrxcls.sys und die
Driver
später in Duqu verwendet.
Der Code der mrxcls und jmidebs Treiber ist weitgehend ähnlich. Einige kleine
Unterschiede können aufgrund unterschiedlicher Einstellungen und minimale
Änderungen in der Quellencode, während der Punkt des Codes gleich bleibt.
Es können jedoch mehr signifikante Änderungen in verschiedenen Funktionen
ermittelt werden:
Der Service-Funktion, die Adressen der API-Funktionen erhält man:
Die Version in mrxcls nutzt die Funktion MmGetSystemRoutineAddress für diesen
Zweck und die entsprechenden Textnamen der Adressen der ankommenden
API-Funktionen. Die Version in jmidebs nennt seine eigenen Funktionen
API-Adressen mit Hash-Summen ihre Namen erhalten. Die gleichen Funktionen sind
in Duqu-Treiber verwendet, während die Liste der Funktionen "Hashes ist doppelt
so lang.
Die Funktion, die Stubs erzeugt, um PNF DLL in Prozesse injizieren:
Die mrxcls Version verwendet einen Stub mit einer Gesamtgröße von 6332 Byte.
Die jmidebs und Duqu-Treiber verwenden Stubs mit einer Gesamtgröße von 7061
Byte. Die in der Stub-Module für diese Treiber verwendete Code ist identisch,
hat andere Zusammenstellung Daten aber.
Mrxcls (Stuxnet) jmidebs Duqu
API RtlGetVersion, KeAreAllApcsDisabled, indem MmGetSystemRoutineAddress
erhalten RtlGetVersion, KeAreAllApcsDisabled, PsGetProcessSessionId, erhalten
PsGetProcessPeb mit eigenen Funktionen Ähnlich jmidebs, fügte 4 weitere
Funktionen
Injiziert EXE 6332
1. Januar 2009 22.53.23 7061
14. Juli 2010 13.05.31 7061
Zusammenstellung verschiedener Daten
Driver
Evolution
Wir haben die Verbindungen zwischen bekannten Driver
, deren Entwicklung und die
wichtigsten Phasen der Entwicklung sind leicht zu verfolgen abgebildet.
Treiber Entwicklung 2008-2011
rndismpc.sys, rtniczw.sys und jmidebs.sys
Wie Sie aus dem Diagramm sehen kann, ist nicht bekannt, welche Schadprogramm mit
den folgenden drei Driver
interagiert: rndismpc.sys, rtniczw.sys und
jmidebs.sys. Die offensichtliche Frage wäre: sie waren in Stuxnet
verwendet Unserer Meinung nach wäre die Antwort sein müssen "Nein".
Erstens, wenn sie in Stuxnet verwendet worden war, hätten sie einen weit
größeren Platzbedarf als die einzelnen Fällen haben wir festgestellt haben,
verlassen. Zweitens muss es eine einzige Variante des Stuxnet die geeignet ist,
mit dieser Treiber ist nicht.
Die Datei rtniczw.sys wurde am 18. März 2010 unterzeichnet, aber am 14. April
2010 werden die Autoren Stuxnet eine neue Variante des Wurms, die Verwendung der
"Referenz" mrxcls.sys gemacht. Es ist offensichtlich, dass rtniczw.sys wurde für
eine andere Verwendung vorgesehen. Das gleiche kann von jmidebs.sys gesagt
werden. Wir glauben, dass die drei Driver
sind nur indirekt mit Stuxnet verwandt
und kann von Stuxnet Geschichte sicher gelöscht werden.
Dann gibt es eine weitere Frage: Könnte diese
Driver
haben mit Duqu verwendet?
Es gibt keine eindeutige Antwort. Obwohl alle bekannten Varianten von Duqu sind
aus dem Zeitraum November 2010 bis Oktober 2011 glauben wir dort waren frühere
Versionen des Trojaners Spion geschaffen, um Informationen zu stehlen. Die drei
Driver
in Frage hätte leicht in frühen Versionen von Duqu oder mit anderen
Trojaner auf der Basis des Stuxnet / Duqu-Plattform verwendet. Wie Duqu wurden
diese Trojaner wahrscheinlich in gezielten Angriffen vor dem Erscheinen des
Stuxnet verwendet (aus dem Jahr 2008 zumindest), die beide während er aktiv war
und nach seinem C & C wurde geschlossen. Sie waren wahrscheinlich gewesen
parallele Projekte zu haben, und Stuxnet wurde anschließend auf dieser
Erfahrungen und der Code bereits geschrieben hatte, basiert. Es scheint sehr
unwahrscheinlich, dass dies das einzige Projekt, das die Autoren beteiligt
waren.
Der Driver
Erstellungsprozess
Lassen Sie uns versuchen, sich vorzustellen, was der
Driver
Erstellungsprozess
aussieht. Ein paar Mal im Jahr die Autoren erstellen eine neue Version einer
Treiber-Datei, die Schaffung einer Referenzdatei. Der primäre Zweck dieser Datei
ist es ein Hauptmodul, der separat erstellt wird, zu laden und auszuführen. Es
könnte Stuxnet, Duqu oder oder etwas anderes sein.
Wenn es notwendig ist, einen Treiber für ein neues Modul zu nutzen, verwenden
die Autoren ein spezielles Programm, um Informationen in der Datei "Referenz"
des Drivers zu ändern, dh ihre Namen und Service-Informationen sowie die
Registrierungsschlüssel und seinen Wert.
Es ist wichtig zu beachten, dass sie zwicken fertige Dateien und nicht eine neue
von Grund auf neu erstellen. Das heißt, sie können so viele verschiedene
Treiberdateien zu machen, wie sie wollen, die jeweils exakt die gleiche
Funktionalität und Erstellungsdatum.
Je nach dem Ziel des Angriffs und des Trojaners Opfer können mehrere
Treiberdateien dann mit legitimen digitalen Zertifikaten, deren Ursprünge
unbekannt bleiben unterzeichnet werden.
Abschluss
Von Daten, die wir zur Verfügung haben, können wir mit ziemlicher Sicherheit,
dass die "Tilded" Plattform wurde um das Ende 2007 oder Anfang 2008 vor einer
seiner wichtigsten Änderungen im Sommer / Herbst 2010 Diese Änderungen wurden
erstellt löste sagen durch Fortschritte in der Code und die Notwendigkeit,
Erkennung durch Antivirus-Lösungen zu vermeiden. Es gab eine Reihe von
Projekten, die Programme auf der Grundlage der "Tilded" Plattform über den
gesamten Zeitraum von 2007 bis 2011. Stuxnet und Duqu sind zwei von ihnen - es
gibt andere, die jetzt unbekannt gewesen sein könnte bleiben Die Plattform
weiter zu entwickeln, was nur bedeuten kann, eine Sache -. Wir wahrscheinlich
mehr Änderungen in der Zukunft zu sehen.
https://securelist.com/analysis/publications/36462/stuxnetduqu-the-Evolution-of-drivers/