Beginner·200 points·6 solves

Windows Event Log Analysis

Learn to read the Windows Security log the way an analyst does: recognise the core event IDs, interpret Logon Types, stitch scattered events into one session with the Logon ID, and spot account creation plus privileged group changes as persistence. You also learn why how an account logged on matters more than where it logged on from.

The vulnerability

You are a SOC analyst at ABC Finance on the morning of 22 April 2026. Overnight something happened on the finance file server FIN-FS-02 that alerted nothing loudly, and there is no alert feed this time. The raw Security log lives in /var/log/soc/security-events.json (about 350 events, one JSON object per line, filterable with jq), with the same events rendered in Event Viewer format in /var/log/soc/security-events.txt. Two references sit alongside: /var/log/soc/logon-types.md maps Logon Types and event IDs, and /var/log/soc/asset-inventory.csv records host ownership, the service account register, and change control. The whole investigation is derivable from those four files with time-based filtering and session correlation.

Your tasks

Reduce the volume with a time filter

With no alert to start from, time is the cheapest first cut. Filter security-events.json for events before 06:00 and roughly 350 events fall to nine. Read all nine rather than skimming them: note how many are logons, how many are logoffs, and which of them change the state of an account or a group instead of merely recording access. The nightly backup job runs in that window too, so expect legitimate activity in the results alongside whatever else is there.

Find the account that logged on in a way it never should

Group every successful logon by its Logon Type and count them. One type accounts for the overwhelming majority, which is a file server doing its job; the uncommon types are where to look, and logon-types.md explains what kind of access each one represents. List the accounts behind each uncommon type, then cross-reference asset-inventory.csv, which records host ownership and what each registered account is approved to do. Most of those accounts are doing something approved, so the type on its own gives you a shortlist and not a finding: the finding is the account for which that kind of logon is not an approved use at all.

Confirm against the account's own baseline

Once you have a candidate, list every logon it made across the whole day with the type and timestamp of each. Scheduled work logs on like a metronome: six logons at a fixed four-hour interval, eleven seconds past the hour, all of the same type. One event breaks that pattern on both timing and type, and the account's own history is what makes it visible - no threat feed required. Check the source address on that event against the approved corporate ranges in asset-inventory.csv while you are there, and note that it sits inside one of them. An internal address proves nothing either way.

Correlate the session by Logon ID

Every event in one logon session shares a Logon ID: it appears as TargetLogonId on the logon event itself and as SubjectLogonId on the actions taken during that session. Take the Logon ID off the anomalous logon and filter the log on both fields. Five events come back, spanning a window of under ten minutes - a logon, a special-privileges assignment, two changes to accounts or groups, then the logoff. Read them in timestamp order; the ordering is the narrative.

Read what was done during the session and map it to MITRE ATT&CK

Two of those five events change state rather than record access: a 4720 creates an account, and a 4732 adds a member to a security-enabled local group. Mind the field trap on 4732 - TargetUserName holds the group, and the account being added is in MemberName, written as a distinguished name. Check the change control section of asset-inventory.csv for a ticket authorising either change. Then work out what the operator gains from the new account later rather than immediately: that reasoning gives you the ATT&CK tactic, and the technique underneath it that covers what was done here.

Answer the questions

Start the lab, investigate the evidence in the terminal, and answer the questions here.

Hints

Loading…

Official write-up

Loading…

Frequently Asked Questions

Which Windows event IDs matter most in investigations?

Common ones include 4624 and 4625 for logons, 4672 for special privileges, 4720 for new accounts, 4732 for group membership changes and 7045 for new services. Together they show how an attacker gained and kept access.

How do you spot a persistent admin backdoor in Windows logs?

Look for newly created accounts, additions to privileged groups and new services or scheduled tasks, especially when they happen outside business hours and are performed by a service account that normally does none of this.

Is this Windows event log lab beginner-friendly and free?

Yes. It is free on Codelivly and designed for beginners. You analyse an overnight Security log with no alert to guide you, which builds the habit of hunting from raw evidence.

NEW350+ rooms now have a live terminal, so you can learn by typing the commands, right in your browser.Learn in a live terminal. 350+ rooms.Try a labCodelivly is 100% free, no paywall. If it helped you, chip in to keep it running.100% free. Help keep it so.Support us