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

Micro-Update:

- Prozesse mit Präfix "R00tk!t" werden versteckt
- Die DLL taucht nicht mehr mit korrektem Namen unter "unloaded modules" im WinDbg auf.
Nun sind meiner Meinung nach keine Rückschlüsse mehr auf den "Urheber" möglich, da sich zu diesem Zeitpunkt im Speicher ja eigentlich ohnehin schon lange nichts mehr befindet, und "unloaded modules" sozusagen der letzte Beweis dafür war, das etwas nicht stimmt.
Diverse String-Suchen mit Process Hacker nach Original- und Fakename lieferten keine brauchbaren Resultate.
Um das Rootkit jetzt noch zu entdecken, kann man Process Monitor verwenden, dessen LoadImage-Notify-Routinen ziemlich schnell zeigen, wie das Rootkit tatsächlich heisst.

Damit der Fake funktioniert, muss die DLL exakt "~FontCache.dat" heissen - AppInit_Dlls ignoriert die Endung und lädt die DLL trotzdem.
Da hier mit einigen undokumentierten Strukturen und ohne Checks gearbeitet wird, sollte das Rootkit nur auf Windows 8.1 ausprobiert werden.

Nun werde ich damit beginnen, 32-Bit-"Support" zu implementieren.


Grüsse - Microwave

P.S. hatte ein Beitrags-EDIT versucht, aber das gab es nicht (oder ich war zu dämlich, es zu finden)

Und für die Interessierten geht's mal wieder weiter:

- Gängigste Anti-Rootkits/herunterladbare Antivirentools wie GMER, MBAR, TDSSKiller, aswMbr, OTL oder Emsisoft Emergency Box sind nun unbrauchbar, funktionieren nicht korrekt oder übersehen einfach die Systemveränderungen
- Usermode-Hookscanner aka Hookshark64 sind unbrauchbar wegen Zugriffssperre auf ntdll.dll
- Vollständiger 32-Bit-"Support"
- Starteinträge können vom "infizierten" System aus nicht einfach überschrieben werden, da sie sofort wieder auf die zum DLL-Laden erforderlichen Werte gesetzt werden (genauer gesagt bei jedem Process/Thread-Attach/Detach an die Rootkit-DLL)
Dabei schreibt die 64-Bit-Version auch die Starteinträge der 32-Bit-Version, die 32-Bit-Version aber nur 32-Bit-Einträge
- Nach wie vor keine verantwortliche DLL vorhanden, wenn man mit ProcessExplorer/Process Hacker die geladenen DLLs anschaut
- Die Grösse des gesamten Programms ist nicht allzu auffällig mit 38kB

Das 32- und 64-Bit-Binary wurde getestet auf Windows 7 SP1 x64, Windows Server 2008 R2 und Windows 8.1 x64.

Zudem habe ich mal noch einen Loader geschrieben - verständlich, dass dieser "keygen.exe" heissen muss.
Da der Lader ja auf das "Adobe AfterEffects CS7(Gibts, glaube ich, noch gar nicht )"-Verzeichnis in "C:\Program Files (x86)" zugreifen muss, erfragt er sich selbstverständlich Admin-Rechte (obwohl zumindest auf Win7 noch der sogenannte "WinElevate"-Trick funktionieren würde).

Das Ladeprogramm organisiert sich zuerst Debugprivilegien, damit es auf mehr Prozesse Zugriff hat, und extrahiert dann die komprimierten x86- und AMD64-Abbilder des Rootkits in ein Unterverzeichnis von Windows.
Anschliessend schmeisst der Loader die 64-Bit-DLL in die meisten 64-Bit-Prozesse, und die Startroutine der AMD64-DLL schreibt die erforderlichen Autostart-Einträge.
Hatte man zu diesem Zeitpunkt 32-Bit-Prozesse gestartet, bleiben diese unbeeinflusst.
Grund dafür ist, dass ich nicht herausgefunden habe, wie man von einem 64-Bit-Prozess aus ein 32-Bit-LoadLibraryA im x86-Zielprozess ausführen kann.

Sobald ein neuer 32-Bit-Prozess gestartet wird, wird er aber durch den AppInit_DLLs-Eintrag ebenfalls gepatcht und "sieht" dies und jenes nicht mehr.

Nach getaner Arbeit gibt der Lader eine adäquate Fehlermeldung aus und beendet sich.
Die "keygen.exe" wird aber nicht gelöscht, da dies zu auffällig wäre. Nachteil ist halt, dass der Verursacher auf dem Silbertablett präsentiert ist und selbst mit dem Editor analysiert werden könnte.

Den AppInit_DLLs-Eintrag könnt ihr, wie erwähnt, versuchen zu überschreiben, dies wird das Rootkit nicht ausser Gefecht setzen.
(Dieses Prinzip könnte man vielleicht sogar umkehren, um sich hostbasiert gegen (schlimme) Malware zu schützen - einfach *.sys blocken und NtLoadDriver gerade auch noch - damit Malware jetzt diese APIs wieder nutzen dürfte, müsste sie erst alle Prozesse (inkl. sich selbst) beenden und AppInit_DLLs löschen)

Leider ist noch keinerlei Netzwerk-Funktionalität implementiert - ab da fängt der Spass ja erst an...

Nach wie vor gibt es eine Menge Schwachstellen, an denen man ansetzen könnte:
- Sowohl Hookshark64 als auch Process Hacker zeigen im Zielprozess ausführbare Speicherseiten an, die keiner DLL zugeordnet sind - das ist ein gutes Indiz
- Die gepatchten APIs sind nicht gegen Unpatching geschützt (man könnte aber NtVirtualProtect hooken und Schutzveränderungen an bestimmten Stellen verweigern)
- Bootet man in den abgesicherten Modus, wird das Rootkit nicht geladen und kann leicht gefunden werden
- Momentan sehr rigorose Zugriffsbeschränkungen auf "geblacklistete" Dateien (*.sys, ntdll.dll, usw.) --> die häufigen Fehlermeldungen sind etwas auffällig - mit mehr Systemwissen könnte man das ganze feiner abstimmen, so dass wirklich NUR noch Rootkit und Trittbrettfahrer selbst versteckt sind
- Einige Spezialtools schaffen es nach wie vor, an mehr Informationen zu kommen, als mir lieb wäre (PowerTool x64 von KernelMode.info z.B.)
- Die beiden Images werden nur aktiv versteckt, man könnte sie jedoch auch noch als "Versteckt" und "System" markieren, oder gar in ADS verstecken
- Da cmd.exe keine user32.dll benötigt, wird auch keine AppInit_DLL geladen. cmd.exe sieht also ALLES --> dies führt irgendwann zur Notwendigkeit einer neuen Lademethode.
Alternativ könnte die DLL jeden Prozesses einen Thread erstellen, der die DLL periodisch in alle Prozesse mit oder ohne user32.dll injiziert, Nachteil wäre vermutlich die klare Sichtbarkeit eines unbekannten Zombie-Threads in Process Explorer & co.
- Da viele Antivirenprogramme eine DLL-Injektion verhindern dürften, müsste man neue Wege finden, den Rootkit-Code zur Up-Time in die Prozesse zu bekommen. (In Windows Internals Bd. 2 dürfte einiges über Shared Sections, Views und co. zu finden sein..)

Angehängt ist wieder das Binary, auf Anfrage könnte man auch über den Quellcode reden.


Grüsse - Microwave

Wie krieg ich das weg? Wieso machst du sowas überhaupt? Es kopiert sich immer wieder, jetzt kann ich nicht mal ein Spybot ausführen!! MACH ES WEG!!!!!

Wie man es wegmacht, kann ich dir leider auch nicht sagen, aber wieso Malwarebekämpfer "Ausprobier"-Malware schreiben, kann ich mir ungefähr denken: Man am genauesten feststellen und verstehen, wie die bösen Programme funktionieren, indem man selbst welche schreibt.
Er hat es ja nicht irgendwo untergejubelt, sondern genau dazugeschrieben, was es macht, und es anderen Malwarebekämpfern zur Verfügung gestellt.
Das nächste Mal weißt du, dass man so was nicht auf einem Produktivsystem ausprobiert, sondern auf einem System, das man sowieso neu aufsetzen will.
Ich hoffe aber, man kann dir hier noch helfen, es ohne großen Ärger loszuwerden!

Es kopiert sich immer wieder, jetzt kann ich nicht mal ein Spybot ausführen!

Warum führst du es denn aus, wenn du nicht weißt wie du es wegbekommst bzw. du das System noch brauchst. Spybot ist eh Schrott, das kann gar nix.

Keckrem, von als gefährlich geschilderten Dingen geht nun mal eine gewisse Faszination aus und man muss sich manchmal echt beherrschen, um sie nicht auszuprobieren. BESONDERS wenn die Gefahr nicht direkt glaubhaft ist (was ich gespeichert habe, kann ich ja wohl auch wieder löschen... und außerdem wird ja wohl in einem seriösen Forum nichts echt Böses angeboten...) Siehe die immer wiederkehrenden Fälle von Kindern, die bei Frost Metallgegenstände anlecken, und Erwachsenen, die sich Glühbirnen in den Mund stecken (wenn der Mund so weit aufgeht, dass sie rein kommt, MUSS er doch auch exakt genauso weit aufgehen, damit sie wieder raus kommt...).

Plagiat, mach doch mal in "Plagegeister..." oder "Log-Analyse..." einen neuen Thread auf, da sind die Helfer schon ganz gelangweilt von der vielen Standard-Adware. Für die ist es bestimmt eine nette Abwechslung, dieses Rootkit zu bekämpfen. Gib aber fairerweise einen Link zu diesem Thread an.

Aber bitte mit FRST und GMER-Logs, auch wenn die ja nix von dem Rootkit finden...

Keckrem, das ist zwar einerseits irgendwie schon lustig, aber ich würde sagen: ja! "Logs bitte immer posten, auch wenn nichts gefunden wurde" habe ich schon in vielen Bereinigungsthreads gelesen. Und ist es nicht irgendwie echt cool, diese Demo-Malware aus dem eigenen Forum in "freier Wildbahn" untersuchen zu können?

(Außerdem ist ja nicht ausgeschlossen, dass zusätzlich noch Adware oder was drauf ist)

Klar, man weiß ja nie ob der Scanner up-to-date ist und der Scan richtig und als Administrator ausgeführt wurde. Zumal man als Laie bei FRST nie weiß, ob ein schädlicher Eintrag drinsteht.

Also irgendwie gehört dieser Thread m.E. nicht in den öffentlichen Bereich.

Ich glaube der Bereich ist schon ok, jedoch sollte ich das nächste Mal wohl ein Passwort hineintun.

plagiat hat jedoch nicht unbedingt geschickt gehandelt, das hätte man auch kluger anstellen können.
Glück im "Unglück" ist, dass diese Version einen gewaltigen Bug hat, der mir erst später eingefallen ist. Dieser führt dazu, dass man das Rootkit ausser Gefecht setzen kann, indem man irgendwelchen Müll in den AppInit-Eintrag schreibt, wobei genau das ja eigentlich verhindert werden sollte. Die Release-Version (nicht veröffentlicht) weist diesen Bug nicht mehr auf.


Grüsse - Microwave

P.S. Es sei einmal mehr versichert, dass die einzigen Funktionen im sich selbst verstecken und Entfernungsverhindern bestehen.