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

Lesson 58 — The Activity Crossed Entra, Exchange and SharePoint

The first alert was about identity.

A suspicious sign-in appeared in Microsoft Entra.

Then Exchange showed mailbox activity.
A few minutes later, SharePoint showed file access.

Three services.
Three sets of evidence.
One account.

Agent Foskett opened the timeline.

“Stop investigating the products separately. Follow the identity.”

The incident is the sequence of activity — not the individual product alerts.

Build the Cross-Service Timeline Back to SOC Analyst Academy

Agent Foskett correlating Microsoft Entra Exchange and SharePoint cloud evidence

One identity. Multiple workloads.

Correlate authentication, mailbox and file activity to reconstruct what the account actually did.

✓ Anchor on the identity

✓ Correlate timestamps

✓ Follow workload transitions

✓ Build one incident timeline

Case briefing

07:58 — Microsoft Entra Unusual sign-in context 08:04 — Exchange Mailbox activity begins 08:11 — Exchange Message / mailbox actions observed 08:18 — SharePoint Sensitive site accessed 08:24 — SharePoint Multiple files accessed 08:31 — SharePoint External sharing activity THREE WORKLOADS. ONE ACCOUNT: jordan@contoso.com THE INVESTIGATION QUESTION: Is this three unrelated events? Or one cloud incident moving across services?

Investigation objective

Follow one identity across Microsoft Entra, Exchange and SharePoint, correlate the activity by time and context, and determine whether separate workload events form one coherent incident.

Investigator's rule

Do not let product boundaries become investigation boundaries. Attackers use identities and permissions; analysts must correlate the resulting evidence across services.

Stage 1 — anchor on the identity

jordan@contoso.com │ ├── ENTRA │ Authentication / session context │ ├── EXCHANGE │ Mailbox activity │ └── SHAREPOINT File and sharing activity THE ACCOUNT IS THE COMMON ENTITY. START THERE.

Why identity is the best pivot

Applications and workloads may change during an incident, but the same compromised identity can appear across all of them. The account gives the analyst a common thread.

Normalise what you can

Record timestamps, account identifiers, IP addresses, applications, actions and session context consistently so events from different evidence sources can be compared.

Stage 2 — establish the Entra starting point

07:58 — IDENTITY EVENT ACCOUNT: jordan@contoso.com ASK: Was the authentication expected? Was the IP familiar? Was the location explainable? Was MFA involved? Was Conditional Access applied? Was the device familiar? Was this interactive or non-interactive? Was an existing session involved? DO NOT START WITH: "THE SIGN-IN WAS MALICIOUS." START WITH: "WHAT DOES THE AUTHENTICATION EVIDENCE SHOW?"

The first event is not always initial access

The earliest event visible in your investigation may only be the first event you can currently see. Avoid claiming initial access unless the evidence establishes it.

Capture the identity context

The IP, device context, authentication method, session and risk indicators become comparison points when activity appears in other cloud workloads.

Stage 3 — follow the account into Exchange

12345678

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

Do not search only for “bad” actions

Begin broadly enough to understand what the account did. Ordinary-looking mailbox actions can become important when they occur immediately after suspicious authentication.

Preserve workload detail

Exact Exchange actions and fields vary by telemetry. Keep the raw event context while you identify mailbox access, configuration changes, message activity or other relevant behaviour.

Stage 4 — ask what Exchange added to the story

Exchange evidence	Investigation question
Mailbox access	Did the account access mail immediately after the identity event?
Message activity	Were messages read, searched, sent or otherwise acted upon?
Mailbox configuration	Were forwarding, rules or other settings changed?
IP / client context	Does it align with the identity evidence?
Timing	Does the sequence connect naturally to the preceding authentication?

Correlation is stronger than coincidence

The same account appearing across services is useful. The same account, close timestamps, matching infrastructure and related actions create a much stronger connection.

Do not overstate missing fields

Different workloads may not expose identical identifiers. Correlate using the strongest available combination of account, time, IP, client, session and behaviour.

Stage 5 — follow the identity into SharePoint

1234567

CloudAppEvents
| where Timestamp between
    (datetime(2026-09-03 07:45:00) ..
     datetime(2026-09-03 09:00:00))
| where AccountId =~ "jordan@contoso.com"
| where Application has_any ("SharePoint", "OneDrive")
| project Timestamp,
          Application,
          ActionType,
          IPAddress,
          RawEventData
| order by Timestamp asc

Now the incident changes shape

The investigation has moved from authentication to mailbox activity and then into data access. The sequence may indicate a single actor using the same identity for different objectives.

Identify the resources touched

Determine which sites, libraries or files were involved where telemetry permits. Business sensitivity and resource ownership help establish impact.

Stage 6 — build one cross-service timeline

07:58 — ENTRA Unusual authentication context ↓ 6 minutes 08:04 — EXCHANGE Mailbox activity begins ↓ 7 minutes 08:11 — EXCHANGE Additional mailbox actions ↓ 7 minutes 08:18 — SHAREPOINT Sensitive site accessed ↓ 6 minutes 08:24 — SHAREPOINT Multiple files accessed ↓ 7 minutes 08:31 — SHAREPOINT External sharing event NOW ASK: DOES THIS SEQUENCE MAKE SENSE AS ONE INCIDENT?

Time is your correlation engine

Close temporal proximity does not prove causation, but it helps establish whether events plausibly belong to the same sequence. Combine time with identity and contextual evidence.

Look for transitions

The transition from identity to email to files may reveal attacker objectives: establish access, gather information, locate sensitive data and create exposure.

Stage 7 — compare infrastructure and client context

ENTRA: IP A Client / device context X EXCHANGE: IP A? Client context X? Same time window? SHAREPOINT: IP A? Related session? Same user agent? Different infrastructure? MATCHES STRENGTHEN CORRELATION. DIFFERENCES CREATE NEW QUESTIONS.

A changed IP does not automatically break the chain

Cloud infrastructure, proxies, VPNs and session behaviour can complicate IP correlation. Treat network context as one evidence dimension rather than the sole identifier.

A matching IP does not prove the same actor

Shared egress and proxy infrastructure can place many users behind one address. Correlate IP evidence with identity, client, session and behaviour.

Stage 8 — summarise workload activity

1234567

CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "jordan@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

Summaries expose the shape

A workload summary helps identify where the account was active, when each service entered the timeline and which actions deserve deeper investigation.

Then return to individual events

Aggregation is excellent for orientation but can hide sequence and detail. Use it to find pivots, then inspect the underlying events.

Stage 9 — test competing explanations

Hypothesis	Evidence that may support it
Normal user workflow	Expected authentication, normal mailbox use, expected SharePoint access and confirmed business activity.
Account compromise	Suspicious identity context followed by unexplained activity across multiple workloads.
Application-driven activity	Actions are attributable to an approved or suspicious application rather than direct human interaction.
Multiple unrelated events	Different context, unrelated timing and independent business explanations for each workload.
Insufficient evidence	Events correlate partially but not strongly enough to establish one actor or incident.

Do not merge incidents just because you can

Correlation should be evidence-driven. If two events cannot be connected beyond sharing the same account, retain uncertainty and continue investigating.

Do not split incidents because products did

Separate alerts from Entra, Exchange and SharePoint may still represent one continuous compromise. The SOC timeline should reflect the evidence, not the product boundaries.

Stage 10 — establish impact

IDENTITY Suspicious authentication ↓ EXCHANGE Mailbox accessed ↓ SHAREPOINT Sensitive files accessed ↓ SHARING External access created IMPACT QUESTIONS: What mailbox data was exposed? Which files were accessed? Were files downloaded? Was anything shared externally? Did the actor change persistence? Were other users touched? How long did access continue?

Impact may span services

Do not close the case after confirming the sign-in. A compromised identity may expose email, files, contacts, internal information and cloud permissions across the tenant.

Scope outward from the common entities

Use the account, suspicious IPs, applications, recipients and affected resources to determine whether the activity extends beyond the original identity.

Stage 11 — write the cross-service finding

SOC FINDING At 07:58, jordan@contoso.com generated an identity event with authentication context inconsistent with the user's established activity. Beginning at 08:04, the same account performed Exchange activity, followed at 08:18 by SharePoint access and subsequent activity involving sensitive files. The timing, common identity and supporting context indicate that the events should be investigated as one cross-service incident rather than independent workload alerts. The evidence establishes activity across Entra, Exchange and SharePoint. Further response should scope mailbox and file impact, contain the affected identity and investigate whether additional accounts, applications or resources were involved.

Lesson 58 key takeaways

Product boundaries should not become investigation boundaries.
The identity is often the strongest pivot across Microsoft cloud workloads.
Build one chronological timeline from Entra, Exchange and SharePoint evidence.
The earliest visible event is not automatically the initial-access event.
Correlate account, time, IP, client, session and behaviour where available.
Close timestamps strengthen correlation but do not prove causation alone.
Matching IP addresses require context because shared egress is common.
Different IP addresses do not automatically mean unrelated activity.
Use aggregation to understand the shape of activity, then inspect individual events.
Do not merge unrelated events without sufficient evidence.
Do not split one incident simply because separate products generated the alerts.
Assess impact across every cloud service the identity touched.

Module 6 — Cloud & SaaS Incidents

Lesson 58 followed one identity across Microsoft Entra, Exchange and SharePoint. Lesson 59 now makes the attribution problem harder: was the unusual cloud activity performed by the legitimate employee or by someone using their account?

Next: Lesson 59 — Was This Insider Activity or Account Compromise?

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

Investigate cloud activity by correlating identities, applications, permissions, sessions and Microsoft 365 workload evidence.

← Previous lesson

Lesson 57 — The Cloud Alert Had No Endpoint Evidence Work an incident where evidence exists only in cloud services.

✅ Current lesson

Lesson 58 — The Activity Crossed Entra, Exchange and SharePoint Follow one identity across Microsoft cloud workloads.

Next lesson →

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

Correlate Microsoft Entra, Exchange and SharePoint security evidence

Lesson 58 of the Agent Foskett SOC Analyst Academy teaches analysts how to follow one identity across Microsoft Entra, Exchange and SharePoint and reconstruct a cross-service Microsoft 365 security incident.

Build a cross-workload cloud incident timeline with Microsoft Defender XDR and KQL

Learn how to correlate account, timestamp, IP, client and application context across cloud workloads, distinguish one continuous compromise from unrelated events and assess impact across email and file services.