Hoe belangrijke Windows-beveiligingsgebeurtenissen bijhouden met PowerShell

Veel organisaties vertrouwen op Microsoft-technologieën om werk gedaan te krijgen. Tegelijkertijd kunnen bedreigingsactoren gebruikmaken van besturingssystemen zoals Windows. Gelukkig registreert Windows beveiligingsgebeurtenissen van het besturingssysteem om u te helpen dit gedrag op te sporen.

Beveiligingsgebeurtenissen geproduceerd door Windows dienen als een kritieke bron in het incidentrespons-proces. Tools zoals de Windows Event Viewer van Microsoft geven u de toegang die nodig is om vastgelegde gebeurtenissen te bekijken, maar het handmatig doorzoeken van een druk logboek om afwijkingen te detecteren, is onrealistisch.

In deze post leert u hoe u potentiële beveiligingsinbreuken in Windows kunt opsporen door meer te weten te komen over auditbeleid, Windows-logboeken en het analyseren van beveiligingsgebeurtenissen met PowerShell.

Vereisten

Deze handleiding is bedoeld om informatie over te brengen waarmee u leert hoe u Windows-beveiligingsgebeurtenissen kunt analyseren met PowerShell. Als u wilt meedoen met een van de demonstraties, heeft u het volgende nodig:

• 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.
• Beheerdersrechten op de Windows-pc
• A PowerShell code editor such PowerShell ISE or Visual Studio (VS) Code.

Waar Windows Beveiligingsgebeurtenissen Opslaat

Wanneer er een actie wordt ondernomen op een Windows-besturingssysteem, registreert Windows de actie als een gebeurtenis in één of meer gebeurtenislogboeken. Windows-gebeurtenislogboeken worden standaard opgeslagen op het bestandssysteem in de map %SystemRoot%\system32\winevt\logs. Deze locatie kan worden gewijzigd door de respectievelijke registerondervermelding van het gebeurtenislogboek aan te passen EventLog.

Als u wilt weten waar de belangrijkste gebeurtenislogboeken (Toepassing, Beveiliging en Systeem) op uw systeem zijn opgeslagen, kopieert en plakt u de onderstaande code in een PowerShell-console of slaat u deze op als een script.

Om toegang te krijgen tot de opslaglocatie van het Beveiligingslogboek, moet u de code uitvoeren als beheerder.

#Presenteer toepassings-, beveiligings- en systeemlogboeken in een array.
 $arrLogs = @(
     "Application"
     "Security"
     "System"
 )
 #Gebruik de ForEach-Object-cmdlet om elk respectief logboek te targeten met de Get-ItemProperty-cmdlet.
 $arrLogs | ForEach-Object {
     #Gebruik de Get-ItemProperty-cmdlet om het geconfigureerde bestandspad voor het toepassings-, beveiligings- en systeemlogboek weer te geven.
     Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\$_ -Name File | Select-Object PSChildName,File
 }

De onderstaande schermafbeelding toont de verwachte uitvoer van de code, waarbij de logboeknaam en opslaglocatie worden weergegeven voor het Toepassings, Beveiliging en Systeem logboekbestanden.

Auditbeleid: Definiëren van gebeurtenissen om op te nemen

Standaard legt Windows niet alle beveiligingsgebeurtenissen vast die nodig kunnen zijn om een inbreuk te detecteren of te onderzoeken. Om te bepalen wat Windows wel en niet opneemt, moet je auditbeleidsregels definiëren en toepassen. Een auditbeleid is een reeks instructies die aan Windows worden doorgegeven en die aangeeft welke gebeurtenissen moeten worden vastgelegd.

Er zijn verschillende manieren om auditbeleidsregels toe te wijzen en mee te werken, zoals Group Policy. Group Policy werkt goed als je auditbeleidsregels op veel machines moet implementeren. Maar in dit artikel ga je je beperken tot een enkel apparaat, dus je zult de auditpol-tool gebruiken. De auditpol-tool wordt meegeleverd met Windows en stelt je in staat om auditbeleidsregels op een Windows-systeem te vinden en in te stellen.

Het vinden van Auditbeleidsregels

Om bijvoorbeeld de status van alle auditbeleidsregels op je Windows-systeem te vinden, gebruik je de /get-parameter zoals hieronder weergegeven. Door de /category-parameter te gebruiken, gevolgd door een wildcard, vertelt auditpol om de status van alle auditbeleidsregels te vinden; niet slechts één die overeenkomt met een specifieke categorie of subcategorie.

#Verkrijg de auditbeleidsconfiguratie van het systeem.
auditpol /get /category:*

De volgende schermafbeelding toont een verkorte versie van de verwachte uitvoer van de code, met de auditbeleidscategorie Accountbeheer, subcategorieën en status (Instelling).

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

Instellen van Auditbeleid

De auditpol-tool kan meer dan alleen auditbeleidsinstellingen bekijken. Het kan ze ook wijzigen met behulp van het auditpol /set commando. Om toekomstige secties in deze tutorial te demonstreren, opent u een PowerShell-console als beheerder en voert u het onderstaande commando uit. Dit commando begint met het loggen van alle gebeurtenissen (succesvol en mislukt) die deel uitmaken van de Aanmelden subcategorie.

Het configureren van de Aanmelden subcategorie dwingt uw systeem om gebeurtenissen vast te leggen:

• 4624: Een account is succesvol aangemeld
• 4625: Een account kon niet worden aangemeld
• 4626: Gebruiker/ Apparaatclaims informatie
• 4648: Een aanmelding werd geprobeerd met expliciete referenties
• 4675: SIDs werden gefilterd

#Stel aanmeldingsgebeurtenissen in om succes/mislukking vast te leggen.
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

Er zijn tal van middelen beschikbaar om u te helpen bij het configureren van een auditbeleid volgens de best practices, waaronder het Center for Internet Security (CIS) Benchmarks en de Security Technical Implementation Guides (STIG) van het Defense Information Systems Agency (DISA), en richtlijnen gepubliceerd door Microsoft.

Het genereren van logs voor mislukte aanmeldingen voor analyse

Dit artikel zal een tutorial zijn en verwacht dat u meedoet. Als u Windows hebt geconfigureerd om aanmeldingsgebeurtenissen te controleren, laten we nu wat beveiligingsgebeurtenissen genereren voor latere analyse. Laten we specifiek 35 mislukte aanmeldingspogingen genereren die worden geregistreerd in het beveiligingslogboek van uw systeem om brute force-activiteit na te bootsen.

1. Open uw favoriete code-editor.

2. Kopieer de volgende code en plak het in de code-editor. Deze codepoging probeert het PowerShell.exe-proces te openen met behulp van het Start-Process-cmdlet met fictieve gebruikersnamen en wachtwoorden.

#Definieer 5 gebruikersnamen om vast te leggen als aanmeldingsmislukkingen.
 $arrUsers = @(
     "AtaBlogUser1"
     "AtaBlogUser2"
     "AtaBlogUser3"
     "AtaBlogUser4"
     "AtaBlogUser5"
 )
 #Loop door de gebruikersnamen met ForEach-Object om een aanmeldingsmislukking voor elk te genereren.
 $arrUsers | ForEach-Object {
     $securePassword = ConvertTo-SecureString "AtA810GRu13Z%%" -AsPlainText -Force 
     $storedCredential = New-Object System.Management.Automation.PSCredential($_, $securePassword)
     Start-Process -FilePath PowerShell -Credential $storedCredential
 }
 #Genereer 30 aanmeldingsmislukkingen voor gebruiker 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. Sla het PowerShell-script op als Invoke-BogusEvents.ps1 of een andere naam naar keuze en voer het script uit.

Wanneer uitgevoerd, zult u een verwachte foutmelding 35 keer herhaald zien worden, waarin staat De gebruikersnaam of het wachtwoord is onjuist.

Als u de verwachte uitvoer niet ontvangt, zorg er dan voor dat de Secondary Logon-service in de status Uitgevoerd is.

Toegang tot Windows-gebeurtenissen met PowerShell

Nu u er zeker van bent dat u ten minste 35 Windows-beveiligingsgebeurtenissen heeft, gaan we kijken hoe u ze kunt vinden met behulp van het Get-WinEvent-cmdlet van PowerShell.

U bent mogelijk bekend met PowerShell’s Get-EventLog-cmdlet, dat ook wordt gebruikt om toegang te krijgen tot het gebeurtenislogboek via programmeren. Get-EventLog gebruikt een verouderde Win32 Application Programming Interface (API) die niet wordt besproken in deze post.

Open een PowerShell-console als administrator en roep de Get-WinEvent cmdlet aan met de FilterHashtable en MaxEvents parameter zoals hieronder weergegeven.

De opdracht hieronder vraagt het beveiligingslogboek van uw systeem (LogName='Security') op voor gebeurtenis-ID 4625 (ID=4625) en geeft de eerste 10 nieuwste instanties terug (MaxEvents 10).

# Filter het beveiligingslogboek voor de eerste 10 instanties van Gebeurtenis-ID 4625
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 10

Als het succesvol is, zou u een uitvoer moeten zien die vergelijkbaar is met het volgende:

Toegang tot gebeurteniseigenschappen met Get-WinEvent

In het bovenstaande gedeelte gebruikte u Get-WinEvent om Windows-beveiligingsgebeurtenissen op een hoog niveau te bekijken, maar een Windows-gebeurtenis bevat veel meer informatie. Elke Windows-gebeurtenis heeft waardevolle eigenschappen die u kunt gebruiken voor diepgaande analyse.

Windows-gebeurtenissen als XML

Wanneer Windows een gebeurtenis registreert, wordt deze opgeslagen in XML-indeling. Als dat het geval is, waarom heeft uw Get-WinEvent opdracht dan typische PowerShell-objecten geretourneerd? De Get-WinEvent cmdlet leest de native Windows API en vertaalt de gebeurtenissen naar PowerShell-objecten voor verhoogde functionaliteit.

Elke Windows-gebeurtenis heeft verschillende attributen die een specifiek XML-schema of structuur volgen.

Hieronder ziet u dat elke gebeurtenis een specifieke structuur volgt met drie attributen:

• naam – De naam van de eigenschap
• inType – De invoertype definitie of hoe het evenement een waarde accepteert
• outputType – De uitvoertype definitie of hoe het evenement wordt geregistreerd

Het vinden van Event XML-sjablonen met PowerShell

Zoals hierboven vermeld, wordt elk Windows-beveiligingsevenement opgeslagen in XML en heeft het een specifiek schema, maar hoe ziet dat schema eruit? Laten we dat uitzoeken.

In een van de vorige secties heeft u een paar gebeurtenissen gegenereerd met ID 4625 in het beveiligingsevenementenlogboek. Dit type gebeurtenis heeft specifieke kenmerken die alleen op hem van toepassing zijn. Om die kenmerken te vinden en hoe het sjabloon eruitziet:

1. Open een PowerShell-console als beheerder als u deze nog niet hebt geopend.

2. Voer Get-WinEvent opnieuw uit, maar gebruik deze keer de ListProvider-parameter waarbij u de provider opgeeft die Windows gebruikt om gebeurtenissen naar het beveiligingsevenementenlogboek te registreren en alleen de Events-eigenschap retourneert.

De Events-eigenschap bevat alle gebeurtenissen die de lijstprovider heeft geregistreerd en maakt het XML-sjabloon voor elk van die gebeurtenissen beschikbaar.

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

3. Nu u de code heeft om sjablonen te vinden voor alle typen gebeurtenissen, beperkt u dat door alleen de gebeurtenis terug te geven die is gekoppeld aan ID 4625.

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

4. Zodra u alleen het aanmeldingstype met gebeurtenis-ID 4625 retourneert, beperkt u dat tot alleen de Template-eigenschap zoals hieronder weergegeven.

#Ontvang gebeurtenis-XML-sjabloon voor gebeurteniskenmerken van gebeurtenis-ID 4625.
 ((Get-WinEvent -ListProvider 'Microsoft-Windows-Security-Auditing').Events | Where-Object -Property ID -eq 4625).Template

De volgende schermafbeelding toont een verkorte versie van de uitvoer van de code, waarbij de naam van de gebeurteniseigenschap, het invoertype en het uitvoertype worden geïdentificeerd. U kunt zien dat gebeurtenis-ID 4625 gebeurteniseigenschappen heeft met verschillende invoer- en uitvoerdefinities.

De onderstaande schermafbeelding benadrukt de eigenschap SubjectUserSid van gebeurtenis-ID 4625. Deze specifieke gebeurtenis accepteert een invoertype (inType) van win:SID en geeft de uitvoer (outType) weer als een string, zoals opgeslagen in het beveiligingslogboek.

Hoe PowerShell XML vertaalt naar objecten

Nu u heeft gezien hoe Windows gebeurtenissen opslaat in XML en hoe u die sjablonen in PowerShell kunt bekijken, laten we eens kijken hoe PowerShell die XML omzet in objecten.

1. Voer het commando Get-WinEvent opnieuw uit om onze gebeurtenis-ID 4625 terug te krijgen. Tot nu toe is dit niets nieuws. Merk op dat PowerShell slechts vier eigenschappen toont, TimeCreated, Id, LevelDisplayName en Message.

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

Standaard retourneert de cmdlet Get-WinEvent niet alle attributen van de XML-gegevensbron van de gebeurtenis als een PowerShell-object.

2. Pijp nu de uitvoer van het bovenstaande commando naar de cmdlet Select-Object en specificeer de parameter Property met een waarde van om alle eigenschappen te tonen.

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

Merk op dat PowerShell hieronder veel verschillende eigenschappen verborg. Meer specifiek een eigenschap genaamd Properties. De eigenschap Properties bevat de waarde van elk gebeurtenisattribuut dat u eerder in het XML-sjabloon zag.

3. Beperk de uitvoer van het Get-WinEvent-commando hierboven om de eigenschap Properties bloot te leggen. Deze eigenschap slaat alle gebeurtenis-eigenschappen op, niet PowerShell object eigenschappen, in een array.

#Uitvoer gebeurtenis eigenschappen array voor het eerste exemplaar van Gebeurtenis-ID 4625
 $eventProperties = (Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 1).properties
 $eventProperties

Aan de linkerzijde van de onderstaande schermafbeelding staat de uitvoer van het bovenstaande commando. De array bevat de waarden voor elk van de XML-attributen in de XML-sjabloon aan de rechterkant van de schermafbeelding.

De uitvoer van de code in de schermafbeelding geeft aan dat er een authenticatiefout is opgetreden voor gebruiker AtaBlogUser (TargetUserName) van systeem Desktop-XXXXX (WorkstationName) met gebruik van een IP-adres van ::1 (IpAddress).

Misschien wilt u alleen de waarde teruggeven voor de gebeurtenis eigenschap TargetUserName. Aangezien u alle gebeurtenis eigenschappen al hebt opgeslagen in een variabele genaamd $eventProperties, verwijst u naar het vijfde index, dat de waarde voor TargetUserName bevat.

U moet de value-eigenschap op het individuele gebeurtenis eigenschapsobject verwijzen om alleen de waarde terug te geven (AtaBlogUser). $eventProperties[5].value

$eventProperties[5].value

De in dit gedeelte beschreven praktijken zullen worden gebruikt in de volgende secties om de brute force poging die u eerder in dit bericht heeft gesimuleerd, op te sporen.

Het opsporen van een Brute Force-aanval

Je bent nu klaar om je PowerShell-vaardigheden te gebruiken om de brute force-aanval op te sporen die je eerder in deze post hebt gerepliceerd! Laten we je vaardigheden op de proef stellen door te simuleren hoe het eruit zou kunnen zien om een brute force-aanval op te sporen op basis van een specifieke tijdsperiode.

Stel dat je op de hoogte bent gebracht van een incident waarbij jouw organisatie vermoedt dat iemand probeert in te loggen op een belangrijke Windows Server met een beheerdersaccount. Deze activiteit is gisteren begonnen. Je moet ontdekken hoeveel gebeurtenissen met gebeurtenis-ID 4625: Een account kon niet worden aangemeld zich hebben voorgedaan in de afgelopen 24 uur en het aanmeldingstype van elke gebeurtenis bepalen.

1. Zoek alle gebeurtenissen met ID 4625 (ID=4625) in het Windows-beveiligingslogboek (LogName="Security") voor de afgelopen 24 uur (StartTime=((Get-Date).AddDays(-1).Date), eindigend op het huidige tijdstip (Get-Date).

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

2. Tel nu alle gebeurtenissen die zijn opgeslagen in de variabele om te bepalen of er meer mislukte aanmeldgebeurtenissen zijn dan verwacht.

$events.Count

Je zou nu een numerieke waarde moeten zien die aangeeft hoe vaak gebeurtenis-ID 4625 is gevonden in het beveiligingslogboek van de afgelopen 24 uur.

3. Nu je hebt vastgesteld dat er een brute force-aanval heeft plaatsgevonden, ga je op zoek naar meer informatie over deze Windows-beveiligingsgebeurtenissen. Doe dit door alleen de eigenschappen van elke gebeurtenis te retourneren waarin je geïnteresseerd bent.

Zoals eerder vermeld, wordt elke waarde voor een specifieke gebeurtenis opgeslagen in een array met een specifieke index. De interessante eigenschappen voor deze demo zijn hieronder.

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

De onderstaande codevoorbeeld leest elk object in de variabele $events, verzamelt alleen de interessante eigenschappen en concateneert ze tot één regel.

# Extract TargetUserName, LogonType, WorkstationName, and IpAddress event properties from all instances of Event ID 4625 in the last 24 hours.
 $events | ForEach-Object {
     ## Verwijs naar het eigenschappenobject
     ## Geef alleen de waarde van indexen 5, 10, 13 en 19 terug uit de eigenschappenarray
     ## Concateneer alle waarden door ze met een komma te verbinden
     $_.properties[5,10,13,19].value -join ", "
 }

De onderstaande schermafbeelding toont een ingekorte versie van de verwachte uitvoer van de code, met een lijst van TargetUserName, LogonType, WorkstationName, en IpAddress gescheiden door komma’s.

4. Zoals je eerder zag in de XML-template, heeft event ID 4625 een LogonType-attribuut. Dit attribuut geeft de methode aan waarin het account heeft geprobeerd te authenticeren. Na verder onderzoek merkte je op dat de LogonType af en toe verschilde.

De LogonType-waarde is een numerieke waarde van 2-11, maar wat betekent dat? U doet wat onderzoek en ontdekt wat elke waarde betekent.

2 – Interactief – Een gebruiker heeft zich aangemeld bij deze computer.

3 – Netwerk – Een gebruiker of computer heeft zich aangemeld bij deze computer vanaf het netwerk.

4 – Batch – Batch-aanmeldingstype wordt gebruikt door batch-servers, waar processen mogelijk worden uitgevoerd namens een gebruiker zonder hun directe tussenkomst.

5 – Service – Een service werd gestart door de Service Control Manager.

7 – Ontgrendelen – Deze werkstation is ontgrendeld.

8 – NetwerkCleartext – Een gebruiker heeft zich aangemeld bij deze computer vanaf het netwerk. Het wachtwoord van de gebruiker werd doorgegeven aan het authenticatiepakket in ongehashte vorm. De ingebouwde authenticatiepakketten hashen alle referenties voordat ze ze over het netwerk verzenden. De referenties worden niet in platte tekst (ook wel cleartext genoemd) over het netwerk verzonden.

9 – NieuweCredentials – Een beller heeft zijn huidige token gekloond en nieuwe referenties opgegeven voor uitgaande verbindingen. De nieuwe aanmeldsessie heeft dezelfde lokale identiteit, maar gebruikt andere referenties voor andere netwerkverbindingen.

10 – RemoteInteractief – Een beller heeft zijn huidige token gekloond en nieuwe referenties opgegeven voor uitgaande verbindingen. De nieuwe aanmeldsessie heeft dezelfde lokale identiteit, maar gebruikt andere referenties voor andere netwerkverbindingen.

11 – CachedInteractief – Een gebruiker heeft zich aangemeld bij deze computer met netwerkreferenties die lokaal op de computer waren opgeslagen. De domeincontroller werd niet gecontacteerd om de referenties te verifiëren.

Nu je een goed begrip hebt van elke LogonType, wil je in plaats van een numerieke waarde in de uitvoer een meer beschrijvende string zien. Gebruik een hashtable om “maps” te maken in PowerShell.

$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. Combineer Get-WinEvent en de LogonType hashtable met ForEach-Object om een script te maken dat alleen de gewenste eigenschappen teruggeeft met een gebruikersvriendelijke LogonType-waarde, zoals hieronder getoond. Het Format-Table-cmdlet voegt toe aan de gebruikersvriendelijke uitvoer door de reactie van PowerShell te formatteren als een tabel.

#Gebruik Get-WinEvent om toegang te krijgen tot de eigenschappen van elke gelogde instantie van Gebeurtenis-ID 4625
$events = Get-WinEvent -FilterHashTable @{LogName="Security";ID=4625;StartTime=((Get-Date).AddDays(-1).Date);EndTime=(Get-Date)}
## Maak de numerieke waarde naar 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"
}
## Begin met het verwerken van elk object in de $events-array
$events | ForEach-Object {
    ## Zoek de numerieke waarde op in de hashtable
    $logonType = $logonTypes[$_.properties[10].value] 
    #Maak aangepast PowerShell-object om relevante gebeurteniseigenschappen uit te voeren 
    [PSCustomObject]@{     
        TimeCreated = $_.TimeCreated     
        TargetUserName = $_.properties[5].value     
        LogonType = $logonType     
        WorkstationName = $_.properties[13].value     
        IpAddress = $_.properties[19].value 
    }
} | Format-Table -Wrap

Op dit punt heb je nu een script dat objecten van het type PSCustomObject retourneert, waardoor je veel verschillende soorten analyses kunt uitvoeren! Om de analyse van deze tutorial af te ronden, geef je de pogingen tot authenticatiefouten prioriteit op basis van TargetUserName. Combineer om de mislukkingen te prioriteren op basis van de TargetUserName-eigenschap de bovenstaande code met het Group-Object-cmdlet. Gebruik Sort-Object en zijn Descending-schakelaar om de hoogst overtredende gebruiker te identificeren.

#Gebruik Get-WinEvent om toegang te krijgen tot de eigenschappen van elke gelogde gebeurtenis met gebeurtenis-ID 4625
$events = Get-WinEvent -FilterHashTable @{LogName="Security";ID=4625;StartTime=((Get-Date).AddDays(-1).Date);EndTime=(Get-Date)}
## Creëer de numerieke waarde naar de 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"
}
## Begin met het verwerken van elk object in de $events-array
$events | ForEach-Object {
    ## Zoek de numerieke waarde op in de hashtable
    $logonType = $logonTypes[$_.properties[10].value] 
    #Maak aangepast PowerShell-object om relevante gebeurteniseigenschappen weer te geven
    [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

Goed werk! Je hebt zojuist PowerShell gebruikt om de brute force-poging te detecteren die je eerder in deze post hebt gesimuleerd. Volgens de output slaagde AtaBlogUser er niet in om 30 keer in te loggen in de laatste 24 uur!

Volgende stappen

In deze tutorial heb je geleerd hoe Windows gebeurtenissen logt, hoe je gebeurtenisregistratie kunt inschakelen voor bepaalde gebeurtenistypen, en hoe je een PowerShell-tool kunt bouwen om deze gebeurtenissen te doorzoeken.

Met het PowerShell-script dat je nu hebt, hoe kun je het verbeteren? Hoe ga je de code die je vandaag hebt geleerd gebruiken om een betere tool te bouwen?