Your First Windows Security Log Investigation

What you’ll learn

• Locate and filter the Windows Security log without clearing it.
• Compare event 4624 (a logon session was created) and 4625 (a failed logon attempt).
• Read target account, logon type, timestamp and available source fields.
• Separate observed evidence from assumptions and communicate a finding.

Before you start

• A Windows 11 PC or VM you own and control, with access to a local administrator account to read Security logs and check audit settings. A disposable VM with a snapshot is recommended. This exercise does not require a SIEM, paid tools, cloud services or an Active Directory domain.
• Use a dedicated standard local test account with a password you know. Keep your administrator session available. Avoid work/school devices, real company accounts, Microsoft account/Windows Hello sign-ins and any device whose policy you do not manage.
• If you need a test account, open Settings → Accounts → Other users → Add account. Choose “I don’t have this person’s sign-in information” then “Add a user without a Microsoft account”, where offered. Create a standard local user with a unique lab-only password. Windows wording varies by version.
• Know the account’s lockout policy before testing. Make at most one deliberate failed attempt, only with the test account. If the policy or current failure count is unknown, use existing records instead. Do not disable account lockout or other security controls.
• Record the lab’s local time and time zone. Never publish raw Security logs, passwords or personal information. You will sanitise your final evidence.

1. Check the lab and audit settings

1. Save your work and take a VM snapshot if available. Note the Windows edition/build and the test account name.
2. Search Start for Event Viewer, choose Run as administrator and open Windows Logs → Security. This log contains sensitive information; keep it inside your lab.
3. In an administrator Command Prompt, check the Logon audit subcategory with the read-only command below. Success and Failure auditing are needed to record both types of activity. This GUID avoids language-specific policy names.

auditpol /get /subcategory:"{0CCE9215-69AE-11D9-BED3-505054503030}"

If either setting is disabled, record its original value first. On your own disposable lab only, enable both with the command below, or use Local Security Policy → Advanced Audit Policy Configuration → System Audit Policies → Logon/Logoff → Audit Logon, if that console is available. Never change managed policy.

auditpol /set /subcategory:"{0CCE9215-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

Run the read-only check again to verify. Auditing records future activity; changing a setting cannot recreate missing historical events.

2. Generate a small, controlled example—or use existing records

The safest option is to find existing 4624/4625 events in your lab and document their context. If none exist and you know your test account’s lockout policy, use this controlled exercise:

1. Note the start time. From a normal Command Prompt, run the command below, replacing LABUSER with your dedicated local test account. The account must have a password, and the Secondary Logon service must be available.
2. Enter the correct lab password at the prompt (input is hidden). A new command window should open as that account. Run whoami there to confirm, then close that window. This should create a 4624 logon event when Success auditing is enabled.
3. Only if the account is known to be safe to test, run the same command once more and deliberately enter one incorrect password. Expect an error and a 4625 event when Failure auditing is enabled. Stop after this single failure. Do not automate retries or use /netonly or /savecred.
4. Record the end time. Return to Event Viewer in your administrator session and refresh the Security log.

runas /user:%COMPUTERNAME%\LABUSER cmd.exe

If RunAs is unavailable, use existing records. Alternatively, on a disposable VM with the administrator session preserved, use Switch user to sign in with the test account’s password. Windows Hello PIN/biometric failures may not produce the same events. Never risk locking yourself out for this exercise.

3. Filter Event Viewer and compare the records

1. Under Windows Logs → Security, select Filter Current Log. Choose your time range and enter 4624,4625 in the Event IDs field, then select OK.
2. Open an event and inspect General and Details → XML View. Match the target account and time to your notes. A busy log contains service and system activity unrelated to your test.
3. Record the Event ID, EventRecordID, timestamp and time zone, computer alias, target account, logon type and any source/workstation fields. For 4625, also record Failure Reason, Status and SubStatus when present.
4. For 4624, read the New Logon account; for 4625, read Account For Which Logon Failed. The Subject account describes the requester and may differ from the account you are investigating.

Event Viewer usually displays local time in General; XML SystemTime is UTC (ends in Z). Normalise times before comparing. An absent address or “-” is possible; 127.0.0.1 and ::1 indicate loopback. Record missing data as missing instead of guessing a source.

4. Answer the investigation questions

1. Which target account and computer appear in each event? Are you reading the target rather than the Subject?
2. When did each attempt occur, in which time zone, and does that match your controlled actions?
3. What is the logon type? Does it fit an interactive, service or network action?
4. What source information is actually present? What cannot be inferred from missing fields?
5. What do the 4625 failure fields say? Which details support your explanation?
6. If a failure is followed by a success, what supports connecting them? Time proximity alone does not prove the same actor or a compromise.
7. What additional evidence would you need before escalating an unexpected pattern?

Expected results and troubleshooting

A controlled correct-password RunAs attempt should open a process as your test account and produce a matching 4624; the single incorrect-password attempt should fail and produce a 4625. You may see extra events. Event counts and source fields vary with authentication method and configuration.

No matching records?

Refresh Security, widen the time range and check that you are inspecting the machine where the logon was attempted. Check the target username, your clock/time zone and Audit Logon Success/Failure. Auditing must have been enabled before the test; older logs may have rolled over. Do not keep generating failures to troubleshoot.

Access denied or no policy console?

Use your authorised local administrator session to open Event Viewer. Some editions lack Local Security Policy; the auditpol commands above provide a built-in alternative. If the device is managed or you lack permission, stop and move to an owned lab.

RunAs fails even with the correct password?

Confirm the local account name and password, keyboard layout and Secondary Logon service availability. Do not enter a PIN as a password. Use existing events if policy prevents the test; do not weaken protections to force it.

Different logon types or blank IP addresses?

These depend on how authentication occurred. Service and system sessions are normal background activity. Compare account, time and context; a blank source is not proof of evasion. Document the difference rather than forcing the expected answer.

5. Write your portfolio summary

Copy this template into your own notes. Include a small sanitised screenshot or table showing your actual observations. Replace hostnames and usernames with consistent aliases; remove SIDs, public IPs and other identifying details. Do not upload raw EVTX files or fabricate results.

# Windows Security Log Investigation
Goal: What question was I trying to answer?
Environment: Windows edition/build, local lab, tools, audit settings.
Scope: Host alias, test account alias, time window and time zone.
Method: Steps performed and how I kept the exercise safe.
Evidence: Sanitised event record IDs, event IDs, timestamps, target
account, logon types, source fields, status/substatus (where present).
Timeline: Observations in time order; separate facts from assumptions.
Findings: What do the records support? What remains uncertain?
Troubleshooting: What failed, how I checked it, what changed.
Limitations: Missing fields/events; no proof of compromise from this alone.
Next step: What evidence would I collect or skill would I practise next?
Reflection: Explain this project in 3 sentences, in your own words.

You are done when you can explain one success and one failure using evidence, name at least one limitation, and describe a sensible next check. If your environment did not record both events, document that limitation honestly and revisit setup.

6. Clean up and choose your next step

Close test sessions and remove only the test account you created, if no longer needed, after saving your notes. Restore audit settings to their recorded values if you changed them, or revert your disposable VM snapshot. Do not clear the Security log. Keep raw evidence private.

Next, repeat the analysis with a different small time window and compare normal account activity. Then follow the SOC Analyst roadmap to learn how a SIEM collects and queries these events.

Reference documentation

Use Microsoft’s documentation to check field meanings against your actual records:

• Microsoft: event 4624 and logon types
• Microsoft: event 4625 and failure fields
• Microsoft: auditpol get and auditpol set