Lesson 36 — Cloud Incident Response
Stopping suspicious activity is only one part of incident response.
A complete cloud response prepares the organisation before an incident, detects and analyses activity, contains affected identities and resources, removes persistence, restores trusted services, preserves evidence and improves the environment afterwards.
This lesson explains the cloud incident-response lifecycle, the roles involved, the evidence that must be protected, the containment choices available across identities and workloads, and the validation required before an incident can be closed.
What you will learn
This lesson follows the full cloud incident lifecycle from preparation through recovery and lessons learned.
Cloud incident-response lifecycle
↓
Detect suspicious activity
↓
Analyse alerts, identities, resources and business impact
↓
Declare and prioritise the incident
↓
Preserve evidence
↓
Contain identities, workloads, credentials and network paths
↓
Eradicate malware, persistence and vulnerable configurations
↓
Restore trusted services and data
↓
Validate identities, networking, logging and monitoring
↓
Close the incident
↓
Complete lessons learned and control improvements
Incident-response phases
| Phase | Primary objective | Example action |
|---|---|---|
| Preparation | Be ready before the incident. | Test emergency access and logging. |
| Detection and analysis | Understand what happened and the impact. | Correlate Defender alerts and identity activity. |
| Containment | Stop or limit attacker activity. | Disable a compromised service principal. |
| Eradication | Remove attacker access and persistence. | Delete rogue credentials and patch the exploit. |
| Recovery | Restore trusted business operations. | Redeploy from a known-good build. |
| Lessons learned | Prevent recurrence and improve response. | Update policy, monitoring and playbooks. |
Learning objectives
- Explain the cloud incident-response lifecycle.
- Prepare roles, tools and evidence sources.
- Contain identities, resources and credentials.
- Eradicate attacker access and persistence.
- Recover trusted services safely.
- Preserve evidence and document actions.
- Improve controls after the incident.
What is cloud incident response?
Cloud incident response is the coordinated process used to prepare for, detect, analyse, contain, eradicate, recover from and learn from security incidents affecting cloud resources and identities.
Why cloud response is different
Cloud environments are highly dynamic, identity-driven and API-controlled. An attacker can create, modify or delete resources quickly without touching a traditional server console.
Shared responsibility
Microsoft secures the underlying cloud platform, while customers remain responsible for their identities, data, configurations, applications and incident-response decisions.
Preparation
Preparation establishes roles, permissions, communication channels, evidence sources, response playbooks and tested containment procedures before an incident occurs.
Detection
Detection can originate from Defender for Cloud, Defender XDR, Microsoft Sentinel, Azure Monitor, identity alerts, workload logs or user reports.
Analysis
Analysis determines whether the alert is malicious, what happened, which assets are affected and how the activity relates to business impact.
Containment
Containment stops or limits attacker activity while preserving evidence and maintaining essential services where possible.
Eradication
Eradication removes malware, persistence, exposed credentials, rogue resources, vulnerable code and unauthorised access paths.
Recovery
Recovery restores trusted services, validates configuration and gradually returns workloads to normal operation.
Lessons learned
Post-incident review identifies what failed, what worked and which security, governance and response controls must improve.
Incident declaration
Declare an incident when malicious activity, significant business impact or coordinated response requires formal ownership and tracking.
Incident severity
Set severity using threat activity, affected assets, sensitive data, business impact, regulatory obligations and attacker persistence.
Incident commander
The incident commander coordinates decisions, priorities, communication and ownership across technical and business teams.
SOC role
The SOC maintains the alert timeline, investigates evidence, tracks entities and coordinates security-response actions.
Cloud platform team
The cloud platform team supports subscription access, networking, identity assignments, policy, resource configuration and recovery.
Application team
Application owners investigate code, deployment pipelines, dependencies, data flow and customer impact.
Identity team
Identity specialists review sign-ins, Conditional Access, privileged roles, service principals, sessions and credential exposure.
Legal and privacy
Legal and privacy teams assess notification, evidence-handling, contractual and regulatory obligations.
Communications
Communications teams coordinate accurate internal, customer and external messaging when required.
Access preparation
Response teams need pre-approved emergency access that is tightly controlled, monitored and tested.
Break-glass accounts
Emergency accounts should be protected, excluded only from policies that would prevent emergency use and monitored for every sign-in.
Response permissions
Define who can isolate resources, revoke credentials, change firewall rules, access logs and restore services.
Logging preparation
Retain identity, Activity Log, resource, network, endpoint, application and security telemetry long enough for investigation.
Time synchronisation
Normalise timestamps across portals, logs and external systems before reconstructing the incident.
Evidence integrity
Record who collected evidence, when it was collected and how it was stored to support trustworthy analysis.
Defender for Cloud alerts
Use Defender alerts to identify the suspicious activity, affected resource, evidence and recommended actions.
Defender for Cloud incidents
Security incidents can correlate alerts affecting multiple resources and help reveal a broader attack story.
Defender XDR incidents
Defender XDR can correlate cloud, endpoint, identity, email and application evidence into unified incidents.
Microsoft Sentinel
Microsoft Sentinel can centralise incidents, analytics, hunting, automation and long-term cross-platform telemetry.
Initial triage
Confirm the alert, affected resource, identity, source, time range, business owner and whether active attacker behaviour continues.
Scope assessment
Identify every affected identity, subscription, resource, credential, data set and connected environment.
Timeline
Build a timeline from first known access through containment and recovery, preserving uncertainty where facts are incomplete.
Root cause
Identify the initial access path and the control failure that allowed the incident to begin.
Persistence
Search for new credentials, role assignments, service principals, automation, scheduled tasks, startup changes, web shells and hidden resources.
Lateral movement
Review how identities, permissions, secrets and network relationships allowed movement between workloads.
Data impact
Determine whether data was accessed, changed, deleted, encrypted or exfiltrated.
Identity containment
Disable compromised users, revoke sessions, reset authentication methods and remove privileged assignments.
Service-principal containment
Disable or restrict compromised applications, remove credentials, revoke consent and review API permissions.
Managed-identity containment
Remove role assignments, stop the owning workload or isolate it until the identity can no longer be abused.
Credential rotation
Rotate exposed passwords, keys, secrets, certificates, SAS tokens, connection strings and publishing credentials.
Virtual-machine containment
Isolate the VM, block network access, preserve disks or snapshots and prevent further credential use.
Storage containment
Disable public access, revoke SAS tokens, rotate keys, quarantine malicious files and restrict network paths.
Database containment
Disable compromised users, rotate credentials, restrict connectivity and preserve query and audit evidence.
Container containment
Isolate or remove compromised pods, block malicious image digests, revoke service accounts and redeploy from trusted images.
App Service containment
Restrict the affected app or slot, rotate deployment credentials and redeploy a trusted patched build.
Key Vault containment
Restrict the compromised identity, rotate exposed objects and review every secret, key or certificate accessed.
Network containment
Block malicious addresses, remove public exposure, tighten firewall rules and restrict east-west communication.
Preserve before deleting
Do not remove a compromised resource before collecting required logs, snapshots, files and configuration evidence.
Snapshots
Snapshots can preserve disk state for later analysis, but access and handling should follow the incident evidence process.
Export configuration
Preserve resource definitions, role assignments, network rules, policy assignments and deployment history.
Threat intelligence
Record indicators such as IP addresses, domains, hashes, user agents, certificates and attacker-controlled applications.
Eradicate malware
Remove malicious software and persistence, then rebuild from trusted sources where confidence in cleanup is limited.
Patch vulnerabilities
Correct the exploited vulnerability before restoring normal access.
Remove rogue resources
Delete unauthorised VMs, identities, keys, automation, forwarding rules and persistence after evidence is preserved.
Review attack paths
Confirm that the incident did not reveal additional routes toward other high-impact resources.
Recovery planning
Define which services return first, which controls must be verified and how increased monitoring will be maintained.
Trusted rebuild
Prefer redeployment from known-good images, code and infrastructure templates rather than relying solely on manual cleanup.
Restore data
Restore from validated backups when data was deleted, encrypted or modified.
Validate identities
Confirm only approved users, service principals and managed identities retain required permissions.
Validate networking
Confirm public access, firewalls, private endpoints and segmentation match the secure design.
Validate logging
Ensure alerting and telemetry remain active after restoration and that no evidence source was lost during recovery.
Heightened monitoring
Monitor affected identities, resources and indicators closely after recovery for signs of recurrence.
Automation rules
Microsoft Sentinel automation rules can update incidents, assign ownership and trigger response workflows.
Playbooks
Sentinel playbooks use Azure Logic Apps to automate actions such as enrichment, notification, isolation and credential response.
Human approval
High-impact automated actions should use approval gates when a false action could disrupt critical services.
Communication log
Record decisions, notifications, approvals and status updates throughout the incident.
Regulatory notification
Assess whether affected data, jurisdictions or contracts require notification within a defined timeframe.
Customer communication
Communicate verified impact, protective actions and required customer steps without speculation.
Closure criteria
Close the incident only when attacker access is removed, persistence is addressed, recovery is validated and follow-up actions have owners.
Post-incident review
Review detection gaps, response delays, missing telemetry, unclear ownership and opportunities for automation.
Metrics
Track time to detect, time to contain, time to recover, affected assets, repeated control failures and overdue improvements.
Playbook improvement
Update response playbooks with the evidence sources, commands, permissions and decisions learned during the incident.
Agent Foskett investigation: “The attack had stopped…”
↓
The incident-response process was activated
↓
The VM was isolated from the network
↓
Disk snapshots and logs were preserved
↓
The VM managed identity had accessed Key Vault
↓
The identity was disabled and its role assignments removed
↓
Exposed secrets and certificates were rotated
↓
A malicious service principal was discovered
↓
Its credentials and consent grants were revoked
↓
Related storage and database activity was reviewed
↓
The exploited application vulnerability was patched
↓
The workload was rebuilt from a trusted image
↓
Network access and logging were validated
↓
Heightened monitoring showed no further attacker activity
↓
The business service was restored
↓
The response timeline and lessons learned were documented
↓
The attack had stopped
↓
But the incident was not over until trust was restored
Cloud incident-response checklist
| Area | Question | Evidence |
|---|---|---|
| Declaration | Has the event met the incident threshold? | Severity, business impact and incident record. |
| Scope | Which identities, resources and data are affected? | Alerts, logs and timeline. |
| Evidence | What must be preserved before containment? | Snapshots, exports, files and logs. |
| Containment | Which action stops the threat safely? | Identity, resource and network response plan. |
| Persistence | How could the attacker regain access? | Credentials, identities, automation and startup mechanisms. |
| Eradication | Has malware, vulnerable code and rogue access been removed? | Rebuild, patch and credential records. |
| Recovery | Can services return from trusted sources? | Backup, deployment and validation testing. |
| Monitoring | Is heightened detection active after recovery? | Alerts, queries and telemetry health. |
| Closure | Are follow-up actions assigned and tracked? | Lessons learned and improvement plan. |
Key takeaways
- Cloud incident response covers preparation, detection, analysis, containment, eradication, recovery and lessons learned.
- Stopping suspicious activity does not complete the incident.
- Identity, control-plane and workload evidence must be investigated together.
- Preserve evidence before deleting or rebuilding affected resources.
- Contain users, service principals, managed identities, credentials, workloads and network paths as required.
- Eradication removes persistence, malicious resources and vulnerable configurations.
- Recovery should use trusted images, code, templates and backups.
- Microsoft Sentinel automation rules and playbooks can support consistent response.
- Closure requires validated containment, trusted recovery and assigned follow-up actions.
- Lessons learned should improve controls, logging, ownership and response playbooks.
What Agent Foskett checked
- Incident severity
- Affected identities
- Affected resources
- Defender alerts
- Activity timeline
- Persistence
- Role assignments
- Secrets and credentials
- Snapshots and logs
- Recovery source
- Monitoring health
- Lessons learned
Best practices
- Prepare before an incident.
- Test emergency access.
- Preserve evidence first.
- Contain identities and credentials.
- Remove persistence.
- Rebuild from trusted sources.
- Validate recovery.
- Use automation carefully.
- Document every decision.
- Improve the environment afterwards.
Related Agent Foskett resources
Continue learning
What is cloud incident response?
Cloud incident response is the coordinated process used to prepare for, detect, analyse, contain, eradicate, recover from and learn from security incidents affecting cloud identities, resources, applications and data.
Cloud Incident Response Lesson
This Agent Foskett lesson explains incident preparation, detection, analysis, containment, eradication, recovery, evidence preservation, automation, communication, closure and lessons learned.
