Jup. Das klang aber auch ziemlich trollig. => http://www.trojaner-board.de/151164-...ml#post1302317

Das Usermode-Rootkit spielt in einer gänzlich anderen Liga.
Da wir hier keinen Treiber laden, kann uns der Signierungszwang von Microsoft (KMCS) so lang wie breit sein, denn noch(?) muss nur Kernelcode signiert sein, um ausgeführt werden zu können.
Deshalb kann das Rootkit einfach ohne Neustart im System verankert werden.

Zudem kommt dieses Rootkit ja inklusive Dropper.
Dafür beträgt die "Stärke" dieses Rootkits nur ein Bruchteil derjenigen des Kerneltreibers - wir haben "nur" Admin-Rechte.
Ausserdem wird der Dropper auch sehr gut erkannt, immerhin gebrauche ich ganz unverblümt OpenProcess(...,PROCESS_VM_OPERATION,...) und WriteProcessMemory gefolgt von CreateRemoteThread.

Den Testmodus schalte ich dir mit links ein, schrauber, das ist nicht das Problem.
Wesentlich höherer Fähigkeiten bedarf es jedoch, um zu verhindern, dass die Standard-Scanner (FRST64 & co.) den plötzlich aktivierten Testmodus anmeckern - ohne Verwendung von Hooks, meine ich jetzt.
Und ziemlich unmöglich ist es dann, die Tools auch in einer WinRE glauben zu machen, dass alles im Lot sei.
Allerdings darf man sich dennoch nicht sicher fühlen, denn mit einem gefälschten Zertifikat brauche ich keine Testsignierung und keinen verdächtigen Neustart, dann gibt's für die Tools auch nix mehr zu erkennen. Dass man Zertifikate klauen kann, hat Stuxnet ja bewiesen .


Grüsse - Microwave

Und ziemlich unmöglich ist es dann, die Tools auch in einer WinRE glauben zu machen, dass alles im Lot sei.

das meinte ich ja weiter oben. In der RE hat nichts ne Chance.

Zitat von schrauber

das meinte ich ja weiter oben. In der RE hat nichts ne Chance.

Ohne Zertifikat - ja, wie ich sagte.
Mit Zertifikat - Denke schon. Oder hast du gerade konkrete Tipps, wie man z.B. den $Extend-Ordner unter WinRE scannt, um herauszufinden, ob da was ist? FRST64 und co. werden dann nichts mehr anzeigen, weil in diesem WC-Szenario ja keine Testsignierung aktiviert wäre - also keinerlei Anhaltspunkte!
Weder autoruns noch FRST64 noch regedit noch weitere Tools zeigen den Eintrag an in der WinRE. Selbst RegDelNull wird nichts anzeigen, weil ja nicht das "\0-im-Schlüssel-Prinzip" angewendet wird.

Daher bleibe ich bei meiner Behauptung. Der installierte Treiber ist standardmässig nicht erkennbar, der Testsignierungs-Eintrag schon.
Wenn jetzt jemand viel mit Custom-µC-Brennern spielt (Hobbybastler), gibts vielleicht auch nicht immer für jeden Brenner einen signierten Treiber. So Leute stellen dann Beispiele dar, wo legitime Testsignierung doch noch vorkommt.
Auch wenn man am Boot-Design umherschrauben will, ist man ja gezwungen, wichtige Systemdateien zu patchen - also wieder Testmodus völlig legitim eingeschaltet..


Grüsse - Microwave

Der installierte Treiber ist standardmässig nicht erkennbar

In der RE? Gib mal her das Ding, halte ich für ein Gerücht. Und wir müssten dann noch die Definition von "standardmäßig" klären

Hier angehängt:
hxxp://www.kernelmode.info/forum/viewtopic.php?f=14&t=3461#p24775, Quellcode auf der nächsten Thread-Seite.

Standardmässig bedeutet mit Tools wie Regedit oder verschiedenen Scannern. Jedenfalls war das am 31.12.2014 noch so, vielleicht wurden mittlerweile essentielle Funktionen von FRST64 angepasst, dass ungültige Treiber-Einträge auch erkannt und angemeckert werden.

Aber:
Wenn FRST64 gescannt hat, ist die Registry iirc noch geladen und der Services-Schlüssel kann mit dem Regedit eingesehen werden. Dann kann man auch gerade den gesamten Services-Key exportieren und die .reg-Datei im notepad analysieren. Scrollt man dann ganz hinunter, sieht man meine Einträge. Manuell ist der Treibereintrag also erkennbar.
Er manifestiert sich als Schlüssel, der mit Z beginnt und der vorhergehende Schlüssel hat eine Menge Leerzeichen drin.
Nicht erkennbar ist jedoch die ausführbare Imagedatei (Das Command "more" kann jedoch deren Inhalt anzeigen, wenn man deren genauen Namen kennt...). Die Datei ist übrigens auch nicht ohne Akrobatik zu entfernen. ntfs.sys verhindert wirksam, dass diese jemand zu Gesicht bekommt, geschweige denn sie verändert - auch in der WinRE-Umgebung.


Grüsse - Microwave

Ich lade mal

Zitat von schrauber

Ich lade mal

Hat das Laden denn geklappt?
Ich verfolge diesen Thread mit Interesse und bin neugierig, wie er weitergeht.

habs noch nit versucht, zu viel um die Ohren im Moment. Da ich aber eh noch 4 neue VMs bauen muss ist das mit auf dem Zettel

Mach es lieber mit einem reellen System. Sonst wird noch gesagt, dass die VM irgendwas verfälscht oder so

Wenn die VM auch eine kbdclass.sys hat und Windows auf C:\Windows installiert ist, sollte es eigentlich gehen.
(Momentan noch unschön, ich arbeite mit hardkodierten Laufwerksangaben)

Grüsse -Microwave

Warum nimmst keine Umgebungsvariablen... %SYSTEMDRIVE% und/oder %WINDIR%

Afaik sind Umgebungsvariablen ein gerüttelt Mass mehr Highlevel als das, was ich mache. D.h. ich hab da gar keine Umgebungsvariablen.. (Und mir fällt gerade ein, dass theoretisch eigentlich nur der Laufwerkbuchstabe stimmen müsste.)

Grüsse - Microwave