Lesson 53 — Hundreds of Files Were Downloaded in Minutes
The cloud alert reported a burst of activity.
Not ten files.
Not fifty.
Hundreds of files had been downloaded in only a few minutes.
The obvious question was whether somebody was stealing data.
But Agent Foskett had seen synchronisation tools, migration jobs and legitimate bulk work create very similar telemetry.
So before calling it exfiltration, he asked:
“Is the volume unusual — or is the speed, source, data and behaviour unusual?”
Count. Time. Compare. Correlate.
Measure the burst, establish what is normal for the user, inspect the data and determine what mechanism generated the activity.
Case briefing
Investigation objective
Measure a rapid cloud-download burst, compare it with historical behaviour and determine whether the activity is consistent with normal work, synchronisation, automation or possible data exfiltration.
Investigator's rule
Do not investigate “hundreds of files” as one vague event. Break the burst into time, account, application, IP, user agent, repository and data context.
Stage 1 — quantify the burst
CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "sam@contoso.com"
| where ActionType has "Download"
| summarize DownloadEvents = count()
by bin(Timestamp, 1m), Application
| order by Timestamp asc
Rate matters
Four hundred downloads across an entire week and four hundred downloads in seven minutes describe very different behaviours. Measure the concentration of activity.
Find the beginning and end
Establish when the burst started, when it peaked and when it stopped. Those timestamps become anchors for identity, endpoint, application and business investigation.
Stage 2 — visualise the shape of the activity
Patterns can suggest mechanism
Regular, high-frequency operations may indicate a client or automated process. Irregular manual activity may look different. Treat the pattern as evidence to test, not proof of a particular tool.
Do not infer bytes from event count
Hundreds of download events do not tell you the total data volume by themselves. File sizes and workload-specific details must be established from available telemetry or supporting records.
Stage 3 — inspect the surrounding cloud events
CloudAppEvents
| where Timestamp between
(datetime(2026-09-02 15:30:00) ..
datetime(2026-09-02 16:00:00))
| where AccountId =~ "sam@contoso.com"
| project Timestamp,
Application,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp asc
Look beyond download actions
Activity immediately before the burst may reveal browsing, search, sharing changes or other actions. Activity afterwards may show continued access, deletion, external sharing or an abrupt end to the session.
Preserve workload detail
Keep RawEventData available for deeper inspection because file names, object information and other workload-specific properties can be important to the investigation.
Stage 4 — establish the user's baseline
CloudAppEvents
| where Timestamp between (ago(30d) .. ago(1d))
| where AccountId =~ "sam@contoso.com"
| where ActionType has "Download"
| summarize DownloadEvents = count()
by bin(Timestamp, 1h), Application
| summarize
TypicalHourlyEvents = avg(DownloadEvents),
PeakHourlyEvents = max(DownloadEvents)
by Application
Compare the user with themselves first
A developer, media producer or data analyst may naturally move more files than another employee. Personal baseline often provides better context than an organisation-wide average.
Then compare peers if useful
If role information is available through approved processes, peer behaviour can add context. But do not treat a peer average as proof that an individual user's activity is legitimate or malicious.
Stage 5 — identify the repositories involved
Scope can matter more than count
A burst limited to one expected project library may be easier to explain than a burst spanning unrelated sensitive repositories.
Ask whether access was expected
The account may possess permission to a repository without having a current business reason to bulk-download its contents.
Stage 6 — identify the mechanism
| Possible mechanism | Evidence to investigate |
|---|---|
| OneDrive synchronisation | Known device, expected client/user-agent pattern, repeatable sync behaviour and expected folders. |
| Migration or backup | Approved IT activity, service/application context and known change window. |
| Manual bulk download | Interactive browser activity, selected repositories and user-driven sequence. |
| Script or automation | Highly regular operations, application context and non-standard user-agent behaviour. |
| Potential exfiltration | Unusual data scope, abnormal session, sensitive content and no legitimate explanation. |
Mechanism is not motive
Even if a script performed the downloads, the SOC still needs to determine whether it was an approved business tool, malicious automation or something else.
Known tools can still be abused
A legitimate synchronisation client or browser can be used during unauthorised collection. Do not clear activity solely because the software itself is trusted.
Stage 7 — correlate identity and session evidence
A new session before the burst matters
An unfamiliar sign-in immediately followed by rapid bulk downloads creates a very different case from an established managed-device session performing expected synchronisation.
Follow the identity across services
If the same suspicious session or IP appears in Exchange, SharePoint, OneDrive or other cloud workloads, the investigation may be broader than a file-download alert.
Stage 8 — compare normal and suspicious patterns
| More explainable pattern | More concerning pattern |
|---|---|
| Known managed device | New or unexplained device/session |
| Known network path | New or rare IP infrastructure |
| Expected project repositories | New sensitive repositories |
| Historical sync behaviour | No similar historical activity |
| Approved change or migration | No documented business reason |
| Normal working context | Unusual timing or employment context |
No single column decides the case
One suspicious characteristic may be explainable. Several independent anomalies occurring together increase confidence that the event deserves escalation.
Be careful with “normal”
Historical repetition does not automatically make behaviour safe. An attacker may reuse an established session, and an insider may use familiar devices and networks.
Stage 9 — build an evidence-weighted timeline
Sequence changes meaning
Bulk download followed by external sharing may deserve more concern than download activity alone. Build the surrounding timeline before deciding what the burst represents.
Search for what happened next
Do not stop when the downloads stop. Review subsequent sharing, mailbox, identity and cloud activity that could establish impact or attacker objectives.
Stage 10 — test competing hypotheses
| Hypothesis | What would strengthen it? |
|---|---|
| Normal synchronisation | Known device/client, expected folders, historical pattern. |
| Approved migration | Change record, IT confirmation, expected service context. |
| Legitimate bulk work | Manager/user explanation aligned with repositories and timing. |
| Account compromise | Unfamiliar identity/session evidence plus unusual downloads. |
| Potential insider collection | Known user context but unusual sensitive data with no business justification. |
Keep attribution separate from impact
You may be able to confirm that sensitive files were downloaded before you can establish whether the actor was the legitimate user, an attacker or an approved process.
Escalate according to evidence and risk
If sensitive information is involved and the activity remains unexplained, follow organisational procedures for containment, data-owner review and further investigation.
Stage 11 — write the SOC finding
Lesson 53 key takeaways
- Measure bulk cloud activity by time and rate, not just total event count.
- Establish the beginning, peak and end of the burst.
- Do not assume event count equals total bytes transferred.
- Review cloud activity immediately before and after the download sequence.
- Compare the user's current activity with their own historical baseline.
- Repository scope and data sensitivity can matter more than raw volume.
- Investigate whether sync, migration, manual activity or automation generated the events.
- A legitimate tool can still be used during unauthorised collection.
- Correlate downloads with IP, device, session and authentication evidence.
- Look for activity across other cloud workloads.
- Test competing explanations instead of assuming exfiltration.
- Write the final finding around the combined evidence, not the alert threshold.
Module 6 — Cloud & SaaS Incidents
Lesson 53 measured rapid bulk cloud access and compared it with normal behaviour. Lesson 54 moves into application consent and cloud persistence.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 6: Cloud & SaaS Incidents
Investigate bulk SharePoint and OneDrive downloads with Microsoft Defender XDR
Lesson 53 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate hundreds of cloud file downloads by measuring event rates, establishing historical baselines and reviewing repositories, identity and session context.
Use KQL to investigate rapid cloud data access
Use CloudAppEvents to examine download bursts and test synchronisation, migration, legitimate bulk work, account compromise and possible data-exfiltration hypotheses without treating a high event count as proof of malicious activity.
