Hier geht's um Rootkits und Ähnliches?
Fein, da misch ich mich gerne ein

@foxm2k:
Proof of Concept bzgl. Systemaufrufe verbiegen gibt's schon, hier ein kleines Rootkit entwickelt von meiner Wenigkeit:
hxxp://www.kernelmode.info/forum/viewtopic.php?f=15&t=3259
Sollte laufen unter Windows 7 SP1 und Windows 8.1 64-Bit.
Allerdings ist das ziemlich leicht erkennbar, wenn man weiss, wonach man sucht.
GMER funktioniert beispielsweise überhaupt nicht mehr, das ist dann natürlich schon etwas seltsam.
Offline hat der PoC sowieso keinerlei Chance, dem FRST64-Scanner zu entgehen.

Das Problem liegt daran, dass klassische Hooks Veränderungen vom System darstellen - und zwar Veränderungen von statischen Daten, sprich Code, und das ist IMMER auf die eine oder andere Art erkennbar, denn Code hat sich niemals zu verändern. Desweiteren ist ist natürlich immer höchst unverdächtig, wenn es on- und offline unterschiedliche Scanresultate gibt.

Wenn du im Kernel Hooks anbringst, kannst du im Livescan alle Tools hier alt aussehen lassen, wenn du es richtig angehst. Du kannst auch den "Configuration Manager" oder den Disk-Treiber (disk.sys) unterwandern und alle Bemühungen in Stücke hauen, dich zu finden. Offline-Scans sind allerdings etwas anderes. Zudem ist heutzutage die deutliche Mehrheit der Privatsysteme x64-basiert, was dich vor zwei Probleme stellt:
- Kernel Patch Protection (Man darf so ziemlich überhaupt nichts im Kernel-Adressraum modifizieren, weder Code noch Daten (zum Prozesse verstecken oder unsignierte Treuber laden zuzulassen etwa).
- Kernel Mode Code Signing Policy (Wenn man nicht möchte, dass auf dem Desktop ein bändesprechendes "Testmodus, Windows XY, Build Schlagmichtot" zu sehen ist, muss jeder Kerneltreiber mit einem gültigen Produktions-Zertifikat (nicht Testzertifikat!!) versehen sein.)

Das Zweite stellt eine grössere Hürde dar, aber das Erste lässt sich sehr einfach umgehen, wenn man sich mal ganz kurz überlegt, wozu ein Rootkit eigentlich Informationen verfälschen will. Alternativ lässt sich PatchGuard auch deaktivieren, mit Windows 8/8.1 ist das aber sehr schwierig geworden und ist ja eigentlich ohnehin sinnlos:
Warum Informationen verfälschen? Logische Antwort: Ein Rootkit versucht damit, seine Anwesenheit und die anderer Malware zu verbergen.
Aber - Muss das aktiv geschehen? Kann man nicht betriebssystemeigene Mechanismen ausnutzen, um sich oder Informationen zu verbergen?
Doch! Man kann, und wie! Zudem hat man den Vorteil, dass windows-basierte Recoverylösungen überhaupt rein gar nichts Verdächtiges anzeigen, weil man ja nur passiv versteckt ist. Die alte Regel "Bei einem Offline-Scan kann die Malware gefunden werden, weil sie sich nicht mehr gegen eine Erkennung wehren kann" stimmt dann nicht mehr.
Schau dir dazu mein anderes "Rootkit" an: hxxp://www.kernelmode.info/forum/viewtopic.php?f=14&t=3461

Zusammenfassung der wichtigsten Punkte des obigen Kernel-Treibers:
- Datei ist versteckt im nie sichtbaren (weder unter Windows noch unter Linux) "C:\$Extend\$RmMetadata"-Verzeichnis.
- Treiber-Datei wird im abgesicherten und im normalen Start über einen speziell präparierten Registrierungseintrag geladen. Die Einträge im Schlüssel sind hier derart verbogen und ungewöhnlich, dass Windows den Treiber zwar noch automatisch lädt, aber Tools wie FRST64 nichts damit anfangen können und den Eintrag deshalb nicht listen.
- Über manuelle Schreiboperationen erstellt der Treiber eine spezielle Version des "testsigning YES"-Werts, die von normalen Tools und bcdedit nicht entfernt werden kann. Damit ist die zweite Hürde technisch überwunden, jedoch können viele Tools den BCD-Eintrag listen und dann ist erkennbar, dass da zweimal "testsigning" steht.
- In normalem Betrieb abonniert der Treiber ein paar Benachrichtigungen, ob sein Eintrag, der Boot-Eintrag oder seine Datei verändert oder gelöscht wurden und stellt sie kurzerhand wieder her.
- Nachdem der Kernel-Treiber geladen wurde, entfernt er sich wieder aus dem Speicher, damit er nicht mehr in der Liste der geladenen Treiber auftaucht. Alle seine Systemthreads laufen von als ausführbar markiertem "Nonpaged Pool" aus.
- "Nutzlast" (Payload) ist ein Keylogger. Dazu werden dynamisch sogenannte IRP-Hooks angebracht, und zwar nur, wenn eine Taste gedrückt WIRD (nicht IST). Dies verhindert eine Erkennung durch Spezialtools, die die sogenannte "MajorFunction Table" enumerieren können.

Das Teil erkennst du weder per LiveCD noch per FRST im Offlinemodus (WinRE) noch unter laufendem Betrieb, wenn du nicht ganz genau weisst, wonach du eigentlich suchst. Sowohl MBAR, MBAM, GMER und TDSSKiller strecken hier alle Viere von sich und selbst mit Tools wie PC-Hunter kannst du zwar Veränderungen erkennen, aber nicht immer nicht beheben.
Du kannst allerdings den Service-Key in der Registry exportieren (auch online), dann findest du schnell heraus, was nicht stimmt.

Eine weitere Technik besteht darin, den Treiber zu laden, zu entfernen (und komplett zwar aus Registry, Dateisystem und dem Kernel-Speicher), und kurz bevor der PC wieder heruntergefahren wird, wieder die Datei und den Registry-Eintrag zu schreiben. Frühe Versionen meines Kerneltreibers arbeiteten nach diesem Prinzip.
Hier ist ganz klar der Vorteil, dass der Treiber per Definition des Wortes "Löschen" ÜBERHAUPT NICHT MEHR erkennbar ist, wenn man nicht einen Memory-Dump provoziert, oder die Kernelstacks der laufenden Systemthreads untersucht. (Erkennbar ist wohl aber der "testsigning YES"-Eintrag.)
Nachteil ist, dass die Entfernung prinzipbedingt sehr einfach ist, weil der Treiber ja ein sauberes Herunterfahren braucht, um zu merken, dass er sich wieder neu installieren kann. Dazu halt einfach den PC abstürzen lassen.
Wenn du noch mehr basteln/probieren willst: Mit Leerzeichen in Registry-Einträgen und Dateinamen schaffst du auch allerlei Unmögliches. Da kannst du dann auch Treibernamen und Einträge auf deinen Kram umbiegen, so dass am Schluss on- und offline überhaupt gar niemand mehr den Durchblick hat.

Für die momentan ITW vorkommende Mal-/Adware hat man mit den standardmässig verwendeten Tools aber noch einen ziemlich guten Durchblick.

Und was Virtualisierung und BluePill angeht: Im laufenden Betrieb mag das 100%ig? unsichtbar sein, doch wie sieht's im Offline-Modus aus? Wenn es über den MBR/VBR startet, steht man wieder vor dem selben Problem: Code (der MBR/VBR) verändert sich nicht. Wenn er dies trotzdem tut, ist wahrscheinlich etwas faul.

Am besten versteckt ist man immer noch in der Registry, weil man die nicht sinnvoll offline scannen kann - zuviel verändert sich hier jedes Mal, als dass man eine heuristische Erkennung durchführen könnte. Um die Registry heuristisch effektiv analysieren zu können, muss man sie laden (mappen) und dann verstehen, man muss also Windows verstehen.
Schau dir mal Sirefef/ZeroAccess an, der kam später völlig ohne Hooks aus und hat ein sehr grosses Botnet zustande gebracht (blieb also gut versteckt).
Das Einzige was der zum Starten benutzt hat, waren irgendwelche Einträge aus der \CLSID\{XXXX...}-Kategorie, bei der sowieso kaum jemand richtig durchblickt, was die ganzen GUIDs zu bedeuten haben. Die Datei war durch einen überflüssigen Reparse-Point geschützt bzw. versteckt.

Wieder mal viel zu lang geworden, alles.


Grüsse - Microwave

EDIT: Ich ziehe es auch sehr vor, live am PC zu sitzen, wenn ich etwas reparieren muss.
Mit meinem speziellen Rettungssystem, das ein direkt von USB startbares Windows 7 SP1 x64 einschliesst, bekomme ich jedes Problem gelöst, behaupte ich jetzt mal bewusst grossspurig. Und wenn sich das Problem (insbesondere auf den eigenen PC bezogen) nicht in vernünftiger Zeit lösen lässt, arbeite ich einfach auf dem Rettungssystem-Windows, bis ich wieder Zeit habe, das Problem genauer zu untersuchen.
Da sieht so ziemlich jede LiveCD/WinRE-Umgebung steinalt aus, dagegen.

Danke für die sehr ausführliche Beschreibung. Leider habe ich fast nichts verstanden. Aber es scheint ja so, dass dein Rootkit scheinbar als DLL-Datei irgendwie ins System kommt. Kannst du das noch genauer schreiben. Wie kommt die DLL-Datei ins Windows bzw. wie verhindert Windows es? Verzichte in der Betrachtung auf Virenscanner. Eine gezieltes Rootkit wäre wohl so optimiert, dass kein Virenscanner oder zumindetens der des Opfers ihn nicht erkennt.