Triage a Suspicious Windows Login

Investigate synthetic Windows logins and build an incident response case file.

Introduction

30 Second Summary

A string of failed sign-ins can look alarming at first glance. Without the surrounding activity, a normal password mistake can resemble an attack.

In this project, you will use Windows PowerShell to investigate synthetic authentication telemetry from a suspicious login at Northstar Retail. Your finished case folder connects the evidence to a defensible response decision.

What You'll Build

A PowerShell query reveals the suspicious sequence in chronological order so you can defend your conclusion with the Northstar Retail case evidence.

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

  • A visible chronological authentication timeline that lets you trace all 14 events from earliest to latest.
  • A seven-row evidence trail that shows why the svc-backup sequence deserves escalation.
  • A completed incident report that supports containment decisions through a reusable response playbook for future suspicious logins.
  • Secret Mission: Independently assess the mroberts explicit-credential event to justify whether you would close, monitor, or escalate it.

Are there any prerequisites?

You need a Windows 10 or Windows 11 device. No administrator access or prior incident response experience is required.

Before We Start

This checkpoint places you in the role of a junior SOC analyst investigating suspicious Windows authentication activity for Northstar Retail, a fictional company. An evidence timeline establishes the event sequence needed for a defensible response decision.

Set Up the Safe Case Lab

Northstar Retail's alert needs repeatable evidence before you can judge whether the activity deserves escalation. This lab gives you a safe place to investigate that evidence.

Real Windows security logs can require administrator access or specific audit settings. A controlled synthetic case gives you consistent evidence without changing your real security logs.

In this step, get ready to:
  • Confirm that PowerShell can run the investigation commands.
  • Create the lab folder with its Northstar Retail case brief.
  • Load the synthetic dataset to display 14 authentication events.

Why use a synthetic case?

Live authentication telemetry can depend on permissions. It can also depend on the device's audit policy.

A synthetic CSV keeps the investigation repeatable. Everyone starts with the same timeline.

Validate the required tools

Your investigation depends on a shell that can display evidence consistently. Windows PowerShell 5.1 is the primary path because it ships with Windows.

PowerShell 7.6.6 is the official fallback when Windows PowerShell is unavailable. The same version check tells you which path is ready.

  • Select Start on your Windows taskbar.
  • Type Windows PowerShell into the search box.
  • Select Windows PowerShell from the search results.
  • Check the active PowerShell version by running this command:
$PSVersionTable

What does this command show?

The $PSVersionTable variable contains details about the active PowerShell session. Its PSVersion item identifies the version running in this window.

  • Choose the tab that matches the version information you see.

✔️ I see Windows PowerShell 5.1

Your primary shell is ready. Keep this Windows PowerShell window open for the rest of the investigation.

ⓧ I see an older PowerShell 7 version

Your PowerShell 7 installation needs an update before it becomes the fallback for this lab. Microsoft's installation guidance provides the current Windows package.

  • Open Microsoft's official Windows installation page.
  • Install PowerShell 7.6.6 using the Windows guidance on the page.
  • Approve the installation request if Windows displays one.
  • Select Start after the installation finishes.
  • Type PowerShell 7 into the search box.
  • Select PowerShell 7 from the search results.
  • Check the updated fallback version by running this command:
$PSVersionTable

What confirms the update?

The PSVersion item now identifies PowerShell 7.6.6. Keep this PowerShell 7 window open for the remaining commands.

ⓧ Windows PowerShell is unavailable

PowerShell 7.6.6 gives you the supported fallback path. The installer choice can feel fiddly, so use the device guidance on Microsoft's page.

  • Open Microsoft's official Windows installation page.
  • Install PowerShell 7.6.6 using the Windows guidance on the page.
  • Approve the installation request if Windows displays one.
  • Select Start after the installation finishes.
  • Type PowerShell 7 into the search box.
  • Select PowerShell 7 from the search results.
  • Check the fallback version by running this command:
$PSVersionTable

What confirms the fallback?

The PSVersion item identifies PowerShell 7.6.6. Keep this PowerShell 7 window open for the remaining commands.

Still unable to open PowerShell?

Restart Windows after the installation if PowerShell 7 does not appear in the Start search results. Confirm that the installation completed before searching again.

Ask for help with the installation details: Help me get PowerShell running on Windows.

The case files need a plain-text editor that preserves their exact contents. Windows Notepad provides that editor without adding formatting.

  • Select Start on your Windows taskbar.
  • Type Notepad into the search box.
  • Select Notepad from the search results.

You'll see a blank Notepad window. That confirms your text editor is available.

Notepad missing from the results?

Install Windows Notepad from its official Microsoft Store listing. Search for Notepad again after the installation completes.

Ask for help if the installation does not complete: Help me install Windows Notepad.

Create the case folder and brief

A case folder keeps the source evidence separate from your other files. The case brief records the approved baseline that you use to judge each login.

  • Switch back to the PowerShell window from the version check.
  • Create IncidentResponseLab in your home folder by running these commands:
New-Item -Path "$HOME\IncidentResponseLab" -ItemType "Directory" -Force
Set-Location -Path "$HOME\IncidentResponseLab"
notepad.exe .\case-brief.txt

What do these commands do?

  • The first command creates the IncidentResponseLab folder inside the current Windows user's home directory.
  • The second command changes PowerShell's working directory to that folder.
  • The third command opens case-brief.txt in Notepad.

Did the case brief fail to open?

Check that the PowerShell prompt ends with IncidentResponseLab. A different ending means the folder change did not complete.

Ask for help with the folder commands: Help me create the case folder.

  • Fill case-brief.txt by copying the following case brief into Notepad:
Organization: Northstar Retail (fictional)
Alert: Multiple failed logons for svc-backup at approximately 02:13 UTC.
Business hours: 07:00 through 19:00 UTC.
Known baseline:
- jlee normally signs in from HR-LT-04 at 10.20.5.18.
- mroberts normally signs in from SALES-LT-12 at 10.20.5.44 and may use explicit credentials for approved support work.
- svc-backup should authenticate only from BACKUP-SRV-01 at 10.20.8.20.
- Interactive or manual use of svc-backup is prohibited.
Analyst objective: Determine whether the alert is an incident, identify the affected account and systems, preserve the key timeline, and recommend response actions.

What does the case brief establish?

The brief defines expected accounts. It also defines approved source addresses.

The baseline gives you a comparison point for suspicious behavior. Every later conclusion must connect to this context.

  • Save case-brief.txt in Notepad.
  • Check the document tab at the top of Notepad.

You'll see case-brief.txt as the saved document name. Your investigation now has an approved reference point.

Case brief still blank after saving?

Paste the brief again if the document area is empty. Save the file before leaving Notepad.

Ask for help if the content disappears: Help me save the case brief correctly.

✔️ Awesome, I've got everything!

Your saved case brief contains the Northstar Retail alert. It also contains the account baselines that guide the investigation.

ⓧ I'd like to double check the full code

Organization: Northstar Retail (fictional)
Alert: Multiple failed logons for svc-backup at approximately 02:13 UTC.
Business hours: 07:00 through 19:00 UTC.
Known baseline:
- jlee normally signs in from HR-LT-04 at 10.20.5.18.
- mroberts normally signs in from SALES-LT-12 at 10.20.5.44 and may use explicit credentials for approved support work.
- svc-backup should authenticate only from BACKUP-SRV-01 at 10.20.8.20.
- Interactive or manual use of svc-backup is prohibited.
Analyst objective: Determine whether the alert is an incident, identify the affected account and systems, preserve the key timeline, and recommend response actions.
Create and load the synthetic evidence

The evidence file stores one authentication event per row. Its columns preserve the time, account, source, workstation, logon type, outcome, and event detail.

  • Return to the PowerShell window from the folder setup.
  • Create the evidence file in IncidentResponseLab by running this command:
notepad.exe .\incident-events.csv

What does this command do?

The command opens incident-events.csv in Notepad. The relative path places it inside PowerShell's current IncidentResponseLab folder.

  • Fill incident-events.csv by copying the following dataset into Notepad:
TimeCreated,EventId,Account,SourceNetworkAddress,WorkstationName,LogonType,Outcome,Detail
2026-09-22T01:00:00Z,4624,svc-backup,10.20.8.20,BACKUP-SRV-01,5,Success,Baseline service logon
2026-09-22T02:13:08Z,4625,svc-backup,198.51.100.42,UNKNOWN,3,Failure,Bad password
2026-09-22T02:13:21Z,4625,svc-backup,198.51.100.42,UNKNOWN,3,Failure,Bad password
2026-09-22T02:13:45Z,4625,svc-backup,198.51.100.42,UNKNOWN,3,Failure,Bad password
2026-09-22T02:14:02Z,4625,svc-backup,198.51.100.42,UNKNOWN,3,Failure,Bad password
2026-09-22T02:14:39Z,4624,svc-backup,198.51.100.42,FILE-SRV-03,3,Success,Network logon
2026-09-22T02:15:11Z,4648,svc-backup,198.51.100.42,FILE-SRV-03,N/A,Success,Explicit credentials
2026-09-22T08:02:14Z,4625,jlee,10.20.5.18,HR-LT-04,2,Failure,Bad password
2026-09-22T08:02:31Z,4625,jlee,10.20.5.18,HR-LT-04,2,Failure,Bad password
2026-09-22T08:03:05Z,4624,jlee,10.20.5.18,HR-LT-04,2,Success,Interactive logon
2026-09-22T09:15:00Z,4624,mroberts,10.20.5.44,SALES-LT-12,2,Success,Interactive logon
2026-09-22T09:20:10Z,4648,mroberts,10.20.5.44,SALES-LT-12,N/A,Success,Approved support task
2026-09-22T14:40:00Z,4625,mroberts,10.20.5.44,SALES-LT-12,2,Failure,Bad password
2026-09-22T14:40:22Z,4624,mroberts,10.20.5.44,SALES-LT-12,2,Success,Interactive logon

What is inside the dataset?

The first line defines eight event properties. The next 14 lines represent synthetic authentication events.

The rows include failed logons, successful logons, and explicit-credential activity. That mix gives you enough context to test competing explanations later.

  • Save incident-events.csv in Notepad.
  • Return to the PowerShell window from earlier.

Does the dataset look incomplete?

Confirm that the header starts with TimeCreated. Confirm that the final row ends with Interactive logon.

Ask for help if rows disappeared during the paste: Help me check the synthetic CSV.

✔️ Awesome, I've got everything!

Your evidence file has one header row followed by 14 synthetic authentication-event rows.

ⓧ I'd like to double check the full code

TimeCreated,EventId,Account,SourceNetworkAddress,WorkstationName,LogonType,Outcome,Detail
2026-09-22T01:00:00Z,4624,svc-backup,10.20.8.20,BACKUP-SRV-01,5,Success,Baseline service logon
2026-09-22T02:13:08Z,4625,svc-backup,198.51.100.42,UNKNOWN,3,Failure,Bad password
2026-09-22T02:13:21Z,4625,svc-backup,198.51.100.42,UNKNOWN,3,Failure,Bad password
2026-09-22T02:13:45Z,4625,svc-backup,198.51.100.42,UNKNOWN,3,Failure,Bad password
2026-09-22T02:14:02Z,4625,svc-backup,198.51.100.42,UNKNOWN,3,Failure,Bad password
2026-09-22T02:14:39Z,4624,svc-backup,198.51.100.42,FILE-SRV-03,3,Success,Network logon
2026-09-22T02:15:11Z,4648,svc-backup,198.51.100.42,FILE-SRV-03,N/A,Success,Explicit credentials
2026-09-22T08:02:14Z,4625,jlee,10.20.5.18,HR-LT-04,2,Failure,Bad password
2026-09-22T08:02:31Z,4625,jlee,10.20.5.18,HR-LT-04,2,Failure,Bad password
2026-09-22T08:03:05Z,4624,jlee,10.20.5.18,HR-LT-04,2,Success,Interactive logon
2026-09-22T09:15:00Z,4624,mroberts,10.20.5.44,SALES-LT-12,2,Success,Interactive logon
2026-09-22T09:20:10Z,4648,mroberts,10.20.5.44,SALES-LT-12,N/A,Success,Approved support task
2026-09-22T14:40:00Z,4625,mroberts,10.20.5.44,SALES-LT-12,2,Failure,Bad password
2026-09-22T14:40:22Z,4624,mroberts,10.20.5.44,SALES-LT-12,2,Success,Interactive logon

Before you run the final check, do you expect PowerShell to recognize every CSV column as a separate event property?

  • Verify the active shell and import the saved evidence by running these commands:
$PSVersionTable
Import-Csv -Path .\incident-events.csv

What does this check prove?

  • The first command displays the active PowerShell version details.
  • The Import-Csv command reads the saved evidence file from the current folder.
  • PowerShell displays 14 event rows beneath the version details. Each CSV column becomes a property in the imported objects.

Your safe case lab is working. PowerShell can now read all 14 synthetic authentication events from the folder you created.

Seeing fewer than 14 rows?

Confirm that PowerShell's prompt ends with IncidentResponseLab. Confirm that incident-events.csv contains every row from the full-file check.

Ask for help with the import result: Help me load all 14 event rows.

Your tools are ready. Your case brief now defines the baseline. Next up, you'll turn the 14 raw events into a chronological authentication timeline.

Build the Authentication Timeline

You have the lab foundations in place. Your case brief sits beside 14 rows of authentication telemetry in the case folder.

Raw rows hide the order of an incident. An incident timeline arranges that evidence from earliest to latest. That order shows what happened before the alert. It also shows what followed.

In this step, get ready to:
  • Import the 14 authentication events into one reusable variable.
  • Sort the evidence chronologically using its timestamps.
  • Identify what the three event types reveal about each authentication attempt.
Import the evidence once

PowerShell can hold imported objects in a variable. This lets each later query reuse the same 14 rows from the CSV evidence file.

  • Return to the PowerShell session from earlier.
  • Store the evidence in $events by running this command:
$events = Import-Csv -Path .\incident-events.csv

What does this command do?

  • Import-Csv turns each row from incident-events.csv into an object.
  • $events holds all 14 objects for the queries you run next.
  • Display the stored evidence by running this command:
$events

What does the variable show?

  • Entering $events displays every object currently stored in the variable.
  • Each object retains the columns from the original evidence file.

You should see all 14 authentication-event rows displayed again. The evidence is now ready for repeated analysis without another file import.

Seeing fewer than 14 rows?

  • Confirm that PowerShell is still working inside $HOME\IncidentResponseLab.
  • Check that incident-events.csv still contains one header row plus 14 data rows in Notepad.
  • Run the import command again after correcting the file or folder location.

Help me diagnose why my PowerShell variable does not show all 14 CSV rows.

Sort the evidence chronologically

Chronological sorting uses the TimeCreated timestamp on every row. Sort-Object uses ascending order by default, which places the earliest timestamp first.

  • Arrange the 14 events from earliest to latest by running this command:
$events | Sort-Object -Property TimeCreated

How does the sorting work?

  • The pipeline sends every object from $events into Sort-Object.
  • Sort-Object compares the TimeCreated value on each object.
  • The result preserves every row while changing the display order.

The first row is the 01:00 svc-backup baseline service logon. The last row is the 14:40:22 mroberts interactive logon.

Is the timeline out of order?

  • Check that the property is spelled TimeCreated with the same capitalization shown in the CSV header.
  • Confirm that $events still displays the imported authentication rows.
  • Run the sorting command again after correcting the property name.

Help me troubleshoot why my PowerShell timeline is not sorted by TimeCreated.

Label the three event types

An event ID identifies the type of authentication activity recorded in each row. The surrounding account details provide the context needed to interpret that activity.

  • Record 4624 as a successful logon session created on the destination computer.
  • Record 4625 as a failed logon recorded on the computer where the attempt occurred.
  • Record 4648 as explicit-credential use that requires context.

Why does explicit-credential use need context?

Event 4648 means that a process explicitly specified an account's credentials. This event can also occur during routine activity.

The account baseline determines whether the event supports an incident finding. One event ID cannot establish intent by itself.

Before you run the timeline again, which account activity do you expect to bookend the sorted output?

  • Verify the complete sequence by running the sorting command again:
$events | Sort-Object -Property TimeCreated

What proves the timeline is ordered?

  • The first row shows the 01:00 baseline service logon for svc-backup from BACKUP-SRV-01.
  • The last row shows the 14:40:22 interactive logon for mroberts from SALES-LT-12.
  • All 14 rows remain in the output between those two endpoints.

That is your first investigation win. You have turned raw authentication rows into a timeline that exposes the sequence of activity.

Missing an endpoint row?

  • Display $events to confirm that the variable still contains all 14 rows.
  • Check the first and last TimeCreated values in incident-events.csv.
  • Repeat the import before running the sorting command if the variable contains incomplete data.

Help me find why the expected first or last event is missing from my sorted PowerShell timeline.

Your authentication timeline is now readable from the first baseline event to the final interactive logon. Next, you will test a failure-only hypothesis against the same evidence.

Test the Failure-Only Hypothesis

Your Windows PowerShell session now holds a readable timeline of all 14 authentication events. You can use that timeline to test your first investigation hypothesis.

A large failure cluster can look suspicious at first glance. This step tests whether failure counts provide enough evidence for a reliable triage decision.

In this step, get ready to:
  • Isolate the 4625 events in $failed.
  • Rank the failure clusters using account plus source address.
  • Save an evidence-aware initial hypothesis in incident-report.txt.
Filter failed logons

A failure-only hypothesis starts with event 4625. Filtering on that event ID gives you every failed logon from the case.

Before you run the filter, do you expect every returned row to represent the same level of risk?

  • Create $failed from the events already in memory by running the code below:
$failed = $events | Where-Object -Property EventId -EQ -Value "4625"
$failed

What does this code do?

  • The Where-Object filter checks the event ID on every object stored in $events.
  • The matching failed logons are stored in $failed for reuse.
  • The final line displays the filtered rows in Windows PowerShell.

You'll see seven failed logons spread across three accounts. The same filter captures the suspicious service-account attempts plus ordinary user failures.

Why does the hypothesis fall short?

The failure signal does not explain what happened around each attempt. This is the intended shortfall of failure-only triage.

Reliable event correlation adds successful logons plus baseline context. Those details separate an incident candidate from a normal password mistake.

No failed events displayed?

  • Confirm that the variable name is $events.
  • Check that the event value is written as "4625".
  • Run the filter again from the PowerShell session that contains the imported events.

Ask for help with the filter if the output remains empty.

Group failures by account and source

Individual rows show each attempt. Grouping combines matching account and source pairs so the largest cluster rises to the top.

Before you run this query, which account and source pair do you expect to rank first?

  • Group the failed logons by account plus source address by running the code below:
$failed |
    Group-Object -Property Account, SourceNetworkAddress -NoElement |
    Sort-Object -Property Count -Descending

How does the ranking work?

  • The pipeline sends the failed logons from $failed into Group-Object.
  • The grouping uses Account plus SourceNetworkAddress as the shared identity of each cluster.
  • The final sort ranks the clusters from the highest failure count to the lowest.

You'll see four failures for svc-backup, 198.51.100.42. Below it, you'll see two for jlee, 10.20.5.18 plus one for mroberts, 10.20.5.44.

The service-account cluster is the strongest lead. Its size alone does not confirm malicious activity because the query also ranks failures followed by normal activity.

Groups missing or out of order?

  • Confirm that $failed displayed seven rows before grouping.
  • Check the property spelling against Account plus SourceNetworkAddress.
  • Confirm that the final sort uses descending order.

Ask for help interpreting the grouped output if your counts differ.

Record the initial hypothesis

An investigation note should preserve your strongest lead without overstating certainty. Your first report entry records the cluster plus the limit of failure-only evidence.

  • Open the report draft in Notepad by running this command:
notepad.exe .\incident-report.txt

What does this command do?

The command targets incident-report.txt inside the current IncidentResponseLab folder. Notepad gives you a plain-text draft for your investigation decisions.

  • Paste the following hypothesis into incident-report.txt exactly as shown:
Initial hypothesis:
The largest failure cluster involves svc-backup from 198.51.100.42. Failure count alone is not enough to confirm an incident because jlee and mroberts also have failed logons followed by normal activity.

Why record this wording?

The first sentence identifies the strongest lead from the grouped evidence. The second sentence documents the limit of the current method.

This wording keeps your conclusion proportional to the evidence. A defensible investigation separates observations from confirmed findings.

  • Save incident-report.txt in Notepad.
  • Confirm that the saved draft shows the heading plus the complete hypothesis.

Report text missing after saving?

  • Confirm that Notepad is editing incident-report.txt.
  • Check that the file is saved inside IncidentResponseLab.
  • Compare the saved wording with the full draft below.

Ask for help locating the report if it was saved elsewhere.

✔️ Awesome, I've got everything!

Your initial hypothesis is saved in incident-report.txt.

ⓧ I'd like to double check the full code

Initial hypothesis:
The largest failure cluster involves svc-backup from 198.51.100.42. Failure count alone is not enough to confirm an incident because jlee and mroberts also have failed logons followed by normal activity.

Before the final check, predict which three account and source groups the failure-only query will display.

  • Switch back to Windows PowerShell.
  • Verify the ranked failure groups by running the query again:
$failed |
    Group-Object -Property Account, SourceNetworkAddress -NoElement |
    Sort-Object -Property Count -Descending

What does this final check prove?

The repeated query confirms that $failed still contains the failure-only evidence. The ranking makes the three account and source clusters directly comparable.

You'll see four failures for svc-backup, 198.51.100.42. You'll also see two for jlee, 10.20.5.18 plus one for mroberts, 10.20.5.44.

You have tested the failure-only hypothesis and captured its limit. Your report now distinguishes the largest cluster from a confirmed incident finding.

Your strongest lead is documented without jumping to a verdict. Next, you'll correlate the service-account failures with the baseline plus the surrounding successful activity.

Correlate and Export Incident Evidence

Your failure-only query surfaced the largest cluster. It also caught normal password mistakes because failures alone do not show what happened next.

Event correlation reconnects each failure with the events around it. In Windows PowerShell, you will use that sequence to make a defensible scope decision.

In this step, get ready to:
  • Isolate every svc-backup event in chronological order.
  • Compare the sequence with approved account behavior.
  • Export the seven-row evidence timeline for the incident report.
Isolate the service-account events

Filtering the full $events collection keeps every event type for one account. Sorting by TimeCreated exposes the order that the failure-only view hid.

Before the run, make a mental prediction about whether the surrounding activity will remain ambiguous or form one connected sequence.

  • Build the chronological service-account timeline by running these commands:
$timeline = $events |
    Where-Object -Property Account -EQ -Value "svc-backup" |
    Sort-Object -Property TimeCreated
$timeline

What Does This Pipeline Do?

  • The $events variable supplies all 14 imported records.
  • Where-Object keeps records whose Account value is svc-backup.
  • Sort-Object orders those records by TimeCreated.
  • The $timeline variable retains the filtered sequence for export.

You will see seven svc-backup rows. The output includes successful logons plus failed logons plus explicit-credential activity.

The sequence starts with the 01:00 baseline service logon. It ends with the 02:15 explicit-credential event.

Seeing Fewer Than Seven Rows?

  • Confirm that the pipeline begins with the full $events variable.
  • Check that the account value is exactly svc-backup.
  • Confirm that $timeline appears on the final line.

Help me diagnose my service-account timeline.

Compare the sequence with the approved baseline

An account baseline describes the activity that the organization expects. The case brief allows svc-backup to authenticate only from one approved source.

  • Switch back to case-brief.txt in Notepad.
  • Compare the 01:00 row with the approved source 10.20.8.20.
  • Confirm that the approved workstation is BACKUP-SRV-01.
  • Compare the events after 02:13 with the unapproved source 198.51.100.42.
  • Trace the four failures through the successful network logon at 02:14.
  • Trace that success through the explicit-credential event at 02:15.

That is the key correlation done: svc-backup is the account scope candidate. FILE-SRV-03 is the system scope candidate.

The source 198.51.100.42 requires investigation because it violates the approved service-account baseline.

Why Does Correlation Strengthen the Finding?

Failures alone showed attempted access. The later 4624 event shows a successful network logon from the same unapproved source.

The following 4648 event adds explicit-credential activity on FILE-SRV-03. The connected sequence supports escalation with a specific scope.

  • Capture your evidence-backed scope decision in the checkpoint below.
Preserve the suspicious timeline

A separate CSV preserves the filtered evidence independently of your current session. Reimporting suspicious-timeline.csv confirms that the saved file contains the same sequence.

Before the export, make a mental prediction about whether a fresh import will preserve all seven rows in chronological order.

  • Create the evidence file by running these commands:
$timeline | Export-Csv -Path .\suspicious-timeline.csv -NoTypeInformation
Import-Csv -Path .\suspicious-timeline.csv

How Is the Evidence Preserved?

  • Export-Csv writes the seven objects from $timeline to suspicious-timeline.csv.
  • -NoTypeInformation removes the type-information header from the exported file.
  • Import-Csv reads the new file back into PowerShell for verification.

PowerShell displays seven rows again. That is the evidence-preservation checkpoint complete: the filtered timeline survives a fresh import.

The first row is the approved 01:00 baseline service logon. The next four relevant rows are failures from 198.51.100.42.

The sequence then shows a successful network logon to FILE-SRV-03. It ends with explicit-credential activity on that system.

Is the Export Missing or Incomplete?

  • Confirm that PowerShell is still working inside $HOME\IncidentResponseLab.
  • Check that the export path is exactly .\suspicious-timeline.csv.
  • Confirm that $timeline displays seven rows before repeating the export.

Help me troubleshoot my exported incident timeline.

✔️ Awesome, I've got everything!

Your correlation pipeline and evidence export commands are complete. Confirm that suspicious-timeline.csv contains seven reimported rows.

ⓧ I'd like to double check the full code

$timeline = $events |
    Where-Object -Property Account -EQ -Value "svc-backup" |
    Sort-Object -Property TimeCreated
$timeline

$timeline | Export-Csv -Path .\suspicious-timeline.csv -NoTypeInformation
Import-Csv -Path .\suspicious-timeline.csv

Your suspicious activity is now correlated into a defensible seven-row evidence file. Next up, you will turn that evidence into response decisions and a reusable incident playbook.

Write the Report and Playbook

Your seven-event svc-backup timeline now connects the unapproved source to a successful network logon. It also connects that source to explicit-credential activity on FILE-SRV-03.

An investigation becomes useful when evidence supports a clear response decision. That decision gives responders a defensible next move.

You will document the case in an incident report. You will preserve the investigation method in a reusable response playbook.

In this step, get ready to:
  • Complete an evidence-backed report with a containment decision.
  • Build a reusable suspicious-login response playbook.
  • Verify both files in Windows PowerShell.
Complete the evidence-backed report

A defensible report connects every conclusion to the timeline. It also separates confirmed evidence from actions that still require approval.

  • Switch back to incident-report.txt in Notepad from earlier.
  • Select all of the existing draft text.
  • Replace the draft with the report structure below by pasting it into the document:
Incident: Suspicious service-account authentication
Status: Escalate for containment

1. Executive summary
State what happened, which account and system are involved, and why the sequence is suspicious.

2. Evidence and timeline
List the seven correlated svc-backup events and cite suspicious-timeline.csv.

3. Scope and affected assets
Account: svc-backup
System: FILE-SRV-03
Source requiring investigation: 198.51.100.42

4. Severity and rationale
Choose Low, Medium, or High. Justify the choice using the successful network logon, service-account baseline violation, and explicit-credential activity.

5. Containment recommendations
Recommend disabling or restricting svc-backup, isolating FILE-SRV-03 if confirmed affected, blocking the unapproved source where appropriate, and preserving relevant logs before destructive changes.

6. Eradication and recovery recommendations
Recommend resetting credentials, checking dependent services, removing unauthorized access, validating the system, restoring normal service carefully, and monitoring for recurrence.

7. Communications
Identify who needs technical, management, legal, or external notification based on the confirmed scope.

8. Lessons learned and improvements
Recommend one detection improvement, one account-control improvement, and one playbook improvement.

How does this structure help?

  • Sections 1 through 4 turn the timeline into a finding with defined scope and severity.
  • Sections 5 through 7 convert that finding into response recommendations and communication decisions.
  • Section 8 captures improvements that reduce the chance of the same gap recurring.
  • Save incident-report.txt in Notepad.
  • Return to Windows PowerShell from earlier.
  • Display the saved report structure by running this command:
Get-Content -Path .\incident-report.txt

What should you see?

The Get-Content command reads the report one line at a time. You should see the incident title followed by all eight section headings.

What belongs in the completed report?

  • The executive summary states that four failures were followed by a successful network logon. It also names the explicit-credential activity on FILE-SRV-03.
  • The evidence section cites suspicious-timeline.csv. It records all seven svc-backup events in chronological order.
  • The scope section names svc-backup as the affected account. It names FILE-SRV-03 as the affected system.
  • The scope section records 198.51.100.42 as the source requiring investigation.
  • The severity section chooses Low, Medium, or High. Its rationale cites the successful network logon.
  • The severity rationale also cites the service-account baseline violation. It includes the explicit-credential event.
  • The containment section recommends restricting svc-backup. It preserves logs before destructive changes.
  • The containment section recommends investigating or isolating FILE-SRV-03. It addresses the unapproved source where appropriate.
  • The recovery section covers credential reset and dependent-service validation. It also covers unauthorized-access removal.
  • The recovery section defines controlled restoration. It adds monitoring for recurrence.
  • The communications section identifies the technical and management audiences. It considers legal or external notification according to confirmed scope.
  • The final section records one detection improvement. It also records one account-control improvement and one playbook improvement.
  • Return to incident-report.txt in Notepad.
  • Replace every directive sentence with a completed decision grounded in the evidence checklist.
  • Save incident-report.txt.

Before you read the completed report back, do you expect any directive sentences or blank decisions to remain?

  • Display the completed report by running this command:
Get-Content -Path .\incident-report.txt

What should you see now?

You should see Escalate for containment beneath the incident title. Every section should contain a case-specific decision with no blank fields.

Seeing prompts or missing sections?

Return to Notepad and confirm that you edited incident-report.txt inside $HOME\IncidentResponseLab. Save the file before reading it again.

Compare the visible headings with the structural reference below.

Help me find missing decisions in my incident report.

✔️ Awesome, I've got everything!

Your report now records the evidence, scope, severity, response recommendations, communication decisions, and improvements.

ⓧ I'd like to double check the full code

Incident: Suspicious service-account authentication
Status: Escalate for containment

1. Executive summary
State what happened, which account and system are involved, and why the sequence is suspicious.

2. Evidence and timeline
List the seven correlated svc-backup events and cite suspicious-timeline.csv.

3. Scope and affected assets
Account: svc-backup
System: FILE-SRV-03
Source requiring investigation: 198.51.100.42

4. Severity and rationale
Choose Low, Medium, or High. Justify the choice using the successful network logon, service-account baseline violation, and explicit-credential activity.

5. Containment recommendations
Recommend disabling or restricting svc-backup, isolating FILE-SRV-03 if confirmed affected, blocking the unapproved source where appropriate, and preserving relevant logs before destructive changes.

6. Eradication and recovery recommendations
Recommend resetting credentials, checking dependent services, removing unauthorized access, validating the system, restoring normal service carefully, and monitoring for recurrence.

7. Communications
Identify who needs technical, management, legal, or external notification based on the confirmed scope.

8. Lessons learned and improvements
Recommend one detection improvement, one account-control improvement, and one playbook improvement.

How to use this reference

Keep every heading and the containment status shown here. Your finished report replaces each directive sentence with evidence-backed prose.

Strong work. Your correlated evidence now supports a clear containment decision.

Build the reusable response playbook

The report captures this specific investigation. The playbook preserves the process that analysts can apply to future suspicious-login alerts.

  • Create login-incident-playbook.txt in the current lab folder by running this command:
notepad.exe .\login-incident-playbook.txt

What does this command do?

The command opens login-incident-playbook.txt in Notepad. The relative path places the file inside the current IncidentResponseLab folder.

  • Add the playbook title and its first two sections by pasting this block into Notepad:
Suspicious Login Incident Response Playbook

Preparation
- Define account and source baselines.
- Confirm Incident Manager, Tech Manager, and Communications Manager contacts.
- Identify log sources and evidence-preservation locations.

Detect
- Validate the alert.
- Collect failed, successful, and explicit-credential events.
- Correlate account, time, source address, workstation, and logon type.
- Compare activity with the approved baseline.

What do these sections cover?

Preparation defines the baselines, contacts, and evidence locations needed before an incident. Detect turns an alert into a correlated set of events that can be compared with approved activity.

  • Save login-incident-playbook.txt in Notepad.
  • Return to Windows PowerShell from earlier.
  • Confirm that the first two sections were saved by running this command:
Get-Content -Path .\login-incident-playbook.txt

What should you see?

You should see the playbook title followed by Preparation and Detect. Each section should contain its complete procedure list.

Missing Preparation or Detect?

Confirm that Notepad saved the file as login-incident-playbook.txt. Check that the filename does not have an extra .txt extension.

Help me troubleshoot my missing playbook sections.

  • Return to login-incident-playbook.txt in Notepad.
  • Append the remaining response procedures below the final Detect item by pasting this block:
Respond
- Declare severity and scope.
- Preserve the working timeline and original evidence.
- Contain affected accounts, systems, and sources using approved procedures.
- Investigate persistence and unauthorized access before eradication.

Recover
- Reset or replace exposed credentials.
- Validate affected systems and dependent services.
- Restore access in a controlled order.
- Monitor for recurrence.

Communicate
- Maintain a single incident owner and update cadence.
- Escalate to technical, management, legal, communications, and external parties as required.

Improve
- Hold a blameless retrospective.
- Update detections, account controls, and this playbook.

How does the response flow work?

  • Respond preserves evidence before approved containment procedures change the environment.
  • Recover validates affected systems before access returns in a controlled order.
  • Communicate gives the incident one owner and a consistent update cadence.
  • Improve turns lessons from the incident into stronger detections, controls, and procedures.
  • Save login-incident-playbook.txt.

In Notepad, you should now see all six procedure headings. Each heading should contain concrete actions for that phase.

✔️ Awesome, I've got everything!

Your playbook now covers preparation, detection, response, recovery, communication, and improvement.

ⓧ I'd like to double check the full code

Suspicious Login Incident Response Playbook

Preparation
- Define account and source baselines.
- Confirm Incident Manager, Tech Manager, and Communications Manager contacts.
- Identify log sources and evidence-preservation locations.

Detect
- Validate the alert.
- Collect failed, successful, and explicit-credential events.
- Correlate account, time, source address, workstation, and logon type.
- Compare activity with the approved baseline.

Respond
- Declare severity and scope.
- Preserve the working timeline and original evidence.
- Contain affected accounts, systems, and sources using approved procedures.
- Investigate persistence and unauthorized access before eradication.

Recover
- Reset or replace exposed credentials.
- Validate affected systems and dependent services.
- Restore access in a controlled order.
- Monitor for recurrence.

Communicate
- Maintain a single incident owner and update cadence.
- Escalate to technical, management, legal, communications, and external parties as required.

Improve
- Hold a blameless retrospective.
- Update detections, account controls, and this playbook.

What does the full playbook show?

The complete file carries one investigation method from preparation through improvement. Each phase gives future responders a defined outcome.

Verify every decision

Reading both files back proves that your edits were saved in the case folder. This final review also catches empty fields before another analyst receives the case.

Before you run the checks, do you expect both documents to contain complete decisions with no unfinished prompts?

  • Read the final incident report by running this command:
Get-Content -Path .\incident-report.txt

Check the report

You should see all eight report sections with no blank decision fields. The report should cite suspicious-timeline.csv and mark the case Escalate for containment.

  • Read the final response playbook by running this command:
Get-Content -Path .\login-incident-playbook.txt

Check the playbook

You should see Preparation, Detect, Respond, Recover, Communicate, and Improve. Every section should contain its complete procedure list.

Still seeing an unfinished document?

Use the filename above the incomplete output to identify which document needs another edit. Return to that file in Notepad and replace any remaining prompt text.

Save the corrected file before running its Get-Content command again.

Help me review my final incident documents.

You have turned raw authentication evidence into a defensible response decision. You also have a repeatable process for the next suspicious-login alert.

Secret mission

Rule Out a False Positive

One explicit-credential event can look suspicious in isolation. You will correlate the four mroberts events against the approved baseline. You will add a defensible close or monitor decision to your incident report.

Clean Up Your Resources

Clean Up Your Resources

Your Northstar Retail case lives entirely on your Windows device with no ongoing cost. Choose the option that fits what you want to do next.

Resources you used:

  • Case brief: $HOME\IncidentResponseLab\case-brief.txt.
  • Original authentication evidence: $HOME\IncidentResponseLab\incident-events.csv.
  • Filtered suspicious timeline: $HOME\IncidentResponseLab\suspicious-timeline.csv.
  • Incident report: $HOME\IncidentResponseLab\incident-report.txt.
  • Response playbook: $HOME\IncidentResponseLab\login-incident-playbook.txt.

Keep everything running

No action is needed. Choose this option if you are still working with the case.

  • Keep the complete $HOME\IncidentResponseLab folder in your Windows user folder.
  • Retain all five files inside the folder so the report can keep pointing to its evidence.

Pause - I'll come back to this later

Shut down the running apps to pause your work. The files stay local at no cost.

  • Save any final changes in incident-report.txt.
  • Save any final changes in login-incident-playbook.txt.
  • Close Notepad.
  • Close Windows PowerShell.

You have kept the whole investigation intact for your next session.

Delete - I don't want to use this again

Deleting the case folder is permanent. Copy anything you value before you continue.

  • Copy any file you want to keep to a different folder.
  • Close Notepad.
  • Close Windows PowerShell.
  • Press the Windows key to open Windows search.
  • Type File Explorer into Windows search.
  • Press Enter to open File Explorer.

The case folder sits in your Windows user folder. PowerShell represents this location as $HOME.

  • Open your Windows user folder in File Explorer.
  • Select the IncidentResponseLab folder.
  • Press the Delete key to move the folder to Recycle Bin.

The folder now sits in Recycle Bin. Removing that single item protects unrelated deleted files.

  • Open Recycle Bin from the Windows desktop.
  • Select the IncidentResponseLab folder.
  • Use its context menu to permanently delete only that folder.
  • Approve the confirmation prompt.
  • Return to your Windows user folder.
  • Confirm that the IncidentResponseLab folder no longer appears.

Cleanup complete. The synthetic evidence plus both response documents are now removed from your device.

Nice Work!

Nice Work!

You did it! You turned 14 rows of synthetic authentication telemetry into a defensible investigation for Northstar Retail. Your case folder now shows why svc-backup needs escalation while mroberts needs a more measured verdict.

You've learned how to:

  • Used Windows PowerShell to turn 14 raw events into a chronologically sorted authentication timeline. Preserved the confirmed svc-backup path as a seven-row evidence file.
  • Correlated failed logons with successful network access to separate normal password mistakes from an incident candidate. Added explicit-credential activity to the analysis. Used source context plus account baselines to justify the svc-backup escalation.
  • Completed an evidence-backed incident report with clear response decisions. Built a reusable suspicious-login incident response playbook that covers preparation through improvement.
  • Secret Mission: Assessed the mroberts explicit-credential event against its approved baseline. Documented a close or monitor verdict with a stated confidence level. Named additional evidence that could change the verdict.

Ready to quiz yourself?