ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • SharePoint Online • Anonymous Sharing • Microsoft 365 Audit • OfficeActivity • KQL

The SharePoint Folder Was Private — Until Someone Created an Anonymous Link

The SharePoint folder looked private.

The expected users had access.
The expected groups had access.
Nothing in the visible membership immediately suggested public exposure.

But the audit trail contained another permission path.

Someone had created an anonymous sharing link.

Agent Foskett stopped asking who belonged to the site and started reconstructing the sharing event itself.

Who created the link? What did it expose? And was the link ever used?

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating anonymous SharePoint sharing in Microsoft 365 audit logs
Private Membership. Public Link.

Site membership can look perfectly reasonable while a sharing link creates a separate route to the content. The investigation has to include the sharing model, not just the membership list.

✓ Find the sharing event
✓ Identify the exposed object
✓ Hunt for subsequent access

The permissions looked normal

The investigation began with a concern that confidential material might have been exposed outside the organisation.

Administrators checked the obvious places. Site membership looked expected. The folder was not sitting in an obviously public location.

That could have ended the investigation too early.

SharePoint access is not explained only by who belongs to the site.

Sharing can create another path.

An anonymous link changes the question

An anonymous or “Anyone” link is designed to allow access without requiring the recipient to authenticate as a specific named user, subject to the tenant and sharing configuration in effect.

That means the analyst may not be able to answer the incident simply by looking for an external guest account.

Agent Foskett broke the problem into three parts.
CreationWho created the sharing link, and when?
ScopeWhich file or folder did the link expose and what type of access did it permit?
UsageWhat audit evidence exists after the link was created?

Start with SharePoint sharing activity

Where Microsoft 365 audit data is ingested into Microsoft Sentinel, OfficeActivity can provide SharePoint and OneDrive audit events. Agent Foskett began broadly so the investigation reflected the operations actually present in the tenant.
sharepoint-sharing-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload =~ "SharePoint"
| where Operation has_any (
    "AnonymousLink",
    "Sharing",
    "SecureLink")
| project TimeGenerated,
          UserId,
          Operation,
          Site_Url,
          OfficeObjectId,
          ClientIP,
          Parameters
| order by TimeGenerated desc

The sharing event became the anchor

The audit evidence identified a sharing operation involving the content under investigation.

Agent Foskett inspected the raw event and available parameters rather than assuming every sharing operation carried identical fields. The important facts were the actor, timestamp, affected object and sharing context recorded by Microsoft 365.

The folder had not become public because its membership changed. A new access mechanism had been created.
Investigation principle: A permission investigation must include links as well as identities.

Search the exact object

Once the affected path was known, Agent Foskett narrowed the timeline to every relevant audit event involving that file or folder. This helped separate the link creation from later activity.
object-audit-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let ObjectPath = "/Shared Documents/Finance/";
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload =~ "SharePoint"
| where OfficeObjectId has ObjectPath
| project TimeGenerated,
          UserId,
          Operation,
          ClientIP,
          OfficeObjectId,
          Parameters
| order by TimeGenerated asc

Creation does not prove exposure was used

Finding the anonymous link answered an important question, but it did not automatically prove that an unauthorised person opened or downloaded the content.

Agent Foskett therefore separated link creation from link usage.

The investigation searched the subsequent audit window for access, preview, download and sharing-related operations involving the affected object. The exact operation names and identity information available depend on the audited event and Microsoft 365 logging.

Hunt the activity after the link appeared

The link-creation timestamp defined the next investigation window. Agent Foskett looked for activity involving the same content after that moment rather than searching the entire audit history without context.
activity-after-sharing.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let LinkCreated = datetime(2026-09-28 14:06:00);
let ObjectPath = "/Shared Documents/Finance/";
OfficeActivity
| where TimeGenerated between
    (LinkCreated .. LinkCreated + 7d)
| where OfficeWorkload =~ "SharePoint"
| where OfficeObjectId has ObjectPath
| project TimeGenerated,
          Operation,
          UserId,
          ClientIP,
          OfficeObjectId,
          Parameters
| order by TimeGenerated asc

The creator mattered too

An anonymous link can be created deliberately for a legitimate business purpose, accidentally with the wrong sharing scope, or as part of malicious activity.

Agent Foskett therefore investigated the account that created it.

Was the user expected to share this content? Did the timing make sense? Was the source IP familiar? Were there other unusual sharing operations by the same identity?

The link was evidence. Intent still required context.

Expand the hunt to the creator

If one unexpected anonymous link existed, Agent Foskett wanted to know whether it was isolated. He searched the creator's SharePoint audit activity for other sharing events during the same period.
creator-sharing-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let Creator = "alex@contoso.com";
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload =~ "SharePoint"
| where UserId =~ Creator
| where Operation has_any (
    "AnonymousLink",
    "Sharing",
    "SecureLink")
| project TimeGenerated,
          Operation,
          Site_Url,
          OfficeObjectId,
          ClientIP,
          Parameters
| order by TimeGenerated asc

Build the exposure timeline

The incident became much clearer when the sharing and access evidence was placed in order.
14:06 — Link createdA sharing operation creates a new route to the protected content.
14:06 onward — Exposure windowThe link remains a potential access path until it expires, is disabled or otherwise becomes unusable.
Later activity — Validate usageAudit evidence is reviewed to determine what can actually be established about subsequent access.

What Agent Foskett checked

Sharing operationWhat event created the additional access path?
CreatorWhich identity created the link and from what available context?
ObjectExactly which file or folder was exposed?
Link scopeWhat sharing type and permissions were recorded?
Subsequent activityWhat evidence exists after the sharing event?
Broader scopeDid the same account create other unexpected sharing links?

What the evidence can and cannot prove

An anonymous link can create an access path without changing ordinary site membership. That does not mean every anonymous link represents a breach.

Likewise, proving that a link existed does not automatically prove that an unauthorised party used it or downloaded the content.

Microsoft 365 audit fields and operations vary by event, workload and configuration. Analysts should inspect the actual audit records in their environment and avoid inferring identity or access that the telemetry does not establish.

Exposure and confirmed access are related questions — but they are not the same finding.

The lesson

The SharePoint folder looked private because the expected membership looked private.

That view was incomplete.

A sharing link had created another route to the content.

Agent Foskett reconstructed the sharing event, identified the affected object, investigated the creator and searched the subsequent audit window for evidence of use.

When investigating access to cloud content, don't only ask who has permission. Ask what links exist too.
Investigation principle: Private membership does not guarantee private content when another sharing path exists.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingExplore practical investigation techniques across Microsoft Defender XDR and Microsoft Sentinel.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
The membership was private. The link wasn't.
Find the sharing event. Define the exposure window. Then determine what the evidence proves.
Continue the Investigation

Final thought

Cloud permission investigations cannot stop at group membership.

A sharing link can create an entirely different access path without making the ordinary membership list look unusual.

Reconstruct the link creation, inspect the object and sharing scope, investigate the creator and correlate the activity that followed.

Follow the evidence. Build the timeline.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The SharePoint Folder Was Private — Until Someone Created an Anonymous Link

This Agent Foskett investigation examines how SharePoint content can gain another access path through anonymous sharing even when ordinary site membership appears private.

Investigating SharePoint Anonymous Links With Microsoft 365 Audit Logs

Where Microsoft 365 audit data is available in Microsoft Sentinel, OfficeActivity can help investigators identify SharePoint sharing events, affected objects, creators, client context and subsequent activity.

Microsoft Sentinel KQL for SharePoint Sharing Investigations

Use KQL to reconstruct the sharing timeline, define the potential exposure window, investigate the identity that created the link and distinguish link creation from evidence of subsequent content access.