How to Use PowerShell to Parse Security Event Logs and Flag Brute-Force Attempts

As more organizations amp up their security against brute-force attacks, records of such attempts are often unnoticed–until a credential is compromised or an account is locked out.

IT administrators can use PowerShell to get and parse Security Event Logs to strengthen their organization’s defense. This guide provides a step-by-step guide on brute force attack detection and blacklisting with PowerShell.

Set up Security Event Logs via PowerShell

Before we begin, make sure that you have the following prerequisites:

📌 Prerequisites:

• Administrative access to local or remote systems
• PowerShell 5.1+
• Windows Security Audit Log enabled via GPO
• Access to Windows Registry for flagging detection state
• RMM platform (e.g., NinjaOne) for deploying scripts and alerts
• Optional: Event forwarding to SIEM or centralized logging

Step 1: Enable logon failure auditing via Group Policy

The first step is to ensure that auditing is active on all endpoints. You can enable this via Group Policy. When enabled, both successful and failed logon attempts are recorded with event IDs such as 4625 (failed logon) and 4624 (successful logon).

To enable logon failure auditing:

1. Press Win + R, type gpmc.msc, and press Enter to open the Group Policy Configuration.
2. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff.
3. Modify the setting for Audit Logon – Success, Failure.

⚠️ Important: Incorrect Audit Logon settings may cause issues. Read more about it in the Things to look out for section.

Step 2: Use PowerShell to parse failed logon events

1. Open PowerShell as an administrator.
2. Use the following commands:
   • Parse Event ID 4625 over the last 24 hours:

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

Note: If no matching events are found, the command will return an empty result set.

• • Extract failed logon sources and usernames:

$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]

}

}

}

• • Export to CSV:

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

Step 3: Identify threshold-based brute-force patterns

Once you’re able to parse event logs, you can detect patterns and apply brute-force thresholds to tighten your security. To do this via PowerShell, apply the following commands:

Group and count by source IP or username:

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

This script analyzes failed logon events on a single computer, groups them by source IP, and reports any IP with 10 or more failed attempts as a potential brute-force attack.

Note: The threshold in this line is adjustable. The number after Count -ge can be changed to set the number of failed attempts that can trigger a brute-force alert.

💡 Tip: Alternatively, you can group by username to detect account-targeted brute-force:

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

Thresholds can be adjusted per risk appetite (e.g., 5+ in 10 minutes).

Step 4: Write detection to Registry and CMD-accessible logs

Step 4 deals with connecting parsed events to RMM and CMD-accessible logs for visibility and easier remediation. With the following keys, you can trigger alerts in NinjaOne or disable network access automatically:

Registry tagging for RMM or manual inspection:

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 check for detection status:

reg query HKLM\SOFTWARE\Org\SecurityAlerts

⚠️ Things to look out for

Next steps: Blocking IP or alerting

Blocking IP addresses, alerting, and other mitigation actions are usually done after you have parsed your Security Event Logs. This section focuses on actions you can take with PowerShell in the event of multiple failed login attempts or a brute force attack detection.

Write event to Event Log:

Write-EventLog -LogName Application -Source "BruteForceDetector" -EventId 1010 -EntryType Warning -Message "Brute-force detected from $($grouped[0].Name)"

Note: If the event source does not exist, you can create it once (as Administrator) with:

New-EventLog -LogName Application -Source ‘BruteForceDetector’

Additionally, IT administrators may opt to block the IP locally (if the source is external):

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

💡 Note: Document any IP blocks and cleanup policies in your RMM to ensure consistency across your devices.

Additional considerations when enforcing brute force attack detection and blacklisting with PowerShell

Local vs RDP attacks

Logs showing brute-force attempts look different, depending on the source. Remote Desktop Protocol (RDP) brute-force attempts usually show an external IP Address under Source Network Address, whereas a local brute-force attack only shows 127.0.0.1. Checking the Logon type may provide further context.

Domain controllers

In Active Directory (AD) environments, failed logon attempts are typically logged on the domain controllers (DCs), not just the workstation where the login was attempted. It is recommended that the PowerShell scripts be run centrally or via event forwarding.

False positives

Not all repeated logon failures are caused by failed brute-force attacks. Service accounts or sync tools may occasionally trigger failed logons. To maintain efficiency, exclude known safe accounts from brute-force detection rules (this can be done by adding a whitelist in your script so those accounts are skipped automatically)

SIEM integrations

For organizations with a Security Information and Event Management (SIEM) system, integrating brute-force detection data can significantly improve visibility. If available, pipe data to a central log collector to catch attacks throughout your environment.

Troubleshooting common issues

Firewall rules do not apply

If your script attempts to block an offending IP with a PowerShell firewall rule but doesn’t work, the issue may be with firewall profiles or script permissions. Windows Firewalls have separate profiles (Domain, Private, Public), and the rule must apply to the correct one. Additionally, PowerShell execution policies or insufficient privileges can prevent the command from running. Always run the script with administrative rights and confirm that the system firewall is active and properly configured.

Registry entries not updating

Writing detection results to the registry requires appropriate permissions, particularly when targeting HKLM:\SOFTWARE. If a standard user runs the script, registry writes will fail silently or throw an access error. To avoid this, ensure the script executes under Administrator or SYSTEM context, which can be enforced when deploying through tools like NinjaOne. It’s also wise to confirm the registry key exists and isn’t locked down by Group Policy or endpoint security software.

Enhance brute-force detection with NinjaOne services

With NinjaOne, IT administrators and MSPs can enforce scalable brute-force detection and integrate incident response through:

• Deploying PowerShell detection scripts across devices or client groups
• Monitoring registry values or file outputs to flag detection
• Triggering automated remediation workflows (alerts, IP blocking, user notifications)
• Generating cross-client reports showing brute-force attempts and source IPs
• Alerting on repeated detections or accounts being targeted

Use PowerShell to get the Security Event Log

Using PowerShell to parse Security Event Logs for brute-force attempts gives MSPs a powerful and scalable method to detect and respond to credential attacks. This guide provides a step-by-step guide and troubleshooting assistance for common issues for IT administrators.

Related topics:

• How to Read Windows Event Logs: Shutdown and Restart
• How to Clear Windows Security’s Protection History in Windows 11
• Understanding Linux Logs: Overview with Examples
• What Is a Brute Force Attack?
• Detecting and Preventing Brute Force Attacks with PowerShell