Kinderkrankheiten Malwarebytes Antimalware, Emsisoft EEK und FRST64?

Microwave

@Fragerin: Ja, ich habe die Dateien und Pfade rekursiv erzeugt (einschlägige NtXxx-Aufrufe)und ja es gibt drei Typen von Dateien,
die Windows nicht so gerne mag: Dateien mit Leerschlägen am Ende, Dateien mit einem Punkt am Ende und Dateien mit einer Dateinamenlänge von 255 Zeichen, die sich in einem tieferen Verzeichnis als bloss C:\ befinden.

Zur zweiten Frage kann ich sagen, jein das geht (nicht). Es kommt immer darauf an, was du mit Windows meinst.
Mit den NtXxx-Systemaufrufen lassen sich ungültige Dateien erzeugen, mit denen das Windows-GUI nichts anfangen kann.
Dies bedeutet in der Tat, dass auch Windows-Malware, die "dokumentierte" Dinge tut, wie z.B. den Run-Key benutzen, schöne sichtbare GUIs anzeigen, und den Zugriff auf den Desktop blocken (vgl. GEMA-Trojaner), sich nicht mittels derartiger Dateien verankern kann.
Wesentlich typischer ist es allerdings für schädliche Software, so undokumentierte Dinge wie möglich zu tun, und da wird auch vor speziellen Systemaufrufen nicht halt gemacht.
Wie du siehst, könnte Malware somit dennoch schwerlöschbare Ordner und Dateien anlegen, einfach nicht über's GUI.

Interessanter ist jedoch die Tatsache, dass Dienste vom Typ "Systemstart" und "Bootstart" ebenfalls von Pfaden geladen werden können, mit denen das UI nichts anfangen kann, da dazu intern ebenfalls native Aufrufe verwendet werden.
Das macht es also möglich, eine ".YncrèdybleFile " im C: abzulegen, die zwar in den Systemkern geladen wird, aber nicht so ohne Weiteres entfernt werden kann.
Mittels 16000 Verzeichnisse tiefem Ordnersystem, das den Namen " " trägt, könnte der Virenscanner dann gerade noch endgültig zum Abstürzen gebracht werden.
Ist in der Theorie also durchaus möglich.
Desweiteren ist es ganz einfach, den kaum verwendeten Treibereintrag "system32\drivers\parport.sys" auf "system32\drivers\parport.sys "
umzubiegen, und nachher auch wirklich eine "parport.sys " ins Verzeichnis zu kopieren.
Ergebnis: Jeglicher Zugriff auf "parport.sys " endet auf "parport.sys" (man markiert "parport.sys " und will sie
löschen, Windows fragt aber, ob man "parport.sys" löschen möchte), der Kernel lädt aber dennoch die "parport.sys ".
Der Schleier fällt erst, wenn die parallele Schnittstelle spinnt, weil der Eintrag auf "parport.sys " verweist, aber der theoretisch erforderliche Treiber "parport.sys" wäre.

Ich hatte das vor einiger Zeit mal ausprobiert und wie erwartet hat FRST64 0.00% gemeckert, obwohl schön jedes Mal die falsche parport.sys ("parport.sys ") geladen wurde.
Windows hat auf die Anfrage von FRST64 "Hey Windows, trägt die Datei "parport.sys "" eine gültige digitale Signatur?" nämlich einfach geantwortet: "Ja, selbstverständlich ist "parport.sys" gültig signiert!", wonach die Datei gewhitelisted wurde.
Die falsche "parport.sys " hat sich dann noch selber versteckt (Treiberobjekt von den Laufwerken umgebogen), womit die Welt in Ordnung zu sein schien.
In diesem Falle erkannte Malwarebytes das Ganze allerdings als "Rootkit.Driver", die Entfernung klappte ebenfalls.
Spannend wäre es im Nachhinein gewesen, wenn man einen tiefen Ordner " " ebenfalls im Drivers-Verzeichnis platziert hätte, womit MBAM jedes Mal abgestürzt wäre und der falsche Treiber unendeckt geblieben wäre.. das nur nebenbei.
Einfach aber höchst wirkungsvoll ist auch der Trick, Dateien im C:\$Extend-Verzeichnis zu platzieren, denn dieses - oh Überraschung - ist unsichtbar ohne Verwendung von Spezialmitteln, und auch der Zugriff darauf gestaltet sich eher schwierig.

@bbi2014, der Nullzeichen-Trick ist alt, ja. FRST64 kann damit nicht umgehen, Gmer hingegen zeigt einen "Hidden Service" an, wenn man versucht, auf diese Weise einen Treibereintrag zu verstecken.
Es gibt allerdings weitere offline funktionierende Möglichkeiten (man benötigt keine auffälligen oder verbotenen(->PatchGuard) Hooks), um zumindest
vor Regedit Treibereinträge zu verstecken, die auch GMER nicht dazu veranlassen, Alarm zu schlagen.


Offenbar sind alle diese Modifikationen nicht an geladene Malware gebunden, die Offline-Enfernung dürfte die Tools also mindestens vor die selben Probleme wie bei der Online-Entfernung stellen...


Grüsse - Microwave