Lesson 34 — Investigating Cloud Alerts
A Microsoft Defender for Cloud alert is the beginning of an investigation, not the conclusion.
A structured cloud investigation connects the alert to the affected resource, the identity that acted, the Azure configuration that changed, the surrounding activity, related alerts and any path toward more sensitive assets.
This lesson explains how to triage an alert, validate its evidence, reconstruct a timeline, investigate resources and identities, determine scope, contain the threat and document the response.
What you will learn
This lesson follows a cloud alert from initial triage through evidence review, timeline reconstruction, containment and closure.
Cloud alert investigation workflow
↓
Record severity, time, resource and detection source
↓
Review entities, evidence and recommended actions
↓
Confirm the resource owner and expected activity
↓
Investigate identity, Azure Activity Log and resource telemetry
↓
Search for related alerts, resources and credentials
↓
Reconstruct activity before, during and after the alert
↓
Determine scope, business impact and attack-path context
↓
Classify the alert
↓
Preserve evidence
↓
Contain the identity, resource, credential or network path
↓
Validate containment and assign follow-up actions
Investigation evidence map
| Evidence source | What it can answer | Example |
|---|---|---|
| Defender alert | What suspicious behaviour was detected? | Command execution or unusual access. |
| Azure Activity Log | Who changed the cloud resource? | Public access enabled. |
| Microsoft Entra logs | How did the identity authenticate? | Service principal sign-in from a new IP. |
| Resource logs | What data-plane operation occurred? | Secret retrieval or blob download. |
| Application logs | Which code path or request triggered activity? | Vulnerable API endpoint. |
| Network telemetry | What systems communicated? | Outbound connection to malicious infrastructure. |
| Attack paths | How could the attacker reach critical assets? | Public VM to managed identity to Key Vault. |
Learning objectives
- Triage Defender for Cloud alerts.
- Review severity, evidence and entities.
- Investigate affected resources.
- Investigate users, managed identities and service principals.
- Reconstruct a cloud activity timeline.
- Determine scope and related alerts.
- Contain and document an incident.
Why cloud investigations are different
Cloud activity spans identities, subscriptions, control-plane changes, workload telemetry, network paths and managed services. The alert rarely contains the whole story.
Start with the alert record
Record the alert name, severity, status, first activity, last activity, subscription, resource, detection source and time zone before taking action.
Alert severity
Severity helps prioritise work but should be combined with business criticality, exposure, identity privilege, sensitive data and attack-path context.
Alert status
Use a consistent status workflow such as active, in progress, resolved or dismissed so ownership and progress remain visible.
Alert description
Read the full description to understand the detected behaviour, why it was considered suspicious and which assumptions require validation.
Detection source
Identify which Defender plan or connected protection generated the alert because the available evidence and response actions vary by workload.
Affected resource
Confirm the exact subscription, resource group, resource ID, cloud environment and business owner.
Entities
Entities may include users, IP addresses, hosts, containers, databases, storage accounts, managed identities, service principals, processes and files.
Evidence
Evidence can include command lines, operations, request paths, network connections, file names, authentication methods and threat-intelligence context.
MITRE ATT&CK mapping
MITRE ATT&CK tactics and techniques help place the detection within an attack lifecycle, but they do not prove the complete attack chain by themselves.
Recommended actions
Review the recommended response guidance, then adapt it to the actual workload, business impact and evidence.
Validate the timestamp
Confirm whether alert times are shown in UTC or local time and normalise every evidence source before building the timeline.
Establish the baseline
Determine what normal activity looks like for the resource, identity, application, region and time of day.
Confirm the owner
Contact the technical or application owner early to establish whether the activity matches an approved change or operational process.
Avoid premature closure
A familiar resource or valid identity does not make unusual behaviour benign. Compromised credentials often produce technically valid activity.
Resource configuration
Review networking, public exposure, identity assignments, diagnostic settings, Defender plans, tags and recent configuration changes.
Resource history
Investigate deployments, policy changes, key rotation, role assignments, network updates and resource creation around the alert period.
Azure Activity Log
The Azure Activity Log provides control-plane evidence such as who changed a resource, what operation occurred, when it happened and whether it succeeded.
Resource logs
Resource-specific logs provide data-plane evidence such as storage access, database queries, Key Vault retrieval and application requests.
Log Analytics
Use Log Analytics to search across retained cloud, identity, application and infrastructure telemetry.
Application telemetry
Application logs and Application Insights can connect a cloud alert to a user request, code path, dependency or deployment event.
Network evidence
Review source and destination addresses, DNS activity, firewall logs, NSG flow data, private endpoints and unusual outbound connections.
Identity evidence
Investigate Entra sign-ins, token use, MFA, Conditional Access, role activation, consent, credential changes and service-principal activity.
User accounts
Review user risk, authentication method, device, location, recent password changes and privileged role membership.
Managed identities
Determine which workload owns the managed identity, what resources it can access and whether its normal host was compromised.
Service principals
Review app registrations, credentials, certificates, API permissions, consent and recent sign-in behaviour.
Role assignments
Look for new or expanded Azure RBAC assignments before or during the alert period.
Conditional Access
Confirm whether the identity was subject to the expected policies and whether any exclusions or service-account exceptions applied.
Related alerts
Search for alerts sharing the same identity, resource, IP address, subscription, process, image, application or time window.
Incidents
Multiple correlated alerts may form a broader incident. Review incident context before treating each alert independently.
Security graph context
Use relationships between identities, resources, permissions and exposure to understand how the alert could connect to other assets.
Attack paths
Review attack paths when the alert involves an exposed resource, privileged identity or connection to critical data.
Timeline reconstruction
Arrange sign-ins, resource changes, workload events, alerts and response actions in time order.
Before the alert
Search backwards for reconnaissance, privilege changes, credential creation, public exposure and deployment activity.
During the alert
Record the exact operations, resources, identities and network connections involved in the detected behaviour.
After the alert
Search forwards for persistence, lateral movement, data access, deletion, credential use and additional alerts.
Scope determination
Identify every affected identity, subscription, resource, region, credential, workload and data set.
False positive validation
Confirm whether the activity was authorised, technically expected and documented. A single explanation should account for all evidence.
Benign positive
A benign positive is real activity correctly detected as suspicious but authorised for a legitimate reason. Document the reason before tuning.
True positive
A true positive indicates malicious or unauthorised activity and requires containment, eradication, recovery and follow-up.
Unknown
Keep the alert open when evidence is insufficient. Document what additional telemetry or owner confirmation is required.
Containment planning
Select actions that stop the threat while preserving evidence and minimising unnecessary business disruption.
Identity containment
Disable accounts, revoke sessions, remove role assignments, rotate credentials or restrict service principals as required.
Resource containment
Isolate virtual machines, restrict network access, disable public endpoints, stop compromised applications or quarantine malicious objects.
Credential containment
Rotate exposed keys, secrets, certificates, passwords, SAS tokens and deployment credentials.
Network containment
Block malicious sources and destinations, tighten firewall rules and close unintended management paths.
Evidence preservation
Preserve alerts, logs, snapshots, files, configuration records and timestamps before destructive remediation.
Escalation
Escalate when critical resources, privileged identities, sensitive data, multiple subscriptions or active attacker movement are involved.
SOC coordination
The SOC should maintain incident ownership, timeline, evidence, severity, communications and response tracking.
Cloud platform team
Platform teams assist with subscriptions, policy, networking, identity assignments and shared cloud controls.
Application team
Application teams investigate code, deployment pipelines, service identities, dependencies and business impact.
Incident response team
Engage incident response when compromise is confirmed, evidence preservation is complex or the scope extends beyond routine alert handling.
Management communication
Communicate known facts, current impact, containment status, uncertainty and next decisions without overstating conclusions.
Closure criteria
Close the alert only when the activity is understood, scope is established, containment is validated and follow-up actions have owners.
Post-incident improvement
Use the investigation to improve logging, alert routing, identity controls, resource configuration, automation and response playbooks.
Agent Foskett investigation: “The alert looked minor…”
↓
A small number of unusual requests reached a storage account
↓
The alert was initially treated as isolated activity
↓
Agent Foskett reviewed the Azure Activity Log
↓
Public network access had been enabled thirty minutes earlier
↓
The change was made by a newly created service principal
↓
Entra sign-in evidence showed the credential was used from an unfamiliar host
↓
The same service principal had received Contributor access
↓
A managed identity was then attached to a virtual machine
↓
Key Vault logs showed secret retrieval by that identity
↓
The retrieved secret provided access to another production workload
↓
Related alerts appeared across storage, compute and Key Vault
↓
The service principal was disabled
↓
Sessions and credentials were revoked
↓
Public access was removed
↓
The virtual machine was isolated
↓
Secrets were rotated
↓
The alert looked minor
↓
Until the timeline revealed the complete attack chain
Cloud alert investigation checklist
| Area | Question | Evidence |
|---|---|---|
| Alert | What was detected and how severe is it? | Alert title, severity and description. |
| Resource | Which workload is affected and who owns it? | Resource ID, tags and CMDB. |
| Identity | Which user, service principal or managed identity acted? | Entra logs and role assignments. |
| Activity | What changed before and after the alert? | Activity Log and resource logs. |
| Network | Where did the activity originate and communicate? | IP, DNS, firewall and connection logs. |
| Related alerts | Is the alert part of a broader incident? | Shared entities, resources and timeline. |
| Scope | What else could the attacker access? | Permissions, credentials and attack paths. |
| Containment | Which action stops the threat safely? | Response plan and owner approval. |
| Closure | Has containment been validated? | Retesting, monitoring and follow-up tickets. |
Key takeaways
- A Defender for Cloud alert begins the investigation.
- Severity must be combined with business criticality and attack context.
- Review the affected resource, entities, evidence and recommended actions.
- Use Azure Activity Log for control-plane changes.
- Use resource and application logs for data-plane activity.
- Investigate users, service principals and managed identities.
- Search for related alerts and shared entities.
- Reconstruct activity before, during and after the detection.
- Preserve evidence before destructive containment.
- Close the alert only after scope and containment are validated.
What Agent Foskett checked
- Alert severity
- Affected resource
- Entities
- Azure Activity Log
- Resource logs
- Entra sign-ins
- Role assignments
- Managed identities
- Network activity
- Related alerts
- Attack paths
- Containment status
Best practices
- Record the alert immediately.
- Normalise timestamps.
- Confirm resource ownership.
- Investigate valid identities.
- Search before and after the alert.
- Review related alerts.
- Preserve evidence.
- Contain the narrowest safe scope.
- Validate response actions.
- Document lessons learned.
Related Agent Foskett resources
Continue learning
How do you investigate Microsoft Defender for Cloud alerts?
Investigating Defender for Cloud alerts requires reviewing severity, affected resources, entities, evidence, Azure Activity Log, identity activity, resource telemetry, related alerts, attack paths and containment actions.
Investigating Cloud Alerts Lesson
This Agent Foskett lesson explains alert triage, evidence review, identity investigation, resource investigation, timeline reconstruction, scope analysis, containment, escalation and closure.
