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

Lesson 57 — The Cloud Alert Had No Endpoint Evidence

The incident looked suspicious.

A new OAuth application had appeared.
Cloud data had been accessed.
The account had activity from an unfamiliar location.

So the analyst opened the endpoint evidence.

Nothing.

No suspicious process.
No malicious file.
No PowerShell.
No device alert.

Agent Foskett looked at the evidence already on the screen.

“Who said every compromise has to touch the endpoint?”

The absence of endpoint evidence does not invalidate cloud evidence. Investigate where the activity actually occurred.

Investigate the Cloud-Only Incident Back to SOC Analyst Academy

Agent Foskett investigating a cloud incident with no endpoint evidence

Follow the evidence into the cloud

Build the incident from identity, application, session and Microsoft 365 workload telemetry when endpoint evidence is absent.

✓ Start with the cloud event

✓ Build the identity timeline

✓ Correlate application activity

✓ Scope cloud impact

Case briefing

08:42 — Unusual cloud sign-in context 08:49 — OAuth-related activity 09:03 — SharePoint access 09:07 — Multiple files accessed 09:12 — External sharing event ENDPOINT SEARCH: No suspicious process No malicious file No device alert No obvious execution chain INITIAL QUESTION: Does "no endpoint evidence" mean there was no compromise? NO. It means the investigation must follow the evidence that actually exists.

Investigation objective

Build a defensible incident using cloud and identity telemetry alone, while clearly documenting that endpoint evidence was searched for but not observed.

Investigator's rule

Missing evidence from one telemetry source is not evidence that nothing happened. State what was observed, what was not observed and what cannot be determined.

Stage 1 — stop waiting for an endpoint story

TRADITIONAL EXPECTATION Email ↓ Browser ↓ PowerShell ↓ Payload ↓ Persistence BUT THIS CASE MAY BE: Identity / session ↓ OAuth / cloud access ↓ SharePoint / OneDrive / Exchange ↓ Data access ↓ External sharing THE ATTACK CHAIN CAN EXIST ENTIRELY IN CLOUD SERVICES.

Endpoint evidence is valuable — when it exists

Device telemetry can explain phishing, token theft, malware or browser activity. But a cloud incident should not be forced into an endpoint narrative when the available evidence does not support one.

Document the negative finding

“No endpoint evidence observed” is useful when it accurately describes the search performed. It is different from saying “the endpoint was clean” or “the endpoint was not involved.”

Stage 2 — build the cloud timeline

12345678

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

Chronology replaces assumptions

Start with the first unusual cloud event and move forward. Authentication, consent, application activity, file access and sharing events can form a complete investigation chain.

Keep the raw context

Preserve RawEventData while the investigation is broad. Workload-specific identifiers and details may become important as the timeline develops.

Stage 3 — identify the evidence domains

Evidence domain	Questions to answer
Identity	Who authenticated, from where, with what session and authentication context?
Applications	Was an OAuth or enterprise application involved?
Exchange	Was mailbox data accessed or changed?
SharePoint / OneDrive	Were files opened, downloaded, modified or shared?
Directory	Were permissions, roles, credentials or objects changed?
Endpoint	Was relevant device evidence observed, absent or unavailable?

Think in evidence domains

A SOC investigation is not defined by one product or table. The analyst's job is to correlate the evidence domains that can answer the incident questions.

Availability matters

Different tenants retain different telemetry and licensing can affect what is available. Record evidence gaps instead of inventing certainty from data you do not have.

Stage 4 — establish identity context

08:42 — CLOUD IDENTITY EVENT ↓ ASK: Expected account? Expected IP? Expected country? Expected device context? Interactive or non-interactive? MFA context? Conditional Access context? Risk indicators? Known VPN / proxy? Existing session? Other accounts from same IP? ↓ IDENTITY CONTEXT BECOMES THE FIRST MAJOR PIVOT.

A location anomaly is not the verdict

VPNs, proxies and cloud security services can alter apparent location. Evaluate the IP and session in organisational context before labelling the authentication malicious.

Look for session continuity

Cloud activity may continue through an existing authenticated session or application relationship. A new interactive sign-in is not required before every cloud action.

Stage 5 — follow the account across cloud activity

1234567

CloudAppEvents
| where Timestamp > ago(7d)
| where AccountId =~ "alex@contoso.com"
| summarize
    Events = count(),
    Actions = make_set(ActionType, 100),
    IPs = make_set(IPAddress, 50),
    UserAgents = make_set(UserAgent, 50)
    by Application
| order by Events desc

Workload transitions matter

An identity event followed by OAuth activity, then file access and external sharing may be more meaningful than any one event considered separately.

Sequence creates the story

The SOC should be able to explain not only what happened, but the order in which the account moved through cloud services.

Stage 6 — explicitly test the endpoint hypothesis

HYPOTHESIS: A compromised endpoint caused the cloud activity. SEARCH FOR: Relevant device alerts Suspicious process execution Browser / script activity Malicious downloads Credential theft indicators Known device associated with the account RESULT: No relevant endpoint evidence observed within available telemetry. CORRECT CONCLUSION: The available endpoint telemetry does not currently explain the cloud activity. NOT: "The endpoint definitely was not involved."

Negative evidence needs boundaries

State the devices, time range and telemetry searched where useful. A defensible negative finding explains the limits of the search.

Absence and unavailability are different

If the user's device is unmanaged or not onboarded, you may have no endpoint telemetry at all. That is an evidence gap, not a clean result.

Stage 7 — scope the cloud impact

1234567

CloudAppEvents
| where Timestamp between
    (datetime(2026-09-03 08:30:00) ..
     datetime(2026-09-03 10:30:00))
| where AccountId =~ "alex@contoso.com"
| summarize Events = count(),
            Actions = make_set(ActionType, 100),
            Applications = make_set(Application, 50)
    by bin(Timestamp, 15m)
| order by Timestamp asc

Impact is a separate question

Even if the initial access mechanism remains uncertain, the SOC can often establish which cloud services and actions were affected.

Do not wait for perfect attribution

Containment may be justified by confirmed unauthorised cloud activity even while analysts continue investigating exactly how the session or application access was obtained.

Stage 8 — test competing hypotheses

Hypothesis	Evidence that may support it
Legitimate cloud activity	Known location or proxy, expected app, approved actions and user confirmation.
Compromised cloud session	Unexplained identity context followed by unauthorised cloud actions without endpoint evidence.
Malicious OAuth application	Suspicious consent or app relationship followed by cloud data access.
Compromised endpoint	Relevant device evidence connects endpoint activity to the cloud sequence.
Insufficient evidence	Cloud events are suspicious but the access mechanism cannot yet be established.

Keep mechanism and impact separate

You may know that sensitive files were accessed without yet knowing whether the attacker obtained a token, compromised a password, abused OAuth consent or used another path.

Uncertainty is allowed

A strong SOC finding can say that the initial access mechanism is undetermined while still documenting confirmed unauthorised cloud activity and required containment.

Stage 9 — build the evidence-weighted timeline

08:42 — Unusual identity context 08:49 — OAuth-related event 09:03 — SharePoint access 09:07 — Multiple files accessed 09:12 — External sharing 09:18 — Continued cloud activity ENDPOINT REVIEW: No relevant endpoint evidence observed ↓ CONFIRMED: Cloud activity occurred. SUPPORTED: Identity and application context are suspicious. NOT YET PROVEN: Exact initial-access mechanism.

The timeline can still be complete

A complete timeline does not require every unanswered question to disappear. It requires the analyst to distinguish confirmed events, supported interpretations and unresolved gaps.

Confidence should match evidence

Use language such as “confirmed,” “consistent with,” “not observed” and “undetermined” deliberately. Those words communicate the strength of each conclusion.

Stage 10 — containment questions

PRESERVE: Identity evidence Session context OAuth / application evidence Cloud workload activity Affected files / mailboxes Sharing events IP and user-agent context Endpoint search results Known telemetry gaps THEN FOLLOW APPROVED PROCEDURES FOR: Session revocation Credential remediation OAuth / app containment External-sharing removal Data exposure review Tenant-wide scoping Additional monitoring

Contain what you can prove

If the evidence supports unauthorised cloud access, response does not need to wait for malware to appear. Protect the identity, application relationship and exposed data according to incident procedures.

Keep hunting after containment

Containment protects the environment. Investigation continues to determine initial access, additional affected identities and whether the same infrastructure or application appears elsewhere.

Stage 11 — write the SOC finding

SOC FINDING Cloud telemetry identified suspicious activity for alex@contoso.com beginning at 08:42. The sequence included unusual identity context, OAuth-related activity, SharePoint access, multiple file operations and external sharing. Relevant endpoint telemetry was reviewed for the investigation window. No endpoint evidence was observed that explains the cloud activity. The available evidence supports unauthorised cloud activity and requires identity, application and data containment. The exact initial-access mechanism remains undetermined. The absence of observed endpoint evidence should not be interpreted as proof that an endpoint could not have been involved.

Lesson 57 key takeaways

Not every security incident produces endpoint evidence.
Cloud-only attack chains can involve identity, applications and Microsoft 365 workloads.
Do not force cloud evidence into an unsupported endpoint narrative.
Build the investigation chronologically from the evidence that exists.
Think in evidence domains rather than individual products.
Identity context is often the first major pivot in a cloud-only case.
No fresh interactive sign-in does not mean no cloud access occurred.
Document negative endpoint findings carefully and with appropriate boundaries.
No endpoint evidence observed is not the same as proving the endpoint was uninvolved.
Separate the initial-access mechanism from confirmed cloud impact.
It is acceptable for a final finding to retain uncertainty where evidence is incomplete.
Contain confirmed unauthorised cloud activity even while attribution continues.

Module 6 — Cloud & SaaS Incidents

Lesson 57 proved that a strong investigation can be built without endpoint evidence. Lesson 58 now follows one identity across Entra, Exchange and SharePoint to reconstruct a cross-service cloud incident.

Next: Lesson 58 — The Activity Crossed Entra, Exchange and SharePoint

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 56 — The Account Shared a Sensitive File Externally Investigate external sharing and exposure.

✅ Current lesson

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

Next lesson →

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

Investigate a Microsoft cloud incident with no endpoint evidence

Lesson 57 of the Agent Foskett SOC Analyst Academy teaches analysts how to build a defensible cloud-only security investigation using identity, OAuth application, SharePoint, OneDrive, Exchange and Microsoft 365 workload evidence.

Investigate cloud compromise with Microsoft Defender XDR and KQL

Learn how to document absent endpoint evidence without dismissing cloud telemetry, separate initial access from confirmed impact, test competing hypotheses and contain unauthorised Microsoft 365 activity while the exact access mechanism remains under investigation.