PowerShell gebruiken om Security Event Logs te parseren en brute-force-pogingen te markeren

Nu steeds meer organisaties hun beveiliging tegen brute-force-aanvallen opschroeven, blijven registraties van zulke pogingen vaak onopgemerkt – totdat een inloggegeven wordt gecompromitteerd of een account wordt vergrendeld.

IT-beheerders kunnen PowerShell gebruiken om Security Event Logs op te halen en te parseren en zo de verdediging van hun organisatie te versterken. Deze gids beschrijft stap voor stap hoe u brute-force-aanvallen detecteert en blacklisting toepast met PowerShell.

Wilt u snel een visueel overzicht? Bekijk dan onze videogids PowerShell gebruiken om Security Event Logs te parseren en brute-force-pogingen te markeren

Security Event Logs instellen via PowerShell

Controleer voordat we beginnen of u aan de volgende vereisten voldoet:

📌 Vereisten:

• Beheerderstoegang tot lokale of externe systemen
• PowerShell 5.1+
• Windows Security Audit Log ingeschakeld via GPO
• Toegang tot het Windows-register om de detectiestatus te markeren
• RMM-platform (bijvoorbeeld NinjaOne) voor het uitrollen van scripts en notificaties
• Optioneel: event forwarding naar SIEM of gecentraliseerde logging

Stap 1: auditing van mislukte aanmeldingen inschakelen via Groepsbeleid

De eerste stap is controleren of auditing actief is op alle endpoints. Dit schakelt u in via Groepsbeleid. Zodra het is ingeschakeld, worden zowel geslaagde als mislukte aanmeldpogingen vastgelegd met gebeurtenis-ID’s zoals 4625 (mislukte aanmelding) en 4624 (geslaagde aanmelding).

Zo schakelt u auditing van mislukte aanmeldingen in:

1. Druk op Win + R, typ gpmc.msc en druk op Enter om de configuratie van het Groepsbeleid te openen.
2. Ga naar Computerconfiguratie > Beleidsregels > Windows-instellingen > Beveiligingsinstellingen > Geavanceerde configuratie van auditbeleid > Auditbeleid > Aanmelden/afmelden.
3. Pas de instelling voor Aanmelding controleren aan naar Geslaagd, Mislukt.

⚠️ Belangrijk: onjuiste instellingen voor Aanmelding controleren kunnen problemen veroorzaken. Lees er meer over in de sectie Waar u op moet letten.

Stap 2: mislukte aanmeldgebeurtenissen parseren met PowerShell

1. Open PowerShell als beheerder.
2. Gebruik de volgende opdrachten:
   • Parseer gebeurtenis-ID 4625 over de afgelopen 24 uur:

$events = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message

Let op: als er geen overeenkomende gebeurtenissen worden gevonden geeft de opdracht een lege resultatenset terug.

• • Haal de bronnen en gebruikersnamen van mislukte aanmeldingen op:

$failedLogons = $events | ForEach-Object {

if ($_.Message -match "(?s)Account For Which Logon Failed:.*Account Name:\s+(\S+).*Source Network Address:\s+(\S+)") {

[PSCustomObject]@{

Time = $_.TimeCreated

Username = $matches[1]

SourceIP = $matches[2]

}

}

}

• • Exporteren naar CSV:

$failedLogons | Export-Csv "C:\Reports\FailedLogons.csv" -NoTypeInformation

Stap 3: brute-force-patronen op basis van drempelwaarden herkennen

Zodra u gebeurtenissenlogboeken kunt parseren, kunt u patronen detecteren en drempelwaarden voor brute force toepassen om uw beveiliging aan te scherpen. Gebruik hiervoor de volgende PowerShell-opdrachten:

Groeperen en tellen op bron-IP of gebruikersnaam:

$grouped = $failedLogons | Group-Object SourceIP | Where-Object { $_.Count -ge 10 }
$grouped | ForEach-Object {
Write-Output "Potential brute-force from $($_.Name) with $($_.Count) attempts"
}

Dit script analyseert mislukte aanmeldgebeurtenissen op één computer, groepeert ze op bron-IP en rapporteert elk IP-adres met tien of meer mislukte pogingen als een mogelijke brute-force-aanval.

Let op: de drempelwaarde in deze regel is aanpasbaar. Het getal na Count -ge bepaalt hoeveel mislukte pogingen een brute-force-notificatie activeren.

💡 Tip: u kunt ook groeperen op gebruikersnaam om brute force gericht op een specifiek account te detecteren:

$groupedUsers = $failedLogons | Group-Object Username | Where-Object { $_.Count -ge 10 }

Drempelwaarden kunt u aanpassen aan uw risicobereidheid (bijvoorbeeld 5 of meer binnen 10 minuten).

Stap 4: detectie wegschrijven naar het register en naar logboeken die via CMD toegankelijk zijn

In stap 4 koppelt u geparseerde gebeurtenissen aan RMM en aan logboeken die via CMD toegankelijk zijn, voor meer inzicht en eenvoudiger herstel. Met de volgende sleutels activeert u notificaties in NinjaOne of schakelt u netwerktoegang automatisch uit:

Registertagging voor RMM of handmatige inspectie:

New-Item -Path "HKLM:\SOFTWARE\Org\SecurityAlerts" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\SecurityAlerts" -Name "LastBruteForceDetected" -Value (Get-Date).ToString("u")
Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\SecurityAlerts" -Name "OffendingIP" -Value $grouped[0].Name

CMD-controle van de detectiestatus:

reg query HKLM\SOFTWARE\Org\SecurityAlerts

⚠️ Waar u op moet letten

Volgende stappen: IP-adressen blokkeren of notificaties versturen

IP-adressen blokkeren, notificaties versturen en andere maatregelen volgen doorgaans nadat u uw Security Event Logs hebt geparseerd. Deze sectie behandelt acties die u met PowerShell kunt uitvoeren bij meerdere mislukte aanmeldpogingen of bij de detectie van een brute-force-aanval.

Gebeurtenis wegschrijven naar het gebeurtenissenlogboek:

Write-EventLog -LogName Application -Source "BruteForceDetector" -EventId 1010 -EntryType Warning -Message "Brute-force detected from $($grouped[0].Name)"
Let op: als de gebeurtenisbron niet bestaat kunt u deze eenmalig aanmaken (als beheerder) met:

New-EventLog -LogName Application -Source 'BruteForceDetector'

Daarnaast kunnen IT-beheerders ervoor kiezen het IP-adres lokaal te blokkeren (als de bron extern is):

New-NetFirewallRule -DisplayName "Block Brute IP" -Direction Inbound -RemoteAddress $grouped[0].Name -Action Block

💡 Let op: documenteer alle IP-blokkeringen en opschoonbeleidsregels in uw RMM om consistentie op al uw devices te waarborgen.

Aanvullende overwegingen bij brute-force-detectie en blacklisting met PowerShell

Lokale aanvallen versus RDP-aanvallen

Logboeken met brute-force-pogingen zien er anders uit, afhankelijk van de bron. Bij brute-force-pogingen via Remote Desktop Protocol (RDP) staat er meestal een extern IP-adres onder Source Network Address, terwijl een lokale brute-force-aanval alleen 127.0.0.1 toont. Het logontype controleren kan extra context geven.

Domeincontrollers

In Active Directory-omgevingen (AD) worden mislukte aanmeldpogingen doorgaans vastgelegd op de domeincontrollers (DC’s) en niet alleen op de werkplek waar is geprobeerd in te loggen. Het is aan te raden de PowerShell-scripts centraal of via event forwarding uit te voeren.

False positives

Niet elke reeks mislukte aanmeldingen komt door een brute-force-aanval. Serviceaccounts of synchronisatietools veroorzaken soms mislukte aanmeldingen. Houd uw detectie efficiënt door bekende veilige accounts uit te sluiten van de regels voor brute-force-detectie (dat kan door een whitelist in uw script op te nemen zodat die accounts automatisch worden overgeslagen)

SIEM-integraties

Voor organisaties met een Security Information and Event Management-systeem (SIEM) levert het integreren van brute-force-detectiegegevens aanzienlijk meer inzicht op. Stuur de gegevens indien mogelijk door naar een centrale logverzamelaar om aanvallen in uw hele omgeving te onderscheppen.

Veelvoorkomende problemen oplossen

Firewallregels worden niet toegepast

Als uw script een schadelijk IP-adres probeert te blokkeren met een PowerShell-firewallregel maar dit niet werkt, kan het probleem liggen bij de firewallprofielen of de scriptrechten. Windows-firewalls hebben afzonderlijke profielen (Domein, Privé, Openbaar) en de regel moet op het juiste profiel van toepassing zijn. Daarnaast kunnen PowerShell-uitvoeringsbeleidsregels of onvoldoende rechten verhinderen dat de opdracht wordt uitgevoerd. Voer het script altijd met beheerdersrechten uit en controleer of de systeemfirewall actief en correct geconfigureerd is.

Registervermeldingen worden niet bijgewerkt

Het wegschrijven van detectieresultaten naar het register vereist de juiste rechten, zeker wanneer het om HKLM:\SOFTWARE gaat. Voert een standaardgebruiker het script uit, dan mislukken de registerbewerkingen stilzwijgend of volgt er een toegangsfout. Zorg daarom dat het script in de context van Administrator of SYSTEM draait, wat u kunt afdwingen bij uitrol via tools zoals NinjaOne. Het is ook verstandig te controleren of de registersleutel bestaat en niet is afgeschermd door Groepsbeleid of software voor eindpuntbeveiliging.

Brute-force-detectie versterken met de diensten van NinjaOne

Met NinjaOne kunnen IT-beheerders en MSP’s schaalbare brute-force-detectie afdwingen en incidentrespons integreren via:

• Het uitrollen van PowerShell-detectiescripts op devices of klantgroepen
• Monitoring van registerwaarden of bestandsuitvoer om detectie te markeren
• Het activeren van geautomatiseerde herstelworkflows (notificaties, IP-blokkering, gebruikersmeldingen)
• Het genereren van klantoverstijgende rapporten met brute-force-pogingen en bron-IP’s
• Notificaties bij herhaalde detecties of accounts die doelwit zijn

Het Security Event Log ophalen met PowerShell

Met PowerShell Security Event Logs parseren op brute-force-pogingen geeft MSP’s een krachtige en schaalbare methode om aanvallen op inloggegevens te detecteren en erop te reageren. Deze gids biedt IT-beheerders een stappenplan en hulp bij het oplossen van veelvoorkomende problemen.

Gerelateerde onderwerpen:

• Windows-gebeurtenissenlogboeken lezen: afsluiten en opnieuw opstarten
• De beveiligingsgeschiedenis van Windows-beveiliging wissen in Windows 11
• Linux-logboeken begrijpen: overzicht met voorbeelden
• Wat is een brute-force-aanval?
• Brute-force-aanvallen detecteren en voorkomen met PowerShell