Introduction: The Criticality of Android VM Forensics

In the landscape of modern cyber threats, Android virtual machines (VMs) often serve as critical environments, whether for application development, malware analysis sandboxes, or even as targets within a compromised cloud infrastructure. When an Android VM is suspected of compromise, a thorough forensic examination of its artifacts becomes paramount. This expert-level guide details the methodology for reverse engineering and analyzing a compromised Android VM to uncover attacker Tools, Techniques, and Procedures (TTPs), providing actionable intelligence for incident response and threat intelligence.

Understanding the Android VM as a Forensic Target

Unlike physical devices, Android VMs offer unique advantages and challenges for forensic investigators. Common Android VM platforms include Google’s Android Emulator, Genymotion, and custom QEMU/KVM setups. The primary forensic artifacts reside within the VM’s disk image (e.g., QCOW2, VDI, VMDK) and, if available, memory snapshots or dumps.

Key Artifacts to Target:

• Disk Image: Contains the full Android filesystem, including system partitions, data partitions, and user data.
• Memory Dumps: Captures the VM’s active memory state, revealing running processes, open files, network connections, and potentially decrypted data.
• Snapshots: Point-in-time captures of the VM’s state, useful for tracking changes.
• Network Traffic Logs: PCAP files if network monitoring was in place.

Phase 1: Acquisition of VM Artifacts

The first step involves securely acquiring the VM’s disk image and any available memory dumps. It’s crucial to ensure the integrity of these artifacts through hashing.

Acquiring Disk Images:

For VMs running on hypervisors like QEMU/KVM or VirtualBox, the disk image is typically a file on the host system. For example, a QEMU image might be a .qcow2 file, and VirtualBox uses .vdi.

# Example: Copying a QCOW2 disk image from a QEMU/KVM hostsudo cp /var/lib/libvirt/images/android_compromised.qcow2 /mnt/forensic_drive/android_disk_image.qcow2sha256sum /mnt/forensic_drive/android_disk_image.qcow2 > /mnt/forensic_drive/android_disk_image.qcow2.sha256

Acquiring Memory Dumps:

If the VM was paused or suspended, a memory dump might be available. For live systems, tools like virsh dump (for KVM) or specific hypervisor snapshot features can be used.

# Example: Dumping memory from a running KVM VMvirsh dump android_vm_name --memory-only /mnt/forensic_drive/android_vm_memory.dmp--format rawsha256sum /mnt/forensic_drive/android_vm_memory.dmp > /mnt/forensic_drive/android_vm_memory.dmp.sha256

Phase 2: Disk Image Analysis

Once the disk image is acquired, it needs to be mounted and analyzed. Android disk images typically contain several partitions (boot, system, vendor, data, cache).

Mounting the Disk Image:

Tools like qemu-nbd, losetup, and kpartx are invaluable for this step.

# 1. Connect the QCOW2 image as a network block device (NBD)sudo qemu-nbd -c /dev/nbd0 /mnt/forensic_drive/android_disk_image.qcow2# 2. Map partitions from the NBD devicesudo kpartx -av /dev/nbd0# This will create device mappings like /dev/mapper/nbd0p1, /dev/mapper/nbd0p2 etc.# 3. Identify the 'data' partition (often the largest or last primary partition).#    Use `fdisk -l /dev/nbd0` to determine partition types and sizes.#    Let's assume the data partition is /dev/mapper/nbd0pX (e.g., nbd0p5)# 4. Mount the data partitionmkdir /mnt/android_data_rootingsudo mount -o ro /dev/mapper/nbd0pX /mnt/android_data_root

Key Artifacts Extraction and Analysis:

With the partitions mounted, we can now dig into critical areas.

1. Installed Applications:

APKs installed by users or malware reside in /data/app. Examine package names, installation times, and permissions.

ls -l /mnt/android_data_root/data/appdu -sh /mnt/android_data_root/data/app/*# To extract an APK for further static analysis (e.g., using apktool)cp /mnt/android_data_root/data/app/com.example.malware-1/base.apk ~/analysis/malware.apk

2. User Data and Application Sandboxes:

/data/data contains application-specific data, including databases, shared preferences, and cached files. Malicious apps often store configurations or exfiltrated data here.

• Databases (SQLite): Many apps use SQLite. Examine files like /data/data/com.malware.app/databases/malware.db. Use tools like sqlitebrowser.
• Shared Preferences: XML files in /data/data/com.malware.app/shared_prefs/ can reveal configurations, C2 server addresses, or stolen credentials.
• Cache Directories: Look for suspicious downloaded files or temporary artifacts.

find /mnt/android_data_root/data/data/ -name ".db"find /mnt/android_data_root/data/data/ -name "*.xml"

3. System Logs:

While a live logcat is not possible, persistent logs may exist. Kernel logs (`dmesg`) can be found in various locations depending on the Android version and device type, often within debugfs or specific log files.

# Search for log filesfind /mnt/android_data_root -name "*.log" -o -name "logcat"# Specifically look in /data/system/usagestats/ for app usage logs, # though this may require parsing specific protobuf formats.

4. Network Configuration and History:

Examine /etc/hosts for redirects, browser history, and DNS cache files to identify C2 infrastructure or data exfiltration attempts.

cat /mnt/android_data_root/system/etc/hosts# Browse browser history databases (e.g., Chrome's History file in /data/data/com.android.chrome/app_chrome/Default/History)

5. Malware Persistence Mechanisms:

Attackers often establish persistence. Look for:

• Boot-time services: Custom init scripts or modifications to existing ones.
• Accessibility Services: Malicious use of accessibility features.
• Device Admin APIs: Granting unwarranted device administrator privileges.
• Scheduled Tasks: Using JobScheduler or custom alarms.

Phase 3: Memory Analysis (Advanced)

If a memory dump was acquired, tools like Volatility Framework, specifically designed for Android memory forensics, become invaluable. Volatility can help extract runtime information not available on disk.

Using Volatility for Android:

Volatility requires a profile matching the Android OS version and kernel. You might need to build a custom profile if one isn’t readily available.

# Example Volatility commands (assuming an Android profile is loaded)python vol.py -f /mnt/forensic_drive/android_vm_memory.dmp --profile=AndroidX_Y_Z_PROFILE pslist       # List running processesnetscan      # List active network connectionsmodules      # List loaded kernel modulesmalfind      # Identify potentially malicious code injectionsprocdump -p PID -D /tmp/dumps/ # Dump a process's memory

Analyze process trees for suspicious parent-child relationships, network connections for C2 callbacks, and loaded modules for rootkits or unauthorized injections.

Phase 4: Unmasking Attacker TTPs

The goal is to correlate all findings to reconstruct the attacker’s actions:

• Initial Access: How did the malware get onto the VM (sideloaded APK, drive-by download, compromised app store)?
• Execution: What mechanisms were used to run the malicious code?
• Persistence: How did the attacker maintain access (boot-time services, modified system apps)?
• Privilege Escalation: Were any vulnerabilities exploited to gain root access?
• Defense Evasion: Were any techniques used to hide activity (rootkit, obfuscation)?
• Credential Access: Were credentials harvested (keyloggers, phishing apps, shared_prefs)?
• Discovery: What information about the VM or user was gathered?
• Lateral Movement: Did the attacker attempt to move to other systems (less likely in a single VM scenario unless the VM bridged networks)?
• Command and Control: What servers did the malware communicate with?
• Exfiltration: Was any data sent out from the VM?

By mapping these findings to a framework like MITRE ATT&CK for Android, you can develop a comprehensive understanding of the attack chain and gather crucial threat intelligence.

Conclusion

Forensic examination of compromised Android VMs provides a rich source of intelligence for understanding attacker TTPs. By systematically acquiring and analyzing disk images, memory dumps, and other artifacts, security professionals can meticulously reconstruct attack narratives, identify indicators of compromise (IoCs), and bolster defenses against future intrusions. This detailed approach is indispensable for advanced incident response and proactive threat hunting in the mobile ecosystem.