Wie man wichtige Windows-Sicherheitsereignisse mit PowerShell verfolgt

Viele Organisationen verlassen sich auf Microsoft-Technologien, um ihre Arbeit zu erledigen. Gleichzeitig können Bedrohungsakteure Betriebssysteme wie Windows ausnutzen. Glücklicherweise protokolliert Windows Sicherheitsereignisse des Betriebssystems, um Ihnen bei der Verfolgung dieses Verhaltens zu helfen.

Sicherheitsereignisse, die von Windows erzeugt werden, dienen als wichtige Ressource im Incident Response-Prozess. Tools wie das Windows Event Viewer von Microsoft ermöglichen Ihnen den Zugriff, um erfasste Ereignisse zu überprüfen. Das manuelle Durchsuchen eines überfüllten Protokolls, um Abweichungen zu erkennen, ist jedoch unrealistisch.

In diesem Beitrag erfahren Sie, wie Sie potenzielle Sicherheitsverletzungen in Windows aufspüren, indem Sie sich mit Überwachungsrichtlinien, Windows-Ereignisprotokollen und der Analyse von Sicherheitsereignissen mit PowerShell vertraut machen.

Voraussetzungen

Dieser Artikel soll Informationen vermitteln, die Ihnen beibringen, wie Sie Windows-Sicherheitsereignisse mit PowerShell analysieren können. Wenn Sie an einer der Demonstrationen teilnehmen möchten, benötigen Sie:

• A Windows 10+ PC – This PC will be used to generate and track down potential security events in the event log. This tutorial will be using Windows PowerShell 5.1.
• Administratorrechte auf dem Windows-PC
• A PowerShell code editor such PowerShell ISE or Visual Studio (VS) Code.

Wo Windows Sicherheitsereignisse speichert

Wenn auf einem Windows-Betriebssystem eine Aktion ausgeführt wird, protokolliert Windows die Aktion als Ereignis in einem oder mehreren Ereignisprotokollen. Die Windows-Ereignisprotokolle werden standardmäßig im Verzeichnis %SystemRoot%\system32\winevt\logs auf dem Dateisystem gespeichert. Dieser Speicherort kann geändert werden, indem der entsprechende Ereignisprotokoll-EventLog-Registrierungsschlüssel modifiziert wird.

Wenn Sie sehen möchten, wo die wichtigsten Ereignisprotokolle (Anwendung, Sicherheit und System) auf Ihrem System gespeichert sind, kopieren Sie den folgenden Code in eine PowerShell-Konsole oder speichern Sie ihn als Skript.

Um auf den Speicherort der Sicherheitsprotokolldatei zuzugreifen, müssen Sie den Code als Administrator ausführen.

#Präsentieren Sie Anwendungs-, Sicherheits- und Systemprotokolle in einem Array.
 $arrLogs = @(
     "Application"
     "Security"
     "System"
 )
 #Verwenden Sie den ForEach-Object-Cmdlet, um jedes entsprechende Protokoll mit dem Get-ItemProperty-Cmdlet anzusprechen.
 $arrLogs | ForEach-Object {
     #Verwenden Sie das Get-ItemProperty-Cmdlet, um den konfigurierten Dateipfad für das Anwendungs-, Sicherheits- und Systemprotokoll aufzulisten.
     Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\$_ -Name File | Select-Object PSChildName,File
 }

Im Folgenden wird der erwartete Ausgabecode angezeigt, der den Protokollnamen und den Speicherort für die Anwendungs-, Sicherheits– und System-Protokolldateien anzeigt.

Audit Policies: Definition von aufzuzeichnenden Ereignissen

Standardmäßig erfasst Windows nicht alle Sicherheitsereignisse, die zur Erkennung oder Untersuchung eines Angriffs erforderlich sein könnten. Um zu steuern, was Windows aufzeichnet und was nicht, müssen Sie Audit-Richtlinien definieren und anwenden. Eine Audit-Richtlinie ist ein Satz von Anweisungen, die an Windows übergeben werden und ihm sagen, welche Ereignisse aufgezeichnet werden sollen.

Es gibt verschiedene Möglichkeiten, Audit-Richtlinien zuzuweisen und damit zu arbeiten, wie zum Beispiel Gruppenrichtlinien. Gruppenrichtlinien funktionieren gut, wenn Sie Audit-Richtlinien auf vielen Maschinen implementieren müssen. In diesem Artikel beschränken Sie sich jedoch auf ein einzelnes Gerät und verwenden das Auditpol-Tool. Das Auditpol-Tool ist in Windows vorinstalliert und ermöglicht es Ihnen, Audit-Richtlinien auf einem Windows-System zu finden und festzulegen.

Audit-Richtlinien finden

Zum Beispiel können Sie mit dem Parameter /get den Status aller Audit-Richtlinien auf Ihrem Windows-System finden, wie unten gezeigt. Durch Verwendung des Parameters /category gefolgt von einem Platzhalter fordert auditpol auf, den Status aller Audit-Richtlinien zu finden, nicht nur einer, die einer bestimmten Kategorie oder Unterkategorie entspricht.

#Erhalten Sie die Audit-Richtlinienkonfiguration des Systems.
auditpol /get /category:*

Der folgende Screenshot zeigt eine gekürzte Version der erwarteten Ausgabe des Codes, die die Kategorie Account-Verwaltung, Unterkategorien und Status (Einstellung) der Audit-Richtlinie anzeigt.

A Setting that is configured as No Auditing means that all events associated with that audit policy subcategory will not be logged.

Einstellung der Audit-Richtlinien

Das Tool auditpol kann mehr als nur Audit-Richtlinieneinstellungen anzeigen. Es kann sie auch mit dem auditpol /set-Befehl ändern. Um zukünftige Abschnitte in diesem Tutorial zu demonstrieren, öffnen Sie eine PowerShell-Konsole als Administrator und führen Sie den untenstehenden Befehl aus. Dieser Befehl beginnt mit dem Protokollieren aller Ereignisse (Erfolg und Fehler), die Teil der Anmelde-Unterkategorie sind.

Die Konfiguration der Anmelde-Unterkategorie zwingt Ihr System, Ereignisse aufzuzeichnen:

• 4624: Ein Konto wurde erfolgreich angemeldet
• 4625: Ein Konto konnte nicht angemeldet werden
• 4626: Benutzer-/Geräteanspruchsinformationen
• 4648: Ein Anmeldeversuch wurde mit expliziten Anmeldeinformationen durchgeführt
• 4675: SIDs wurden gefiltert

#Setzen Sie Anmeldeereignisse, um Erfolgs-/Fehlverhalten zu erfassen.
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

Es gibt zahlreiche Ressourcen, die Ihnen bei der Konfiguration von Audit-Richtlinien nach bewährter Praxis helfen, darunter die Center for Internet Security (CIS) Benchmarks und die Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIG), sowie Richtlinien, die von Microsoft veröffentlicht wurden.

Generieren von Anmeldefehlerprotokollen für die Analyse

Dieser Artikel wird ein Tutorial sein und von Ihnen erwartet, dass Sie mitmachen. Wenn Sie Windows so konfiguriert haben, dass Anmeldeereignisse überwacht werden, generieren wir jetzt einige Sicherheitsereignisse für spätere Analysen. Genauer gesagt, lassen Sie uns 35 fehlgeschlagene Anmeldeversuche generieren, die im Sicherheitsprotokoll Ihres Systems aufgezeichnet werden, um Brute-Force-Aktivitäten zu imitieren.

1. Öffnen Sie Ihren bevorzugten Code-Editor.

2. Kopieren Sie den folgenden Code und fügen Sie ihn in den Code-Editor ein. Dieser Codeausschnitt versucht, den PowerShell.exe-Prozess mithilfe des Start-Process-Befehlslets mit erfundenen Benutzernamen und Passwörtern zu öffnen.

#Definieren Sie 5 Benutzernamen, die als Anmeldefehler erfasst werden sollen.
 $arrUsers = @(
     "AtaBlogUser1"
     "AtaBlogUser2"
     "AtaBlogUser3"
     "AtaBlogUser4"
     "AtaBlogUser5"
 )
 #Schleife durch Benutzernamen mit ForEach-Object, um für jeden einen Anmeldefehler zu generieren.
 $arrUsers | ForEach-Object {
     $securePassword = ConvertTo-SecureString "AtA810GRu13Z%%" -AsPlainText -Force 
     $storedCredential = New-Object System.Management.Automation.PSCredential($_, $securePassword)
     Start-Process -FilePath PowerShell -Credential $storedCredential
 }
 #Generieren Sie 30 Anmeldefehler für den Benutzer AtaBlogUser.
 $i = 0
 Do {
     $securePassword = ConvertTo-SecureString "AtA810GRu13Z%%" -AsPlainText -Force 
     $storedCredential = New-Object System.Management.Automation.PSCredential("AtaBlogUser", $securePassword)
     Start-Process -FilePath PowerShell -Credential $storedCredential
     $i++
 } Until ($i -eq 30)

3. Speichern Sie das PowerShell-Skript als Invoke-BogusEvents.ps1 oder beliebigen anderen Namen und führen Sie das Skript aus.

Beim Ausführen bemerken Sie einen erwarteten Fehler, der 35 Mal wiederholt wird und darauf hinweist, dass Der Benutzername oder das Kennwort ist falsch.

Wenn Sie nicht die erwartete Ausgabe erhalten, stellen Sie sicher, dass der Dienst für sekundäre Anmeldung im Zustand „Ausgeführt“ ist.

Zugriff auf Windows-Ereignisse mit PowerShell

Jetzt, da Sie sicher mindestens 35 Windows-Sicherheitsereignisse haben, lassen Sie uns sehen, wie Sie diese mit dem Get-WinEvent-Befehlslet von PowerShell finden können.

Sie kennen möglicherweise bereits das Get-EventLog-Befehlslet von PowerShell, das ebenfalls verwendet wird, um auf das Ereignisprotokoll programmgesteuert zuzugreifen. Get-EventLog verwendet eine veraltete Win32-Anwendungsprogrammierschnittstelle (API), über die in diesem Beitrag nicht diskutiert wird.

Öffnen Sie eine PowerShell-Konsole als Administrator und rufen Sie das Get-WinEvent-Cmdlet auf, wobei Sie die FilterHashtable– und MaxEvents-Parameter wie unten gezeigt übergeben.

Der folgende Befehl fragt das Sicherheitsprotokoll Ihres Systems ab (LogName='Security') nach Ereignis-ID 4625 (ID=4625) und gibt die ersten 10 neuesten Instanzen zurück (MaxEvents 10).

#Filtern Sie das Sicherheitsprotokoll nach den ersten 10 Instanzen der Ereignis-ID 4625
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 10

Bei Erfolg sehen Sie eine Ausgabe ähnlich der folgenden:

Zugriff auf Ereigniseigenschaften mit Get-WinEvent

In dem obigen Abschnitt haben Sie Get-WinEvent verwendet, um Windows-Sicherheitsereignisse auf oberster Ebene zu sehen, aber ein Windows-Ereignis enthält viel mehr Informationen. Jedes Windows-Ereignis hat wertvolle Eigenschaften, die Sie für eine tiefere Analyse verwenden können.

Windows-Ereignisse als XML

Wenn Windows ein Ereignis aufzeichnet, wird es im XML-Format gespeichert. Wenn das der Fall ist, warum hat Ihr Get-WinEvent-Befehl typische PowerShell-Objekte zurückgegeben? Das Get-WinEvent-Cmdlet liest die native Windows-API und übersetzt die Ereignisse in PowerShell-Objekte für eine erhöhte Funktionalität.

Jedes Windows-Ereignis hat verschiedene Attribute, die einem bestimmten XML-Schema oder einer Struktur folgen.

Sie sehen unten, dass jedes Ereignis einer spezifischen Struktur mit drei Attributen folgt:

• name – Der Name der Eigenschaft
• inType – Die Eingabetypdefinition oder wie das Ereignis einen Wert akzeptiert
• outputType – Die Ausgabetypdefinition oder wie das Ereignis aufgezeichnet wird

Finding Event XML Templates with PowerShell

Wie oben erwähnt, wird jedes Windows-Sicherheitsereignis in XML gespeichert und hat ein spezifisches Schema, aber wie sieht dieses Schema aus? Lassen Sie es uns herausfinden.

In einem der vorherigen Abschnitte haben Sie einige Ereignisse mit der ID 4625 im Sicherheitsereignisprotokoll generiert. Diese Art von Ereignis hat spezifische Attribute, die nur darauf zutreffen. Um diese Attribute und das Aussehen der Vorlage zu finden:

1. Öffnen Sie eine PowerShell-Konsole als Administrator, falls Sie sie nicht bereits geöffnet haben.

2. Führen Sie erneut Get-WinEvent aus, verwenden Sie diesmal jedoch den ListProvider-Parameter und geben Sie den Anbieter an, den Windows verwendet, um Ereignisse im Sicherheitsereignisprotokoll aufzuzeichnen. Geben Sie nur die Events-Eigenschaft zurück.

Die Events-Eigenschaft enthält alle Ereignisse, die der List-Anbieter aufgezeichnet hat, und gibt die XML-Vorlage für jedes dieser Ereignisse frei.

(Get-WinEvent -ListProvider 'Microsoft-Windows-Security-Auditing').Events

3. Jetzt, da Sie den Code haben, um Vorlagen für alle Ereignistypen zu finden, beschränken Sie dies, indem Sie nur das Ereignis mit der ID 4625 zurückgeben.

(Get-WinEvent -ListProvider 'Microsoft-Windows-Security-Auditing').Events | Where-Object -Property ID -eq 4625

4. Wenn Sie nur den Anmeldetyp mit der Ereignis-ID 4625 zurückgeben, beschränken Sie dies darauf, nur die Template-Eigenschaft wie unten angegeben anzuzeigen.

#Ereignis-XML-Vorlage für Ereigniseigenschaften der Ereignis-ID 4625 abrufen.
 ((Get-WinEvent -ListProvider 'Microsoft-Windows-Security-Auditing').Events | Where-Object -Property ID -eq 4625).Template

Das folgende Screenshot zeigt eine gekürzte Version der Code-Ausgabe und identifiziert den Ereignisnamen, den Eingabetyp und den Ausgabetyp. Sie können sehen, dass das Ereignis mit der ID 4625 Ereigniseigenschaften mit verschiedenen Eingabe- und Ausgabedefinitionen hat.

Der folgende Screenshot hebt die Eigenschaft SubjectUserSid des Ereignisses mit der ID 4625 hervor. Dieses spezielle Ereignis akzeptiert einen Eingabetyp (inType) von win:SID und gibt die Ausgabe (outType) als string aus, so wie sie im Sicherheitsprotokoll gespeichert ist.

Wie PowerShell XML in Objekte übersetzt

Nachdem Sie gesehen haben, wie Windows Ereignisse in XML speichert und wie Sie diese Vorlagen in PowerShell anzeigen können, widmen wir uns nun der Frage, wie PowerShell dieses XML in Objekte übersetzt.

1. Führen Sie den Befehl Get-WinEvent erneut aus, um unsere Ereignis-ID 4625 zurückzugeben. Bis jetzt ist das nichts Neues. Beachten Sie, dass PowerShell nur vier Eigenschaften anzeigt: TimeCreated, Id, LevelDisplayName und Message.

Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 1

Standardmäßig gibt der Get-WinEvent-Cmdlet nicht alle Attribute aus der XML-Datenquelle des Ereignisses als PowerShell-Objekt zurück.

2. Leiten Sie nun die Ausgabe des obigen Befehls zum Select-Object-Cmdlet und geben Sie den Property-Parameter mit einem Wert von „“ an, um alle Eigenschaften anzuzeigen.

Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 1 | Select-Object -Property *

Beachten Sie unten, dass PowerShell viele verschiedene Eigenschaften ausgeblendet hat. Genauer gesagt eine Eigenschaft namens Properties. Die Eigenschaft Properties enthält den Wert jedes Ereignisattributs, das Sie zuvor in der XML-Vorlage gesehen haben.

3. Begrenzen Sie die Ausgabe des Get-WinEvent-Befehls oben, um die Eigenschaften-Eigenschaft offenzulegen. Diese Eigenschaft speichert alle Ereigniseigenschaften, nicht PowerShell-Objekteigenschaften, in einem Array.

# Ausgabe Ereigniseigenschaften Array für die erste Instanz von Ereignis-ID 4625
 $eventProperties = (Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 1).properties
 $eventProperties

Auf der linken Seite des Screenshots unten befindet sich die Ausgabe des oben genannten Befehls. Das Array enthält die Werte für jede der XML-Attribute in der XML-Vorlage auf der rechten Seite des Screenshots.

Die Ausgabe des Codes im Screenshot zeigt, dass ein Authentifizierungsfehler für Benutzer AtaBlogUser (TargetUserName) vom System Desktop-XXXXX (WorkstationName) unter Verwendung einer IP-Adresse von ::1 (IpAddress) aufgetreten ist.

Vielleicht möchten Sie nur den Wert für die Ereigniseigenschaft TargetUserName zurückgeben. Da Sie bereits alle Ereigniseigenschaften in einer Variable namens $eventProperties gespeichert haben, verweisen Sie auf den fünften Index, der den Wert für TargetUserName enthält.

Sie müssen die value-Eigenschaft auf dem einzelnen Ereigniseigenschaftsobjekt referenzieren, um nur den Wert zurückzugeben (AtaBlogUser). $eventProperties[5].value

$eventProperties[5].value

Die in diesem Abschnitt beschriebenen Praktiken werden in den folgenden Abschnitten verwendet, um den Brute-Force-Angriff zu verfolgen, den Sie früher in diesem Beitrag simuliert haben.

Erkennung eines Brute-Force-Angriffs

Sie sind jetzt bereit, Ihre PowerShell-Fähigkeiten einzusetzen, um den Brute-Force-Angriff zu verfolgen, den Sie zuvor in diesem Beitrag repliziert haben! Lassen Sie uns Ihre Fähigkeiten auf die Probe stellen, indem wir simulieren, wie es aussehen könnte, einen Brute-Force-Angriff innerhalb eines bestimmten Zeitraums zu verfolgen.

Angenommen, Sie wurden über einen Vorfall informiert, bei dem Ihre Organisation glaubt, dass jemand versucht, sich mit einem Administratorkonto auf einem wichtigen Windows Server anzumelden. Diese Aktivität begann gestern. Sie müssen herausfinden, wie viele Ereignisse mit der Ereignis-ID 4625: Ein Konto konnte sich nicht anmelden in den letzten 24 Stunden aufgetreten sind und den Anmeldetyp jedes Ereignisses bestimmen.

1. Suchen Sie alle Ereignisse mit der ID 4625 (ID=4625) im Windows-Sicherheitsprotokoll (LogName="Security") für die letzten 24 Stunden (StartTime=((Get-Date).AddDays(-1).Date), bis zur aktuellen Zeit (Get-Date).

$events = Get-WinEvent -FilterHashTable @{LogName="Security";ID=4625;StartTime=((Get-Date).AddDays(-1));EndTime=(Get-Date)}

2. Zählen Sie nun alle Ereignisse, die in der Variablen gespeichert sind, um festzustellen, ob es mehr fehlgeschlagene Anmeldeereignisse gibt als erwartet.

$events.Count

Sie sollten jetzt einen numerischen Wert sehen, der angibt, wie oft die Ereignis-ID 4625 im Sicherheitsereignisprotokoll für die letzten 24 Stunden gefunden wurde.

3. Sie haben also festgestellt, dass ein Brute-Force-Angriff stattgefunden hat. Nun müssen Sie weitere Informationen zu diesen Windows-Sicherheitsereignissen finden. Um dies zu tun, geben Sie nur die Attribute der Ereignisse zurück, die Sie interessieren.

Wie bereits erwähnt, wird jeder Wert für ein bestimmtes Ereignis in einem Array mit einem spezifischen Index gespeichert. Die interessanten Ereigniseigenschaften für diese Demo sind unten aufgeführt.

• TargetUserName Index: [5]
• LogonType Index: [10]
• WorkstationName Index: [13]
• IpAddress Index: [19]

Das folgende Codebeispiel liest jedes Objekt in der Variable $events, sammelt nur die interessanten Eigenschaften und fügt sie zu einer einzigen Zeile zusammen.

#Extrahiere TargetUserName, LogonType, WorkstationName und IpAddress Ereigniseigenschaften aus allen Instanzen von Ereignis-ID 4625 in den letzten 24 Stunden.
 $events | ForEach-Object {
     ## Beziehe dich auf das Eigenschaftenobjekt
     ## Gib nur den Wert der Indizes 5, 10, 13 und 19 aus dem Eigenschaftenarray zurück
     ## Füge alle Werte zusammen, indem du sie mit einem Komma verbindest
     $_.properties[5,10,13,19].value -join ", "
 }

Der folgende Screenshot zeigt eine gekürzte Version der erwarteten Ausgabe des Codes, in der eine kommagetrennte Liste von TargetUserName, LogonType, WorkstationName und IpAddress detailliert aufgeführt ist.

Wie Sie bereits aus der XML-Vorlage gesehen haben, hat die Vorlage für Ereignis-ID 4625 ein LogonType-Attribut. Dieses Attribut gibt die Methode an, mit der der Account versucht hat, sich anzumelden. Durch weitere Untersuchungen haben Sie festgestellt, dass der LogonType gelegentlich unterschiedlich war.

Der Wert LogonType ist ein numerischer Wert von 2-11, aber was bedeutet das? Sie führen einige Recherchen durch und entdecken, was jeder Wert bedeutet.

2 – Interaktiv – Ein Benutzer hat sich an diesem Computer angemeldet.

3 – Netzwerk – Ein Benutzer oder Computer hat sich von einem Netzwerk aus an diesem Computer angemeldet.

4 – Batch – Batch-Anmeldeart wird von Batch-Servern verwendet, bei denen Prozesse im Auftrag eines Benutzers ohne direktes Eingreifen ausgeführt werden können.

5 – Dienst – Ein Dienst wurde vom Dienststeuerungs-Manager gestartet.

7 – Entsperren – Dieser Arbeitsplatz wurde entsperrt.

8 – Netzwerkdurchsichtig – Ein Benutzer hat sich von einem Netzwerk aus an diesem Computer angemeldet. Das Passwort des Benutzers wurde im unverschlüsselten Format an das Authentifizierungspaket übergeben. Die integrierten Authentifizierungspakete hashen alle Anmeldeinformationen, bevor sie über das Netzwerk gesendet werden. Die Anmeldeinformationen durchqueren das Netzwerk nicht im Klartext (auch als Klartext bezeichnet).

9 – Neue Anmeldeinformationen – Ein Aufrufer hat seinen aktuellen Token geklont und neue Anmeldeinformationen für ausgehende Verbindungen angegeben. Die neue Anmeldesitzung hat dieselbe lokale Identität, verwendet jedoch andere Anmeldeinformationen für andere Netzwerkverbindungen.

10 – Remoteinteraktiv – Ein Aufrufer hat seinen aktuellen Token geklont und neue Anmeldeinformationen für ausgehende Verbindungen angegeben. Die neue Anmeldesitzung hat dieselbe lokale Identität, verwendet jedoch andere Anmeldeinformationen für andere Netzwerkverbindungen.

11 – Zwischengespeicherte Interaktivität – Ein Benutzer hat sich an diesem Computer mit Netzwerkanmeldeinformationen angemeldet, die lokal auf dem Computer gespeichert waren. Der Domänencontroller wurde nicht kontaktiert, um die Anmeldeinformationen zu überprüfen.

Nun, da Sie ein gutes Verständnis für jeden LogonType haben, möchten Sie statt eines numerischen Werts in der Ausgabe einen beschreibenden String sehen. Verwenden Sie in PowerShell ein Hashtable, um „Maps“ zu erstellen.

$logonTypes = @{
     [uint32]2 = "Interactive"
     [uint32]3 = "Network"
     [uint32]4 = "Batch"
     [uint32]5 = "Service"
     [uint32]7 = "Unlock"
     [uint32]8 = "NetworkCleartext"
     [uint32]9 = "NewCredentials"
     [uint32]10 = "RemoteInteractive"
     [uint32]11 = "CachedInteractive"
 }

5. Kombinieren Sie Get-WinEvent und das LogonType-Hashtable mit ForEach-Object, um ein Skript zu erstellen, das nur die gewünschten Eigenschaften zurückgibt mit einem benutzerfreundlichen LogonType-Wert, wie unten gezeigt. Das Format-Table-Cmdlet trägt zur benutzerfreundlichen Ausgabe bei, indem es die Antwort von PowerShell als Tabelle formatiert.

#Verwenden Sie Get-WinEvent, um auf die Eigenschaften jeder protokollierten Instanz von Ereignis-ID 4625 zuzugreifen
$events = Get-WinEvent -FilterHashTable @{LogName="Security";ID=4625;StartTime=((Get-Date).AddDays(-1).Date);EndTime=(Get-Date)}
## Erstellen Sie die Zuordnung von numerischem Wert zu String
$logonTypes = @{
    [uint32]2 = "Interactive"
    [uint32]3 = "Network"
    [uint32]4 = "Batch"
    [uint32]5 = "Service"
    [uint32]7 = "Unlock"
    [uint32]8 = "NetworkCleartext"
    [uint32]9 = "NewCredentials"
    [uint32]10 = "RemoteInteractive"
    [uint32]11 = "CachedInteractive"
}
## Beginnen Sie mit der Verarbeitung jedes Objekts im Array $events
$events | ForEach-Object {
    ## Suchen Sie den numerischen Wert im Hashtable nach
    $logonType = $logonTypes[$_.properties[10].value] 
    #Erstellen Sie ein benutzerdefiniertes PowerShell-Objekt, um relevante Ereigniseigenschaften auszugeben
    [PSCustomObject]@{     
        TimeCreated = $_.TimeCreated     
        TargetUserName = $_.properties[5].value     
        LogonType = $logonType     
        WorkstationName = $_.properties[13].value     
        IpAddress = $_.properties[19].value 
    }
} | Format-Table -Wrap

Zu diesem Zeitpunkt haben Sie nun ein Skript, das Objekte vom Typ PSCustomObject zurückgibt und Ihnen ermöglicht, viele verschiedene Arten von Analysen durchzuführen! Um die Analyse dieses Tutorials abzuschließen, priorisieren Sie die Authentifizierungsfehlversuche nach TargetUserName. Um die Fehler nach der TargetUserName-Eigenschaft zu priorisieren, kombinieren Sie den obigen Code mit dem Group-Object-Cmdlet. Verwenden Sie Sort-Object und seinen Descending-Schalter, um den am meisten fehlerhaften Benutzer zu identifizieren.

#Mit Get-WinEvent auf die Eigenschaften jeder protokollierten Instanz von Ereignis-ID 4625 zugreifen
$events = Get-WinEvent -FilterHashTable @{LogName="Security";ID=4625;StartTime=((Get-Date).AddDays(-1).Date);EndTime=(Get-Date)}
## Erstellen Sie den numerischen Wert für den String "map"
$logonTypes = @{
    [uint32]2 = "Interactive"
    [uint32]3 = "Network"
    [uint32]4 = "Batch"
    [uint32]5 = "Service"
    [uint32]7 = "Unlock"
    [uint32]8 = "NetworkCleartext"
    [uint32]9 = "NewCredentials"
    [uint32]10 = "RemoteInteractive"
    [uint32]11 = "CachedInteractive"
}
## Beginnen Sie mit der Verarbeitung jedes Objekts im $events-Array
$events | ForEach-Object {
    ## Suchen Sie den numerischen Wert in der Hashtable nach
    $logonType = $logonTypes[$_.properties[10].value] 
    #Erstellen Sie ein benutzerdefiniertes PowerShell-Objekt, um relevante Ereigniseigenschaften auszugeben 
    [PSCustomObject]@{     
        TimeCreated = $_.TimeCreated     
        TargetUserName = $_.properties[5].value     
        LogonType = $logonType     
        WorkstationName = $_.properties[13].value     
        IpAddress = $_.properties[19].value 
    }
} | Group-Object -Property TargetUserName | Sort-Object -Property Count -Descending

Großartige Arbeit! Sie haben gerade PowerShell verwendet, um den simulierten Brute-Force-Versuch zu erkennen, den Sie zuvor in diesem Beitrag durchgeführt haben. Gemäß der Ausgabe hat AtaBlogUser in den letzten 24 Stunden 30-mal keine Authentifizierung durchgeführt!

Nächste Schritte

In diesem Tutorial haben Sie gelernt, wie Windows Ereignisse protokolliert, wie Sie die Ereignisprotokollierung für bestimmte Ereignistypen aktivieren und wie Sie ein PowerShell-Tool erstellen, um diese Ereignisse abzufragen.

Mit dem PowerShell-Skript, das Sie jetzt haben, wie können Sie es verbessern? Wie werden Sie den heute gelernten Code nehmen und ein besseres Tool erstellen?