Lesson 4 — The User Said “I Didn’t Do That”
The alert involves a real user. You contact them and ask about the activity.
Their answer is immediate: “I didn’t do that.”
That statement matters. But it is not a verdict. Users forget things, misunderstand questions,
work through remote sessions, use shared devices and sometimes describe what they remember rather
than what the telemetry recorded. The analyst has to respect the statement while still testing it
against the evidence.
The user's statement
A successful sign-in and suspicious process activity are associated with a user account. The user denies performing the activity. Your task is to test the statement without assuming either the user or the detection is automatically correct.
Case briefing
Investigation objective
Learn how to record and use a user statement without treating it as proof. Validate the account, device, sign-in and process evidence before deciding whether the activity represents compromise, legitimate work or an unresolved inconsistency.
Investigator's rule
Do not argue with the user and do not blindly trust the user. Record the statement accurately, then test it against telemetry. The purpose is not to prove somebody wrong. It is to explain what happened.
Stage 1 — record exactly what the user said
User conversations are part of the evidence trail. Write down the important facts without paraphrasing them into stronger claims than the user actually made.
| User statement | What it supports | What it does not prove |
|---|---|---|
| “I didn’t do that.” | The user does not recognise the activity. | That the account was compromised. |
| “I haven’t used PowerShell today.” | The user denies intentionally launching PowerShell. | That PowerShell did not run in their session. |
| “I was working from home.” | Provides location and work-context information to validate. | The exact source IP, device or session used. |
Ask neutral questions
“Did you run PowerShell?” is useful. “Did you click the malicious link that compromised your account?” is not. The second question embeds a conclusion before the evidence supports it.
Memory has limits
Users may not recognise background processes, scripts launched by software, remote sessions or activity performed earlier in the day. A sincere denial can still be incomplete.
Stage 2 — validate the sign-in with KQL
This is where KQL belongs in the SOC Academy. The lesson is not about learning the query language itself; KQL is simply the fastest way to test the user's statement against Microsoft Entra telemetry.
let TargetUser = "emily.h@contoso.com";
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
UserPrincipalName,
IPAddress,
Location,
AppDisplayName,
ClientAppUsed,
DeviceDetail,
AuthenticationRequirement,
ConditionalAccessStatus,
ResultType
| order by TimeGenerated asc
Compare with the user's context
If the user says they were working from home, compare the source IP, location, device details and sign-in history with known home-working patterns. Do not treat geography alone as proof.
Successful authentication matters
A successful sign-in tells you that authentication requirements were satisfied. It does not prove who physically controlled the session. That distinction becomes important when the user denies the activity.
Stage 3 — validate the endpoint activity
Now test the second part of the user's statement: “I haven’t used PowerShell today.” Use endpoint telemetry to identify exactly how PowerShell started and which account context was associated with the process.
let TargetDevice = "SALES-LT-018";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where FileName =~ "powershell.exe"
| project Timestamp,
DeviceName,
AccountName,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
ProcessCommandLine,
SHA1
| order by Timestamp asc
The parent process can change the story
If powershell.exe was launched by an approved management agent, the user's denial may be completely consistent with legitimate background activity. If it was launched by a browser or unusual executable, the denial becomes more concerning.
Account context is not human attribution
A process running under the user's account shows the security context in which it executed. It still does not prove that the user consciously started it.
Stage 4 — compare competing explanations
| Explanation | Evidence that would support it | Evidence that would weaken it |
|---|---|---|
| Legitimate user activity | Known device, familiar location, recognised process chain, expected command. | User denial plus unknown source and abnormal process ancestry. |
| Legitimate background software | Approved parent process, signed software, known management task. | Browser or unknown executable launching PowerShell. |
| Account compromise | Unfamiliar sign-in, new device/session, suspicious follow-on activity. | Strong evidence of expected authentication and approved activity. |
| User memory mismatch | Telemetry shows normal activity the user reasonably may not remember. | Multiple independent compromise indicators. |
Do not choose a theory too early
The user's denial makes compromise more plausible, but it does not eliminate legitimate software, delegated access, remote sessions or memory error. Keep multiple explanations alive until the evidence separates them.
Look for independent corroboration
A suspicious sign-in plus browser-launched PowerShell plus an external network connection provides much stronger support for compromise than a user denial alone.
Stage 5 — update the investigation with both sources
Your evidence board
| Evidence | What it supports | Weight |
|---|---|---|
| User denies performing the activity | Creates a credible need to test for unauthorised activity. | Supporting evidence |
| Successful sign-in from an unfamiliar source | May support unauthorised account access. | Moderate to strong with context |
| PowerShell launched by a browser | Supports suspicious endpoint execution. | Strong when unexpected |
| PowerShell launched by approved management software | May explain why the user does not recognise the activity. | Strong benign context when validated |
| User statement alone | Shows what the user recalls. | Insufficient for final disposition |
Write the finding like an analyst
Example: The user stated that they did not recognise the successful sign-in or intentionally execute PowerShell on SALES-LT-018. The statement was recorded as supporting evidence and validated against Microsoft Entra sign-in and Defender for Endpoint telemetry. Investigation reviewed source IP, location, authentication context, device details, PowerShell process ancestry and command-line activity. The user's denial increases concern but does not independently establish compromise. Final disposition should be based on whether the technical evidence supports legitimate background activity, normal user behaviour or unauthorised access and execution.
Lesson 4 key takeaways
- A user statement is evidence, not a final disposition.
- Record what the user actually said without strengthening the wording.
- Ask neutral questions that do not embed your working theory.
- User memory and technical telemetry can legitimately differ.
- Use Entra sign-in telemetry to validate location, IP, device and authentication context.
- Use endpoint telemetry to determine how suspicious processes actually started.
- Process account context does not prove human attribution.
- Keep legitimate and malicious explanations alive until evidence separates them.
- KQL is a SOC investigation tool — not the purpose of the lesson.
- Write conclusions from the combined human and technical evidence.
Module 1 — inside the SOC
The user's statement has become part of the investigation, but the next challenge is deciding what evidence should be collected before the analyst starts forming a stronger conclusion.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 1: Inside the SOC: Thinking Like an Analyst
How SOC analysts validate user statements
Lesson 4 of the Agent Foskett SOC Analyst Academy teaches analysts how to record user statements and compare them with Microsoft Entra sign-in and Defender for Endpoint evidence.
Use KQL to validate identity and endpoint activity
Learn how SOC analysts use KQL to review sign-in context, device activity, PowerShell process ancestry and supporting telemetry without treating either the user statement or security alert as automatically correct.
