Lesson 39 — Cloud Investigation Playbook
A good cloud investigation should not depend on who happens to be on shift.
A repeatable playbook gives analysts a consistent sequence for validating alerts, identifying affected resources and identities, reviewing permissions and exposure, reconstructing timelines, checking related alerts and attack paths, preserving evidence, containing the threat and validating recovery.
This lesson brings together the entire Defender for Cloud investigation workflow into one operational playbook that can be followed, documented and improved over time.
What you will learn
This lesson converts Defender for Cloud investigation concepts into one repeatable operational workflow.
Cloud investigation playbook
↓
Validate the detection
↓
Identify the affected resource
↓
Identify the user, service principal or managed identity
↓
Review authentication and permissions
↓
Review cloud configuration and exposure
↓
Review Azure Activity Log and workload evidence
↓
Search for related alerts and entities
↓
Build the timeline
↓
Review recommendations and attack paths
↓
Determine scope and business impact
↓
Preserve evidence
↓
Contain, eradicate and recover
↓
Validate and document lessons learned
Investigation decision points
| Decision | Question | Outcome |
|---|---|---|
| Validation | Is the activity malicious, benign or unknown? | Classify and continue or close with evidence. |
| Priority | What is the business and security impact? | Set severity and escalation. |
| Scope | How many identities and resources are affected? | Expand or contain the investigation. |
| Containment | What action stops the threat safely? | Disable, isolate, rotate or restrict. |
| Recovery | Can the service be restored from trusted sources? | Rebuild, restore and validate. |
| Closure | Has access, persistence and residual risk been addressed? | Close or continue monitoring. |
Learning objectives
- Follow a repeatable cloud investigation workflow.
- Validate Defender alerts consistently.
- Identify affected resources and identities.
- Review permissions, exposure and configuration.
- Build an evidence-based timeline.
- Determine scope, contain the incident and recover safely.
- Document and improve the playbook.
Why use a playbook?
A playbook reduces missed steps, improves consistency, supports handover and helps analysts explain how conclusions were reached.
Investigation principles
Stay evidence-led, preserve uncertainty, separate fact from assumption and record every major decision.
Step 1 — Receive the alert
Record the alert title, severity, time, source, affected resource, subscription and current status.
Step 2 — Validate the alert
Determine whether the activity is true positive, benign positive, false positive or still undetermined.
Step 3 — Identify the resource
Confirm the exact resource ID, resource group, subscription, environment, business owner and criticality.
Step 4 — Identify the identity
Determine which user, service principal, managed identity, device or account performed the activity.
Step 5 — Review authentication
Review sign-ins, tokens, MFA, Conditional Access, device state, source IP and authentication method.
Step 6 — Review permissions
Check Azure RBAC, inherited roles, custom roles, PIM activation, app permissions and data-plane access.
Step 7 — Review cloud configuration
Inspect public exposure, firewalls, private endpoints, logging, Defender plans, extensions and recent configuration changes.
Step 8 — Review activity logs
Use Azure Activity Log to identify control-plane operations before, during and after the alert.
Step 9 — Review workload evidence
Use endpoint, storage, database, Key Vault, container, App Service or API telemetry according to the affected workload.
Step 10 — Review related alerts
Search for shared identities, IP addresses, resources, techniques and timestamps across Defender XDR and Sentinel.
Step 11 — Build the timeline
Normalise timestamps and arrange identity, resource, network, endpoint and alert evidence in order.
Step 12 — Review attack paths
Determine whether the activity connects to an exposed entry point, privileged identity or high-impact resource.
Step 13 — Determine scope
Identify every affected resource, subscription, identity, credential, data set and connected environment.
Step 14 — Preserve evidence
Export alerts, save logs, capture configurations, create snapshots and record evidence-handling details.
Step 15 — Contain
Disable identities, revoke sessions, rotate credentials, isolate workloads and restrict network access as required.
Step 16 — Eradicate
Remove persistence, malware, rogue resources, unsafe permissions and vulnerable configurations.
Step 17 — Recover
Restore trusted workloads, validate data and re-enable access gradually under heightened monitoring.
Step 18 — Close and improve
Document the root cause, impact, response, lessons learned and assigned improvement actions.
Alert severity
Use severity as a starting point, then adjust priority using asset criticality, identity privilege and business impact.
Detection source
Identify which Defender plan or Microsoft security product generated the alert and what evidence it can provide.
MITRE ATT&CK
Use tactics and techniques to organise attacker behaviour without assuming the complete attack chain is already known.
Resource ownership
Confirm the technical owner and business owner early so expected activity and operational impact can be validated.
Resource history
Review deployment, policy, networking, identity and configuration changes around the alert period.
User investigation
Review sign-ins, devices, risk, roles, authentication methods and recent administrative activity.
Service-principal investigation
Review app registrations, credentials, API permissions, consent, sign-ins and role assignments.
Managed-identity investigation
Identify the owning workload, token access, role assignments and downstream resources.
Privileged access
Review Owner, Contributor, User Access Administrator and custom privileged roles carefully.
PIM activity
Check privileged role activation, approval, duration and justification where PIM is used.
Public exposure
Review public IP addresses, open management ports, public storage, internet-facing applications and unrestricted database access.
Network paths
Review firewalls, NSGs, private endpoints, routing, peering and unusual outbound communication.
Secrets and credentials
Identify passwords, keys, certificates, tokens, SAS URLs and connection strings that may have been exposed.
Defender recommendations
Review recommendations affecting the resource, identity and attack path to identify contributing weaknesses.
Secure Score context
Use Secure Score to understand posture gaps, but do not let the score replace the incident evidence.
Attack-path context
Identify whether the alert sits within a route toward sensitive or privileged assets.
Azure Activity Log
Use Azure Activity Log for resource creation, deletion, role assignment, networking and configuration changes.
Microsoft Entra logs
Review sign-ins, audit activity, risky users, service principals and Conditional Access results.
Defender XDR evidence
Use the unified incident graph, timeline, assets and evidence to connect cloud, device, identity and email activity.
Microsoft Sentinel evidence
Use Sentinel for KQL hunting, third-party data, custom analytics, bookmarks and playbooks.
Endpoint evidence
Review process execution, file activity, network connections and logged-on users on affected devices.
Storage evidence
Review object access, downloads, uploads, SAS use, malware findings and public-access changes.
Key Vault evidence
Review secret, key and certificate operations, identity, source address and object versions.
Database evidence
Review authentication, queries, exports, schema access and unusual volume.
Container evidence
Review image digest, pod, namespace, service account, process execution and network activity.
App Service evidence
Review requests, processes, deployment history, SCM access, managed identity and outbound communication.
API evidence
Review endpoint, method, token, object identifier, response code, source and request sequence.
Timeline quality
Every timeline entry should include time, source, entity, action, result and evidence reference.
Scope expansion
Search for the same identity, IP address, credential, application or resource pattern across other environments.
Containment priority
Contain active attacker access first while preserving evidence and critical business operations.
Identity containment
Disable accounts, revoke sessions, remove permissions and rotate authentication methods.
Resource containment
Isolate machines, restrict apps, disable public access and block malicious workloads.
Credential containment
Rotate secrets, keys, certificates, passwords and deployment credentials.
Network containment
Block malicious sources and destinations and close unintended access paths.
Recovery validation
Confirm old credentials fail, clean workloads are deployed and monitoring remains healthy.
Closure criteria
Close only when cause, scope, containment and recovery are understood and follow-up actions are assigned.
Documentation
Record evidence, decisions, ownership, actions, timestamps, classification and business impact.
Handover
A clear playbook allows another analyst to continue without repeating the investigation.
Metrics
Track time to validate, contain and recover, together with missed evidence and repeated control failures.
Playbook maintenance
Update the playbook whenever products, portal experiences, logging sources or response actions change.
Common mistake: alert chasing
Do not investigate only the alert description. Follow resources, identities, permissions and activity.
Common mistake: missing identity context
Cloud incidents are often identity incidents. Always review users, service principals and managed identities.
Common mistake: missing permissions
An apparently small alert can become critical when the identity has broad inherited access.
Common mistake: closing too early
Stopping one action does not prove attacker access or persistence has been removed.
Common mistake: no evidence record
Without evidence references and timestamps, conclusions become difficult to defend or reproduce.
Agent Foskett investigation: “The first alert wasn’t the whole attack…”
↓
Agent Foskett recorded the resource, severity and timestamp
↓
The alert was validated as suspicious
↓
Azure Activity Log showed public access enabled earlier
↓
A service principal had made the change
↓
Entra logs showed the credential used from an unfamiliar host
↓
The service principal had Contributor access
↓
Defender XDR showed related endpoint activity
↓
Key Vault logs showed secret retrieval
↓
An attack path connected the service principal to production SQL
↓
Sentinel hunting found the same IP in another subscription
↓
The scope expanded to two subscriptions and three workloads
↓
Evidence was preserved
↓
The service principal was disabled
↓
Secrets were rotated and public access removed
↓
Clean workloads were redeployed
↓
Monitoring confirmed no further activity
↓
The first alert was not the whole attack
↓
It was simply where the investigation began
Cloud investigation checklist
| Check | Completed when | Evidence |
|---|---|---|
| Alert validation | The detection is classified with evidence. | Alert record and analyst notes. |
| Resource identification | The exact affected resource and owner are known. | Resource ID, tags and ownership record. |
| Identity identification | The acting identity and authentication path are known. | Entra and workload logs. |
| Permission review | Direct and inherited access is documented. | RBAC and app permissions. |
| Timeline | Events before, during and after the alert are ordered. | Timestamped evidence references. |
| Attack-path review | Potential movement to high-impact assets is assessed. | Attack-path analysis and recommendations. |
| Scope | All affected identities, resources and data are identified. | Cross-environment searches. |
| Containment | Attacker access is stopped and validated. | Response actions and retesting. |
| Recovery | Trusted services are restored and monitored. | Deployment, backup and health checks. |
| Lessons learned | Improvements have owners and due dates. | Post-incident action plan. |
Key takeaways
- A cloud investigation playbook creates consistent analyst behaviour.
- Start with the alert, but do not stop with the alert.
- Investigate resources, identities, authentication and permissions together.
- Use Azure Activity Log and workload-specific telemetry to build the timeline.
- Review recommendations and attack paths for exposure context.
- Expand scope using shared identities, credentials, IP addresses and resources.
- Preserve evidence before destructive containment.
- Contain identities, resources, credentials and network paths as required.
- Recovery requires trusted deployment and validation.
- The playbook should improve after every investigation.
What Agent Foskett checked
- Alert record
- Affected resource
- Resource owner
- User or workload identity
- Authentication method
- RBAC permissions
- Azure Activity Log
- Workload telemetry
- Related alerts
- Attack paths
- Containment status
- Recovery validation
Best practices
- Use one documented workflow.
- Record evidence references.
- Normalise timestamps.
- Review identity first.
- Check inherited permissions.
- Search before and after the alert.
- Preserve evidence.
- Validate containment.
- Assign follow-up actions.
- Update the playbook regularly.
Related Agent Foskett resources
Continue learning
What is a cloud investigation playbook?
A cloud investigation playbook is a repeatable workflow for validating alerts, investigating resources and identities, reviewing permissions and exposure, building timelines, determining scope, preserving evidence, containing threats and validating recovery.
Cloud Investigation Playbook Lesson
This Agent Foskett lesson explains alert validation, resource and identity investigation, Azure Activity Log, Defender XDR, Microsoft Sentinel, attack paths, containment, recovery and lessons learned.
