Querying Windows Event Logs with PowerShell for Security Audits
Security audits rarely start with a clean inbox. Most sysadmins across Sydney, Brisbane, and Perth are asked to prove what happened on a server long after the event, and the only reliable witness is the Windows Event Log. PowerShell gives administrators a repeatable way to pull those records, filter them down to the security events that matter, and export them into formats that auditors and SIEM pipelines can consume.
The approach below assumes a hybrid Windows environment, whether that means a handful of servers in a Brisbane data centre or cloud instances spanning Australian time zones from AWST through to AEDT. Local drivers such as the Notifiable Data Breaches scheme and the ACSC Essential Eight shape what gets logged, retained, and reported, so the scripts here produce auditable, exportable output rather than screen-friendly text.
Preparing the PowerShell environment
Before running meaningful queries, the host needs PowerShell 5.1 or, preferably, PowerShell 7. The older Get-EventLog cmdlet is deprecated on newer Windows builds, so Get-WinEvent should be your default. You will need local administrator rights on the target server, or a domain account delegated Event Log Readers permissions through Group Policy.
Execution policy often catches out admins who copy scripts from a gist. Run Get-ExecutionPolicy -List to see the current scope, and either sign your script or set the policy to RemoteSigned on the test machine. If you are still building a safe place to rehearse these commands, the home lab resources on IT Diversified walk through an isolated setup that mirrors the domain-joined estate most Australian IT shops run.
Core cmdlets for querying event logs
The workhorse of modern log retrieval is Get-WinEvent. It supports both classic event logs and the newer applications-and-services logs generated for things like PowerShell script block logging and Sysmon. A simple starting point is to list the providers installed on a host:
Get-WinEvent -ListProvider * | Select-Object Name, LogLinks
To grab the last 24 hours of security log entries, use the -FilterHashtable parameter, which is far faster than piping through Where-Object for large logs. For example, to pull every successful and failed logon:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625; StartTime=(Get-Date).AddDays(-1)}
That single line replaces several minutes of clicking through Event Viewer.
Filtering events for security incidents
Raw event volume is the enemy of a useful audit. The Security log on a busy Melbourne file server can generate tens of thousands of events a day, so filtering is not optional. The most useful Event IDs to start with are 4624 (logon), 4625 (failed logon), 4648 (explicit credential use), 4720 (account created), 4732 (member added to security group), and 1102 (audit log cleared).
For more complex hunts, XPath is the right tool. A query like *[System[EventID=4625] and EventData[Data='Administrator']] lets you chase repeated failed logons for a specific account, often the first sign of a password spray. Pipe the results into Select-Object TimeCreated, Id, Message and Sort-Object TimeCreated -Descending so the most recent activity sits at the top of your export.
Exporting logs for auditors and SIEM
Once you have a useful subset, exporting is straightforward. Export-Csv is the most common choice for compliance teams working in Excel, while ConvertTo-Json plays better with downstream automation. Always specify -NoTypeInformation on Export-Csv to avoid the #TYPE header that breaks some parsers, and set -Encoding UTF8 so accented usernames do not get mangled.
A practical pattern is to drop the file onto a share that is itself backed up offsite, with a timestamped filename like "\\fs01\audit$\$(Get-Date -Format 'yyyyMMdd-HHmm').csv". For SIEM ingestion, write the JSON to a local directory first and let your forwarder pick it up, so a network blip does not cost you a gap in the audit trail.
Built-in tools versus PowerShell
Windows still ships with several ways to read and export event logs, and each has its place. The three options an Australian sysadmin is most likely to weigh up are compared below.
| Feature | Get-WinEvent | wevtutil (CLI) | Event Viewer (GUI) |
|---|---|---|---|
| Scriptable | Yes | Yes | No |
| XPath and filter hashtable support | Yes | Limited | Basic filter UI only |
| Works on remote hosts without RDP | Yes, via -ComputerName |
Yes, via wevtutil remote |
No |
| Export to CSV or JSON natively | Yes (via ConvertTo-Json/Export-Csv) | Export to .evtx only | Export to .evtx, CSV, XML |
| Best use case | Automation, ad-hoc analysis, SIEM feeds | Bulk archival of full .evtx files | Quick manual triage |
For repeatable audit work, Get-WinEvent wins. For long-term archival of the raw log file for legal hold, wevtutil epl is the cleanest path because it produces a tamper-evident .evtx file that can be re-imported later.
Scheduling routine audit exports
Manual exports do not survive a long weekend, so automation is essential. Task Scheduler is the most common approach, and it is worth creating a dedicated service account with the Event Log Readers right on every target server. Schedule the script during the quietest window for your site. A Perth-based shop running on AWST might prefer 2 am local, while a Melbourne team on AEDT may run at 3 am after the nightly backups finish.
Always log the script's own activity. Append a line to a local text file with the run time, the number of events exported, and any errors, so you can prove the job actually ran. Sending that run log to a separate monitoring mailbox gives you a cross-check that does not depend on the same server you are auditing.
Forwarding events to a central log store
Individual server exports are useful, but the real security value comes from correlation. Windows Event Forwarding lets you subscribe target servers to a central collector and pull the events you care about into a single repository, ready for Splunk, an ELK stack, or a managed SIEM.
For Australian organisations subject to the Privacy Act, centralising logs also helps satisfy data residency requirements. The collector and SIEM should sit in a region that meets your compliance obligations, and access to the forwarded data should be restricted through the same Group Policy controls you use for the source servers. With the query, filter, export, and forward pipeline in place, security auditing stops being a fire drill and becomes part of the normal operations rhythm.