Agent Foskett Academy • SOC Analyst Academy • Module 4 • Lesson 37 • Endpoint Incidents: Following the Attack Chain

Lesson 37 — LSASS Was Accessed by an Unexpected Process

The endpoint was already suspicious.

PowerShell had launched. A file appeared and executed. The process contacted an external IP and created persistence.

Then another event raised the stakes:

an unexpected process accessed LSASS.

LSASS is involved in Windows authentication and can contain valuable credential material. Legitimate security and system processes may interact with it, but unexpected access during an active attack chain demands careful investigation.

Access to LSASS is not automatically credential theft — but in the wrong process chain it can be one of the most important clues in the incident.

Investigate the LSASS Access Back to SOC Analyst Academy

Agent Foskett investigating unexpected LSASS access in Microsoft Defender XDR

Credential access changed the risk

The analyst must identify the accessing process, establish why it touched LSASS, connect it to the existing execution chain and look for signs of credential use afterwards.

✓ Identify the accessing process

✓ Reconstruct process ancestry

✓ Validate legitimate security tooling

✓ Look for follow-on credential use

Case briefing

10:14:45 update-check.exe executes ↓ 10:14:53 external connection begins ↓ 10:15:19 persistence created ↓ 10:16:02 LSASS ACCESS OBSERVED PROCESS update-check.exe TARGET lsass.exe USER alex.wilson THE QUESTION Is this legitimate process interaction? OR Has the attack chain moved into credential access?

Investigation objective

Determine whether the LSASS access is expected, identify the process and ancestry involved, validate security or administrative explanations and assess whether credential-access behaviour may have enabled later movement.

Investigator's rule

Credential-access indicators need context. The same LSASS interaction can be legitimate in one environment and highly suspicious in another.

Stage 1 — understand why LSASS matters

Question	Why it matters
Which process accessed LSASS?	Identifies the actor inside the endpoint timeline.
Is the process expected to interact with LSASS?	Security tools and operating-system components may have legitimate reasons.
What launched the process?	Process ancestry may connect the access to the earlier attack chain.
What happened immediately afterwards?	New logons or movement can strengthen the credential-access hypothesis.
Is the behaviour common in the environment?	Prevalence helps distinguish baseline activity from anomaly.

LSASS is not inherently suspicious

Windows and security software interact with LSASS legitimately. The investigation must identify why this specific process accessed it.

The existing chain matters

An unknown process touching LSASS after suspicious execution, external communication and persistence deserves far more scrutiny than the same event in isolation.

Stage 2 — identify suspicious LSASS-related process activity

12345 6789101112 131415

let TargetDevice = "WS-FIN-044";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where FileName =~ "update-check.exe"
   or ProcessCommandLine has "lsass"
| project Timestamp,
          AccountName,
          FileName,
          FolderPath,
          SHA1,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Start with the known suspicious process

The earlier lessons already established update-check.exe as part of the attack chain. Use that knowledge to reduce noise and focus the investigation.

Command-line evidence may be indirect

Not every LSASS-access event exposes intent directly in the process command line. Use the telemetry that is available and avoid inventing details that are not present.

Stage 3 — look for Defender endpoint events around the access

12345 6789101112 13

let StartTime = datetime(2026-08-25 10:15:30);
let EndTime   = datetime(2026-08-25 10:17:00);
DeviceEvents
| where DeviceName =~ "WS-FIN-044"
| where Timestamp between (StartTime .. EndTime)
| project Timestamp,
          ActionType,
          AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          AdditionalFields
| order by Timestamp asc

Read the event detail, not just the action name

Relevant Defender events can vary by detection and platform context. Preserve ActionType and AdditionalFields so the investigation remains grounded in actual telemetry.

Correlate the initiating process

If the same executable associated with file creation, network activity and persistence also appears in the LSASS-related event, the attack chain becomes substantially stronger.

Stage 4 — reconstruct the attack sequence

BROWSER ↓ POWERSHELL ↓ ENCODED COMMAND ↓ SUSPICIOUS FILE ↓ PROCESS EXECUTION ↓ EXTERNAL CONNECTION ↓ PERSISTENCE ↓ LSASS ACCESS ↓ WHAT HAPPENS TO THE CREDENTIALS?

The hypothesis has changed

Earlier lessons asked whether the endpoint was compromised. At this point the SOC must also consider whether credentials may now be exposed.

Credential access can expand scope

If valid credentials were obtained, the incident may no longer be limited to one endpoint. Identity and lateral-movement hunting become necessary.

Stage 5 — check whether the process is normal in the environment

12345 67891011

let TargetHash = "9D0B...E41C";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where SHA1 == TargetHash
| summarize
    Executions=count(),
    Devices=dcount(DeviceName),
    FirstSeen=min(Timestamp),
    LastSeen=max(Timestamp)
    by SHA1, FileName

Low prevalence adds weight

A process seen only on the compromised device deserves more scrutiny, especially when it already sits inside a suspicious attack timeline.

High prevalence can still be suspicious

Trusted or common binaries can be abused. Prevalence helps with context but does not replace process ancestry and behaviour.

Stage 6 — test legitimate explanations

Possible explanation	What to validate
Endpoint security software	Vendor process, signed binary, expected deployment and documented LSASS interaction.
Administrative troubleshooting	Known administrator, approved tool, change record and expected timing.
System component	Expected Windows path, signature and normal parent process.
Credential-access behaviour	Suspicious ancestry, low prevalence, attack-chain timing and unexplained LSASS interaction.

Digital signatures are useful context

A valid signature can support a legitimate explanation, but signed software can still be abused. Treat signature status as one part of the evidence.

Ask the endpoint team

Security tooling can generate low-level process access that looks unusual. Validate known EDR, antivirus and credential-management software before escalating solely on LSASS access.

Stage 7 — look for follow-on logon activity

12345 678910111213

let TargetAccount = "alex.wilson";
DeviceLogonEvents
| where Timestamp > ago(24h)
| where AccountName =~ TargetAccount
| project Timestamp,
          DeviceName,
          LogonType,
          ActionType,
          AccountDomain,
          AccountName,
          RemoteIP,
          RemoteDeviceName
| order by Timestamp asc

Do not assume credentials were successfully extracted

Unexpected LSASS access raises the hypothesis. Follow-on authentication evidence is needed before claiming stolen credentials were used.

Look for the next device

If the same account appears on another endpoint shortly afterwards, that new device becomes a high-priority pivot for possible lateral movement.

Stage 8 — make the SOC decision

UNEXPECTED LSASS ACCESS ↓ IDENTIFY PROCESS ↓ RECONSTRUCT ANCESTRY ↓ COMPARE WITH BASELINE ↓ VALIDATE SECURITY / ADMIN TOOLS ↓ CORRELATE WITH ATTACK CHAIN ↓ CHECK FOLLOW-ON LOGONS ↓ ASSESS CREDENTIAL RISK ↓ ESCALATE / CONTAIN / EXPAND SCOPE

The LSASS event matters because it appears after execution, network activity and persistence — and before potential movement to another device.

Write the investigation finding

ENDPOINT INVESTIGATION FINDING At 10:16:02, endpoint telemetry recorded unexpected LSASS-related activity associated with update-check.exe on WS-FIN-044. The same executable had already been linked to: - suspicious PowerShell execution - rapid file creation and launch - outbound network activity - persistence creation No validated endpoint-security or administrative explanation was identified for the LSASS access. DECISION Escalate the incident as possible credential access and expand hunting to account activity and other endpoints. REASON The LSASS interaction occurs inside an existing evidence-backed compromise chain and increases the risk that credentials may have been exposed.

Lesson 37 key takeaways

LSASS access requires context; it is not automatically credential theft.
Identify the process associated with the LSASS interaction.
Reconstruct process ancestry before drawing conclusions.
Validate endpoint-security and administrative explanations.
Correlate the LSASS event with the existing attack timeline.
Use process prevalence and signature context as supporting evidence.
Do not claim credential extraction without evidence.
Follow the affected account into DeviceLogonEvents.
Expand scope if the account appears on another device.
Treat credential-access evidence as a possible bridge from endpoint compromise to lateral movement.

Module 4 — Endpoint Incidents: Following the Attack Chain

Lesson 37 moves the investigation into possible credential access. Next, Agent Foskett follows the affected account when it logs on to another device only minutes later.

Next: Lesson 38 — The Account Logged On to Another Device Minutes Later

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 4: Endpoint Incidents: Following the Attack Chain

Follow endpoint evidence across execution, persistence, credential access, movement and containment.

← Previous lesson

Lesson 36 — The Suspicious Process Created Persistence Investigate scheduled tasks, registry changes and persistence.

✅ Current lesson

Lesson 37 — LSASS Was Accessed by an Unexpected Process Recognise credential-access behaviour.

Next lesson →

Lesson 38 — The Account Logged On to Another Device Minutes Later Follow possible lateral movement.

How to investigate unexpected LSASS access in Microsoft Defender XDR

Lesson 37 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate unexpected LSASS access, correlate process ancestry and endpoint events, validate legitimate tooling and assess possible credential-access behaviour.

KQL credential access investigation for SOC analysts

Learn how to use DeviceProcessEvents, DeviceEvents and DeviceLogonEvents to connect suspicious endpoint activity with possible credential access and follow-on lateral movement.