Den Einträgen der Registry darf man eigentlich auch nur trauen, wenn man sie von einem Live-System auslesen kann

Ergänzung: Genau das macht FRST in der RE.

Untersuchung in der Recovery Environment (RE) heißt auch Untersuchung von einem extern geladenen System aus. Das ist für mich wieder Variante 2.

Ich hatte ja nur auf die Unterscheidung...

Variante 1: Untersuchung laufendes System mit x-Tools

Variante 2: Untersuchung von externem Boot-System

...gesprochen

Hängt euch doch bitte nicht so sehr an dem "Live-CD" auf. Den Ausdruck hab ich nur geschrieben, damit klar ist was ich meine aber es ging ums Prinzip.

Ich hatte vorab nicht soo viele Bereinigungsthreads hier gelesen, aber die die ich mir angeschaut hab benutzten ausschließlich Tools die vom laufenden (wahrscheinlich infizierten) System aus gestartet wurden.

Ich hatte vorab nicht soo viele Bereinigungsthreads hier gelesen, aber die die ich mir angeschaut hab benutzten ausschließlich Tools die vom laufenden (wahrscheinlich infizierten) System aus gestartet wurden.

korrekt, da es aktuell keine richtige Malware mehr gibt. 99,99% sind PUPs oder Adware, da brauchts das nicht (ausser bei iSafe). Wenn nötig gehen wir aber von Aussen ran

Zitat von schrauber

korrekt, da es aktuell keine richtige Malware mehr gibt.

Öhm, das ist aber ein großes Fenster...

also ich hab 2014 genau 6001 Rechner bereinigt (hier, ohne die andern Boards), und davon waren vielleicht 100 nicht nur reine Adware.

Also ich sehe hier recht häufig Kombiinfektionen. Was da nu zuerst da war, keine Ahnung.
Aber das ist ja schon quasi OffToppic.

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.

das Hauptproblem hier ist (was ich sehe):
Er bastelt was, schiebt es in den passenden Ordner und sorgt dafür dass es lauffähig ist.

Mich würde mal eine Variante intressieren, die ich auf einer cleanen, durch AV geschützte VM "aus Versehen" ausführe, und dann seine Arbeit verrichtet.

Ein Virenscanner sehe ich dann als ungeeignet an, wenn mich jemand gezielt angreifen will bzw. es unbekannte Risiken gibt. Das Betriebssystem soll mich schützen und nicht so kaputt sein, dass ich einen Virenscanner vorschalten muss. Natürlich kann ich auch bei Linux z.B. irgendwelche .so-Dateien als root reinkopieren oder Systemprogramme unter /sbin austauschen. Ich möchte wissen wie so eine DLL ins System kommt und warum sie nicht erkannt werden sollte bzw. warum der Kernel sie akzeptiert. Virenscanner sind wichtig. Aber wenn er das Zeug gerade heute geschrieben hat und es eine tolle neue Idee ist wird der Virenscanner auch nichts merken.

Und wie soll Microwave das testen, ohne einer von den Bösen zu sein? :-)

Wenn er nicht einer von den Bösen ist wird er seine Software inkl. Quellcode irgendwo zum testen bereitstellen. Mal abwarten ob er einen Link postet.

hat er (bis aud den Quellcode glaube ich) in seinem Thema hier gemacht. Aber das Ding läuft nur wenn man manuell noch paar Sachen erlaubt/tut. Wenn ich mich korrekt erinnere.

Ich warte auf den fertigen Dropper, der alles selbst macht

Also viel Gebastel und Ausnahmen sind da nicht. Ausserdem handelt es sich bei der schärferen Variante (dem Keylogger) um einen sogenannten Kerneltreiber (dynamisch ladbares Kernelmodul) und nicht um eine DLL. Da gibt's auch keine grossartige Installation, vorausgesetzt, der sogenannte Testmodus ist aktiviert. Zudem muss man natürlich so hell sein, einen allfälligen Dropper mit Adminrechten auszuführen, da mindestens das SeLoadDriverPrivilege nötig ist.
Problem ist hier wirklich hauptsächlich die Treibersignierung von 64-Bit Windows.
Angenommen, diese sei aus einem Grund X deaktiviert, sind noch zwei auffallende Aktionen erforderlich: .
- Entpacken des Treibers in ein Verzeichnis X (z.B. Temp/mybadrootkit.sys)
--> Erstellen eines Registrykeys mit Name mybadrootkit und Werten "Type "und "ImagePath" darin
--> Öffnen von fltmc.exe load mybadrootkit oder Aufruf von ntdll!NtLoadDriver

Bzgl. Heuristik: Wenn das AV eine sogenannte LoadImageNotifyRoutine für Kernelmodule hat, helfen auch direkte Intel Syscalls (0F 05) nicht. (In diesem Fall könnte man den Treiber auch UsbDrv30.sys nennen zur Tarnung, dann denkt der Benutzer vielleicht, es sei legitim..)

Verdächtige Dateioperationen kann man verhindern, indem man den Treiber nicht in System32/drivers kopiert, sondern z.b. auf den eigenen Desktop.
Registry-Operationen kann man vielleicht mit NtSaveKey/NtLoadKey oder so ähnlich umgehen/unverdächtig aussehen lassen.
Das und nicht mehr müsste ein Dropper können.

Ist keine Testsignierung eingeschaltet, wird man nicht um einen Neustart kommen nach erfolgreicher Erstellung eines BCD-Eintrags "testsigning Yes". Der Neustart kann entweder irgendwann erfolgen, oder aber man erzwingt einen mit NtSetSystemPowerState oder einfach NtShutdownSystem. Möglicherweise können AV-Treiber aber Power-Callbacks registrieren.. Dann müsste man das auch wieder unverdächtig aussehen lassen. Zudem könnte man am Explorer schnell ein SetWindowsHooksEx ausführen und dann Mausereignisse abgreifen. Wenn sich nun die Maus 10Minuten lang nicht bewegt und die CPU-Last unter 10% ist, scheint der Benutzer "afk" zu sein und man kann einen Neustart durchführen.. So ungewöhnlich sind plötsliche Neustarts nicht, unter Windows..

Und eben.. Von Hand muss man überhaupt nichts präparieren, man kann den Dropper nämlich auch die Testsignierung einschalten lassen.

Momentan bin ich aber gerade anderweitig beschäftigt, einen Dropper gibts also wenn überhaupt, erst später. Atm bin ich eigentlich damit beschäftigt, ein kleines HIDS zu programmieren..


Grüsse - Microwave

P.S. Quellcode des Kernel-Treibers sollte eigentlich auch auf km.info sein...

vorausgesetzt, der sogenannte Testmodus ist aktiviert

Klar, wir user aktivieren den ja freiwillig .

Das musst Du machen . Erst dann ist ein echter Test deiner "Malware" aussagekräftig.