To investigate suspected SharePoint exploitation, build a timeline that connects the suspected identity and sign-in session to SharePoint file, page, and sharing activity—and check whether the same identity or access path touched other Microsoft 365 services. No single audit event proves exploitation: use the records as leads, correlate them with context, and state conclusions only as strongly as the evidence allows.
Start with a defined scope and time window
Record what triggered the investigation before searching: the suspected user, site or library, files of concern, approximate start time, and any known sign-in anomaly or Defender alert. Note the time zone used for the timeline. Include enough time before and after the suspected activity to capture possible initial access, later actions, and related alerts.
Keep the investigation focused on the questions you need to answer: which identity acted, through which session or token, on which resources, what sharing changed, and whether the activity extended to other services. Preserve the search criteria and exported records so another responder can reproduce the timeline.
Correlate Entra sign-ins with SharePoint audit records
Start with the suspected user’s Microsoft Entra sign-in records near the relevant time. Identify linkable values such as the Session ID (SID) or Unique Token Identifier (UTI), along with the user object identifier and any available device information. Microsoft documents how to carry these identifiers into Microsoft 365 audit searches in its guide to tracking identity activity with linkable identifiers.
#1 Best Overall
- In Entra sign-in records, locate the relevant user and time range, then record available session or token identifiers.
- In Microsoft Purview Audit, search SharePoint Online activity over the corresponding time range. Filter by the user and, where available, the session or token identifier.
- Export the results and compare timestamps, actors, resources, and related events. Search other affected Microsoft 365 services as needed to determine whether activity continued beyond SharePoint.
Microsoft maps the identifiers as follows in SharePoint Online audit data: sid to AADSessionId in the App Access Context object; uti to UniqueTokenId; oid to UserObjectId; and tid to OrganizationId. A device ID is available only for registered or domain-joined devices, so its absence is not by itself evidence that a record is invalid or benign.
If the response team determines that active token misuse is likely, Microsoft’s documented response sequence is to revoke the user’s active sessions and tokens, then investigate unauthorized actions across affected services. Treat that as a containment decision for the incident team; preserve the evidence and timeline needed to establish impact.
Read file, page, and sharing events as sequences
Use the Microsoft audit activity reference to interpret SharePoint and OneDrive operation names. A record identifies an activity, not necessarily the full story. Compare the actor, target, resource, timestamp, session context, and adjacent records before deciding whether an action was unauthorized.
Allow for extended-access and extended-modification records
FileAccessedExtended can represent continued access by the same person over an extended period, up to three hours; FileModifiedExtended serves a similar purpose for continued modification. These events reduce repeated-event noise. Do not count each extended record as a separate open or edit without checking the associated initial events and surrounding activity.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Distinguish invitation, access grant, and link use
| Audit event | What it indicates | What to verify |
|---|---|---|
SharingInvitationCreated |
An invitation was generated. Microsoft states, “The invitation grants no access to the resource at this point.” | Look for a later acceptance or another access-grant event; creation alone does not establish recipient access. |
SharingInvitationAccepted |
The external recipient accepted the invitation and received access. | Identify the recipient and resource, then check whether the grant matched an approved sharing action. |
AnonymousLinkCreated and AnonymousLinkUsed |
An “Anyone” link was created and later used. | Establish who created the link, which resource it covered, and whether its use fits the expected business context. |
SecureLinkCreated and AddedToSecureLink |
A specific-person link was created and a target user was added. | Inspect the target field and adjacent event details to confirm who received access. |
AddedToGroup and SharingSet |
SharePoint may grant access through group membership when the target already has a directory guest account. | Check the target identity, group or sharing change, and resource to understand how access was granted. |
Microsoft’s sharing-audit guidance explains these event meanings and notes that sharing records identify an acting user and target user. Inspect the exported AuditData column for additional context. Trace the sequence from initiation to grant and, where recorded, subsequent use; compare it with the organization’s approved sharing activity.
Check whether an application grant is part of the access path
If suspicious activity may involve application access rather than only a user’s interactive session, search the audit log for Consent to application. Review the record details, including the administrative-consent value, then inventory the applications and permissions to decide whether the grant is expected. Microsoft’s application consent investigation guidance notes that a corresponding audit record can take 30 minutes to 24 hours to appear. Retention and searchability also depend on the user’s Microsoft 365 subscription licensing. An immediate search with no result therefore does not establish that no consent event occurred.
Expand the investigation in Microsoft Defender
If the activity appears in a Microsoft Defender incident, review its overview and timeline, affected users and entities, evidence, response status, incident graph, and underlying investigations. These views can help connect SharePoint activity to related alerts and other Microsoft 365 entities. Microsoft’s Defender incident workflow describes how automated investigation and response findings can be collected into an incident. The cited workflow lists Defender for Office 365 Plan 2 or higher, suitable security roles, and Search and purge as prerequisites; confirm the tenant’s current licensing and permissions before relying on a feature.
Audit searches can be opened in Microsoft Defender or Microsoft Purview. Microsoft’s Defender portal audit-search documentation lists Exchange Online Organization Management or Compliance Management role groups, or Microsoft Entra Global Administrator or Compliance Administrator roles, among permission routes. Assign only the permissions responders need: Microsoft strongly advocates least privilege, and says Global Administrator should be limited to emergency use or cases without a suitable lower-privilege route.
Best Value
Investigate suspicious or blocked files
For a malware alert or suspicious file, identify the detection source in Defender quarantine or the applicable content-malware view, then correlate it with the file’s site and path and the surrounding user activity. Purview Audit can be searched for FileMalwareDetected; the audit data can include VirusVendor and VirusInfo. SharePoint Online PowerShell’s Get-SPOMalwareFile returns detection details, including malware information and site/path context. Microsoft’s SharePoint malware-detection guidance describes these investigation sources and false-positive handling.
SharePoint uses Microsoft Defender for Office 365 sandbox scanning and Microsoft Defender for Endpoint signature-based protection. Scanning may be asynchronous and can depend on factors such as file type and sharing status. When SharePoint detects malware, access is blocked and a warning appears. Investigate the detection; do not unblock a file unless you are confident it is safe. If you believe the detection is a false positive, follow Microsoft’s submission process for analysis.
Build a defensible finding from correlated evidence
Before classifying the activity, compare the records across a few dimensions rather than ranking isolated event names:
- Identity and provenance: acting and target users, guest or application identities, session or token identifiers, and device identifiers when present.
- Action sequence: sign-in context, invitation or grant, link use, file or page access, modification, deletion, and later sharing changes.
- Resource scope: affected site, library, folder, or file, including its business importance or sensitivity as known to your organization.
- Time and context: event order, expected work patterns, approved sharing, and related Defender alerts.
- Evidence quality: raw audit details and exported
AuditDataalongside alert summaries; note relevant delays, retention limits, licensing, and missing fields.
Document what the correlated evidence establishes, what remains uncertain, and the affected identities and resources. Suspicious activity warrants investigation, but a single invitation, access event, or alert is not proof of exploitation; confirmation depends on the full sequence and context.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
