By Ronak Mishra · Security+ Certified · Wazuh Home Lab

Most cybersecurity courses hand you a list of Windows Event IDs and tell you to memorize them. What they don’t show you is what these events actually look like when they fire — the raw fields, the timestamps, the account names, the parent processes.

I set up a home lab running Wazuh SIEM connected to a Windows 11 agent and deliberately triggered each of these events to see exactly what gets captured. Every screenshot in this post is from that lab. No stock images, no theory — just real detections.

Here are the 5 event IDs that matter most when something bad is happening on a Windows machine.

Event ID 4625 Failed logon attempt

“An attacker is outside your network trying passwords one by one, hoping something works. This is what it looks like inside your SIEM before they get in.”

Event ID 4625 fires every time a Windows logon attempt fails. One or two of these is completely normal — people mistype passwords. But when you see a cluster of them hitting in rapid succession targeting the same account, that’s a brute force attack in progress.

The fields that matter most: targetUserName (who they’re targeting), subStatus (why it failed), and logonType (how they’re trying to get in). SubStatus code 0xc0000064 means the targeted user doesn’t even exist — a classic sign of username enumeration before a brute force.

I simulated this by running repeated failed logon attempts against a non-existent account called “fakeuser” on my Windows 11 VM. Here’s what Wazuh captured:

Expanding one of those alerts reveals exactly what happened at the field level — the targeted account name, the failure reason code, and the plain-English confirmation from Windows itself:

Event ID 4688 New process created

“Malware can’t do anything without running a process. This event fires the moment something executes — including the tools attackers use to steal credentials or move through a network.”

Every time a new process starts on Windows, Event ID 4688 fires — if process creation auditing is enabled. The key isn’t just what process ran, it’s what spawned it. The parent-child relationship tells the real story.

A legitimate user opening Notepad looks completely different from malware spawning PowerShell from inside a Word document. In an attack scenario, watch for: PowerShell or cmd spawned by Office applications, encoded command line arguments, or executables running from temp folders.

I triggered this by launching cmd, PowerShell, and Notepad from my Windows VM. Wazuh captured 345 process creation events — the spike you see in the chart is the exact moment those commands ran:

The expanded view shows the full execution chain in one log entry — exactly what process ran, what launched it, and who triggered it:

Event ID 4720 User account created

“The attacker is already inside. Now they’re creating a backdoor account so they can return even if their original access gets cut off.”

Event ID 4720 fires whenever a new local or domain user account is created. In a normal environment this should be rare and expected — IT provisioning a new employee, for example. If you see this event at 2am, created by a non-admin process, with no change ticket backing it up, that’s a persistence mechanism being installed.

This maps directly to MITRE ATT&CK T1136 — Create Account. It’s one of the most reliable persistence indicators in Windows environments because attackers almost always need a fallback entry point.

I created a test account called “testattacker” using PowerShell to simulate this. Wazuh caught it immediately — a single isolated event with zero noise around it:

The expanded view shows every detail Wazuh captured — the account name, who created it, and the event ID confirmed in yellow:

Event ID 4663 File or object accessed

“Ransomware touches hundreds of files in seconds. A credential-stealing tool targets one specific file. Either way — this event is watching.”

Event ID 4663 logs access attempts to specific files and folders when auditing is enabled. In Wazuh, the File Integrity Monitoring module captures this same behavior in real time — logging every file that gets created, modified, or deleted in monitored directories, including SHA1 and MD5 hashes before and after so you can prove exactly what changed.

Ransomware behavior looks like hundreds of these events firing in rapid sequence across multiple directories. A targeted attack looks like one precise access to a credential store or sensitive config file. Volume and pattern are everything.

My Wazuh FIM is running in realtime mode on monitored directories. I created a file called “you are hacked.txt” to trigger it deliberately. Here’s what got captured the moment that file was created:

How to think about these as a SOC analyst

Knowing what each event ID means in isolation is only half the skill. The real work is correlation — one event rarely tells the full story. Here’s how these connect in real attack scenarios:

• Multiple 4625s from one source followed by a 4624 right after — brute force that succeeded
• 4688 showing PowerShell spawned by an Office application — likely a phishing payload executing
• 4720 outside business hours with no change ticket — unauthorized persistence attempt
• Hundreds of 4663s firing across many files in under 30 seconds — ransomware encryption in progress

That pattern — two or more signals, a time window, a threshold — is the foundation of detection engineering. It’s what separates someone who reads logs from someone who builds detection rules. And it’s exactly the thinking SOC roles are looking for in interviews.

I’m building out more detection scenarios in my home lab and documenting everything as I go — Wazuh, Splunk, MITRE ATT&CK mapping, and more. If you’re on the same path — studying for CySA+, building your first SIEM lab, or working toward your first SOC role — feel free to connect on LinkedIn. Always good to compare notes with people actually doing the work.