HDD sauber - aber eine Datei lässt sich ums Verrecken nicht löschen
 

Hallo, ich habe die letzten 3 Nächte damit verbracht, eine ausgebaute Notebookplatte (Windows XP prof. 32bit NTFS) nach Virenbefall zu säubern. Habe die Platte in ein externes (SATA-) Gehäuse gesteckt und via USB an meinen "Werkstatt-PC" gehängt.

Auf der Platte waren eine ganze Reihe von Trojanern, Rootkits u.ä. drauf (BOO/TDss.D, W32/PatchLoad.A, TR/Crypt.XPACK.Gen, TR/ATRAPS.Gen2, TR/Spy.53472.4, TR/FakeSysdef.A.2966, RKIT/ZeroAccess.H). :pfeiff:

Von da aus habe ich wie hier beschrieben, mittels diverser Such- und Säuberungsprogramme (aswMBR, MBRCheck, Combofix, Dr.Web, FixTDSS, TDSSKiller, Norton PE, Avira Antivir PE) die Übeltäter verbannen können.

Ergebnis: Alles chic - bis auf eine Datei auf der extern angeschlossenen Platte: c:\windows\$NTUninstallKB16527$ :nono:

Die hatte sich also als Windows-Update "verkleidet", ließ sich aber im Gegensatz zu ihren echten "Verwandten" nicht löschen. Weder aus der Wiederherstellungskonsole der Windows XP CD, noch im abgesicherten Modus noch von einer Linux Boot-CD (dabei steckte die Platte wieder im Notebook). Zumindest konnte ich die Datei unter Linux umbenennen und verschieben nach c:\xyz.

Aber auch danach waren alle Löschversuche erfolglos. Nicht einmal mit einem so coolen Linux Befehl von der Seite hxxp://wiki.magenbrot.net/linux/dateien_loeschen_anhand_der_inode-nummer_-_datei_laesst_sich_nicht_loeschen :
[root@bash]# find . -inum 2479591 -exec rm -f {} \; :balla:

Entweder war Linux der Meinung "directory not empty" oder mit [root@bash]# find . -inum 2479591 -exec rmdir -f {} \; "is no directory" zumindest sinngemäß - wörtlich weiß ichs nicht mehr 100%ig.

Interessant war aber der Zusatz hinter der Datei in der Auflistung mittels "ls -ali" da stand schön in rot "unexpected reparse point" wobei ich mir bei "unexpected" nicht ganz sicher bin, sinngemäß trifft es aber zu.

Das ist also so eine Art Hardlink, der egal wo er steht und wie er heißt immer auf die richtige Datei zeigt. So hab ich es zumindest verstanden. Blöd nur, wenn es sich um einen Virus dabei handelt. Die Datei selbst bzw. der Hardlink wurde von keinem Scanner bemängelt.

Ich hatte nach der Umbenennung mal versucht wieder richtig von der Platte zu booten. Aber gleich kamen wieder Virenmeldungen hoch. Also alles noch mal von vorn, bis zum Stand: Platte sauber bis auf eine Datei c:\xyz und die lässt sich nicht löschen. :killpc:

Daher nun meine Fragen:
A: Gibt es irgendeine Möglichkeit, diese Datei doch noch los zu werden? :Boogie:
B: Oder muss ich die Platte platt machen und alles neu installieren? :daumenrunter:

Danke schon mal im Voraus für eine positive Antwort zu Variante A! :applaus:

PS: Ich bin davon ausgegangen, dass keine Logfiles benötigt werden. Falls doch, muss ich die erst anfertigen. Dazu gleich 2 Fragen: Platte wieder extern anschließen und Scanner vom Werkstatt-PC aus laufen lassen? Oder Platte in Notebook zurück und damit wieder der Geister von der Leine lassen und dann erst scannen?

Hallo, ich hab nun doch noch eine Scan mit OTL gemacht, bei dem befallenen Platte aber nur extern via USB angeschlossen war. War aber sinnfrei, da scheinbar nur die lokale Platte C:\ gescannt wurde und demzufolge auch keine Fehlermeldung auftauchte.

Daher nochmal meine Fragen:

Muss doch die Platte ins Notebook zurück und damit der Virus wieder aktiviert werden, um dann mit OTL zu scannen?

Oder gibt es irgendeine Lösung zum Löschen der widerspenstigen Datei?

Danke und Grüße,
Troja007

Bei dem Teil ist eine Bereinigung echt nicht mehr gutzuheißen. :balla:

Von einem Live-Linux aus braucht man nicht solche Befehle anwenden, erst recht sollte man keine verwenden, die auf einem Windows-Dateisystem sinnfrei sind.
Mit einem einfachen

wärs auch erledigt. http://www.trojaner-board.de/images/icons/icon32.gif

Was das für ein Ordner ist, ist dir sicherlich auch völlig klar? Was könnte "NTUninstall" wohl bedeuten?


Ich wär erstmal dafür, du postest ALLE vorhandenen Logs.

Hallo cosinus,

erst einmal Danke dafür, dass du dich des Problem annimmst!

Zum Löschen unter Linux:
Die einfachen Löschbefehle bzw. Löschen über Linux Dateimanager hatte ich vorher natürlich schon durchprobiert - ohne Erfolg. Dann erst bin ich auf die mögliche Problemlösung mittels der inode-Nr. gestoßen

Zu c:\windows\$NTUninstallKB16527$:
Dass sich die Uninstall-Ordner von Windows Updates so benennen ist mir klar. Die lassen sich ja auch einfach löschen. Nur der Virus (oder Rootkit oder was es denn nun ist) hat sich hinter einem solchen Namen nur versteckt. Denn diese Datei (bzw. eigentlich ist es ja ein Verzeichnis) lässt sich eben nicht öffnen oder löschen.

Die Datei ließ sich unter Linux zumindest umbenennen und verschieben (wie oben beschrieben). Und sie ließ sich auch mittels Dateimanager "löschen" - also in den "Papierkorb" verschieben. Interessanter Weise hat die dann im Papierkorb Unterverzeichnisse mit Dateien. Wie das genau aussieht muss ich noch nachliefern. Komm da jetzt nicht ran.

Vorhandene Logs:
Komm ich jetzt auch nicht ran. Aber die bezogen sich nur auf LW C:\ meines Werkstatt-PCs, der ja nicht befallen ist. Über die via USB angeschlossene Platte schwiegen die sich entweder ganz aus oder es gab keine Funde. Die "Problemdatei" wurde nie angemeckert.

Neue Los kommen:
Da ich inzwischen ein Image des aktuellen Zustand der Platte mit Acronis gemacht habe. Werde ich nun die Platte wieder ins Notebook einbauen, von ihr booten und dann alle Logs posten.

Bis denne!

Hier erst mal die Korrektur einiger aus dem Gedächtnis zitierter Begriffe und Meldungen:

Die nicht löschbare Datei wir unter Linux mit dem Hinweis versehen:
unsupported reparse point

Konkret sieht das so aus:

root@lesslinux:/media/sda1
# ls -ali
...
65326 lrwxrwxrwx 1 surfer surfer 26 Jan 30 2007 xyz -> unsupported reparse point

Der Löschbefehl mit Bezug zur inum bringt diese Meldung::
# find . -inum 65326 -exec rm -f {} \;
rm: can't remove './xyz': Directory not empty


Der Löschbefehl für nicht leere Verzeichnisse mit Bezug zur inum führt auch zu nix:
# find . -inum 65326 -exec rm -f -ignore-fail-on-non-empty {} \;
invalid option oder unrecognized option


Das mehr so zur Info. Ich werd jetzt doch wieder Windows XP von der Platte booten und dann nach Anleitung die Logs posten.

Bis denne.

Hier nun das GMER Log:

GMER Logfile:
--- --- ---


Und die Logs von OTL im Anhang.

Grüße, Troja007

Kurzer Nachtrag:

Zur Zeit verhält sich der Virus ruhig. Nachdem ich noch mal unter Linux die widerspenstige Datei verschoben, umbenannt und wieder zurück nach c:\xyz verschoben habe, tut sich virusmäßig nix auf dem Notebook. :confused:

Bisher war immer nach dem Windows-Neustart mit Dr.Web CureIt! Virenbefall an folgenden Orten zu verzeichnen

c:\windows\system32\drivers
c:\system volume information
c:\windows\assembly

Aber zur Zeit ist da nix. Er findet auf der ganzen Platte nix. Hab aber auch die Internetverbing unter Windows gekappt. Auch im Taskmanager finde ich keine verdächtigen Prozesse. Hm? :confused:

Trotzdem will ich natürlich immer noch c:\xyz loswerden. :aufsmaul:

'xyz' ist das umbenannte '$NTUninstallKB16527$'?
Das kleine L bei Berechtigungsinfos weist auf einen symbolischen Link hin. Mit was das da aber verknüpft ist sieht man nicht. (unsupported reparse point)

Zum Löschen von nicht leeren Verzeichnissen wendet man rm -rf an. Ich versteh immer noch nicht, was du da mit der inode-Nummer rumfummeln musstest...aber gut, es sollte sich ja erst durchs Umbenennen löschen lassen - kann ich so nicht nachvollziehen :confused:

Du hast ja ne ganze Palette an Tools ausgeführt, das kann ja wohl schlecht alles an Logs sein. Poste alle Logs wenn du dir weiterhin Hilfe benötigst.

Das hab ich ganz am Anfang geschrieben, dass ich schon alles versucht hatte, das Ding zu löschen, unter Windows und von 'ner Linux-CD aus. Natürlich erst mal alle 08/15-Befehle und weil's alles nichts brachte, hab ich halt im Web gesucht, was noch so geht. Daher der Versuch mittels inode-Nr. gefunden. Ich hatte und hab’s auf deine Empfehlung auch noch mal mit rm -rf probiert, ohne Erfolg.

Na ja, es gibt doch infizierte Dateien, die sich auch nicht unter Windows löschen oder umbenennen lassen. Wenn man die aber umbenennt (z.B. wenn die Platte extern an einem anderen PC hängt und also nicht von ihr gebootet wurde) kann man sie nach dem nächsten Systemstart löschen. Hab ich sonst bei ähnlichen Problemen immer erfolgreich anwenden können. Aber die Nuss hier ist härter ... :wtf:

Nun ja, die Logs hab ich nicht mehr alle. Aber vor allem haben die letzten Scans gar nix mehr gefunden. In meinem Verständnis konnte mit den vorangegangenen Säuberungsaktionen die aktuell infizierten Dateien repariert bzw. gelöscht werden. Ich befürchte aber nach wie vor, dass die Quelle allen Unheils hier hinter c:\xyz lauert. Daher will ich die loswerden.

Ist denn aus den bisher glieferten Logs nix erkennnbar?

Das hat aber einen anderen Grund. Unter Windows kann man in Gebrauch befindliche Dateien bekanntlich nicht löschen und wenn noch Schädlinge aktiv sind, so lassen sich diese Dateien vom Schädling auch nicht löschen.
Wenn du von einem Live-Linux aus startest ist die Windows-Partition für Linux aber nichts weiter als eine nackte "Datenplatte" und hat so nichts mit dem Betriebssystem zu tun. Daher sollte auch eigentlich ein Löschen ohne Probleme möglich sein. Aber ok, der besagte Ordner war ein Symlink mit unter Linux nicht unterstütztem "Ziel", vllt lag es daran.

Poste bitte alle noch vorhandenen Logs.

zumindest kommen mir diese Zeilen aus dem GMER-Log recht "interessant" vor:
GMER ist auch das einzige Tool, was mal das Verzeichnis C:\xyz\ angemeckert hat.

Ich hab noch drei alte Logs gefunden und erstelle grad noch mal neue mit jedem Tool. Kann aber noch bissl dauern ...

Hier nun die Logs von TDSSKIller, aswMBR, Defogger und MBRCheck.
GMER und Dr.Web CureIT! kommen später.

Bitte nun routinemäßig einen Vollscan mit malwarebytes machen und Log posten.
Denk daran, dass Malwarebytes vor jedem Scan manuell aktualisiert werden muss!

Falls Logs aus älteren Scans mit Malwarebytes vorhanden sind, bitte auch davon alle posten!



ESET Online Scanner

• Hier findest du eine bebilderte Anleitung zu ESET Online Scanner
• Lade und starte Eset Online Scanner
• Setze einen Haken bei Ja, ich bin mit den Nutzungsbedingungen einverstanden und klicke auf Starten.
• Aktiviere die "Erkennung von eventuell unerwünschten Anwendungen" und wähle folgende Einstellungen.
• Klicke auf Starten.
• Die Signaturen werden heruntergeladen, der Scan beginnt automatisch.
• Klicke am Ende des Suchlaufs auf Fertig stellen.
• Schließe das Fenster von ESET.
• Explorer öffnen.
• C:\Programme\Eset\EsetOnlineScanner\log.txt (bei 64 Bit auch C:\Programme (x86)\Eset\EsetOnlineScanner\log.txt) suchen und mit Deinem Editor öffnen (bebildert).
• Logfile hier posten.
• Deinstallation: Systemsteuerung => Software / Programme deinstallieren => Eset Online Scanner V3 entfernen.
• Manuell folgenden Ordner löschen und Papierkorb leeren => C:\Programme\Eset

Auf dem Rechner läuft noch Dr.Web. Dauert also noch etwas. :kaffee:

Was ist denn aus den bisher glieferten Logs ersichtlich?

Hab außerdem weiter nach remove reparse points und remove junction points gegooglt. U.a. hab ich das gefunden: hxxp://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil.mspx?mfr=true

Ich würde mal fsutil reparsepoint delete C:\xyz probieren. Was meinst du?

Nein lass das erstmal. Ich will erst die Ergebnisse von MBAM/ESET sehen

Okay, Dr. Web ist durch und hat nix gefunden. MBAM läuft grad. ESET kommt danach dran.

Hier schon mal das Logfile von MBAM.

Dazu ein Screenshot der Registry bei dem oben rot markierten Eintrag
http://www.trojaner-board.de/attachm...1&d=1318272527

Hm, sieht schon komisch aus...


Außerdem hab mich mal fsutil reparsepoint query c:\xyz ausprobiert.
Ergebis Fehler: Zugriff verweigert


ESET läuft noch mindestens 'ne Stunde (hat erst 26% nach 34 min).
Hat leider schon 3 Threads gefunden, jeweils Java/Agent.DS trojan
:headbang:

Na toll, ESET hat auch was gefunden, allerdings wieder was ganz anderes, als MBAM:

Hab spaßeshalber noch ein neues Avira Free Antvirus installiert und damit noch mal die ganze Platte gescannt. Ergebnis wie bei ESET. Avira hat auch die drei zip-Dateien in C:\Dokumente und Einstellungen\***\Anwendungsdaten\Sun\Java\Deployment\cache\javapi\v1.0\jar\ angemeckert und sie in die Quarantäne verschoben.

Gute Nacht erst mal! :sleepy:

Mach einen OTL-Fix, beende alle evtl. geöffneten Programme, auch Virenscanner deaktivieren (!), starte OTL und kopiere folgenden Text in die "Custom Scan/Fixes" Box (unten in OTL): (das ":OTL" muss mitkopiert werden!!!)

Hinweis: Falls Du Deinen Benutzernamen unkenntlich gemacht hast, musst Du das Ausgesternte in Deinen richtigen Benutzernamen wieder verwandeln, sonst funktioniert das Script nicht!!

Klick dann oben links auf den Button Fix!
Das Logfile müsste geöffnet werden, wenn Du nach dem Fixen auf ok klickst, poste das bitte. Evtl. wird der Rechner neu gestartet.

Die mit diesem Script gefixten Einträge, Dateien und Ordner werden zur Sicherheit nicht vollständig gelöscht, es wird eine Sicherheitskopie auf der Systempartition im Ordner "_OTL" erstellt.

Hinweis: Das obige Script ist nur für diesen einen User in dieser Situtation erstellt worden. Es ist auf keinen anderen Rechner portierbar und darf nicht anderweitig verwandt werden, da es das System nachhaltig schädigen kann!

Da isses:
Im Übrigen gabs kurz nach dem Start (Klick auf Fix) eine Fehlermeldung. Genauen Text hab ich leider nicht mehr, weil da stand, dass wegen des Fehlers abgebrochen wird, was dann aber nicht geschah. Es ging jedenfalls um eine fehlende Datei namens msvcp71.dll, die sich auf meinem funktionierenden PC in diesem Verzeichnis befindet:
C:\Dokumente und Einstellungen\***\Anwendungsdaten\Sun\Java\Deployment\SystemCache\6.0\46\f84c6ae-560666a7-n\

Hab grad noch mal auf dem infizierten Rechner gesucht. Dort taucht diese Datei 2x auf in:
c:\programme\microsoft\autoroute
c:\programme\HP\digital imaging\bin

Bevor du das machst, würde mich mal die Ausgabe von fsutil reparsepoint query C:\xyz interessieren

Ich bin übrigens ein Depp. Hatte ich doch in der Zwischenzeit c:\xyz in c:\aaa umbenannt, damit es am Anfang der Liste erscheint ... :headbang:
Daher konnte OTL es nicht natürlich finden. SORRY! :stirn:

Kannst du mir bitte einen neuen Text für die "Custom Scan/Fixes" Box schicken, nur um die c:\aaa zu löschen?

Könnte der vielleicht so aussehen?
:OTL
O32 - AutoRun File - [2007.01.30 21:38:34 | 000,000,000 | -HSD | M] -- C:\aaa
:Files
C:\aaa
:Commands
[emptytemp]
[resethosts]

Die "ICQ Search" befand sich übrigens immer noch im IE und im Firefox. Hab die mal rausgenommen.

Grüße, Troja007

Achso nee dann geht das nicht :D
Ja einfach nur in meinem Script das xyz passend umbennen

Den Befehl fsutil reparsepoint query / delete hatte ich gestern auch noch gefunden. Ergebnis jeweils: Fehler: Zugriff verweigert

Genausowenig funzt delrp.exe aus dem Windows Ressource Kit: The delete call failed.

Das scheint mir eine richtig fiese Sache zu sein mit diesem reparse point. Das Ding wird manchmal aus als junction point bezeichnet. Es gibt dafür spezielle Tools zum Erstellen und Löschen, die aber alle auf "normale" reparse points ausgerichtet sind. Wie man an dieses Exemplar hier rankommt, ist mir ein Rätsel.

Was ist denn mit der Hosts-Datei passiert? Die alte wurde ja ersetzt (da war aber nix drin außer 127.0.0.1 localhost)

Die neue lässt gerade keinen Internetzugriff zu:

127.0.0.1 localhost
::1 Localhost

Hat das einen Grund?

Noch besser: Ich kann die nicht mehr editieren - also speichern oder löschen ???

Erledigt: Avira war Schuld!

Der Internetzugriff durch die Hostsdatei wird nur eingeschränkt wenn dort deutlich andere Sachen drinstehen. AFAIK muss nichtmal mehr das 127.0.0.1 localhost eingetragen sein, weil der loopback/localhost direkt schon im Stack integriert ist.

hast du schonmal mit der junction.exe dein Glück probiert?

Nee, die hatte ich gestern auch gefunden. Probier ich jetzt auch noch aus.

Aber ehrlich gesagt glaube ich mittlerweile nicht mehr daran, dass man mit solchen Tools was erreichen kann (in diesem Fall). Vermutlich müsste man mit irgendwelchen Low-level HDD-Tools ran. Aber davon hab ich keinen Schimmer.

EDIT: Wie erwartet: Error deleting c:\aaa: Zugriff verweigert

Dann muss man entweder sich damit abfinden, dass dieser Rechner nicht mehr zu retten ist und man formatieren muss :pfeiff:
oder du versuchst junction bzw. fsutil über eine Live-CD wie BartPE oder OTLPE auszuführen

Diese Live-CD unbedingt auf einem anderen, garantiert sauberen Rechner bitte erstellen!

Das werd ich mal noch probieren, auch wenn ich keine großen Hoffnungen mehr hab.

Kannst du mir noch sagen, was es mit dem Teil au dem GMER-Log auf sich hat:

C:\WINDOWS\system32\drivers\tifm21.sys entry point in "init" section [0xEC0D28BF]
C:\WINDOWS\system32\drivers\hardlock.sys section is writeable [0xAA0E7400, 0x82482, 0xE8000020]
C:\WINDOWS\system32\drivers\hardlock.sys entry point in ".protectÿÿÿÿhardlockentry point in ".protectÿÿÿÿhardlockentry point in ".p" section [0xAA187420]
C:\WINDOWS\system32\drivers\hardlock.sys unknown last code section [0xAA187200, 0x5105, 0xE0000020]

Das protectÿÿÿÿhardlockentry point kommt mir doch sehr spanisch vor - und ich kann gar kein Spanisch ...

Einträge zu 2 Systemdateien. Die halte ich für legitim.

Also das mit der BartPE-CD hab ich nicht hinbekommen. Muss da irgendwie SATA-Treiber einbinden, was entweder sehr kryptisch oder gar nicht im Web beschrieben ist. Habs zumindest nicht gefunden. :wtf:

Aber ist das nicht unterm Strich dasselbe, als wenn ich die Platte wieder ausbaue und in 'nem exteren Gehäuse via USB an meinen Werkstatt -PC anschließe? Das hat ja schon mal nicht gefunzt. :eek:

Hab grad die ominöse Datei/Verzeichnis unter Linux in ::: umbenannt. Damit kann doch Windoof nix anfangen. Fragt sich nur, ob die sich dahinter verbergenden Geister trotzdem rauskommen können? :aufsmaul:

Hab ständig den Taskmanager im Blick und kann keine verdächtigen Aktivitäten feststellen. Auch auf dem Netz ist in Richtung Internet erst mal nix los. Hm, ist das Ding nun eingemauert? :glaskugel:

Hab seit der Umbenennung gestern Abend noch mal alles durchlaufen lassen (GMER, Dr.Web, Malwarebytes, Avira, awsMBR, MBRCheck und OTL). Alles ohne Befund.

Nur das ominöse Verzeichnis wurde von GMER aufgelistet:

Nun meine Fragen:

- Welcher Virus/Trojaner oder was auch immer könnte das sein?
- Kann es sein, dass der jetzt ruhig gestellt ist aufgrund des Verzeichnisnamens?

Grüße, Troja007

Hab mal bisschen rumgegooglt, und zwar nach dem Dateinamen einer in dem Verzeichnis enthaltenen click.tlb:

hxxp://forums.majorgeeks.com/showthread.php?p=1672737
hxxp://forums.majorgeeks.com/showthread.php?t=244613
hxxp://www.bleepingcomputer.com/forums/topic421957.html

Es scheint sich um das (einmal auch gefundene) Rootkit Zero Access zu handeln. In den o.g. Fällen hatten alle eine ähnliche Verzeichnisstruktur wie bei mir. Teilweise auch mit C:\Windows\$NtUninstallKB?????$ und entsprechenden Unterordner mit vielen Ziffern und dann exakt die gleichen Dateien drin. Nur eine davon hieß immer anders, die sich bei mir wjxaiaeh nennt.

Allerdings konnte die meistens gelöscht werden. Habs grad auch noch mal mit Avenger und folgenden Script probiert:

(je nach dem, ob Avenger das Ding als Datei oder Verzeichnis ansieht). Aber egal. Auch Avenger konnte es nicht löschen: :daumenrunter:
Der oft geschilderte gekappte Internetzugang war bei mir auch da. Hab dann den Winsocks2 Schlüssel in der Registry gelöscht und durch einen exportierten aus einem funktionierenden System ersetzt. Funzt wieder.

Ein User schrieb auch, dass er das Rootkit entfernen konnte, nachdem er sich mit der Funktionsweise von Rootkits beschäftigt hatte. Hm, wie er es aber gemacht hat stand da nicht drin.

Ich befürchte außerdem, dass es sich bei mir um eine Kombination aus Rootkit und einem Versteck hinter einem unsupported reparse point handelt. Scheinbar hab ich ihn aber (jetzt wieder nach c:\::: umbenannt), so zusagen in Quarantäne schicken können. :zunge:

Hast du sonst noch eine Idee zum Löschen dieses Teils?

Grüße aus Troja ;-)

Geh mal ins BIOS deines Computers und stell den Plattencontroller von AHCI auf IDE bzw. Compatible um. Genauere Anleitungen kann man nicht posten, da fast jedes BIOS anders aussieht. Schau notfalls ins Handbuch.

Um das installierte Windows wieder booten zu können musst du natürlich auf AHCI wieder umstellen.

Ich hab den Rechner jetzt erst mal wieder normal laufen und beobachte mal, ob sich noch was tut. Ich denke sämtliche Löschversuche sind sinnlos.

Hab zum Thema Rootkit Zero Access diese Erklärung gefunden, da erkenn eich einiges wieder: hxxp://pxnow.prevx.com/content/blog/zeroaccess_analysis.pdf

Welches Tool findet und beseitigt denn dieses Rootkit zuverlässig, wenn seine Wirkungsweise schon mindestens ein halbes Jahr bekannt ist (Erstalldatum der PDF-Datei (11.04.2011)?

Nachdem ich mich nun so lange mit fremdem Rechnern beschäftig habe, dachte ich mir, ich scanne spaßeshalber mal meinen eigenen. Das angehängte Logfile von awsMBR hat mir dann erst mal einen leichten Schauer über den Rücken laufen lassen. :wtf:

Hier die vier farblich markierten Zeilen:

01:36:12.812 Service atapi C:\WINDOWS\System32\DRIVERS\atapi.sys **LOCKED** 32
01:36:12.875 Service GMSIPCI F:\INSTALL\GMSIPCI.SYS **LOCKED** 21
01:36:18.500 ntkrnlpa.exe CLASSPNP.SYS disk.sys ACPI.sys hal.dll >>UNKNOWN [0x8b22ec50]<<
01:36:18.515 \Driver\atapi[0x8b2ae360] -> IRP_MJ_CREATE -> 0x8b22ec50

Nach FixMBR war alles immer noch so. Watt iss hier los? :schrei:

Muss ich dafür etwas ein neues Thema aufmachen?

Garkeins! Zuverlässige im Sinne von 100% gibt es nicht und wird es auch nie geben! Ich hab anfangs schon erwähnt: Bei dem Teil ist eine Bereinigung echt nicht mehr gutzuheißen!!

Warum verfolgst du die Sache mit der Live-CD nicht mehr?! Wenn das nicht geht lass es sein, man kann einfach nicht jedes System per Bereinigung retten.

Hab ich doch geschrieben, weil ich glaube, dass jegliche herkömmlich Löschversuche sinnlos sein werden. Booten von 'ner Live-CD hat ja unter Linux schon nicht viel gebracht. Und ich hab die Platte ja auch schon extern an einen anderen Rechner angeschlossen. Da ging auch nix. Das wäre doch fast dasselbe, wie von 'ner Windows-Live CD zu starten, oder?

Außerdem hab ich das Notebook grad nicht mehr. Der Besitzer muss erst mal paar Rechnungen damit schreiben. Das Rootkit wird sich doch nicht auf Papier weiterverbreiten? :lach:

Der Hauptgrund für die ganzen Reinigungsversuche war nämlich, dass das installierte Handwerkerprogramm eben nicht einfach neu installiert werden kann. Da hält der Hersteller ordentlich die Hand dafür auf. :daumenrunter:

Verdacht auf Rootkit: SYS-Dateien **LOCKED** + ntkrnlpa.exe + \Driver\atapi
 

gelöscht und als neues Thema veröffentlicht

Zumindest hätte man mit der Windows-Live-CD nochmal junction oder fsutil ausprobieren können...

Ja, aber welchen Unterschied hätte denn ein Start von einer Windows-Live-CD gemacht gegenüber dem von einem Windows-PC, an dem die Platte extern via USB angeschlossen ist?

Achso, darauf willst du hinaus. Ich dachte du willst das von dem immer och befallen Windows aus tun. Nun, wenn die Platte mit dem infizierten Windows als externe Platte an einem anderen Rechner angeschlossen ist ist das natürlich genauso gut :)