Monitor Windows Security Events with PowerShell

The Windows Security event log provides valuable evidence about authentication, privilege use, account changes, and system activity. Its raw records are difficult to interpret manually, particularly on busy servers, but PowerShell can collect and filter events consistently across a fleet of Windows hosts.

Using PowerShell to monitor Windows Event Log for security anomalies is most effective when events are correlated with identity, source address, time, and normal administrative activity. A failed login, for example, may be suspicious during unusual hours but harmless during a morning password reset.

The workflow begins with selecting relevant event identifiers, normalising their XML data, and then applying sensible detection rules. The resulting findings can be sent to a security team, a SIEM, or a scheduled report without requiring a full-time analyst to watch the event stream.

Capture the right event data

Start with a narrow set of security events covering authentication, account administration, group membership, process creation, and privilege assignment. XML parsing is more reliable than relying on message text because Windows event messages can be localised.

function Convert-SecurityEvent {
    param([Parameter(ValueFromPipeline = $true)]$Event)

    process {
        [xml]$xml = $Event.ToXml()
        $data = @{}

        foreach ($node in $xml.Event.EventData.Data) {
            $data[$node.Name] = [string]$node.'#text'
        }

        [pscustomobject]@{
            Time       = $Event.TimeCreated
            EventId    = $Event.Id
            RecordId   = $Event.RecordId
            User       = $data['TargetUserName']
            LogonType  = $data['LogonType']
            Source     = $data['IpAddress']
        }
    }
}

$since = (Get-Date).AddMinutes(-15)
$ids = 4624,4625,4672,4688,4719,4720,4726,4728,4732,4768,4769,4776,1102

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = $ids
    StartTime = $since
} -ErrorAction SilentlyContinue | Convert-SecurityEvent

Event 4688 is only useful when Process Creation auditing is enabled, while command-line details require an additional audit policy setting. Likewise, several account and group events depend on Advanced Audit Policy rather than legacy audit categories.

Turn events into actionable findings

Treat each event as a signal rather than a verdict. A useful first detection is a burst of failed authentication attempts from one account, but the threshold should reflect the organisation’s environment and be compared with VPN, endpoint, and identity-provider records.

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = $since
} | Convert-SecurityEvent |
    Where-Object { $_.User -and $_.User -notmatch '\$$' } |
    Group-Object User |
    Where-Object { $_.Count -ge 10 }

Other patterns include successful network or RDP logons from previously unseen addresses, new administrator accounts, and unexpected additions to privileged groups. Event 4624 with LogonType 3 indicates a network logon, while type 10 represents Remote Desktop Services. Neither is inherently suspicious, but both benefit from source-address context.

Thresholds should be tuned against false positives. Shared service accounts, scheduled jobs, backup agents, kiosk devices, and staff working different shifts can all create regular authentication patterns that would otherwise generate persistent noise.

Verify audit and retention settings

Monitoring cannot detect an event that Windows never recorded or has already removed. Review the audit policy on each Windows Server and endpoint, including domain controllers, where identity changes have the greatest impact.

auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Detailed Tracking"

Use Group Policy where possible so the configuration remains consistent across the estate. Enable success and failure auditing for logons, and enable Process Creation auditing when command execution is required. Command-line auditing increases visibility but can expose sensitive arguments, so it should be paired with appropriate event-log access controls.

Retention also matters. Size the Security log for the busiest host and the longest acceptable investigation window, enable rollover, and avoid clearing the log manually. Central collection through Windows Event Forwarding or a SIEM agent provides a second copy and protects evidence if the local machine is rebuilt or compromised.

Signals for a first deployment

Begin with alerts that have clear investigative value and a known supporting data source. This keeps the initial output manageable while revealing where local context is missing.

• Authentication pressure: repeated event 4625 records for one account, particularly from several source addresses within a short period.
• New logon paths: event 4624 with logon type 3 or 10 from an address outside the account’s established pattern.
• Directory changes: events 4720, 4726, 4728, or 4732 involving administrators, service accounts, or sensitive groups.
• Sensitive actions: event 4672 for privileged use, 4768 or 4769 for unusual ticket activity, 4719 for audit changes, and 1102 for a cleared log.

These signals should generate an investigation record containing the host, account, source, timestamp, and nearby events. Events such as 4672 and 4768 commonly occur during legitimate administration, so their value depends heavily on matching them to change records and expected administrator schedules.

Apply Australian operating context

Australian operating conditions affect what should be considered normal. Time zones, hybrid work routines, the technology mix used by local organisations, and privacy obligations all influence alert quality.

• Time handling: Sydney and Melbourne change between AEDT and AEST, while Brisbane remains on AEST. Store monitoring data in UTC and convert it to local time when presenting findings.
• Everyday access patterns: staff in Sydney, Melbourne, and Brisbane may move between CBD offices, home connections, and shared workstations. Combine logon alerts with badge, VPN, and roster information.
• Technology landscape: many Australian organisations combine Microsoft 365, Defender for Endpoint, and Entra ID with on-premises Active Directory and VMware estates. Local Security events cannot reveal cloud-only authentication.
• Privacy requirements: event logs can contain names, addresses, and operational details. Apply the Privacy Act 1988 and the Notifiable Data Breaches scheme when a suspected compromise may involve personal information.

Changes made during weekends, public holidays, or agreed maintenance windows should not be discarded automatically. They should be compared with change records and the responsible team’s roster. A discrepancy may identify an undocumented change rather than an immediate compromise.

Schedule and centralise the monitor

Run the collector through Task Scheduler at a short interval, such as five or ten minutes. Use a dedicated service account with read access to the Security log and only elevate it where the operating system requires additional privileges. Windows PowerShell 5.1 is included with Windows, while PowerShell 7 provides a modern cross-platform management environment.

Use a small overlap between runs and the event RecordId to prevent duplicate findings:

$checkpoint = 'C:\ProgramData\SecurityMonitor\last-record.txt'
$lastRecord = if (Test-Path $checkpoint) {
    [int](Get-Content $checkpoint)
} else { 0 }

$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = $ids
    StartTime = (Get-Date).AddMinutes(-10)
}

$newEvents = $events |
    Where-Object RecordId -gt $lastRecord |
    Sort-Object RecordId

if ($newEvents) {
    $newEvents | Convert-SecurityEvent |
        Export-Csv 'C:\ProgramData\SecurityMonitor\events.csv' -Append
    ($newEvents | Select-Object -Last).RecordId |
        Set-Content $checkpoint
}

Protect the checkpoint and output directory, and treat event 1102 as both a high-priority alert and a reason to validate collector state. Forward the same normalised records to Defender, Microsoft Sentinel, Splunk, Elastic, or an internal webhook. A staged rollout then establishes a reliable baseline while preserving a consistent collection path for ongoing detection and investigation.