Cloud Incident Response: How IR Differs in Cloud Environments

Cloud service models and what they mean for IR

Cloud computing delivers resources as services. The service model determines what you're responsible for securing, what evidence you have access to during an incident, and what containment actions are available to you.

Infrastructure as a Service (IaaS) provides virtual machines, networking, and storage. Azure Virtual Machines, AWS EC2, and Google Compute Engine are IaaS. You manage the operating system, applications, and data. The provider manages the physical hardware, hypervisor, and network fabric. When an IaaS virtual machine is compromised, you can capture its disk image, take a memory snapshot, and analyze network flow logs. The investigation shares some characteristics with traditional endpoint IR: you have an operating system with a filesystem, running processes, and log files. But you also have cloud-layer evidence that doesn't exist on-premises: Azure Activity Log records every management-plane operation, and the cloud control plane provides an audit trail for who created, modified, or deleted the resource.

Platform as a Service (PaaS) provides managed application platforms. Azure App Service, Azure SQL Database, and AWS Lambda are PaaS. You manage the application and its data. The provider manages the runtime, operating system, and infrastructure. In a PaaS incident, you don't have access to the underlying operating system. You can't image a disk or capture memory. Your evidence is application logs, platform audit logs, and the provider's activity records. The investigation is constrained to what the platform exposes through its APIs and logging.

Software as a Service (SaaS) provides complete applications. Microsoft 365, Google Workspace, and Salesforce are SaaS. You manage user access, configuration, and data. The provider manages everything else: the application code, the runtime, the operating system, the infrastructure. In a SaaS incident, you have no access to the underlying systems. Your evidence is entirely the audit logs and activity records the provider makes available through APIs, PowerShell cmdlets, and portal exports.

Microsoft 365 is SaaS. This course operates entirely in the SaaS investigation model. You investigate through the logs Microsoft provides, accessed through Graph API, KQL in Sentinel, Advanced Hunting in Defender XDR, and PowerShell. You don't image a server. You don't capture memory. You don't analyze network packets at the infrastructure layer. The evidence is what the platform recorded, subject to the retention periods the provider defines and the license tier your organization pays for.

How incident response changes in the cloud

Unit 42's 2025 Global Incident Response Report found that 29% of investigations involved cloud or SaaS environments, with one in five incidents resulting in direct adverse impact to cloud assets. IBM X-Force's 2026 cloud threat analysis found that most cloud intrusions stemmed from weaknesses in identity controls, workload configuration, and hybrid-cloud integration rather than advanced exploitation. These aren't endpoint incidents that happened to touch the cloud. They're cloud-native incidents that require cloud-native response.

Identity is the primary attack surface. Traditional IR focuses on the network perimeter and the endpoints behind it. In M365, the attack surface is the identity provider. Microsoft blocks over 4.5 million new malware attempts daily, but the attacks that succeed overwhelmingly target identity. Of the 600 million daily identity attacks Microsoft recorded in the 2025 Digital Defense Report, 97% were password-based. The remaining 3% includes the attacks that bypass MFA entirely: AiTM proxy phishing (up 146% year-over-year), device code phishing, token theft from compromised endpoints, and OAuth consent phishing. Once the attacker has a valid token, they authenticate through the same front door your users use. Every control between the internet and your data, Conditional Access, MFA, device compliance, evaluates at the identity layer. Pass that evaluation with a stolen token and you're in.

Evidence is ephemeral and distributed. On-premises evidence persists until the disk is overwritten. Cloud evidence has retention limits. Entra ID sign-in logs expire after 30 days natively. The Unified Audit Log retains records for 180 days on all tiers (changed from 90 days in October 2023), with E5 tenants getting one year for Exchange, SharePoint, and Entra ID activity. MailItemsAccessed, the evidence source that proves which specific emails the attacker read, is only available on E5 or with the Audit Premium add-on. If your organization runs E3, the single most important email investigation evidence source does not exist for your tenant.

Evidence is also distributed. A single compromised identity produces evidence across four separate domains simultaneously: Entra ID sign-in logs (authentication), Exchange Online audit (email activity), SharePoint audit (file access), and Entra ID audit log (directory changes). Each domain has different log sources, different query tools, different retention periods. No single query shows you everything that happened. The investigation must cover all four domains or it produces incomplete findings. Unit 42 specifically calls this out: cloud investigations require a focus on identities, misconfigurations, and service interactions rather than traditional endpoint and network evidence.

Containment is multi-channel. On an endpoint, you isolate the device from the network and the attacker loses access. In M365, the attacker may simultaneously hold active session tokens (valid until revocation propagates through Continuous Access Evaluation), OAuth consent grants (survive password resets indefinitely), service principal credentials (authenticate without any user interaction), inbox forwarding rules (silently copy every incoming email to an external address), and anonymous SharePoint sharing links (provide direct file access without authentication). Resetting the user's password addresses one of these five channels. A comprehensive containment response must address all of them, and the 40% of ransomware attacks now targeting hybrid components means the containment may need to span both cloud and on-premises AD simultaneously.

No physical access to evidence. You cannot image a disk in M365. You cannot capture process memory. You cannot mirror network traffic. Every evidence collection action goes through an API, a PowerShell cmdlet, or a portal export. Your investigation capability is bounded by what Microsoft's APIs expose, what your permissions allow, and what your license tier includes. This is a fundamental constraint that shapes the entire investigation methodology.

What cloud gives incident responders

Cloud IR has constraints, but it also gives responders capabilities that don't exist in traditional environments.

Centralized, structured logging at scale. On-premises, every application, server, and device logs in its own format to its own location. Collecting evidence means touching dozens of systems, often under time pressure. In M365 with Sentinel, activity across Exchange, SharePoint, OneDrive, Teams, Entra ID, and Defender is recorded in structured log tables accessible from a single query interface. A KQL query can correlate a sign-in event with a mailbox access event with a file download with a directory modification in one statement. On-premises, that correlation requires manual evidence assembly across multiple systems with different log formats and different time sources.

API-driven evidence collection. On-premises evidence collection typically means running tools on the compromised system, imaging disks over the network, or deploying collection agents. In M365, you collect evidence through APIs: Graph API for sign-in and audit logs, Exchange Online PowerShell for mailbox data, Search-UnifiedAuditLog for the central audit trail. You can collect evidence from any account in the tenant without touching a device, without deploying an agent, without being on the same network. For an organization with 10,000 users spread across 40 countries, the ability to collect evidence from any account through a single API endpoint is transformative compared to shipping forensic kits to branch offices.

Programmatic containment at speed. On-premises containment often involves manual steps: disable a network port, add a firewall rule, physically isolate a machine. In M365, containment is scriptable. You can revoke sessions for every user in a department with a PowerShell loop. You can deploy an emergency Conditional Access policy via Graph API in seconds. You can enumerate and remove every inbox forwarding rule in a tenant with a single script. You can identify and revoke every OAuth consent grant from a specific time window programmatically. When the preparation work from Module 3 is in place, cloud containment executes faster than any physical containment process.

Historical evidence depth. On-premises, you get what was configured to log. If the Windows Security log wrapped at 128MB, the evidence from last week is gone. If Sysmon wasn't installed, process creation details don't exist. In M365, audit logging is enabled by default for most operations across all license tiers. MailItemsAccessed records every email access. SharePoint logs every file download. Sign-in logs record every authentication attempt with IP address, geographic location, device details, user agent, and the full Conditional Access evaluation result. The volume and structure of evidence M365 produces exceeds what most on-premises environments generate, provided you're within the retention window and your license tier includes the relevant evidence source.

Remote investigation from anywhere. On-premises investigation often requires physical access or VPN connectivity to the compromised network. M365 investigation requires an internet connection and the right permissions. You can investigate from anywhere, against any tenant, without being on the corporate network. For IR teams and consultants, this means faster engagement: you can start collecting evidence within minutes of receiving credentials, rather than waiting for VPN access, jump boxes, or physical travel.

These advantages are real, but every one of them depends on preparation. The centralized logging only helps if you've configured Sentinel to ingest the logs before the incident. The API-driven collection only works if you've set up the Graph API permissions and scopes. The programmatic containment only executes if you've built and tested the scripts and policies. Module 3 covers this preparation in detail because the capability you don't build before the incident is the capability you won't have during it.

Section 0.4 maps the M365 evidence landscape specifically: which log sources exist, what each one records, how long it's retained, and what disappears first.