Lesson 59 — Was This Insider Activity or Account Compromise?
The evidence looked bad.
A user accessed sensitive SharePoint data.
Hundreds of files were opened.
Several were downloaded.
One was shared externally.
The account was valid.
MFA had succeeded.
Someone in the room said:
“Looks like an insider.”
Agent Foskett looked back at the timeline.
“Or somebody using the insider's account.”
Account activity is not human attribution
Test insider activity and account compromise as competing explanations using technical and business evidence.
Case briefing
Investigation objective
Compare insider activity and account compromise as competing hypotheses, identify evidence that supports or weakens each explanation, and avoid attributing suspicious account activity to a person before the evidence supports it.
Investigator's rule
An account is an identity object, not proof of the human behind the keyboard. Authentication and activity evidence must be interpreted before personal attribution.
Stage 1 — separate what you know from what you think
Start with account attribution
It is often defensible to say that activity was performed using a particular account. It may not yet be defensible to say which person controlled that account at the time.
Language protects the investigation
Prefer “activity performed using Riley's account” until identity and business evidence support a stronger attribution statement.
Stage 2 — build the activity timeline
CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "riley@contoso.com"
| project Timestamp,
AccountId,
Application,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp ascChronology comes before motive
Establish exactly what the account did and when. Motivation is difficult to infer until the underlying sequence is clear.
Look beyond the headline event
The external share may be the alert trigger, but earlier authentication, searches, file access or application activity may explain how the incident developed.
Stage 3 — test the account-compromise hypothesis
| Evidence area | Questions |
|---|---|
| Authentication | Was the sign-in context normal for the user? |
| IP / location | Was the source known, expected, proxied or unusual? |
| Device / client | Was the device or user agent familiar? |
| MFA | Was MFA genuinely expected, or could an attacker have obtained an authenticated session? |
| Session | Did activity continue through an existing or unusual session? |
| Applications | Was OAuth or other application access involved? |
| Other identities | Did the same infrastructure touch additional accounts? |
MFA success does not prove the user acted
MFA is strong security evidence, but a successful MFA result does not by itself establish who performed every subsequent action in a session.
Look for attacker infrastructure
If the same IP, application or other infrastructure appears across multiple unrelated accounts, the compromise hypothesis may strengthen substantially.
Stage 4 — test the insider-activity hypothesis
Authorisation is not justification
A user may technically have permission to access a file without having a current business reason to collect or share it. Access rights and business need are different questions.
Business context becomes evidence
Role, project responsibilities, approved collaboration and data-owner confirmation can explain unusual technical activity that would otherwise appear suspicious.
Stage 5 — compare behaviour with the user's baseline
CloudAppEvents
| where Timestamp > ago(30d)
| where AccountId =~ "riley@contoso.com"
| summarize
Events = count(),
Actions = make_set(ActionType, 100),
IPs = make_set(IPAddress, 50),
Applications = make_set(Application, 50)
by bin(Timestamp, 1d)
| order by Timestamp ascCompare the user with themselves first
Thirty days of history may show whether high-volume SharePoint access, external sharing or the observed infrastructure is normal for this account.
Anomaly is not intent
A major deviation from baseline increases investigative interest. It still does not tell you whether the cause is legitimate work, insider activity or account compromise.
Stage 6 — look for evidence that discriminates
Seek discriminating evidence
The best next question is often not “what else is suspicious?” but “what evidence would make one explanation more likely than the other?”
User confirmation is useful, not magical
A user's statement can provide important context, but it should be correlated with technical and business evidence rather than treated as the sole basis for the verdict.
Stage 7 — scope the data activity
CloudAppEvents
| where Timestamp between
(datetime(2026-09-03 09:00:00) ..
datetime(2026-09-03 10:00:00))
| where AccountId =~ "riley@contoso.com"
| summarize
Events = count(),
Actions = make_set(ActionType, 100),
IPs = make_set(IPAddress, 50)
by Application
| order by Events descImpact can be established before attribution
You may be able to prove that sensitive data was accessed, downloaded or shared even while the identity of the human actor remains unresolved.
Protect the data while attribution continues
If confirmed activity creates unacceptable exposure, containment and data-protection actions should follow approved procedures without waiting for perfect certainty about motive.
Stage 8 — build an evidence matrix
| Observation | Insider | Compromise |
|---|---|---|
| Expected corporate device | Supports | Does not exclude |
| Known corporate IP | Supports | Does not exclude |
| New foreign infrastructure | Weakens | Supports |
| Same IP touches other accounts | Weakens | Strongly supports |
| User denies activity | Weakens | Supports, but verify |
| No legitimate business purpose | Supports concern | Also compatible |
| Suspicious OAuth activity | Weakens | Supports |
| Unusual data collection | Compatible | Compatible |
Some evidence supports both explanations
Bulk downloads and sensitive-file access can occur in both insider and compromised-account scenarios. Focus on evidence that differentiates the hypotheses.
Avoid confirmation bias
Once an investigation is labelled “insider” or “compromise,” analysts can unconsciously interpret every new event through that label. Keep both hypotheses alive until the evidence separates them.
Stage 9 — know when to involve other teams
Stay inside the SOC's role
The SOC can establish technical facts and security risk. Decisions involving employee intent, disciplinary matters or legal conclusions require the appropriate organisational process.
Neutrality is operationally useful
Evidence-focused reporting lets security, management, legal, HR and data owners make decisions without having to undo unsupported technical assumptions.
Stage 10 — write the finding at the right confidence level
Lesson 59 key takeaways
- Activity can be attributed to an account before it can be attributed to a person.
- A valid account and successful MFA do not automatically prove the legitimate user performed every action.
- Separate confirmed technical facts from interpretations about motive.
- Test insider activity and account compromise as competing hypotheses.
- Use identity, session, device, infrastructure and application evidence.
- Compare the user's activity with their own historical baseline.
- Anomalous behaviour does not establish malicious intent.
- Business context is essential when evaluating authorised access.
- Look for evidence that discriminates between hypotheses rather than evidence that merely looks suspicious.
- Some observations, such as bulk downloads, are compatible with both insider and compromise scenarios.
- Avoid confirmation bias by keeping plausible hypotheses open.
- The SOC should report evidence and security risk without inventing motive or employment conclusions.
Module 6 — Cloud & SaaS Incidents
Lesson 59 separated account activity from human attribution. Lesson 60 brings the entire module together by building a defensible cloud-compromise timeline across identity, applications and Microsoft 365 services.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 6: Cloud & SaaS Incidents
Investigate insider activity versus account compromise in Microsoft 365
Lesson 59 of the Agent Foskett SOC Analyst Academy teaches analysts how to compare insider activity and compromised-account hypotheses using identity, session, device, cloud, behavioural and business evidence.
Use Microsoft Defender XDR and KQL for evidence-based attribution
Learn how to distinguish activity performed with an account from attribution to a human, avoid confirmation bias, compare user baselines and document suspicious Microsoft 365 data access at the appropriate confidence level.
