Forensic Analysis of Windows Subsystem for Android (WSA)
Overview
Microsoft released Windows 11 with a new feature, Windows Subsystem for Android (WSA). This feature enabled users to run Android applications in Windows 11 without involving third-party virtualization software. I believe that digital forensic examiners need to understand this feature as it can be used as a new source of digital evidence in Windows 11 systems. This blog post focuses on some of the critical WSA artifacts and how to extract data from the WSA environment.
Analysis of the WSA Environment
Like any newly implemented feature, there is limited documentation and research regarding WSA. Figure 1 shows two primary layers to be considered during a digital forensic examination of WSA. Windows 11 is the first layer and the overall environment containing all the data, including execution, logging, and registry artifacts. The second layer is the Android environment, which contains user data and the installed applications.
Testing Environment
A Windows 11 environment was used to
generate WSA testing data. WSA was installed along with applications from the Amazon
Appstore and through sideloading. The installation and execution of WSA were
monitored using Procmon to determine the primary locations where related artifacts
can be found. During testing, the focus was on WSA information found in the;
registry, log files, and virtual storage files.
Registry Artifacts
The registry contained information
about all the installed Android applications. The NTUSER.DAT hive is the
primary location where important details about installed applications can be
found. The path for this information is located under Software\Microsoft\Windows\CurrentVersion\Uninstall\.
Each installed application had a separate key. The name of the key matched the application
package name. For instance, Amazon Appstore’s key name is com.amazon.venezia. Table
1 lists important values found in the Amazon Appstore registry key.
Table 1. Values of the Amazon Appstore registry key.
|
Value Name |
Data |
|
AndroidInstallSource |
System |
|
AndroidPackageName |
com.amazon.venezia |
|
AndroidVersionCode |
426010 |
|
DisplayName |
Amazon Appstore |
|
DisplayVersion |
release-60.17.1.0.208834.0_426010 |
|
InstallDate |
20230601 |
|
Publisher |
amazon.com |
The
“AndroidInstallSource” value is significant because it shows how the
application was installed. Amazon Appstore was installed through Microsoft
Store, which explained the “System” value. Other applications were installed through
the Amazon Appstore, and their install source
value was reflected as “com.amazon.venezia.” Testing also showed that the
install source value appeared as “Sideload” if the application was installed
using the sideloading technique. It is worth noting that the “InstallDate” can
be the original install date or the date when the application was last updated.
Table 2 lists significant values found under the registry key of the WhatsApp application,
which was sideloaded into the environment.
Table 2. Values of the WhatsApp registry key.
|
Value Name |
Data |
|
AndroidInstallSource |
Sideload |
|
AndroidPackageName |
com.whatsapp |
|
DisplayName |
WhatsApp |
|
DisplayVersion |
2.23.12.13 |
|
InstallDate |
20230607 |
|
Publisher |
Unknown |
WAS Logging
During testing, Procmon showed that the
WSA process interacted with log files located under C:\Users\(user)\AppData\Local\Packages\MicrosoftCorporationII.WindowsSub
systemForAndroid_8wekyb3d8bbwe\LocalState\diagnostics\logcat\. The metadata
of the logs found in the referenced path indicated that a new log file was
generated every time WSA was started. The log file name was the time and date
the file was created in UTC. For instance, the 20230607191940.log file was
created on 7 June 2023, at 7:19:40 PM UTC. I will expand further in a future blog about
the log files and their contents, as they appear to record a great deal of
information worth digging into.
WSA Virtual Disk
Using Procmon to monitor the testing environment revealed a Hyper-V virtual disk located in C:\Users\<user>\AppData\Local\Packages\MicrosoftCorporationII.WindowsSubsystemForAndroid_8wekyb3d8bbwe\LocalCache\userdata.vhdx. The name of the file indicated that it contained user data. A review of the filesystem structure of the userdata.vhdx file revealed that the data was encrypted. According to Microsoft [1], “Windows Subsystem for Android performs per-file encryption that is software-based,” which confirmed that this virtual disk file cannot be examined offline. Figure 2 shows the encrypted data within the /data directory.
User Data Extraction
The only option I found possible to extract data from WSA is live Android Debug Bridge (ADB) extraction. I enabled the Developer option in WSA to allow ADB access to the environment. This option can be enabled from the Developer tab found in the main WAS interface. Figure 3 shows the main interface and the Developer option. The Developer tab also provided the IP address and port number that can be used to interact with the system via ADB.
ADB shell access was successfully obtained, but root access could not be achieved. During testing, attempts to extract a full filesystem or gain privileged access to the environment were unsuccessful. I navigated to many directories located under the root directory and attempted to list and copy the contents, but the lack of privileged access blocked all my attempts. Figure 4 shows the directory listing of the root directory.
During the review of WSA diagnostic logs, a mount point was
provided for a directory path within the data directory in the WSA
filesystem. Figure 5 shows a snapshot of the log entries listing the mount point
for user 0.
Using the information obtained from the
diagnostic logs, I conducted an ADB pull of the /storage directory using the adb
pull /storage command. However, the content of the extraction revealed that
it was partial and not complete data extraction, which means that a great deal
of data was not pulled from the environment. Figures 6 and 7 show user data
extraction from WSA.
As mentioned previously, WhatsApp application was
installed in the environment, and messages were exchanged from within the
application. However, due to the lack of privileged access to the WSA environment,
WhatsApp messages were not included in the extraction, along with much more
data related to the user and system.
WSA Impact on Digital Forensics
WSA was implemented by Microsoft to allow Android applications to function in Windows. This means that digital
forensic examiners have a new source of data related to Android applications
found in Windows systems. Due to file-based encryption, a live ADB extraction would
have to be conducted to extract partial user data from the WSA environment.
Further testing and research are necessary to determine the possibility of
obtaining privileged access to the Android environment in Windows.
Reference:
[1] Microsoft (2023). Windows Subsystem for Android. https://docs.microsoft.com/en-us/windows/android/wsa/