SOC Login Investigation with PowerShell

Investigate synthetic login events and write an evidence-backed SOC report.

Introduction

30 Second Summary

A suspicious sign-in alert can look urgent. The evidence often sits buried in a wall of timestamps, accounts, sources, devices, and outcomes.

In this project, you will investigate a synthetic sign-in alert with Windows PowerShell as a junior SOC analyst. You will turn authentication logs into an evidence-backed incident report through baselining, filtering, aggregation, and event correlation.

What You'll Build

The finished case shows raw events becoming ranked failures before a correlated timeline reveals the account that may be compromised.

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

  • A synthetic authentication case you can inspect safely. Its 16 events contain normal activity plus two concealed attack patterns.
  • A repeatable Windows PowerShell workflow that filters failed sign-ins. It ranks source addresses. It correlates later successes.
  • An evidence-backed incident report that another analyst can review. It captures the timeline. It records the severity decision. It recommends authorized response actions.
  • Secret Mission: Distinguish Password Guessing from Password Spraying. Map both patterns to MITRE ATT&CK.

Are there any prerequisites?

You need a computer running Windows 10 or newer. The project requires no administrator access, cloud account, or prior PowerShell experience.

Before We Start

First, lock in the purpose of your investigation before you begin the hands-on work. You are examining synthetic suspicious authentication activity to decide whether the alert should be escalated.

Prepare the SOC Case Files

A reliable SOC triage investigation depends on evidence you can trust. A dependable toolchain keeps every later result repeatable.

You will confirm Windows PowerShell before creating an untouched authentication log. You will use Notepad to preserve the source events exactly as supplied.

In this step, get ready to:
  • Verify that Windows PowerShell reports version 5.1.
  • Confirm that Notepad is available.
  • Prepare the C:\SOC-Lab workspace with the untouched source log.
Check your investigation tools

This project uses Windows PowerShell 5.1 so every later query behaves consistently. The version table identifies the shell currently running on your computer.

  • Press the Windows key to open the Start menu.
  • Type Windows PowerShell into the search box.
  • Select Windows PowerShell from the results.
  • Display the running version information by entering this command:
$PSVersionTable

What does this command do?

The $PSVersionTable command displays details about the current PowerShell session. The PSVersion row identifies the version used by your investigation.

✔️ I see version 5.1

Confirm that the PSVersion value begins with 5.1. Keep this Windows PowerShell window open for the next substep.

ⓧ I see an older version

Windows PowerShell 5.1 is included with supported Windows releases. An older result means the Windows installation needs an update before you continue.

  • Follow the official Windows Management Framework guidance to update the built-in framework.
  • Restart Windows after completing the update.
  • Repeat the version check above until PSVersion begins with 5.1.

ⓧ Windows PowerShell is missing

Windows PowerShell 5.1 is installed by default on supported Windows client computers. A missing result means the built-in Windows component needs to be restored.

  • Use the official Windows Management Framework guidance to restore the supported framework.
  • Restart Windows after restoring the component.
  • Repeat the Start menu search for Windows PowerShell.
  • Repeat the version check above until PSVersion begins with 5.1.

Notepad gives you a plain-text editor for the source data. Plain text keeps every comma-separated field visible.

  • Press the Windows key to open the Start menu.
  • Type Notepad into the search box.
  • Select Notepad from the results.

✔️ Notepad opens

Keep the blank Notepad document open. You will add the source events after preparing the case folder.

ⓧ Notepad is missing

The official Microsoft Store listing provides the plain-text editor required for this project.

  • Open the official Windows Notepad listing.
  • Use the listing's installation control to install the app.
  • Press the Windows key after the installation finishes.
  • Type Notepad into the search box.
  • Select Notepad from the results.

Your investigation tools are ready. You now have the exact shell required for the analysis plus a plain-text editor for preserving the evidence.

Create the SOC case folder

The C:\SOC-Lab folder keeps the case evidence in one known location. An existing folder can be reused without deleting its contents.

  • Switch back to the Windows PowerShell window from the version check.
  • Create the case folder by running this command:
New-Item -Path "C:\" -Name "SOC-Lab" -ItemType "Directory"

What does this command do?

  • New-Item creates a new item on your computer.
  • -Path "C:\" places the item directly on the C: drive.
  • -Name "SOC-Lab" gives the workspace its project name.
  • -ItemType "Directory" creates a folder.

For a new workspace, you will see directory details containing the name SOC-Lab. This confirms that C:\SOC-Lab now exists.

Folder already exists?

A message about an existing item means C:\SOC-Lab is already present. Reuse that folder without deleting its current files.

If the command cannot create the folder for another reason, check that the path begins with C:\.

help me create the SOC-Lab folder safely

Save and verify the source log

A source log should remain unchanged during an investigation. This synthetic dataset becomes the fixed evidence that every later query examines.

  • Switch back to the blank Notepad document.
  • Add the untouched source data by pasting the block below:
Timestamp,User,SourceIP,Device,Status
2026-09-18T08:00:00,alex,192.0.2.10,WS-01,Success
2026-09-18T08:02:00,maya,192.0.2.22,WS-02,Success
2026-09-18T08:05:00,alex,192.0.2.10,WS-01,Failure
2026-09-18T08:06:00,alex,192.0.2.10,WS-01,Success
2026-09-18T09:00:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:01:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:02:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:03:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:04:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:05:00,maya,203.0.113.42,UNKNOWN,Success
2026-09-18T09:20:00,devin,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:21:00,priya,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:22:00,chen,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:23:00,maya,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:24:00,alex,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:30:00,maya,192.0.2.22,WS-02,Success

How is the log structured?

  • The first line defines the five fields stored for each event.
  • Each remaining line represents one synthetic authentication event.
  • The commas preserve a consistent structure for PowerShell to import in the next step.
  • Select File in Notepad.
  • Select Save As.
  • Enter C:\SOC-Lab\auth-log.txt as the file name.
  • Confirm the save.

The saved document is now the untouched source record for your case. Every later finding can be traced back to these same events.

Did the file save somewhere else?

Repeat Save As if the document is not stored at C:\SOC-Lab\auth-log.txt. Enter the complete path so Notepad saves it inside the case folder.

Check that the filename ends with auth-log.txt.

help me save the authentication log in the correct folder

✔️ Awesome, I've got everything!

Great. Keep C:\SOC-Lab\auth-log.txt open in Notepad for the final check.

ⓧ I'd like to double check the full code

Compare your complete C:\SOC-Lab\auth-log.txt file with this source record:

Timestamp,User,SourceIP,Device,Status
2026-09-18T08:00:00,alex,192.0.2.10,WS-01,Success
2026-09-18T08:02:00,maya,192.0.2.22,WS-02,Success
2026-09-18T08:05:00,alex,192.0.2.10,WS-01,Failure
2026-09-18T08:06:00,alex,192.0.2.10,WS-01,Success
2026-09-18T09:00:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:01:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:02:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:03:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:04:00,maya,203.0.113.42,UNKNOWN,Failure
2026-09-18T09:05:00,maya,203.0.113.42,UNKNOWN,Success
2026-09-18T09:20:00,devin,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:21:00,priya,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:22:00,chen,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:23:00,maya,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:24:00,alex,198.51.100.25,UNKNOWN,Failure
2026-09-18T09:30:00,maya,192.0.2.22,WS-02,Success

Before you count the saved events, how many complete rows do you expect beneath the header?

  • Confirm that Notepad is displaying C:\SOC-Lab\auth-log.txt.
  • Count the event rows beneath the header.
  • Check that the final row ends with 2026-09-18T09:30:00,maya,192.0.2.22,WS-02,Success.

You should see the header plus 16 event rows. This confirms that the full source log is saved in the case workspace.

Missing an event row?

Compare the open file with the full source record above. A complete file starts with the header and ends with Maya's 09:30:00 success event.

Replace the file contents with the full source record if any line is missing. Save C:\SOC-Lab\auth-log.txt again before continuing.

help me find a missing row in the authentication log

Your case workspace now holds a complete source log. Next, you will load those events into Windows PowerShell to establish the normal login baseline.

Establish the Normal Login Baseline

Your untouched authentication log is ready at C:\SOC-Lab\auth-log.txt. Windows PowerShell remains open for the investigation.

Raw sign-in data contains ordinary failures beside suspicious behavior. A normal-login baseline gives your later SOC triage a reference point for deciding which events deserve attention.

In this step, get ready to:
  • Import the synthetic CSV as PowerShell objects.
  • Display all 16 authentication events in a table.
  • Use Alex's isolated failure-success sequence as the normal-login baseline.
Turn the CSV into event objects

PowerShell can turn each row of the source log into an object with named properties. Storing those objects in $logs creates a collection that later queries can filter or group.

  • Return to the Windows PowerShell window from the previous step.
  • Load the 16 event rows into $logs by running this command:
$logs = Import-Csv -Path C:\SOC-Lab\auth-log.txt

What does this command do?

  • Import-Csv reads the comma-separated source log.
  • Each CSV header becomes a property on the imported objects.
  • Each event row becomes one object in the collection.
  • $logs stores the complete collection for this PowerShell session.

A clean return to the PowerShell prompt confirms that the import completed. Your first analysis collection is now ready in $logs.

Import did not complete?

  • Check that the path in your command is exactly C:\SOC-Lab\auth-log.txt.
  • Return to C:\SOC-Lab\auth-log.txt in Notepad if PowerShell reports that it cannot find the file.
  • Confirm that the file still contains the CSV header plus 16 event rows.

help me diagnose why PowerShell cannot import my authentication log

See what raw chronology reveals

Chronological order shows what happened before each outcome. Your baseline comes from an isolated failure followed by a success on the same known device.

Before you display the events, which short sequence do you expect to represent ordinary login activity?

  • Display the complete event stream by running this command:
$logs | Format-Table -AutoSize

How does the table view work?

  • $logs sends the imported event objects into the PowerShell pipeline.
  • Format-Table arranges the object properties into columns.
  • -AutoSize adjusts each column width to fit its values.

You'll see all 16 events in a five-column table. Near the top you'll see Alex's 08:05 failure immediately followed by an 08:06 success.

Both rows use 192.0.2.10 on the known device WS-01.

  • Use Alex's two adjacent rows as your normal-login baseline.

Why is this the baseline?

Alex has one failed sign-in followed one minute later by a successful sign-in from the same source. The known device stays consistent across both events.

This pair gives you a concrete example of ordinary activity before you rank the larger patterns elsewhere in the log.

Table missing rows or columns?

  • Rerun the import command above to restore $logs if the variable is empty.
  • Widen the Windows PowerShell window if the table columns wrap.
  • Confirm that the source log contains 16 event rows if the table is shorter than expected.

help me fix my incomplete PowerShell event table

You have the baseline locked in with Alex's failure-success pair as the normal reference point. Next, you'll filter the failures to expose the patterns hidden by chronological noise.

Expose the Hidden Pattern

Your normal-login baseline now shows how an isolated failure can fit ordinary user behavior. The wider event stream still needs a reliable way to surface repeated activity.

Chronological authentication logs make concentrated failures difficult to rank.

Filtering creates a focused collection of failed sign-ins. Aggregation then ranks the source addresses by frequency.

In this step, get ready to:
  • Filter the event collection to failed sign-ins.
  • Group the failed sign-ins by source address.
  • Rank the source counts from highest to lowest.
Filter the failed sign-ins

The $logs variable still holds all 16 events in the Windows PowerShell session from earlier. A filtered collection lets you focus on failed outcomes without changing the source log.

  • Create the $failures collection in the Windows PowerShell window from earlier by running this command:
$failures = $logs | Where-Object Status -EQ "Failure"

What does this command do?

  • The $logs variable supplies all 16 imported authentication events.
  • The Where-Object condition keeps objects whose Status property equals "Failure".
  • The assignment stores the 11 matching events in $failures for the grouped query.

You are back at the PowerShell prompt with the failed events ready for aggregation.

Filter command showing an error?

Confirm that you used the Windows PowerShell window from earlier. The $logs variable only exists in the session where you imported the source log.

Check that Status matches the CSV header. Check that "Failure" includes both quotation marks.

Help me diagnose the failed-event filter.

Group and rank the sources

Source-level aggregation turns repeated addresses into a frequency ranking. That ranking makes concentrated behavior visible.

Before you run the grouped query, predict whether a single source will stand alone at the top.

  • Group the failed events by SourceIP and rank the counts by running this command:
$failures | Group-Object -Property SourceIP -NoElement | Sort-Object -Property Count -Descending

What does this command do?

  • The Group-Object -Property SourceIP -NoElement portion creates one summary row for each source address. Each row includes the number of failed events from that source.
  • The Sort-Object -Property Count -Descending portion places the highest counts first.

You'll see 203.0.113.42 with five failures. You'll see 198.51.100.25 with five failures.

You'll see 192.0.2.10 with one failure. That matches the normal-login baseline.

You've surfaced the hidden concentration: two unfamiliar sources are tied at five failures.

That tie is the intended shortfall. A count-only view cannot establish whether either source achieved access.

Grouped table missing or out of order?

Confirm that $failures was created in the same Windows PowerShell session before you run the grouped query.

Check that the query ends with -Descending if the one-failure source appears above the five-failure sources.

Help me fix the grouped failure query.

Your failure ranking has exposed two equally noisy sources. Next, you'll correlate each source with later outcomes to identify the activity that warrants escalation.

Correlate Evidence and Escalate

Windows PowerShell has exposed a tie between two sources with five failures each. Failure volume alone cannot establish impact.

Event correlation connects those failures to later outcomes. The result becomes an incident severity decision recorded in Notepad.

In this step, get ready to:
  • Build chronological timelines for both five-failure sources.
  • Identify the source with evidence of possible account access.
  • Save an incident report with severity evidence and response recommendations.
Build the source timelines

A source timeline places each event in time order. That order makes outcome changes visible.

Before you run these queries, which source do you think will show stronger evidence of impact?

  • Display both source timelines in chronological order by running these queries:
$logs | Where-Object SourceIP -EQ "203.0.113.42" | Sort-Object -Property Timestamp | Format-Table -AutoSize
$logs | Where-Object SourceIP -EQ "198.51.100.25" | Sort-Object -Property Timestamp | Format-Table -AutoSize

What Do These Queries Do?

  • Each Where-Object command selects events from one source address.
  • Sort-Object places the selected events in timestamp order.
  • Format-Table keeps the account, device, status, source, and timestamp visible together.

The first timeline shows five failures against maya from 09:00 through 09:04. It then shows a success at 09:05 from the same source and device.

The second timeline shows five failures across devin, priya, chen, maya, and alex. No success follows from that source.

You have found the deciding signal. The equal counts now describe two different levels of impact.

Timelines Missing or Unsorted?

Check that the source addresses match 203.0.113.42 and 198.51.100.25 exactly. A changed digit produces an empty result.

Confirm that $logs still contains the imported events. Reimport the untouched source log if the variable was cleared.

help me diagnose my source timeline queries

Prioritize the impacted account

Correlation resolves the count-only tie by adding outcome context. A failure followed by a success from the same source raises the possibility of account compromise.

  • Compare the Status values in the timeline for 203.0.113.42.
  • Confirm that all six events involve maya on UNKNOWN.
  • Compare the Status values in the timeline for 198.51.100.25.
  • Confirm that its five events contain failures without a success.

Why Is the Lab Severity High?

Under this project's rubric, 203.0.113.42 receives High lab severity. Its failure-then-success sequence indicates possible access to maya.

This severity belongs to the lab rubric. Production teams use their own playbooks to determine urgency.

The next actions remain recommendations for an authorized responder. You do not perform account changes or source blocking in this lab.

Write the incident report

An incident report turns terminal output into a reviewable handoff. Each field connects the escalation decision to observable evidence.

  • Return to the Notepad window from earlier.
  • Press Ctrl+N to create a blank document.
  • Add the incident findings by pasting this report:
Summary:
Potential account compromise affecting maya after five failures followed by a success from 203.0.113.42.

Evidence:
Five failures targeted maya from 203.0.113.42 on UNKNOWN from 09:00 through 09:04.
A success for maya followed from the same source and device at 09:05.
198.51.100.25 produced five failures across devin, priya, chen, maya, and alex without a success.

Timeline:
09:00 through 09:04: Five failures for maya from 203.0.113.42 on UNKNOWN.
09:05: One success for maya from 203.0.113.42 on UNKNOWN.

Affected Account: maya
Source: 203.0.113.42
Lab Severity: High
Confidence: High confidence in the observed sequence. Further investigation is required to confirm compromise.

Recommended Actions:
- An authorized responder should reset or disable the affected account according to organizational policy.
- An authorized responder should terminate active sessions.
- An authorized responder should review activity after 09:05.
- An authorized responder should block or monitor the source according to organizational policy.
- No response action was performed in this lab.

What Does This Report Capture?

  • Summary states the suspected impact in one sentence.
  • Evidence records the observations that support escalation.
  • Timeline preserves the failure-then-success sequence.
  • Lab Severity and Confidence separate urgency from certainty.
  • Recommended Actions gives an authorized responder a clear next move without claiming that the lab performed it.
  • Select File in Notepad.
  • Select Save As.
  • Enter C:\SOC-Lab\incident-report.txt in the File name box.
  • Confirm the save.

You should see incident-report.txt in the Notepad title bar. The saved document remains open for your final check.

✔️ Awesome, I've got everything!

Your saved report contains the required evidence, severity decision, authorization boundary, and response recommendations.

ⓧ I'd like to double check the full code

Compare your saved C:\SOC-Lab\incident-report.txt file with this complete report:

Summary:
Potential account compromise affecting maya after five failures followed by a success from 203.0.113.42.

Evidence:
Five failures targeted maya from 203.0.113.42 on UNKNOWN from 09:00 through 09:04.
A success for maya followed from the same source and device at 09:05.
198.51.100.25 produced five failures across devin, priya, chen, maya, and alex without a success.

Timeline:
09:00 through 09:04: Five failures for maya from 203.0.113.42 on UNKNOWN.
09:05: One success for maya from 203.0.113.42 on UNKNOWN.

Affected Account: maya
Source: 203.0.113.42
Lab Severity: High
Confidence: High confidence in the observed sequence. Further investigation is required to confirm compromise.

Recommended Actions:
- An authorized responder should reset or disable the affected account according to organizational policy.
- An authorized responder should terminate active sessions.
- An authorized responder should review activity after 09:05.
- An authorized responder should block or monitor the source according to organizational policy.
- No response action was performed in this lab.

What Should Match?

Check every field heading against your report. Confirm that the evidence names the same account, source, device, timeline, severity, and authorization boundary.

Before the final check, which details should prove that the failure-count tie has been resolved?

  • Review the saved C:\SOC-Lab\incident-report.txt file in Notepad.

You should see 203.0.113.42 named as the high-priority source. The affected account should be maya.

The timeline should cover 09:00 through 09:05 from UNKNOWN. The lab severity should be High.

The recommendations should be reserved for an authorized responder. The report should state that no response action was performed.

That closes the count-only gap. Your escalation now rests on a timeline with evidence of possible account access.

Report Missing Details?

Check that the file name ends with incident-report.txt. A different name prevents the final case file from matching the investigation workspace.

Compare each heading with the full-report tab. Restore any missing timeline or authorization statement before saving again.

help me check my incident report

Secret mission

Separate Password Guessing from Password Spraying

Two sources caused five failures each. Their account targeting tells different stories. Extend your report with two MITRE ATT&CK mappings plus two proposed detections.

Clean Up Your Resources

Clean Up Your Resources

This project has no ongoing costs because every case file stays on your Windows computer. Choose Keep, Pause, or Delete below.

Resources you used:

  • The local case folder at C:\SOC-Lab.
  • The untouched synthetic source log at C:\SOC-Lab\auth-log.txt.
  • The completed incident report at C:\SOC-Lab\incident-report.txt.

Keep everything running

No action is needed. Choose this option if you want to preserve the completed investigation for future practice.

  • Retain C:\SOC-Lab on your computer.
  • Use auth-log.txt when you want to rerun queries in Windows PowerShell.
  • Use incident-report.txt when you want to review your evidence or triage decision.

Pause - I'll come back to this later

Close the active tools to end the session while preserving the case files. You can return to the investigation later.

  • Save any final changes to C:\SOC-Lab\incident-report.txt.
  • Close Notepad.
  • Close Windows PowerShell.
  • Leave C:\SOC-Lab untouched on your computer.

Your investigation is safely paused. The files remain ready for another session.

Delete - I don't want to use this again

Remove the local case workspace if you have finished with the investigation. This clears every resource created during the project.

Permanent Local Deletion

Deleting C:\SOC-Lab removes both case files from this computer.

Permanent deletion can feel severe. Your report cannot be recovered unless you saved a copy elsewhere.

Close the active tools
  • Confirm that you no longer need C:\SOC-Lab\incident-report.txt.
  • Close Notepad.
  • Close Windows PowerShell.
Find the case folder

File Explorer gives you a visible way to confirm that the folder is gone.

  • Press the Windows key to open search.
  • Type File Explorer and press Enter.
  • Select the address bar.
  • Enter C:\.
  • Press Enter to display the folders on the drive.
Delete the case folder
  • Select the SOC-Lab folder.
  • Press Shift+Delete to request permanent deletion.
  • Confirm the permanent deletion in the prompt.
  • Check the file list to confirm that SOC-Lab is no longer present.

Cleanup complete. Your local SOC case workspace has been removed.

Nice Work!

Nice Work!

Case closed! You turned 16 synthetic authentication events into an evidence-backed SOC triage decision with Windows PowerShell. Your saved incident report gives another analyst a clear escalation path for suspicious activity involving maya.

You've learned how to:

  • Establish a normal-login baseline from all 16 authentication events. You used Alex's isolated failure followed by a success to recognize ordinary behavior before escalating suspicious activity.
  • Isolate failed sign-ins with filtering. You grouped failures by source address to expose two sources with equal counts. You ranked those groups to focus the investigation.
  • Use event correlation to connect five failures from 203.0.113.42 with the later success for maya. You documented the evidence in C:\SOC-Lab\incident-report.txt with a High lab severity. You also recommended actions for an authorized responder.
  • Secret Mission: Distinguish Password Guessing from Password Spraying by comparing how each source targeted accounts. You mapped both patterns to MITRE ATT&CK using T1110.001 Password Guessing plus T1110.003 Password Spraying. You proposed a detection for each pattern.

Ready to quiz yourself?