Suche nach Hinweisen auf Kompromittierung am Windows-Beispiel

Vorbereitung

Auch bei Routineüberprüfungen sollten Ein- und Ausgaben protokolliert werden. Das ist leider unter Windows nicht so bequem möglich wie unter Unix, da der script Befehl fehlt (es sei denn, man installiert eine entsprechende Unix Umgebung, aber das dürfte nur selten der Fall sein). Als Alternative mit Bordmitteln muß das Kommando doskey /history genügen, mit dem sich leider nur nachträglich eine Historie der eingegebenen Kommandos anzeigen läßt. Die Ausgaben der Kommandos sollten gleich mittels Ausgabeumlenkung (">") in Dateien geschrieben werden.

Stellt sich der anfängliche Verdacht als unbegründet heraus, hat das Protokoll keine zusätzliche Arbeit verursacht und kann theoretisch archiviert werden, um den Normalzustand zu veranschaulichen. Da für die Untersuchungen die Zeitpunkte in Logfiles und dgl. besondere Bedeutung haben, sollte die die Systemzeit protokolliert und ein Offset mit der "Normalzeit" von ihrer Armbanduhr protokolliert werden.

Z:\zeugs>date /t
19.02.2006
Z:\zeugs>time /t
19:46
Z:\zeugs>doskey /history
date /t
time /t
doskey /history
Z:\zeugs>

Aktive Benutzer

Die gerade und vorher angemeldeten Benutzer sollten kontrolliert werden. Mögliche Fragen:

  • Sind oder waren Benutzer zu ungewöhnlicher Zeit angemeldet?

  • Gab es Logins von ungewöhnlichen Systemen?

  • Gibt es neue Benutzer, die so nicht auf das System gehören?

  • Haben bekannte oder neue Nutzer erweiterte Privilegien ?

  • Hat die Gruppe der (lokalen oder Domain) Administratoren neue Mitglieder ?

Z:\zeugs>psloggedon
PsLoggedOn v1.31 - Logon Session Displayer
Copyright (C) 1999-2003 Mark Russinovich
Sysinternals - www.sysinternals.com
Users logged on locally:
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
19.02.2006 20:35:05    DONALD\klaus
NT AUTHORITY\SYSTEM
No one is logged on via resource shares.
Z:\zeugs>

Failed Remote Logins anzeigen mit ntlast -f -r. Die zeitlich enge Abfolge könnte von einem automatisierten Login-Versuch stammen.

Z:\zeugs>ntlast -f -r
meyer      \\ANGREIFER  DONALD  Sun Feb 19 08:14:13pm 2005
meyer      \\ANGREIFER  DONALD  Sun Feb 19 08:14:13pm 2005
meyer      \\ANGREIFER  DONALD  Sun Feb 19 08:14:14pm 2005
mueller    \\ANGREIFER  DONALD  Sun Feb 19 08:14:14pm 2005
mueller    \\ANGREIFER  DONALD  Sun Feb 19 08:14:15pm 2005
mueller    \\ANGREIFER  DONALD  Sun Feb 19 08:14:15pm 2005
Z:\zeugs>

Detailanzeige eines lokalen Logins mit ntlast -v

Z:\zeugs>ntlast -v
Record Number: 3
ComputerName: DONALD
EventID: 528   -   Successful Logon
Logon:  Sun Feb 19 08:35:04pm 2006
Logoff: Sun Feb 19 08:35:04pm 2006
Details -
ClientName:     klaus
ClientID:       (0x0,0x6361D)
ClientMachine:  DONALD
ClientDomain:   DONALD
LogonType:      Interactive
- End Of File -
Z:\zeugs>

Windows führt nur dann ein Protokoll über Logins und Login-Versuche, wenn in den Audit Einstellungen "Audit logon events" bzw. "Audit account logon events" aktiviert ist. Dies ist per Default nur im Windows Server 2003 der Fall, auf allen anderen Windows (NT) Versionen muß diese Option von Hand (oder über den Security Editor) aktiviert werden.

Nachsehen-Windows: Audit Policy

Laufende Prozesse

Mögliche Ungereimtheiten bei den laufenden Prozessen:

  • Wird ungewöhnlich viel Rechenzeit verbraucht, könnte es sich um einen sog. Sniffer handeln, der Netzwerkverkehr protokolliert

  • Läuft ein Prozess unter einer falschen Benutzerkennung?

  • Laufen evtl. mehrere Prozesse mit ähnlich klingendem Namen ? Z.B.: "winlogin.exe" und "winlogon.exe" (der letztere gehört zu Windows, der vorige nicht).

  • Laufen Prozesse mit ungewöhnlichen Pfaden oder Argumenten ?

  • Läuft ein Prozess mit einer ungewöhnlichen Shared-Library (.dll)

Z:\zeugs>pslist
PsList 1.26 - Process Information Lister
Copyright (C) 1999-2004 Mark Russinovich
Sysinternals - www.sysinternals.com
Process information for DONALD:
Name                Pid Pri Thd  Hnd   Priv        CPU Time    Elapsed Time
Idle                  0   0   1    0      0     1:01:49.781     0:00:00.000
System                4   8  51  335      0     0:00:14.734     0:00:00.000
smss                540  11   3   21    252     0:00:01.218     1:14:56.730
csrss               612  13  12  325   1712     0:00:20.718     1:14:48.261
winlogon            636  13  18  514   6864     0:00:01.859     1:14:47.120
services            680   9  16  264   1860     0:00:03.453     1:14:42.011
lsass               692   9  17  319   3468     0:00:01.187     1:14:41.824
svchost             848   8  16  191   2848     0:00:00.156     1:14:34.870
svchost             916   8  10  250   1580     0:00:00.390     1:14:33.667
svchost            1020   8  53 1203  12144     0:00:09.515     1:14:33.230
svchost            1072   8   4   72   1052     0:00:00.187     1:14:32.949
svchost            1148   8  15  238   2320     0:00:00.187     1:14:32.589
spoolsv            1364   8  10  116   2976     0:00:00.234     1:14:30.355
VMwareService      1724  13   3   43    660     0:00:00.609     1:14:22.449
alg                 248   8   6  103   1012     0:00:00.078     1:14:06.902
explorer            312   8  12  331   6860     0:00:04.562     1:13:23.292
wscntfy             336   8   1   35    468     0:00:00.062     1:13:23.245
VMwareTray         2024   8   2   30    624     0:00:00.093     1:13:11.933
VMwareUser         2016   8   1   29    760     0:00:00.281     1:13:11.902
msmsgs              980   8   2  173   1308     0:00:00.203     1:13:11.855
ctfmon             1004   8   1   64    756     0:00:00.125     1:13:11.792
svchost            1264   8   7  131   2328     0:00:00.203     0:13:03.375
PSEXESVC            892   8   6   63   1008     0:00:00.010     0:25:47.564
cmd                1272   8   1   25    984     0:00:00.020     0:25:15.969
ftp                1372   8   1   39   1176     0:00:00.020     0:21:05.861
cmd                1160   8   1   28    976     0:00:00.020     0:23:25.536
nc                 1424   8   3   40   1012     0:00:00.010     0:23:39.800
cmd                1948   8   1   31   1888     0:00:00.140     0:00:04.640
pslist              372  13   2   71    680     0:00:00.078     0:00:00.062
Z:\zeugs>

Netzwerkverbindungen

Für die offenen Netzwerkverbindungen gilt Ähnliches wie bei den Prozessen:

  • Haben ungewöhnliche Prozesse eine Netzwerkverbindung oder nehmen sogar selber auf einem Port Verbindungen an ?

  • Läuft ein Service, der nicht laufen sollte ?

  • Wird von einem bekannten Service ein falscher Port gebunden ?

Zur Überprüfung bietet sich das Werkzeug tcpview von Sysinternals (GUI) an, oder die Kommandozeilenversion tcpvcon

Z:\zeugs>tcpvcon -anc
TCP,C:\WINDOWS\system32\svchost.exe,916,LISTENING,0.0.0.0:135,0.0.0.0:0
TCP,System,4,LISTENING,0.0.0.0:445,0.0.0.0:0
TCP,C:\WINDOWS\System32\alg.exe,248,LISTENING,127.0.0.1:1025,0.0.0.0:0
TCP,System,4,LISTENING,172.16.190.128:139,0.0.0.0:0
TCP,C:\WINDOWS\system32\mirc.exe,200,ESTABLISHED,172.16.190.128:1062,10.11.12.134:6667
UDP,System,4,,0.0.0.0:445,*:*
UDP,C:\WINDOWS\system32\lsass.exe,692,,0.0.0.0:500,*:*
UDP,C:\WINDOWS\System32\svchost.exe,1072,,0.0.0.0:1033,*:*
UDP,C:\WINDOWS\system32\lsass.exe,692,,0.0.0.0:4500,*:*
UDP,C:\WINDOWS\System32\svchost.exe,1020,,127.0.0.1:123,*:*
UDP,C:\WINDOWS\System32\svchost.exe,1148,,127.0.0.1:1900,*:*
UDP,C:\WINDOWS\System32\svchost.exe,1020,,172.16.190.128:123,*:*
UDP,System,4,,172.16.190.128:137,*:*
UDP,System,4,,172.16.190.128:138,*:*
UDP,C:\WINDOWS\System32\svchost.exe,1148,,172.16.190.128:1900,*:*
Z:\zeugs>

Nachsehen-Windows: TCP View

(Das Tool fport von Foundstone scheint bei neueren Windows Versionen Probleme mit der Zuordnung von Prozess-IDs zu haben und sollte daher nicht verwendet werden.) Ab Windows XP ist eine Ausgabe der Prozess-ID mit netstat -o möglich, die dann über den Task-Manger o. ähnliche Programme genauer untersucht werden kann.

Z:\zeugs>netstat -ano
Active Connections
Proto  Local Address          Foreign Address        State           PID
TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       916
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
TCP    127.0.0.1:1025         0.0.0.0:0              LISTENING       248
TCP    172.16.190.128:139     0.0.0.0:0              LISTENING       4
TCP    172.16.190.128:1077    10.11.12.134:6667      ESTABLISHED     364
UDP    0.0.0.0:445            *:*                                    4
UDP    0.0.0.0:500            *:*                                    692
UDP    0.0.0.0:1033           *:*                                    1072
UDP    0.0.0.0:4500           *:*                                    692
UDP    127.0.0.1:123          *:*                                    1020
UDP    127.0.0.1:1900         *:*                                    1148
UDP    172.16.190.128:123     *:*                                    1020
UDP    172.16.190.128:137     *:*                                    4
UDP    172.16.190.128:138     *:*                                    4
UDP    172.16.190.128:1900    *:*                                    1148
Z:\zeugs>

Mit Hilfe von handle, listdlls oder dem Process Explorer(Sysinternals) kann der Prozess identifiziert und genauer untersucht werden, um z.B. die Datei mit dem Programmtext zu finden (Eintrag txt).

Wenn im folgenden Abschnitt das Eventlog untersucht wird, wird man feststellen, dass die Adressen von fremden Systemen nicht als IP-Adresse, sondern als NetBIOS Name gespeichert werden. Um die Zuordnung von Namen in IP-Adressen zu erhalten, sollte ein Dump des NetBIOS Name Cache gemacht werden:

nbtstat -c
Local Area Connection:
Node IpAddress: [192.168.13.14] Scope Id: []
NetBIOS Remote Cache Name Table
Name             Type     Host Address  Life [sec]
------------------------------
ANGREIFER <20> UNIQUE     172.16.123.45    378

Manche Angreifer ändern die Zuordnung von Hostnamen zu IP-Adressen, um das Aktualisieren von Anti-Virus Signaturen oder Windows-Patches zu verhindern oder um Nutzer auf ihre Seiten umzuleiten (z. B. zum Phishing). Dazu werden entsprechende Einträge in den Dateien %Systemroot%\System32\Drivers\Etc\hosts und %Systemroot%\System32\Drivers\Etc\lmhosts gemacht. Es lohnt sich also immer, diese Dateien mit in die forensische Untersuchung aufzunehmen. (%Systemroot% ist üblicherweise C:\WINDOWS oder C:\WINNT) Bei Windows 95, 98 und ME liegen diese Dateien in %Systemroot%.

C:\WINDOWS\system32\drivers\etc>type hosts
127.0.0.1       localhost
172.16.10.10    www.windowsupdate.com
C:\WINDOWS\system32\drivers\etc>

Anstatt nur auf dem lokalen System zu suchen, bietet es sich evtl. auch an, mit Hilfe von Programmen wie nmap von außen zu testen, auf welchen Ports Verbindungen angenommen werden. Ergibt sich eine Diskrepanz zur Ausgabe von netstat oder tcpvcon, so wurde das System wahrscheinlich kompromittiert und ein Rootkit installiert.

Hinweise in den Logs

Die Suche nach Unregelmäßigkeiten in den Logfiles sollte ggf. ganz am Anfang durchgeführt werden. Was eine Unregelmäßigkeit darstellt ist aber sehr von der jeweiligen Installation abhängig. Natürlich muß dazu das Logging im System aktiviert sein, das ist auch in den neuesten Windows-Versionen nicht per Default so und muß sofort nach der Installation durch die Systemadministratoren erfolgen.

Ganz allgemein sollten folgende Ereignisse misstrauisch machen:

  • Unerwartete Neustarts von Diensten - speziell des Eventlogs

  • Abschaltungen von Diensten - besonders sicherheitsrelevante Dienste wie Antivirenprogramme.

  • Ungewöhnliche Fehlermeldungen oder gar Abstürze von Diensten

  • Allgemein können Steuerungszeichen in den Logfiles auf einen Versuch zum Auslösen eines Buffer Overflows hinweisen

Das Windows Eventlog liegt nur in binärer Form vor und muß daher mit Spezialprogrammen in lesbare Form überführt werden. Das geht mit dem dumpel Tool aus Microsoft Windows Resource Kit oder dem dumpevt Tool von Systemtools, letzteres bietet etwas mehr Funktionalität.

Genau genommen gibt es nicht ein Eventlog sondern mehrere, Security, System und Application die alle einzeln untersucht werden müssen. Windows 2000 und Windows 2003 Server die als Domain Controller agieren, haben zusätzlich noch drei weitere Eventlogs: DNS, File Replication und Directory Service

Neben dem Eventlog unterhält Windows noch eine Reihe weitere Logfiles, die jedoch normalen ASCII-Logdateien unter Unix entsprechen, d.h. sie können als normale Textdateien angesehen und bearbeitet werden, leider auch durch den Angreifer. Lücken im Log, Kontrollzeichen u. dgl. sollten also mißtrauisch machen.

Änderungen in der Registry

Manchmal sehen sich Angreifer gezwungen, die Konfiguration des gerade kompromittierten Systems zu ändern, z.B. um die lokale Firewall für ihre Zwecke durchlässiger zu machen. Die Firewall kann man dann unvermutet abgeschaltet oder mit neuen Regeln vorfinden.

regedit /s firewall.reg
firewall.reg:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
"EnableBalloonTips"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Security Center]
"FirewallDisableNotify"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Security Center]
"FirewallOverride"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\
FirewallPolicy\StandardProfile\GloballyOpenPorts\List]
"1900:UDP"="1900:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22007"
"2869:TCP"="2869:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22008"
"139:TCP"="139:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22004"
"445:TCP"="445:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22005"
"137:UDP"="137:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22001"
"138:UDP"="138:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22002"
"65530:TCP"="65530:TCP:*:Enabled:Unspecified"
"1001:TCP"="1001:TCP:*:Enabled:Unspecified"
"1002:TCP"="1002:TCP:*:Enabled:Unspecified"
"1003:TCP"="1003:TCP:*:Enabled:Unspecified"
"1004:TCP"="1004:TCP:*:Enabled:Unspecified"
"1005:TCP"="1005:TCP:*:Enabled:Unspecified"
"65500:TCP"="65500:TCP:*:Enabled:Unspecified"
"65501:TCP"="65501:TCP:*:Enabled:Unspecified"
"65502:TCP"="65502:TCP:*:Enabled:Unspecified"
"65503:TCP"="65503:TCP:*:Enabled:Unspecified"
"65504:TCP"="65504:TCP:*:Enabled:Unspecified"
"65505:TCP"="65505:TCP:*:Enabled:Unspecified"

Da praktisch alle relevanten Konfigurationseinstellungen in der Windows Registry abgelegt werden, ist eine genauere Untersuchung notwendig. Mit dumpreg lassen sich einzelne oder alle Registry-Keys in eine ASCII Datei schreiben.

Nachsehen-Windows: Dumpreg

Besondere Bedeutung haben zwei Bereiche: Einmal die sog. Autorun Keys, die bestimmen, welche Programme bei Systemstart oder Einloggen des Benutzers gestartet werden sollen. Man kann sich diese Schlüssel einzeln aus der Registry suchen, bequemer ist aber das Programm Autoruns bzw. die Kommandozeilenversion autorunsc (beide von Sysinternals).

Z:\zeugs>autorunsc
Autoruns v8.43 - Autostart program viewer
Copyright (C) 2002-2005 Mark Russinovich and Bryce Cogswell
Sysinternals - www.sysinternals.com
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
C:\WINDOWS\system32\userinit.exe
Userinit Logon Application
Microsoft Corporation
c:\windows\system32\userinit.exe
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
Explorer.exe
Windows Explorer
Microsoft Corporation
c:\windows\explorer.exe
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
VMware Tools
VMwareTray
VMware, Inc.
c:\program files\vmware\vmware tools\vmwaretray.exe
VMware User Process
VMwareUser
VMware, Inc.
c:\program files\vmware\vmware tools\vmwareuser.exe
Windows Data Services
Data Services
Microsoft
c:\windows\system32\rundll32 c:\windows\system32\:svchost.dll
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
MSMSGS
Windows Messenger
Microsoft Corporation
c:\program files\messenger\msmsgs.exe
ctfmon.exe
CTF Loader
Microsoft Corporation
c:\windows\system32\ctfmon.exe
Z:\zeugs>

Ebenfalls wichtig sind die Einstellungen zum Audit, d.h. welche Ereignisse überhaupt ins Eventlog geschrieben werden. Auch sie lassen sich aus den dumpreg Daten extrahieren, einfacher ist jedoch das Tool Auditpol.

Z:\zeugs>auditpol
Running ...
(X) Audit Enabled
AuditCategorySystem            = No
AuditCategoryLogon             = Success and Failure
AuditCategoryObjectAccess      = No
AuditCategoryPrivilegeUse      = No
AuditCategoryDetailedTracking  = No
AuditCategoryPolicyChange      = No
AuditCategoryAccountManagement = No
Unknown                        = No
Unknown                        = Success and Failure
Z:\zeugs>

Mit psinfo -d kann überprüft werden, ob eigentlich in Reserve gehaltene Platten montiert wurden und ob sich in einem Dateisystem unerwartet viele Daten befinden. Ist letzteres der Fall, wurde das System wahrscheinlich von den Angreifern als Lager oder evtl. sogar als Verteilstation für illegale Kopien von Software, Filmen, Pornographie und ähnlichem missbraucht.

Z:\zeugs>psinfo -d
PsInfo v1.71 - Local and remote system information viewer
Copyright (C) 2001-2005 Mark Russinovich
Sysinternals - www.sysinternals.com
System information for \\DONALD:
(...)
Volume Type       Format     Label                      Size       Free   Free
A: Removable                                                          0.0%
C: Fixed      NTFS                               3.99 GB    1.98 GB  49.5%
D: CD-ROM     CDFS       WXPOEM_EN             488.59 MB              0.0%
Z: Remote     HGFS       Shared Folders         66.25 GB   36.92 GB  55.7%
Z:\zeugs>

Spuren im Dateisystem

Oft lassen die Angreifer Dateien und Verzeichnisse im Dateisystem zurück, die uns als Hinweise dienen. Dabei wählen die Angreifer zur Ablage ihrer Dateien Verzeichnisse, die auf jedem System vorhanden sind und im Windows Explorer nicht angezeigt werden (d.h. das "hidden" Attribut ist für diese Dateien und Verzeichnisse gesetzt. Um mögliche Probleme mit Zugriffsrechten, wie unter Unix, machen sich die Angreifer in der Regel keine Sorgen, da Benutzer unter Windows sehr häufig Mitglied der Gruppe der lokalen Administratoren sind und damit praktisch überall im Dateisystem Schreibzugriff haben.

Daher verstecken die Angreifer ihre Dateien in Verzeichnissen wie C:\Recycler C:\System Volume Information oder C:\Documents and Settings\Default User\Local Settings\Temporary Internet Files.

Beliebt ist auch das Systemverzeichnis %systemroot%\system32 oder Unterverzeichnisse davon. Hier werden die Programme mit Namen abgelegt, die identisch zu Systemprogrammen sind, dann jedoch nicht im selben Verzeichnis wie das Originalprogramm oder mit Namen, die dem Original sehr ähnlich sind.

C:\WINDOWS\system32>dir winlog*
Volume in drive C has no label.
Volume Serial Number is 206A-B316
Directory of C:\WINDOWS\system32
19.02.2006  19:56            27.384 winlogin.exe
04.08.2004  00:56           502.272 winlogon.exe
2 File(s)        529.656 bytes
0 Dir(s)   2.122.985.472 bytes free
C:\WINDOWS\system32>

Ein anderes Verfahren ist das Ausnutzen der Windows "Alternate Data Streams" (ADS). Dieses Feature erlaubt es, in einer Datei oder einem Verzeichnis mehrere Datenströme unterzubringen. Der Vorteil für die Angreifer ist, dass die meisten Windows Werkzeuge ADS nicht anzeigen bzw. Sicherheitssoftware wie Anti-Virenprogramme ADS oft nicht durchsucht. Mit speziellen Werkzeugen, wie lads von heysoft kann jedoch nach ADS gesucht werden. Die Malware aus dem folgenden Beispiel würde sich beispielsweise mit rundll32 C:\WINDOWS\system32\:svchost.dll starten lassen. Allerdings gibt es auch legitime Verwendungen von ADS.

C:\WINDOWS\system32>z:\zeugs\lads /a
LADS - Freeware version 4.00
(C) Copyright 1998-2004 Frank Heyne Software (http://www.heysoft.de)
This program lists files with alternate data streams (ADS)
Use LADS on your own risk!
Scanning directory C:\WINDOWS\system32\
size  ADS in file
----------  ---------------------------------
32658  C:\WINDOWS\system32\:svchost.dll
32658 bytes in 1 ADS listed
309363217 bytes (uncompressed) used by C:\WINDOWS\system32\
4285337600 total bytes on this disk
2123481088 free bytes on this disk
C:\WINDOWS\system32>

Ein Rootkit finden

Manchmal sind die Dateien und die Netzwerkverbindungen der Angreifer nicht zu finden, obwohl klar ist, dass ein Einbruch stattgefunden hat. Evtl. wurde in diesem Fall ein sog. Rootkit installiert, das die Spuren der Angreifer unsichtbar macht.

Ein Rootkit besteht oft aus ausgetauschten Systemprogrammen wie z.B. netstat, wobei die vom Angreifer eingebrachte Version manche Netzwerkverbindungen nicht mehr anzeigt. Anstatt der Programme kann ein Angreifer auch Bibliotheken austauschen, auf die die entsprechenden Programme aufbauen, um die Manipulation an einer etwas zentraleren und schwerer zu entdeckenden Stelle durchzuführen.

Bei der Suche nach Manipulation sollten daher bevorzugt Programme verwendet werden, die auf einem separaten Medium gelagert werden wie Diskette, CD, USB-Stick oder CIFS-Mount. Diese sollten statisch gebunden sein, oder Bibliotheken benutzen, die ebenso von einem vertrauenswerten Medium kommen. Ergibt sich nun ein Unterschied in der Ausgabe der Systemprogramme in den lokalen Verzeichnissen und denen vom vertrauenswerten Medium, liegt offensichtlich ein Problem vor.

Es bietet sich an, die Integrität der Systemprogramme zu überprüfen. Dies kann z.B. mit den Programmen tripwire oder osiris gemacht werden. Dabei werden nach der Installation, bzw. zu einem Zeitpunkt an dem man sich sicher ist, dass noch keine Kompromittierung vorliegt, kryptographische Hashes aller Systemprogramme erzeugt. Diese werden auf einem separaten Medium gespeichert und im Falle eines Verdachts mit frisch erzeugten Hashes verglichen, wobei ausgetauschte Programme entdeckt werden sollten.

osiris-4.2.0-release[donald]: print-log 1
-------- begin log file --------
compare time: Thu Feb 23 18:16:24 2006
host: donald
scan config: default.windowsxp (974cd899)
log file: 1
base database: 1
compare database: 2
[203][donald][new][c:\windows\system32\nc.exe]
[203][donald][new][c:\windows\system32\upnp.exe]
Change Statistics:
----------------------------------
checksums: 0
SUID files: 0
root-owned files: 0
file permissions: 0
new: 2
missing: 0
total differences: 2
--------  end log file  --------

Es gibt auch spezielle Programme für die Suche nach Rootkits. Die bekanntesten sind Rootkit Revealer von Sysinternals, RKdetect und RKDetector die frei verfügbar sind, sowie kommerzielle Produkte, wie F-Secure Blacklight, NAI Stinger und Microsoft AntiSpyware.

Diese Programme suchen nach bekannten Mustern bzw. Ungereimtheiten, die durch den Einsatz des jeweiligen Rootkits im System entstehen. Wurde das Rootkit modifiziert oder ist es relativ neu, so besteht die Gefahr, dass es so nicht gefunden werden kann.

Referenzen der Werkzeuge zum Download: