11.3 Mobile Device Isolation, Acquisition, and Incident Handling

Mobile Device Isolation, Acquisition, and Incident Handling

A mobile device is simultaneously an encrypted computer, a radio, an identity token, and a gateway to cloud data. An impulsive action can lock the examiner out, trigger a remote command, drain the battery, or change application databases. The first responder's task is therefore to preserve options: document the observed state, prevent unauthorized network change when feasible, maintain custody, and transfer the device to a validated mobile-forensics workflow.

Android and iOS Security Boundaries

Both platforms isolate applications and protect keys, but implementation and device state determine acquisition options.

• Android: Each application normally runs under a distinct Linux user identifier in a sandbox. Android Keystore keys may be hardware-backed by a Trusted Execution Environment or secure element. File-Based Encryption can protect different credential-encrypted and device-encrypted data classes. Vendor, OS version, patch level, bootloader state, and whether the user has unlocked the device since boot all matter.
• iOS and iPadOS: Application containers, entitlements, Data Protection classes, the Keychain, and the Secure Enclave restrict access to files and keys. A powered-off or restarted device may be in a more restrictive Before First Unlock state; a device already unlocked since boot can expose more data to an authorized extraction.

A statement such as “physical acquisition gets everything” is therefore wrong. Raw encrypted flash may yield ciphertext without hardware-bound keys, while a supported file-system extraction from an unlocked device may produce far more usable records.

First-Responder Documentation

Before interacting, photograph the front, back, cables, connected peripherals, and screen. Record:

• date, time, displayed clock, battery level, lock or unlock state, and whether the device appears powered on;
• cellular service, Wi-Fi, Bluetooth, airplane-mode indicators, and visible VPN or hotspot state;
• notifications, active application, incoming call or message activity, and any countdown or remote-management warning;
• make, model, serial or asset tag visible without unnecessary navigation, SIM or removable-media status, and the identity of every handler;
• each button press, cable connection, radio change, and reason for the action.

Do not browse applications, guess passcodes, root or jailbreak the device, or connect it to an untrusted workstation. Those actions can change evidence, consume an exploit opportunity, or trigger data deletion.

Choosing a Network-Isolation Method

NIST mobile-forensics guidance describes multiple isolation choices rather than one mandatory step:

The responder follows the laboratory's device-specific decision tree and legal authority. If shielding is chosen, test the container, verify that calls or messages do not reach the device where procedure permits, monitor heat and battery, and use an approved filtered power solution when maintaining power is necessary. GPS reception is not itself a remote-wipe channel; the isolation objective is preventing network communication and state changes.

Enterprise Mobile Device Management (MDM) creates another tradeoff. Administrators may be able to lock, retire, or wipe a device, but issuing those commands destroys or changes evidence. Coordinate with the incident commander, legal counsel, device owner, and MDM administrator so preservation holds and session revocation occur deliberately.

Acquisition Levels and Evidence Sources

• Manual examination photographs visible content through the interface. It is limited and highly interactive but may preserve information that no tool can parse.
• Logical acquisition requests records through supported operating-system, backup, or application interfaces. It commonly returns contacts, messages, media, and selected databases.
• File-system acquisition obtains a broader directory and metadata view when the device and tool support it, often including application containers and deleted database rows that remain within allocated files.
• Physical acquisition reads raw storage. On older or vulnerable devices it may expose unallocated data; on modern encrypted devices it may produce limited ciphertext.

Hash acquired containers where the tool supports it, retain tool and adapter versions, preserve extraction logs, and record errors or inaccessible data classes. A forensic extraction is not necessarily bit-for-bit identical to dynamic flash storage; report exactly what the method collected.

The handset is only one evidence source. Correlate synchronized cloud backups, enterprise email and chat archives, identity-provider sessions, MDM compliance and command logs, mobile threat-defense alerts, carrier records obtained through proper process, Wi-Fi authentication, and paired desktop backups. Cloud data may reside in another jurisdiction or account and often requires separate consent, warrant, subpoena, or enterprise authority.

Malware and Zero-Click Investigations

Commercial spyware may leave sparse, short-lived traces. Preserve crash and diagnostic logs, suspicious process or network indicators, configuration profiles, VPN settings, certificates, calendar invitations, message attachments, and backup artifacts. Absence of a known indicator does not prove absence of compromise; indicator sets are time-bound and attackers change infrastructure.

Containment after acquisition can include revoking enterprise sessions, rotating exposed tokens, removing unauthorized profiles under a controlled remediation plan, updating the OS, or replacing the device. Preserve a verified extraction and investigation record before remediation. The exam-safe sequence is: document, choose and verify isolation, maintain custody and power appropriately, acquire with a validated method, correlate external sources, then remediate.