Lesson 56 — The Account Shared a Sensitive File Externally
The alert sounded serious.
A sensitive file had been shared outside the organisation.
The file contained commercial pricing information.
The recipient used an external email address.
Easy verdict?
Not yet.
External sharing can be legitimate business activity.
It can also be accidental exposure, compromised-account activity or deliberate data removal.
Agent Foskett opened the timeline.
“Before we call this exfiltration, who shared what with whom — and how?”
Sharing does not automatically equal exfiltration
Identify the file, sharing mechanism, recipient, identity context and actual access before reaching a verdict.
Case briefing
Investigation objective
Determine what was shared, who initiated the sharing, who received access, which sharing mechanism was used, whether the external party actually accessed the data and whether the activity fits a legitimate business purpose.
Investigator's rule
Do not use “shared externally” and “data exfiltration” as synonyms. Establish exposure, access and context before assigning intent.
Stage 1 — locate the sharing activity
CloudAppEvents
| where Timestamp > ago(7d)
| where AccountId =~ "maya@contoso.com"
| where ActionType has_any ("Share", "Sharing", "AnonymousLink")
| project Timestamp,
AccountId,
Application,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp ascInspect the underlying event
Exact action names and available properties vary with workload and telemetry. Preserve RawEventData so file, recipient, link and sharing details can be inspected where available.
Anchor the investigation
Record the exact sharing time. Then examine activity immediately before and after it rather than treating the share as an isolated event.
Stage 2 — identify exactly what was shared
The file matters as much as the event
A publicly available brochure and a confidential pricing workbook are not equivalent incidents. Establish the business sensitivity of the object involved.
Do not infer sensitivity from the filename alone
Use available labels, repository context, ownership and business confirmation. A dramatic filename is useful context, not proof of classification.
Stage 3 — determine how access was granted
| Sharing mechanism | Investigation question |
|---|---|
| Specific external person | Which identity was granted access and was that recipient expected? |
| Guest account | Was an existing or newly created guest used? |
| Organisation-scoped link | Was access limited to authenticated organisational users? |
| Anonymous / anyone link | Could possession of the link allow access without a named recipient? |
| Existing permission changed | Was an earlier sharing relationship expanded? |
The mechanism changes the exposure
A named external recipient and a broadly accessible anonymous link create different scoping problems. Determine how access was granted before estimating impact.
Sharing created is not necessarily sharing used
The existence of a link or permission shows potential exposure. Look for evidence that the external party actually accessed the resource.
Stage 4 — investigate the identity that performed the share
Was Maya really Maya?
If the identity context is suspicious, the external sharing event may be part of an account-compromise investigation rather than a simple data-governance issue.
Normal authentication does not settle intent
A legitimate user can accidentally or deliberately share sensitive data. A valid session tells you about authentication context, not business justification.
Stage 5 — establish the user's sharing baseline
CloudAppEvents
| where Timestamp > ago(30d)
| where AccountId =~ "maya@contoso.com"
| where ActionType has_any ("Share", "Sharing", "AnonymousLink")
| summarize Events = count(),
Actions = make_set(ActionType, 50),
Applications = make_set(Application, 20),
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp)Baseline behaviour provides context
If the user's role routinely involves external collaboration, sharing may be common. The important question becomes whether this recipient, file, mechanism and timing fit that normal pattern.
Rare does not mean malicious
A first-time external share can still be legitimate. Baselines help identify deviation; they do not provide the final verdict.
Stage 6 — investigate the recipient
Business context is essential
A new external domain may be suspicious, or it may belong to a newly engaged consultant. Confirm the relationship through appropriate business channels.
Watch for lookalikes
A mistyped or deceptive recipient domain can turn a legitimate sharing intention into a real exposure. Compare the destination carefully with the expected organisation.
Stage 7 — determine whether the file was actually accessed
CloudAppEvents
| where Timestamp between
(datetime(2026-09-03 14:00:00) ..
datetime(2026-09-03 16:00:00))
| where RawEventData has "FY27-Pricing-Strategy.xlsx"
| project Timestamp,
AccountId,
Application,
ActionType,
IPAddress,
RawEventData
| order by Timestamp ascFollow the object, not only the user
Once a specific file becomes central to the case, pivot on that object through the available telemetry. This can reveal access occurring under a different identity context.
Exposure and access are separate findings
If sharing was created but no external access is observed, report potential exposure. If external access is confirmed, document that separately and continue scoping.
Stage 8 — expand the timeline
Look beyond the first file
A single sensitive share may be isolated. Multiple external shares to the same destination can indicate a broader exposure pattern that needs tenant-wide scoping.
Look before the share too
Bulk file access, unusual searches or rapid navigation through sensitive repositories immediately before sharing can change the risk assessment.
Stage 9 — test competing hypotheses
| Hypothesis | Evidence that may support it |
|---|---|
| Approved collaboration | Known recipient, documented business purpose, expected sharing method and data-owner approval. |
| Accidental exposure | Wrong recipient, incorrect link type or user confirms a sharing mistake. |
| Policy violation | User intentionally shared data for work but bypassed approved controls or process. |
| Account compromise | Suspicious identity/session evidence plus unexplained external sharing. |
| Potential insider activity | Authenticated user activity, unexplained collection/sharing and no legitimate business justification. |
Intent is the hardest part
Telemetry can often prove that sharing occurred and that data was accessed. It may not prove why the user did it. Keep technical findings separate from unsupported attribution.
Use neutral investigation language
Prefer “external sharing inconsistent with known business context” over “the employee stole data” unless the wider investigation has established that conclusion.
Stage 10 — decide what needs containment
Containment should match the finding
An accidental anonymous link may require link removal and exposure review. A compromised account may additionally require session and identity remediation. Do not treat every external share identically.
Preserve evidence first
Where procedures allow, capture the sharing relationship and relevant activity before permissions are removed so the incident can still be reconstructed accurately.
Stage 11 — write the SOC finding
Lesson 56 key takeaways
- External sharing is not automatically data exfiltration.
- Identify the exact file or object involved.
- Establish its sensitivity using evidence and business context.
- Determine how external access was granted.
- Named recipients and anonymous links create different exposure scenarios.
- Investigate the identity and session that performed the share.
- Compare the event with the user's normal sharing behaviour.
- Validate the external recipient and business relationship.
- Separate permission creation from confirmed external access.
- Pivot on the file to follow subsequent activity.
- Test legitimate collaboration, accidental exposure, policy violation, account compromise and insider activity as competing hypotheses.
- Do not assign malicious intent unless the evidence supports it.
Module 6 — Cloud & SaaS Incidents
Lesson 56 investigated a sensitive file shared outside the organisation. Lesson 57 removes endpoint evidence completely and asks the analyst to work an incident using cloud telemetry alone.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 6: Cloud & SaaS Incidents
Investigate external file sharing in Microsoft 365
Lesson 56 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate sensitive files shared outside an organisation by identifying the object, recipient, sharing mechanism, identity context and subsequent external access.
Investigate SharePoint and OneDrive data exposure with Microsoft Defender XDR and KQL
Use CloudAppEvents and supporting Microsoft 365 evidence to distinguish legitimate collaboration, accidental exposure, policy violations, account compromise and potential insider activity while keeping technical evidence separate from unsupported attribution.
