Agent Foskett Academy • KQL Academy • Module 13 • Lesson 158 • Cloud & SaaS Investigation

Lesson 158 — The Account Shared a Sensitive File Outside the Organisation

Lesson 157 confirmed that mailbox content was being redirected externally. Now the investigation finds another form of data exposure: a SharePoint or OneDrive file is shared outside the organisation.

External sharing is a normal collaboration feature, so the important questions are not simply whether a share occurred. We need to know which file was shared, who received access, how the share was created, whether the behaviour was normal for the user and whether it belongs to the same suspicious cloud session.

External sharing is not automatically exfiltration. The file, recipient, permissions, timing and surrounding identity context determine the risk.

Begin the Investigation Back to KQL Academy

Agent Foskett KQL Academy external SharePoint file sharing investigation

Your case file

At 4:08 PM, alex.wilson@contoso.com shares a sensitive document from SharePoint with a recipient outside the organisation.

✓ Find the sharing event

✓ Identify the file and recipient

✓ Compare with historical sharing behaviour

✓ Correlate the action with the suspicious session

Case briefing

CASE FILE User: alex.wilson@contoso.com 15:22 — suspicious inbox rule ↓ 15:28–16:02 — external mail forwarding ↓ 16:08 — SHAREPOINT FILE SHARED EXTERNALLY ↓ File: Project-Falcon-Financials.xlsx Recipient: external address under investigation ↓ THE QUESTION Was this legitimate collaboration, or did the compromised cloud session expose sensitive organisational data outside the tenant?

Investigation objective

Use Microsoft 365 audit data and Entra sign-in telemetry to identify SharePoint and OneDrive sharing activity, preserve the file and recipient evidence, compare the event with the user's historical sharing pattern and determine whether the action belongs to the wider compromise timeline.

Investigator's rule

Sharing creates access; it does not prove the recipient opened the file. Establish the sharing action first, then investigate whether the recipient or anonymous link was actually used.

Stage 1 — find SharePoint and OneDrive sharing events

Begin with Microsoft 365 audit telemetry for the target user and focus on sharing-related operations. Preserve file, site, recipient, source IP and user-agent context.

1234567891011

let TargetUser = "alex.wilson@contoso.com";
OfficeActivity
| where TimeGenerated > ago(7d)
| where UserId =~ TargetUser
| where OfficeWorkload in ("SharePoint", "OneDrive")
| where Operation in ("SharingSet", "SharingInvitationCreated",
                      "AnonymousLinkCreated", "SecureLinkCreated")
| project TimeGenerated, UserId, Operation, Site_Url,
          SourceFileName, SourceRelativeUrl,
          TargetUserOrGroupName, ClientIP, UserAgent
| order by TimeGenerated asc

Operation names matter

Different sharing methods can produce different audit operations. A direct invitation and an anonymous link do not create the same exposure or control model.

Keep the file path

The file name alone may be ambiguous. Preserve the site and relative path so the exact resource can be identified and classified correctly.

Stage 2 — identify the recipient and shared resource

Project the recipient alongside the file and site information so the investigator can evaluate who received access and what was exposed.

123456789101112

let TargetUser = "alex.wilson@contoso.com";
OfficeActivity
| where TimeGenerated > ago(7d)
| where UserId =~ TargetUser
| where OfficeWorkload in ("SharePoint", "OneDrive")
| where Operation in ("SharingSet", "SharingInvitationCreated",
                      "AnonymousLinkCreated", "SecureLinkCreated")
| extend Recipient = tostring(TargetUserOrGroupName)
| project TimeGenerated, Operation, SourceFileName,
          SourceRelativeUrl, Site_Url, Recipient,
          ClientIP, UserAgent
| order by TimeGenerated asc

External recipient requires validation

Determine whether the recipient belongs to a trusted partner, contractor, personal account, unknown domain or another approved collaboration scenario before describing the share as unauthorised.

Anonymous links change the problem

An anonymous link may not identify a specific recipient at all. In that case, the investigation must focus on link creation, scope, later access events and whether the link remained active.

Stage 3 — establish the user's normal sharing baseline

Look back across 30 days and summarise sharing activity. This helps determine whether external collaboration is routine for the account or a new behaviour appearing during the incident.

1234567891011121314

let TargetUser = "alex.wilson@contoso.com";
OfficeActivity
| where TimeGenerated > ago(30d)
| where UserId =~ TargetUser
| where OfficeWorkload in ("SharePoint", "OneDrive")
| where Operation in ("SharingSet", "SharingInvitationCreated",
                      "AnonymousLinkCreated", "SecureLinkCreated")
| summarize SharingEvents=count(),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated),
            Recipients=make_set(TargetUserOrGroupName, 50),
            Files=make_set(SourceFileName, 50)
          by bin(TimeGenerated, 1d)
| order by TimeGenerated asc

Rare sharing increases interest

If the account almost never shares externally, a new share during an active compromise investigation becomes more significant.

Frequent sharing still needs review

A user who collaborates externally every day can still expose a sensitive file to the wrong destination. Baseline explains behaviour; it does not approve the specific action.

Stage 4 — correlate the share with the identity timeline

Return to Entra sign-in telemetry and inspect the authentication context around the file-sharing event.

12345678910

let TargetUser = "alex.wilson@contoso.com";
let ShareTime = datetime(2026-08-18 16:08:00);
SigninLogs
| where TimeGenerated between (ShareTime - 45m .. ShareTime + 30m)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated, UserPrincipalName, IPAddress,
          Location, AppDisplayName, ClientAppUsed,
          DeviceDetail, AuthenticationRequirement,
          ConditionalAccessStatus, ResultType
| order by TimeGenerated asc

Source and session context matter

If the sharing event occurs from the same suspicious source and device context already identified in the cloud investigation, that correlation can materially strengthen the compromise hypothesis.

Successful authentication is still not attribution

The user account may have authenticated successfully while an attacker controlled the session. Keep identity success and human attribution as separate conclusions.

Stage 5 — build the external-sharing timeline

Combine the sign-in and file activity around the share into one chronological view. This shows whether access, downloads and external sharing occurred as part of one connected cloud sequence.

12345678910111213141516171819202122232425262728293031

let TargetUser = "alex.wilson@contoso.com";
let StartTime = datetime(2026-08-18 15:30:00);
let EndTime = datetime(2026-08-18 16:30:00);
union
(
    SigninLogs
    | where TimeGenerated between (StartTime .. EndTime)
    | where UserPrincipalName =~ TargetUser
    | project TimeGenerated,
              EvidenceType="Sign-in",
              Activity=AppDisplayName,
              Source=IPAddress,
              Detail=strcat(tostring(Location),
                            " | CA=", tostring(ConditionalAccessStatus))
),
(
    OfficeActivity
    | where TimeGenerated between (StartTime .. EndTime)
    | where UserId =~ TargetUser
    | where OfficeWorkload in ("SharePoint", "OneDrive")
    | where Operation in ("FileAccessed", "FileDownloaded",
                          "SharingSet", "SharingInvitationCreated",
                          "AnonymousLinkCreated", "SecureLinkCreated")
    | project TimeGenerated,
              EvidenceType="Cloud file activity",
              Activity=Operation,
              Source=ClientIP,
              Detail=strcat(SourceFileName, " | ",
                            tostring(TargetUserOrGroupName))
)
| order by TimeGenerated asc

Look for access before sharing

File access or download events immediately before external sharing can show how the resource entered the incident sequence and whether the actor deliberately targeted it.

The next question is use

After proving that access was granted outside the organisation, determine whether the recipient or link was used. Sharing and external access are separate evidence questions.

Agent Foskett's external-sharing timeline

15:22 Suspicious mailbox rule ↓ 15:28–16:02 Mail forwarded externally ↓ 16:04 Sensitive SharePoint file accessed ↓ 16:08 EXTERNAL SHARE CREATED ↓ FILE + SITE + RECIPIENT preserved from OfficeActivity ↓ 30-DAY BASELINE sharing behaviour compared with history ↓ SIGN-IN CONTEXT source + location + device reviewed ↓ ASSESSMENT Sensitive organisational file was exposed externally Actual recipient access still requires evidence

The share proved access was granted. The next question is whether anyone outside the organisation used it.

Your evidence board

Evidence	What it supports	Weight
External sharing event for identified file	Confirms access was granted outside the organisation.	Strong fact
File is classified or confirmed as sensitive	Increases the potential impact of the exposure.	Very strong impact context
Recipient is unapproved or previously unseen	Strengthens concern about unauthorised sharing.	Strong when validated
Share occurs during suspicious cloud session	Connects the action to the wider compromise timeline.	Strong context
External sharing is rare for the account	Shows the behaviour is unusual.	Supporting evidence
Sharing event alone	Does not prove the recipient accessed or downloaded the file.	Insufficient for confirmed use

Write the finding like an investigator

Example: Microsoft 365 audit telemetry recorded an external sharing event by alex.wilson@contoso.com involving a SharePoint file during the same investigation window as suspicious authentication, mailbox configuration and external forwarding activity. The event was reviewed by operation, file name, site, recipient, client IP and user-agent context and compared with the user's recent external-sharing history. The file was confirmed as sensitive and the recipient required validation against approved collaboration records. The sequence supports the conclusion that access to organisational data was granted outside the tenant during an active compromise investigation. The sharing event alone does not establish that the external recipient opened or downloaded the file. Subsequent access and link-use evidence should be investigated to determine actual exposure.

Lesson 158 key takeaways

Use Microsoft 365 audit telemetry to investigate SharePoint and OneDrive sharing events.
Preserve the exact file, site, recipient, source and user-agent context.
Different sharing operations create different exposure models.
Validate whether a recipient is external, approved and expected.
Anonymous links require a different follow-up investigation from named invitations.
Historical sharing behaviour helps identify unusual actions.
Correlate sharing with the surrounding Entra sign-in timeline.
A successful sign-in does not prove the legitimate user initiated the share.
External sharing proves access was granted, not that the resource was actually accessed.
Follow recipient or link usage to determine real exposure.

Module 13 — bring the cloud evidence together

Lesson 158 adds external file sharing to the compromise story. Next, we stop looking at one workload at a time and follow the same user across Entra, Exchange and SharePoint to build a single cloud investigation view.

Next: Lesson 159 — Following the User Across Entra, Exchange and SharePoint.

Continue your KQL investigation training

Module 13 follows users, sessions, applications and data through Microsoft 365 and cloud services.

KQL Academy Lesson 157 — The Mailbox Started Forwarding Messages Externally Microsoft Sentinel Academy Agent Foskett Academy

🔎 KQL Academy — Module 13: Advanced Cloud & SaaS Investigation

Following users, sessions, applications and data through Microsoft 365 and cloud services.

⬅ Previous lesson

Lesson 157 — The Mailbox Started Forwarding Messages ExternallyConfirm whether suspicious mailbox configuration resulted in external message delivery.

✅ Current lesson

Lesson 158 — The Account Shared a Sensitive File Outside the OrganisationInvestigate external SharePoint and OneDrive sharing and determine whether sensitive data was exposed outside the tenant.

Next lesson

Lesson 159 — Following the User Across Entra, Exchange and SharePointCorrelate identity, mailbox and file activity into a single cloud investigation timeline.

Investigate external SharePoint sharing with KQL

Lesson 158 of the Agent Foskett KQL Academy uses Microsoft Sentinel and Microsoft 365 audit telemetry to investigate SharePoint and OneDrive files shared outside the organisation.

Investigate sensitive file exposure in Microsoft 365

Learn how to identify external sharing events, preserve recipient and file context, compare behaviour with historical baselines and correlate sharing with suspicious Entra sign-in activity.