Investigate a Failed Windows Logon

Analyze a Windows failed logon and publish a sanitized SOC case report.

Introduction

30 Second Summary

A failed sign-in can be a harmless typo or the first clue that someone is testing an account. The evidence only becomes useful when someone can explain what happened.

In this project, you will investigate a failed Windows sign-in by interpreting Event ID 4625 in Windows Security logs. You will publish your verdict as a sanitized SOC case report in a private GitHub repository.

What You'll Build

You'll open your private repository to a readable case report that traces the failed sign-in from raw evidence to a clear verdict with practical recommendations.

By the end of this project, you'll have:

A verified failed-logon record that you can inspect as evidence from one controlled attempt or Microsoft's official sample.
A field-by-field triage record that explains the account, failure information, logon type, source, process, and authentication package.
A sanitized SOC case report that presents a timeline, verdict, recommendations, and clear limits on what the evidence proves.
Secret Mission: Add an escalation decision table for status codes 0xC0000064, 0xC000006A, and 0xC0000234.

Are there any prerequisites?

You'll need a Windows PC with administrator access. You'll also need the correct account password plus a GitHub account.

Before We Start

This step turns a Windows failed-logon record into a focused SOC investigation. You will commit to the investigation goal before any hands-on work begins.

Prepare a Safe Windows Audit Lab

Your SOC investigation needs a failed-logon record. Creating one carelessly can trigger an account lockout.

Windows audit policy controls which security events Windows records. A policy backup keeps the original configuration recoverable before Logon auditing changes.

In this step, get ready to:

Check the account lockout threshold before generating evidence.
Back up the original local audit policy.
Configure verified Success and Failure auditing for Logon.

Check the lockout threshold

An elevated Windows PowerShell session gives auditpol the permission needed to manage audit settings. The lockout threshold tells you how many failed sign-in attempts can lock the account.

Press the Windows key to open the Windows search bar.
Type Windows PowerShell into the search field.
Right-click the matching Windows PowerShell result.
Choose the administrator launch option.
Approve the Windows permission request.
Check the local account policy by running this command:

NET ACCOUNTS

What does this command show?

The command displays local account lockout settings.
The Lockout threshold row shows how many failed sign-in attempts trigger an account lockout.

Find the Lockout threshold row in the command output.
Record the displayed value here: your Lockout threshold value.

Choose the safe evidence path

A threshold of 1 routes your investigation to the official Microsoft Event ID 4625 sample in the next step. This route avoids locking your account.

A value of Never or a numeric threshold greater than 1 allows the live route. That route uses exactly one deliberate wrong-password attempt in the next step.

Unable to read the account policy?

Close PowerShell if Windows blocks the command because of permissions.
Reopen Windows PowerShell with administrator access.

Help me troubleshoot the account policy check.

Back up the audit policy

Audit settings persist after PowerShell closes. A backup creates a restoration point for the local policy that existed before this investigation.

Back up the current audit policy to C:\auditpolicy.csv by running this command:

auditpol /backup /file:C:\auditpolicy.csv

What does this backup protect?

The command writes the current audit configuration to C:\auditpolicy.csv. This file provides the restoration point used during cleanup.

Confirm that Windows reports the command completed successfully.

Good work. Your original local audit policy is now recoverable before any setting changes.

Backup not completing?

Confirm the PowerShell window still has administrator access.
Check that the destination in the command is exactly C:\auditpolicy.csv.

Help me troubleshoot the audit policy backup.

Enable and verify Logon auditing

The Logon subcategory determines whether Windows records successful sign-ins and failed sign-ins. Your backup preserves the earlier configuration for restoration.

The final query shows the effective policy after local or domain Windows Group Policy is applied. That effective result is the setting Windows uses.

Enable Logon success auditing and failure auditing by running this command:

auditpol /set /subcategory:"logon" /success:enable /failure:enable

What does this command change?

The success:enable setting records successful Logon events.
The failure:enable setting records failed Logon events.

Confirm that PowerShell reports a successful policy change.

Before you verify, do you expect the effective Logon row to show both audit result types?

Verify the effective audit configuration by running this command:

auditpol /get /category:*

What does this verification show?

This effective-policy query lists the configured audit categories and subcategories. It confirms the policy Windows is currently using.

Find the Logon row in the command output.

You should see Success and Failure on the Logon row. This confirms that Windows can record the authentication evidence needed for your investigation.

Logon row showing a different setting?

Confirm that the PowerShell window still has administrator access.
Run the preceding policy-setting command again.
Run the effective-policy query again.

A local or domain Group Policy may override the setting if the row still differs.

Help me investigate the effective Logon audit setting.

Your safe lab checkpoint

Your recorded lockout threshold determines whether the next step uses local evidence or the official Microsoft sample.
Your original local Windows audit policy is backed up in C:\auditpolicy.csv.
Your effective Logon subcategory shows Success and Failure auditing.

Your lab now protects the original policy while collecting the right Logon evidence. Next, you will capture one failed-logon record or use the official Microsoft sample when the safety gate requires it.

Capture a Failed Logon Event

Your elevated Windows PowerShell session is ready. Your original audit policy remains safely backed up.

The next goal is to create one verified failed-logon evidence source without risking an account lockout. You will use one controlled attempt or Microsoft's official sample.

A raw Windows Security event can be dense. You will inspect that raw output first. Triage comes in the next step.

In this step, get ready to:

Choose the live or sample evidence path using your recorded lockout threshold.
Query the Security log for Event ID 4625.
Observe why raw failed-logon output still needs triage.

Choose a safe evidence path

Your recorded Lockout threshold determines which evidence path is safe. Follow only the tab that matches the value you reviewed earlier.

Threshold Is Never or Greater Than 1

This sign-in test touches account access, so the checked threshold plus the one-attempt limit keeps the exercise controlled.

Confirm that your recorded Lockout threshold is Never or a number greater than 1.
Lock your PC by pressing Windows key + L.
Enter one deliberately incorrect password for your Windows account.

Windows rejects the sign-in attempt. That single failure supplies the controlled event for your investigation.

Enter the correct password to sign back in.
Return to the elevated Windows PowerShell session from earlier.

Threshold Is 1

A threshold of 1 makes a live attempt unsafe. Microsoft's official sample provides the same event structure without touching your account.

Confirm that your recorded Lockout threshold is 1.
Skip the live wrong-password attempt.
Open Microsoft's official Event ID 4625 reference in your browser.
Locate <EventID>4625</EventID> in the sample payload.
Keep the official sample page open for the investigation.

The sample payload is now your verified evidence source.

Query and observe the Security log

The Get-WinEvent query searches the local Security log for failed-logon events recorded during the last day. Running it also confirms whether your controlled attempt appears in the available evidence.

Before you run the query, predict whether the raw result can already tell you if the attempt is suspicious.
Search for Event ID 4625 from the elevated Windows PowerShell session by running:

Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=(Get-Date).AddDays(-1); Id='4625'}

What does this query do?

The LogName='Security' filter searches the local Security log.
The StartTime=(Get-Date).AddDays(-1) filter limits the search to the last day.
The Id='4625' filter keeps failed-logon events.

Inspect the raw result before filtering or interpreting any fields.

You may see a short table or a long event message. The raw output still leaves the investigation questions unanswered.

That shortfall is intentional. The query proves that evidence exists without yet explaining who attempted the logon or whether the activity is suspicious.

Using a Local Event

Check the query output for at least one result with ID 4625.

You should see at least one Event ID 4625 result from the last day. Your controlled local evidence is ready for triage.

Using the Official Sample

Return to the official Microsoft sample in your browser.
Confirm that the payload contains <EventID>4625</EventID>.

That XML line verifies the sample as an Event ID 4625 evidence source. It remains your investigation record even if the local query returns no results.

No local event in the results?

Return to the elevated Windows PowerShell session if Windows blocks access to the Security log.
Run the same query once more if the controlled attempt does not appear immediately.
Keep the one-attempt limit if the result remains empty.

Share the output without personal account details when you ask for help with the missing Event ID 4625 result.

You handled the risky part safely. Your verified failed-logon evidence source is ready for triage.

Frame your evidence screenshot around the Event ID 4625 result or the sample's Event ID line.
Exclude visible account names from the screenshot.

Your raw failed-logon evidence is secured. Next, you will isolate the relevant record and turn its fields into an analyst-ready verdict.

Triage Event ID 4625

Your Windows PowerShell query proved that failed-logon evidence exists. The raw Windows Security log still cannot support a defensible verdict.

Windows Event Viewer lets you isolate one Event ID 4625 record. A structured evidence triage checklist turns that record into an analyst-ready explanation.

In this step, get ready to:

Filter the Windows Security log for Event ID 4625.
Capture every required field in an evidence table.
Write a verdict that separates facts from analyst judgment.

Filter the Security log

A log filter removes unrelated events from view. This gives you a smaller evidence set for identifying the record that matches your controlled test or official sample.

Press the Windows key to open the search bar.
Type Event Viewer into the search bar.
Press Enter to open Event Viewer.
Expand Windows Logs in the left navigation pane.
Select Security under Windows Logs.
Choose Filter Current Log from the right pane.
Enter 4625 in the Event IDs field.
Select OK to apply the filter.

On the live path, you should see one or more rows with 4625 in the Event ID column. On the sample path, the filtered local list can be empty because your evidence remains in the official Microsoft sample.

Cannot find the local event?

Confirm that Security is selected under Windows Logs. Check that the filter contains only 4625.

Compare the Event Viewer time range with the raw PowerShell results from the previous step.

Help me find my Event ID 4625 record.

Double-click the newest relevant 4625 row if you generated a controlled local event.
Switch back to the official Microsoft sample payload if the lockout safety check blocked the live test.
Confirm that the sample contains <EventID>4625</EventID>.
Keep the filtered Event Viewer window open while you triage the evidence.

Protect identifiers in your screenshot

A real Security event can expose account names or computer names. It can also expose network addresses.

Crop your validation image to the filter and Event ID column. If you use the sample, crop the image to the <EventID>4625</EventID> line.

Build the evidence table

A field checklist prevents important evidence from disappearing inside a long event message. Every row needs either an observed value or an explicit note that the field was not populated.

Reading the XML sample

The Microsoft sample uses XML field names. These names map directly to the labels in your evidence table.

TargetUserName supplies Account Name.
LogonType supplies Logon Type.
Status supplies Status.
SubStatus supplies Sub Status.
WorkstationName supplies Workstation Name.
IpAddress supplies Source Network Address.
ProcessName supplies Caller Process Name.
LogonProcessName supplies Logon Process.
AuthenticationPackageName supplies Authentication Package.

Create a two-column evidence table named Event ID 4625 Evidence Record in your private investigation notes.
Label the columns Field and Observed Value.
Record the timestamp shown for the event.
Record Account Name under Account For Which Logon Failed.
Record the Logon Type value.
Record the Failure Reason value.
Record the Status value.
Record the Sub Status value.

How to interpret Logon Type

Logon Type describes how the attempted session reached Windows. Preserve the numeric value in your table alongside its meaning.

2 means Interactive.
3 means Network.
4 means Batch.
5 means Service.
7 means Unlock.
8 means NetworkCleartext.
9 means NewCredentials.
10 means RemoteInteractive.
11 means CachedInteractive.

Record the Workstation Name value.
Record the Source Network Address value.
Record the Caller Process Name value.
Record the Logon Process value.
Record the Authentication Package value.
Replace every blank field with not populated.

How to treat source evidence

The Source Network Address values ::1 and 127.0.0.1 mean localhost. These values support a local-origin interpretation.

An empty source field leaves the origin unknown. Preserve that uncertainty with not populated.

Write a defensible verdict

A SOC verdict links analyst judgment to recorded evidence. It also makes uncertainty visible so another analyst can review the reasoning.

Write one paragraph beneath your evidence table.
Open the paragraph by identifying the controlled test or Microsoft sample as your evidence source.
State whether the event appears expected or suspicious.
Support your judgment with the recorded timestamp.
Add the relevant target account evidence.
Interpret the recorded Logon Type.

What makes a verdict defensible?

Observed values are facts from the event. Your conclusion is analyst judgment based on those facts.

A one-time failure that aligns with the controlled test supports an expected verdict. Repeated failures or an unexpected source would justify escalation.

Include the recorded Failure Reason.
Include the recorded Status value.
Include the recorded Sub Status value.
Cite the strongest source or process clue.
Name the most important missing evidence.
Finish with the activity pattern that would trigger escalation.

Before the final check, make a mental prediction about which field carries the most uncertainty.

Compare the completed evidence table with your local record or official sample.
Check that every required field contains a value or not populated.
Switch back to the filtered Security log in Event Viewer.
Confirm that the active filter contains 4625.
Reopen the newest relevant event if you used the controlled local test.

On the live path, you should see the newest relevant event in the Security log filtered for 4625. On the sample path, you should see the same filter active after checking your table against the Microsoft payload.

You have done the hard analytical work: your raw failed-logon evidence is now a structured SOC triage record with a defensible verdict.

Your investigation now has evidence, interpretation, and a clear decision. Next up, you will turn this triage record into a sanitized SOC case report.

Publish a Sanitized SOC Case Report

Your SOC triage record now separates observed Event ID 4625 facts from analyst judgment. It also identifies missing evidence.

The final handoff must protect personal identifiers from the Windows record. In this step, you'll publish a sanitized report in a private GitHub repository.

In this step, get ready to:

Create a private GitHub repository with README initialization.
Turn the completed triage record into a professional case report.
Sanitize the report before its final commit.

Create the private repository

A private repository gives your draft a controlled workspace while you remove identifying values. README initialization creates the report file directly on GitHub.com.

Visit GitHub.com in your browser.
Complete GitHub's sign-in flow if it appears.
Select New repository from the repository menu.
Select your personal account under Owner.
Enter windows-logon-investigation in the Repository name field.
Choose Private under visibility.
Turn on Add README.
Select Create repository.

You'll see the repository page with README.md in the file list. The repository's visibility indicator should show Private.

Good progress. Your investigation now has a controlled home for the report draft.

Repository Not Ready?

Confirm the repository name is exactly windows-logon-investigation.
Confirm the visibility indicator shows Private before adding evidence.

Help me fix my private repository setup.

Draft the report from your evidence

A professional SOC report keeps each reasoning layer visible. Readers can trace the verdict back to the event fields.

What Belongs in the Report?

The Executive Summary gives the investigation question plus the final conclusion.
The Scope and Safety section identifies the controlled lab or official sample context with a clear lab disclaimer.
The Evidence section presents every required field in a readable table with a captured value or an explicit not populated note.
The Timeline section lists only times and actions supported by your evidence.
The Analysis section interprets the logon type, failure information, source, process, authentication package, and evidence gaps.
The Verdict section states whether the event matches the controlled test or official sample context.
The Recommendations section names the activity pattern that would justify escalation.
The Skills Demonstrated section summarizes the collection, triage, interpretation, sanitization, and reporting skills shown in the case.

Select README.md from the repository file list.
Choose the edit control above the file content.
Draft the Executive Summary, Scope and Safety, and Evidence sections from your triage record.
Select Preview to render the opening report sections.

You'll see two prose sections followed by a readable evidence table. Every table row should show a captured value or not populated.

Return to the editing view.
Draft the Timeline, Analysis, and Verdict sections from supported evidence.
Select Preview to render the investigation reasoning.

You'll see a chronology followed by your interpretation and verdict. Any uncertainty from the original event should remain explicit.

Return to the editing view.
Draft the Recommendations and Skills Demonstrated sections.
Select Preview to render the complete report structure.

You'll see all eight required section headings on one rendered page. The recommendations should connect directly to the escalation triggers in your verdict.

Sanitize, preview, and commit the report

Data sanitization replaces identifying values while preserving the event's investigative meaning. Sanitization remains required inside a private repository because the report may be shared later.

Return to the editing view.
Replace every personal account name with [REDACTED-USER].
Replace every local computer name with [LOCAL-HOST].
Select Preview to inspect the first redaction pass.

You'll see [REDACTED-USER] and [LOCAL-HOST] where personal account and computer values appeared.

Return to the editing view.
Replace every real domain with a clear redaction label.
Replace every real network address with a clear redaction label.
Select Preview to inspect the network redactions.

You'll see descriptive labels in place of real domains and network addresses. The surrounding analysis should still explain what each field contributes to the investigation.

Return to the editing view.
Remove any password or credential text from the report.

Before you preview, do you expect any identifying value from the original event to remain?

Select Preview to perform the final sanitization check.

You'll see the complete report with redaction labels in every sensitive field. No personal username, hostname, domain, network address, password, or credential should remain.

Select Commit changes to open the commit form.
Enter Publish sanitized Event ID 4625 case report in the commit message field.
Select Commit changes in the commit form.

Before you open the rendered file, which report sections do you expect to see on one page?

Select README.md from the repository file list to view the committed report.

You'll see Executive Summary, Scope and Safety, Evidence, Timeline, Analysis, Verdict, Recommendations, and Skills Demonstrated on the rendered page. The evidence table should use sanitized values while the scope section displays the lab disclaimer.

That's a professional handoff. Your private repository now shows how you turn raw Windows evidence into a defensible SOC decision without exposing personal data.

Report Missing a Section?

Return to the file's editing control if a required heading is missing.
Confirm the latest commit contains your complete sanitized report.
Repeat the preview check before committing another correction.

Help me check my SOC report structure and sanitization.

Secret mission

Secret Mission: Build an Escalation Decision Table

Turn three documented failed-logon status codes into a reusable escalation decision table. Your report will show when one controlled failure is expected context and when a pattern needs further investigation.

Clean Up Your Resources

Choose whether to keep your resources, restore the lab settings, or delete the saved artifacts. This project uses built-in Windows tools plus a private GitHub Free repository, so there are no ongoing costs.

Resources you used:

Windows Logon audit policy with Success and Failure auditing enabled.
Audit-policy backup stored at C:\auditpolicy.csv.
Private GitHub.com repository windows-logon-investigation containing the committed README.md case report.

Keep everything running

No action is needed. Choose this option if you want to continue investigating Windows authentication events or refining your case report.

Leave Logon success and failure auditing enabled for future analysis.
Retain C:\auditpolicy.csv as a record of the original audit settings.
Keep windows-logon-investigation private while you continue reviewing its sanitized content.

Pause - I'll come back to this later

Restore the original audit settings while keeping the backup available. Your private report remains ready for later.

Restore the original audit policy in the elevated Windows PowerShell session by running this command:

auditpol /restore /file:c:\auditpolicy.csv

What Does This Command Do?

The auditpol /restore command reads the original policy from C:\auditpolicy.csv. This returns the audit configuration to the state captured before the lab.

Windows PowerShell should report that restoration completed successfully. Your original audit settings are now back in place.

Retain C:\auditpolicy.csv in case you need to review the original policy later.
Keep the windows-logon-investigation repository private until you return to the report.

Delete - I don't want to use this again

Remove the saved report plus the audit-policy backup. The audit policy is restored first, so Windows returns to the configuration captured before the lab.

Restore the original audit policy in the elevated Windows PowerShell session by running this command:

auditpol /restore /file:c:\auditpolicy.csv

What Does This Command Do?

The auditpol /restore command applies the policy stored in C:\auditpolicy.csv. Restoring the policy before deleting the backup preserves the safe rollback order.

Windows PowerShell should report that restoration completed successfully. This confirms the backup has served its purpose.

Press the Windows key to open Windows search.
Type File Explorer into Windows search.
Press Enter to open File Explorer.
Select the File Explorer address bar.
Type C:\ into the address bar.
Press Enter to display the drive root.
Select auditpolicy.csv.
Press Delete to remove the backup file.

You should no longer see auditpolicy.csv listed under C:\.

Switch back to the windows-logon-investigation repository already open on GitHub.com.
Select Settings.
Select General.
Scroll to Danger Zone.

You are now at the controls that remove the repository.

Select Delete this repository.
Select I want to delete this repository.
Select I have read and understand these effects.
Follow GitHub's prompt to confirm the repository name.
Complete the final confirmation shown by GitHub.
Return to your GitHub.com repositories list.

The windows-logon-investigation repository should no longer appear in your list. That closes the lab cleanly with the original audit policy restored.

Nice Work!

Excellent work! You turned a Windows failed-logon record into a sanitized SOC investigation with a defensible verdict.

You've learned how to:

Protect a Windows lab with an account lockout safety check. You used Windows PowerShell to preserve the original audit policy. You also verified Logon Success and Failure auditing before collecting evidence.
Use Windows Event Viewer to isolate the newest relevant Event ID 4625 record. You converted that record into a structured evidence table. You also separated observed facts from missing evidence. That distinction supported your analyst judgment.
Publish a sanitized SOC case report in a private GitHub repository. Your report communicates the evidence timeline. It states a clear verdict. It recommends practical next steps without exposing personal identifiers.
Secret Mission: Build a reusable escalation decision table. It distinguishes 0xC0000064, 0xC000006A, and 0xC0000234. Each row connects a status code to an investigation question. Each row also defines an escalation condition.

Ready to quiz yourself?