Investigate Account Takeover with Splunk

Analyze simulated login activity in Splunk and publish a SOC incident report.

Introduction

30 Second Summary

A burst of failed sign-ins can look alarming. A successful login from the same unfamiliar source can change the story completely.

In this project, you will act as a SOC analyst to investigate a simulated account takeover in Splunk Cloud Platform. You will turn your evidence into a public incident report on GitHub.

What You'll Build

Picture a public incident report that uses a clear authentication timeline to show why six failed logins followed by a suspicious success point to likely compromise.

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

  • A searchable authentication dataset in Splunk Cloud Platform that lets you inspect fictional sign-in activity without exposing real users.
  • A failed-login ranking that identifies the loudest source before a chronological timeline reveals the successful login that changes the case.
  • A public incident report on GitHub that makes your likely account takeover decision easy for another analyst to follow.
  • Secret Mission: Investigate a second source and explain why an attempted attack does not automatically prove an account takeover.

Are there any prerequisites?

This project uses browser-only workflows. No prior cybersecurity, coding, Git, or command-line experience is required.

Before We Start

Before the investigation begins, lock in what you are examining and why it matters. This commitment connects your simulated account takeover analysis to the public SOC report you plan to publish.

Set Up Your Investigation Workspace

Your security operations center investigation needs a reliable place to store evidence. It also needs a browser workspace for searching events.

GitHub keeps the eventual report shareable. Splunk Cloud Platform provides the SIEM workspace that turns uploaded events into searchable evidence.

Why This Browser-Based Pair?

A manual report records conclusions. Splunk Cloud Platform lets you search the events behind those conclusions.

GitHub keeps your final report available after the temporary Splunk trial ends.

In this step, get ready to:
  • Create a verified GitHub personal account.
  • Activate a 14-day Splunk Cloud Platform trial.
  • Create a public repository with an initialized README.md.
Create your GitHub account

GitHub requires a personal account with a verified email address. Verification connects the repository you create later to an account you control.

  • Visit the official GitHub signup page in your browser.
  • Enter an email address you can access in the signup form.
  • Complete the remaining on-screen prompts with your personal account details.
  • Open the verification message from GitHub in your email inbox.
  • Select the verification link in the message.
  • Sign in to GitHub.com in the same browser.

You should reach your signed-in GitHub account without another email-verification prompt. Your account is ready to own the public repository.

Verification Email Not Arriving?

Check the spam or junk folder for a message from GitHub. Confirm that the signup email address was entered correctly.

Ask for targeted help with finding or completing GitHub email verification.

Start your Splunk Cloud Platform trial

Splunk Web is the browser interface where you will upload authentication events. It also provides the search workspace for your investigation.

Starting a cloud trial can feel like a billing commitment. This trial runs for 14 days without requiring a credit card.

What Happens After 14 Days?

This step activates the free Splunk Cloud Platform trial. Continued use after the trial requires a paid license.

  • Visit the official Splunk Cloud Platform trial page in your browser.
  • Begin registration using the free trial option shown on the page.
  • Complete the Splunk account prompts using an email address you can access.
  • Open the verification message from Splunk in your email inbox.
  • Select the verification link in the message.
  • Sign in to your verified Splunk account.
  • Activate the Splunk Cloud Platform trial.
  • Open the instance link supplied by Splunk.

Splunk Web should load inside your active trial. Your cloud search workspace is now ready for authentication evidence.

Splunk Web Not Loading?

Confirm that you completed the Splunk email verification. Check your inbox for the instance link supplied after trial activation.

Ask for targeted help with accessing the Splunk Cloud Platform trial.

Create your public investigation repository

A public repository gives your final incident report a shareable home.

Choosing public can feel exposing. At this point the repository contains only its project name.

  • Switch back to the signed-in GitHub tab from earlier.
  • Choose New repository from the GitHub navigation.
  • Enter soc-authentication-investigation in the repository name field.
  • Select Public as the repository visibility.
  • Select Add README to initialize the repository.
  • Choose Create repository.

GitHub should open the new public repository. The rendered README shows soc-authentication-investigation as its heading.

Why Initialize the README?

GitHub renders README.md on the repository front page. This gives your investigation report a visible starting point.

Before you check both tabs, what two signs would prove that your investigation workspace is ready?

  • Keep the GitHub repository open in its current browser tab.
  • Switch back to the Splunk Web tab from earlier.
  • Return to the GitHub repository tab.

You should move between two working browser tabs. GitHub shows the initialized README.md. Splunk Web loads inside the active trial.

Your investigation workspace is ready for evidence. Next, you will load the authentication events that power your first Splunk search.

Load the Authentication Evidence

Your browser workspace is ready. Now you will move a safe authentication dataset from GitHub into Splunk Cloud Platform.

A SIEM becomes useful once its structured events are searchable. This step creates the first visible version of your investigation.

In this step, get ready to:
  • Create a synthetic authentication log in your public repository.
  • Download the raw evidence file from GitHub.
  • Upload the 16 events to Splunk Web and prove they are searchable.
Create the synthetic evidence file

A structured CSV keeps each timestamp, username, source address, action, and device in a consistent column. The fictional records let you investigate authentication behavior without exposing real user data.

  • Switch back to the GitHub tab containing your soc-authentication-investigation repository.
  • Select Add file above the repository file list.
  • Select Create new file.
  • Enter auth_events.csv in the filename field.
  • Populate auth_events.csv with the synthetic authentication dataset by pasting the code below:
timestamp,username,source_ip,action,device
2026-10-30T08:00:00Z,mrivera,10.0.0.15,success,managed-windows
2026-10-30T08:05:00Z,jmora,10.0.0.22,success,managed-macos
2026-10-30T08:10:00Z,achen,10.0.0.30,success,managed-windows
2026-10-30T09:00:00Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:00:20Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:00:40Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:01:00Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:01:20Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:01:40Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:02:00Z,mrivera,203.0.113.50,success,unknown-linux
2026-10-30T10:00:00Z,jmora,198.51.100.24,failure,unknown-browser
2026-10-30T10:00:30Z,jmora,198.51.100.24,failure,unknown-browser
2026-10-30T10:01:00Z,jmora,198.51.100.24,failure,unknown-browser
2026-10-30T10:01:30Z,jmora,198.51.100.24,failure,unknown-browser
2026-10-30T10:05:00Z,jmora,10.0.0.22,success,managed-macos
2026-10-30T10:10:00Z,achen,10.0.0.30,failure,managed-windows

What Does This File Contain?

  • The header turns timestamp, username, source_ip, action, and device into separate fields.
  • The 16 data rows create a small authentication timeline.
  • The fictional values keep the investigation safe to publish.
  • Select Preview above the file editor.
  • Confirm that the preview shows one header row plus 16 event rows.
  • Select Commit changes....
  • Enter Add authentication evidence in the commit message field.
  • Select Commit changes.

Solid start. Your public repository now lists README.md and auth_events.csv.

Does the File Preview Look Wrong?

Confirm that the filename ends with .csv. Check that every row contains five comma-separated values.

Ask for targeted help with fixing the authentication CSV structure.

✔️ Awesome, I've got everything!

Your synthetic evidence file is committed to the public repository.

ⓧ I'd like to double check the full code

timestamp,username,source_ip,action,device
2026-10-30T08:00:00Z,mrivera,10.0.0.15,success,managed-windows
2026-10-30T08:05:00Z,jmora,10.0.0.22,success,managed-macos
2026-10-30T08:10:00Z,achen,10.0.0.30,success,managed-windows
2026-10-30T09:00:00Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:00:20Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:00:40Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:01:00Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:01:20Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:01:40Z,mrivera,203.0.113.50,failure,unknown-linux
2026-10-30T09:02:00Z,mrivera,203.0.113.50,success,unknown-linux
2026-10-30T10:00:00Z,jmora,198.51.100.24,failure,unknown-browser
2026-10-30T10:00:30Z,jmora,198.51.100.24,failure,unknown-browser
2026-10-30T10:01:00Z,jmora,198.51.100.24,failure,unknown-browser
2026-10-30T10:01:30Z,jmora,198.51.100.24,failure,unknown-browser
2026-10-30T10:05:00Z,jmora,10.0.0.22,success,managed-macos
2026-10-30T10:10:00Z,achen,10.0.0.30,failure,managed-windows
Download the raw CSV

The raw download preserves the comma-separated file that Splunk needs to ingest. This creates an exact local copy of the evidence stored in your repository.

  • Select auth_events.csv in the repository file list.
  • Select Raw in the file view.
  • Use the download control in the file view to save the raw file to your computer.
  • Confirm that the downloaded file is named auth_events.csv.

That bridge is ready. You now have the repository evidence as a local file that Splunk can ingest.

Cannot Find the Downloaded File?

Check your browser's recent downloads. Confirm that the saved filename is auth_events.csv.

Ask for help with finding the raw GitHub download.

Upload and verify the events

Splunk can use the CSV header to extract searchable fields during indexing. The detected csv source type gives each event the same structure.

  • Switch back to the Splunk Web tab from earlier.
  • Select Settings.
  • Select Add Data.
  • Select Upload.
  • Select Select File.
  • Choose the downloaded auth_events.csv file.

Why Check the Preview?

The preview shows how Splunk interprets the file before indexing it. A 16-row preview confirms that every synthetic authentication event is available for ingestion.

  • Confirm that the detected source type is csv.
  • Review the preview for all 16 data rows.
  • Select Next to continue to Input Settings.
  • Select Next to continue to Review.
  • Select Submit.
  • Select Start Searching.

The ingestion is complete. Your 16 synthetic authentication events are now indexed in Splunk.

Does Splunk Show the Wrong Preview?

Confirm that you selected the raw auth_events.csv download. Check that the detected source type is csv before submitting the upload.

Ask for targeted help with diagnosing the CSV upload preview.

The evidence timestamps are historical. The All time range includes every event in the final count.

  • Set the Time Range Picker to All time.

Before you run the search, how many events do you expect Splunk to count from the uploaded file?

  • Verify that the uploaded evidence is searchable by running this search:
sourcetype=csv username=* | stats count

What Does This Search Do?

  • The sourcetype=csv filter keeps events from the uploaded CSV source type.
  • The username=* filter keeps events with a username value.
  • The stats count command reduces the matching events to one total.

The Statistics result shows a count of 16. You have turned a static evidence file into a searchable investigation dataset.

Does the Count Differ from 16?

Confirm that the time range is All time. Check that the search uses the csv source type.

Ask for help with diagnosing the Splunk event count.

Your authentication evidence is searchable. Next, you will rank the failed-login activity to find the loudest source.

Triage the Failed-Login Spike

Your 16 authentication events are now searchable in Splunk Cloud Platform. The next move in a security operations center workflow is to rank the failures so the loudest signal rises to the top.

A failure count can show where an authentication attack is concentrated. You still need to test whether that count supports an account-compromise decision.

In this step, get ready to:
  • Filter the dataset to failed logins.
  • Rank each source IP and username combination by failure count.
  • Decide what the leading result proves about access.
Rank the failed-login activity

An aggregation turns many individual events into a short ranking. This makes repeated activity visible without reading every log entry.

  • Switch back to the Splunk Search tab from earlier.
  • Set the Time Range Picker to All time.

Before you run the search, which source-and-user pair do you expect to produce the highest failure count?

  • Rank the failed-login activity by running this search:
sourcetype=csv action="failure" | stats count BY source_ip, username | sort -count

What Does This Search Do?

  • The action="failure" filter limits the results to failed authentication events.
  • The stats count BY source_ip, username command groups events by source and account.
  • The count records how many events belong to each combination.
  • The sort -count command places the largest count first.

The Statistics table contains three rows. The first row shows source IP 203.0.113.50 with username mrivera and a count of 6.

The second row shows 198.51.100.24 with jmora and a count of 4. The third row shows 10.0.0.30 with achen and a count of 1.

Good work. Your first triage view now puts the loudest failure source at the top.

This result exposes the intended shortfall. Six failures prove a repeated authentication attempt against mrivera from 203.0.113.50.

The result contains no proof that anyone logged in successfully. A failure spike supports investigation without establishing account compromise.

No Ranked Rows?

Confirm that the Time Range Picker shows All time. A narrower range can exclude the historical events.

Check that the search starts with sourcetype=csv. Confirm that it uses the field names source_ip and username.

Ask for targeted help with troubleshooting the failed-login search.

Explain the evidence gap

Incident triage separates indicators from conclusions. A cluster of failed logins is an indicator of attempted access.

Evidence of likely compromise requires proof that suspicious activity led to successful access. The current table cannot answer that question because the search includes only failures.

  • Compare the leading row with the two lower-count rows.
  • Check whether the failed-only result includes any successful login event.

The table supports the presence of an attempted authentication attack. It does not establish successful access to the account.

Before your final check, do you expect the ranking to prove attempted access or successful access?

  • Verify the leading signal by checking the first row in the Statistics table.

You should see source IP 203.0.113.50. You should also see username mrivera with a count of 6.

This confirms the leading signal is six failed login attempts against one account. Your defensible conclusion is an attempted authentication attack that needs more evidence before classification as a compromise.

You have isolated the loudest failure spike without over-classifying it. Next, you will build the account timeline to test whether the suspicious source gained access.

Correlate Events and Confirm the Incident

Your Splunk Cloud Platform ranking exposed the loudest failed-login signal. It left one critical question unanswered: did the suspicious source gain access?

Event correlation aligns activity by account, source, device, action, and time. The resulting timeline turns a noisy alert into a defensible incident decision.

In this step, get ready to:
  • Build a chronological timeline for mrivera.
  • Classify the incident from the correlated evidence.
  • Draft response and recovery recommendations.
Build the account timeline

A baseline captures the account's normal source and device. Comparing that baseline with later activity reveals whether the failed-login spike led to access.

  • Return to the Splunk Web tab from earlier.
  • Confirm that the Time Range Picker shows All time.

Before you run this search, do you think the suspicious source ever reaches a successful login?

  • Replace the current search with the query below:
sourcetype=csv username="mrivera" | sort timestamp | table timestamp, username, source_ip, action, device

What Does This Search Do?

  • The sourcetype=csv username="mrivera" filter limits the evidence to events for the affected account.
  • The sort timestamp command places the account events in chronological order.
  • The table command presents the fields needed to compare time, source, action, and device.
  • Press Enter in the search bar to run the account timeline.

You'll see the 08:00:00Z baseline from 10.0.0.15 on managed-windows. You'll then see six failures from 203.0.113.50 on unknown-linux.

The 09:02:00Z row shows a successful login from that same suspicious source and device. This later success closes the evidence gap left by the failed-login count.

Timeline Empty or Missing Fields?

  • Confirm that the Time Range Picker still shows All time.
  • Check that the search starts with sourcetype=csv.
  • Compare every field name with the header row in auth_events.csv.
  • Ask for help with troubleshooting the account timeline.
Classify the incident

Incident triage converts correlated evidence into a disposition. Medium severity is a scenario-specific judgment for this simulation.

Why Medium Severity?

The timeline indicates likely unauthorized access to one standard account. The dataset contains no privileged activity.

The evidence also contains no represented downstream impact. Those boundaries support a Medium classification for this case.

  • Identify 10.0.0.15 as the baseline source.
  • Identify managed-windows as the baseline device.
  • Trace the 6 failures from 203.0.113.50.
  • Match the 09:02:00Z success to 203.0.113.50.
  • Match the later success to unknown-linux.
  • Classify the simulated event as a likely account takeover.
  • Assign Medium severity to the incident.
  • Use the checkpoint below to document the supporting evidence.
Draft the response and recovery actions

Incident response turns the classification into steps that contain risk. These recommendations apply to the simulated account represented by the evidence.

Multi-factor authentication adds another identity check before access is restored. The remaining recommendations preserve the investigation while reducing the chance of repeated access.

  • Draft a recommendation to preserve the authentication evidence.
  • Draft a recommendation to disable mrivera during the investigation.
  • Draft a recommendation to revoke the account's active sessions.
  • Draft a recommendation to reset the account password.
  • Draft a recommendation to verify or enforce MFA before restoring access.
  • Draft a recommendation to investigate 203.0.113.50.
  • Draft a recommendation to investigate unknown-linux.
  • Draft a recommendation to monitor for recurrence.

Before your final check, which event should distinguish likely access from failed attempts alone?

  • Press Enter in the Splunk Web search bar to rerun the account timeline.

You'll see normal activity from 10.0.0.15 on managed-windows. You'll then see six failures from 203.0.113.50 on unknown-linux.

The final suspicious row shows a successful login from that same source and device. The sequence supports a likely account takeover with Medium severity.

You found the turning point. Your timeline now distinguishes an attempted authentication attack from likely unauthorized access.

Your investigation now has a defensible decision backed by correlated evidence. Next, you'll turn that analysis into a report another person can follow.

Publish the Incident Report

Your Splunk Cloud Platform timeline now supports a likely account takeover classification. The source change plus the device change gives your decision a defensible evidence trail.

Analysis has limited employment value when nobody else can review the reasoning. A public report in GitHub turns your investigation into a case that stands on its own after the temporary Splunk trial ends.

Why Publish on GitHub?

A public README preserves your evidence trail in a format that hiring managers can review without access to your Splunk instance. It shows how you communicate a security decision.

A manual report alone would miss the searchable investigation workflow you completed. Combining Splunk analysis with a GitHub report demonstrates both technical reasoning and written communication.

In this step, get ready to:
  • Replace the starter README.md content with the complete incident report.
  • Preview the rendered headings, timeline table, evidence searches, and response actions.
  • Commit the report and verify that it works without access to Splunk.
Draft the evidence-backed report

A Markdown README can combine concise findings with tables and searchable evidence. You will build the report in three short chunks so each preview confirms a visible part of the final case.

  • Return to README.md in the soc-authentication-investigation repository from earlier.
  • Select the file editor control in the upper-right corner.
  • Replace the existing # soc-authentication-investigation line by pasting this first report section:
# Simulated Account Takeover Investigation

This project documents a synthetic SOC investigation performed with Splunk Cloud Platform. All usernames, devices, timestamps, and network events are fictional. The public IP addresses come from IANA documentation ranges and do not identify real systems.

## Executive Summary

Authentication logs show six failed login attempts against `mrivera` from `203.0.113.50`, followed by a successful login from the same source and the same `unknown-linux` device. Earlier normal activity for the account used `10.0.0.15` and `managed-windows`.

Disposition: Likely account takeover in the simulated scenario.

Severity: Medium. The evidence indicates likely unauthorized access to one standard user account, but the dataset contains no privileged activity or downstream impact.

## Scope

- Affected account: `mrivera`
- Suspicious source: `203.0.113.50`
- Suspicious device: `unknown-linux`
- Evidence source: `auth_events.csv`
- Analysis platform: Splunk Cloud Platform

## Investigation Timeline

| Time | Event | Analyst interpretation |
| --- | --- | --- |
| 08:00:00Z | Successful login from `10.0.0.15` using `managed-windows` | Baseline activity |
| 09:00:00Z to 09:01:40Z | Six failed logins from `203.0.113.50` using `unknown-linux` | Repeated authentication attack |
| 09:02:00Z | Successful login from `203.0.113.50` using `unknown-linux` | Evidence of likely account compromise |

What Does This Section Do?

  • The opening labels every event as fictional so the public report does not imply that real accounts were exposed.
  • The executive summary states the disposition and Medium severity near the top.
  • The scope identifies the affected account, suspicious source, suspicious device, evidence file, and analysis platform.
  • The timeline shows the sequence that changed the alert from repeated failures into evidence of likely compromise.
  • Select Preview above the editor.

You should see the report title, executive summary, scope list, and a three-row investigation timeline. The table should show the normal login before the suspicious failures and later success.

Preview Still Shows the Starter Title?

Return to editing mode. Confirm that the original repository heading was replaced before the new content was pasted.

Ask for help with fixing the first README section.

  • Return to editing mode.
  • Append the evidence searches and key findings by pasting this after the timeline table:
## Evidence Searches

Failed-login triage:

```spl
sourcetype=csv action="failure" | stats count BY source_ip, username | sort -count
```

Account timeline:

```spl
sourcetype=csv username="mrivera" | sort timestamp | table timestamp, username, source_ip, action, device
```

## Key Findings

1. Failed logins alone showed an attack attempt but did not prove access.
2. The later successful login from the same source raised the event from suspicious activity to a likely account takeover.
3. The source and device differed from the account's earlier normal activity.
4. The provided evidence does not establish data access, privilege escalation, or lateral movement.

How Does This Preserve the Evidence?

  • The two SPL blocks record the searches that produced the triage ranking and account timeline.
  • The findings separate observed evidence from unsupported conclusions.
  • The final finding defines the investigation boundary by naming impacts that the dataset does not establish.
  • Select Preview above the editor.

You should see two formatted SPL blocks followed by four numbered findings. The first finding should explain why failed logins alone were insufficient.

SPL Searches Are Not Formatted?

Return to editing mode. Confirm that each search sits between matching lines of three backticks.

Ask for help with repairing the SPL blocks in Markdown.

  • Return to editing mode.
  • Complete the report by pasting this final section after the fourth key finding:
## Recommended Response and Recovery

1. Preserve the authentication evidence and investigation notes.
2. Disable the affected account and revoke its active sessions while the investigation continues.
3. Reset the account password and verify or enforce MFA before restoring access.
4. Review additional authentication, endpoint, and application logs for activity tied to the account, source, and device.
5. Restore access only after checking for additional indicators of compromise, then increase monitoring for recurrence.

## NIST Alignment

- Detect: Reviewed authentication events and characterized the adverse activity.
- Respond: Triaged the report, estimated severity, categorized the likely account takeover, and recommended containment.
- Recover: Recommended credential changes, tighter controls, verification before restoration, and continued monitoring.
- Improvement: Recorded lessons learned in an after-action report.

## Lessons Learned

A high failure count is a signal, not a conclusion. Correlation across username, source IP, device, action, and time produced the evidence needed to make a defensible incident decision.

How Does This Complete the Case?

  • The response section turns the classification into containment, investigation, recovery, and monitoring actions.
  • The NIST alignment connects the case to Detect, Respond, Recover, and Improvement activities.
  • The lesson records the central analytical principle demonstrated by the investigation.
  • Select Preview above the editor.

You should see the five response actions, four NIST alignment bullets, and the closing lesson. The report now carries the investigation from evidence through recovery.

Final Sections Look Merged Together?

Return to editing mode. Confirm that each level-two heading starts on its own line with a blank line above it.

Ask for help with fixing the final README layout.

✔️ Awesome, I've got everything!

Your report now contains every required section. Keep the GitHub editor open for the final review.

ⓧ I'd like to double check the full code

# Simulated Account Takeover Investigation

This project documents a synthetic SOC investigation performed with Splunk Cloud Platform. All usernames, devices, timestamps, and network events are fictional. The public IP addresses come from IANA documentation ranges and do not identify real systems.

## Executive Summary

Authentication logs show six failed login attempts against `mrivera` from `203.0.113.50`, followed by a successful login from the same source and the same `unknown-linux` device. Earlier normal activity for the account used `10.0.0.15` and `managed-windows`.

Disposition: Likely account takeover in the simulated scenario.

Severity: Medium. The evidence indicates likely unauthorized access to one standard user account, but the dataset contains no privileged activity or downstream impact.

## Scope

- Affected account: `mrivera`
- Suspicious source: `203.0.113.50`
- Suspicious device: `unknown-linux`
- Evidence source: `auth_events.csv`
- Analysis platform: Splunk Cloud Platform

## Investigation Timeline

| Time | Event | Analyst interpretation |
| --- | --- | --- |
| 08:00:00Z | Successful login from `10.0.0.15` using `managed-windows` | Baseline activity |
| 09:00:00Z to 09:01:40Z | Six failed logins from `203.0.113.50` using `unknown-linux` | Repeated authentication attack |
| 09:02:00Z | Successful login from `203.0.113.50` using `unknown-linux` | Evidence of likely account compromise |

## Evidence Searches

Failed-login triage:

```spl
sourcetype=csv action="failure" | stats count BY source_ip, username | sort -count
```

Account timeline:

```spl
sourcetype=csv username="mrivera" | sort timestamp | table timestamp, username, source_ip, action, device
```

## Key Findings

1. Failed logins alone showed an attack attempt but did not prove access.
2. The later successful login from the same source raised the event from suspicious activity to a likely account takeover.
3. The source and device differed from the account's earlier normal activity.
4. The provided evidence does not establish data access, privilege escalation, or lateral movement.

## Recommended Response and Recovery

1. Preserve the authentication evidence and investigation notes.
2. Disable the affected account and revoke its active sessions while the investigation continues.
3. Reset the account password and verify or enforce MFA before restoring access.
4. Review additional authentication, endpoint, and application logs for activity tied to the account, source, and device.
5. Restore access only after checking for additional indicators of compromise, then increase monitoring for recurrence.

## NIST Alignment

- Detect: Reviewed authentication events and characterized the adverse activity.
- Respond: Triaged the report, estimated severity, categorized the likely account takeover, and recommended containment.
- Recover: Recommended credential changes, tighter controls, verification before restoration, and continued monitoring.
- Improvement: Recorded lessons learned in an after-action report.

## Lessons Learned

A high failure count is a signal, not a conclusion. Correlation across username, source IP, device, action, and time produced the evidence needed to make a defensible incident decision.
Preview and commit the report

The complete preview is your final quality check before publication. It confirms that a reader can follow the evidence without seeing your Splunk workspace.

  • Select Preview above the editor.
  • Confirm that the rendered title reads Simulated Account Takeover Investigation.
  • Confirm that the investigation timeline contains three rows.
  • Confirm that both SPL searches appear in separate code blocks.
  • Confirm that the severity is Medium.
  • Confirm that the response section contains five numbered actions.
  • Confirm that the NIST alignment appears near the bottom.
  • Confirm that the lessons learned section closes the report.

The preview should now read as one complete incident case. Every conclusion has a visible path back to the evidence.

  • Select Commit changes... in the upper-right corner.
  • Keep the generated commit message.
  • Select Commit changes in the dialog.

That is the investigation published. Your repository front page now renders the full incident report above the project files.

Report Did Not Update?

Return to the repository front page. Refresh the page after confirming that the commit completed.

Ask for help with finding the missing README commit.

Verify the public report

A signed-out check tests the report from an outside reader's perspective. It proves that the case remains understandable without your GitHub session or temporary Splunk access.

Before the final check, form a prediction about whether the report can explain the classification without access to Splunk.

  • Copy the current repository address into your public repository URL.
  • Open a private or signed-out browser window.
  • Paste your public repository URL into the browser address bar.
  • Press Enter.

What Should You See?

  • The public repository opens without asking the reader to sign in.
  • The rendered README displays the executive summary, scope, investigation timeline, and evidence searches.
  • The report shows Medium severity plus the recommended response and recovery actions.
  • The NIST alignment and lessons learned remain understandable without access to the Splunk trial.

Repository Does Not Open Publicly?

Return to the signed-in repository tab. Confirm that you copied the repository address instead of the temporary file-editing address.

Ask for help with checking public access to the repository.

You now have a public incident report that preserves the evidence, decision, and recommended response. A reader can assess your SOC reasoning without needing your Splunk environment.

Secret mission

Separate an Attempt from a Compromise

Investigate a second authentication sequence with the same evidence model. Publish a comparison that distinguishes an unsuccessful attack from a likely account takeover.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep your public GitHub repository, sign out for now, or remove the report entirely. The project path costs $0, but your 14-day Splunk Cloud Platform trial keeps counting down while you are signed out.

Cost warning

The Splunk Cloud Platform trial requires no credit card. Allowing it to expire creates no automatic charge.

The 14-day clock continues while you are signed out. Continued use after the trial requires a paid license.

Resources you used:

  • The public repository named soc-authentication-investigation.
  • The rendered incident report in README.md.
  • The synthetic evidence file named auth_events.csv inside the repository.
  • The downloaded copy of auth_events.csv on your computer.
  • The active 14-day Splunk Cloud Platform trial with the uploaded CSV data.

Keep everything running

No action is needed. Choose this option if you want the public report to remain available while you continue investigating the synthetic data.

  • Keep the soc-authentication-investigation repository public.
  • Keep README.md available as your published incident report.
  • Keep the downloaded auth_events.csv file for future practice.
  • Continue using the searchable CSV data while the Splunk Cloud Platform trial remains active.

Your report stays public. Your authentication data remains searchable until the trial expires.

Pause - I'll come back to this later

Sign out of both services to end your active browser sessions. Your repository remains public while the 14-day trial continues counting down.

  • Sign out of GitHub from the account menu.
  • Return to Splunk Web from earlier.
  • Sign out from the Splunk account menu.
  • Keep the downloaded auth_events.csv file on your computer.
  • Return before the trial expires if you want to run more searches.

Your active browser sessions are closed. The public report remains available without an ongoing charge.

Delete - I don't want to use this again

This option permanently removes the public report. The synthetic dataset contains no live user or system evidence.

  • Return to the public soc-authentication-investigation repository from earlier.
  • Open the repository settings area.
  • Scroll to the repository deletion controls.
  • Choose the option that permanently deletes the repository.
  • Complete the on-screen confirmation prompts.
  • Use your browser history to revisit the repository front page.

You should see that the public repository is no longer available. This removes both README.md and the repository copy of auth_events.csv.

  • Open your browser's download history.
  • Reveal the downloaded auth_events.csv file in Finder or File Explorer.
  • Delete the downloaded auth_events.csv file.
  • Empty the Trash on macOS or the Recycle Bin on Windows.
  • Return to the folder that contained the downloaded file.

You should no longer see auth_events.csv in that folder.

  • Return to Splunk Web from earlier.
  • Sign out from the Splunk account menu.
  • Allow the no-credit-card trial to reach the end of its 14-day period.

Cleanup complete. Continued Splunk Cloud Platform use after the trial requires a paid license.

Nice Work!

Nice Work!

You completed the investigation! You used Splunk Cloud Platform to confirm a simulated account takeover. Your public GitHub report now presents the evidence behind that decision.

You've learned how to:

  • Transform auth_events.csv into searchable authentication evidence inside a SIEM.
  • Rank failed-login activity by source account. Correlate account activity across source IP and device. Track each action over time. Use the combined evidence to classify a likely account takeover with Medium severity.
  • Publish a public incident report that connects evidence to your severity decision. Recommend response actions. Recommend recovery actions. Align the analysis with NIST incident response guidance. Record lessons learned.
  • Secret Mission: Distinguish an unsuccessful authentication attack from a likely account takeover. Defend continued monitoring as the appropriate disposition for jmora.

Ready to quiz yourself? Let's see what you remember.