Grundsätzliches - Laufendes System untersuchen sinnvoll?
 

Hallo zusammen,

ich bin kein dedizierter Sicherheitsexperte aber beschäftige mich seit fast 20 Jahren mit PCs, Windows, Programmierung (auch systemnah) und vielen Bereichen rund um dieses Themenfeld.

Seit einigen Jahren setze ich bei der Analyse mir privat überlassener Problemfälle sehr gerne auf eine isoliert externe Sicht auf das System. Sprich ein Boot-Linux, von dem aus ich mit diversen Tools und Virenscannern das System durchleuchte. Das Vorgehen gewinnt seit Desinfec't auch allgemein an Popularität.

Daß dabei gerade keine Prozesse laufen sondern sich die Anlayse ausschließlich auf persistent gespeicherte Daten bezieht, habe ich dabei immer als Vorteil verstanden. Schließlich muß sich jedes Schadprogramm irgendwo speichern, um auch beim nächsten Systemstart wieder geladen zu werden.

Auf der anderen Seite kann ich im laufenden System nach einer Infektion nicht mehr sicher sein, welche Systemfunktionen u. U. verbogen wurden. Kernelnahe Hooks könnten einem anfragenden Analyse-Programm eine gefilterte Wirklichkeit weiterreichen. Ein Hook auf die NTCreateProcess könnte den Start einiger bekannter Programme verbieten oder durch den Aufruf täuschend ähnlich aussehender Plazebos inkl. Ausleitung gefälschter Log-Dateien ersetzen.

Soweit ich das bisher beobachtet habe, setzt die Analyse hier im Forum ein breites Arsenal an Programmen ein, die jedoch alle das laufende System untersuchen. Wie steht ihr zu dazu? Mit welchen Maßnahmen wird diesen Risiken begegnet? Gilt z.B. erst ein redundant erhobener Befund oder das Fehlen eines solchen als 'gesichert' (schließlich werden ja praktisch immer eine ganze Reihe Programme nacheinander konsultiert)?

Viele Grüße,
Andreas

Ein Forum wie dieses und eine Live CD sind an sich schon verschiedene Dinge.
Mit der Live CD oder Stick, ist man erst mal alleine, hier im Forum nicht.
Jeder der es will, schafft hier eine sagen wir mal, fundierte Bereinigung des Systems ohne profunde PC Kentnisse.
Allein das erstellen einer Live CD stellt einige User schon vor Probleme.
Zu den Tools die hier verwendet werden ist zu sagen, das sie eine Kombination von privat und durch firmen erstellte Software sind und sicher redundante Prozesse durchspielen. Aber jedes dabei mit einer anderen Engine und am Ende auch anderem Ergebnis.
Meiner persönlichen Meinung nach, würde ich mich, wie jeder andere hier wahrscheinlich auch, am liebsten selber an jeden infizierten Rechner setzten.
Die Wahrheit ist aber die eine Bereinigung in nachvollziehbare Schritte zu zerlegen, den User diese abarbeiten zu lassen und nach dem Stand der Technik, am Ende die meisten Systeme dann auch sauber zu haben.

Nach erfolgter Bereinigung werden, das solltest Du auch gesehen haben, immer die Tools, wenn nötig, entfernt und Verhaltenshinweise gegeben.

Hallo Alexander,

ich hab das Gefühl, daß du dich persönlich oder die Community angegriffen gesehen hast. Aber das ist nicht richtig.

Die Arbeit die hier geleistet wird ist höchst professionell. Ich freue mich, daß es rund um das Thema Schädlings-Entfernung eine so große und aktive Community gibt! Und ich gebe dir recht, jemand der unter Linux sein System analysieren kann wird hier selten selbst als Fragensteller auftreten.

Aber das war auch gar nicht der Punkt. Wie im Thread-Titel schon geschrieben geht es mir um Grundsätzliches zu diesem Thema.

Nochmal kurz zusammengefasst:
Es gibt prinzipiell 2 Herangehensweisen. Die Untersuchung des Systems von außerhalb und die von innerhalb bzw. am laufenden Objekt.

Die Analyse-Ergebnisse aus einem laufenden, kompromittierten System heraus beinhalten meines Wissens immer das Risiko verfälscht zu sein. Stealth Techniken und Kernel Hooks gehören zum gängigen Repartoire.

Wenn ein System erst einmal komprimittiert ist, bin ich persönlich / von meinem Gefühl her nie mehr ganz sicher ob ich den Anzeigen / Antworten aus dem System noch trauen kann. Ich stelle mal ganz provokant die Frage: Wieso mache ich eine Untersuchung, um etwas zu beweisen oder auszuschließen, wenn ich mir im Falle des Ausschlußes aber nicht 100% sicher sein kann? (In diesem Fall habe ich eben nicht wirklich ausgeschlossen)

Und gerade weil hier die große Expertise zu diesem Thema versammelt ist, stelle ich die Frage wie ihr damit umgeht. Ist dieses Risiko viel geringer als ich es gerade einschätze? Ist es ein Restrisiko das bewußt eingegangen wird weil es nunmal keine bessere Lösung gibt?

Ich stelle mir diese Fragen seit Jahren und habe gehofft hier Leute zu finden um ein paar Gedanken auszutauschen und darüber zu diskutieren.

Viele Grüße,
Andreas

Ich fühle mich nicht angegriffen, die anderen sicher auch nicht.
Die Fragen, die Du stellst, habe ich mir auch schon alle gestellt. Ich sehe nicht zwei Herangehensweisen, sondern jedes mal eine individuelle. Auch Live CDs kommen hier zum Einsatz.
Tools wie gmer die Hooks finden sollen, werden schon seit Jahren von Schadsoftware erkannt, daher wird die Datei bei jeden download auch umbenannt, Sigchecks werden von vielen Tools durchgeführt. Prüfsummen können manipuliert werden, der MBR ist auch keine sicherer Hafen mehr für Malware. Der ADS ist auch nicht so geheim, wie es den Anschein macht.
Neuster aufgedeckter Angriffsvektor sind die Biose der unterschiedlichen Systeme. Hier scannt noch nichts, auch Bad USB spielt in dem Bereich.
Hier muss man immer die Verhältnismäßigkeit mit abwägen, ich für mich bin auch eher der Formatinator. Aber das ist nicht immer die Beste Lösung im Benutzerkontext. Und was taucht hier am Ende auf? Alles was in the wild ist und etwas mehr.
Aber: Aufgrund der Unwägbarkeiten insgesamt, stehe ich der Fernbereinigung skeptischer den je gegenüber.

Wir setzen auch Scans von Aussen an. Aber dann immer noch mit Tools unserer Wahl. Ich persönlich halte von Notfall Cds gar nichts, also wirklich überhaupt gar nichts.

Klar werden dann von aussen Malware-Files gefunden, es wird ja die Platte gescannt.

Aber wieviele der schönen CDs laden denn die Windows Registry, um diese zu scannen`?

File von aussen gelöscht, leerer/defekter Reg Eintrag oder Dienst bleibt zurück.

CD raus, Windows normal booten.

Hey, Malware ist weg, ok, Windows auch, bootet jetzt gar nicht mehr, but nobody is perfect ;)

Aber wenn Du vor dem Rechner sitzen würdest, könntest Du Dir den Einsatz auch vorstellen, oder?

Ich finde die Arbeit hier auch gut. Die mit den hier aufgeführten Tools gereinigten Windows-Systeme sind danach wahrscheinlich weit sauberer als der Durschnitts-Rechner. Ich würde aber nach einem Schadcodebefall doch lieber neu installieren. Weder ein Scannen im laufenden System noch von einer Live-CD halte ich für ausreichend um wirklich sicher zu sein.

:daumenhoc

Das ist auch der beste Weg um ein vertrauenswürdiges Windows zurückzubekommen. Noch besser man spielt ein Image zurück das man sich vor dem Befall angelegt hat, dann dauert es ca. 20 Minuten und es geht weiter.

nein, weil die nix können. USB Stick, FRST aus der RE, dauert 2 Minuten und alle Probleme sind aus der Welt. Und es wird nur das gemacht was ich machen will.

und Kronos sollte sich am Besten gleich raus halten, die letzte Nummer war doch peinlich genug oder? ;)

Die Bereiniger:
http://d1.stern.de/bilder/stern_5/di...twidth_489.jpg
:D
Möchte aber nicht schon wieder eine Grundsatzdiskussion starten, da gibt es eh schon einen Thread dafür....

Für wen denn....

Also das die nix können, würde ich jetzt nicht sagen, CDs haben z.B. den Vorteil, das ein Fileinfector da nur sehr schwer drauf kommt.
Insgesamt ist die Entscheidung, wie vorgegangen wird, aber doch immer eine individuelle, auch wenn es sehr gleichartig aussehen mag.
Und wer will, kann ja auch formatigern.

Für dich, mal wieder.

ich zitiere mich mal :)

Warum also so ne tolle Möchtegern-CD nutzen, wenn ich das dann nicht mehr bootende System doch mit FRST bearbeiten muss? Dann nehm ich lieber gleich das Bessere ;)

Hallo zusammen,

zunächst mal freu ich mich, daß jetzt doch eine Diskussion entstanden ist! :-)

Daß Live-CDs "nix können" find ich ein bißchen hart. Wenn ich erreiche, daß ich den Schadcode von meinem System bekomme, dann ist das für mich streng genommen schon das Ziel. Und das schafft eine Live-CD, die 4 große Virenscanner nacheinander drüber laufen läßt recht zuverlässig.

Ich geb dir aber recht, verwaiste Registry / Start-Einträge bleiben dann normal über. So lange das Windows trotzdem startet stören mich diese Einträge aber auch nicht. Praktisch jede Software die ich mal kurz gestartet oder gar installiert habe tut das auch.

Daß Windows dann nicht mehr startet, weil z.B. der Einsprungspunkt auf den Windows Explorer geändert wurde, hatte ich auch schon mal erlebt. Allerdings erst einmal. Und ja, dann muß man doch wieder manuell und remote an der registry fummeln.

Ihr habt vollkommen recht damit, daß das auf jeden Fall eine sehr individuelle Entscheidung ist. Bei meinen eigenen Rechnern würde ich sofort formatieren (mußte ich zum Glück schon viele Jahre nicht mehr :) ) bei Rechnern von Bekannten stecke ich da aber in der Zwickmühle. Das Backup der Daten, Formatieren, neu installieren, einrichten der Treiber und Software etc. muß da nämlich auch ich machen. Dafür fehlt mir meist schlicht die Zeit.

Und so komme ich dann immer auf die genannten Fragen. Wir leben in einer Zeit, in der es Schädlinge gibt, die eine laufende Windows-Instanz in eine virtuelle Maschine verfrachten können ohne daß es der Anwender bemerkt (Stichwort blue pill). Wie sicher kann ich mir da noch bei der Vollständigkeit und Authentizität von Log-Files sein?

Mir ist jetzt die Idee gekommen es vielleicht einfach mal selbst zu versuchen ein Programm als system service zu schreiben, das einen hook implementiert. Es sollte versuchen Anfragen nach der Prozess-Liste vor Weitergabe an die anfragenden Prozesse um den eigenen Eintrag zu filtern. Mal schaun ob ich in der nächsten Zeit mal ein wenig Freiraum dafür finde, wäre ein interessantes Projekt :)

Viele Grüße,
Andreas

und je nach Befall ist genau dass das Problem ;). Nach der Live CD bootet gar nix mehr!

Also warum dann ne CD nutzen, die ewig rum scannt, wenn ich mit unsern Tools in der RE in 3 Minuten fertig bin? :)

@ Schrauber, du hast aber schon meinen ganzen Beitrag gelesen oder? ;-)

Wie gesagt, daß Windows nicht mehr startet hatte ich erst einmal von unzähligen Fällen.

Weil du dir ggf. nicht sicher sein kannst ob das System dir die Wahrheit sagt.

in der RE? Ohne geladenes Windows, also ohne jegliche geladenen Rootkits, falls vorhanden? Die Wette halte ich :)

Was heißt RE? Wieso ohne geladenes Windows? Wir reden ja eben davon ein laufendes Windows zu untersuchen.

Wie gesagt, ich werd demnächst mal ein proof-of-concept versuchen mit einem kernel hook, bei dem ihr ein Programm im Autostart habt aber keinen Eintrag in der Prozessliste oder den startup-locations.

nein, wir reden die ganze Zeit von Notfalls CDs. Und ich schlage jede Notfall CD in Zeitverbrauch und Qualität des Bereinigens mit FRST in der RE.

Da dürfen wir gerne auch anderer Meinung sein, das tut uns beiden keinen Abbruch. Ich finde beide Wege legitim und im Ergebnis gleichwertig.

bezog sich auf

:)

Ich für meinen Teil bin mit FRST in der RE schneller als jede Notfall CD von aussen, und gründlicher.

Guten Tag,
tut mir leid dass ich mich da mal so rein hänge, aber genau das was du da sagst ist das Problem.
Du kannst damit schnell Arbeiten aber wieviel von dir gibt es? ;)
Ich komme zwar auch vom "Fach" aber nicht aus der Schadwehrbekämpfung.
Da Ihr hier im Forum eine Anleitung habt wollte ich mir das von dir so angepriesene Produkt mal anschauen, da ich momentan mit dem Thema bei uns zu tun habe. Nach der Hälfte des Textes habe ich Kopfweh bekommen weil ich nichts verstanden habe worauf man den jetzt genau achten muss (Indikatoren)(Vllt stand auch die Lösung im restlichen Text :D). Da ich immer gern selbst weiß was passiert kümmere ich mich um sowas selbst gern aber muss ich ein Trojaner Board Admin sein um schnell und effizient meine Viren zu löschen? Ist es dann doch nicht effektiver eine „Notfall CD“ zu haben die einem die Arbeit abnimmt?
Danke für euer Ohr :)

wenn die cd das auch machen würde wäre ich ganz bei dir. Solange die Registry von Win aber aussen vor bleibt ist dem nicht so :).

So ne CD ist wie wenn einer mit gefährlichem Halbwissen manuell am System rum fixt.

Die Ausbildung hier dauert mehrere Monate. Schrauber meinte mit Sicherheit nicht, dass es für den Normalnutzer so schneller geht.

PS: Wann sind denn mal wieder Plätze frei? :-)

Man muss natürlich schon wissen was zu tun ist und was man selber tut. Sonst haut das nicht hin. Eine Live-CD ist für Laien einfacher birgt aber die schon von schrauber angesprochenen Gefahren. Und ist definitiv langsamer und tendenziell unsicherer/"ungründlicher" als ein erfahrener Helfer der mit FRSTRE rangeht

FRST wird aber in der Registry auch nur Abweichungen ermitteln, die bereits bekannt sind. Und inwieweit eine Malware vielleicht sogar den Zugriff zur Registry manipulieren kann weiß ich nicht. Irgendeine Schnittstelle wird wohl genutzt werden müssen. Den Einträgen der Registry darf man eigentlich auch nur trauen, wenn man sie von einem Live-System auslesen kann. Da schließt sich dann wieder der Kreis.

Mit FRSTRE machst ja auch primär einen no booter wieder startklar.
Der Rest folgt dann mit gängigen anti-rootkit-tools im wieder laufenden System wenn es denn unbedingt sein muss.

Was soll denn manipuliert werden wenn ich in der RE bin? Ich lade die Hives, 100% Ist-Zustand, mit allen Manipulationen, aber ohne Verschleierungen. Und wenn FRST etwas standardmäßig nicht zeigt kann ich mir immer noch den Rest des Systems nach Belieben anzeigen lassen.

Iceweasel, Schrauber (und jetzt auch Cosinus) reden schon seit einiger Zeit von einem Zugang aus dem Recovery Environment (Reparaturoptionen oder von Win-CD gestartet), nicht vom normalen FRST-Scan im laufenden System. Benutzen tun sie aber zugegebenermaßen immer, wenn sie können, letzteres (meiner Beobachtung nach)...

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.

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 :)

Ö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 :crazy:

@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. :blabla:

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...

Klar, wir user aktivieren den ja freiwillig ;).

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

Hat nicht schon mal ein Leser Microwaves Rootkit aktiviert und sich dann beschwert? Da war es also funktionsfähig insoweit, als er es erfolgreich auf den Rechner des Lesers gebracht hat.

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

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

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 :)

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 :D

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

Also , ähm aber was macht der Durchschnitts - Pfosten , wenn er grad nur ein Rechner hat und dann mitten in der Neuinstallation stecken bleibt und das System nicht mehr Internet fähig ist ?

Dann bliebe solchen Leuts wohl nur noch der Gang in nem PC Shop , wo sie ein vermutlich feierlich erklären , das sie es zum Sonderpreis von 35 ,- untersuchen und dir dann sagen , das die Festplatte kaputt ist , obwohl sie gar nicht kaputt ist (und der Typ aufgrund des Einfachheit des Fehlers zum weiter führen der Neuinstallation erahnt , das der Kunde ein Pfosten ist) und noch mal 250 daafür verlangt und natürlich den Gratis- Service das deine Daten weg sind und die Einstellungen .

Die meisten kenn ich auch nur über Inet , da extrem schüchtern , wüßte gar nicht , wen ich überhaupt mein Rechner tagelang überlassen könnte , sollte , der ja noch Ahnung haben muß davon .

Also , da geh ich lieber hier hin und lass es checken , ist schon mal viel , viel besser als gar nichts checken zu lassen oder damit leben zu müssen , das eine Suchmaschine deine Suche verändert und dich zu Tode spamt und weiß der Geier noch für Helferchen runter lädt und einfach gaar nix zu machen ist bis zum PUP , punktuell unausweichlicher Platten-tot und nicht mehr rückbildungsfähig .

Und den PC Läden trau ich nie so recht , da haben wir leider auch schon Sachen hingegeben haben , die angeblich kaputt waren , und als mein Vater es auseinander schraubte (was ich nicht für Anfänger empfehle , man muß schon Kenntnis haben , grad Röhrenbildschirme und Geräte mit Lasern , war ne Play Station die unreparierbar war angeblich) und alles prüfte und sich alles mögliche an Infos holte , stellte er fest , das ein kleines Bauteil durch gebrannt war .
Kostenpunkt des Bauteils über nen Bekannten , der Elektriker ist , belief sich auf 3 Cent !!!

Ganze 3 Cent , das muß man sich mal rein ziehen . Klaar , er hat für seine 1. Playstation 5 Wochen gebraucht (war ja kein Rentner) , aber danach machte er weiter , vorher nur Staubsauger , Toaster , Bohrmaschinen und so , jetZt aber kann der in weniger als 2 Stunden Gerät auseinander bauen , war nen Reciver mit ner Sollbruchstelle , bestimmte Komponenten auslöten (manche durch messen und manche die verändert aussehen oder typisch kaputt gehen) und lötet entsprechendes wieder rein .

Erst kürzlich mit dem Miele Waschmaschinen Fachmann per Telefon den Fehler auf der Schaltplatine entfernt in nur 1 einhalb Stunden . Hätte niemals geglaubt , das die so kulant sind und ein sagen , wo welcher Messwert (Geräte zum Stromspannung messen hat er ja reichlich) sein muß , um den Übeltäter zu finden .

Da lustige war , das er das Bauteil einem alten Röhrenmonitor entnommen hat . ^^
Er darf seine Bastelei aber nicht gewerblich nutzen und Garantie ist dann ntürlich auch pfutsch , aber Maschine heile zum Preis eines Telefonats .^^


Und bevor ich 5 Wochen an nem Rechner Problem tüftel , das mir min. 47 Level zu hoch ist , dann bin ich lieber hier , dann dauerts keine 5 Tage (je nach dem wie lange es dauert , bis mir ein Licht aufgeht) und weg ist es . :lach: