Lesson 51 — The User Downloaded Gigabytes Before Leaving
The alert looked uncomfortable.
A user had downloaded several gigabytes of files from Microsoft 365.
The timing made it worse.
Their employment was ending on Friday.
It would be easy to write the conclusion immediately:
“Departing employee exfiltrated company data.”
Agent Foskett looked at the evidence and asked a different question:
“Unusual compared with what?”
Large does not automatically mean malicious
Measure the activity, compare it with the user's baseline, identify the data involved and add business context before deciding what happened.
Case briefing
Investigation objective
Determine whether a departing user's large cloud download represents legitimate business activity, unusual but explainable behaviour, policy concern or possible data exfiltration.
Investigator's rule
Never let the employment context become the verdict. A departing user deserves investigation based on evidence, not an assumption of malicious intent.
Stage 1 — define exactly what was unusual
| Question | Why it matters |
|---|---|
| How many files? | Distinguishes isolated access from bulk activity. |
| How much data? | Provides scale, but not intent by itself. |
| Which workloads? | Shows whether activity involved OneDrive, SharePoint or other cloud services. |
| Which repositories? | Helps determine whether the user accessed expected project locations. |
| What file types? | Can distinguish normal working sets from archives, exports or sensitive documents. |
| When did it happen? | Allows comparison with working hours, resignation timing and other events. |
Start with measurement
“Gigabytes” sounds dramatic, but the SOC needs a precise picture. A synchronisation client, project archive or media repository can legitimately move large volumes of data.
Do not confuse volume with intent
The download is an observable fact. Data theft is a conclusion that requires additional evidence.
Stage 2 — inspect the user's cloud activity
CloudAppEvents
| where Timestamp > ago(7d)
| where AccountId =~ "jordan@contoso.com"
| where ActionType has "Download"
| project Timestamp,
AccountId,
Application,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp asc
Preserve RawEventData
Cloud audit records can contain workload-specific details that are useful during deeper investigation. Keep the raw event available while you identify the exact files, locations and activity represented.
Look for concentration
Was the activity spread across the user's normal working day, or did hundreds of operations occur in a short burst immediately before departure?
Stage 3 — establish the user's baseline
CloudAppEvents
| where Timestamp between (ago(30d) .. ago(1d))
| where AccountId =~ "jordan@contoso.com"
| where ActionType has "Download"
| summarize DownloadEvents = count()
by bin(Timestamp, 1d), Application
| order by Timestamp asc
The baseline changes the meaning
If the user normally performs large downloads as part of design, engineering, backup or project work, today's activity may be less anomalous than the alert suggests.
But normal volume is not automatic clearance
A familiar quantity of data can still be suspicious if the repositories, file types, destination or timing are different from the user's established pattern.
Stage 4 — compare current activity with normal behaviour
Behavioural comparison is stronger than a threshold
A fixed threshold may generate an alert. The investigation asks whether the activity differs meaningfully from the user's own history and role.
Look for new repositories
Access to locations the user has never previously touched can be more significant than the raw number of downloaded files.
Stage 5 — identify what data was accessed
| Observed data | Investigative significance |
|---|---|
| User's normal project folder | Potentially expected, depending on role and current work. |
| Project handover documents | May support a legitimate departure process. |
| Customer lists | May increase business and privacy concern. |
| Finance documents | Requires role and permission context. |
| Executive or board material | Potentially high sensitivity if outside normal duties. |
| Large archives or exports | May indicate deliberate collection and staging. |
Access rights are not the same as business need
A user may technically have permission to open a library while rarely having a legitimate reason to download its contents. Investigate both entitlement and expected use.
Data sensitivity changes severity
Ten highly sensitive documents can matter more than several gigabytes of ordinary project material. Measure impact as well as volume.
Stage 6 — add identity and session context
Do not skip account compromise
The HR context can bias the investigation toward insider activity. Verify that the cloud activity aligns with the user's known sessions and devices before attributing it to the employee.
Attribution needs evidence
An account name in a cloud log tells you which identity performed the action. It does not automatically tell you which human controlled that identity at the time.
Stage 7 — add the business context
Ask the right people
HR can confirm employment timing. The manager can explain project handover. Data owners can explain whether the accessed repositories were appropriate. The SOC supplies technical evidence; business stakeholders supply context.
Context can increase or reduce concern
An approved handover may explain the activity. A manager saying, “Jordan had no reason to access Finance,” may make the same technical evidence considerably more concerning.
Stage 8 — test competing hypotheses
| Hypothesis | Evidence that may support it |
|---|---|
| Normal work | Known repositories, normal device, expected hours, similar historical volume. |
| Approved handover | Manager confirmation, handover task, project-related data, expected timing. |
| Automated sync or migration | Consistent client behaviour, known device, IT change or migration evidence. |
| Account compromise | Unfamiliar sign-in, new location/device, suspicious session or related identity evidence. |
| Potential insider data collection | Unusual repositories, sensitive data, abnormal timing, bulk collection and no business justification. |
Do not choose the most dramatic hypothesis
Choose the explanation best supported by the complete evidence. If two explanations remain plausible, document both and identify what evidence would distinguish them.
A hypothesis is not an accusation
Especially in insider-risk scenarios, use neutral language. The SOC's job is to document observable activity and risk, not infer motive without evidence.
Stage 9 — build the decision matrix
Escalation may be appropriate before certainty
If sensitive data is involved and the activity cannot be explained, the SOC may need to escalate according to organisational procedures even while attribution or intent remains unresolved.
Preserve evidence before remediation
Where organisational procedures allow, retain relevant timestamps, identities, file details, session information and business context so later reviewers can understand the basis of the decision.
Stage 10 — write a defensible SOC finding
Lesson 51 key takeaways
- Large download volume is a signal, not a verdict.
- Measure exactly what happened before interpreting it.
- Compare current activity with the user's own historical baseline.
- Repository choice and data sensitivity may matter more than total gigabytes.
- Permission to access data does not automatically establish business need.
- Verify identity, session, IP and device context before attributing activity to a person.
- Departing-user context can create investigative bias.
- Use HR, managers and data owners to add legitimate business context.
- Test normal work, handover, automation, account compromise and insider-risk hypotheses.
- Use neutral language and avoid inferring motive without evidence.
- Escalate based on risk and evidence, even when intent remains unresolved.
- A defensible finding explains both what is known and what still needs review.
Module 6 — Cloud & SaaS Incidents
Lesson 51 introduced cloud data-access investigation using behavioural and business context. Lesson 52 introduces another cloud trap: the same account accessing SharePoint from two different countries.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 6: Cloud & SaaS Incidents
Investigate unusual Microsoft 365 cloud downloads with Microsoft Defender XDR
Lesson 51 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate unusual cloud data access by measuring download activity, comparing user baselines, reviewing data sensitivity and adding business context.
Investigate departing-user cloud activity with KQL
Use CloudAppEvents and Microsoft security telemetry to review cloud download behaviour while considering legitimate handover activity, automated synchronisation, account compromise and possible insider-risk scenarios without assuming intent.
