ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 46 • Investigating CloudAppEvents

Investigating CloudAppEvents: The User Passed MFA. The Attacker Still Got In.

The sign-in looked legitimate.

The user passed MFA.

No malware was detected. No suspicious PowerShell executed. No endpoint alert triggered.

Yet within minutes, mailbox access changed, files were downloaded and an OAuth application appeared inside the tenant.

The evidence was not hiding in endpoint telemetry.

It was hiding inside CloudAppEvents.

Start Lesson 46 Back to Academy
Agent Foskett Academy lesson explaining CloudAppEvents in Microsoft Defender XDR
Lesson overview

Learn how CloudAppEvents helps defenders investigate what happened after access was granted inside Microsoft 365 and connected cloud applications.

Investigate cloud application activity
Identify suspicious OAuth consent events
Track SharePoint and OneDrive access
Build cloud attack timelines

Why CloudAppEvents matters

A successful sign-in tells you access was granted. CloudAppEvents helps you understand what the account did next.
The attacker may never touch an endpointModern attacks often target Microsoft 365 directly using OAuth abuse, mailbox access, cloud file access and application permissions.
Cloud activity leaves evidenceCloudAppEvents records actions performed inside Microsoft 365 and connected cloud services, giving defenders a place to look beyond the sign-in.
The attack timeline often starts hereMany business email compromise and cloud data exposure investigations are reconstructed by following CloudAppEvents activity in time order.

Investigation scenario

A user passed MFA and nothing looked obviously wrong. But the mailbox changed, files were accessed and an OAuth application appeared. The question was simple: what happened after the user got in?
The user reported nothing unusualThere were no obvious failed sign-ins, no malware detections and no suspicious endpoint process tree to follow.
The mailbox looked differentRules had changed, messages were disappearing and finance staff suspected that the account was being used for business email compromise.
Cloud activity became the focusAgent Foskett pivoted into CloudAppEvents to follow the actions that occurred after authentication succeeded.

Step 1 — Review recent cloud activity

Start with recent CloudAppEvents records and keep the fields that explain who acted, which application was involved, what action occurred and where it came from.
cloudappevents-recent-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
CloudAppEvents
| where Timestamp > ago(7d)
| project Timestamp, AccountDisplayName, AccountId, Application,
          ActionType, IPAddress, CountryCode, UserAgent
| order by Timestamp desc

Step 2 — Investigate one user

When one account becomes suspicious, place its activity into chronological order. The attacker story usually appears when events are read from oldest to newest.
cloudappevents-one-user-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
let User = "user@company.com";
CloudAppEvents
| where AccountDisplayName == User or AccountId == User
| project Timestamp, Application, ActionType, IPAddress,
          CountryCode, ObjectName, ObjectType, UserAgent
| order by Timestamp asc

Step 3 — Hunt OAuth consent activity

OAuth abuse can give an attacker persistent access without dropping malware or running PowerShell. Look for application consent and service principal activity.
cloudappevents-oauth-consent-hunt.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType has_any ("Consent", "Grant consent", "Add service principal", "Add app role assignment")
| project Timestamp, AccountDisplayName, Application, ActionType,
          IPAddress, ObjectName, ObjectType, RawEventData
| order by Timestamp desc

Step 4 — Investigate SharePoint activity

After account access, attackers often search SharePoint for finance records, customer files, contracts, HR data and sensitive project documents.
cloudappevents-sharepoint-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
CloudAppEvents
| where Timestamp > ago(14d)
| where Application contains "SharePoint"
| project Timestamp, AccountDisplayName, ActionType, IPAddress,
          CountryCode, ObjectName, ObjectType, UserAgent
| order by Timestamp desc

Step 5 — Investigate OneDrive activity

OneDrive activity can show whether the account accessed, downloaded, synchronised or shared files after the suspicious session began.
cloudappevents-onedrive-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
CloudAppEvents
| where Timestamp > ago(14d)
| where Application contains "OneDrive"
| project Timestamp, AccountDisplayName, ActionType, IPAddress,
          CountryCode, ObjectName, ObjectType, UserAgent
| order by Timestamp desc

Step 6 — Build the cloud attack timeline

The goal is not to prove that the user signed in. The goal is to explain what happened after the sign-in.
cloudappevents-build-attack-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
let User = "user@company.com";
CloudAppEvents
| where Timestamp between (ago(24h) .. now())
| where AccountDisplayName == User or AccountId == User
| project Timestamp, Application, ActionType, IPAddress,
          ObjectName, ObjectType, CountryCode
| order by Timestamp asc

What the timeline revealed

Once the events were ordered, the investigation stopped being a collection of alerts and became a story.
8:12 AM — The user passed MFAThe authentication looked normal enough to avoid immediate suspicion.
8:14 AM — OAuth consent appearedA cloud application received permissions shortly after the successful sign-in.
8:20 AM — Files were accessedSharePoint and OneDrive activity showed that the attacker moved straight into cloud data access.

Common investigation uses

CloudAppEvents is most useful when defenders need to move beyond authentication and understand the actions performed inside cloud services.
OAuth abuseInvestigate suspicious application consent, service principal changes and cloud application permission activity.
Business email compromiseReview mailbox-related cloud activity, unusual account actions and suspicious behaviour after a successful sign-in.
Data exposure and exfiltrationTrack SharePoint and OneDrive access, downloads, sharing activity and sensitive object access.

Common mistakes

Cloud investigations often fail when defenders treat MFA as the end of the story instead of the start of the timeline.
Only investigating sign-insAuthentication is important, but it does not explain what the account did once access was granted.
Ignoring OAuth applicationsAttackers increasingly target permissions instead of passwords, so application consent activity deserves careful review.
Stopping at MFAPassing MFA does not prove the activity was safe. It only proves the account successfully completed an authentication step.
The attacker did not need malware to create impact.
CloudAppEvents showed what happened after the account got in: consent, access, files and cloud actions.
Back to Academy →

What you learned

CloudAppEvents records cloud actionsYou can use it to investigate activity occurring inside Microsoft 365 and connected cloud applications.
OAuth abuse leaves evidenceConsent grants, application permission changes and service principal activity can help expose cloud persistence.
Timelines reveal attacker behaviourOrdering cloud activity often explains what happened after authentication and how the attacker used the account.

Related Agent Foskett Academy lessons

Investigating EmailEventsStart with email metadata when cloud compromise begins with phishing.
Investigating EmailUrlInfoReview URLs embedded in messages before following the cloud activity that came next.
Investigating UrlClickEventsConnect suspicious email links to user click behaviour and cloud access.
Investigating AlertEvidenceConnect alerts to users, files, IP addresses, cloud entities and related evidence.
Investigating IdentityLogonEventsReview authentication evidence before investigating what the account did next.
Investigating IdentityDirectoryEventsInvestigate account, group and directory changes connected to cloud activity.
Building Investigation TimelinesTurn cloud actions, sign-ins and alerts into a clear incident story.
Connecting Tables with joinJoin cloud events with identity, alert, email and endpoint telemetry.

Coming next

Lesson 47 — Investigating IdentityInfo in Microsoft Defender XDRNext, Agent Foskett Academy will move into IdentityInfo, helping defenders enrich investigations with account attributes, roles, groups and identity context.
Why this mattersCloud actions are easier to assess when defenders understand who the account belongs to and how much privilege it has.
What you will learn nextLearn how to use identity context to prioritise suspicious accounts and connect user details to sign-in, cloud app and alert evidence.

Final thought

The attacker did not bypass MFA. They abused what happened after MFA.
Agent Foskett mindsetThe important question is not: did the user successfully sign in? The important question is: what happened after they signed in?
Follow the cloud actionThe real impact of a compromised account is often found in the files, apps, permissions and cloud actions that followed authentication.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Investigating CloudAppEvents in Microsoft Defender XDR

Agent Foskett Academy Lesson 46 teaches defenders how to use CloudAppEvents to investigate OAuth abuse, Microsoft 365 activity, mailbox compromise, SharePoint access, OneDrive downloads and cloud-based attacker behaviour in Microsoft Defender XDR.

The user passed MFA but the attacker still got in

This lesson explains why defenders should not stop at successful authentication. CloudAppEvents helps reveal what happened after the sign-in, including application consent, file access, cloud actions and suspicious activity inside Microsoft 365.