PPFScanner: Auswertung der Scanfiles

    Hier ein grober Abriss von dem, was in den Scandateien beim Ausführen des Scripres Erweiterter Scan.scp gelistet wird und wie das auszuwerten ist. Der Umfang, Ihnhalt, die Anzahl und auch die Namen der Dateien können sich ändern, denn sie sind abhängig vom Script, das ausgeführt wird.


    Inhalt:

    6 Mal editiert, zuletzt von AxT ()

    Die meisten Scanfiles des PPFScanners besitzen alle den selben Kopf. In etwa sieht der so aus:


    Einträge unter nicht geladene Module:
    Der PPFScanner vollzieht bei seinem Start einen Selbsttest auf in den Scanner geladene DLLs, die eine standard Keylogger Technik verwenden, und deshalb nicht vom Scanner selbst geladen werden. Alle Dateien, die hier stehen, sollten vom Pfad und Dateinamen her genauer unter die Lupe genommen werden. Stehen hier merwürdige Sachen, deutet das auf einen laufenden Keylogger hin. Im Beispiel hier steht dort eine DLL der Firewall.


    Der Eintrag Threads:
    Ein Programm kann gleichzeitig nicht nur eine Sache machen, sondern es können quasi parallel mehrere Sachen ausgeführt werden. Unter Threads wird hier angegeben, wie viele Programmschleifen im Scanner parallel nebeneinander laufen - hinter dem Pfeil stehen die Identitätsnummern (IDs) dieser Threads. Der Scanner ist zur Zeit noch in XProfan geschrieben. XProfan kann maximal mit einem Thread umgehen. Bis einschließlich Vista darf da also maximal ein Thread auftauchen. Ab Windows7 erzeugt das Betriebsystem hier einen zusätzlichen Thread - ab Windows7 dürfen hier also maximal 2 Threads stehen. Alles, was über diesem Wert ist, deutet auf im Scanner ausgeführten Code hin, der nicht vom Scanner gestartet wurde (Usermode RootKit oder Sicherheitsanwendung). Steht hier etwas ungewöhnliches, sollte das mit zusätzlichen RootKit Scans abgeklärt werden.


    Der Eintrag Call:
    Der Scanner benutzt eine von mir entwickelte spezielle Technik, um Usermode RootKits auszutricksen. Steht hier 1, konnte diese Technik erfolgreich initialisiert werden und funktioniert korrekt.


    Der Eintrag SeDebugPrivilege:
    Der Scanner benötigt ein spezielles Privileg, um korrekt scannen zu können. Konnte das Privileg aktiviert werden, steht dieser Eintrag auf 1.


    Der Eintrag Admin:
    Hier muss ja stehen. Steht hier nein, verfügt der User nicht über Adminrechte und der Scanner kann nicht korrekt scannen.

    4 Mal editiert, zuletzt von AxT ()


    Diese Datei listet die in den Speicher geladenen (also momentan ausgeführten) Treiber. Es werden hier nur Treiber gelistet, die keine eindeutige Microsoft Signatur haben. Was hier steht, sollte vom Dateinamen und der Signatur her überprüft werden. Wenn in MD5.TXT die Prüfsumme ausgelesen wurde, ziehe ich auch diese in der Regel mit zur Überprüfung heran.
    Die Angaben über Firmenname, Dateibeschreibung und Produktname sind der jeweiligen Treiberdatei angehängte Informationen, die vom Hersteller stammen. In der Regel achte ich hier auf Treiber ohne Beschreibung oder ungewöhnlichen Angaben zum Hersteller ohne Signatur.
    Die Herstellerangaben und Produktangaben können aber auch gefälscht werden - die Signatur ist da eindeutiger.


    Gelistet werden hier alle von Prozessen (laufenden Programmen) geladene DLLs und EXE Dateien, die nicht eindeutig von Microsoft signiert wurden.
    Die Angaben über Firmenname, Dateibeschreibung und Produktname sind der jeweiligen Datei angehängte Informationen, die vom Hersteller stammen. In der Regel achte ich hier auf Dateien ohne Beschreibung, ungewöhnlichen Angaben zum Hersteller oder ungewöhnliche Datei- und Pfadnamen ohne Signatur.


    Der Eintrag Prozessliste:
    Hier sind die gerade vom System sichtbar ausgeführten Prozesse (gestarteten Programme) zu finden.
    Wichtig sind hier erst mal auch die Einträge unter Kommandozeile. Über manche Microsoft Programme, zum Beispiel RUNDLL32.EXE, lassen sich über einen Kommandozeilenbefehl spezielle DLLs laden. Unter Kommandozeile sieht man, welche DLL zum Beispiel von einer RUNDLL32.EXE ausgeführt wird.
    Die Angaben über Firmenname, Dateibeschreibung und Produktname sind der jeweiligen Datei angehängte Informationen, die vom Hersteller stammen. In der Regel achte ich hier auf Dateien ohne Beschreibung, ungewöhnlichen Angaben zum Hersteller oder ungewöhnliche Datei- und Pfadnamen.


    Der Eintrag Versteckte Prozesse:
    Der Scanner führt hier einen kleinen RootKit Test durch und sucht dabei nach versteckten Prozessen. Der Test ist eher oberflächlich, kann aber erste Hinweise auf laufende RootKits geben.
    Status Zombie: Ein Zombie ist ein bereits beendeter Prozess, von dem noch Teile im Speicher zurückgeblieben sind. Ein Zombie deutet in der Regel nicht auf RootKits hin, sondern auf Probleme mit dem Prozesse, dessen ID unter Holder-PID angegeben wird.
    Werden beim Scan Programme gestartet oder beendet, kann es hier zu Fehlmeldungen kommen. Ein hier gemeldetes RootKit sollte durchs Scans mit weiteren RootKit Scannern abgeklärt werden.

    2 Mal editiert, zuletzt von AxT ()

    Die MD5.TXT enthält die MD5 Summen aller Dateien aus dem System32 und dem Drivers Ordner, sowie die MD5 der EXPLORER.EXE aus dem Windows Ordner. Konnte von einer Datei keine MD5 erstellt werden, ist der Platz hinter dem -> frei.
    Eine MD5 kann nicht erstellt werden, wenn
    a) die Datei 0 Bytes groß ist
    b) der Zugriff zum Lesen der Datei verweigert wird
    Ich schaue hier zuerst immer nach Dateien, bei denen keine MD5 erstellt werden konnte. Alle ausführbaren Dateien (EXE, SYS und DLL), von denen keine MD5 erstellt werden konnte, sind erst mal verdächtig. Stammen die (laut Dateinamen) auch noch von Microsoft, ist das ein fast hundertprozentiger Hinweis auf ein TDSS RootKit.

    In der Datei Hidden.txt kann man Informationen über DLLs finden, die in einen Microsoft Prozess geladen wurden, die aber nicht in der DLL-Liste des Prozesses auftauchen. Ich verwende hier eine von mir vor einigen Jahren selbst entwickelte und zur Zeit noch recht effektive Scantechnik. Bis einschließlich WindowsXP darf in dieser Datei eigentlich gar nichts stehen. Ab Vista gibt es da einige DLLs, die das Betriebsystem unsichtbar in einige Systemprozesse lädt. Diese DLLs sind ausnahmslos von Microsoft.
    In meinem Testbeispiel wurde eine unsichtbare RootKit-DLL in den Prozess DWM.EXE geladen. Die Sachen, auf die man achten sollte, sind rot markiert.

    In der Scandatei Warnings.txt findet man Hinweise darauf, ob Zugriffe auf ein Objekt verweigert wurden, hinter denen sich ein RootKit verbergen kann. Alles was hier mit "Zugriff verweigert" steht (besonders Registryschlüssel), sollte als Alarmmeldung wahrgenommen werden. Diese Einträge sollten (wenn auffällig) mit weiteren RootKit-Scans überprüft werden.
    Desweiteren findet man hier Dateien mit ungültigen Signatureinträgen. Alle Dateien mit dem Vermerk "...nicht vertrauenswürdig..." sollten auf Malware hin überprüft werden!



    Tauchen in dieser Datei hinweise auf IAT Hooks oder Patches in einer bestimmten DLL auf, kann das auf das Vorhandensein eines Usermode Rootkits hindeuten.

    Aus der Scandatei Scripting.txt kann man ersehen, ob beim Ausführen von Scripten alles geklappt hat und was schief gelaufen ist.
    Die Datei wird meist erst wichtig, wenn der User irgendwelche Probleme beim Scan meldet.
    An wichtigen Daten werden dort eigentlich nur Zugriffslisten abgelegt, wenn folgende Scriptingbefehle verwendet werden:

    • FILE_ACES
    • SET_FILE_ACE_IN_DACL
    • READ_FILE_IL
    • READ_FILE_IL_NO_EXPAND
    • SET_FILE_IL
    • SET_FILE_IL_NO_EXPAND
    • SET_REGKEY_ACE_IN_DACL
    • REGKEY_ACES
    • READ_REGKEY_IL
    • SET_REGKEY_IL

    2 Mal editiert, zuletzt von AxT ()