Lesson 98 — The Insider-Threat Hypothesis Was Wrong
The employee downloaded sensitive files.
It looked deliberate.
Then the sign-in evidence arrived.
The theory stopped fitting.
The first explanation is not the final verdict.
Test competing hypotheses against identity, endpoint and cloud evidence.
Case briefing
Investigation objective
Test an insider-threat hypothesis against the available evidence, recognise contradictory findings and revise the investigation when external account compromise becomes the stronger explanation.
Investigator's rule
A hypothesis is something you test — not something you defend.
Stage 1 — understand why insider threat was suspected
| Observation | Initial interpretation |
|---|---|
| Sensitive files accessed | User may be collecting information |
| Bulk downloads | Possible deliberate removal |
| External sharing | Possible unauthorised disclosure |
| Actions performed as employee | Possible insider activity |
The theory was reasonable
Early evidence can support an insider hypothesis. The mistake is not forming the hypothesis — it is refusing to change it when better evidence appears.
User context is not identity proof
An action attributed to an account does not automatically prove that the legitimate account owner performed it.
Stage 2 — test the identity
let User = "alex@contoso.com";
EntraIdSignInEvents
| where Timestamp > ago(6h)
| where AccountUpn =~ User
| project Timestamp,
AccountUpn,
IPAddress,
Country,
Application,
ErrorCode
| order by Timestamp ascAsk who controlled the session
Review sign-in location, source infrastructure, applications, timing and authentication context before attributing cloud actions to the employee.
Attribution requires more than a username
The account identifies the security principal used for the action. It does not by itself identify the human operating the session.
Stage 3 — the contradiction appears
Contradictions are valuable
Evidence that does not fit the current theory is not inconvenient noise. It may be the clue that prevents a false conclusion.
Ask what would need to be true
If this were deliberate insider activity, would the employee normally need an unfamiliar external session to perform it?
Stage 4 — compare competing hypotheses
| Evidence | Insider misuse | Account compromise |
|---|---|---|
| Bulk download | Supports | Supports |
| External sharing | Supports | Supports |
| Unfamiliar sign-in | Weakens | Supports |
| Different session context | Weakens | Supports |
| No matching endpoint activity | Weakens | Supports cloud-session theory |
One fact can support two theories
Bulk downloads are not uniquely malicious-insider behaviour. They can also occur when an external attacker controls a legitimate account.
Prefer the theory that explains more evidence
The stronger hypothesis is the one that accounts for the complete evidence set with fewer unsupported assumptions.
Stage 5 — correlate cloud activity with the suspicious session
let User = "alex@contoso.com";
CloudAppEvents
| where Timestamp > ago(6h)
| where AccountId =~ User
| project Timestamp,
AccountId,
IPAddress,
Application,
ActionType,
ObjectName
| order by Timestamp ascMatch time and source
If the suspicious cloud actions align with the unfamiliar session rather than the employee's known activity, the compromise hypothesis becomes stronger.
Follow the session, not the assumption
Build the sequence from authentication through mailbox, SharePoint, OneDrive or other cloud actions.
Stage 6 — check the endpoint
let User = "alex@contoso.com";
DeviceProcessEvents
| where Timestamp > ago(6h)
| where AccountUpn =~ User
| project Timestamp,
DeviceName,
AccountUpn,
FileName,
ProcessCommandLine
| order by Timestamp ascNegative evidence can matter
If the employee's managed device shows no corresponding download or sharing workflow, that absence may weaken the insider theory when combined with stronger cloud evidence.
Do not overstate absence
Missing endpoint evidence does not prove the employee was uninvolved. Telemetry coverage and alternative devices must still be considered.
Stage 7 — revise the hypothesis
Changing direction is good investigation
Revising a hypothesis is not failure. It demonstrates that conclusions are being controlled by evidence rather than ego or expectation.
The questions change too
Once compromise becomes the leading theory, pivot toward initial access, session activity, persistence, data exposure and related identities.
Stage 8 — avoid the human consequence of a bad theory
Insider labels carry weight
Analysts should use careful language and avoid attributing intent to an employee before the evidence supports that conclusion.
Security conclusions affect people
A technically careless attribution can create serious operational and human consequences while also allowing the real attacker to remain active.
Stage 9 — incident finding
Document the change
Record why the original hypothesis was reasonable, what evidence contradicted it and why the revised assessment now better fits the facts.
Leave room for uncertainty
If evidence remains incomplete, state the confidence level rather than converting a strong hypothesis into an unsupported certainty.
Decision point
Good analysts can be wrong early
The skill is recognising when the evidence has changed enough to demand a new explanation.
Next comes communication
Lesson 99 shifts from investigation to handover: another analyst must be able to understand the unfinished incident and continue without losing context.
Lesson 98 key takeaways
- Form hypotheses early, but treat them as testable explanations.
- An action performed by an account does not prove who controlled the session.
- Test identity context before attributing behaviour to a user.
- Contradictory evidence can be more valuable than confirming evidence.
- Compare competing hypotheses against the same evidence set.
- Prefer the explanation that accounts for more evidence with fewer assumptions.
- Correlate cloud activity with authentication time and source context.
- Use negative endpoint findings carefully and account for telemetry limitations.
- Revise the investigation when the original theory no longer fits.
- Avoid attributing malicious intent without sufficient evidence.
- Document why the hypothesis changed.
- Follow the evidence, not the theory.
Module 10 — Complete SOC Investigation Scenarios
Lesson 98 tested investigative discipline by overturning an insider-threat hypothesis when the evidence supported external account compromise instead. Lesson 99 focuses on preserving that reasoning in a complete handover for the next analyst.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 10: Complete SOC Investigation Scenarios
How should a SOC analyst test an insider-threat hypothesis?
Lesson 98 of the Agent Foskett SOC Analyst Academy demonstrates how identity, cloud and endpoint evidence can overturn an initial insider-threat theory and point instead to external account compromise.
Changing an investigation hypothesis when evidence disagrees
Learn how to compare competing hypotheses, identify contradictory evidence, avoid premature attribution, revise an assessment and document why the investigation changed direction.
