Mobile, IoT, Cloud and Virtual Environment Forensics

Introduction and Context

Digital evidence is no longer concentrated in a desktop computer or a single hard disk. Investigations increasingly involve smartphones, wearable devices, smart-home equipment, industrial sensors, virtual machines, containers, software-as-a-service platforms and geographically distributed cloud infrastructure. These environments provide valuable evidence, but they also create technical and legal problems: volatile data may disappear quickly, encryption may prevent access, cloud resources may be shared by several customers, and relevant records may be stored across national borders.

Cyber forensics in these environments therefore requires more than the ability to extract files. An examiner must understand system architecture, acquisition limitations, provider processes, authentication, cryptographic controls, time sources, application behaviour and legal authority. The central principle remains unchanged: evidence must be acquired lawfully, preserved reliably, analysed reproducibly and presented with sufficient context for another competent person to evaluate it.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the forensic characteristics of mobile, IoT, cloud and virtual environments.
2. Select appropriate acquisition methods for different devices and services.
3. Distinguish volatile, persistent, local and provider-controlled evidence.
4. Analyse application artefacts, virtual machines, containers and cloud logs.
5. Address encryption, multi-tenancy, provider dependency and cross-border evidence.
6. Apply sound preservation, validation, documentation and reporting practices.
7. Evaluate ethical, legal, governance and operational risks in contemporary investigations.

1. A Unified Evidence Model

A useful model classifies evidence along four dimensions.

Location. Evidence may be located on the endpoint, on a network, in a provider-controlled service, or in a third-party system such as a payment platform.

Volatility. Volatile evidence includes memory contents, active network sessions, temporary tokens and live cloud instances. Persistent evidence includes flash storage, databases, audit logs and retained backups. Volatile evidence normally requires earlier collection because routine operation can overwrite it.

Control. The investigator may control the device, control an organisational account, depend on a cloud provider, or have no direct control at all. Control determines what can be preserved and which acquisition tools are available.

Interpretability. Raw records require context. A timestamp, for example, may represent event time, ingestion time, device time or provider time. A log entry without knowledge of the relevant time zone, clock synchronisation and retention policy may be misleading.

The forensic process should consequently begin with an evidence map rather than a tool choice. The map identifies assets, owners, custodians, data types, likely volatility, legal authority and preservation actions.

Evidence Sources by Environment

2. Mobile Device Forensics

2.1 Architecture and Evidence Locations

Modern mobile devices combine secure hardware, an operating system, applications, removable or soldered storage, wireless interfaces and synchronised cloud services. Evidence may therefore exist in several places:

• the handset’s file system and application databases;
• secure or protected hardware areas;
• SIM or eSIM-related records;
• paired computers and vehicle systems;
• messaging, social-media and backup services;
• cellular, Wi-Fi, Bluetooth and location-provider records.

Application data is frequently stored in SQLite databases, JSON files, key-value stores, caches and encrypted containers. Deleted records may remain in database free pages, write-ahead logs or unallocated storage, although modern flash storage and garbage collection can reduce recoverability.

2.2 Acquisition Methods

Manual acquisition records what is visible through the user interface. It is useful for documenting screen content but has limited completeness and weak repeatability.

Logical acquisition requests selected files, databases, contacts, messages or metadata through the operating system or an authorised interface. It is generally less invasive but may omit deleted data and protected application areas.

File-system acquisition obtains a broader representation of directories, metadata and application stores. It may require elevated privileges, a forensic agent or exploitation of a permitted service interface.

Physical acquisition attempts to obtain a bit-level representation of accessible storage. It is technically difficult on modern devices because of hardware encryption, secure boot, key derivation and flash translation layers.

Cloud-assisted acquisition obtains synchronised data from a provider using valid credentials, legal process or an enterprise export. It must not be confused with a complete image of the handset: synchronisation is selective and may alter data or omit local-only content.

The examiner should document the device state before acquisition: make, model, serial number, operating-system version, power state, network connections, lock state, displayed time and visible notifications. Unnecessary interaction can change evidence. If the device is unlocked, isolation from networks may prevent remote wiping, but isolation itself can alter connection records. The response must therefore be risk-based and documented.

2.3 Mobile Artefact Interpretation

A message may have multiple representations: a local database record, notification, cloud copy, attachment, thumbnail and backup entry. Investigators should correlate these sources rather than treating one artefact as complete.

Location evidence also requires caution. GPS coordinates may be direct measurements, estimated positions, geofences or application inferences. Wi-Fi and cell-site information provide different precision levels. A location timestamp does not necessarily prove that a person physically handled the device; automated synchronisation and background services can generate records.

A basic integrity check uses a cryptographic hash. For a file or acquired image, a hash function produces a fixed-length digest. If the same input is processed by the same approved algorithm, identical inputs should produce identical digests; however, a matching hash proves integrity relative to the hashed object, not authenticity, ownership or truth of the content.

2.4 Mobile Encryption and Authentication

Full-disk or file-based encryption can make a powered-off device inaccessible without a passcode or hardware-backed key. Examiners must not assume that a lawful authority automatically defeats encryption. Law, device design and available technical capability are separate issues. Attempts to bypass authentication may trigger lockout, key destruction or remote erasure. Any use of specialised tools must be authorised, validated and recorded.

3. IoT and Embedded-System Forensics

The Internet of Things is a system of interacting sensors, actuators, gateways, mobile applications and cloud services. The “device” under examination is often a distributed ecosystem rather than a single object.

3.1 Evidence Layers

1. Physical layer: sensor state, wiring, storage chips, power conditions and tamper indicators.
2. Firmware layer: boot loaders, operating-system images, configuration, credentials and update history.
3. Network layer: protocols such as MQTT, CoAP, HTTP or proprietary messaging; packet captures; addresses and certificates.
4. Gateway layer: local databases, queues, translated protocols and cached commands.
5. Cloud layer: device registration, telemetry, alerts, user actions and administrative logs.
6. Application layer: dashboards, notifications, automation rules and user accounts.

The relationship between layers is critical. A temperature alert in a cloud dashboard may depend on a sensor reading, gateway conversion, rule-engine decision and notification service. Each step can introduce delay, rounding, transformation or loss.

3.2 Acquisition and Analysis

Investigators should first preserve provider and gateway records because IoT services commonly have short retention periods. Network isolation must be considered carefully: disconnecting a device may stop destructive commands but may also eliminate useful network activity or cause it to reconnect with a new state.

Firmware acquisition can involve vendor update packages, debug interfaces, removable memory or chip-level methods. Firmware should be examined in a controlled environment, preferably using a verified copy. Analysts should identify hard-coded credentials, cryptographic keys, update mechanisms, logs and configuration files. Embedded devices often use weak or incorrect time sources; event ordering may consequently be more reliable than absolute timestamps.

Physical examination may be relevant where an actuator, alarm or sensor state is disputed. Photographs, power conditions, serial numbers and environmental observations should be recorded before disassembly.

4. Cloud Forensics

Cloud computing changes the acquisition relationship. The investigator often does not possess the physical storage and cannot independently image it. Evidence is obtained through provider APIs, administrative exports, legal process, snapshot mechanisms, audit services or incident-response functions.

4.1 Service Models and Evidence

This division is not absolute. Contracts, managed services and tenant settings may change responsibility.

4.2 Cloud Preservation

A preservation request should identify the account, tenant, resources, date range, relevant regions, log categories and expected retention period. It should request preservation before normal retention or lifecycle rules delete evidence. Investigators should record the provider’s response, export method, chain of custody, time standard, identifiers and any transformations applied during export.

Cloud logs are often generated by several services. Identity logs may record authentication; object-storage logs may record access; network-flow logs may show traffic metadata; application logs may show business actions. These records should be correlated using request identifiers, account identifiers, resource IDs and carefully normalised time.

4.3 Multi-Tenancy and Provider Dependency

Cloud hardware is commonly shared among customers. Direct seizure of a physical disk could expose unrelated data and is usually inappropriate. Logical collection, provider-controlled snapshots and narrowly scoped exports reduce this risk. Nevertheless, a provider may lack historical logs, may use undocumented internal processes, or may be unable to provide data in a desired format. The examiner should distinguish provider-generated evidence from investigator-generated interpretation.

A cloud export is not automatically complete. It may exclude deleted objects, transient memory, unmanaged accounts, regional replicas, encryption keys or records held by subcontractors. The report should state scope and limitations explicitly.

4.4 Cross-Border Evidence

Cloud data may be replicated or processed in several jurisdictions. Applicable law can include the law of the investigating state, the location of the data, the provider’s incorporation, the customer’s location and the location of affected persons. Investigators should use appropriate legal channels, mutual legal assistance, recognised production orders or approved organisational processes. Accessing data solely because credentials work may still be unlawful.

5. Virtual Machines and Containers

5.1 Virtual Machine Forensics

A virtual machine (VM) has a guest operating system, virtual disks, memory, virtual network interfaces and configuration metadata. The host or hypervisor may contain additional evidence, including snapshots, event logs, virtual-switch records and management actions.

A forensic acquisition should consider:

• virtual disk files and their format;
• snapshots and differencing disks;
• guest memory, if the VM is running;
• host and hypervisor logs;
• cloud control-plane records;
• time configuration and synchronisation;
• attached storage and virtual network records.

A snapshot is a state-management mechanism, not necessarily a complete forensic image. It may depend on a parent disk, contain inconsistent application state, or change metadata when created. The examiner should preserve the original and work from validated copies.

5.2 Container Forensics

Containers share a host kernel and are usually designed to be replaceable. A running container may disappear during scaling, deployment or failure recovery. Evidence can include container metadata, image manifests, read-only image layers, writable layers, standard output logs, orchestration events, secrets, mounted volumes and host audit records.

Container image layers may preserve older versions of software or accidentally embedded credentials. However, an image is not evidence that a particular container ran at a particular time. Runtime evidence must be linked through container IDs, image digests, orchestration records and host logs.

Kubernetes-like environments introduce control-plane evidence: API-server audit logs, workload specifications, service-account activity, admission events and node records. Collection must respect the separation between cluster-level evidence and tenant-level evidence.

5.3 Live Response and Volatility

Live collection may be necessary for memory-resident keys, running processes, mounted volumes, active connections and ephemeral containers. It also changes the system. A sound procedure establishes authority, records commands and timestamps, captures the least disruptive information first, and preserves command output. Analysts should avoid treating live output as equivalent to a static image.

6. A Forensic Workflow for Distributed Environments

A defensible workflow can be organised as follows:

1. Scope and authority: define the incident, systems, accounts, time range, legal basis and privacy boundaries.
2. Triage and volatility assessment: identify data likely to disappear, including tokens, memory, provider logs and running workloads.
3. Preservation: suspend deletion where possible, issue provider preservation requests, record retention policies and protect originals.
4. Acquisition: select logical, file-system, physical, API, snapshot, memory or network methods according to the environment.
5. Validation: calculate hashes where technically meaningful, verify exports, compare record counts and document tool versions.
6. Normalisation: preserve original timestamps and fields while creating analysis copies with clearly documented conversions.
7. Correlation: connect device, identity, application, network, cloud and host records using identifiers and time windows.
8. Analysis: test competing explanations, identify gaps and distinguish observation from inference.
9. Reporting: state methods, scope, findings, uncertainty, limitations and reproducibility information.
10. Review and release: conduct peer review, retain required material and securely dispose of unnecessary copies.

Time Correlation

Distributed systems often use UTC internally, local display time, monotonic counters or unsynchronised clocks. A defensible timeline records the original timestamp, source time zone, clock offset if known, precision and confidence. If a device clock is observed to be 90 seconds fast, an analyst may create a corrected analytical timestamp, but the original must remain visible and the correction must be explained.

Timeline correlation should not manufacture precision. An event recorded only to the nearest minute should not be reported as occurring at 14:32:07 merely because another system provides seconds.

7. Case Study: Illustrative Smart-Building Investigation

Background

A company reported that an unauthorised person entered a restricted laboratory and altered a network-connected environmental controller. The building used a smart lock, badge readers, temperature sensors, a gateway, a mobile administration application and a cloud management service.

Problem

The organisation initially had a hallway video recording, a cloud alert and a mobile phone belonging to a facilities administrator. It needed to determine whether the administrator had changed the controller remotely and whether the account had been compromised.

Analysis and Approach

Investigators first preserved cloud audit records and exported the gateway database. They documented the mobile phone in an unlocked state, isolated it from networks after considering remote-wipe risk, and acquired authorised application data. The phone contained an authentication token and local notification records, but no direct evidence that the administrator had issued the command.

Cloud logs showed a successful login from an unfamiliar address, followed by a controller change. The provider recorded the account identifier, request identifier and UTC timestamp. Gateway logs showed receipt of the command 18 seconds later. The mobile application had generated a notification only after the cloud action, so the notification was not evidence that the phone initiated the command.

The team compared the cloud login with identity-provider records and found that multi-factor authentication had been bypassed through an existing session token. The token had been issued to a browser on a separate workstation. The workstation’s browser artefacts and endpoint telemetry linked token use to a malicious extension installed the previous day.

Outcome

The evidence supported account-session compromise rather than direct use of the administrator’s phone. The cloud audit trail established the command, the gateway established downstream execution, and endpoint evidence explained how the session token was misused. Investigators reported that the precise physical location of the attacker could not be proven from the cloud IP address alone.

Learning Points

• A mobile notification may be a consequence of an action, not its source.
• Cloud, gateway and endpoint records must be correlated.
• Authentication logs should be interpreted with session and token evidence.
• IP addresses provide investigative leads but rarely establish a person’s identity.
• Provider exports and retention settings should be preserved immediately.

8. Legal, Ethical and Governance Considerations

Investigators must operate within authority, necessity and proportionality. Mobile devices frequently contain intimate personal information unrelated to the investigation. Cloud accounts may include data belonging to employees, customers or other tenants. Collection should therefore be targeted, access-controlled and limited to the authorised purpose.

Important governance controls include role-based access, encryption of evidence at rest and in transit, audit logging, retention schedules, secure transfer, segregation of duties and documented destruction. Organisations should maintain cloud contracts that specify logging, preservation assistance, data location, incident notification, subcontractor use and forensic cooperation.

Privacy law, employment law, computer misuse law, electronic communications rules and evidence rules may all apply. Consent, corporate ownership and technical access are not interchangeable concepts. When evidence crosses borders, legal advice and approved international mechanisms are essential.

Artificial intelligence can assist with classification, translation, anomaly detection and timeline grouping. It should not silently determine evidential truth. AI-generated classifications require validation, provenance, error assessment and human review. Original artefacts must remain available, and reports should identify where automated methods influenced conclusions.

9. Challenges, Limitations and Best Practices

The most significant challenges are strong encryption, proprietary formats, rapidly changing applications, short log retention, cloud replication, shared infrastructure, deleted or ephemeral workloads, weak IoT clocks and incomplete provider visibility. Tool support may lag behind operating-system updates, and a successful extraction can still be incomplete or misinterpreted.

Best practice is to:

• preserve volatile and provider-controlled evidence early;
• use the least invasive acquisition capable of answering the question;
• validate tools against representative versions and document limitations;
• preserve originals and analyse verified working copies;
• maintain a detailed chain of custody;
• correlate independent evidence sources;
• separate facts, interpretations and hypotheses;
• record negative findings and acquisition gaps;
• protect unrelated personal and tenant data;
• obtain specialist legal advice for cross-border and privileged material;
• conduct peer review before presenting conclusions.

Chapter Summary

Mobile, IoT, cloud and virtual environments distribute evidence across devices, applications, gateways, providers, hosts and jurisdictions. Effective forensic work begins with an evidence map that considers location, volatility, control and interpretability. Mobile acquisition ranges from manual and logical methods to file-system and physical techniques, but encryption and secure hardware impose important limits. IoT investigations require analysis across physical, firmware, network, gateway, cloud and application layers. Cloud investigations depend on provider interfaces, preservation requests, scoped exports and careful treatment of multi-tenancy. Virtual-machine and container investigations must address snapshots, memory, image layers, orchestration records and ephemeral workloads. Across all environments, lawful authority, privacy, integrity, time correlation, reproducibility and explicit limitations are essential. Contemporary tools, including AI-assisted analysis, can improve efficiency but cannot replace validation and professional judgement.

Key Terms

Cloud forensics: Examination of evidence held in provider-managed cloud services.

Container: An isolated application environment sharing the host operating-system kernel.

Cryptographic hash: A fixed-length digest used to check whether data has changed.

File-system acquisition: Collection of files, directories and metadata from storage.

Full-disk encryption: Encryption designed to protect storage when the device is not authorised for access.

IoT gateway: A system that connects local devices to networks or cloud services.

Logical acquisition: Collection through operating-system or application interfaces.

Multi-tenancy: Use of shared infrastructure by multiple customers or organisations.

Physical acquisition: Attempted bit-level collection of accessible storage.

Provider dependency: Reliance on a service provider for access, logs, preservation or interpretation.

Snapshot: A recorded state or copy mechanism for a virtual resource.

Volatile evidence: Evidence that may disappear or change when a system is powered down or continues operating.

Virtual machine: A software-defined computer running a guest operating system.

Write-ahead log: A database file that records pending or recent transactions.

Chain of custody: Documentation of evidence possession, handling, transfer and storage.

Firmware: Software embedded in a device’s hardware.

Session token: A credential representing an authenticated session.

Cross-border evidence: Digital evidence stored, processed or controlled across national jurisdictions.

Review Questions

5 Short Answer Questions

1. Why is a cloud export not necessarily a complete image of a customer’s cloud environment?
2. Distinguish logical, file-system and physical mobile acquisition.
3. What types of evidence may exist at an IoT gateway?
4. Why can a container image not by itself prove that a specific container ran?
5. Why should original timestamps be preserved when creating a normalised timeline?

5 Long Answer Questions

1. Explain how encryption, secure hardware and device state affect mobile forensic acquisition.
2. Discuss the forensic implications of cloud multi-tenancy and provider dependency.
3. Compare forensic acquisition of virtual machines with acquisition of containers.
4. Develop a defensible workflow for investigating a distributed smart-building incident.
5. Analyse the legal and ethical issues arising when cloud evidence crosses national borders.

3 Analytical / Application Questions

1. A cloud audit log records a controller change, while a mobile notification appears 20 seconds later. What conclusions can and cannot be drawn, and what additional evidence should be collected?
2. A running container is scheduled for deletion in five minutes. Design a minimally disruptive live-response plan and identify the evidence that may be lost.
3. An IoT sensor and cloud service disagree by three minutes. Explain how you would establish event order and report the uncertainty.

Multiple Choice Questions with Answers

Question 1

Which acquisition method generally provides the broadest representation of accessible mobile storage?

A. Manual acquisition

B. Logical acquisition

C. Physical acquisition

D. Screenshot acquisition

Correct Answer: C. Physical acquisition

Question 2

Why should cloud evidence be preserved promptly?

A. Cloud services never retain logs

B. Retention and lifecycle rules may delete relevant records

C. Cloud data cannot be exported

D. Provider logs always change every second

Correct Answer: B. Retention and lifecycle rules may delete relevant records

Question 3

Which statement best describes multi-tenancy?

A. One customer owns every physical disk

B. Several customers use shared infrastructure

C. A device has several batteries

D. A VM has several operating systems

Correct Answer: B. Several customers use shared infrastructure

Question 4

Which evidence is most likely to be volatile?

A. A retained object-storage file

B. A printed report

C. A running process and its memory

D. A sealed hardware label

Correct Answer: C. A running process and its memory

Question 5

What is a major limitation of an IoT device timestamp?

A. It is always encrypted

B. The device clock may be inaccurate or unsynchronised

C. It cannot be stored electronically

D. It proves the identity of the user

Correct Answer: B. The device clock may be inaccurate or unsynchronised

Question 6

Why is a container image insufficient to prove that a particular container executed?

A. Images contain no software

B. Images identify only the physical rack

C. Runtime execution requires corroborating metadata and logs

D. Containers cannot produce logs

Correct Answer: C. Runtime execution requires corroborating metadata and logs

Question 7

What does a matching cryptographic hash primarily demonstrate?

A. The author’s identity

B. The truth of the file’s contents

C. That the compared data has not changed relative to the hash

D. The legal admissibility of the evidence

Correct Answer: C. That the compared data has not changed relative to the hash

Question 8

Which cloud record is most directly associated with administrative API activity?

A. Identity or control-plane audit log

B. A building temperature reading

C. A mobile wallpaper

D. A printer toner report

Correct Answer: A. Identity or control-plane audit log

Question 9

Which statement about an IP address is most accurate in an investigation?

A. It always identifies a person

B. It can provide a lead but usually does not alone establish the user’s identity

C. It proves physical presence at the keyboard

D. It replaces authentication evidence

Correct Answer: B. It can provide a lead but usually does not alone establish the user’s identity

Question 10

What is the most defensible approach to AI-assisted forensic classification?

A. Accept every automated result without review

B. Delete the original artefacts after classification

C. Validate results, preserve provenance and apply human review

D. Use AI only when no legal authority exists

Correct Answer: C. Validate results, preserve provenance and apply human review