Security Tools · Event log triage

Windows Event Log Triage Tool

Upload a Windows Security event log exported as CSV and get a plain-English triage report: who logged on, what failed, which accounts were created or given new rights — and which patterns a SOC analyst would want to look at more closely, with the reasons why and the innocent explanations too.

Your event log is analysed locally in your browser and is not uploaded anywhere. No server, no AI service, no analytics, no cookies. The page is locked so it cannot make network requests.

Educational SOC triage tool. Findings indicate activity that deserves investigation. They never prove compromise or malicious intent.
Only analyse logs from systems you own or are authorised to investigate.

Jump to: Analyse a log · How to think like a SOC analyst · Event ID reference · Export a log · Limitations

1. Load an event log

Works with Event Viewer’s Save All Events As… → CSV, PowerShell Get-WinEvent | Export-Csv, and SIEM-style CSVs with columns such as EventID, TargetUserName and IpAddress. Version 1 reads CSV only — not .evtx files. How to export.

Demo data

Fictional logs from a lab domain using private and documentation IP addresses. Each one uses a different export format.

Or download them to try the upload: normal · guessing · persistence · mixed lab

Suggested demo walkthrough
  1. Normal Activity: a quiet day. Two people mistype their password — below the threshold, so nothing fires. Only low-priority context appears.
  2. Password Guessing: one outside address tries nine account names (spraying), another guesses one password until it works (High). Compare with svc_reporting: also “repeated failures”, but every 5 minutes from an internal server — a stale saved password.
  3. Account Persistence: a new account is created at 23:41 and made an Administrator within a minute. Compare it with k.patel, onboarded at 10:05 into an ordinary group.
  4. Mixed SOC Lab: the whole story — spraying, a guessed RDP password, discovery commands, encoded PowerShell, a new admin, a service, then the log is cleared. Use the Event timeline to read it in order.
  5. The lesson: open any finding and read Possible benign explanations. Detection tells an analyst where to look; investigation decides what happened.

2. Detection thresholds

These numbers are educational defaults, not universal security thresholds. A domain controller in a large company sees thousands of failed logons a day; a home PC sees almost none. Tune them to the environment. Changes apply immediately.

Rules 1 & 2 · fires at this many or more
Rules 1 & 6 · time window
Rule 2 · failures this close before a success
Rule 3
Rule 5 · fires at this many or more
Rule 5 · 24-hour clock, e.g. 8
Rule 5 · e.g. 18 means 6 pm
Rule 6 · password spraying

How to Think Like a SOC Analyst

An alert is a question, not an answer. Your job is to find out which story the evidence supports.

  1. Start with what fired, and why. Read the evidence, not just the title. “15 failed logons in 6 minutes from the internet” is very different from “7 failures every 5 minutes from our own app server”.
  2. Identify the who, what, where and when. Which account? Which computer? From which address? At what time — and is that normal for this person?
  3. Build the timeline. Put related events in order. A failed logon means little; failures, then a success, then a new admin account, then a cleared log tells a story.
  4. Look for corroboration. One odd event is weak evidence. Several independent signals pointing the same way are strong evidence.
  5. Actively try to prove it benign. Check tickets, change records, rotas and the account owner. Most alerts have an innocent explanation; finding it quickly is a skill.
  6. Correlate with other sources. VPN, firewall, EDR, email and identity-provider logs can confirm or rule out what the Windows log suggests.
  7. Decide and document. Close it as benign (and tune the rule), keep watching, or escalate. Write down what you checked so the next analyst does not repeat it.

Common traps

Event ID Quick Reference

What each supported event means, and what an analyst looks at first. “Typical priority” is for one event on its own; correlation can raise it.

Logon types (in 4624 and 4625)

Why a logon failed (4625 Sub Status)

Getting a CSV out of Windows

Only export logs from computers you own or are authorised to investigate. Reading the Security log needs administrator rights.

Option A — Event Viewer (no typing)

  1. Press Win+R, type eventvwr.msc and press Enter.
  2. Open Windows Logs → Security.
  3. Optional: Filter Current Log… and enter 4624,4625,4720,4726,4728,4732,1102,4688 in the Event IDs box.
  4. Choose Save All Events As… (or Save Filtered Log File As…), set Save as type to CSV (Comma Separated), and save.
  5. Upload the CSV here.

Option B — PowerShell (run as administrator)

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4624,4625,4720,4726,4728,4732,1102,4688 } -MaxEvents 20000 |
  Select-Object TimeCreated, Id, MachineName, ProviderName, Message |
  Export-Csv -Path "$env:USERPROFILE\Desktop\security-events.csv" -NoTypeInformation -Encoding UTF8

The optional events live in other logs: service installs (7045) in System, and PowerShell script blocks (4104) in Microsoft-Windows-PowerShell/Operational. Export those the same way with a different LogName and combine the files, or upload them separately.

If an event never appears

Limitations

Educational SOC triage tool. Findings indicate activity that deserves investigation and never prove compromise or malicious intent. Only analyse logs from systems you own or are authorised to investigate.