ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • SharePoint • CloudAppEvents • Microsoft Defender XDR • Data Access • KQL

The SharePoint File Was Accessed 2,400 Times Overnight

The file was important.

But it was not unusual for people to open it.

What was unusual was the number.

Between midnight and 6:00 AM, Microsoft 365 recorded more than 2,400 access events involving the same SharePoint content.

Was it an attacker collecting data?
A synchronisation client?
An automated process?
Or simply noisy audit telemetry?

The count created the suspicion. The context would decide the verdict.

Discuss cloud security Back to investigations
Agent Foskett investigating unusual SharePoint file access
High Volume Is A Clue — Not A Verdict

Cloud investigations need more than a big number. Identify the actor, action, application, IP address and surrounding activity before deciding what happened.

✓ Establish the access pattern
✓ Identify users, apps and source IPs
✓ Separate automation from suspicious collection

The overnight spike

The investigation began with an access-volume anomaly. One SharePoint resource had generated thousands of events during a period when normal user activity should have been low. The first task was not to call it exfiltration. It was to establish exactly what Microsoft 365 had recorded.
2,400 eventsThe volume was far outside the normal pattern for the file.
Overnight activityTiming made the behaviour more interesting, but timing alone did not make it malicious.
One cloud resourceThe repeated access created a strong pivot into users, applications, IP addresses and related files.

Start with the SharePoint activity

In environments where the relevant Microsoft 365 activity is available in CloudAppEvents, begin by locating events associated with the file or SharePoint object and preserving the raw action names before making assumptions about what “accessed” means.
sharepoint-file-activity.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
let FileName = "Board-Financials.xlsx";
CloudAppEvents
| where Timestamp > ago(24h)
| where Application == "Microsoft SharePoint Online"
| where RawEventData has FileName
| project Timestamp,
          ActionType,
          AccountDisplayName,
          AccountId,
          IPAddress,
          UserAgent,
          RawEventData
| order by Timestamp asc

Who generated the 2,400 events?

The next pivot is the actor. If one account produced nearly every event, investigate that identity. If several users appear, look for a shared application, IP address, synchronisation process or service behaviour.
sharepoint-actors.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
CloudAppEvents
| where Timestamp > ago(24h)
| where Application == "Microsoft SharePoint Online"
| summarize Events = count(),
            Actions = make_set(ActionType, 20),
            IPs = make_set(IPAddress, 20),
            UserAgents = make_set(UserAgent, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
    by AccountDisplayName, AccountId
| order by Events desc

The action type changes the story

A large number of audit events does not necessarily mean a user manually opened the same document 2,400 times. Break the activity down by ActionType. Preview, sync, access, download, sharing and application-generated operations have different investigative meanings.
sharepoint-action-breakdown.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
CloudAppEvents
| where Timestamp > ago(24h)
| where Application == "Microsoft SharePoint Online"
| summarize Events = count(),
            Users = dcount(AccountId),
            IPs = dcount(IPAddress)
    by ActionType
| order by Events desc

Now pivot on the account and IP address

If one identity dominates the activity, investigate everything that identity did around the same period. Then pivot on the source IP. The goal is to determine whether the file activity was isolated, part of wider SharePoint collection, or connected to suspicious authentication.
cloud-account-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 User = "alex@contoso.com";
CloudAppEvents
| where Timestamp > ago(24h)
| where AccountId =~ User
| project Timestamp,
          Application,
          ActionType,
          IPAddress,
          UserAgent,
          RawEventData
| order by Timestamp asc

Check the sign-in context

Cloud activity becomes more significant when it lines up with an unusual sign-in, unfamiliar IP address, unexpected device, new location or abnormal authentication pattern. Correlate the cloud evidence with Microsoft Entra sign-in telemetry rather than treating SharePoint in isolation.
signin-context.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 User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ User
| project TimeGenerated,
          IPAddress,
          AppDisplayName,
          ResultType,
          ConditionalAccessStatus,
          DeviceDetail,
          LocationDetails
| order by TimeGenerated asc

Automation, sync or collection?

This is where the investigation earns its verdict. Compare the actor, application, user agent, IP address, timing, action types and breadth of accessed content. A known service account performing a scheduled job is very different from a user account that signed in from a new location and immediately touched hundreds of sensitive files.
Legitimate automationExpected account, expected application, repeatable schedule and known business purpose.
Synchronisation activityOneDrive or other sync behaviour can generate high-volume cloud events without a person opening each file manually.
Suspicious collectionUnfamiliar identity context, unusual IP, broad sensitive-file access and abnormal timing can indicate data staging or collection.

Agent Foskett's investigation mindset

The number 2,400 is interesting, but it is not the answer. Good cloud investigations turn volume into context: who, what, where, how, and what happened immediately before and after.
Count firstEstablish whether the volume is genuinely abnormal.
Break it apartGroup by account, action, IP address, application and user agent.
Correlate before decidingUse identity and surrounding cloud telemetry to determine whether the pattern is expected or suspicious.

Investigation findings

The investigation showed why high-volume SharePoint activity cannot be judged from a dashboard number alone. The analyst had to identify the actor, classify the actions, examine the source infrastructure and correlate the activity with authentication evidence before deciding whether the overnight spike represented legitimate automation, synchronisation or malicious collection.
The spike created the lead2,400 events were enough to justify investigation, not enough to prove compromise.
CloudAppEvents created the timelineThe audit trail exposed the actions, accounts, applications and source IPs behind the volume.
Context created the verdictThe meaning came from correlation, not from the count itself.

Related Agent Foskett investigations

Continue the cloud data investigation with synchronisation, sharing and identity activity.
The File Was Never Downloaded — It Was SynchronisedInvestigate cloud data movement that never appears as a traditional browser download. The Attacker Didn't Download the Files — They Shared ThemFollow exposure caused by changes to who can access the data. Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
2,400 accesses were the clue — not the conclusion.
In cloud investigations, context turns volume into evidence.
Visit the Agent Foskett Academy

Final thought

An analyst could have seen 2,400 SharePoint events and immediately called it data exfiltration. Agent Foskett asks a better question: what generated those events? The answer lives in the relationships between the file, the account, the action, the application, the IP address and the sign-in that made the activity possible.
Find the actorWho or what generated the activity?
Understand the actionWhat did the audit event actually represent?
Follow the surrounding evidenceBecause a large number becomes meaningful only when the rest of the story supports it.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The SharePoint File Was Accessed 2,400 Times Overnight

This Agent Foskett investigation explores high-volume SharePoint activity, CloudAppEvents, Microsoft Defender XDR, Microsoft Sentinel and KQL to distinguish legitimate cloud behaviour from suspicious data collection.

SharePoint CloudAppEvents And KQL Investigation

The investigation follows account activity, action types, IP addresses, user agents, sign-in context and surrounding Microsoft 365 events to explain why a single SharePoint resource generated thousands of audit events overnight.

Cloud Data Access Investigation

GEMXIT helps organisations investigate Microsoft 365 and SharePoint security activity using Defender XDR, Sentinel and KQL, correlating cloud audit evidence with identity telemetry before reaching a verdict.