10. Cloud, Mobile, IoT and Operational-Technology Forensics

Introduction and Context

Digital investigations increasingly cross organisational boundaries, device types and technical environments. A single incident may involve a compromised cloud identity, a mobile authenticator, a container workload, an internet-connected sensor and an industrial control system. These environments differ not only in architecture but also in the way evidence is created, retained, accessed, interpreted and preserved.

Traditional forensic practice assumes that investigators can seize a device, isolate it, create a bit-stream image and analyse the copy. That assumption is often unsuitable for cloud, mobile, Internet of Things (IoT) and operational-technology (OT) environments. Cloud evidence may be distributed across jurisdictions and controlled by a service provider. Containers may disappear when an orchestration platform reschedules a workload. Mobile applications may store important information in encrypted sandboxes or synchronise it with cloud services. IoT devices may have limited storage, weak logging and proprietary protocols. In OT environments, aggressive investigative actions can interrupt safety-critical processes or damage equipment.

The central challenge is therefore not simply data extraction. It is the construction of a defensible evidential account while preserving availability, safety, privacy and business continuity. Investigators must understand the architecture that produced the evidence, the contractual and legal authority governing access, and the degree of reliability that can reasonably be attributed to each artefact.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain how the shared-responsibility model affects forensic readiness and investigation in cloud services.

2. Distinguish forensic issues in SaaS, PaaS, IaaS, containers and serverless environments.

3. Plan evidence acquisition from mobile devices, IoT systems and OT networks without causing unnecessary harm.

4. Apply principles of volatility, provenance, integrity and chain of custody to distributed environments.

5. Evaluate provider dependencies, jurisdictional restrictions, encryption and limited logging.

6. Design an incident-handling approach that combines forensic objectives with operational and safety constraints.

7. Analyse emerging uses of automation, telemetry and artificial intelligence in contemporary investigations.

Why Conventional Forensics Must Be Adapted

Forensic soundness is commonly associated with preservation, repeatability, authenticity and demonstrable integrity. These principles remain valid, but their implementation changes across modern environments. An investigator may not possess the physical infrastructure, administrative privileges or technical capability needed to acquire a traditional image. Instead, evidence may consist of API responses, audit-log exports, snapshots, mobile backups, memory captures, packet records, application records and provider attestations.

Three characteristics are especially important. First, evidence is distributed. A user action in a SaaS platform may generate records in an identity provider, endpoint, application, database, security-monitoring platform and provider audit service. Second, evidence is volatile. Cloud instances, ephemeral containers, dynamic IP addresses, access tokens and short-retention logs may disappear quickly. Third, evidence is relational. The meaning of an event often emerges only when timestamps, identities, network flows and application records are correlated.

A defensible investigation should document the source, acquisition method, time reference, permissions, tool or API used, transformations performed and cryptographic hash of every exported object where hashing is technically appropriate. Hashing proves that a preserved copy has not changed; it does not, by itself, prove that the original source was accurate or that the account associated with an event was operated by a particular person.

A Forensic View of the Cloud Service Stack

The cloud service model influences both responsibility and access to evidence.

Software as a Service

In SaaS, the provider operates the application and underlying infrastructure. The customer may control users, roles, configuration, content and selected audit settings, but normally cannot inspect host disks or hypervisor logs. Useful evidence may include sign-in events, administrative actions, file-sharing records, mailbox activity, API calls, data-loss-prevention alerts, retention-policy events and application audit trails.

The primary risk is assuming that a customer interface exposes the complete record. Dashboards often show a filtered or summarised view, while detailed events may require an API, a specialised export or a provider request. Investigators should identify the tenant, account, time zone, retention period, relevant subscriptions and administrative changes before collecting records.

Platform as a Service

PaaS customers deploy code while the provider manages much of the operating system and infrastructure. Evidence may include application logs, database audit records, deployment histories, source-control activity, identity events, secrets-management logs and platform configuration. Host-level evidence may be unavailable. A forensic strategy must therefore emphasise application instrumentation, immutable logging, deployment provenance and rapid preservation of relevant resources.

Infrastructure as a Service

IaaS provides greater control over virtual machines, storage, networks and security groups, but the physical infrastructure remains provider-controlled. Investigators may acquire virtual-disk snapshots, memory where supported, flow logs, firewall records, identity events, object-storage access logs and configuration histories. A snapshot is not necessarily a complete physical image, and provider metadata concerning snapshot creation, cloning or access should be preserved as part of the evidential record.

Containers and Serverless Workloads

Containers are designed to be replaceable. A running container may contain valuable process, filesystem and credential evidence, yet disappear when a deployment is updated or a node fails. Container images, image digests, orchestration manifests, pod specifications, admission records, registry logs, runtime events and host telemetry should be preserved alongside live-state captures where safe.

Serverless functions create another difficulty: execution environments are short-lived and may leave only invocation logs, application output, identity events and platform metrics. Investigators should preserve function code, dependency versions, environment configuration, event triggers and relevant logs. A compromised function cannot be understood solely from its final output; the triggering event and permissions granted to its execution identity are equally significant.

Shared Responsibility and Provider Dependency

The shared-responsibility model divides security obligations between provider and customer, but the boundary varies by service. It should not be mistaken for a complete forensic agreement. A customer may be responsible for enabling logs, selecting retention, protecting credentials and requesting preservation, while the provider controls infrastructure telemetry, clock synchronisation, physical access and some incident records.

Before an incident, organisations should establish a cloud forensic readiness plan containing:

• a map of services, accounts, tenants, regions and dependencies;
• ownership of logging, retention and export functions;
• emergency contacts and provider escalation paths;
• legal authority and procedures for cross-border data requests;
• approved methods for isolating accounts, workloads and storage;
• time-synchronisation and naming conventions; and
• rules for preserving evidence without destroying volatile data.

Provider terms may restrict scanning, memory acquisition, deception systems or access to other tenants. Contracts should address log availability, retention, export formats, service-level commitments, incident notification, preservation requests, audit support, sub-processors and the evidential status of provider-generated records. Where a provider cannot disclose underlying data, its signed report, preservation statement or service attestation may still be valuable, but investigators must record the limitations.

Evidence Acquisition in Cloud Investigations

Cloud acquisition is best treated as a staged process rather than a single collection event. The first stage is scoping: identify affected identities, resources, regions, time windows and possible legal constraints. The second is preservation: prevent deletion or alteration through retention locks, legal holds, snapshots, account suspension procedures or provider preservation requests. The third is collection: export records using documented APIs or approved tools. The fourth is validation and correlation.

Volatility should guide priorities. Active sessions, temporary credentials, running processes, orchestration state and short-retention logs may require immediate attention. At the same time, disabling an account may destroy session evidence or trigger automated deletion. Response actions should therefore be sequenced deliberately. For example, investigators may first record active sessions and access tokens, preserve logs and snapshot a workload, then revoke credentials and isolate the resource.

Cloud timestamps commonly involve UTC, local time, browser time or service-specific formats. Every timeline should state the time standard and account for clock skew. Correlation should distinguish an event time, ingestion time, export time and analyst processing time. An access record created at 10:00 and exported at 10:20 is not evidence that the activity occurred at export time.

Mobile Forensics in a Cloud-Connected World

Mobile devices combine endpoint evidence, application data, communications records, sensor information and cloud synchronisation. The investigator must decide whether the priority is preservation of the device state, acquisition of volatile data, prevention of remote wiping or recovery of a cloud-backed record.

A basic mobile acquisition plan identifies the device model, operating-system version, lock state, power state, network connections, SIM or eSIM information, associated accounts and potential remote-management controls. Unnecessary interaction should be avoided because opening applications, unlocking the device or connecting it to a network may alter metadata, trigger synchronisation or overwrite temporary records.

Mobile acquisition methods vary. A logical acquisition collects accessible files and records through supported interfaces. A filesystem acquisition provides deeper access where authorised tools and device conditions permit. A physical acquisition attempts to obtain storage contents but may be impossible because of encryption, secure hardware or modern operating-system protections. Backup acquisition can be valuable, but a backup is an artefact produced by a system and should not automatically be treated as a complete copy of the device.

Important evidence may exist outside the handset. Messaging databases, cloud photographs, location histories, mobile-device-management records, application servers and authentication providers can corroborate or contradict local evidence. Investigators should document whether synchronisation was active and whether timestamps reflect message creation, receipt, modification or download.

Encryption and biometric controls create legal and ethical issues. Investigators must act under appropriate authority and avoid coercive or technically unauthorised methods. Privacy minimisation is particularly important because mobile devices contain information about people who are not subjects of the investigation.

IoT Evidence: Small Devices, Large Systems

IoT investigations are complicated by scale and heterogeneity. A sensor, camera, smart meter or medical device may have minimal storage and weak security, while its platform stores richer records. Evidence may be located in device flash memory, gateway logs, wireless controllers, mobile applications, vendor clouds, DNS records and network telemetry.

The first task is to understand the device ecosystem. A device identifier alone is insufficient; investigators should map firmware version, owner, gateway, communication protocol, cloud tenant, time source and data path. Physical seizure may destroy power-state evidence or interrupt a safety or monitoring function. In some cases, collecting network traffic and platform records is preferable to immediately disconnecting the device.

IoT data should be interpreted cautiously. A sensor reading may reflect a measurement, a cached value, a recalibrated value or a value transformed by a gateway. Missing data may indicate power loss, network failure, storage limits or deliberate interference. Proprietary formats and vendor-controlled services can make independent validation difficult. Investigators should retain native exports where possible, record decoding tools and preserve a readable derivative for analysis.

Operational-Technology Forensics and the Safety Imperative

OT systems control or monitor physical processes such as manufacturing, energy, water treatment, transportation and building management. They include programmable logic controllers, supervisory control and data acquisition systems, distributed control systems, engineering workstations, historians, human-machine interfaces and industrial network devices.

In IT environments, isolation and scanning are often routine. In OT, these actions may cause process instability, loss of visibility or unsafe physical conditions. Availability and safety can take priority over immediate evidence collection. An incident handler must coordinate with process engineers, control-room operators, safety officers and management before changing configurations or disconnecting equipment.

A prudent OT approach begins with passive observation. Network taps, existing historian data, controller diagnostics, engineering-change records, alarm histories, remote-access logs and physical access records may provide significant evidence without intrusive interaction. If active acquisition is necessary, it should be conducted during an approved maintenance window, with tested recovery procedures and a clear rollback plan.

OT timelines require process context. A command that appears malicious in a network log may be an authorised engineering action, while a seemingly ordinary change may have caused a dangerous process condition. Analysts should correlate cyber events with alarms, operator actions, maintenance schedules, physical sensor readings and changes in production state.

An Integrated Incident-Handling Method

A cross-environment incident requires a coordinated method rather than separate investigations. The following sequence is adaptable to the particular risk profile.

Prepare. Establish asset inventories, cloud contacts, logging standards, mobile-management procedures, IoT ownership and OT safety protocols. Conduct tabletop exercises involving legal, privacy, communications and operational personnel.

Recognise and scope. Determine what is known, what is suspected and what could be affected. Identify identities, devices, workloads, gateways, controllers and providers. Avoid premature attribution.

Stabilise without destroying evidence. Use least-destructive containment. Preserve volatile cloud and mobile state, isolate compromised accounts or network segments where safe, and avoid powering down OT equipment unless safety requires it.

Acquire and preserve. Capture relevant logs, snapshots, configurations, images, backups, network records and provider statements. Record authorisation, methods, tools, hashes, timestamps and custodians.

Analyse and correlate. Build a unified timeline, distinguish facts from inferences, evaluate alternative explanations and identify gaps. Use identity, network, application, host and physical-process evidence together.

Recover and learn. Restore from trusted configurations, rotate credentials, validate safety and monitor for persistence. Conduct a post-incident review that addresses both technical causes and organisational weaknesses such as missing logs or unclear provider responsibilities.

This method reflects the distinction between preservation and containment. A response action can reduce ongoing harm while also changing the evidence. The decision record should explain why the action was necessary, what information may have been lost and how the investigation compensated for that loss.

Illustrative Case Study: Compromise Across a Cloud-Connected Factory

Background

A fictional manufacturer operates a factory with an OT network, cloud-based production analytics and mobile authentication for administrators. Sensors send measurements through an IoT gateway to a cloud platform. Engineers use a SaaS collaboration service and a mobile application for remote alerts. The company retains cloud audit logs for thirty days but has not tested provider exports.

Situation

The plant reports unusual changes in production thresholds. At approximately the same time, an administrator receives repeated mobile authentication prompts and approves one unintentionally. A cloud analytics workload begins making unusual requests to object storage. The security team suspects a stolen identity, but plant personnel warn that disconnecting the gateway could interrupt monitoring.

Analysis

The incident team first identifies the relevant accounts, cloud region, gateway, analytics workload, mobile device and controller-management station. Rather than immediately shutting down the factory network, it asks the control-room operator to confirm process stability and places the affected cloud identity under monitored restriction.

Investigators preserve SaaS sign-in and administrative records, export identity-provider events, snapshot the analytics workload and retain the container image digest and orchestration configuration. They request provider preservation for logs approaching the retention limit. The mobile device is placed in a controlled state to reduce remote wiping and is acquired under organisational authority. Network telemetry shows that the cloud workload accessed storage shortly after the suspicious authentication event.

OT specialists compare engineering-change records with controller configurations and historian data. They find that a threshold change was entered through an authorised engineering account, but the change time corresponds to an anomalous remote session. The plant remains operational because the team uses passive monitoring and a preapproved procedure to restrict the affected remote-access path without disconnecting safety systems.

Approach and Outcome

The combined evidence indicates that an attacker obtained the administrator’s cloud credentials through an approval-fatigue attack, accessed the analytics environment and used a trusted engineering integration to reach the management path. The mobile record corroborates the authentication prompt, while cloud and OT records establish the sequence and impact. Credentials and tokens are revoked, the integration is redesigned with least privilege, retention is extended, and the factory introduces a tested emergency evidence-preservation plan.

Learning Points

The case demonstrates that no single artefact proves the entire event. Mobile, identity, cloud, container, network and OT evidence must be correlated. It also shows why containment cannot be separated from safety. A technically simple action, such as disconnecting an industrial gateway, may create greater operational risk than the original compromise.

Challenges, Limitations and Common Errors

A frequent error is treating a provider dashboard as a complete evidential source. Investigators may also overlook tenant-level retention settings, fail to preserve logs before revoking an account, or confuse a cloud snapshot with an independent physical image. Other mistakes include relying on system time without documenting time zones, collecting only the compromised device while ignoring synchronised cloud data, and interpreting IoT values without understanding calibration or gateway transformation.

Attribution is particularly difficult. Shared accounts, service principals, delegated access, stolen tokens and automated processes can make an event appear to originate from a legitimate user. IP addresses identify network endpoints, not necessarily people. Analysts should express conclusions proportionately, distinguish observed facts from interpretations and identify unresolved uncertainty.

Provider dependence may delay acquisition or limit transparency. Encryption may make data inaccessible, while proprietary formats reduce reproducibility. Legal restrictions can apply to content, subscriber information and cross-border transfers. In OT, safety and production constraints may prevent ideal acquisition. These are not reasons to abandon forensic discipline; they are reasons to document limitations and select alternative sources.

Governance, Ethics and Professional Responsibility

Cloud and mobile investigations often expose personal information, privileged communications and data belonging to unrelated customers. Collection should be authorised, proportionate and limited to a defined purpose. Access should be role-based, logged and reviewed. Sensitive exports require secure storage, controlled sharing and defined destruction procedures.

Organisations should align investigative practice with applicable privacy, evidence, sectoral, employment and critical-infrastructure obligations. Contracts should clarify authority to access provider records and responsibilities for breach notification. Investigators must preserve exculpatory as well as incriminating information and should not manipulate systems merely to obtain a preferred result.

Professional competence includes knowing when not to act. In an OT setting, an investigator who ignores process safety may create physical harm. In a cloud environment, an investigator who changes a configuration without documenting it may compromise both operations and evidence. Escalation to specialists is a professional requirement, not a weakness.

Technology, Automation and Emerging Practice

Security-information and event-management platforms can aggregate cloud, mobile, endpoint, IoT and OT records, but automated correlation depends on reliable identity and time data. Detection engineering increasingly uses cloud-native audit streams, behavioural analytics and graph models to connect accounts, workloads, devices and resources.

Artificial intelligence can assist with timeline construction, anomaly prioritisation, log summarisation and identification of relationships across large datasets. Its outputs must remain reviewable. Investigators should preserve the underlying records, record model versions and prompts where relevant, validate suggested conclusions and avoid treating probabilistic output as a forensic fact.

Current practice is moving toward forensic readiness rather than evidence collection only after an incident. Examples include tamper-evident central logging, short-lived credential monitoring, container admission controls, mobile-management telemetry, IoT asset identity, passive OT sensors and contractual evidence clauses. Confidential-computing architectures, edge processing and automated response may improve protection, but they can also reduce investigator visibility if logging is not designed in advance.

Best-Practice Principles

A mature programme should:

1. Design logging, retention and export capability before an incident.

2. Maintain an architecture and responsibility map for every cloud and connected system.

3. Prioritise volatile evidence while sequencing containment carefully.

4. Preserve native records, readable derivatives and acquisition metadata.

5. Correlate technical evidence with identity, physical and operational context.

6. Use passive and least-disruptive methods in IoT and OT environments.

7. Test provider escalation, legal holds and emergency contacts.

8. Apply least privilege, privacy minimisation and secure evidence handling.

9. Document uncertainty, limitations, transformations and response decisions.

10. Validate automated or AI-assisted findings through qualified human review.

Chapter Summary

Cloud, mobile, IoT and OT investigations require adaptation of traditional forensic principles to distributed, volatile and provider-dependent systems. The shared-responsibility model determines who can preserve and produce evidence, but contractual readiness and technical preparation are equally important. SaaS, PaaS, IaaS, containers and serverless workloads expose different forms of audit, configuration and runtime evidence. Mobile and IoT investigations must account for encryption, synchronisation, limited storage, proprietary formats and privacy. OT investigations place safety and process continuity alongside evidential objectives, often favouring passive collection.

An effective approach scopes the environment, preserves volatile information, acquires evidence through authorised and documented methods, correlates records across layers and distinguishes facts from inferences. Professional practice depends on forensic readiness, careful containment, provider coordination, privacy protection and human oversight of automation. The most reliable investigation is not necessarily the one that collects the most data, but the one that obtains proportionate, authentic and interpretable evidence without creating additional harm.

Key Terms

Cloud forensic readiness: Advance preparation of cloud configurations, logs, contracts and procedures to support an investigation.

Shared responsibility model: Allocation of security and operational duties between a cloud provider and its customer.

SaaS: Provider-managed software accessed as a service, with customer control usually focused on data, users and configuration.

PaaS: A cloud platform for deploying applications while the provider manages much of the underlying infrastructure.

IaaS: Cloud provision of virtualised computing, storage and networking resources.

Ephemeral data: Information that exists temporarily and may disappear when a process, session or workload ends.

Container image digest: A cryptographic identifier used to verify a particular container image version.

Serverless computing: Execution of application functions in provider-managed, event-driven environments.

Logical acquisition: Collection of accessible files, records or backups through supported interfaces.

Filesystem acquisition: Collection of a device’s accessible filesystem structures and data beyond ordinary user-level exports.

IoT: Network-connected physical devices that collect, exchange or act upon data.

Gateway: An intermediary that connects devices or protocols to another network or service.

Operational technology: Hardware and software used to monitor or control physical processes.

SCADA: Supervisory control and data acquisition systems used to monitor and control distributed industrial processes.

Forensic provenance: Documented history of an item’s origin, handling, transformation and custody.

Volatility: The likelihood that evidence will change or disappear over time or through system activity.

Provider attestation: A provider-supplied statement or report describing service events, controls or preserved records.

Least-disruptive containment: Restriction of an incident using the smallest practical effect on operations and evidence.

Forensic timeline: A structured sequence of events correlated across systems using documented time references.

Review Questions

Short Answer Questions

1. Why is a cloud snapshot not necessarily equivalent to a physical disk image?

2. What does the shared-responsibility model imply for cloud forensic readiness?

3. Identify two reasons why mobile evidence may exist outside the handset.

4. Why should OT investigations generally begin with passive observation?

5. Distinguish event time, export time and processing time in a forensic timeline.

Long Answer Questions

1. Explain the principal forensic differences among SaaS, PaaS, IaaS, containers and serverless workloads.

2. Develop a staged evidence-acquisition plan for a compromised cloud identity and workload.

3. Discuss the technical, legal and ethical challenges of mobile-device forensics in a cloud-connected environment.

4. Explain how IoT and OT characteristics influence evidence preservation and incident containment.

5. Evaluate the role of contracts, provider escalation and forensic readiness in cloud investigations.

Analytical / Application Questions

1. A container suspected of exfiltrating data is scheduled for deletion in ten minutes. Design an acquisition and containment sequence that preserves volatile evidence while limiting further harm.

2. An industrial facility shows suspicious controller changes, but disconnecting its gateway could remove safety visibility. Decide what evidence should be collected first and justify the response using safety and forensic principles.

3. A mobile authentication approval, a cloud sign-in and an OT configuration change appear within the same five-minute period. Explain how you would correlate these records and what alternative explanations must be tested.

22. Multiple Choice Questions with Answers

Question 1

Which statement best explains why cloud forensic readiness must be planned in advance?

A. Cloud systems cannot generate audit records after deployment.

B. Customers may control retention and exports while providers control important underlying evidence.

C. Cloud providers always refuse to support investigations.

D. Cloud evidence is limited to physical server images.

Correct Answer: B. Customers may control retention and exports while providers control important underlying evidence.

Question 2

What should generally be prioritised because it is highly volatile during a cloud incident?

A. Archived compliance reports from five years earlier

B. Printed network diagrams

C. Active sessions, temporary credentials and short-retention logs

D. Unused storage quotas

Correct Answer: C. Active sessions, temporary credentials and short-retention logs

Question 3

Which evidence is particularly relevant when investigating a compromised container workload?

A. Only the container’s display name

B. The image digest, orchestration configuration and runtime events

C. The physical location of the provider’s building

D. A user’s unrelated mobile photographs

Correct Answer: B. The image digest, orchestration configuration and runtime events

Question 4

Why may a mobile-device investigation need cloud-provider records?

A. Mobile devices never store local data.

B. Cloud synchronisation may contain messages, backups or application data absent from the handset.

C. Cloud records automatically identify the perpetrator.

D. Provider records are always more accurate than device records.

Correct Answer: B. Cloud synchronisation may contain messages, backups or application data absent from the handset.

Question 5

What is the safest initial approach for many OT forensic investigations?

A. Immediately reboot every controller

B. Run an unrestricted vulnerability scan across the control network

C. Begin with passive observation and coordinate with process and safety personnel

D. Delete unusual configurations before analysing them

Correct Answer: C. Begin with passive observation and coordinate with process and safety personnel

Question 6

Which statement about hashing is correct?

A. Hashing proves that a user performed an action.

B. Hashing proves that the original system clock was accurate.

C. Hashing helps demonstrate that a preserved copy has not changed.

D. Hashing eliminates the need to document acquisition methods.

Correct Answer: C. Hashing helps demonstrate that a preserved copy has not changed.

Question 7

An IoT sensor reports an unusual value. What is the most appropriate investigative interpretation?

A. The value automatically proves malicious manipulation.

B. The value should be considered alongside calibration, gateway processing and network context.

C. The value is irrelevant unless the device has a large hard disk.

D. The value can be interpreted without identifying the device’s time source.

Correct Answer: B. The value should be considered alongside calibration, gateway processing and network context.

Question 8

Why should investigators distinguish event time from export time?

A. Exports always alter the original event.

B. The time a record is downloaded is not necessarily the time the underlying activity occurred.

C. Event times are never recorded by cloud services.

D. Export time is legally more important in every investigation.

Correct Answer: B. The time a record is downloaded is not necessarily the time the underlying activity occurred.

Question 9

Which response action may create both containment benefits and evidential risk?

A. Documenting the investigation scope

B. Revoking an account or shutting down a workload before preserving volatile state

C. Recording the applicable time zone

D. Preserving a provider escalation contact

Correct Answer: B. Revoking an account or shutting down a workload before preserving volatile state

Question 10

What is the appropriate role of AI-assisted forensic analysis?

A. To replace preservation of original records

B. To provide unreviewed attribution decisions

C. To assist correlation and prioritisation while findings remain subject to human validation

D. To remove the need for chain-of-custody documentation

Correct Answer: C. To assist correlation and prioritisation while findings remain subject to human validation