1 FileMonitoring

1.1 Einleitung zum Filemonitoring

Technet: What's New in Windows Security Auditing
Technet: Manage Security Auditing

Windows und Powershell bieten verschiedene Möglichkeiten an, Objekte im NTFS zu monitoren

  • NTFS-Auditing
  • Windows Eventmonitoring WMI / .Net
  • Tools ( Process Monitor)
  • FileSystem-Module aus dem Powershellpack

a) NTFS-Auditing

Vorteile

  • liefert viele Informationen, unter anderem auch das Konto des Verursachers des Events
  • kann für Ordner und Dateien eingesetzt werden
  • natives bewährtes, stabiles, gut dokumentiertes Windowswerkzeug

Nachteile

  • zur Einrichtung sind Eingriffe in der Infrastruktur notwendig (Policyänderung, NTFS-Rechteveränderung)
  • zur Auswertung muss das Anwendungsprotokoll im Eventviewer untersucht werden. 
  • die Auswertung erfordert tiefes Windows-KnowHow, wie die Bedeutung der EventIds

 b) Windows Eventmonitoring WMI / .Net

Vorteile

  • es sind keine Änderungen an der Infrastruktur notwendig
  • man kann die gelieferten Informationen einschränken und sofort in der gewünschten Form ausgeben (Email, Tabelle, Eventlog) 
  • die Ergebnisse sind ohne tiefe Kenntnisse interpretierbar
  • einfache Remotefähigkeit bei der WMI-Methode 
  • über die Windowsaufgabenplanung (Scheduler) ist das Auditing einfach zeitlich konfigurierbar ("Das Auditing soll ab 7:30 Uhr morgens jeden Tag zwei Stunden lang laufen.")

Nachteile

  • Nicht mit allen Methoden der FileSystemWatcher-Klasse können Ordnerobjekte auditiert werden, sondern nur Dateien
  • bei längerem Einsatz sollten die Skripte selbst laufend überwacht werden
  • Skripte können Fehler enthalten
  • eventuell ist der Ressourcenverbrauch (CPU/ Memory) der Skripte problematisch.


c) ProcessMonitor

Der "Process Monitor" von Sysinternals ist ein Spezialistentool, welches eigentlich nicht in diese Reihe der Auditingwerkzeuge gehört. 
Mit dem ProcessMonitor erhält man umfangreiche Informationen, welche Prozesse auf das FileSystem oder die Registry zugreifen und diese verändern. 

Den Einsatz des Prozessmonitors muß man sorgfältig planen und testen. Ohne die richtige Konfigurationen zeichnet dieses Tool eine Unmenge an Daten auf und reißt die CPU-Last nach oben. 

Auf den Process Monitor werde ich hier nicht näher eingehen.

d) FileSystem-Modul aus dem Powershellpack

Installiert man das Powershellpack - siehe My Powershell -> 3.3.3 Module und SnapIns -> Beispiel 7 - so kann man das Module "FileSystem einbinden und bekommt damit das cmdlet Start-FileSystemWatcher.


Anbei noch ein kleines Beispielskript, dass nacheinander einige Grundoperationen mit Ordnern und Dateien(Lesen, Schreiben, Umbenennen) in einem Verzeichnis durchführt.
Zum Testen einer Überwachung kann man dieses Skript in einer parallelen Powershellsitzung starten. Das Skript führt dann einige Testfälle aus.

Beispiel 1: Testfälle

Function FSW_StartCleaner{
 param($path="C:\Temp\FileMon")
 #Eventuelle Inhalte unterhalb des Testpfads löschen
 $a=Test-Path -path $path
    if ($a -eq $true){
      Get-Childitem -Path $Path | ForEach {Remove-Item $_.Fullname -Force -Recurse }
     }
}

Function FSW_Test{
  param($path="C:\Temp\Filemon")
  
  #Verzeichnis anlegen"
  New-Item $Path\Verzeichnis_1 -Type Directory -EA 0
     
  #Datei anlegen 
  New-Item $Path\File_1.txt -Type File -EA 0
  
  #Ordner umbenennen
  Rename-Item $Path\Verzeichnis_1 Verzeichnis_2 -EA 0
 
  #Datei umbenennen
  Rename-Item $Path\File_1.txt File_2.txt -EA 0
  
  #Unterverzeichnis erstellen
  New-Item $Path\Verzeichnis_2\SubVerzeichnis_1 -Type Directory -EA 0
 
  #CreationTime einer Datei verändern
  $DotNetfile=get-item -path $path\File_2.txt
  $DotNetFile.lastaccesstime = ([datetime]::now).adddays(-1) #gestern
 
  #Inhalt in eine Datei schreiben
  Set-Content $Path\\File_2.txt -Value "My good old friend Karl Napf"
     
  #Datei löschen
  Remove-Item $Path\File_2.txt
   
  #Ordner löschen
  Remove-Item $Path\Verzeichnis_2\SubVerzeichnis_1 -recurse -EA 0
 }
 
 FSW_StartCleaner C:\temp\Filemon
 FSW_Test -Path C:\temp\Filemon

 

1.2 NTFS-Auditing

Umfassende Informationen über Filezugriffe liefert das NTFS-Auditing. Damit lässt sich genau feststellen, wer wann was an einer Datei oder an einem Verzeichnis verändert hat, oder wer auch nur lesend auf das NTFS-Objekt zugegriffen hat.

Die Einrichtung ist etwas aufwändig. Die Ergebnisse werden im SicherheitsProtokoll (=SecurityEventlog) des überwachten Rechners geschrieben. Bis hierhin sind keine Scriptingkenntnisse erforderlich, alles geschieht durch eine Konfiguration in einer GUI.

Einige Links, die das Vorgehen im Detail erklären:

  • Sehr umfangreiche Informationen über Auditing enthalten die Links dieser Technetseite:  Technet Library: Security Auditing
  • Eine kompakte Anleitung, wie ein Auditing zu aktivieren ist, liefern die Links dieser Technetseite: Technet Library: Manage Security Auditing


Zwei Technet Links, die ebenfalls das Einrichten einer Audit Policy Step-by-Step beschreiben:

Step2: Creating and verifying an advanced audit policy
Step 3: Creating and verifying an audit policy that provides the reason for object access ´

1.3 Eventmonitoring

Das Erstellen, Löschen oder überhaupt das Verändern einer Datei verursacht unter Windows ein sogenanntes Event (ETW: Event Tracing for Windows). Diese Events haben nichts mit den WindowsEvent-Logs "System",  "Anwendung" oder "Sicherheit" zu tun hat, die man aus dem Eventviewer (eventvwr.exe) her kennt.

Solche ETW-Events kann man entweder über WMI-Klassen erzeugen und abfragen, oder mit der .Net Klasse "FileSystemwatcher".

Der Vorteil bei WMI liegt in der einfachen Remotefunktionalität durch einfaches Besetzen des Positionsparameters "-ComputerName" im cmdlet Register WMIEvent. (siehe Beispiel 1b im nachfolgenden Kapitel)

.Net ist dagegen syntaktisch etwas einfacher und natürlich die modernere und eventuell auch performantere Herangehensweise.

1.3.1 FileMonitoring mit WMI

Generell funktioniert die Überwachung des NTFS-Filesystems mit WMIEvents, wie die folgenden Beispiele zeigen werden. Jedoch rät Don Jones, einer der Gurus der PowershellCommunity, von dieser Art des Filemonitorings aus Performancegründen, verbunden mit mangelnder Zuverlässigkeit, ab:

"As an aside, don’t be tempted to register for instance creation events on the CIM_DataFile class that represents files on disk. WMI isn’t very efficient at monitoring new file creation. It will likely miss events, and can impose some pretty heavy overhead in trying to catch everything."

TechNet Magazine August 2010: Windows PowerShell -> Responding to WMI Events
(Link bitte im InternetExplorer betrachten)

Ich sehe es nicht ganz so pauschal. Wenn nicht zu viele parallele Events zu erwarten sind, beispielsweise zur Überwachung von Logverzeichnissen, so kann man WMI durchaus noch benutzen. Ich habe 30 Dateien in ein Verzeichnis kopiert, diese wurden alle schnell und sauber erfasst.
Auch in einem MSDN-Beitrag wird diese Art des Filemonitorings ohne Einschränkungen beschrieben:
MSDN: WMI Event -> Windows Event on File Create?


Beispiel 1a: Erstellen einer Datei lokal überwachen (__InstanceCreationEvent)

$DirectoryPath="c:\temp"
$DirectoryPath=$DirectoryPath.Replace("\","\\\\")
 
$SourceIdentifier = "MyFileMon_Create"
UnRegister-Event $SourceIdentifier -EA 0
      
$Query = "Select * from __InstanceCreationEvent WITHIN 1
           WHERE TargetInstance ISA 'CIM_DirectoryContainsFile' 
            AND TargetInstance.GroupComponent = 'Win32_Directory.Name=""$directorypath""'"
          
$Action = {
          $WMIFileName=$($event.SourceEventArgs.NewEvent.TargetInstance.PartComponent)
          $WMIFileName = $WMIFileName-split "Name="
          $FileName = $WMIFileName[1].Replace("\\","\")
          Write-Host "$Filename[1] wurde am $(get-date) erstellt"
          }        
         
Register-WmiEvent -Query $Query -SourceIdentifier $SourceIdentifier -Action $Action
#mögliche Ausgabe nach dem Erstellen einer Datei unter c:\temp

"c:\temp\Neues Textdokument (6).txt" wurde am 12/10/2011 00:13:23 erstellt

Anmerkungen: 

  • WMI benötigt die Pfadangabe mit 4-fachen Backslashes
  • Mit dem Namen $SourceIdentifier wird das WMI-Event registriert. Da ein Name nicht zweimal registriert werden darf, deregistriere ich den WMI-Event zu Beginn des Skripts. -EA 0 (=ErrorAction -SilentlyContinue) sorgt dafür, dass keine Fehlermeldung ausgegeben wird, falls das Event noch nicht existiert
  • In der Query schränkt der ISA-Operator die Events auf die Klasse 'CIM_DirectoryContainsFile' ein. Näher beschrieben sind EventQueries hier: Kapitel WMI -> 2.5 EventQueries
  • Register-WmiEvent registriert den WMIEvent. Näheres zur Verwaltung von WMIEvents im genannten WMIKapitel in Beispiel 3
  • Das Monitoring läuft nur solange das Skriptfenster geöffnet bleibt.
  • Es lassen sich nur Dateien, aber keine Ordner überwachen.
  • Das cmdlet "Register-WMIEvent" besitzt den Positionsparameter "-computername". Damit kann das Monitoring auch remote ausgeführt werden (siehe nächstes Beispiel)
  • Es können auch mehrere WMI-Events mit unterschiedlichen SourceIdentifiern registriert werden, um verschiedene Aktionen zu überwachen

Technet: Register-WmiEvent

Technet: Unregister-Event
 

Beispiel 1b: Erstellen einer Datei remote überwachen (__InstanceCreationEvent)

$DirectoryPath = "c:\temp"
$DirectoryPath = $DirectoryPath.Replace("\","\\\\")
$ComputerName = "."
 
$SourceIdentifier = "MyFileMon_Create"
UnRegister-Event $SourceIdentifier -EA 0
      
$Query = "Select * from __InstanceCreationEvent WITHIN 1
           WHERE TargetInstance ISA 'CIM_DirectoryContainsFile' 
            AND TargetInstance.GroupComponent = 'Win32_Directory.Name=""$directorypath""'"
          
$Action = {
          $WMIFileName=$($event.SourceEventArgs.NewEvent.TargetInstance.PartComponent)
          $WMIFileName = $WMIFileName-split "Name="
          $FileName = $WMIFileName[1].Replace("\\","\")
          Write-Host "$Filename[1] wurde am $(get-date) erstellt"
          }        
         
Register-WmiEvent -Query $Query -SourceIdentifier $SourceIdentifier -Action $Action -computername $ComputerName

Anmerkung:

  • identisches Ergebnis wie Beispiel 1a


Beispiel 1c: Erstellen einer Datei überwachen -> Ausgabe im Eventlog

$DirectoryPath="c:\temp"
$DirectoryPath=$DirectoryPath.Replace("\","\\\\")
$ComputerName="."
 
New-Eventlog -Source WMIFileMon -LogName Application -EA 0
 
$SourceIdentifier = "MyFileMon_Create"
UnRegister-Event $SourceIdentifier -EA 0
      
$Query = "Select * from __InstanceCreationEvent WITHIN 1
           WHERE TargetInstance ISA 'CIM_DirectoryContainsFile' 
            AND TargetInstance.GroupComponent = 'Win32_Directory.Name=""$directorypath""'"
          
$Action = {
          $WMIFileName=$($event.SourceEventArgs.NewEvent.TargetInstance.PartComponent)
          $WMIFileName = $WMIFileName-split "Name="
          $FileName = $WMIFileName[1].Replace("\\","\")
          Write-Host "$Filename[1] wurde am $(get-date) erstellt"
          $Message="$Filename[1] wurde am $(get-date) erstellt"
          Write-Eventlog -logname Application -source WMIFileMon -eventID 9999 -entrytype Information -message $Message
          }        
         
Register-WmiEvent -Query $Query -SourceIdentifier $SourceIdentifier -Action $Action -computername $ComputerName

Anmerkungen:

  • identisches Ergebnis wie Beispiel 1a
  • Für die Ausgabe der Ergebnisse in das WindowsEventlog sind nur zwei kleine Modifikationen notwendig.
  •    "New-Eventlog -Source WMIFileMon -LogName Application -EA 0" registriert eine Quelle mit dem Namen WMIFileMon
  •     "Write-Eventlog..." schreibt das Ergebnis in das Anwendungprotokoll
  •    Aufgrund des Eventlogeintrags muss man das Script evtl. als Administrator starten

Technet: New-Eventlog

Technet: Write-Eventlog


Beispiel 2: Löschen einer Datei überwachen (__InstanceDeletionEvent)

$DirectoryPath="c:\temp"
$DirectoryPath=$DirectoryPath.Replace("\","\\\\")

$SourceIdentifier = "MyFileMon_Delete"
UnRegister-Event $SourceIdentifier -EA 0
     
$Query = "Select * from __InstanceDeletionEvent WITHIN 1 WHERE TargetInstance ISA 'CIM_DirectoryContainsFile'
          AND TargetInstance.GroupComponent='Win32_Directory.Name=""$directorypath""'"
         
$Action = {
          $WMIFileName=$($event.SourceEventArgs.NewEvent.TargetInstance.PartComponent)
          $WMIFileName = $WMIFileName-split "Name="
          $FileName = $WMIFileName[1].Replace("\\","\")
          Write-Host "$Filename[1] wurde am $(get-date) gelöscht"
          }       
        
Register-WmiEvent -Query $Query -SourceIdentifier $SourceIdentifier -Action $Action
#mögliche Ausgabe nach dem Löschen einer Datei unter c:\temp

"c:\temp\Neu Textdokument (5).txt" wurde am 12/10/2011 22:21:14 gelöscht

 Anmerkungen:

- identisch zu Beispiel 1a

- __InstanceDeletionEvent und __InstanceCreatioEvent können mit __InstanceOperationEvent kombiniert werden

 

1.3.2 FileMonitoring mit der .Net-Klasse FileSystemWatcher

MSDN: FileSystemWatcher-Klasse


Beispiel 1: FileSystemWatcher (Register-ObjectEvent)

Technet: Scripting Gallery -> Powershell FileSystemWatcher

Function FSWatch{
 Param($path)
 UnRegister-Event FileCreated -EA 0
 UnRegister-Event FileChanged -EA 0
 UnRegister-Event FileDeleted -EA 0
 

 $Watcher = New-Object System.IO.FileSystemWatcher
 $Watcher.path=$path
 $Watcher.NotifyFilter = [IO.NotifyFilters]'FileName, LastWrite, FileName, DirectoryName'
 $Watcher.Filter = "*.txt"

 Register-ObjectEvent $Watcher Created -SourceIdentifier FileCreated -Action {
  $Name = $Event.SourceEventArgs.Name
  $ChangeType = $Event.SourceEventArgs.ChangeType
  $TimeGenerated = $Event.TimeGenerated
  $EventIdentifier=$Event.EventIdentifier
  Write-Host "Die Datei $name wurde  $TimeGenerated verändert "
  Write-Host "ChangetTyp: $ChangeType"
  Write-Host "EventIdentifier: $EventIdentifier `n"
 } #Action
 
 Register-ObjectEvent $Watcher Changed -SourceIdentifier FileChanged -Action {
 $Name = $Event.SourceEventArgs.Name
 $ChangeType = $Event.SourceEventArgs.ChangeType
 $TimeGenerated = $Event.TimeGenerated
 $EventIdentifier=$Event.EventIdentifier
 Write-Host "Die Datei $name wurde  $TimeGenerated verändert "
 Write-Host "ChangetTyp: $ChangeType"
 Write-Host "EventIdentifier: $EventIdentifier `n"
 } #Action
 
 Register-ObjectEvent $Watcher Deleted -SourceIdentifier FileDeleted -Action {
 $Name = $Event.SourceEventArgs.Name
 $ChangeType = $Event.SourceEventArgs.ChangeType
 $TimeGenerated = $Event.TimeGenerated
 $EventIdentifier=$Event.EventIdentifier
 Write-Host "Die Datei $name wurde  $TimeGenerated verändert "
 Write-Host "ChangetTyp: $ChangeType"
 Write-Host "EventIdentifier: $EventIdentifier `n"
 } #Action
 
 
} #End Function FSWatch

#Ausführung des Programms

FSWatch -path c:\temp\Filemon #überschreibt den Defaultwert "c:\temp" in der Funktion

#getestet unter PSH V2
#mögliche Ausgabe
#Das Überwachungsskript wurde mit dem Testskript aus in

Kapitel 1 -> Beispiel 1 getestet.

Die Datei File_1.txt wurde  12/17/2011 23:59:00 verändert
ChangetTyp: Created
EventIdentifier: 14

Die Datei File_2.txt wurde  12/17/2011 23:59:00 verändert
ChangetTyp: Changed
EventIdentifier: 15

Die Datei File_2.txt wurde  12/17/2011 23:59:00 verändert
ChangetTyp: Changed
EventIdentifier: 16

Die Datei File_2.txt wurde  12/17/2011 23:59:00 verändert
ChangetTyp: Deleted
EventIdentifier: 17

Leider ist es mir nicht ganz gelungen, das  C#-Beispiel aus der MSDN mit der Klasse "FileSystemEventHandler" nach Powershell umzusetzen. Der Weg aus dem Beispiel der ScriptingGallery über das cmdlet "Register-ObjectEvent" ist nicht weniger gut.
Bei diesem Skript werden leider kein Aktionen an Ordnern gemonitort, sondern nur Dateiaktionen. Das ist etwas verwunderlich, weil ansich in den Enumerationen unter  MSDN: NotifyFilters-Enumeration auch DirectoryName aufgelistet ist.


Beispiel 2: FileSystemWatcher (WaitForChanged)

Function Main{
  $Path="c:\temp"
  $IncludeSubdirectories = $True
  $MaxCount = 10 
  Start-FSW $Path $IncludeSubdirectories $MaxCount
}
 
Function Start-FSW{
  Param($Path,$IncludeSubdirectories, $MaxCount)
    For ($i = 1; $i -lt $maxCount; $i = $i+1){
    $FileSystemWatcher = New-object System.IO.FileSystemWatcher $Path
    $FileSystemWatcher.IncludeSubdirectories  =$true
    $Result = $FileSystemWatcher.WaitForChanged("all")
 
    "$i`nNeuer Name:{0} `nAlter Name:{1} `nChangeType:{2}  `nTime:{3}`n" -f  `
       $($Result.Name),$($Result.OldName),$($Result.ChangeType),$(Get-Date)
 
 
    }#for
 }#function
 
 Main
#mögliche Ausgabe
#Das Überwachungsskript wurde mit dem Testskript aus in

Kapitel 1 -> Beispiel 1 getestet.

1
Neuer Name:Verzeichnis_2\Neuer Ordner
Alter Name:
ChangeType:Deleted 
Time:17.12.2011 23:27:15

2
Neuer Name:File_1.txt
Alter Name:
ChangeType:Created 
Time:17.12.2011 23:27:15

3
Neuer Name:Verzeichnis_2
Alter Name:Verzeichnis_1
ChangeType:Renamed 
Time:17.12.2011 23:27:15

4
Neuer Name:File_2.txt
Alter Name:File_1.txt
ChangeType:Renamed 
Time:17.12.2011 23:27:15

5
Neuer Name:Verzeichnis_2\SubVerzeichnis_1
Alter Name:
ChangeType:Created 
Time:17.12.2011 23:27:15

6
Neuer Name:Verzeichnis_2
Alter Name:
ChangeType:Changed 
Time:17.12.2011 23:27:15

7
Neuer Name:File_2.txt
Alter Name:
ChangeType:Changed 
Time:17.12.2011 23:27:15

8
Neuer Name:File_2.txt
Alter Name:
ChangeType:Changed 
Time:17.12.2011 23:27:15

9
Neuer Name:File_2.txt
Alter Name:
ChangeType:Deleted 
Time:17.12.2011 23:27:15

Anmerkung 1:
Durch die Forschleife werden 10 Veränderungen unterhalb von $Path überwacht. Soll die Überwachung endlos laufen, kann man die Abbruchbedingung der ForSchleife zum Beispiel auf "$i -gt 0" setzen.

Anmerkung 2:
Die möglichen Werte für WaitForChanged findet man unter  MSDN: WatcherChangeTypes-Enumeration

Created

Die Erstellung einer Datei oder eines Ordners.

Deleted

Das Löschen einer Datei oder eines Ordners.

Changed    

Die Änderung einer Datei oder eines Ordners. Es gibt u. a. folgende Arten von Änderungen: Änderungen an der Größe, an Attributen, an den Sicherheitseinstellungen und am Zeitpunkt des letzten Schreibvorgangs bzw. des letzten Zugriffs.

Renamed

Die Umbenennung einer Datei oder eines Ordners.

All

Das Erstellen, Löschen, Ändern oder Umbenennen einer Datei oder eines Ordners.

Anmerkung 3:
Mit WaitForChanged können auch Aktionen an Verzeichnissen gemonitored werden, dafür ist die Auswahl der Attribute kleiner, als bei Register-ObjectEvent aus dem letzten Beispiel:  MSDN: WaitForChangedResult-Eigenschaften

Unter Umständen ist die Angabe eines TimeOutParameters ganz nützlich

Anmerkung 4:
...
$Result = $FileSystemWatcher.WaitForChanged("all",5000)
...

MSDN: FileSystemWatcher.WaitForChanged Method (WatcherChangeTypes, Int32) http://msdn.microsoft.com/en-us/library/aa903940%28v=VS.71%29.aspx

"timeout - The time (in milliseconds) to wait before timing out."

Anmerkung 5:
Neben IncludeSubdirectories besitzt die FileSystemWatcher-Klasse noch weitere Eigenschaften  MSDN:FileSystemWatcher Properties


Beispiel 3: Start-FileSystemWatcher aus dem Powershellpack

import-module FileSystem
get-help Start-FileSystemWatcher

Wer statt den Weg über die .Net-Klasse wie in Beispiel lieber mit cmdlets arbeiten möchte, kann sich das FileSystemModul näher ansehen.

 

1.4 permanentes Filemonitoring mit Get-Content

Mit dem cmdlet get-content lässt sich der bekannte Unixbefehl "tail.exe" nachbauen und erweitern.
 

Beispiel 1: Textfile laufend auf neue Einträge überwachen

$FilePath="c:\temp\anwendung_abc.log"
$Pattern="error"

$LineCounter=0
$NumberOfLines=$(get-content -path $Filepath).count

Get-Content -path $Filepath -Wait | ForEach{
 $LineCounter+=1
 If(($_ -match $Pattern) -and ($Linecounter -gt $NumberOfLines)){
  "$_" #Aktion
  }
}
#mögliche Ausgabe, wenn "anwendung_abc.log" einen neuen Eintrag erhält

25.12.2011 19:04   6dBLtF0HN SaQQcXUElPWb1FU oX Error: 225 2Hl88Woj

get-content mit dem Parameter -wait liest eine Textdatei komplett ein, schliesst danach allerdings nicht den Handle, sondern wartet auf weitere Eingaben. 

In der ForEach-Schleife werte ich anschließend alle Ausgaben von get-content aus, ob sie den Suchbegriff "error" enthalten. Da mich erst neue Errormeldungen interessieren, soll dies ab einer Zeilennummer ($LineCounter) größer als der Zeilenanzahl zu Beginn ($NumberOfLines) geschehen.

Mögliche Aktionen wären eine Emailbenachrichtigung oder ein Dienstneustart. 

2 Monitoring mit dem Process Monitor (Sysinternals)

In diesem Kapitel kommen ausnahmsweise keine Powershellskripte vor. Der Processmonitor ist ein solch nützliches Tool, über das leider kaum eine nähere Beschreibung existiert, so dass ich doch etwas näher darauf eingehen will.

Windows Sysinterals: Process Monitor v2.96

Der Process Monitor beherrscht das Monitoren des Filesystems, der Registry und des Netzwerks. Er integriert die früheren Programme Filemon.exe und Regmon.exe

In den folgenden Kapiteln will ich beispielhaft zeigen, wie man ein bestimmtes Verzeichnis auf Zugriffe und Veränderungen effektiv überwacht. 

Anforderung a) Die Events sollen so gefiltert werden, dass keine unerwünschten Informationen anfallen

Anforderung b) Der Process Monitor soll genau zeigen, welche Prozesse unter welchem Kontext ablaufen, wenn eine einfache Textdatei über Notepad verändert wird.

Anforderung c) Events sollen zur späteren Analyse gespeichert werden

Anforderung d) Für mehrmalige Überwachungen soll ein parametrisierter Aufruf über Commandline erstellt werden (Filter, Backupfile)
 

2.1 Vorbereitungen

Entpackt man den Process Monitor und startet das Programm das erste Mal, so sind die default Einstellungen so, dass innerhalb weniger Sekunden einige tausend Events eingesammelt werden, selbst wenn auf der Maschine nicht gearbeitet wird. Diese Menge an Ereignissen ist erstmal sehr erstaunlich, verhindert aber eine vernünftige Analyse.


Der erste Schritt besteht darin, den Prozessmonitor so zu konfigurieren, dass ausgefilterte Ereignisse weder angezeigt noch gespeichert werden. Wählt dazu bitte im Menü Filter die beiden Einträge "Drop Filtered Event" und "Enable Advance Input" aus.
Dies führt dazu, dass erstens die nicht auf dem Bildschirm dargestellten Einträge verworfen (=gedropped) werden und zweitens die Standardeinstellungen aus dem Filter entfernt werden.

 
Im Menü Files -> Backing Files... wechselt das Logfile vom Pagefile zu einem existierenden Pfad und gebt den Namen des Logfiles an. Dieser Schritt ist notwendig, wenn die Ergebnisse automatisch in dieser Datei abgespeichert werden sollen.


Damit man sieht, wer etwas gemacht hat, kann man im Menu "Options" -> "Select Columns" unter "Process Management" die Spalte "User Name" auswählen.

2.2 Filtereinstellungen

Durch die Auswahl "Enable Advanced Input" die wir im letzten Schritt gesetzt hatten, sind die Filtereinstellungen frei von den Defaulteinstellungen, die -wie oben beschrieben- eine riesige Menge an Events loggen.

Wenn ein bestimmter Pfad wie "C:\temp\DemoMonitoring" überwacht werden soll, so fügt man die folgende Einstellung hinzu:
"Path" "is" "c:\temp\DemoMonitoring"

Sollen auch Subkeys überwacht werden, so ist anstelle des "is" ein "begins with" zu setzen
"Path" "begins with" "c:\temp\DemoMonitoring"

Ebenso lassen sich übrigens auch RegistryPfade überwachen. 
"Path" "is" "HKCU\Software\Classes"

2.3 Ergebnis

Ich habe wie eingangs gefordert, in einer Textdatei unter "C:\temp\demoMonitoring" einen Buchstaben in Notepad geändert und abgespeichert.

In der Ausgabe sieht man, dass bei dieser kleinen Aktion eine ganze Menge hinter den Kulissen passiert. Neben Notepad hat mein Virenscanner "McShield" im Systemkontext "vorbeigeschaut", bevor der Explorerprozess aktiv wurde. 

Tipp: Lasst euch nicht durch vermeintliche Fehlermeldungen ("Invalid Device" oder "Buffer Overflow") vewirren, wie sie auch in diesem Beispiel zu sehen sind. Bei derartigen Entwicklertools sind solche Meldungen vollkommen normal und stellen -isoliert betrachtet- noch keine Fehler dar.
Tatsächliche Fehler identifizieren sich zum Beispiel im Vergleich mit anderen Systemen oder anderen Pfaden. 

 

2.4 Process Monitor per Batch starten

Häufig möchte man eine Überwachung mehrfach starten, sei es auf verschiedenen Systemen oder mehrfach nacheinander auf einem System.

Dazu speichert euch im Menü File unter "Export Configuration" in eine *.pmc-Datei ab. Ein Batchaufruf könnte dann folgendermaßen aussehen.

#code für Batchdatei

procmon  /accepteula /quiet /LoadConfig MyConfig.pmc /Backingfile MyLog.pml 

In der Hilfe procmon.chm befinden sich weitere Schalter

Selbstverständlich war dies hier nur ein kleiner Ausschnitt der Möglichkeiten des Procmon. 
Das Tool ist ein wertvolles Werkzeug, um detaillierte Informationen bei Dateizugriffen zu erhalten.