Agent Foskett Academy • SOC Analyst Academy • Module 6 • Lesson 60 • Cloud & SaaS Incidents

Lesson 60 — Building the Complete Cloud Compromise Timeline

The investigation had evidence everywhere.

Microsoft Entra had the identity events.
An OAuth application had appeared.
Exchange had mailbox activity.
SharePoint had file access.
External sharing had occurred.

Every individual event was useful.

But the incident still did not make sense.

Agent Foskett opened a blank timeline.

“The logs already know what happened. We just need to put them in the right order.”

A cloud incident becomes understandable when isolated events are converted into a single evidence-backed sequence.

Build the Complete Timeline Back to SOC Analyst Academy

Agent Foskett building a complete Microsoft cloud compromise timeline

Follow the evidence across the cloud

Bring identity, applications, Exchange, SharePoint and data exposure into one defensible incident timeline.

✓ Establish the anchor event

✓ Correlate workloads

✓ Separate fact from inference

✓ Produce the final finding

Case briefing

ACCOUNT: alex@contoso.com 08:36 — Identity anomaly 08:43 — OAuth consent activity 08:51 — Application activity begins 09:02 — Exchange mailbox activity 09:14 — SharePoint access 09:21 — Bulk file activity 09:29 — External sharing event 09:37 — Continued application activity EVIDENCE EXISTS ACROSS: Microsoft Entra OAuth / applications Exchange SharePoint / OneDrive THE TASK: TURN SEPARATE EVENTS INTO ONE DEFENSIBLE CLOUD INCIDENT TIMELINE.

Investigation objective

Reconstruct the complete cloud incident by ordering identity, application, mailbox and file activity chronologically, identifying evidence gaps and distinguishing confirmed facts from supported interpretations.

Investigator's rule

The timeline is not a list of alerts. It is an evidence-backed reconstruction of what happened, in what order, and what each event means to the investigation.

Stage 1 — choose the investigation anchor

ALERT TIME: 09:29 — External sharing detected BUT EARLIER EVIDENCE EXISTS: 09:21 — Bulk file activity 09:14 — SharePoint access 09:02 — Mailbox activity 08:51 — Application activity 08:43 — OAuth consent 08:36 — Identity anomaly THE ALERT IS WHERE THE INVESTIGATION STARTED. IT IS NOT NECESSARILY WHERE THE INCIDENT STARTED.

Work backwards before moving forwards

Once an alert identifies suspicious activity, search earlier for authentication, consent, session, application or reconnaissance events that may explain how the activity became possible.

Do not invent “initial access”

The earliest event you can find is the earliest observed event in available telemetry. Call it initial access only when the evidence genuinely establishes that conclusion.

Stage 2 — collect the cloud activity

12345678

CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "alex@contoso.com"
| project Timestamp,
          AccountId,
          Application,
          ActionType,
          IPAddress,
          UserAgent,
          RawEventData
| order by Timestamp asc

Start broad

At the beginning of timeline construction, avoid filtering so aggressively that important transitions disappear. Understand the account's complete cloud sequence before narrowing the investigation.

Preserve raw evidence

Raw workload details can contain identifiers, objects, recipients and other context needed later. Keep them available while you determine which events matter.

Stage 3 — classify each event

Timeline event	Evidence domain	Meaning
Unusual authentication context	Identity	Potential access or session concern
OAuth consent / grant	Application	Potential new cloud capability
Application activity	Application	Observed use of application access
Mailbox activity	Exchange	Email data or configuration interaction
File access	SharePoint / OneDrive	Cloud data interaction
External sharing	SharePoint / OneDrive	Potential external exposure

Events need meaning

A timestamp and action name are not enough. Add the investigative significance of each event without overstating what it proves.

Capability is not impact

A permission grant may create the ability to access data. Later workload events are needed to establish whether that capability was actually used.

Stage 4 — connect the identity to the application

08:36 Identity anomaly ↓ 08:43 OAuth consent / grant ↓ 08:51 Application activity QUESTIONS: Who granted consent? Which application? Which permissions? Delegated or application context? Was the application previously known? Was the consent expected? Did activity begin after the grant? THE ORDER MATTERS.

Consent may be the persistence point

If suspicious application access follows consent, investigate whether the permission relationship allowed cloud activity to continue independently of normal interactive user behaviour.

Do not call every app malicious

Approved business applications can exhibit background activity. Application identity, permissions, history, ownership and business context must support the verdict.

Stage 5 — connect the application to workload impact

1234567

CloudAppEvents
| where Timestamp between
    (datetime(2026-09-03 08:30:00) ..
     datetime(2026-09-03 10:00:00))
| where AccountId =~ "alex@contoso.com"
| summarize
    Events = count(),
    Actions = make_set(ActionType, 100),
    IPs = make_set(IPAddress, 50),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by Application
| order by FirstSeen asc

Watch the workload progression

Exchange followed by SharePoint may show an actor moving from information gathering into data access. The sequence can reveal objectives even when individual actions appear ordinary.

Separate observed use from possible use

Permissions tell you what an application or identity could potentially do. Workload telemetry tells you what the available evidence shows it actually did.

Stage 6 — build the master timeline

08:36 — ENTRA Unusual identity context ↓ 7m 08:43 — APPLICATION OAuth consent / grant observed ↓ 8m 08:51 — APPLICATION Application-related activity begins ↓ 11m 09:02 — EXCHANGE Mailbox activity ↓ 12m 09:14 — SHAREPOINT Sensitive site accessed ↓ 7m 09:21 — SHAREPOINT High-volume file activity ↓ 8m 09:29 — SHAREPOINT External sharing created ↓ 8m 09:37 — APPLICATION Cloud activity continues ONE ACCOUNT. MULTIPLE SERVICES. ONE EVIDENCE-BACKED SEQUENCE.

The timeline exposes transitions

The important story is often found between events: authentication becomes application access, application access becomes mailbox activity, and mailbox activity becomes data access.

Measure the gaps

Minutes between related events can strengthen a hypothesis. Long unexplained gaps may require broader searching or may indicate that apparently related events are actually independent.

Stage 7 — label evidence confidence

Language	Use it when
Confirmed	The telemetry directly establishes the event.
Supports	Multiple observations make an explanation more likely.
Consistent with	The evidence fits an explanation but does not prove it.
Not observed	You searched relevant available evidence and did not find the activity.
Undetermined	The available evidence cannot currently answer the question.

Confidence belongs in the timeline

Analysts should know which events are direct facts and which statements are interpretation. This prevents assumptions from becoming “facts” as the incident is handed between teams.

Unknown is a valid state

A timeline does not become weak because some questions remain unresolved. It becomes weak when uncertainty is hidden.

Stage 8 — test the complete incident hypothesis

HYPOTHESIS: The account was compromised, a cloud application relationship was established, and access then moved through Microsoft 365 services to sensitive data. SUPPORTING EVIDENCE: Identity anomaly Consent / application event Post-consent application activity Mailbox activity SharePoint access Bulk file activity External sharing STILL ASK: Was the initial identity event malicious? Was the application approved? Was the data activity authorised? Was external access actually used? Were other accounts affected?

A coherent story is not automatically a true story

A timeline may fit a compromise hypothesis beautifully. Continue testing legitimate explanations and contradictory evidence before finalising the verdict.

Look for evidence that breaks your theory

Good investigators actively search for facts that would disprove their preferred explanation. That is one of the best defences against confirmation bias.

Stage 9 — scope beyond the original account

1234567

CloudAppEvents
| where Timestamp > ago(7d)
| where IPAddress == "203.0.113.25"
| summarize
    Accounts = make_set(AccountId, 100),
    Applications = make_set(Application, 50),
    Actions = make_set(ActionType, 100),
    Events = count()
| project Events, Accounts, Applications, Actions

Pivot on shared infrastructure

Suspicious IP addresses, application identities, recipients and other entities can reveal whether the activity extends beyond the original account.

Use example indicators carefully

The IP in this training query is documentation-only example space. In a real investigation, substitute evidence from the incident and validate its organisational context.

Stage 10 — establish impact separately

ACCESS: Was the identity / session unauthorised? PERSISTENCE: Was an application or permission relationship created? MAIL: What Exchange activity occurred? DATA: Which SharePoint / OneDrive resources were touched? EXPOSURE: Were files downloaded or shared externally? SCOPE: Were other identities or resources affected? IMPACT IS NOT ONE NUMBER. IT IS A SET OF EVIDENCE-BACKED FINDINGS.

Initial access and impact are different problems

You may never fully prove how an attacker first obtained access, yet still have strong evidence of what happened after access was established.

Do not let one unknown erase ten knowns

An unresolved access mechanism should be documented, but it should not prevent the SOC from reporting confirmed mailbox, application or data activity.

Stage 11 — preserve the evidence before containment

PRESERVE: Identity / sign-in context Session evidence OAuth consent / grants Application identifiers Permissions Exchange activity SharePoint / OneDrive activity Files / resources involved External sharing details IP / user-agent context Affected accounts Timeline timestamps Known evidence gaps THEN FOLLOW APPROVED PROCEDURES FOR: Identity containment Session revocation Application / grant remediation External-sharing removal Data exposure response Tenant-wide scoping

Containment changes the environment

Removing grants, revoking sessions or deleting sharing relationships can alter the evidence available to later investigators. Preserve what your procedures require before remediation.

The timeline should survive containment

Another analyst should be able to understand what happened even after the malicious or risky state has been removed.

Stage 12 — write the final incident finding

FINAL SOC FINDING At 08:36, alex@contoso.com generated an identity event with context inconsistent with the account's established activity. At 08:43, OAuth consent activity was observed, followed by application-related cloud activity beginning at 08:51. The account subsequently performed Exchange activity at 09:02 and accessed sensitive SharePoint resources from 09:14. High-volume file activity occurred at 09:21, followed by an external sharing event at 09:29. The timing and common identity support treating these events as one cross-service cloud incident. The evidence confirms application and Microsoft 365 data activity. The exact initial-access mechanism remains undetermined. Containment should address the affected identity, active sessions, application permissions and external data exposure while related accounts and infrastructure are scoped.

Lesson 60 key takeaways

The alert is where the investigation started, not necessarily where the incident started.
Build the timeline both backwards and forwards from the anchor event.
Do not label the earliest observed event as initial access without evidence.
Correlate identity, application, Exchange and SharePoint activity chronologically.
Classify what each event means to the investigation.
Separate capability from observed impact.
Use workload transitions to understand attacker objectives.
Label confirmed facts, supported interpretations and unresolved questions clearly.
Search for evidence that contradicts your leading hypothesis.
Scope beyond the original account using shared entities and infrastructure.
Establish impact even when the exact access mechanism remains unknown.
Preserve evidence before containment changes the environment.
A defensible timeline should allow another analyst to reconstruct the incident.

Module 6 complete — Cloud & SaaS Incidents

You have now investigated unusual cloud downloads, location anomalies, bulk data access, OAuth consent, non-interactive application activity, external sharing, cloud-only incidents, cross-service activity, attribution problems and finally the complete cloud compromise timeline.

Module 6 Complete — 10 Cloud & SaaS investigations finished.

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 6: Cloud & SaaS Incidents

Module 6 complete — investigate cloud activity by correlating identities, applications, permissions, sessions and Microsoft 365 workload evidence.

← Previous lesson

Lesson 59 — Was This Insider Activity or Account Compromise? Compare competing hypotheses using evidence.

✅ Current lesson

Lesson 60 — Building the Complete Cloud Compromise Timeline Create a defensible cross-service timeline.

Next lesson →

Lesson 61 — The Investigation Became an Incident Recognise the transition from analysis to coordinated response. Module 6 — Cloud & SaaS Incidents Ten cloud investigation lessons completed.

Build a complete Microsoft cloud compromise timeline

Lesson 60 of the Agent Foskett SOC Analyst Academy teaches analysts how to correlate Microsoft Entra identity evidence, OAuth application activity, Exchange events and SharePoint or OneDrive data access into one defensible cloud incident timeline.

Investigate cross-service Microsoft 365 compromise with Microsoft Defender XDR and KQL

Learn how to identify anchor events, work backwards and forwards through cloud telemetry, distinguish capability from observed impact, label evidence confidence, scope related infrastructure and preserve evidence before containment.