5.2 Microsoft Sysinternals – Erweiterte Werkzeuge zur Fehleranalyse

Die Sysinternals-Werkzeuge wurden ursprünglich von Mark Russinovich und Bryce Cogswell entwickelt. Microsoft übernahm Sysinternals im Jahr 2006 und stellt die Werkzeuge weiterhin bereit.

Die Sammlung besteht überwiegend aus kleinen, spezialisierten Programmen. Viele davon müssen nicht klassisch installiert werden und können nach dem Entpacken direkt gestartet werden.

Wichtige Werkzeuggruppen

Abgrenzung

Sysinternals ist:

• keine automatische Reparatursuite
• kein Ersatz für ein Antiviren- oder EDR-System
• kein Ersatz für ein zentrales Monitoring
• kein vollständiger Debugger
• kein Beweiswerkzeug, das aus einer einzelnen Auffälligkeit automatisch die Ursache bestimmt

Die Werkzeuge ergänzen Ereignisanzeige, Task-Manager, Ressourcenmonitor, Leistungsüberwachung, PowerShell und spezialisierte Debuggingprogramme.

Sysinternals-Werkzeuge sollten ausschließlich aus vertrauenswürdigen Microsoft-Quellen bezogen werden.

Offizielle Möglichkeiten

1. Einzelwerkzeuge über Microsoft Learn herunterladen
2. vollständige Sysinternals Suite herunterladen
3. Sysinternals Suite aus dem Microsoft Store installieren
4. Werkzeuge über Sysinternals Live ausführen

Sysinternals Suite

Die Suite enthält einen großen Teil der Diagnosewerkzeuge in einem gemeinsamen Archiv. Für bestimmte Plattformen stellt Microsoft unterschiedliche Pakete bereit, darunter x64 und ARM64.

Microsoft Store

Bei der Store-Version werden grafische Programme im Startmenü eingetragen. Die Befehlszeilenprogramme können über App-Ausführungsaliase aufgerufen werden.

Sysinternals Live

Ein Werkzeug kann direkt von Sysinternals Live gestartet werden:

[TEST][SENS] \\live.sysinternals.com\tools\procexp.exe

Beispiel für Process Monitor:

[TEST][SENS] \\live.sysinternals.com\tools\procmon.exe

Dabei müssen Netzwerkzugriff, Proxy, Firewall, Namensauflösung und die Sicherheitsrichtlinien der Organisation berücksichtigt werden.

In kontrollierten Unternehmensumgebungen sollte nicht ungeprüft eine ausführbare Datei direkt aus dem Internet gestartet werden. Besser ist häufig ein freigegebenes, geprüftes und versioniertes internes Werkzeugverzeichnis.

Vor dem Einsatz sollte geprüft werden:

• stammt die Datei von Microsoft?
• ist die digitale Signatur gültig?
• stimmt die erwartete Architektur?
• wurde die Datei aus einem freigegebenen Speicherort bezogen?
• ist die Werkzeugversion dokumentiert?
• wurde die Datei durch die Sicherheitssoftware geprüft?

Digitale Signatur mit PowerShell kontrollieren

[RO] Get-AuthenticodeSignature ".\procexp.exe" |
    Select-Object Status, StatusMessage, SignerCertificate

Dateihash berechnen

[RO] Get-FileHash ".\procexp.exe" -Algorithm SHA256

Der Hash kann zur internen Dokumentation und zum Vergleich identischer Werkzeugstände verwendet werden. Ein Hash beweist allein jedoch nicht, dass eine Datei vertrauenswürdig ist.

Sysinternals Sigcheck verwenden

[RO] sigcheck.exe -a -h -i ".\procexp.exe"

Typische Informationen können sein:

• Dateiversion
• Herausgeber
• digitale Signatur
• Zertifikatskette
• Zeitstempel
• kryptografischer Hash
• Dateibeschreibung
• Produktname

Eine gültige Signatur bestätigt die signierte Herkunft und Dateiintegrität innerhalb der Signaturprüfung. Sie beweist nicht automatisch, dass jede ausgeführte Funktion im konkreten Einsatz sicher oder erwünscht ist.

Vor dem Start eines Sysinternals-Werkzeugs sollte feststehen:

1. Welcher Fehler wird untersucht?
2. Welcher Computer ist betroffen?
3. Welcher Benutzerkontext ist betroffen?
4. Wann tritt der Fehler auf?
5. Welches Werkzeug kann die benötigte Beobachtung liefern?
6. Welche Daten können bei der Aufzeichnung entstehen?
7. Ist eine erhöhte Ausführung erforderlich?
8. Wie groß kann die Protokolldatei werden?
9. Wo wird sie geschützt gespeichert?
10. Wann wird die Aufzeichnung beendet?
11. Wie werden sensible Daten redigiert?
12. Welche Änderung muss anschließend zurückgenommen werden?

Grundregeln

• zuerst beobachten, dann verändern
• Filter vor längeren Aufzeichnungen vorbereiten
• Zeitpunkt und Reproduktionsschritte dokumentieren
• keine Prozesse oder Handles auf Verdacht beenden
• keine unbekannten Autostarts ungeprüft löschen
• keine Diagnosedateien öffentlich hochladen
• keine Remoteausführung ohne Freigabe
• nur den erforderlichen Berechtigungskontext verwenden
• Werkzeugversion und Befehlszeile dokumentieren
• nach jeder Änderung die betroffene Funktion erneut prüfen

Process Explorer zeigt Prozesse hierarchisch an und liefert detaillierte Informationen zu:

• Prozessname und PID
• übergeordnetem Prozess
• Benutzerkonto
• CPU- und Speicherauslastung
• Handles
• geladenen DLLs
• Speicherabbildern
• Threads
• TCP/IP-Aktivität
• Dateipfad
• Befehlszeile
• digitaler Signatur
• Integritätsstufe
• Sicherheitskontext
• Prozessstartzeit

Starten

[RO][SENS] procexp.exe

Für vollständige Informationen über Systemprozesse können erhöhte Rechte erforderlich sein:

[RO][PRIV][SENS] procexp.exe

Wichtige Funktionen

Typische Anwendungsfälle

• Welcher Prozess hält eine Datei geöffnet?
• Welche Anwendung hat einen Unterprozess gestartet?
• Unter welchem Konto läuft ein Prozess?
• Welche DLL wurde aus einem unerwarteten Pfad geladen?
• Welcher Thread erzeugt hohe CPU-Last?
• Stimmen Dateiname, Pfad und Herausgeber zusammen?
• Ist ein Prozess mehrfach vorhanden?
• Läuft ein Prozess mit erhöhten Rechten?

Prozessfarben

Process Explorer kann unterschiedliche Prozesstypen farblich kennzeichnen. Die genaue Bedeutung hängt von der konfigurierten Farbauswahl ab und sollte über die Programmeinstellungen kontrolliert werden.

Eine Farbe oder ein nicht verifizierter Signaturstatus ist kein automatischer Malware-Nachweis.

Wenn eine Datei nicht gelöscht, verschoben oder ersetzt werden kann, kann ein geöffneter Handle dafür verantwortlich sein.

Vorgehensweise

1. Process Explorer starten.
2. Find öffnen.
3. Find Handle or DLL auswählen.
4. eindeutigen Teil des Datei- oder Verzeichnisnamens eingeben.
5. Treffer und zugehörigen Prozess prüfen.
6. Anwendung möglichst regulär schließen.
7. Dateioperation erneut testen.

Nicht als erste Maßnahme verwenden

• Prozess sofort beenden
• Handle direkt schließen
• Dienst ungeprüft stoppen
• Systemprozess beenden
• Datei mit Gewalt löschen

Das direkte Schließen eines Handles kann den Zustand der Anwendung beschädigen, Datenverlust verursachen oder zu einem späteren Absturz führen.

Die sichere Lösung besteht normalerweise darin, die verursachende Anwendung oder den zugehörigen Dienst kontrolliert zu beenden.

Handle zeigt offene Handles von Prozessen an. Damit kann unter anderem ermittelt werden, welcher Prozess eine bestimmte Datei oder ein Verzeichnis verwendet.

Nach einem Dateinamen suchen

[RO][PRIV][SENS] handle.exe "<DATEINAME>"

Beispiel

[RO][PRIV][SENS] handle.exe "datenbank.db"

Handles eines bestimmten Prozesses anzeigen

[RO][PRIV][SENS] handle.exe -p <PID>

Ausgabe ohne Banner

[RO][PRIV][SENS] handle.exe -nobanner "<SUCHBEGRIFF>"

Handle schließen

[CHANGE][PRIV][DANGER] handle.exe -c <HANDLE-ID> -p <PID>

Das erzwungene Schließen eines Handles kann Daten beschädigen oder einen Prozess destabilisieren. Diese Funktion darf nur verwendet werden, wenn Objekt, Prozess, Abhängigkeiten und Auswirkungen eindeutig bekannt sind.

Process Monitor, kurz Procmon, zeichnet in Echtzeit unter anderem folgende Aktivitäten auf:

• Dateisystemzugriffe
• Registryzugriffe
• Prozessstarts und Prozessbeendigungen
• Threadaktivitäten
• Laden von DLLs und Images
• Profilierungsereignisse
• Prozess-, Benutzer- und Sitzungsinformationen
• zugehörige Aufrufstapel

Starten

[TEST][PRIV][SENS] procmon.exe

Process Monitor beginnt normalerweise unmittelbar mit der Aufzeichnung. Deshalb sollte die Aufzeichnung zunächst angehalten und gezielt vorbereitet werden.

Empfohlene Grundreihenfolge

1. Process Monitor starten.
2. Aufzeichnung anhalten.
3. bestehende Ereignisse leeren.
4. passende Filter festlegen.
5. Aufzeichnung starten.
6. Fehler möglichst genau reproduzieren.
7. Aufzeichnung sofort wieder anhalten.
8. relevante Ereignisse untersuchen.
9. Aufzeichnung im nativen PML-Format sichern.
10. sensible Inhalte vor einer Weitergabe prüfen.

Typische Filter

Process Monitor zeichnet sehr viele normale und erwartete Vorgänge auf. Einzelne Meldungen wie NAME NOT FOUND, PATH NOT FOUND oder ACCESS DENIED sind nicht automatisch Fehlerursachen.

Häufige Ergebnisse

Bewertungsfragen

• Gehört das Ereignis zum betroffenen Prozess?
• Liegt es unmittelbar vor dem sichtbaren Fehler?
• Wird nach einem fehlgeschlagenen Zugriff ein anderer Pfad erfolgreich verwendet?
• Wiederholt sich das Ereignis ungewöhnlich häufig?
• Ist der Pfad laut Anwendung tatsächlich erforderlich?
• Welcher Benutzer führt den Zugriff aus?
• Welche Berechtigungen gelten für das Objekt?
• Handelt es sich um eine optionale Suche der Anwendung?
• Gibt es einen zugehörigen Stack oder Folgefehler?
• Tritt das Verhalten auf einem funktionierenden Vergleichssystem ebenfalls auf?

Wichtiger Grundsatz

Viele Programme suchen nacheinander an mehreren Stellen nach Dateien oder Registrywerten. Mehrere fehlgeschlagene Suchvorgänge können deshalb völlig normal sein, wenn anschließend ein erfolgreicher Treffer erfolgt.

Process Monitor unterstützt Befehlszeilenoptionen für reproduzierbare Aufzeichnungen.

Lizenzdialog vorab akzeptieren

[CHANGE] procmon.exe /AcceptEula

Aufzeichnung mit Sicherungsdatei starten

[TEST][PRIV][SENS] procmon.exe /AcceptEula /Quiet /BackingFile "C:\Diagnose\trace.pml"

Laufende Process-Monitor-Instanz beenden

[CHANGE][PRIV] procmon.exe /Terminate

Gespeicherte PML-Datei als CSV exportieren

[RO][SENS] procmon.exe /OpenLog "C:\Diagnose\trace.pml" /SaveAs "C:\Diagnose\trace.csv"

Bootaufzeichnung

Process Monitor besitzt eine Boot-Logging-Funktion, mit der Aktivitäten während des Systemstarts erfasst werden können. Diese muss über die Programmoberfläche oder passend geplante Optionen kontrolliert aktiviert und anschließend wieder beendet werden.

Bootaufzeichnungen können sehr groß werden und sensible Systeminformationen enthalten. Sie dürfen nicht unbegrenzt aktiviert bleiben.

Autoruns zeigt deutlich mehr Autostartorte als die einfache Autostartansicht des Task-Managers.

Dazu können gehören:

• Anmeldeautostarts
• Dienste
• Treiber
• geplante Aufgaben
• Explorer-Erweiterungen
• Winlogon-Komponenten
• Boot-Execute-Einträge
• Codecs
• AppInit-DLLs
• Image Hijacks
• Office-Erweiterungen
• Winsock-Komponenten
• bekannte Registry-Autostartorte
• Startordner verschiedener Benutzer

Starten

[RO][PRIV][SENS] autoruns.exe

Wichtige Funktionen

Sicheres Deaktivieren

Ein Kontrollkästchen kann deaktiviert werden, um einen Autostart vorübergehend abzuschalten. Das ist in der Regel besser reversibel als das sofortige Löschen des Eintrags.

Eintrag deaktivieren
→ System oder Anwendung kontrolliert testen
→ Ergebnis dokumentieren
→ Eintrag bei ausbleibender Wirkung wieder aktivieren

Ein unbekannter oder nicht signierter Autostarteintrag ist nicht automatisch schädlich. Vor einer Änderung müssen Pfad, Herausgeber, Signatur, Zweck, Abhängigkeiten und betroffene Anwendung geprüft werden.

Autorunsc ist die Befehlszeilenversion von Autoruns und eignet sich für dokumentierbare Bestandsaufnahmen.

Grundlegende Ausgabe

[RO][PRIV][SENS] autorunsc.exe -a * -c -h -s

Dabei können abhängig von der Werkzeugversion und den gewählten Optionen unter anderem Autostartkategorie, Pfad, Signatur und Hash ausgegeben werden.

CSV-Datei erzeugen

[RO][PRIV][SENS] autorunsc.exe -a * -c -h -s > "C:\Diagnose\autoruns.csv"

Nur Microsoft-Einträge ausblenden

[RO][PRIV][SENS] autorunsc.exe -a * -m -c -h -s

Vor einer produktiven Erfassung prüfen

[RO] autorunsc.exe /?

Die verfügbaren Parameter können sich mit Werkzeugversionen verändern. Vor automatisierter Verwendung muss die Hilfe der tatsächlich eingesetzten Version geprüft werden.

Mehrere Sysinternals-Werkzeuge können Hashwerte oder Dateien mit VirusTotal abgleichen.

Dabei muss unterschieden werden zwischen:

• Übermittlung eines Hashwertes
• Abfrage eines bereits bekannten Ergebnisses
• Hochladen einer unbekannten Datei
• automatischer Übermittlung unbekannter Dateien

Mögliche Risiken

• interne Dateinamen werden offengelegt
• proprietäre Anwendungen werden hochgeladen
• Konfigurationsdateien enthalten Geschäftsgeheimnisse
• Dateien enthalten personenbezogene Daten
• Skripte enthalten Servernamen oder Zugangsdaten
• Upload verstößt gegen Unternehmensrichtlinien

Die Übermittlung einer internen Datei an einen externen Analysedienst darf nicht automatisch erfolgen. Vorher müssen Datenschutz, Geheimhaltung, Eigentumsrechte und Sicherheitsvorgaben geprüft werden.

Ein VirusTotal-Ergebnis ist außerdem kein alleiniger Beweis:

• einzelne Erkennung kann ein Fehlalarm sein
• keine Erkennung schließt Schadsoftware nicht aus
• Bewertung kann sich später ändern
• signierte Dateien können trotzdem missbraucht werden

TCPView zeigt aktive TCP- und UDP-Endpunkte mit den zugehörigen Prozessen an.

Starten

[RO][PRIV][SENS] tcpview.exe

Typische Informationen

• Prozessname
• PID
• Protokoll
• lokale Adresse
• lokaler Port
• entfernte Adresse
• Remoteport
• TCP-Zustand
• gesendete und empfangene Daten
• Erstellungszeitpunkt einer Verbindung

Typische Anwendungsfälle

• Welcher Prozess verbindet sich mit einem Server?
• Welcher Prozess lauscht auf einem Port?
• Warum existieren unerwartet viele Verbindungen?
• Welche Remoteadresse verwendet eine Anwendung?
• Ist der erwartete Dienstport geöffnet?
• Welche Verbindung wird beim Start einer Anwendung aufgebaut?

Befehlszeilenversion

[RO][PRIV][SENS] tcpvcon.exe -a -c

Vor der Verwendung sollte die lokale Hilfe geprüft werden:

[RO] tcpvcon.exe /?

Eine Verbindung zu einer unbekannten IP-Adresse ist kein automatischer Sicherheitsvorfall. Content-Delivery-Netzwerke, Cloudplattformen, Telemetrie, Updates, Proxys und gemeinsam genutzte Infrastrukturen können die Zuordnung erschweren.

RAMMap zeigt, wie Windows den physischen Arbeitsspeicher verwendet.

Starten

[RO][PRIV][SENS] rammap.exe

Wichtige Ansichten

Wichtige Speicherbegriffe

Bewertungsregeln

• Wenig vollständig freier RAM ist nicht automatisch problematisch.
• Windows nutzt freien Speicher gezielt als Cache.
• Ein großer Standby-Bereich kann normal sein.
• Hohe Commit-Nutzung muss zusammen mit Commit-Limit und Auslagerungsdatei bewertet werden.
• Ein ungewöhnlich großer nicht ausgelagerter Pool kann auf einen Treiberfehler hindeuten.
• Ein einzelner Snapshot beweist noch kein Speicherleck.

RAMMap enthält Funktionen zum Leeren bestimmter Speicherlisten. Diese verändern den Speicherzustand und können die Leistung vorübergehend verschlechtern.

Speicherlisten dürfen nicht routinemäßig geleert werden, nur um eine niedrigere RAM-Anzeige zu erzeugen. Dadurch wird die Ursache eines Speicherproblems nicht behoben.

VMMap analysiert den virtuellen und physischen Speicher eines einzelnen Prozesses.

Starten

[RO][PRIV][SENS] vmmap.exe

Anschließend wird ein laufender Prozess ausgewählt oder eine Anwendung durch VMMap gestartet.

Untersuchte Speicherarten

• Image
• Heap
• Stack
• Private Data
• Shareable
• Mapped File
• Page Table
• Managed Heap
• reservierter Adressraum
• zugesicherter Speicher
• Working Set

Typische Anwendungsfälle

• wächst der private Speicher fortlaufend?
• welcher Heap wächst?
• besitzt der Prozess ungewöhnlich viele Speicherabbildungen?
• wird viel Adressraum nur reserviert?
• wie unterscheiden sich zwei Zustände desselben Prozesses?
• entsteht der Speicherverbrauch im nativen oder verwalteten Bereich?

Sinnvolle Vorgehensweise bei vermutetem Speicherleck

1. Anwendung in einem definierten Ausgangszustand starten.
2. ersten VMMap-Snapshot erfassen.
3. reproduzierbare Aktion mehrfach ausführen.
4. zweiten Snapshot erfassen.
5. Snapshots vergleichen.
6. wachsende Speichertypen identifizieren.
7. Ergebnis mit Prozessmetriken, Dumps und Anwendungsprotokollen abgleichen.

Ein wachsender Working Set allein beweist kein Speicherleck. Caches und noch erreichbare, später freigegebene Daten können ebenfalls wachsen.

ProcDump kann Speicherabbilder eines Prozesses erzeugen, wenn festgelegte Bedingungen eintreten.

Mögliche Auslöser sind unter anderem:

• unbehandelte Ausnahme
• Prozessabsturz
• hohe CPU-Auslastung
• niedrige CPU-Auslastung
• nicht reagierendes Fenster
• bestimmter Leistungsindikator
• manuell angeforderter Dump
• Prozessstart

Hilfe der installierten Version anzeigen

[RO] procdump.exe -?

Manuelles vollständiges Speicherabbild eines Prozesses

[TEST][PRIV][SENS] procdump.exe -ma <PID> "C:\Diagnose"

Auf Prozessnamen warten und vollständigen Dump bei Ausnahme erzeugen

[TEST][PRIV][SENS] procdump.exe -ma -e -w "<PROZESSNAME.exe>" "C:\Diagnose"

Dump bei nicht reagierendem Fenster

[TEST][PRIV][SENS] procdump.exe -ma -h "<PROZESSNAME.exe>" "C:\Diagnose"

Überwachung beenden

Die betreffende ProcDump-Instanz muss kontrolliert beendet werden, wenn die Diagnose abgeschlossen ist.

Wichtige Planungsfragen

• Wie viele Dumps dürfen entstehen?
• Wie groß kann jeder Dump werden?
• Ist ausreichend Speicherplatz vorhanden?
• Tritt der Fehler in einem sensiblen Prozess auf?
• Wer darf die Dumps lesen?
• Wie lange werden sie gespeichert?
• Welcher Debugger wird zur Analyse verwendet?

Vollständige Prozessabbilder können Passwörter, Tokens, Schlüssel, Dokumentinhalte, Datenbanksätze und andere Geheimnisse enthalten. Sie müssen wie hochsensible Daten geschützt werden.

System Monitor, kurz Sysmon, ist ein Windows-Systemdienst mit Gerätetreiber. Nach der Installation protokolliert er ausgewählte Systemaktivitäten in das Windows-Ereignisprotokoll.

Sysmon kann abhängig von Version und Konfiguration unter anderem erfassen:

• Prozessstarts
• Prozessbeendigungen
• Netzwerkverbindungen
• Erstellung von Dateien
• Änderung von Dateierstellungszeiten
• Laden von Treibern
• Laden von Images und DLLs
• Zugriffe auf Prozesse
• Registryereignisse
• Named Pipes
• DNS-Abfragen
• WMI-Aktivitäten
• Zwischenablageänderungen
• Dateilöschungen
• ausführbare Dateien in bestimmten Ereignissen
• Änderungen an Sysmon selbst

Wichtiger Speicherort

Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ Sysmon
→ Operational

Sysmon mit Konfiguration installieren

[CHANGE][PRIV] sysmon.exe -accepteula -i "C:\Konfiguration\sysmon-config.xml"

Konfiguration aktualisieren

[CHANGE][PRIV] sysmon.exe -c "C:\Konfiguration\sysmon-config.xml"

Aktuelle Konfiguration anzeigen

[RO][PRIV][SENS] sysmon.exe -c

Sysmon deinstallieren

[CHANGE][PRIV] sysmon.exe -u

Sysmon besitzt keine automatische Alarmierungs- oder Bewertungslogik. Die Ereignisse müssen durch geeignete Regeln, ein SIEM, ein EDR-System oder eine kontrollierte manuelle Analyse ausgewertet werden.

Eine Sysmon-Konfiguration bestimmt, welche Ereignisse einbezogen oder ausgeschlossen werden.

Ziele einer guten Konfiguration

• relevante Sicherheitsereignisse erfassen
• unnötige Ereignismengen begrenzen
• wichtige Systemprogramme nicht pauschal ausblenden
• Regeln dokumentieren
• Konfigurationsänderungen versionieren
• Speicherbedarf und Ereignisrate überwachen
• Auswertung durch SIEM oder Monitoring berücksichtigen

Risiken einer ungeprüften Konfiguration

• zu viele Ereignisse überlasten Sammlung und Auswertung
• zu breite Ausschlüsse erzeugen blinde Flecken
• sensible Befehlszeilen werden zentral gespeichert
• DNS-Abfragen offenbaren Benutzeraktivitäten
• Dateipfade enthalten personenbezogene Daten
• Regeländerungen beeinflussen Erkennungsmechanismen
• unterschiedliche Systeme benötigen unterschiedliche Filter

Beispiel einer minimalen XML-Grundstruktur

<Sysmon schemaversion="<SCHEMA-VERSION>">
  <EventFiltering>
    <ProcessCreate onmatch="include">
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

Die erforderliche Schemaversion und die unterstützten Ereignisse müssen mit der tatsächlich verwendeten Sysmon-Version geprüft werden.

Konfigurationsschema anzeigen

[RO] sysmon.exe -s

Eine fremde Sysmon-Konfiguration sollte nicht ungeprüft in einer produktiven Umgebung übernommen werden. Sie muss an Systeme, Anwendungen, Datenschutz, Ereignissammlung und Erkennungsziele angepasst werden.

Sigcheck zeigt Datei- und Signaturinformationen an.

Einzelne Datei untersuchen

[RO][SENS] sigcheck.exe -a -h -i "<DATEI>"

Verzeichnis rekursiv untersuchen

[RO][SENS] sigcheck.exe -s -a -h "<VERZEICHNIS>"

Nicht signierte Dateien suchen

[RO][SENS] sigcheck.exe -u -e "<VERZEICHNIS>"

CSV-Ausgabe

[RO][SENS] sigcheck.exe -c -h "<DATEI>"

Typische Prüfungen

• Herausgeber stimmt mit erwarteter Software überein
• Signaturstatus ist gültig
• Dateipfad ist plausibel
• Produkt- und Dateiversion passen zusammen
• Hash stimmt mit einer bekannten Referenz überein
• Datei wurde nicht aus einem temporären oder Benutzerverzeichnis nachgeladen

Auch legitime Programme können unsignierte Komponenten besitzen. Umgekehrt kann eine gültig signierte Datei für unerwünschte Zwecke missbraucht oder mit einem kompromittierten Zertifikat signiert worden sein.

ListDLLs zeigt geladene DLLs und deren Pfade an.

Alle geladenen DLLs anzeigen

[RO][PRIV][SENS] listdlls.exe

DLLs eines bestimmten Prozesses

[RO][PRIV][SENS] listdlls.exe <PID>

Alternativ kann nach einem Prozessnamen gefiltert werden:

[RO][PRIV][SENS] listdlls.exe "<PROZESSNAME>"

Nach einer bestimmten DLL suchen

[RO][PRIV][SENS] listdlls.exe -d "<DLL-NAME>"

Typische Auffälligkeiten

• DLL aus einem unerwarteten Benutzerverzeichnis
• mehrere Versionen derselben Komponente
• DLL aus einem temporären Verzeichnis
• fehlende oder ungültige Signatur
• Prozess lädt nicht die erwartete Bibliothek
• unerwartete Drittanbieter-Erweiterung

Der Dateiname allein ist nicht ausreichend. Pfad, Version, Signatur, Hash, Ladegrund und Anwendungskontext müssen gemeinsam bewertet werden.

Strings extrahiert lesbare ANSI- und Unicode-Zeichenfolgen aus Binärdateien.

Datei untersuchen

[RO][SENS] strings.exe "<DATEI>"

Mindestlänge festlegen

[RO][SENS] strings.exe -n 8 "<DATEI>"

Ausgabe nach einem Begriff filtern

[RO][SENS] strings.exe -n 8 "<DATEI>" | findstr /i "<SUCHBEGRIFF>"

Mögliche Anwendungsfälle

• eingebettete URLs finden
• Fehlermeldungen erkennen
• Dateipfade finden
• Produkt- oder Debuginformationen erkennen
• verdächtige Befehlszeilen entdecken
• Hinweise auf eingebettete Konfigurationen erhalten

Einschränkungen

• komprimierte oder verschlüsselte Inhalte werden nicht automatisch verständlich
• gefundene Zeichenfolge muss nicht ausgeführt oder verwendet werden
• zufällige Bytefolgen können wie Text aussehen
• Ausgabe kann Zugangsdaten oder andere Geheimnisse enthalten

Strings ist ein Hinweiswerkzeug und kein vollständiges Verfahren zur Malwareanalyse oder zum Reverse Engineering.

NTFS-Dateien können neben dem normalen Dateiinhalt alternative Datenströme besitzen. Windows verwendet solche Datenströme unter anderem für Herkunftsinformationen heruntergeladener Dateien.

Datenströme anzeigen

[RO][SENS] streams.exe "<DATEI>"

Verzeichnis rekursiv untersuchen

[RO][SENS] streams.exe -s "<VERZEICHNIS>"

Alternative Datenströme löschen

[CHANGE][DANGER] streams.exe -d "<DATEI-ODER-VERZEICHNIS>"

Das pauschale Löschen alternativer Datenströme kann Sicherheitskennzeichnungen wie Herkunftsinformationen entfernen und dadurch Schutzfunktionen beeinflussen. Vorher müssen Inhalt, Zweck und Auswirkungen geprüft werden.

PowerShell kann Datenströme ebenfalls anzeigen:

[RO][SENS] Get-Item "<DATEI>" -Stream *

AccessChk zeigt Zugriffsrechte auf verschiedene Windows-Objekte an.

Dazu gehören unter anderem:

• Dateien
• Verzeichnisse
• Registryschlüssel
• Dienste
• Prozesse
• Kernelobjekte
• Freigaben
• benannte Pipes

Hilfe anzeigen

[RO] accesschk.exe /?

Verzeichnisrechte untersuchen

[RO][PRIV][SENS] accesschk.exe -d "<VERZEICHNIS>"

Rechte eines bestimmten Kontos prüfen

[RO][PRIV][SENS] accesschk.exe -d "<BENUTZER-ODER-GRUPPE>" "<VERZEICHNIS>"

Dienstrechte untersuchen

[RO][PRIV][SENS] accesschk.exe -c "<DIENSTNAME>"

Typische Anwendungsfälle

• besitzt ein Benutzer tatsächlich Schreibzugriff?
• darf eine Gruppe einen Dienst konfigurieren?
• existieren übermäßig weitreichende Rechte?
• unterscheidet sich der Benutzerkontext vom Administratorkontext?
• ist ein sensibles Verzeichnis für normale Benutzer beschreibbar?

AccessChk-Ausgaben müssen zusammen mit Vererbung, Gruppenmitgliedschaften, Integritätsstufe, Privilegien, Freigaberechten und dem tatsächlichen Benutzerkontext bewertet werden.

AccessEnum

AccessEnum stellt Berechtigungen für Dateien, Verzeichnisse und Registrybereiche übersichtlich dar. Es kann helfen, Abweichungen innerhalb größerer Strukturen zu finden.

[RO][PRIV][SENS] accessenum.exe

Typische Verwendung:

• Verzeichnis oder Registrybereich auswählen
• Berechtigungen erfassen
• auffällige Abweichungen untersuchen
• Zustand speichern
• späteren Zustand vergleichen

ShareEnum

ShareEnum untersucht SMB-Freigaben und deren Sicherheitseinstellungen innerhalb erreichbarer Netzwerkbereiche.

[RO][PRIV][REMOTE][SENS] shareenum.exe

Zu prüfen sind unter anderem

• unerwartete Freigaben
• zu breite Freigabeberechtigungen
• administrative Freigaben
• erreichbare Systeme
• Kombination aus Freigabe- und NTFS-Rechten
• nicht mehr benötigte Freigaben

ShareEnum darf nur in ausdrücklich freigegebenen Netzwerkbereichen verwendet werden. Eine technische Erreichbarkeit ist keine Berechtigung zum Scannen.

PsTools ist eine Sammlung von Befehlszeilenwerkzeugen für lokale und entfernte Windows-Systeme.

Wichtige Werkzeuge

Systeminformationen lokal abrufen

[RO][SENS] psinfo.exe

Systeminformationen remote abrufen

[RO][REMOTE][SENS] psinfo.exe \\<COMPUTER>

Prozesse remote anzeigen

[RO][REMOTE][SENS] pslist.exe \\<COMPUTER>

Angemeldete Benutzer untersuchen

[RO][REMOTE][SENS] psloggedon.exe \\<COMPUTER>

PsTools können administrative Remoteaktionen ausführen. Authentifizierung, Firewall, administrative Freigaben, Sicherheitsrichtlinien, Protokollierung und Auswirkungen auf das Zielsystem müssen vorher geklärt werden.

PsExec kann Prozesse lokal oder auf entfernten Windows-Systemen starten.

Remote-Befehlszeile starten

[CHANGE][PRIV][REMOTE][SENS] psexec.exe \\<COMPUTER> cmd.exe

Befehl remote ausführen

[CHANGE][PRIV][REMOTE][SENS] psexec.exe \\<COMPUTER> ipconfig /all

Prozess als lokales Systemkonto starten

[CHANGE][PRIV][DANGER] psexec.exe -s -i cmd.exe

Der letzte Befehl erzeugt einen besonders privilegierten Kontext und darf nur für klar begründete administrative Diagnosen verwendet werden.

Sicherheitsregeln

• keine Passwörter offen in der Befehlszeile übergeben
• nur eindeutig bestimmten Zielcomputer verwenden
• aktiven Benutzer und Auswirkungen prüfen
• keine interaktive Sitzung unbeaufsichtigt lassen
• erzeugte Dienste und Prozesse kontrollieren
• Remotezugriff protokollieren
• keine dauerhafte Umgehung regulärer Verwaltungswege
• Befehle zunächst lokal oder in einer Testumgebung prüfen

Anmeldeinformationen in einer Befehlszeile können in Prozesslisten, Protokollen, Shellverläufen oder Diagnoseaufzeichnungen sichtbar werden.

PsPing erweitert einfache Ping-Tests um TCP-Verbindungs-, Latenz- und Durchsatzmessungen.

ICMP-Test

[TEST][SENS] psping.exe <ZIEL>

TCP-Port testen

[TEST][SENS] psping.exe <ZIEL>:<PORT>

Beispiel:

[TEST][SENS] psping.exe server.example:443

Längere Messung

[TEST][SENS] psping.exe -n 20 server.example:443

Für Bandbreitenmessungen ist eine passende PsPing-Instanz als Empfänger erforderlich. Die genauen Parameter müssen anhand der Hilfe der eingesetzten Version gewählt werden:

[RO] psping.exe /?

Bewertungsregeln

• TCP-Erreichbarkeit bestätigt nicht die korrekte Anwendung.
• Durchsatztests erzeugen zusätzliche Netzlast.
• Messergebnisse hängen von Gegenstelle, Route und Systemlast ab.
• kurze Tests können sporadische Störungen übersehen.
• Sicherheitssoftware kann Testverbindungen blockieren.
• Tests gegen fremde Systeme benötigen eine Freigabe.

AD Explorer ist ein grafischer Viewer und Editor für Active Directory.

Das Werkzeug kann:

• AD-Objekte durchsuchen
• Attribute anzeigen
• Objekteigenschaften untersuchen
• Suchabfragen speichern
• Snapshots einer AD-Datenbank erstellen
• zwei Snapshots vergleichen
• zugehörige Sicherheitsinformationen anzeigen

Starten

[RO][PRIV][REMOTE][SENS] adexplorer.exe

Typische Anwendungsfälle

• Attribut eines Benutzers oder Computers prüfen
• Gruppenmitgliedschaften nachvollziehen
• Distinguished Name kontrollieren
• Replikations- oder Änderungsstände vergleichen
• Objekte anhand bestimmter Attribute suchen
• Zustand vor und nach einer administrativen Änderung vergleichen

Risiken

AD Explorer kann nicht nur lesen, sondern bei ausreichenden Rechten auch Objekte verändern. Ein versehentliches Ändern oder Löschen kann Domänendienste und Anwendungen beeinträchtigen.

Für reine Diagnosezwecke sollte nach Möglichkeit ein Konto mit nur den notwendigen Leserechten verwendet werden.

Snapshots können enthalten:

• Benutzernamen
• Gruppenstrukturen
• Computernamen
• E-Mail-Adressen
• organisatorische Strukturen
• sicherheitsrelevante Attribute
• interne Server- und Domäneninformationen

Sie müssen entsprechend geschützt werden.

AD Insight

AD Insight überwacht LDAP-Clientaufrufe eines Prozesses und kann helfen, Active-Directory-Kommunikation einer Anwendung zu untersuchen.

Typische Fragen:

• Welche LDAP-Abfrage führt die Anwendung aus?
• Welcher Domänencontroller wird angesprochen?
• Welche Attribute werden angefordert?
• Welche LDAP-Fehler treten auf?
• Wiederholt eine Anwendung unnötig viele Abfragen?

[TEST][PRIV][SENS] adinsight.exe

Die Aufzeichnung kann sehr viele interne Verzeichnisinformationen enthalten.

AD Restore

AD Restore kann gelöschte Active-Directory-Objekte untersuchen und in unterstützten Fällen wiederherstellen.

[RO][PRIV][SENS] adrestore.exe

Eine tatsächliche Wiederherstellung verändert Active Directory:

[CHANGE][PRIV][DANGER]

AD Restore darf nicht ohne Kenntnis von AD-Papierkorb, Tombstone-Zustand, Replikation, Objektabhängigkeiten, Wiederherstellungsziel und organisatorischer Freigabe eingesetzt werden.

Coreinfo zeigt die Zuordnung logischer Prozessoren sowie unterstützte Prozessor- und Virtualisierungsfunktionen an.

Starten

[RO] coreinfo.exe

Virtualisierungsbezogene Informationen

[RO] coreinfo.exe -v

Typische Anwendungsfälle

• unterstützt die CPU benötigte Virtualisierungsfunktionen?
• sind Funktionen durch Firmware oder Hypervisor beeinflusst?
• wie sind logische Prozessoren, Kerne und NUMA-Knoten zugeordnet?
• stehen benötigte Befehlssatzerweiterungen zur Verfügung?
• unterscheidet sich ein System von einem funktionierenden Vergleichssystem?

Die Anzeige einer CPU-Funktion beweist nicht automatisch, dass sie von Firmware, Betriebssystem, Hypervisor und Anwendung vollständig nutzbar ist.

BgInfo kann technische Systeminformationen in den Desktophintergrund einblenden.

Mögliche Angaben:

• Computername
• IP-Adresse
• Betriebssystemversion
• Domäne
• Benutzer
• letzter Startzeitpunkt
• Prozessor
• Arbeitsspeicher
• freier Speicherplatz
• benutzerdefinierte Werte

Starten

[RO][SENS] bginfo.exe

BgInfo eignet sich beispielsweise für:

• Schulungs- und Testsysteme
• Serverkonsolen
• virtuelle Maschinen
• schnelle Identifikation eines Zielsystems
• kontrollierte Supportumgebungen

Datenschutz beachten

Auf gemeinsam betrachteten Desktops dürfen keine unnötigen sensiblen Angaben angezeigt werden. Dazu gehören beispielsweise:

• öffentliche IP-Adressen
• interne Domänenstrukturen
• personenbezogene Benutzerdaten
• geheime Systemkennungen
• vertrauliche Inventarnummern

BgInfo ist eine Anzeigehilfe und kein Werkzeug zur laufenden Zustandsüberwachung.

Disk2vhd erstellt virtuelle Festplattendateien aus Volumes eines laufenden Windows-Systems. Dafür kann der Volumeschattenkopie-Dienst verwendet werden, um einen konsistenteren Zeitpunkt abzubilden.

Starten

[TEST][PRIV][SENS] disk2vhd.exe

Mögliche Anwendungsfälle

• Testkopie eines Systems erstellen
• System für eine kontrollierte Analyse virtualisieren
• physisches System in eine virtuelle Testumgebung überführen
• Zustand eines Systems vor umfangreicher Analyse sichern

Wichtige Grenzen

• eine VHD- oder VHDX-Datei ist nicht automatisch ein vollständiges Backupkonzept
• laufende Anwendungen können zusätzliche Konsistenzanforderungen besitzen
• Datenbanken benötigen möglicherweise anwendungsspezifische Sicherung
• verschlüsselte Volumes müssen gesondert berücksichtigt werden
• Aktivierung und Lizenzierung können sich in einer VM verändern
• virtuelle Kopie darf nicht unkontrolliert parallel im produktiven Netzwerk starten
• gespeicherte Anmeldeinformationen bleiben möglicherweise enthalten
• die Datei kann nahezu alle Daten des Quellsystems enthalten

Eine virtualisierte Kopie eines Produktivsystems muss isoliert gestartet werden, damit keine doppelten Computerkonten, IP-Adressen, Dienste oder automatischen Aufgaben das Produktivnetz beeinflussen.

LiveKd ermöglicht die Untersuchung eines laufenden Windows-Systems mit Microsoft-Kerneldebuggern, ohne die klassische Remote-Debuggingverbindung zu einem zweiten Computer aufzubauen.

Starten

[TEST][PRIV][SENS] livekd.exe

Je nach Konfiguration wird ein kompatibler Microsoft-Debugger benötigt.

Mögliche Anwendungsfälle

• Kernelstrukturen untersuchen
• Treiberzustände betrachten
• Kernelstacks analysieren
• Speicher- und Objektinformationen prüfen
• Livezustand mit Debuggerbefehlen untersuchen

Grenzen

• das System verändert sich während der Untersuchung weiter
• Daten können zwischen Abfragen inkonsistent werden
• falsche Interpretation von Kernelstrukturen ist möglich
• Symbole müssen zur Systemversion passen
• Debuggerzugriff kann hochsensible Informationen offenlegen

LiveKd ist ein spezialisiertes Werkzeug für fortgeschrittene Windows- und Treiberanalyse. Es sollte nicht ohne Debuggingkenntnisse auf produktiven Systemen eingesetzt werden.

WinObj zeigt den Namensraum des Windows-Objektmanagers.

Darin können unter anderem sichtbar sein:

• Geräteobjekte
• symbolische Links
• Sessions
• Treiberobjekte
• Named Pipes
• BaseNamedObjects
• Dateisystemobjekte
• Kernelobjekte

Starten

[RO][PRIV][SENS] winobj.exe

Typische Anwendungsfälle

• symbolische Objektverknüpfungen untersuchen
• Gerätedateien und Treiberobjekte nachvollziehen
• benannte Synchronisationsobjekte finden
• Unterschiede zwischen Sitzungen erkennen
• interne Objektpfade einer Anwendung prüfen

WinObj zeigt interne Windows-Objekte. Die bloße Existenz eines unbekannten Objekts ist kein Beweis für einen Fehler oder eine Kompromittierung.

Wenn Dateien während des laufenden Betriebs nicht ersetzt oder gelöscht werden können, kann Windows Operationen für den nächsten Systemstart vormerken.

Ausstehende Operationen anzeigen

[RO][PRIV][SENS] pendmoves.exe

Datei beim nächsten Neustart verschieben

[CHANGE][PRIV][RESTART] movefile.exe "<QUELLE>" "<ZIEL>"

Datei beim nächsten Neustart löschen

[CHANGE][PRIV][RESTART][DANGER] movefile.exe "<DATEI>" ""

Risiken

• falsche Systemdatei wird entfernt
• Anwendung startet nach Neustart nicht mehr
• Treiber oder Dienst fällt aus
• Abhängigkeiten werden erst nach Neustart sichtbar
• Rücknahme ist nach dem Start möglicherweise schwierig

Vor dem Vormerken einer Löschung müssen Datei, Hersteller, Signatur, Anwendung, Wiederherstellungsweg und Auswirkungen eindeutig geklärt sein.

SDelete kann Dateien oder freien Speicherplatz überschreiben, um die Wiederherstellung gelöschter Daten zu erschweren.

Hilfe anzeigen

[RO] sdelete.exe /?

Datei sicher löschen

[CHANGE][PRIV][DANGER] sdelete.exe "<DATEI>"

Freien Speicherplatz bearbeiten

[CHANGE][PRIV][DANGER] sdelete.exe -c <LAUFWERK>

Wichtige Einschränkungen

• SSDs besitzen Wear-Leveling und interne Speicherverwaltung
• Speichercontroller können Daten umorganisieren
• virtuelle Datenträger besitzen zusätzliche Speicherschichten
• Snapshots und Backups bleiben unberührt
• Cloud- und SAN-Speicher abstrahieren die physische Ablage
• falscher Zielpfad kann nicht einfach rückgängig gemacht werden

SDelete ist keine allgemeine Fehlerbehebungsmaßnahme. Vor dem Einsatz müssen Datenträgertyp, Sicherungen, Snapshots, Aufbewahrungspflichten und Löschkonzept geprüft werden.

NotMyFault kann absichtlich:

• Systemabstürze auslösen
• Systeme aufhängen
• Kernel-Speicherlecks erzeugen
• Treiberfehler simulieren
• hohe Last erzeugen

Das Werkzeug dient beispielsweise zum Testen von:

• Speicherabbildkonfiguration
• Überwachungssystemen
• Wiederanlaufverhalten
• Absturzanalysen
• Laborübungen

[DANGER][PRIV][RESTART] notmyfault.exe

NotMyFault darf niemals auf einem produktiven System, einem gemeinsam genutzten Schulungssystem oder einem nicht vollständig isolierten Testsystem ausprobiert werden. Es verursacht absichtlich schwerwiegende Störungen.

Vor einem Test müssen mindestens vorhanden sein:

• isolierte virtuelle Maschine
• aktueller Snapshot oder definierter Wiederherstellungsweg
• keine produktiven Daten
• kein Zugang zum Produktivnetz
• dokumentiertes Testszenario
• Kontrolle über Neustart und Speicherabbilder
• ausreichend Speicherplatz
• ausdrückliche Freigabe

1. Originale Fehlermeldung erfassen.
2. Fehlerzeitpunkt dokumentieren.
3. betroffenen Computer und Benutzer bestätigen.
4. Reproduzierbarkeit prüfen.
5. integrierte Windows-Protokolle untersuchen.
6. kleinstes passende Sysinternals-Werkzeug auswählen.
7. Werkzeugquelle, Version und Signatur kontrollieren.
8. Berechtigungsbedarf prüfen.
9. mögliche sensible Daten berücksichtigen.
10. Aufzeichnung vorbereiten.
11. Filter möglichst eng festlegen.
12. Ausgangszustand dokumentieren.
13. Aufzeichnung starten.
14. Fehler einmal reproduzieren.
15. Aufzeichnung unmittelbar beenden.
16. Ereignisse zeitlich eingrenzen.
17. Prozess, Pfad, Benutzer, Operation und Ergebnis vergleichen.
18. normale Such- und Fehlversuche von relevanten Fehlern unterscheiden.
19. Befund mit Ereignisanzeige und Anwendungsprotokollen abgleichen.
20. Hypothese formulieren.
21. möglichst kleinen und reversiblen Test planen.
22. Sicherung und Rückfallplan prüfen.
23. Änderung durchführen.
24. Funktion erneut testen.
25. Diagnosewerkzeuge und temporäre Überwachung beenden.
26. Daten geschützt speichern oder ordnungsgemäß löschen.
27. Ursache, Maßnahme und Ergebnis dokumentieren.

Ausgangslage

Eine Anwendung meldet beim Start, eine Konfigurationsdatei sei nicht vorhanden. Die Datei ist im erwarteten Verzeichnis sichtbar.

Vorgehensweise

1. tatsächlichen Anwendungsprozess bestimmen.
2. Process Monitor starten.
3. Aufzeichnung anhalten und leeren.
4. Filter auf den Prozessnamen setzen.
5. optional nach einem Teil des Dateinamens filtern.
6. Aufzeichnung starten.
7. Fehler reproduzieren.
8. Aufzeichnung beenden.
9. Operationen wie CreateFile untersuchen.
10. tatsächlich abgefragten Pfad prüfen.
11. Benutzerkontext kontrollieren.
12. Ergebnisse vor und nach dem Fehler vergleichen.

Mögliche Befunde

• Anwendung sucht in einem anderen Verzeichnis.
• Umgebungsvariable führt zu einem falschen Pfad.
• Dateiname oder Erweiterung weicht ab.
• Zugriff wird verweigert und als „nicht gefunden“ dargestellt.
• Anwendung läuft unter einem Dienstkonto.
• Datei wird zuerst gefunden, aber eine abhängige Datei fehlt.
• Registrywert enthält einen veralteten Pfad.
• 32-Bit- und 64-Bit-Dateisystemumleitung beeinflusst den Zugriff.

Geeignete Ergänzungen

• Process Explorer für Benutzer und Befehlszeile
• AccessChk für Berechtigungen
• Sigcheck für die Anwendungsdatei
• Ereignisanzeige für Folgefehler

Vorgehensweise

1. Ausgangswert im Task-Manager oder mit PowerShell erfassen.
2. Process Explorer zur Beobachtung verwenden.
3. Private Bytes, Working Set und Commit unterscheiden.
4. VMMap-Snapshot im Ausgangszustand speichern.
5. reproduzierbare Benutzeraktion mehrfach ausführen.
6. zweiten VMMap-Snapshot erstellen.
7. wachsende Speicherart bestimmen.
8. bei Bedarf ProcDump kontrolliert konfigurieren.
9. Speicherabbild mit geeignetem Debugger untersuchen.
10. Anwendungsversion und bekannte Fehler des Herstellers prüfen.

Nicht ausreichend als Beweis

• RAM-Anzeige steigt einmalig
• Working Set sinkt nicht sofort
• freier Speicher wird kleiner
• RAMMap zeigt großen Standby-Cache
• Prozess besitzt viele Speicherabbildungen

Stärkerer Hinweis auf ein Leck

Ein bestimmter Speicherbereich wächst bei wiederholbarer identischer Aktion fortlaufend, wird nicht wieder freigegeben und korreliert mit der Störung.

Geeignete Werkzeuge

• Process Monitor
• Process Explorer
• Autoruns
• Ereignisanzeige
• Leistungsüberwachung
• ProcDump bei Hängern

Vorgehensweise

1. Startzeit reproduzierbar messen.
2. Process Monitor vorbereiten.
3. nur den Startvorgang aufzeichnen.
4. Ereignisse nach Dauer untersuchen.
5. wiederholte Datei- oder Registryzugriffe identifizieren.
6. Netzwerkpfade und Namensauflösung beachten.
7. untergeordnete Prozesse im Process Tree prüfen.
8. Signaturen und Pfade geladener Komponenten kontrollieren.
9. Ergebnis mit einem funktionierenden System vergleichen.

Mögliche Ursachen

• nicht erreichbarer Netzwerkpfad
• langsame DNS-Auflösung
• wiederholte Zertifikatsprüfung
• blockierende Sicherheitssoftware
• fehlende Datei mit wiederholten Suchversuchen
• langsame Benutzerprofilkomponente
• fehlerhafte Shell-Erweiterung
• veraltete Autostartkomponente
• stark ausgelasteter Datenträger
• Drittanbieter-DLL
• nicht erreichbarer Lizenzserver

Sysinternals-Ausgaben können enthalten:

• Benutzernamen
• Computer- und Domänennamen
• IP-Adressen
• Dateipfade
• Befehlszeilen
• Prozessumgebungen
• Registrywerte
• geöffnete Dokumente
• Netzwerkziele
• Sicherheitskennungen
• Anmeldesitzungen
• E-Mail-Adressen
• Tokens und Zugangsdaten
• Datei- und Speicherinhalte
• Active-Directory-Strukturen

Vor der Weitergabe

1. Empfänger und Zweck bestimmen.
2. erforderlichen Datenumfang begrenzen.
3. Datei auf Geheimnisse prüfen.
4. personenbezogene Daten redigieren.
5. verschlüsselten Übertragungsweg verwenden.
6. Zugriffsrechte beschränken.
7. Aufbewahrungsdauer festlegen.
8. Löschung dokumentieren.
9. öffentliche Uploadplattformen vermeiden.
10. Speicherabbilder besonders schützen.

Besonders sensible Dateitypen

Ticket:
Datum und Uhrzeit:
Bearbeiter:

Computername:
Windows-Version:
Build:
Architektur:
Benutzerkontext:
Betroffener Prozess:
PID:
Prozesspfad:
Befehlszeile:
Prozessherausgeber:
Signaturstatus:

Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Reproduktionsschritte:
Letzte funktionierende Nutzung:
Letzte Änderung:

Verwendetes Sysinternals-Werkzeug:
Werkzeugversion:
Bezugsquelle:
Hash des Werkzeugs:
Erhöht ausgeführt:
Startzeit der Aufzeichnung:
Endzeit der Aufzeichnung:
Verwendete Filter:
Verwendete Befehlszeile:
Speicherort der Diagnosedaten:

Relevanter Prozess:
Übergeordneter Prozess:
Benutzer:
Operation:
Objekt oder Pfad:
Ergebnis:
Zeitlicher Zusammenhang:
Vergleichssystem geprüft:
Normales Verhalten ausgeschlossen:

Autostarteintrag:
Signatur:
Hash:
VirusTotal verwendet:
Datei hochgeladen:
Freigabe für externen Dienst vorhanden:

Lokale Adresse:
Lokaler Port:
Remoteadresse:
Remoteport:
Verbindungsstatus:
Zugehöriger Prozess:

RAM-Ausgangswert:
RAM-Endwert:
Working Set:
Private Bytes:
Commit:
Wachsende Speicherart:
Dump erzeugt:
Dump-Typ:
Dump-Größe:
Dump geschützt gespeichert:

Sysmon-Konfiguration:
Sysmon-Ereignis-ID:
Ereignisquelle:
SIEM-Abfrage:

Vermutete Ursache:
Zusätzliche Datenquelle:
Geplante Änderung:
Sicherung geprüft:
Rückfallplan:
Änderung durchgeführt:
Neustart erforderlich:

Ergebnis nach Änderung:
Fehler erneut getestet:
Monitoring kontrolliert:
Temporäre Aufzeichnung beendet:
Diagnosedaten redigiert:
Aufbewahrungsfrist:
Abschluss: