What is cloud forensics explained for security teams

TL;DR:

• Cloud forensics faces unique challenges due to multi-tenant environments, jurisdictional complexities, and reliance on third-party provider cooperation. Investigators must follow a five-phase process—identification, preservation, collection, examination, and reporting—using cloud-native tools to handle evidence volatility and legal limitations. Effective cross-service correlation, legal awareness, and proactive forensic readiness are crucial for successful outcome in cloud breach investigations.

Cloud forensics is one of those disciplines where the gap between what security professionals assume is possible and what the evidence actually supports can make or break an investigation. The common misconception is that because data lives in the cloud, it is always accessible and readily preserved. The reality is far more complex. What is cloud forensics explained properly demands an honest account of multi-tenancy constraints, jurisdictional complications, and the fundamental shift in how evidence exists in virtualised, ephemeral infrastructure. This article covers the forensic process, current threat actor tactics, and the legal and technical challenges that every investigator operating in cloud environments must understand.

Table of Contents

• Key takeaways
• Cloud forensics overview: how it differs from traditional methods
• The cloud forensic process and key tools
• How modern threat actors are changing cloud forensic analysis
• Legal challenges in cloud evidence preservation
• Practical applications of cloud forensics in incident response
• My perspective on investigating in cloud environments
• How Makkarisecurity supports cloud forensic investigations
• FAQ

Key takeaways

Cloud forensics overview: how it differs from traditional methods

Understanding cloud forensics requires accepting that traditional digital forensics assumptions do not transfer cleanly. Physical forensics relies on acquiring a bit-for-bit image of a hard drive you can physically access. In cloud environments, you rarely control the underlying hardware, and the "evidence" is distributed across virtualised layers managed by a third party.

Cloud computing models introduce distinct forensic challenges at each level:

• IaaS (Infrastructure as a Service): You have the most control here. Investigators can snapshot virtual machine disks, pull memory from running instances, and access storage buckets. But even here, underlying hypervisor data and cross-tenant activity logs are inaccessible without provider co-operation.
• PaaS (Platform as a Service): Evidence becomes more abstracted. Application-level logs may exist, but the infrastructure running the platform is entirely outside investigator control, limiting the depth of forensic examination.
• SaaS (Software as a Service): This is the most constrained forensic environment. Investigators depend entirely on what the provider exposes through audit logs and administrative interfaces. Data residency, retention policies, and provider co-operation determine what is recoverable.

Multi-tenancy compounds these challenges significantly. Your organisation's data shares physical infrastructure with other tenants, and forensic access that crosses tenant boundaries is legally prohibited without explicit authorisation. Investigators cannot pursue evidence across those boundaries even when activity patterns suggest it is relevant.

Jurisdictional complexity adds another layer. Cloud data may be stored across multiple countries, each with different legal frameworks governing data access, law enforcement requests, and evidence admissibility. A breach investigation touching AWS regions in Ireland, the United States, and Singapore simultaneously involves at least three distinct legal regimes.

The division of responsibility between cloud service providers and customers is defined by the shared responsibility model. Providers secure the infrastructure. Customers are responsible for securing what runs on it. In forensic terms, this means customers own the investigation of their own resources but must request provider assistance for infrastructure-level evidence, often through formal legal channels.

The cloud forensic process and key tools

Cloud forensics follows a five-phase process: identification, preservation, collection, examination and analysis, and reporting. Each phase carries specific requirements that differ from their physical forensic counterparts.

1. Identification: Determine which cloud services, accounts, regions, and resource types are in scope. This includes mapping IAM roles, identifying affected storage buckets or databases, and cataloguing which audit logs are enabled and what their retention windows cover. Missing log sources discovered at this stage will affect every subsequent phase.

2. Preservation: Evidence volatility in cloud environments is high. Instances can be terminated, logs can be overwritten, and auto-scaling events can destroy forensic artefacts within minutes of an incident. Preservation actions include taking EBS snapshots, enabling enhanced logging where it is not already active, and locking S3 buckets against deletion or modification. Time is the critical variable.

3. Collection: This phase involves acquiring logs, disk images, memory captures, and configuration states from the relevant cloud services. Cloud-native tools are central here. Investigators using AWS CLI, Azure CLI, and Microsoft Defender XDR can pull audit trails, enumerate resource configurations, and extract authentication records. Forensic SDKs allow programmatic querying of telemetry at scale, which is often impractical to do manually across distributed cloud environments.

4. Examination and analysis: Once evidence is collected, investigators reconstruct timelines, attribute activity to identities or IP addresses, and identify indicators of compromise. Cross-service correlation is frequently required. An attacker who compromised an IAM key may have accessed S3 buckets, spun up EC2 instances, and queried Secrets Manager within the same session. Each action leaves telemetry in different services, and analysts must join those data sources to produce a coherent timeline.

5. Reporting: Forensic reports must document the chain of custody for all acquired evidence, describe the tools and methods used, and clearly state what was and was not accessible. Reports that overstate their evidential scope create serious legal risk.

Pro Tip: Before any incident occurs, audit which logs are actually enabled across your cloud environment. CloudTrail data events, VPC Flow Logs, and Azure Diagnostic Settings are often disabled by default. Discovering their absence during an active investigation is one of the most damaging position you can find yourself in.

How modern threat actors are changing cloud forensic analysis

The threat landscape affecting cloud forensic analysis has shifted significantly. Attackers are no longer primarily deploying malware to endpoints. They are targeting identities and control-plane access, leveraging legitimate administrative features to achieve persistence, lateral movement, and data exfiltration while blending into normal operational traffic.

This shift has direct consequences for investigators:

• Malware signatures are largely irrelevant. When an attacker uses a valid service principal to call legitimate APIs, traditional signature-based detection produces nothing. The investigation becomes entirely behavioural.
• Control-plane versus data-plane differentiation is critical. Attackers abuse cloud management features such as VM code execution capabilities and Key Vault access to operate within the environment. Investigators must reconstruct what was done through the management layer versus what occurred within running workloads.
• Identity telemetry becomes the primary evidence source. Sign-in logs, conditional access evaluations, role assignments, and service principal activity form the core of most cloud breach investigations today.
• Cross-service correlation is non-negotiable. A single suspicious action rarely tells the full story. Investigators must correlate events across Microsoft Entra ID, Azure Resource Manager, storage access logs, and network flow data to reconstruct an attacker's full path.

"Threat actors are increasingly targeting cloud identities rather than endpoints, demanding forensic investigation methods that focus on identity behaviour and cross-service correlation rather than traditional artefact analysis."

The Storm-2949 campaign illustrates this precisely. The threat actor converted a single compromised identity into a cloud-wide breach by chaining legitimate administrative operations. No novel exploit. No malware. Just a compromised credential and deep knowledge of cloud management APIs. For forensic investigators, this type of incident demands tooling and methodology that is native to the cloud, not adapted from endpoint forensics.

Legal challenges in cloud evidence preservation

The legal dimension of cloud forensics is where many investigations develop weaknesses that are only discovered later, often in court or regulatory proceedings.

Credible forensic reports must transparently state which platforms were accessible, what data was preserved, and what limitations existed due to provider restrictions or encryption. A report that implies complete visibility when only partial log data was available will not survive scrutiny from opposing counsel. Overstating evidential scope is one of the most common professional errors in cloud investigations.

Regulatory considerations vary considerably depending on where the breached organisation operates and where its data is stored. GDPR obligations in the UK and EU may require specific handling of personal data acquired during investigations, including restrictions on how long investigators can retain copies of evidence. Co-ordinating with legal counsel before collection begins is not optional. It directly affects which data can be collected, how it can be used, and whether it can be disclosed in proceedings.

Pro Tip: Document every access attempt, including failed ones, from the moment an investigation opens. If a cloud provider's support ticket system or legal request process delays your access to specific log data, that delay and its reason must be recorded. It becomes relevant when explaining evidence gaps to a court or regulator.

Practical applications of cloud forensics in incident response

Cloud forensic analysis sits at the centre of several high-frequency investigation scenarios that security teams encounter regularly. Understanding how the forensic process maps to each scenario is what separates an effective response from one that produces inconclusive results.

Consider the most common scenarios:

• Compromised IAM credentials: Investigating a compromised IAM key requires tracing all API calls made using that credential, identifying any resources created or modified, checking for persistence mechanisms such as new IAM users or access keys, revoking the compromised credential, and assessing the full scope of data access. CloudTrail provides the primary log source, but investigators must also check service-specific logs for data exfiltration through S3 GetObject events or RDS query logs.
• S3 bucket exposure: Whether caused by misconfiguration or an active attacker, S3 investigations focus on access logs, bucket policy change history, and data transfer records. The key question is always whether data was actually accessed and by whom, not simply whether access was theoretically possible.
• Virtual machine compromise: This scenario most closely resembles traditional endpoint forensics but with cloud-specific additions. Investigators need a disk snapshot, memory if the instance is still running, and all cloud management plane activity related to that instance since its creation.

For forensic readiness, organisations should maintain a baseline of which logs are enabled, what their retention periods are, and whether access credentials for forensic purposes are pre-provisioned and tested. Waiting until an incident is active to discover your logging configuration is a recoverable position, but a costly one. You can find further guidance on securing cloud infrastructure as part of building that baseline posture.

Integration with incident response workflows is the other critical element. Cloud forensics must feed findings directly into containment decisions. The forensic examiner identifying an attacker's persistence mechanism in an IAM policy change at 02:00 needs a clear channel to the responder who can revoke it before the working day begins. Siloed forensic and response functions produce slower, less effective outcomes.

My perspective on investigating in cloud environments

I've spent years working on breach investigations, and the ones involving cloud environments consistently reveal the same pattern: organisations underestimate how much the investigation depends on decisions made before the incident. Log retention settings, IAM role configurations, and forensic access pre-provisioning are not incident response actions. They are forensic readiness decisions, and they determine what is recoverable when something goes wrong.

What I've found is that the complexity of multi-cloud investigations is routinely underestimated. Investigators who are proficient in AWS often encounter blind spots when the same attacker pivoted through an Azure tenant or used an OAuth token to access a SaaS application. Each environment has its own telemetry model, its own log schema, and its own quirks around what gets recorded and what does not. Building genuine cross-platform forensic capability takes time and direct experience across environments, not just theoretical knowledge.

The other thing I've learned is that collaboration between forensic examiners, incident responders, and legal advisors cannot be bolted on at the end. The moment you start collecting evidence, you are making decisions that affect legal proceedings. A forensic examiner who operates without awareness of the legal context, and a legal team who receive a report without understanding its evidential limitations, are a combination that produces avoidable failures.

The common misconception I'd push back hardest on is the idea that cloud forensics is just digital forensics applied to a different medium. It is a distinct discipline with its own tooling, its own evidence models, and its own legal context. Treating it as an extension of endpoint forensics is how investigations produce incomplete, non-defensible results.

— Makkari

How Makkarisecurity supports cloud forensic investigations

When a breach involves cloud infrastructure, the margin for error in the forensic response is narrow. Makkarisecurity brings court-admissible digital forensics and incident response capabilities purpose-built for complex cloud environments, covering evidence preservation, IAM compromise investigations, and cross-service telemetry analysis.

Our breach counsel and panel support service connects forensic findings directly with legal defensibility, handling the chain-of-custody documentation and evidence scope transparency that courts and regulators require. With a proprietary forensic engine built over five years and a flawless re-breach record underpinned by the Eviction Pledge, Makkarisecurity delivers speed and accuracy at the point where both matter most. If you are facing a cloud breach or want to establish forensic readiness before one occurs, contact Makkarisecurity directly.

FAQ

What is cloud forensics and how does it differ from traditional forensics?

Cloud forensics is the application of digital investigation techniques to cloud computing environments, where evidence exists in virtualised, distributed infrastructure managed by third-party providers. Unlike traditional forensics, investigators cannot physically access hardware, and evidence collection depends on provider co-operation, API access, and cloud-native tooling.

How does cloud forensics work in practice?

Cloud forensics follows a five-phase process covering identification, preservation, collection, examination and analysis, and reporting, with each phase adapted to the constraints of cloud environments including provider-controlled infrastructure and limited retention windows.

What are the main cloud forensics tools used by investigators?

Investigators rely on cloud-native tools including AWS CLI, Azure CLI, and Microsoft Defender XDR, alongside forensic SDKs that allow programmatic querying of audit logs, IAM records, and resource configuration states across cloud environments.

Why is evidence preservation so difficult in cloud environments?

Cloud resources can be terminated or overwritten at any time through auto-scaling, instance termination, or log retention expiry, meaning investigators must act immediately to snapshot disks, lock storage, and extract logs before artefacts are lost.

What makes a cloud forensic report legally defensible?

Forensic reports must transparently state which platforms were accessible, what evidence was preserved, and what limitations existed due to provider restrictions or encryption, avoiding any overstatement of evidential scope that opposing counsel could challenge.

Recommended

• Breach Counsel & Panel Support | Court-admissible DFIR | Makkari Security
• Capabilities | Incident Response, Digital Forensics, IR Retainer | Makkari Security
• Insights | Field notes from Makkari Security
• Mission | Makkari Security