18.2 Virtualization, Container & Microservices Forensics, Bluetooth and Electron Chat Applications

18.2 Virtualization, Container & Microservices Forensics, Bluetooth and Electron Chat Applications

Quick Answer: Blueprint Domain 4 lists virtualization forensics, forensic methodologies for containers and microservices, Bluetooth forensics, and Electron applications and chat application forensics among the investigative methodologies. The unifying theme is ephemerality: a container's writable layer, a suspended VM's memory file, and an Electron app's LevelDB cache all vanish or mutate quickly. The single highest-value trick in this section is that suspending a VMware virtual machine writes its full RAM to a .vmem file — a complete memory image obtained without touching the guest.

---

Virtualization Forensics

VMware File Types

[!IMPORTANT] Suspending a VM is a memory acquisition technique. Suspend writes the entire guest RAM to .vmem, so an examiner can obtain a memory image with no agent inside the guest, no acquisition tool footprint, and no anti-forensic interference from the guest OS. Copy the .vmem and analyze it with Volatility as an ordinary raw memory image. Note the caveat: suspension is an intrusive act on a running system — it is a deliberate, documented decision, not a side effect.

Hyper-V and Others

The Snapshot Chain Problem

Both VMware snapshots and Hyper-V checkpoints work by freezing the parent disk read-only and writing all subsequent changes to a child delta file. The live state is therefore the parent plus every child in order.

Collect the entire chain. A delta .vmdk or .avhdx copied alone is unusable — it contains only changed blocks and has no base. Conversely, a base disk copied alone reflects the state before the incident, which is why an examiner who grabs only the largest file often ends up with the wrong point in time. Preserve .vmsd and the configuration file so the relationships can be reconstructed.

Forensic advantages of virtualization: snapshots give genuine point-in-time evidence; cloning a VM produces a working copy while the original stays untouched; the malware analysis lab depends entirely on snapshot-and-revert.

Forensic disadvantages: thin-provisioned disks may never write deleted blocks to physical storage, so unallocated-space carving yields less; storage deduplication at the datastore level breaks the assumption that a logical block maps to one physical location; and a shared datastore means the physical medium holds other tenants' data, which constrains what may lawfully be imaged.

---

Container and Microservices Forensics

Containers are processes on the host kernel, isolated by namespaces and cgroups, running on a union filesystem: read-only image layers with a thin writable layer on top.

The Evidence Model

Live Container Triage Sequence

docker ps -a                                   # inventory including stopped containers
docker inspect <id>   > /evidence/inspect.json # config, mounts, network, env, start time
docker diff   <id>    > /evidence/diff.txt     # A=added C=changed D=deleted in writable layer
docker logs   <id>    > /evidence/stdout.log   # captured stdout/stderr
docker top    <id>    > /evidence/procs.txt    # processes with HOST pids
docker export <id>    > /evidence/fs.tar       # flattened filesystem, no history
docker commit <id> evidence/case123:t0         # preserves layers AND metadata

[!WARNING] docker kill or docker rm destroys the writable layer irreversibly. In a GitOps or autoscaling environment the orchestrator may do this on its own within minutes (see Section 1.4). The first response action is to cordon the node, suspend reconciliation, and pause rather than kill the container. docker pause uses the cgroup freezer to stop the processes while leaving memory intact.

Kubernetes specifics: the audit log on the API server records every kubectl exec, create, delete, and secret access with the authenticated identity — the equivalent of a control-plane command history and usually the most important single artifact. crictl performs the same inspection where the runtime is containerd rather than Docker. Node-level evidence lives at /var/log/pods/ and in the kubelet journal, and etcd holds cluster state and secrets.

Microservices complications: a single transaction traverses many services, so the timeline must be assembled from distributed tracing (trace and span IDs) and centralized logging rather than from one host; service-mesh sidecars (Envoy) log every inter-service call; and secrets injected as environment variables appear in docker inspect output — which is itself a finding when a secret was never meant to be there.

---

Electron Application and Chat Application Forensics

Electron packages a Chromium renderer and a Node.js runtime into a desktop application. Slack, Discord, Microsoft Teams (classic), Signal Desktop, WhatsApp Desktop, Notion, and many others are Electron apps, which means they leave browser-style artifacts on the desktop.

Where the Data Lives

Base path: %AppData%\<AppName>\ on Windows, ~/Library/Application Support/<AppName>/ on macOS, ~/.config/<AppName>/ on Linux.

Recovery Technique

1. Collect the entire application directory — a LevelDB store is only consistent as a set (.ldb + .log + MANIFEST + CURRENT).
2. Parse with a LevelDB reader (plyvel, ccl_leveldb, Nirsoft/Magnet/Axiom LevelDB viewers). Never open the store with a writable client, which triggers compaction and destroys deleted-record remnants.
3. Carve the .log write-ahead files: deleted and superseded records frequently persist there until compaction, which is the richest source of "deleted" chat content.
4. strings over .ldb files recovers message fragments even where the structure is damaged.
5. Correlate the Chromium Cache for attachments and avatars, and the cookies database for the authenticated account.

Signal Desktop is the instructive special case: messages live in an SQLCipher-encrypted db.sqlite, and the decryption key sits in plaintext in config.json in the same directory (protected on newer builds by OS-level encryption such as DPAPI). Collecting the database without the configuration file yields an undecryptable blob.

---

Bluetooth Forensics

Bluetooth evidence proves proximity and association — that two specific devices were close enough to pair and that a user accepted the pairing.

What it establishes: the device address (BD_ADDR) identifies a specific physical device; the friendly name often embeds the owner's name ("Sarah's AirPods"); pairing timestamps place the two devices in physical proximity at a specific moment. In vehicle infotainment forensics this is decisive — a head unit retains paired phone identities, contact lists, and call logs long after the phone is gone.

Attack-side terminology the exam expects: bluejacking (unsolicited message push), bluesnarfing (unauthorized data theft from a paired or vulnerable device), bluebugging (command execution over the device's control channel), and BlueBorne-class remote code execution in Bluetooth stacks. Address randomization in Bluetooth Low Energy (resolvable private addresses) complicates tracking, but a bonded device stores the identity resolving key, so paired-device records still resolve to a stable identity.