Lesson 55 — The Application Accessed Data Without the User
The user had gone home.
Their laptop was asleep.
There was no new interactive sign-in.
Yet Microsoft 365 activity continued.
Files were still being accessed.
Cloud events were still appearing.
The first reaction was predictable:
“How can the user be doing this if they aren't even online?”
Agent Foskett looked back at the previous OAuth consent event.
“Who said the user was doing it?”
The actor may be an application, not a person
Separate user activity from application activity, then determine which identity, permission relationship and cloud resources are involved.
Case briefing
Investigation objective
Determine whether continuing Microsoft 365 activity is being generated by an application, establish the permission relationship involved and identify what cloud data or resources were accessed.
Investigator's rule
Do not equate account-related activity with a human sitting at the keyboard. Cloud services can generate legitimate or malicious activity through applications, tokens and delegated access.
Stage 1 — establish the timeline
Start with chronology
Place consent, authentication, user activity and application activity on one timeline. The sequence helps distinguish the user establishing access from the application later using it.
No fresh sign-in does not mean no access
Cloud access can occur without a new interactive sign-in for every action. Existing tokens and application permission relationships can allow activity to continue.
Stage 2 — inspect the cloud activity
CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "alex@contoso.com"
| project Timestamp,
AccountId,
Application,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp ascLook for a change in the actor context
Compare application names, user agents, IP addresses and raw event details before and after the user's normal activity stops. A change may reveal a separate application path.
Preserve RawEventData
Application identifiers, object details and workload-specific information may be present in the raw event. Do not discard that context too early in the investigation.
Stage 3 — separate user activity from application activity
| User-driven activity | Application-driven activity |
|---|---|
| Interactive browser or client behaviour | Service or application context |
| User actively opens or changes content | App performs operations through granted access |
| Often correlates with visible user session | May continue without active user interaction |
| User agent may match normal workstation | User agent or application context may differ |
| Business action initiated by person | Operation may be scheduled, automated or token-driven |
Do not rely on one field
Application-driven activity is established through correlation. Use the available application, account, permission, timing and workload evidence together.
Legitimate apps behave this way too
Backup, synchronisation and business applications can legitimately access data without a user clicking anything. The investigation must determine whether the application and its behaviour are expected.
Stage 4 — reconnect the activity to the consent grant
Permission explains capability
Return to the consent evidence from Lesson 54. Determine whether the granted permissions are consistent with the activity now being observed.
Behaviour establishes impact
A permission capable of accessing files creates potential exposure. Evidence showing the application actually interacting with SharePoint or OneDrive moves the investigation toward observed impact.
Stage 5 — scope the application's activity
CloudAppEvents
| where Timestamp > ago(7d)
| where Application has "Document Helper"
| summarize
Events = count(),
Accounts = dcount(AccountId),
AccountList = make_set(AccountId, 50),
Actions = make_set(ActionType, 50),
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp)
by ApplicationOne user may not be the whole incident
If the same application appears against multiple identities, determine whether those users also granted access or whether broader application permissions are involved.
Measure duration as well as volume
An application that performs a few operations immediately after consent is different from one continuing to access cloud data hours or days later.
Stage 6 — map the workloads touched
Potential is not the same as observed
If the application has permission to reach mail and files but only file access is observed, report those facts separately. Capability and confirmed activity are different findings.
Data sensitivity changes priority
Access to ordinary working documents and access to sensitive financial, legal or customer repositories may require different escalation and response urgency.
Stage 7 — inspect timing and repetition
CloudAppEvents
| where Timestamp > ago(7d)
| where Application has "Document Helper"
| summarize Events = count()
by bin(Timestamp, 1h), ActionType
| order by Timestamp ascPersistence has a time dimension
Repeated application activity after the original consent event can demonstrate that the permission relationship remained operational beyond the user's initial interaction.
Look for quiet periods
Activity occurring overnight or while the user is known to be inactive can help distinguish application behaviour from ordinary interactive use, although timing alone is not proof of malicious intent.
Stage 8 — test competing hypotheses
| Hypothesis | Evidence that may support it |
|---|---|
| Approved background application | Known owner, expected permissions, documented purpose and normal activity pattern. |
| Legitimate user-authorised tool | User knowingly installed it and behaviour matches the expected function. |
| Unexpected but benign application | Purpose is legitimate but governance or approval was missing. |
| Consent-phishing application | Suspicious grant followed by unexplained access to cloud data. |
| Persistence after account compromise | Compromised identity established consent and app activity continued afterwards. |
“The user was offline” is not the conclusion
It is a useful observation that forces the analyst to identify another mechanism. The final finding still needs to explain the application relationship and actual activity.
Ask whether access survives other remediation
When investigating application-based persistence, determine whether the permission relationship and associated tokens require separate remediation under your organisation's incident-response procedures.
Stage 9 — build the complete application timeline
This is the persistence story
The important finding is not merely that the user was absent. It is that an application permission relationship enabled continuing cloud access after the initial interaction.
Follow the evidence forward
Determine how long the activity continued, what resources were touched and whether additional identities or applications are part of the same incident.
Stage 10 — containment and evidence preservation
Stage 11 — write the SOC finding
Lesson 55 key takeaways
- Cloud activity associated with a user does not always mean the user is actively performing it.
- Applications can continue operating through established permission relationships.
- No fresh interactive sign-in does not mean no cloud access occurred.
- Place consent, user activity and application activity on one timeline.
- Separate user-driven actions from application-driven actions.
- Reconnect observed activity to the permissions granted earlier.
- Permission capability and confirmed workload access are different findings.
- Scope the application across identities, actions and Microsoft 365 workloads.
- Duration and repetition help establish whether access persisted.
- Legitimate background applications can produce similar behaviour, so test competing hypotheses.
- Application-based persistence may require remediation beyond a password reset.
- Report only the data access and impact supported by evidence.
Module 6 — Cloud & SaaS Incidents
Lesson 55 followed an application that continued accessing data without active user interaction. Lesson 56 moves from application access to a different cloud-risk problem: a sensitive file being shared outside the organisation.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 6: Cloud & SaaS Incidents
Investigate non-interactive OAuth application access in Microsoft 365
Lesson 55 of the Agent Foskett SOC Analyst Academy teaches analysts how to follow application-driven Microsoft 365 activity after OAuth consent and distinguish user interaction from continuing application access.
Investigate application persistence with Microsoft Defender XDR and KQL
Use CloudAppEvents and supporting identity evidence to map OAuth permissions to observed SharePoint, OneDrive and other cloud workload activity, scope affected users and establish defensible impact.
