Agent Foskett Academy • Lesson 119 • Incident Response Workflow Series

Incident Response Workflow: Cloud Identity Attack.

There was no malware alert.

No ransomware note. No suspicious executable. No obvious endpoint compromise.

The attacker simply authenticated successfully, changed cloud identity settings and began moving through Microsoft 365 like a legitimate user.

Agent Foskett knew this was not an endpoint investigation. This was an attack against the organisation's cloud identity plane, and the evidence was spread across sign-ins, roles, Conditional Access, enterprise applications and Microsoft Defender XDR telemetry.

Start Lesson 119 Back to Academy

Agent Foskett Academy lesson cloud identity attack investigation in Microsoft Defender XDR

Lesson overview

Learn how to investigate a cloud identity attack by correlating Microsoft Defender XDR, Microsoft Entra ID identity telemetry, cloud activity, role changes, Conditional Access modifications and application activity.

Review suspicious authentication

Investigate role and policy changes

Analyse enterprise applications

Build a cloud identity attack timeline

Why cloud identity attacks matter

Cloud identity is the control plane for Microsoft 365. If an attacker controls identities, roles, applications or Conditional Access policies, they may not need malware to create serious business impact.

Identity is the perimeterModern attackers often target Microsoft Entra ID because a valid cloud identity can provide access to mail, files, applications, administration and cloud workloads.

Successful sign-ins can still be hostileA cloud identity attack may involve valid credentials, successful MFA and normal-looking access, which means defenders must validate behaviour rather than rely on failure alone.

Administrative changes matterRole assignments, Conditional Access changes, service principal activity and authentication method changes can reveal attacker control of the cloud identity plane.

The cloud identity attack workflow

Agent Foskett investigates cloud identity incidents by moving from authentication evidence to control-plane changes, application access and tenant-wide blast radius.

1. Identify the first signalStart with the alert, account, tenant, timestamp, IP address, location, risk status and affected workload.

2. Review authenticationAnalyse sign-in activity, locations, devices, MFA, risk detections and successful access patterns.

3. Review Entra changesLook for role assignments, group changes, authentication method changes, Conditional Access updates and account modifications.

4. Investigate applicationsReview enterprise applications, service principals, OAuth consent, API permissions and delegated access.

5. Correlate cloud activityPivot into Exchange, SharePoint, OneDrive, Teams and other cloud activity to understand what the attacker accessed.

6. Contain the control planeDisable compromised identities, revoke sessions, remove malicious roles or apps, restore policies and validate tenant recovery.

Step 1 — Review recent identity activity

Start by collecting recent sign-in activity for users involved in the incident.

let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ UserToInvestigate
| project Timestamp,
          AccountUpn,
          ActionType,
          IPAddress,
          Location,
          DeviceName,
          FailureReason
| order by Timestamp asc

Step 2 — Identify risky or unusual sign-in patterns

A cloud identity attack often begins with a successful sign-in from an unfamiliar location, IP address or device context.

let TimeFrame = 7d;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| summarize SignInCount = count(),
            Locations = make_set(Location, 20),
            IPAddresses = make_set(IPAddress, 50),
            Devices = make_set(DeviceName, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by AccountUpn
| where array_length(Locations) > 1 or array_length(IPAddresses) > 5
| order by SignInCount desc

Step 3 — Review cloud administration activity

Cloud identity attacks often involve changes to roles, policies, users, applications or security settings.

let TimeFrame = 14d;
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where ActionType has_any ("Add", "Update", "Set", "Assign", "Consent", "Policy", "Role")
| project Timestamp,
          AccountDisplayName,
          ActionType,
          Application,
          ObjectName,
          IPAddress,
          RawEventData
| order by Timestamp desc

Step 4 — Hunt for application and service principal activity

Service principals and enterprise applications can be used for persistence, automation and delegated access across Microsoft 365.

let TimeFrame = 30d;
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where RawEventData has_any ("ServicePrincipal", "AppId", "Consent", "OAuth", "Permission")
| project Timestamp,
          AccountDisplayName,
          ActionType,
          Application,
          ObjectName,
          IPAddress,
          RawEventData
| order by Timestamp desc

Step 5 — Correlate cloud activity after the identity event

Once suspicious access is identified, determine which Microsoft 365 services were accessed afterwards.

let TimeFrame = 7d;
let UserToInvestigate = "user@contoso.com";
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where AccountDisplayName has UserToInvestigate or AccountObjectId has UserToInvestigate
| summarize ActivityCount = count(),
            Applications = make_set(Application, 20),
            Actions = make_set(ActionType, 50),
            IPAddresses = make_set(IPAddress, 50),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by AccountDisplayName
| order by ActivityCount desc

Step 6 — Build the cloud identity attack timeline

A single timeline helps show when authentication occurred, when administration changed and what cloud activity followed.

let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
let SignIns =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ UserToInvestigate
    | project Timestamp, EventType="IdentityLogon", Account=AccountUpn, Detail=ActionType, IPAddress, Location;
let CloudActions =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountDisplayName has UserToInvestigate
    | project Timestamp, EventType="CloudAppEvent", Account=AccountDisplayName, Detail=ActionType, IPAddress, Location="";
union SignIns, CloudActions
| order by Timestamp asc

Common cloud identity attack clues

Cloud identity attacks are strongest when authentication, administration and application evidence all point in the same direction.

New privileged accessNew role assignments, PIM activations or privileged group membership changes can indicate escalation.

Policy changesConditional Access changes, excluded users or disabled controls may show an attempt to weaken the tenant.

Unfamiliar applicationsNew enterprise applications, service principals or OAuth consent events can provide persistent cloud access.

Authentication method changesNew MFA methods, changed phone numbers or altered recovery options can indicate identity takeover.

Cross-service accessMailbox, SharePoint, OneDrive and Teams activity after suspicious authentication helps determine impact.

Administrative activity from unusual IPsAdmin actions from unfamiliar regions, hosting providers or anonymising infrastructure deserve urgent review.

False positives to consider

Not every cloud identity change is malicious. Validate business context before containment disrupts legitimate administration.

Planned administrationSecurity teams may legitimately update Conditional Access, roles or enterprise applications during projects.

Helpdesk activityPassword resets, MFA changes and account recovery actions may be expected during support cases.

Managed service provider accessExternal IT partners may perform administrative actions from unfamiliar IP addresses.

Cloud application rolloutNew enterprise applications and consent grants may be part of approved SaaS deployments.

User travel or VPNAuthentication may look unusual when users travel or connect through shared VPN infrastructure.

Automation accountsSome role or application changes may be performed by approved automation, deployment or governance tools.

Investigation checklist

Use this checklist before closing a cloud identity attack investigation.

Review sign-insConfirm suspicious authentication, source IPs, locations, devices, MFA and risk signals.

Review Entra changesCheck roles, groups, authentication methods, users, policies and administrative changes.

Review applicationsInspect enterprise applications, service principals, OAuth consent and delegated permissions.

Review cloud activityDetermine which Microsoft 365 workloads were accessed after suspicious authentication.

Contain identity accessDisable compromised identities, revoke sessions and reset credentials where required.

Validate tenant recoveryConfirm malicious changes are removed, policies are restored and monitoring remains active.

Related Agent Foskett Academy lessons

These lessons support cloud identity attack investigations.

Hunting Playbook: Impossible TravelUse travel patterns and location analysis to validate suspicious authentication activity.

Hunting Playbook: OAuth AbuseInvestigate suspicious application consent, delegated permissions and persistent access.

Hunting Playbook: Risky Sign-insReview identity risk signals, sign-in behaviour and suspicious successful authentication.

Incident Response Workflow: Compromised User AccountInvestigate what happened after an attacker gained access to a user identity.

Incident Response Workflow: OAuth Application CompromiseInvestigate malicious application consent and cloud persistence.

Investigating IdentityLogonEventsUnderstand identity sign-in telemetry inside Microsoft Defender XDR.

Coming next

The Incident Response Workflow series finishes with a full Microsoft Defender XDR investigation.

Lesson 120 — Incident Response Workflow: Full Microsoft Defender XDR InvestigationNext, Agent Foskett brings together email, identity, endpoint, cloud activity, alerts and evidence into a complete end-to-end incident response workflow.

Why this mattersCloud identity attacks often touch every part of Microsoft 365. Lesson 120 shows how to combine all Defender XDR evidence into one investigation story.

Final thought

A cloud identity attack is not always loud. Sometimes the attacker simply changes the control plane and waits.

Agent Foskett mindsetDo not stop at the sign-in. Ask what changed after authentication, what access was granted and whether the tenant still behaves as expected.

Incident Response Workflow SeriesLesson 119 connects identity, Entra ID, cloud applications and Microsoft Defender XDR evidence into a repeatable cloud investigation workflow.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Incident Response Workflow Cloud Identity Attack in Microsoft Defender XDR

Agent Foskett Academy Lesson 119 teaches defenders how to investigate cloud identity attacks using Microsoft Defender XDR, Microsoft Entra ID, identity telemetry, cloud activity, role changes, Conditional Access changes and practical KQL hunting workflows.

Learn cloud identity attack investigation with KQL and Defender XDR

Cloud identity attack investigations help analysts validate suspicious authentication, privilege escalation, Conditional Access changes, enterprise application activity, service principals and Microsoft 365 access.

Microsoft Entra ID cloud identity incident response tutorial

This lesson explains how to investigate cloud identity compromise, suspicious sign-ins, role assignments, service principal activity, delegated permissions, cloud application access and tenant-level containment using Microsoft security telemetry.