Guides

Windows Event Logs and Sysmon for Beginner SOC

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Windows Event Logs record security-relevant activity (logons, process creation when enabled, account changes). Sysmon (Sysinternals) adds high-fidelity endpoint telemetry — process create, network connect, file create — that beginner SOC analysts use to rebuild “what happened” timelines. Defence only: install and read logs on systems you administer; no attack payloads.

Host events → (Sysmon enrich) → central SIEM → SOC triage notes
No forward = blind after wipe
IDs without context = noise

What do I need before this guide?

• Basic SOC / SIEM idea: What is SIEM?.
• Optional: EDR vs Antivirus.
• A Windows lab VM you own if you will install Sysmon.

What should a beginner SOC read first?

Core Windows Security events (starter)

1. 4624 — successful logon (check Logon Type: 2 interactive, 3 network, 10 remote interactive — know the common ones).
2. 4625 — failed logon (spray / password guess patterns).
3. 4648 — logon with explicit credentials (interesting lateral clues at high level).
4. 4720 / 4728-style account changes — new users / group membership (monitor tightly).
5. Enable process creation auditing carefully if Sysmon is not yet present (noise management matters).

Sysmon events (starter)

1. Event ID 1 — Process Create (Image, CommandLine, ParentImage — gold for investigation).
2. Event ID 3 — Network connection (which process talked where).
3. Event ID 11 — FileCreate (dropped tools / scripts — high-level detection).
4. Event ID 13 / registry (if enabled) — persistence clues for later modules.
5. Use a maintained config; default-everything can flood disks.

Educational warning: practise on your isolated lab or corporate lab with written approval. Do not enable aggressive auditing on production without change control.

Real incident: NotPetya (2017) — Windows estates and visibility gaps

Public reporting on NotPetya described destructive malware spreading across Windows environments at terrifying speed, with huge business outages. Defenders studying the aftermath emphasised endpoint logging, rapid isolation, and the cost of flat networks — themes that still shape SOC Windows monitoring today.

Takeaways (vertical):

1. What happened — destructive wormable impact on Windows-heavy organisations.
2. What went wrong (theme) — insufficient segmentation and slow understanding of process/network behaviour under stress.
3. Care-take — process ancestry and rare network destinations must be queryable centrally.
4. Care-take — backups and isolation playbooks beat perfect after-the-fact forensics alone.
5. Care-take — “we have Event Viewer” ≠ “SOC can hunt last 30 days”.
6. Bonus parallel — many ransomware IR reports start from missing or rotated-away endpoint logs.

Logon Type cheat sheet (memorise a few)

1. 2 — interactive (keyboard on the console).
2. 3 — network (SMB / similar access patterns).
3. 10 — remote interactive (RDP-style).
4. Unusual Type 10 from a rare country at 03:00 IST deserves a closer look with MFA / VPN context.
5. Pair with Sysmon process evidence before calling “compromised” — admins work nights too.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Clear or stop local logging after access (high-level).
• Blend into normal admin tools and signed binaries (“living off the land”).
• Create noise with failed logons elsewhere to distract.

Blue Team — defend, detect, respond

• Centralise Security + Sysmon; alert if forwarding stops.
• Baseline admin process trees; alert odd parents (for example Office spawning scripting hosts — tune carefully).
• Correlate 4624 rare-source with Sysmon network events.
• Preserve timelines before reimaging.

How do I practise step by step?

Step 1 — Lab baseline

1. Snapshot a Windows lab VM you own.
2. Confirm you can open Event Viewer → Windows Logs → Security.
3. Generate a controlled failed logon against that VM only; find 4625.
4. Note time in IST with a label when you write notes.

Step 2 — Install Sysmon safely

1. Download Sysmon only from the official Microsoft Sysinternals source.
2. Apply a known-good config used by your org or a well-reviewed community baseline (read it first).
3. Confirm Event Viewer → Applications and Services Logs → Microsoft → Windows → Sysmon → Operational.
4. Start a Notepad process; confirm Sysmon ID 1 appears.

Step 3 — Build an L1 mini playbook

For each alert or lab exercise write:

1. Host name and user.
2. Event IDs and Record IDs cited.
3. Parent → child process chain (from Sysmon 1).
4. Any network (Sysmon 3) destinations — reputation check via approved tools.
5. Decision: false positive / true positive / escalate.
6. Containment idea: isolate host via EDR / network; reset credentials if identity suspicious.

Step 4 — Ship to SIEM

1. Use Winlogbeat, Windows Event Forwarding, or your SIEM agent — product-specific docs.
2. Prove a lab event arrives within minutes.
3. Alert when the agent goes silent.

Step 5 — Tune before burnout

1. Exclude known software update storms carefully (document exclusions).
2. Keep high-signal rules: rare parent/child pairs, unexpected script hosts, sudden local account creation.
3. Review exclusions quarterly so attackers do not hide in them.

Step 6 — Pair with identity

1. Same user failing VPN then succeeding on the desktop?
2. New mailbox rule after odd 4624 Logon Type 10?
3. Windows endpoint truth + cloud identity truth together — see the SIEM guide.

Care-take — logs that still help at 2 a.m.

1. Central retention written down (hot / cold).
2. Clock sync (NTP) so timelines merge.
3. Alert on audit policy / Sysmon service stop.
4. Admin workstations get extra telemetry, not less.
5. Reimage only after volatile evidence plan — or you study a wiped disk.
6. Legal hold paths for serious cases (company IR / counsel).

How do I fix common Windows logging mistakes?

Ghabru naka 😅 — these are the usual ones: