Lead Endpoint Incident Response

Lead a synthetic endpoint incident with Splunk evidence and SentinelOne guidance

Introduction

30 Second Summary

A single security alert can point to one compromised computer. The real intrusion may already extend to privileged accounts, business servers, or sensitive data.

In this project, you will lead a synthetic compromised-endpoint incident with Splunk Search & Reporting. You will turn the evidence into role-aware containment guidance for SentinelOne Singularity Endpoint plus an executive incident brief.

What You'll Build

Walk a hiring panel through the finished simulation to show how one endpoint alert became a defensible multi-asset response plan.

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

A safe incident simulation where you can run one synthetic alert plus a 12-event timeline in Splunk without indexing project data or changing production systems.
A defensible risk-based priority that separates confirmed facts from working hypotheses while tracking what remains unknown.
An interview-ready incident brief that turns evidence into a blast-radius assessment, role-aware containment guidance, an executive update, recovery gates, and prioritized improvements.
Secret Mission: Reassess the incident after late evidence confirms svc-backup activity on APP-SRV-04.

Are there any prerequisites?

This project assumes some SOC or IT experience. You also need authorized access to a Splunk deployment plus a SentinelOne tenant on a Microsoft Windows device.

No production response permission is required.

Before We Start

Before any evidence appears, commit to leading synthetic incident IR-2026-017 as its incident manager. This checkpoint anchors your leadership in risk-based triage, containment trade-offs, and stakeholder decisions.

Prepare a Safe Incident Workspace

Incident leadership needs an auditable record before evidence starts moving through tools. Clear safety boundaries also protect production data from a synthetic exercise.

You will prepare a local workspace in Notepad. You will also verify a temporary SPL search path in Splunk Search & Reporting.

You will confirm read-only tenant visibility in SentinelOne Singularity Endpoint. Every endpoint response control stays untouched.

In this step, get ready to:

Create three empty incident files in a local workspace.
Prepare Splunk Search & Reporting for a temporary search.
Confirm read-only SentinelOne visibility without using a response control.

Create the local incident workspace

Each empty file has one job in the incident record. Keeping the files local prevents synthetic material from entering a shared Splunk index.

Select the Start button.
Type Notepad into the search box.

✔️ Notepad appears in the results

Select Notepad from the search results.

Notepad opens with an empty document. The blank document is ready to become your first incident file.

ⓧ Notepad is unavailable

Microsoft Store provides Notepad when the app is missing from Windows.

Type Microsoft Store into the Start search box.
Select Microsoft Store from the search results.
Search for Notepad in Microsoft Store.
Install Notepad from its app listing.

The completed installation makes Notepad available through Start search.

Return to the Start search box.
Type Notepad into the search box.
Select Notepad from the search results.

Notepad opens with an empty document. You can now create the incident files.

Still Unable to Open Notepad?

Confirm that the Microsoft Store installation completed.
Search for Notepad from Start again.

Use this prompt if the app still does not appear. Help me troubleshoot the Notepad installation.

Select File in Notepad.
Select Save As.
Select Documents as the save location.
Create a folder named IR-2026-017 with the new-folder control.

The Save As dialog now shows the local incident folder inside Documents.

Open the IR-2026-017 folder.
Enter first_alert.spl in the File name box.
Set Save as type to All files (*.*).
Select Save.

The first empty search file now exists in Documents\IR-2026-017.

Select File in Notepad.
Select Save As.
Enter incident_evidence.spl in the File name box.
Set Save as type to All files (*.*).
Select Save.

The workspace now contains a second empty file for the broader synthetic evidence.

Select File in Notepad.
Select Save As.
Enter incident_brief.md in the File name box.
Set Save as type to All files (*.*).
Select Save.

Your local incident workspace now contains all three empty files.

Select File in Notepad.
Select Save As to view the current folder.
Confirm that the folder list shows first_alert.spl, incident_evidence.spl, and incident_brief.md.

That is your incident record ready. Each file is empty because later steps add evidence only when the simulation calls for it.

✔️ Awesome, I've got everything!

Great. Double-check that Documents\IR-2026-017 contains the three empty files.

ⓧ I'd like to double check the full code

The complete target state contains no file content at this point.

Confirm that first_alert.spl contains no text.
Confirm that incident_evidence.spl contains no text.
Confirm that incident_brief.md contains no text.

Seeing Extra .txt Extensions?

Return to Notepad.
Use Save As for the affected file.
Set Save as type to All files (*.*).
Remove .txt from the end of the file name.

The final names must match the workspace list exactly. Help me fix these Notepad file extensions.

Open a safe Splunk search session

A self-contained synthetic search creates evidence in temporary memory. This keeps the exercise away from shared production indexes.

Why Use a Synthetic Search?

A self-contained SPL simulation produces evidence without uploading a dataset. It also avoids changing ingestion settings.

This approach gives you repeatable evidence while preserving the safety boundary around production data.

Your credentials stay inside your organization's sign-in flow. This project never asks you to copy them into a local file.

Keep Production Untouched

Keep all synthetic project data on your Windows device.
Avoid uploading project data to Splunk.
Avoid indexing project data in Splunk.
Avoid saving project data to a shared production index.

Go to your organization's Splunk sign-in page in your browser.
Complete the normal sign-in flow with your organizational account.

Splunk Home confirms that your account can reach the existing deployment.

Select Search & Reporting in the Apps panel.

The search app opens with the Search bar ready for a query.

Select SPL in the language picker if that picker is available.

The search session is now ready for the temporary safety check.

Confirm tenant visibility and the safe search path

SentinelOne response controls can change real endpoints. A read-only visibility check proves that your role can reach the tenant while every endpoint remains untouched.

Go to your existing organizational SentinelOne console in your browser.
Complete the normal sign-in flow with your organizational account.

The console shows the tenant information available to your assigned role.

Confirm that your role can view tenant-level endpoint information.
Keep every response control unselected.

That check confirms read-only tenant visibility. No production response action has been selected or executed.

Before you run the final check, consider whether this search depends on indexed project data.

Return to the Splunk Search & Reporting session from earlier.
Place the safe query in the Search bar by pasting this SPL:

| makeresults count=1

What Does This Search Do?

The makeresults command generates a result in temporary memory.
The count=1 setting limits the output to one result.
The command does not save the result to disk.
The command does not index the result.

Press Enter or select the Search icon.
Select the Statistics tab.

You will see one temporary result in the Statistics tab. Your safe Splunk search path is now confirmed without indexing project data.

Search Did Not Return One Result?

Confirm that the Search bar contains the query exactly as shown.
Select SPL in the language picker if that picker is available.
Confirm that your organizational role includes search access.

Use this prompt if the temporary result still does not appear. Help me diagnose this safe Splunk search.

Your local record and safety boundaries are ready. Next, you will triage the first synthetic alert without treating one endpoint signal as the full incident.

Triage the First Endpoint Alert

Your safe workspace now protects the investigation from accidental production changes.

A correlated alert links a privileged identity to a finance endpoint. The signal creates urgency while leaving the wider incident scope unresolved.

Splunk generates this alert from temporary search results. No project data enters a shared index.

In this step, get ready to:

Run the synthetic alert to identify its evidence boundaries.
Defend a project-defined High priority with four impact dimensions.
Deliver an initial update that separates facts from hypotheses.

Run the synthetic first alert

This synthetic SPL query creates the starting signal without touching production data. It gives you a controlled evidence boundary for your first decision.

Switch back to Notepad from earlier.
Load the existing Documents\IR-2026-017\first_alert.spl file in Notepad.
Fill the empty file by pasting this query:

| makeresults
| eval alert_id="IR-2026-017"
| eval detected_asset="FIN-WS-044"
| eval user="p.admin"
| eval signal="Correlated suspicious endpoint and identity activity"
| eval status="Open"
| eval confidence="Medium"
| table _time, alert_id, detected_asset, user, signal, status, confidence

What does this query establish?

The makeresults command creates a temporary result for the simulation.
The eval commands assign the alert fields used for triage.
The table command presents those fields in a fixed order.

Save Documents\IR-2026-017\first_alert.spl.
Switch back to Splunk Search & Reporting from earlier.
Clear the previous query from the Search bar.
Copy the entire query from the saved first_alert.spl file.
Paste the query into the Search bar.

Before you run it, how much incident scope do you think one correlated alert can prove?

Press Enter or select the Search icon.

The Statistics tab shows one row. Its fields identify IR-2026-017, FIN-WS-044, p.admin, Open, and Medium.

The result confirms the alert record while leaving identity activity and incident spread unresolved. That narrow evidence boundary is the intended shortfall.

No synthetic result?

Confirm the query begins with | makeresults.
Check that the final line begins with | table.
Use Help me diagnose why my synthetic SPL query does not return one result..

✔️ Awesome, I've got everything!

Great. Double-check that you saved first_alert.spl after the successful search.

ⓧ I'd like to double check the full code

| makeresults
| eval alert_id="IR-2026-017"
| eval detected_asset="FIN-WS-044"
| eval user="p.admin"
| eval signal="Correlated suspicious endpoint and identity activity"
| eval status="Open"
| eval confidence="Medium"
| table _time, alert_id, detected_asset, user, signal, status, confidence

The single row sets a firm boundary around what you know. Your first incident record should preserve that boundary before assigning impact.

Switch back to Notepad from earlier.
Load the existing Documents\IR-2026-017\incident_brief.md file.
Record the initial facts and evidence gaps by pasting this content into the empty file:

# Incident IR-2026-017

Status: Active
Project-defined priority: High
Working classification: Potential compromise involving privileged identity `p.admin` and finance endpoint `FIN-WS-044`

## Initial facts

- Synthetic alert `IR-2026-017` is Open with Medium confidence.
- The alert identifies `FIN-WS-044` and `p.admin`.
- Signal: Correlated suspicious endpoint and identity activity.

## Initial hypotheses and unknowns

- Hypothesis: A privileged identity or finance endpoint may be compromised.
- Unknown: Identity activity, process execution, network activity, persistence, lateral movement, data exposure, and additional affected assets.

How does this preserve uncertainty?

The initial facts reproduce only the fields visible in the synthetic alert.
The hypothesis labels compromise as a possibility that still needs evidence.
The unknowns identify the investigation areas required to establish scope.

Save Documents\IR-2026-017\incident_brief.md.
Confirm the Notepad tab shows incident_brief.md as the file name.
Confirm the file contains separate Initial facts and Initial hypotheses and unknowns sections.

Brief saved with the wrong extension?

Confirm the file name ends with .md.
Remove any extra .txt extension from the file name.
Use Help me verify the incident brief file name..

Assess impact and set the priority

Risk-based triage turns partial evidence into a justified response priority. The possible privileged-identity impact and finance-endpoint impact support a preliminary project-defined priority of High.

Four dimensions keep that decision explainable. Functional impact covers operations. Information impact covers data. Recoverability covers restoration effort. Urgency covers response speed.

Place the cursor after the final unknown in incident_brief.md.
Press Enter twice to add one blank line.
Append the impact assessment by pasting this content:

## Initial impact assessment

Functional impact: Finance operations could be affected if containment is required.
Information impact: Unknown; finance data may be at risk.
Recoverability: Unknown pending evidence collection and asset validation.
Urgency: High because the alert involves a privileged identity and finance endpoint.

How does the priority stay defensible?

Functional impact identifies the finance operations that containment could disrupt.
Information impact keeps possible data exposure labeled as unknown.
Recoverability remains dependent on evidence collection and asset validation.
Urgency explains the High priority without claiming that compromise is confirmed.

Save Documents\IR-2026-017\incident_brief.md.
Confirm the file contains four distinct lines under Initial impact assessment.

Impact assessment missing a dimension?

Check for separate lines beginning with Functional impact and Information impact.
Check for separate lines beginning with Recoverability and Urgency.
Use Help me review my preliminary impact assessment..

Deliver the 30-second initial update

An initial update gives stakeholders a stable picture while investigation continues. It should separate confirmed alert facts from hypotheses before requesting specific evidence.

Place the cursor after the urgency line in incident_brief.md.
Press Enter twice to add one blank line.
Append the initial update by pasting this content:

## Initial update

We are investigating a medium-confidence correlated alert involving privileged account `p.admin` and finance endpoint `FIN-WS-044`. These are confirmed alert facts; compromise, data impact, and spread are not yet confirmed. I am requesting investigation of identity, process, network, persistence, and lateral-movement evidence before approving production containment actions.

How is the update structured?

The opening sentence names the confirmed alert context.
The second sentence labels compromise and spread as unconfirmed.
The final sentence requests evidence across five investigation areas.
The production containment boundary keeps response actions approval-controlled.

Save Documents\IR-2026-017\incident_brief.md.
Confirm the final section is named Initial update.
Confirm the update requests identity, process, network, persistence, and lateral-movement evidence.

Update blending facts with hypotheses?

Check that compromise remains explicitly unconfirmed.
Check that the request names each investigation area.
Use Help me check whether my initial incident update separates facts from hypotheses..

✔️ Awesome, I've got everything!

Strong work. Your first incident brief now turns one alert into a bounded leadership decision.

ⓧ I'd like to double check the full code

# Incident IR-2026-017

Status: Active
Project-defined priority: High
Working classification: Potential compromise involving privileged identity `p.admin` and finance endpoint `FIN-WS-044`

## Initial facts

- Synthetic alert `IR-2026-017` is Open with Medium confidence.
- The alert identifies `FIN-WS-044` and `p.admin`.
- Signal: Correlated suspicious endpoint and identity activity.

## Initial hypotheses and unknowns

- Hypothesis: A privileged identity or finance endpoint may be compromised.
- Unknown: Identity activity, process execution, network activity, persistence, lateral movement, data exposure, and additional affected assets.

## Initial impact assessment

Functional impact: Finance operations could be affected if containment is required.
Information impact: Unknown; finance data may be at risk.
Recoverability: Unknown pending evidence collection and asset validation.
Urgency: High because the alert involves a privileged identity and finance endpoint.

## Initial update

We are investigating a medium-confidence correlated alert involving privileged account `p.admin` and finance endpoint `FIN-WS-044`. These are confirmed alert facts; compromise, data impact, and spread are not yet confirmed. I am requesting investigation of identity, process, network, persistence, and lateral-movement evidence before approving production containment actions.

Before you rehearse it, which sentence do you expect to keep uncertainty clear for stakeholders?

Read the Initial update section aloud at a steady pace.

You should hear a clear boundary between confirmed alert facts and unconfirmed compromise.

Time a second rehearsal with any clock on your Windows device.

The update should fit within about 30 seconds while preserving the evidence request.

Before your final check, do you expect the saved query to reproduce the same evidence boundary?

Switch back to Splunk Search & Reporting from earlier.
Replace the Search bar contents with the saved query from first_alert.spl.
Press Enter or select the Search icon.

The Statistics tab shows one temporary row. It confirms IR-2026-017, FIN-WS-044, p.admin, Open, and Medium.

Your first alert now has a defensible priority and a leadership-ready update. Next, you will test whether this one-row view captures the true blast radius.

Expand the Investigation Scope

Your first-alert triage established a High priority. Its evidence only named p.admin on FIN-WS-044.

This step uses Splunk to reconstruct the activity around that alert. The timeline exposes the wider blast radius before you recommend containment.

In this step, get ready to:

Run a chronological 12-event synthetic timeline.
Compare asset-level and identity-level evidence pivots.
Update the incident brief with the expanded scope.

Build and run the 12-event timeline

A timeline connects isolated events through time. This query generates synthetic evidence in temporary memory without indexing project data.

Switch back to the empty Documents\IR-2026-017\incident_evidence.spl file in Notepad from earlier.
Populate the synthetic timeline by pasting this code:

| makeresults count=12
| streamstats count AS event_number
| eval _time=_time-((13-event_number)*300)
| eval event_type=case(event_number=1,"identity",event_number=2,"identity",event_number=3,"process",event_number=4,"process",event_number=5,"network",event_number=6,"identity",event_number=7,"file",event_number=8,"network",event_number=9,"identity",event_number=10,"persistence",event_number=11,"identity",event_number=12,"detection")
| eval user=case(event_number=1,"p.admin",event_number=2,"p.admin",event_number=3,"p.admin",event_number=4,"p.admin",event_number=5,"p.admin",event_number=6,"p.admin",event_number=7,"p.admin",event_number=8,"p.admin",event_number=9,"p.admin",event_number=10,"p.admin",event_number=11,"svc-backup",event_number=12,"p.admin")
| eval asset=case(event_number=1,"VPN-GW-01",event_number=2,"IDP-01",event_number=3,"FIN-WS-044",event_number=4,"FIN-WS-044",event_number=5,"FIN-WS-044",event_number=6,"APP-SRV-02",event_number=7,"APP-SRV-02",event_number=8,"APP-SRV-02",event_number=9,"IDP-01",event_number=10,"FIN-WS-044",event_number=11,"APP-SRV-03",event_number=12,"FIN-WS-044")
| eval peer=case(event_number=1,"external-origin",event_number=2,"external-origin",event_number=3,"local",event_number=4,"transfer-node.example",event_number=5,"transfer-node.example",event_number=6,"FIN-WS-044",event_number=7,"finance-share",event_number=8,"transfer-node.example",event_number=9,"external-origin",event_number=10,"local",event_number=11,"FIN-WS-044",event_number=12,"SOC")
| eval process=case(event_number=1,"none",event_number=2,"none",event_number=3,"winword.exe",event_number=4,"powershell.exe",event_number=5,"powershell.exe",event_number=6,"none",event_number=7,"archive.exe",event_number=8,"archive.exe",event_number=9,"none",event_number=10,"powershell.exe",event_number=11,"none",event_number=12,"none")
| eval action=case(event_number=1,"login",event_number=2,"MFA approval",event_number=3,"spawned child process",event_number=4,"download",event_number=5,"outbound connection",event_number=6,"remote login",event_number=7,"archive creation",event_number=8,"upload",event_number=9,"password reset",event_number=10,"scheduled task",event_number=11,"remote login",event_number=12,"correlated alert")
| eval result=case(event_number=1,"success",event_number=2,"success",event_number=3,"observed",event_number=4,"allowed",event_number=5,"allowed",event_number=6,"success",event_number=7,"success",event_number=8,"allowed",event_number=9,"failed",event_number=10,"success",event_number=11,"success",event_number=12,"open")
| eval evidence=case(event_number=1,"First successful login from a new region",event_number=2,"User later denies approving the MFA prompt",event_number=3,"Office process launched powershell.exe",event_number=4,"Script downloaded a payload",event_number=5,"First connection to transfer-node.example",event_number=6,"Privileged session established from FIN-WS-044",event_number=7,"Finance share staged into an archive",event_number=8,"Large outbound transfer allowed",event_number=9,"Reset attempt occurred after the transfer",event_number=10,"Persistence created on FIN-WS-044",event_number=11,"Service account used from FIN-WS-044",event_number=12,"SOC correlation opened the incident")
| sort 0 _time
| table _time, event_number, event_type, user, asset, peer, process, action, result, evidence

What does this timeline do?

The makeresults command creates 12 temporary rows without saving them to disk or an index.
The streamstats command numbers the rows so each event receives specific evidence.
The eval commands assign timestamps plus identity, endpoint, process, network, action, result, and evidence fields.
The sort command arranges the evidence chronologically.
The final table command presents the investigation fields in a readable order.

Save Documents\IR-2026-017\incident_evidence.spl.
Copy the full contents of incident_evidence.spl.
Return to the Splunk Search & Reporting session from earlier.
Replace the current Search bar contents with the copied SPL.

Before you run the search, which event do you think appears first in the reconstructed sequence?

Run the timeline by pressing Enter.

The Statistics tab shows 12 chronological rows. The sequence begins with an external login before moving through execution, server access, data staging, an allowed upload, persistence, service-account activity, and detection.

That first expansion is working. You now have a chronological trail instead of one alert row.

Timeline missing rows or fields?

Confirm the first line contains count=12.
Check that every case() expression closes with a parenthesis.
Confirm the final table line remains at the bottom of the search.

If the result still differs, help me compare my incident timeline query with the expected 12-event SPL query.

✔️ Awesome, I've got everything!

Great. Double-check that incident_evidence.spl is saved with the complete 12-event query.

ⓧ I'd like to double check the full code

| makeresults count=12
| streamstats count AS event_number
| eval _time=_time-((13-event_number)*300)
| eval event_type=case(event_number=1,"identity",event_number=2,"identity",event_number=3,"process",event_number=4,"process",event_number=5,"network",event_number=6,"identity",event_number=7,"file",event_number=8,"network",event_number=9,"identity",event_number=10,"persistence",event_number=11,"identity",event_number=12,"detection")
| eval user=case(event_number=1,"p.admin",event_number=2,"p.admin",event_number=3,"p.admin",event_number=4,"p.admin",event_number=5,"p.admin",event_number=6,"p.admin",event_number=7,"p.admin",event_number=8,"p.admin",event_number=9,"p.admin",event_number=10,"p.admin",event_number=11,"svc-backup",event_number=12,"p.admin")
| eval asset=case(event_number=1,"VPN-GW-01",event_number=2,"IDP-01",event_number=3,"FIN-WS-044",event_number=4,"FIN-WS-044",event_number=5,"FIN-WS-044",event_number=6,"APP-SRV-02",event_number=7,"APP-SRV-02",event_number=8,"APP-SRV-02",event_number=9,"IDP-01",event_number=10,"FIN-WS-044",event_number=11,"APP-SRV-03",event_number=12,"FIN-WS-044")
| eval peer=case(event_number=1,"external-origin",event_number=2,"external-origin",event_number=3,"local",event_number=4,"transfer-node.example",event_number=5,"transfer-node.example",event_number=6,"FIN-WS-044",event_number=7,"finance-share",event_number=8,"transfer-node.example",event_number=9,"external-origin",event_number=10,"local",event_number=11,"FIN-WS-044",event_number=12,"SOC")
| eval process=case(event_number=1,"none",event_number=2,"none",event_number=3,"winword.exe",event_number=4,"powershell.exe",event_number=5,"powershell.exe",event_number=6,"none",event_number=7,"archive.exe",event_number=8,"archive.exe",event_number=9,"none",event_number=10,"powershell.exe",event_number=11,"none",event_number=12,"none")
| eval action=case(event_number=1,"login",event_number=2,"MFA approval",event_number=3,"spawned child process",event_number=4,"download",event_number=5,"outbound connection",event_number=6,"remote login",event_number=7,"archive creation",event_number=8,"upload",event_number=9,"password reset",event_number=10,"scheduled task",event_number=11,"remote login",event_number=12,"correlated alert")
| eval result=case(event_number=1,"success",event_number=2,"success",event_number=3,"observed",event_number=4,"allowed",event_number=5,"allowed",event_number=6,"success",event_number=7,"success",event_number=8,"allowed",event_number=9,"failed",event_number=10,"success",event_number=11,"success",event_number=12,"open")
| eval evidence=case(event_number=1,"First successful login from a new region",event_number=2,"User later denies approving the MFA prompt",event_number=3,"Office process launched powershell.exe",event_number=4,"Script downloaded a payload",event_number=5,"First connection to transfer-node.example",event_number=6,"Privileged session established from FIN-WS-044",event_number=7,"Finance share staged into an archive",event_number=8,"Large outbound transfer allowed",event_number=9,"Reset attempt occurred after the transfer",event_number=10,"Persistence created on FIN-WS-044",event_number=11,"Service account used from FIN-WS-044",event_number=12,"SOC correlation opened the incident")
| sort 0 _time
| table _time, event_number, event_type, user, asset, peer, process, action, result, evidence

Pivot the evidence by asset and identity

A chronological view explains what happened over time. Pivots regroup the same evidence to show how activity clusters around assets or identities.

Keep these pivot edits in Splunk's Search bar. The saved incident_evidence.spl file remains the chronological source.

Copy the current timeline query within the Search bar.
Replace the final | table _time, event_number, event_type, user, asset, peer, process, action, result, evidence line with | stats count AS events values(user) AS users values(peer) AS peers values(action) AS actions BY asset.

Before you run the asset pivot, which endpoint or server do you expect to have the most events?

Run the asset pivot by pressing Enter.

The results group the events across VPN-GW-01, IDP-01, FIN-WS-044, APP-SRV-02, and APP-SRV-03. The asset view proves that the alert's endpoint is one part of a wider path.

Replace the current final stats line with | stats count AS events dc(asset) AS asset_count values(asset) AS assets values(action) AS actions BY user.

Before you run the identity pivot, do you expect the original alert identity to be the only account in the results?

Run the identity pivot by pressing Enter.

The user pivot shows p.admin across four assets: VPN-GW-01, IDP-01, FIN-WS-044, and APP-SRV-02.

A second row shows svc-backup on APP-SRV-03. That result expands the account scope beyond the privileged identity from the first alert.

Pivot results look incomplete?

Confirm that you replaced only the final line of the timeline query.
Check that the asset pivot ends with BY asset.
Check that the identity pivot ends with BY user.

If a row or field remains missing, help me diagnose my Splunk asset and identity pivots.

Update the incident brief and verify the scope

The expanded evidence supports a stronger incident hypothesis. Your brief now needs to distinguish confirmed impact from suspected spread.

Switch back to Documents\IR-2026-017\incident_brief.md in Notepad from earlier.
Select all existing text in the file.
Replace the selected text with the classification plus evidence sections by pasting this content:

# Incident IR-2026-017

Status: Active
Project-defined priority: High
Working classification: Compromised privileged identity with endpoint execution, lateral movement, persistence, and likely data exfiltration

## Facts

- A successful external login and MFA approval occurred for `p.admin`.
- `winword.exe` launched `powershell.exe` on `FIN-WS-044`.
- `FIN-WS-044` connected to `transfer-node.example` and later accessed `APP-SRV-02`.
- A finance share was archived and an outbound upload was allowed from `APP-SRV-02`.
- A scheduled task created persistence on `FIN-WS-044`.
- `svc-backup` was used from `FIN-WS-044` to access `APP-SRV-03`.

## Hypotheses and unknowns

- Hypothesis: `p.admin` was compromised before the endpoint activity began.
- Hypothesis: The allowed upload contained staged finance data.
- Unknown: Whether `APP-SRV-03` executed attacker-controlled activity.
- Unknown: Whether other accounts or assets share the same indicators.

How does the classification change?

The working classification now reflects confirmed endpoint execution, lateral movement, and persistence.
The likely exfiltration wording reflects archive creation followed by an allowed outbound upload.
The hypotheses retain uncertainty around the initial compromise point plus the contents of the transfer.
The unknowns preserve open questions about APP-SRV-03 and further spread.

Save Documents\IR-2026-017\incident_brief.md.
Confirm the brief now starts with the compromised-identity classification.
Confirm the final visible section is Hypotheses and unknowns.

Brief still shows the initial assessment?

Confirm you edited incident_brief.md inside Documents\IR-2026-017.
Check that the previous Initial facts heading no longer appears.

If both versions appear together, help me replace the preliminary incident brief with the evidence-backed version.

Append the impact assessment plus scope sections at the current cursor by pasting this content:

## Impact assessment

Functional impact: Finance operations may be disrupted by endpoint and server containment.
Information impact: Likely confidentiality impact because finance data was staged and an outbound upload was allowed.
Recoverability: Recovery requires credential rotation, endpoint validation or rebuild, server review, and monitoring for persistence.
Urgency: Immediate containment approval is required while scope continues to evolve.

## Scope

Confirmed affected: `FIN-WS-044`, `APP-SRV-02`, `p.admin`
Suspected affected: `APP-SRV-03`, `svc-backup`
Observed infrastructure: `VPN-GW-01`, `IDP-01`
External peer: `transfer-node.example`

How does the scope stay defensible?

Confirmed affected entries have direct evidence of suspicious execution, server activity, or privileged use.
Suspected affected entries require further validation before you claim attacker-controlled execution.
Observed infrastructure supported the access path without being classified as compromised.
The external peer records the transfer destination that connects network activity to likely information impact.

Save Documents\IR-2026-017\incident_brief.md.
Confirm FIN-WS-044 plus APP-SRV-02 appear under confirmed affected scope.
Confirm APP-SRV-03 plus svc-backup appear under suspected affected scope.

Scope section missing an asset?

Confirm the Scope heading appears after the complete impact assessment.
Check that VPN-GW-01 plus IDP-01 remain observed infrastructure.
Check that transfer-node.example remains the external peer.

If the categories are unclear, help me compare confirmed, suspected, and observed incident scope.

✔️ Awesome, I've got everything!

Great. Double-check that incident_brief.md contains the complete evidence-backed classification, findings, impact assessment, and scope.

ⓧ I'd like to double check the full code

# Incident IR-2026-017

Status: Active
Project-defined priority: High
Working classification: Compromised privileged identity with endpoint execution, lateral movement, persistence, and likely data exfiltration

## Facts

- A successful external login and MFA approval occurred for `p.admin`.
- `winword.exe` launched `powershell.exe` on `FIN-WS-044`.
- `FIN-WS-044` connected to `transfer-node.example` and later accessed `APP-SRV-02`.
- A finance share was archived and an outbound upload was allowed from `APP-SRV-02`.
- A scheduled task created persistence on `FIN-WS-044`.
- `svc-backup` was used from `FIN-WS-044` to access `APP-SRV-03`.

## Hypotheses and unknowns

- Hypothesis: `p.admin` was compromised before the endpoint activity began.
- Hypothesis: The allowed upload contained staged finance data.
- Unknown: Whether `APP-SRV-03` executed attacker-controlled activity.
- Unknown: Whether other accounts or assets share the same indicators.

## Impact assessment

Functional impact: Finance operations may be disrupted by endpoint and server containment.
Information impact: Likely confidentiality impact because finance data was staged and an outbound upload was allowed.
Recoverability: Recovery requires credential rotation, endpoint validation or rebuild, server review, and monitoring for persistence.
Urgency: Immediate containment approval is required while scope continues to evolve.

## Scope

Confirmed affected: `FIN-WS-044`, `APP-SRV-02`, `p.admin`
Suspected affected: `APP-SRV-03`, `svc-backup`
Observed infrastructure: `VPN-GW-01`, `IDP-01`
External peer: `transfer-node.example`

Strong work. Your brief now shows why this incident extends beyond one endpoint.

One final check confirms that the saved timeline still produces the evidence behind your scope decision.

Switch back to Documents\IR-2026-017\incident_evidence.spl in Notepad.
Copy the full saved query.
Return to the Splunk Search & Reporting session.
Replace the Search bar contents with the saved query.

Before you run the final check, do you expect the saved file to show the timeline or the most recent pivot?

Run the saved query by pressing Enter.

The Statistics tab shows 12 chronological rows. This confirms the pivot edits did not overwrite the saved timeline.

Replace the final table line with | stats count AS events dc(asset) AS asset_count values(asset) AS assets values(action) AS actions BY user.

Before you run the last pivot, which two identity rows should summarize the expanded account scope?

Run the identity pivot by pressing Enter.

The result shows p.admin across four assets. It also shows svc-backup on APP-SRV-03.

Final verification not matching?

Confirm the saved query returns 12 rows before you apply the identity pivot.
Confirm the identity pivot uses dc(asset) AS asset_count.
Confirm the identity pivot groups results with BY user.

If the two expected users still do not appear, help me trace the missing identity evidence in my Splunk query.

Your investigation now supports a documented multi-asset compromise hypothesis. Next, you will convert that evidence into controlled containment guidance without changing a production endpoint.

Direct Safe Containment

Your 12-event timeline exposed the identities and assets involved in the compromise. That evidence gives you a defensible basis for controlled action.

Safe containment removes attacker access while preserving evidence. Business gates also protect finance operations from an avoidable outage.

A read-only SentinelOne check shows which response controls your role can see. Your incident brief then turns that availability into approval-aware guidance.

In this step, get ready to:

Check which documented SentinelOne response actions your role can access.
Build a six-decision containment matrix with evidence and business gates.
Write an executive update that requests the next controlled actions.

Check response availability without acting

Response availability depends on tenant licensing and your assigned role. Recording what you can see prevents the containment plan from promising an action your team cannot perform.

Keep Production Unchanged

These controls can affect live endpoints. You will inspect availability without selecting any response action.

Stop the check if your console requires confirmation or begins an action workflow. Your goal is a role and capability map.

Switch back to the SentinelOne console from earlier.
Use an endpoint or threat record that your role is authorized to view to locate the response controls.
Check whether network isolation is visible.
Check whether kill is visible.
Check whether quarantine is visible.
Check whether remediate unwanted changes is visible.
Check whether Windows rollback is visible.
Classify each action as available to my role, requires escalation, or not visible in this tenant.

You now know which actions can move directly to an approval request. You also know where another owner or role is required.

Why Check Availability First?

SentinelOne can provide network isolation while preserving administrator interaction with the endpoint. Other actions can stop a process or change endpoint state.

A read-only check keeps those capabilities inside your incident plan until the correct owner approves execution.

Can't Confirm an Action's Availability?

Record the action as not visible in this tenant if the control does not appear. Record requires escalation if your role can see the action without using it.

Do not test a control to discover what it does. Help me classify my read-only SentinelOne capability check.

Build the containment decision matrix

A containment decision needs more than an action name. The matrix connects each action to its trigger and accountable owner.

Evidence gates protect the investigation record. Business gates control operational risk before a team changes production.

Return to incident_brief.md in Notepad from earlier.
Find the ## Impact assessment heading.
Select that heading through the urgency line.
Delete the selected text.
Keep ## Scope as the next heading after the hypotheses and unknowns.
Place your cursor after the External peer: `transfer-node.example` line.
Add the containment matrix by pasting this content:

## Containment decision matrix

| Decision | Trigger | Owner | Evidence gate | Business gate | Recovery check | Tenant status |
| --- | --- | --- | --- | --- | --- | --- |
| Revoke sessions and reset `p.admin` | Confirmed suspicious privileged use | Identity team | Preserve identity and MFA records | Confirm emergency access path | No new `p.admin` sessions | Requires approval |
| Apply network isolation to `FIN-WS-044` | Suspicious execution and persistence | Endpoint team | Preserve required endpoint evidence | Confirm user and finance impact | Endpoint remains manageable | Record tenant status |
| Use kill or quarantine for the confirmed threat | Process or file is validated as malicious | Endpoint team | Capture required process and file context | Confirm action scope | Threat no longer executes | Record tenant status |
| Restrict `APP-SRV-02` egress | Allowed upload after archive creation | Network and server teams | Preserve server and network logs | Confirm finance service dependency | No further suspicious transfer | Requires approval |
| Rotate or disable `svc-backup` | Service-account use from compromised source | Identity and service owners | Preserve authentication records | Validate dependent backup jobs | Services operate with new credential | Requires approval |
| Remediate or use Windows rollback on `FIN-WS-044` | Evidence and containment gates are complete | Endpoint and recovery teams | Evidence owner approves next phase | Recovery owner chooses rollback or rebuild | Clean validation and return-to-service approval | Record tenant status |

How Does the Matrix Control Risk?

The Trigger column states the evidence threshold for considering an action.
The Owner column assigns responsibility to the team that can safely direct the action.
The Evidence gate column protects records needed for investigation.
The Business gate column identifies the operational approval needed before execution.
The Recovery check column defines the observable condition required after containment.
The Tenant status column keeps the plan aligned with your read-only SentinelOne findings.

Save incident_brief.md.
Scroll through the matrix in Notepad to confirm that all six decision rows are visible.

Your matrix now covers identity revocation, endpoint isolation, threat control, server egress, service-account handling, and recovery action. Each decision has an accountable owner.

Does the Matrix Look Misaligned?

Confirm that every row begins and ends with a pipe character. Check that the separator row sits directly below the column headings.

Keep each decision on one line. Help me check my containment matrix formatting.

Finish the leadership brief

An executive update compresses the technical evidence into scope, impact, and requested decisions. A clear update also names uncertainty and sets the next communication point.

Place your cursor after the final row of the containment matrix.
Add the executive update by pasting this content:

## Executive update

SOC has confirmed a high-priority compromise involving privileged account `p.admin` and endpoint `FIN-WS-044`. Evidence indicates suspicious PowerShell execution, access to `APP-SRV-02`, likely staging and outbound transfer of finance data, persistence, and possible spread through `svc-backup` to `APP-SRV-03`. We recommend immediate revocation of `p.admin`, network isolation of `FIN-WS-044`, restricted egress for `APP-SRV-02`, and a dependency check before rotating `svc-backup`. Evidence collection and scope expansion continue. The next update is due in 30 minutes.

What Does This Update Communicate?

The opening sentence states the confirmed priority and primary scope.
The evidence sentence summarizes the observed execution and spread.
The recommendation sentence asks the responsible teams for controlled action.
The uncertainty sentence confirms that investigation continues.
The final sentence establishes a specific update cadence.

Save incident_brief.md.
Confirm the ## Executive update heading appears after the containment matrix.

The brief now translates the expanded investigation into concrete requests. It preserves approval boundaries for every production action.

Is the Executive Update Missing a Decision?

Check that the update requests revocation of p.admin and isolation of FIN-WS-044.

Confirm that it also requests restricted egress for APP-SRV-02 and a dependency check for svc-backup. Help me compare my executive update with the incident evidence.

✔️ Awesome, I've got everything!

Strong work. Double-check that you saved incident_brief.md with the matrix and executive update.

ⓧ I'd like to double check the full code

# Incident IR-2026-017

Status: Active
Project-defined priority: High
Working classification: Compromised privileged identity with endpoint execution, lateral movement, persistence, and likely data exfiltration

## Facts

- A successful external login and MFA approval occurred for `p.admin`.
- `winword.exe` launched `powershell.exe` on `FIN-WS-044`.
- `FIN-WS-044` connected to `transfer-node.example` and later accessed `APP-SRV-02`.
- A finance share was archived and an outbound upload was allowed from `APP-SRV-02`.
- A scheduled task created persistence on `FIN-WS-044`.
- `svc-backup` was used from `FIN-WS-044` to access `APP-SRV-03`.

## Hypotheses and unknowns

- Hypothesis: `p.admin` was compromised before the endpoint activity began.
- Hypothesis: The allowed upload contained staged finance data.
- Unknown: Whether `APP-SRV-03` executed attacker-controlled activity.
- Unknown: Whether other accounts or assets share the same indicators.

## Scope

Confirmed affected: `FIN-WS-044`, `APP-SRV-02`, `p.admin`
Suspected affected: `APP-SRV-03`, `svc-backup`
Observed infrastructure: `VPN-GW-01`, `IDP-01`
External peer: `transfer-node.example`

## Containment decision matrix

| Decision | Trigger | Owner | Evidence gate | Business gate | Recovery check | Tenant status |
| --- | --- | --- | --- | --- | --- | --- |
| Revoke sessions and reset `p.admin` | Confirmed suspicious privileged use | Identity team | Preserve identity and MFA records | Confirm emergency access path | No new `p.admin` sessions | Requires approval |
| Apply network isolation to `FIN-WS-044` | Suspicious execution and persistence | Endpoint team | Preserve required endpoint evidence | Confirm user and finance impact | Endpoint remains manageable | Record tenant status |
| Use kill or quarantine for the confirmed threat | Process or file is validated as malicious | Endpoint team | Capture required process and file context | Confirm action scope | Threat no longer executes | Record tenant status |
| Restrict `APP-SRV-02` egress | Allowed upload after archive creation | Network and server teams | Preserve server and network logs | Confirm finance service dependency | No further suspicious transfer | Requires approval |
| Rotate or disable `svc-backup` | Service-account use from compromised source | Identity and service owners | Preserve authentication records | Validate dependent backup jobs | Services operate with new credential | Requires approval |
| Remediate or use Windows rollback on `FIN-WS-044` | Evidence and containment gates are complete | Endpoint and recovery teams | Evidence owner approves next phase | Recovery owner chooses rollback or rebuild | Clean validation and return-to-service approval | Record tenant status |

## Executive update

SOC has confirmed a high-priority compromise involving privileged account `p.admin` and endpoint `FIN-WS-044`. Evidence indicates suspicious PowerShell execution, access to `APP-SRV-02`, likely staging and outbound transfer of finance data, persistence, and possible spread through `svc-backup` to `APP-SRV-03`. We recommend immediate revocation of `p.admin`, network isolation of `FIN-WS-044`, restricted egress for `APP-SRV-02`, and a dependency check before rotating `svc-backup`. Evidence collection and scope expansion continue. The next update is due in 30 minutes.

Before you review the completed brief, do you expect every containment decision to have all seven fields?

Review the containment matrix from top to bottom.
Count the six decision rows.
Confirm each row has a trigger.
Confirm each row has an owner.
Confirm each row has an evidence gate.
Confirm each row has a business gate.
Confirm each row has a recovery check.
Confirm each row has a tenant status field.

You should see six complete containment decisions. The rows cover p.admin, FIN-WS-044, the validated threat, APP-SRV-02, svc-backup, and remediation or Windows rollback.

Scroll to the executive update.
Confirm it requests identity revocation.
Confirm it requests endpoint isolation.
Confirm it requests APP-SRV-02 egress restriction.
Confirm it requests a svc-backup dependency review.
Confirm it sets the next update time to 30 minutes.

That is a controlled containment plan. You have converted technical findings into role-aware decisions without changing a production endpoint.

Your evidence now drives a safe response plan with clear ownership. Next, you will define recovery criteria and turn the incident into measurable improvements.

Complete the Post-Incident Brief

Your Splunk timeline exposed the incident scope that the original alert hid. Your SentinelOne Singularity Endpoint availability check turned that evidence into an approval-controlled containment plan.

A strong incident lead carries technical findings through recovery. Clear recovery gates keep urgency from pushing an unsafe return to service.

The completed brief also turns the incident into measurable improvements. Its interview story shows your judgment under uncertainty.

In this step, get ready to:

Complete the impact review without promoting hypotheses into facts.
Define observable return-to-service gates.
Prioritize improvements across technology, process, and people.
Rehearse a 90-second incident leadership story.

Complete the incident review

The existing sections establish the identities, activity, locations, and uncertainty in the investigation. The missing impact assessment explains why the project-defined priority remains High.

What does a complete review cover?

Who identifies the privileged user, service account, investigators, and response owners.
What summarizes the suspicious authentication, execution, persistence, lateral movement, and likely data movement.
Where separates confirmed assets, suspected assets, observed infrastructure, and the external peer.
Why keeps the proposed initial compromise path labeled as a hypothesis.
How connects the external login to endpoint execution, server access, staging, transfer, and persistence.

Switch back to incident_brief.md in Notepad from earlier.
Review the working classification to confirm what happened.
Review the Facts section to confirm the evidence sequence.
Check the Hypotheses and unknowns section for unsupported conclusions.
Review the Scope section for the affected identities and assets.
Find the ## Scope heading.
Add the impact assessment immediately above that heading by pasting this content:

## Impact assessment

Functional impact: Finance operations may be disrupted by endpoint and server containment.
Information impact: Likely confidentiality impact because finance data was staged and an outbound upload was allowed.
Recoverability: Recovery requires credential rotation, endpoint validation or rebuild, server review, and monitoring for persistence.
Urgency: Immediate containment approval is required while scope continues to evolve.

What does this assessment establish?

Functional impact identifies the possible disruption caused by containment.
Information impact connects the archive and allowed upload to a likely confidentiality impact.
Recoverability names the work required before affected systems return to service.
Urgency explains why containment approval cannot wait for every unknown to be resolved.

Save incident_brief.md.
Confirm the Impact assessment section appears between Hypotheses and unknowns and Scope.

The brief now connects the evidence to business impact. It also preserves uncertainty around root cause and data contents.

Impact assessment in the wrong place?

Check that the new heading sits directly above ## Scope. Confirm that each impact label appears on its own line.

Keep the two proposed compromise conclusions under Hypotheses and unknowns. Help me check whether my incident brief separates facts, hypotheses, and impact.

Define recovery gates

Containment limits immediate harm. Recovery criteria define the evidence that decision-makers need before restoring normal access or returning an asset to service.

Find the final sentence in the Executive update section of incident_brief.md.
Add the recovery criteria directly below that section by pasting this content:

## Recovery criteria

- Compromised credentials and active sessions are revoked or rotated.
- Confirmed and suspected assets are validated, rebuilt, or returned to service through the approved recovery path.
- No further suspicious authentication, execution, persistence, or outbound transfer is observed.
- Required evidence and incident records are preserved.
- Business owners approve return to service.
- Increased monitoring remains active for the agreed observation period.

What do these gates protect?

Credential revocation closes the confirmed privileged access path.
Asset validation covers clean review, rebuild, or another approved recovery path.
The observation gate checks that suspicious access, execution, persistence, and outbound transfer have stopped.
Evidence preservation keeps the response record available for investigation and review.
Business approval assigns ownership for the return-to-service decision.
Increased monitoring tests whether the recovered environment remains stable during the agreed observation period.

Save incident_brief.md.
Confirm the Recovery criteria section contains six observable gates.

Your return-to-service decision now depends on evidence, ownership, and continued observation. Recovery has a defined finish line.

Recovery criteria feel too vague?

Check that every criterion describes a state the response team can verify. Keep credentials, assets, suspicious activity, evidence, business approval, and monitoring as separate gates.

Avoid replacing a gate with an action plan. Help me distinguish a recovery gate from a containment action.

Prioritize improvements and rehearse the story

Post-incident improvements convert evidence into changes that reduce future risk. A balanced review covers technology, process, and people.

The interview story then compresses the incident into a decision narrative. Its structure keeps the focus on evidence, judgment, trade-offs, and outcome.

Move to the end of the Recovery criteria section in incident_brief.md.
Add the prioritized improvements below the recovery criteria by pasting this content:

## Post-incident improvements

1. Technology: Detect Office applications launching PowerShell and alert on scheduled-task creation from unusual parent processes.
2. Process: Require a service-account dependency owner and emergency rotation procedure in the containment playbook.
3. People: Rehearse MFA-fatigue reporting and privileged-account incident escalation with the SOC and identity teams.

Why use three improvement areas?

Technology improves detection for the execution and persistence patterns in the evidence.
Process assigns ownership before an emergency service-account rotation is required.
People practice the reporting and escalation behavior that shortens response time.

Save incident_brief.md.
Confirm the numbered list contains one technology improvement, one process improvement, and one people improvement.

The brief now closes three different gaps revealed by the incident. Each improvement traces back to observed evidence or a response dependency.

Missing an improvement category?

Check the numbered labels at the start of each line. The order must be Technology, Process, and People.

Keep each improvement tied to this incident scenario. Help me check whether my three improvements are evidence-based.

Place the cursor below the People improvement.
Add the 90-second interview story by pasting this content:

## Interview story

Situation: One medium-confidence alert named a finance endpoint and privileged user.
Evidence: Splunk pivots exposed execution, lateral movement, staging, outbound transfer, persistence, and service-account use.
Decision: I raised the project-defined priority to High and recommended identity revocation, endpoint isolation, controlled server restrictions, and service-owner coordination.
Trade-off: I balanced rapid containment against evidence needs and the risk of disrupting finance and backup services.
Outcome: I produced a scoped action plan, executive update, recovery gates, and three measurable improvements while keeping all production response actions approval-controlled.

How does the interview story work?

Situation establishes the ambiguous starting point.
Evidence shows how the investigation expanded the incident scope.
Decision explains the priority change and requested containment.
Trade-off demonstrates how you balanced speed, evidence, and business continuity.
Outcome summarizes the leadership artifacts produced without executing a production response action.

Save incident_brief.md.
Read the interview story aloud at a steady speaking pace.
Confirm the rehearsal takes about 90 seconds.

Your interview answer now follows the incident from ambiguity to controlled decisions. The story highlights leadership instead of listing tool clicks.

Interview story running long?

Keep one sentence for each of the five labels. Remove extra chronology before removing the decision or trade-off.

Preserve the approval-controlled outcome because no production response action was executed. Help me rehearse this incident story in 90 seconds.

✔️ Awesome, I've got everything!

Great. Double-check that you saved incident_brief.md.

ⓧ I'd like to double check the full code

# Incident IR-2026-017

Status: Active
Project-defined priority: High
Working classification: Compromised privileged identity with endpoint execution, lateral movement, persistence, and likely data exfiltration

## Facts

- A successful external login and MFA approval occurred for `p.admin`.
- `winword.exe` launched `powershell.exe` on `FIN-WS-044`.
- `FIN-WS-044` connected to `transfer-node.example` and later accessed `APP-SRV-02`.
- A finance share was archived and an outbound upload was allowed from `APP-SRV-02`.
- A scheduled task created persistence on `FIN-WS-044`.
- `svc-backup` was used from `FIN-WS-044` to access `APP-SRV-03`.

## Hypotheses and unknowns

- Hypothesis: `p.admin` was compromised before the endpoint activity began.
- Hypothesis: The allowed upload contained staged finance data.
- Unknown: Whether `APP-SRV-03` executed attacker-controlled activity.
- Unknown: Whether other accounts or assets share the same indicators.

## Impact assessment

Functional impact: Finance operations may be disrupted by endpoint and server containment.
Information impact: Likely confidentiality impact because finance data was staged and an outbound upload was allowed.
Recoverability: Recovery requires credential rotation, endpoint validation or rebuild, server review, and monitoring for persistence.
Urgency: Immediate containment approval is required while scope continues to evolve.

## Scope

Confirmed affected: `FIN-WS-044`, `APP-SRV-02`, `p.admin`
Suspected affected: `APP-SRV-03`, `svc-backup`
Observed infrastructure: `VPN-GW-01`, `IDP-01`
External peer: `transfer-node.example`

## Containment decision matrix

| Decision | Trigger | Owner | Evidence gate | Business gate | Recovery check | Tenant status |
| --- | --- | --- | --- | --- | --- | --- |
| Revoke sessions and reset `p.admin` | Confirmed suspicious privileged use | Identity team | Preserve identity and MFA records | Confirm emergency access path | No new `p.admin` sessions | Requires approval |
| Apply network isolation to `FIN-WS-044` | Suspicious execution and persistence | Endpoint team | Preserve required endpoint evidence | Confirm user and finance impact | Endpoint remains manageable | Record tenant status |
| Use kill or quarantine for the confirmed threat | Process or file is validated as malicious | Endpoint team | Capture required process and file context | Confirm action scope | Threat no longer executes | Record tenant status |
| Restrict `APP-SRV-02` egress | Allowed upload after archive creation | Network and server teams | Preserve server and network logs | Confirm finance service dependency | No further suspicious transfer | Requires approval |
| Rotate or disable `svc-backup` | Service-account use from compromised source | Identity and service owners | Preserve authentication records | Validate dependent backup jobs | Services operate with new credential | Requires approval |
| Remediate or use Windows rollback on `FIN-WS-044` | Evidence and containment gates are complete | Endpoint and recovery teams | Evidence owner approves next phase | Recovery owner chooses rollback or rebuild | Clean validation and return-to-service approval | Record tenant status |

## Executive update

SOC has confirmed a high-priority compromise involving privileged account `p.admin` and endpoint `FIN-WS-044`. Evidence indicates suspicious PowerShell execution, access to `APP-SRV-02`, likely staging and outbound transfer of finance data, persistence, and possible spread through `svc-backup` to `APP-SRV-03`. We recommend immediate revocation of `p.admin`, network isolation of `FIN-WS-044`, restricted egress for `APP-SRV-02`, and a dependency check before rotating `svc-backup`. Evidence collection and scope expansion continue. The next update is due in 30 minutes.

## Recovery criteria

- Compromised credentials and active sessions are revoked or rotated.
- Confirmed and suspected assets are validated, rebuilt, or returned to service through the approved recovery path.
- No further suspicious authentication, execution, persistence, or outbound transfer is observed.
- Required evidence and incident records are preserved.
- Business owners approve return to service.
- Increased monitoring remains active for the agreed observation period.

## Post-incident improvements

1. Technology: Detect Office applications launching PowerShell and alert on scheduled-task creation from unusual parent processes.
2. Process: Require a service-account dependency owner and emergency rotation procedure in the containment playbook.
3. People: Rehearse MFA-fatigue reporting and privileged-account incident escalation with the SOC and identity teams.

## Interview story

Situation: One medium-confidence alert named a finance endpoint and privileged user.
Evidence: Splunk pivots exposed execution, lateral movement, staging, outbound transfer, persistence, and service-account use.
Decision: I raised the project-defined priority to High and recommended identity revocation, endpoint isolation, controlled server restrictions, and service-owner coordination.
Trade-off: I balanced rapid containment against evidence needs and the risk of disrupting finance and backup services.
Outcome: I produced a scoped action plan, executive update, recovery gates, and three measurable improvements while keeping all production response actions approval-controlled.

Before you check the finished file, do you expect every required section to be present with uncertainty still labeled?

Return to the top of incident_brief.md in Notepad.
Review the opening half for incident classification, the evidence timeline, labeled uncertainty, impact assessment, and scope.
Review the containment section for the six-decision matrix and executive update.
Review the closing half for recovery criteria, three prioritized improvements, and the five-part interview story.

You should see a complete brief that carries the incident from classification through recovery and improvement. Every production response action remains approval-controlled.

That closes the loop. Your brief now supports recovery decisions while showing the judgment behind them.

Secret mission

Reassess After a Late Evidence Inject

Test a late synthetic event that confirms service-account movement to another server. Preserve your original decision record while revising scope, containment ownership, recovery gates, and the executive update.

Clean Up Your Resources

Choose whether to keep Documents\IR-2026-017, pause your browser sessions, or delete the folder. There is no additional cost because this project used existing organizational access without creating production resources.

Resources you used:

A local incident workspace stored at Documents\IR-2026-017.
Three synthetic queries for Splunk: first_alert.spl, incident_evidence.spl, and late_evidence_inject.spl.
A completed incident decision record in incident_brief.md.

Your temporary Splunk results require no file cleanup. The makeresults command did not save them to disk or index them.

Keep everything running

No action is needed while you plan to revisit the simulation. Your local workspace keeps the synthetic evidence plus your revised decision record ready for another rehearsal.

Review incident_brief.md for organization-specific content.
Remove any organization-specific screenshots, tenant names, or copied tenant data from Documents\IR-2026-017.
Retain Documents\IR-2026-017 on your device for future incident rehearsals.

Pause - I'll come back to this later

Pause safely by ending the project sessions while preserving every local file. You can resume from the same incident record later.

Close the browser tab containing Splunk Search & Reporting.
Close the browser tab containing SentinelOne.
Leave Documents\IR-2026-017 in your Documents folder.

Your synthetic queries plus the updated incident brief remain available on your device.

Delete - I don't want to use this again

Permanent deletion can feel risky. This path removes only the synthetic Documents\IR-2026-017 folder from your device.

Close the browser tab containing Splunk Search & Reporting.
Close the browser tab containing SentinelOne.
Press Windows+E to open File Explorer.
Select Documents in the left sidebar.
Select the IR-2026-017 folder.
Press Shift+Delete to remove the selected folder permanently.
Complete the deletion confirmation.

You should no longer see IR-2026-017 in your Documents folder. Your Splunk and SentinelOne tenants remain unchanged because no production response action was executed.

Nice Work!

You did it! You led the IR-2026-017 simulation from one ambiguous alert to an interview-ready incident brief using Splunk Search & Reporting alongside SentinelOne Singularity Endpoint.

You've learned how to:

Defend a High-priority decision through risk-based triage. Separate confirmed facts from hypotheses as the incident evolves.
Use SPL to build a 12-event timeline from synthetic evidence. Trace privileged-account activity across identities plus assets to expose the blast radius.
Turn evidence into a role-aware containment plan without touching production. Set recovery criteria before returning assets to service. Deliver an executive update that makes ownership plus approval needs clear.
Secret Mission: Reassess the incident after confirmed svc-backup activity reaches APP-SRV-04. Preserve the earlier decision record while expanding scope plus containment ownership.

Ready to quiz yourself?