Kleines "Proof of Concept"-Rootkit (Usermode) für AMD64

Microwave

Hi Anti-Trojaner, mal etwas von der "anderen" Seite.

Nach längerem Herumprobieren habe ich es endlich geschafft, ein kleines Demo-Rootkit für 64-Bit-Windowssysteme zu basteln (getestet auf Windows 7SP1 und 8.1)
Es verhält sich wie ein gewöhnliches (Demo-)Rootkit und versucht seine Anwesenheit zu verbergen, in dem es bestimmte Dateien und Registrierungsschlüssel versteckt (derzeit sind drei Präfixe auf der internen schwarzen Liste) und spezielle Daten in der Registrierung anders darstellt, als sie in Wirklichkeit vorhanden sind.
Registrierungswerte, Prozesse und weitere Systemelemente können von dieser Version aber noch nicht ausgeblendet werden.

Um schlechte Magie zu erleben, muss die DLL in einen beliebigen, nicht geschützten 64bit-Prozess "injiziert" werden, der betreffende Prozess "sieht" verdächtige Dateien und Schlüssel dann nicht mehr.

Das Interessante am Rootkit ist nun aber die Tatsache, dass man mit Prozess-Tools noch lange nach der geladenen DLL suchen kann, da diese nach erfolgtem Patching sofort wieder aus dem jeweiligen Prozess verschwindet.

Soll das Rootkit global agieren, muss es z.B. in C: oder C:\Windows abgelegt werden, der Pfad zur DLL im Registrierungsschlüssel "AppInit_Dlls" eingetragen werden und der Wert LoadAppinit_DLLs auf 1 gesetzt werden.
Spätestens nach einem Neustart ist dann zumindest für Laien nicht mehr erkennbar, dass vielleicht etwas nicht ganz stimmt...

Dass diverse Prozess-Viewer keine verdächtige DLL finden können, dürfte soweit klar sein - viel interessanter ist jedoch, was die weit verbreiteten Scantools (wie z.B. FRST64) daraus machen, was auch ein Hauptgrund für meinen Beitrag ist .

Im Anhang findet ihr die LOGs von FRST64, OTL, mbar, TDSSKiller und gmer.


Erklärungen zu den einzelnen Ergebnissen:
- FRST64 sieht überhaupt nichts, was mit "R00tk!t" o.ä. zu tun hat.
Auch in der Addition sind wenig aufschlussreiche Ergebnisse.

- OTL sieht alles, da es unter WoW64 läuft und somit (noch) nicht gepatcht wird.

- mbar erklärt beim Start, dass ein spezieller Registrierungswert (eben jener AppInit-DLLs-Wert) gefunden worden wäre und auf mögliche Rootkit-Aktivität hindeuten könne, kann dann aber auch nicht herausfinden, was es mit dem Schlüssel, oder der Aktivität im Einzelnen auf sich hat, was vermutlich der signaturbasierten Erkennung geschuldet ist.
Dass mbar überhaupt den Wert erkennt, hängt wieder mit WoW64 zusammen (mbar ist ein 32-Bit-Prozess).




- TDSSKiller erkennt einen für Regedit versteckten Treiber (er ist nicht aktiv, ist einfach ein Trittbrettfahrer), zeigt ihn aber nur als unsigniert und nicht als versteckt an, wie auch die anderen paar Treiber.

- gmer schliesslich zeigt beim Vollscan, dass einschlägige Systemaufrufe gepatcht wurden, zeigt aber auch nicht an, dass eine "R00tk!t.dll" daran schuld ist.
Immerhin zeigt der Autostart-Tab recht schnell, dass via AppInit_DLLs eine unbekannte DLL gestartet wird:



Das Rootkit wurde übrigens unter Anderem mithilfe von Codeausschnitten aus folgenden Quellen erstellt:
Kernelmode-Rootkit "Agony" (Code zum Verstecken von Dateiobjekten und Registrierungsschlüsseln)
Splice-Library "libsplice_um" (Code, um bestimmte Systemaufrufe in der NT-API sauber auf meinen Code umzubiegen)

Um zu verstehen, was im Prozessspeicher passiert, wurden zudem "Cheat Engine 6.3" und "Process Hacker" verwendet, die Injektion zum Testen erfolgte jeweils mit "Process Hacker".

Für die Interessierten ist das Binary ebenfalls angehängt, wobei ich ausdrücklich nicht verantwortlich dafür bin, was ihr damit anstellt.
Eine Möglichkeit für Recovery-Schreibzugriff auf NTFS zu haben, ist bestimmt nie verkehrt.


Wenn ich dann auch 32-Bit-Prozesse hooken kann und eine Lade-Anwendung realisiert habe, melde ich mich wieder.


Probleme:
- Es finden keine Hooks von NtLoadDriver und VirtualProtect statt, somit kann selbst das Ring3-Tool "Hookshark64" feststellen, dass Aufrufe umgeleitet werden, und GMER kann ausgeführt werden
- Es wird nicht geprüft, ob der Systemaufruf die erwarteten Bytefolgen aufweist (und somit nicht bereits durch echte Malware verändert worden ist)
- Die DLL ist nicht gegen Löschen geschützt und - das Wichtigste - die Starteinträge des Rootkits sind nicht gegen Veränderung geschützt
- 32-Bit-Prozesse werden nicht verändert
- Nach Start der DLL wird nicht geprüft, ob andere Threads gerade auf die zu modifizierende API-Funktion zugreifen


Grüsse - Microwave

Angehängte Grafiken

	gmer.png (34,7 KB, 1075x aufgerufen)
	mbar.png (35,0 KB, 1095x aufgerufen)