Background
Due to recent events, I became interested in the forensic implications of Universal Windows Platform (UWP) and classic Win32 applications installed from the Microsoft Store. Specifically, I was curious to find out what forensic artifacts were left behind during user interactions with the Microsoft Store as well as explore if it was possible to differentiate between user-initiated actions and those triggered by system processes such as push deployments and Microsoft Store automatic updates.
This post builds on previous research by Riyadh Alsulami, Justin Boncaldo, and Yogesh Khatri on Microsoft Store applications and aims to serve as a guide for investigators on how to leverage various artifacts in cases involving Microsoft Store applications.
Introduction
There are 2 primary methods that a user can install applications from the Microsoft Store. The first and most obvious method is to open the Microsoft Store app, select the desired application, and click “Get”.
Clicking “Get” to install the LinkedIn app from the Microsoft StoreAlternatively, a user can use the Windows Package Manager (WinGet) command line tool that is included by default on modern Windows 10 and 11 systems to search for and install applications from the Microsoft Store.
To search for an application using WinGet, a user can simply open the Command Prompt or PowerShell and run the command:
winget search <App_Name> -s msstore
The command line output will return a list of matching applications from the Microsoft Store along with their App IDs.
Command line output for a winget search of “copilot” applications from the Microsoft StoreTo install an application, the user can run the command:
winget install <App_ID> -s msstore
Apart from these methods, administrators in enterprise environments may pre-install or deploy applications on devices using deployment solutions such as Microsoft Intune, Microsoft Endpoint Manager, and provisioning packages. In most cases, these deployments do not require user interaction and may occur without a user’s explicit knowledge.
Default Installation Locations of Microsoft Store Installed Apps
Based on previous research by Riyadh Alsulami and Yogesh Khatri in documenting Microsoft Store forensic artifacts (see here and here), installed application packages from the Microsoft Store can be found at C:\Program Files\WindowsApps\<Application_Package_Name>.
Within each application folder is an AppxManifest.xml file that contains essential metadata about the installed package, including the application name, publisher, and version.
AppxManifest.xml file for the Microsoft Store WhatsApp Desktop applicationBy examining the NTFS folder creation timestamps of individual application package folders, we can also get an idea of when these applications were installed or last updated on the system.
In addition, user-specific application data can be found under the respective user’s local application folder at %LOCALAPPDATA%\Packages\<Application_Name>.
In his 2019 Magnet User Summit presentation titled “Windows Store & Apps (AppX) Analysis”, Yogesh Khatri provides a detailed overview of what we can expect to find within these user-specific application folders:
Local Application Data for the Notepad X application (Credit: Yogesh Khatri)Using these 2 folders as a starting point, I began to dig around their contents for artifacts that could potentially reveal insights into user interactions with the Microsoft Store as well as how certain applications of interest came to be installed on the system.
Microsoft Store Settings.dat Hive
The settings.dat registry hive, located in the directory %LOCALAPPDATA%\Packages\Microsoft.WindowsStore_8wekyb3d8bbwe\Settings, stores both local and roaming configuration settings for the Microsoft Store application. This includes key information such as the first and last launch times, details of signed-in users (if applicable), and most importantly, the Microsoft Store search history.
The following table outlines key registry values of interest within the settings.dat hive:
In addition to the values outlined in the table above, the Last Write timestamps of the respective registry keys can indicate when a specific configuration setting was updated, for example, when the most recent search term in the Store’s search history was searched.
However, it was found that if the Store’s search history was cleared, the following changes would occur in the LocalState\SearchContainer registry key:
- The SearchHistoryCount value data is reset to 0.
- All SearchHistoryX (e.g. SearchHistory0, SearchHistory1, etc.) entries are overwritten with the most recent search term that was cleared.
- The Last Write timestamp of the SearchContainer registry key is updated to reflect the date and time of the clearing action and cannot be used to reliably determine when the most recently searched term was searched.
Microsoft Store Access
Organizations may opt to restrict access to the Microsoft Store to prevent users from installing unapproved, malicious, or non work-related applications.
On Enterprise versions of Windows, this restriction can be enforced via Group Policy (GPO) by enabling the setting “Turn off the store application” under Computer Configuration\Administrative Templates\Windows Components\Store.
To check if the Microsoft Store has been blocked on a Windows Enterprise system, investigators can examine the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore
If the RemoveWindowsStore value is set to 1, access to the Microsoft Store is disabled.
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStoreWhen users attempt to open the Store under this configuration, they are presented with an error message indicating that the application is blocked.
It is important to note that blocking access to the Microsoft Store application does not fully prevent application installation through alternative mechanisms, such as by using the Windows Package Manager (WinGet). In addition, previously installed Microsoft Store applications will continue to receive automatic updates even when Store access is disabled.
Microsoft Store Automatic Updates
Automatic updates for Microsoft Store applications can be managed via Group Policy (GPO) or through the Microsoft Store Settings menu.
GPO Configuration
Administrators can disable the automatic download and installation of Microsoft Store apps by enabling the “Turn off Automatic Download and Install of updates” setting under:
Computer Configuration\Administrative Templates\Windows Components\Store
Changes to this GPO setting are reflected in the registry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore
Specifically, the AutoDownload value indicates the following update behaviour:
- 2 = Apps will not be updated
- 4 = Apps will be automatically updated
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStoreMicrosoft Store App Settings
In earlier Microsoft Store versions, toggling off “App updates” in the Microsoft Store Settings would permanently disable automatic updates for UWP apps. However, as of August 2025, this option now only pauses app updates for a user-defined duration of 1 — 5 weeks. Permanent disabling of automatic updates is no longer supported.
Toggling off “App updates” in the Settings menu now only pauses app updates between 1–5 weeksPauses to automatic updates are recorded in the registry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallService\State
The AutoUpdatePauseEndTime value reflects the scheduled date when updates will resume.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallService\StateExamining this value allows investigators to determine if automatic updates were paused.
Microsoft Store Jump List Icons
When a user visits an application page in the Microsoft Store, a custom jump list entry is created under the “Recently Visited” category.
LinkedIn application page in the Microsoft Store
Custom Jump List created for the LinkedIn application under the Microsoft StoreSimultaneously, the application’s jump list icon is cached in the folder:
%LOCALAPPDATA%\Packages\Microsoft.WindowsStore_8wekyb3d8bbwe\LocalState\JumpListIcons
Jump List Icon created for the LinkedIn application under the Microsoft StoreEach cached icon filename (e.g. 9WZDNCRFJ4Q7.png) corresponds to the application’s Microsoft Store Product ID. The associated application can be identified by visiting: https://apps.microsoft.com/detail/<ProductID>
Microsoft Store application webpage for the LinkedIn app at: https://apps.microsoft.com/detail/9wzdncrfj4q7By examining the NTFS file timestamps of these cached icons, investigators can gain insight into user activity on the Microsoft Store and reconstruct a timeline of user interactions with specific Microsoft Store applications within the Store:
- Date Created: First time the user visited the application page in the Microsoft Store
- Date Modified: Most recent time that the user visited the application page in the Microsoft Store
Microsoft Store Cached Content
When a user browses or scrolls through the Microsoft Store, images displayed to the user in the app are cached at:
%LOCALAPPDATA%\Packages\Microsoft.WindowsStore_8wekyb3d8bbwe\LocalCache\perUserCache_{Global}
These cached files can provide insight into what the user was viewing.
In addition, the NTFS file creation timestamps of the cached images can serve as evidence of the approximate times that the user interacted with the Store.
As an example, the following cached images correspond to a user scrolling through search results for “icloud” in the Microsoft Store:
State Repository Database
As documented by Justin Boncaldo in his 2018 blog post, the State Repository Database (StateRepository-Machine.srd) located at C:\ProgramData\Microsoft\Windows\AppRepository maintains a log of every application currently installed on the system, including those that were never launched.
In addition to user-installed applications, pre-installed system applications such as Windows Media Player (Microsoft.ZuneMusic) and Bing Search (Microsoft.BingSearch) are also logged in this database.
Within the database, currently installed Microsoft Store applications are primarily tracked across the following tables: Package, PackageFamily, PackageLocation, and PackageUser.
To retrieve a list of currently installed applications on the system, an SQL query originally authored by Mark Mckinnon and later modified by Yogesh Khatri can be used to merge relevant data from these tables.
SQL Query to Retrieve Currently Installed Application Details
SELECT DISTINCT * FROM
(SELECT substr(packfam.PackageFamilyName, instr(packfam.PackageFamilyName, '.') + 1,
instr(packfam.PackageFamilyName, '_') -2 - instr(packfam.PackageFamilyName, '.') + 1 ) as AppName,
datetime((packuser.installTime/10000000) -11644473600, 'unixepoch') InstallTime,
CASE WHEN instr(pack.PublisherDisplayName, 'ms-resource')=0 THEN pack.PublisherDisplayName
ELSE '' END AS PublisherDisplayName,
packfam.PublisherId, packuser.User, userkey.UserSid,
CASE Architecture
WHEN 0 THEN 'X64'
WHEN 9 THEN 'x86'
WHEN 11 THEN 'Neutral'
ELSE Architecture END AS Architecture,
substr(pack.packageFullName, instr(pack.packageFullName, '_') + 1,
instr(substr(pack.packageFullName, instr(pack.packageFullName, '_') + 1), '_') - 1) AS version,
CASE SignatureOrigin
WHEN 3 THEN 'System'
WHEN 2 THEN 'Store'
ELSE 'Unknown' END AS SignatureKind,
packloc.installedLocation
FROM PackageUser packuser, package pack, MrtPackage mrt, packageFamily packfam, packageLocation packloc, User userkey
WHERE packuser.package = pack._PackageId
AND pack.packageFamily = packfam._PackagefamilyId
AND packuser.user = userkey._UserID
AND packloc.package = pack._packageId
AND (pack.resourceId IS NULL OR pack.resourceId = 'neutral')
)
ORDER BY InstallTime ASC;
A subset of currently installed applications on the system returned by the queryKey Caveats:
- The query does not include uninstalled or deleted applications.
- The InstallTime timestamp reflects the installation time of the latest package update for an application and not its original installation time.
To identify uninstalled or deleted applications, I attempted to use a second SQL query provided by Yogesh Khatri that references the DeploymentHistory table in the database but found that it no longer functions reliably on Windows 11 25H2 systems as the table was empty.
SELECT User, HResult,
(SELECT PackageFullName from PackageIdentity
WHERE PackateIdentity._PackageIdentityID=DeploymentHistory.PackageIdentity) as PkgName,
datetime(WhenOccurred / 10000000) - 11644473600, 'unixepoch') when_occurred
FROM DeloymentHistory
In its place, I wrote the following query that references the SRHistory table — a journal-like table which records all actions performed on current and historical applications installed on the system. This includes a log of all actions taken on an application (staging, registration, removal), the action sequence, date and time of each action, as well as the initiating user. Nevertheless, a key limitation of the SRHistory table is that it appears to retain records only for the last 30 days.
SQL Query to Retrieve Application Action History
SELECT
sr._SRHistoryID,
sr."User",
u.UserSid AS UserSID,
sr.HResult,
sr."Action",
CASE
WHEN sr."Action" = 131073 THEN 'Deployment Add'
WHEN sr."Action" = 131076 THEN 'Deployment Stage'
WHEN sr."Action" = 131078 THEN 'Deployment Register'
WHEN sr."Action" = 131083 THEN 'Deployment StageUserData'
WHEN sr."Action" = 131084 THEN 'Deployment PreRegisterPackage'
WHEN sr."Action" = 131099 THEN 'Deployment OnDemandRegisterOperation'
WHEN sr."Action" = 131101 THEN 'Deployment ProvisionPackageOperation'
WHEN sr."Action" = 131105 THEN 'Deployment DeprovisionPackageOperation'
WHEN sr."Action" = 131074 THEN
CASE
WHEN sr."User" = 5 THEN 'Deployment DeStage' /* Customize condition to include all Users corresponding to System SIDs (i.e. S-1-5-18) based on the User-SID mapping found at: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository\Cache\User\Index\UserSid" */
WHEN sr."User" = 4 THEN 'Deployment Remove' /* Customize condition to include all Users corresponding to non-system SIDs (i.e. local or domain users) based on the User-SID mapping found at: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository\Cache\User\Index\UserSid" */
ELSE 'Unknown'
END
ELSE 'Unknown'
END AS Action_Description,
pi.PackageFullName AS PkgName,
datetime(
(sr.WhenOccurred / 10000000) - 11644473600,
'unixepoch'
) AS when_occurred
FROM SRHistory sr
LEFT JOIN "User" u
ON u._UserID = sr."User"
LEFT JOIN PackageIdentity pi
ON pi._PackageIdentityID = sr."PackageIdentity"
ORDER BY when_occurred ASC;
Action History for the WhatsApp application returned by the query from installation to removalTo identify the user responsible for an action, we can view the UserSID column which contains a hexadecimal representation of the user’s security identifier (SID). This can be resolved and converted into a standard SID format using documented methods.
Alternatively, we can simply reference the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository\Cache\User\Data
Here, each user’s SID is documented under the UserSid key value of each user’s respective subkey.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository\Cache\User\DataIdentifying App Installations, Updates, and Uninstallations from the SRHistory Table
Before analyzing the SRHistory table, it may be helpful to briefly review the installation and uninstallation process for AppX/MSIX packaged applications.
Installation Phases
As per Microsoft’s documentation, installing a packaged application involves 2 distinct phases:
- Staging: The application package is copied to the local file system. By default, packages are stored in C:\Program Files\WindowsApps\<package_full_name> with the executable named app_name.exe.
- Registration: Once staged, the application is registered for use on a per-user basis. Registration occurs when a user logs in, and the operating system creates user-specific app data, file type associations, and Start Menu tiles via the App Readiness Service (ARS).
Uninstallation Phases
Uninstalling a packaged application also involves 2 phases:
- Deregistration: The app is removed from the user’s profile, including all user-specific integrations that were added during the registration process. The app is no longer available to the user, though the app package files still exist on the device.
- Destaging: The app package files in C:\Program Files\WindowsApps and all traces of the app are removed from the device.
SRHistory Action Sequences
App Installations
When an application is first installed from the Microsoft Store, the SRHistory table typically records the following action sequence:
Deployment Stage > Deployment StageUserData > Deployment Register
This sequence occurs regardless of whether the application was installed directly from the Microsoft Store or via the WinGet command-line tool.
Action History for installation of the WhatsApp Desktop applicationApp Updates
Conversely, updates of existing Microsoft Store applications generally follow the sequence:
Deployment Stage > Deployment Register
Notably, the Deployment StageUserData action is absent during updates.
Action History for update of the Microsoft Copilot applicationApp Uninstallations
When an application is uninstalled or removed by a user, a single Deployment Remove action is recorded. This applies regardless of the mode of removal, be it the user clicking on “Uninstall” in the Installed Apps system settings panel or via the Remove-AppxPackage PowerShell cmdlet.
Both user-initiated and system-initiated uninstallations (which occur as part of automatic package update actions) generate an action code of 131074 in the SRHistory table. The key distinction between them lies in the User field:
- System-initiated uninstallations: System or LocalSystem SID (S-1–5–18)
- User-initiated uninstallations: Local or domain user SID
Action History for a user-initiated uninstallation of the WhatsApp Desktop application. In this case, the initiating User has a SID value ending in 1001.Microsoft-Windows-AppXDeploymentServer/Operational Event Logs
Besides the SRHistory table in the State Repository Database, the Microsoft-Windows-AppXDeploymentServer/Operational.evtx logs located at C:\Windows\System32\winevt\Logs provide detailed information on application installations and uninstallations.
- Event IDs 400 and 478 record the successful completion of AppX and MSIX deployment tasks, including Deployment Stage, StageUserData, and Register operations. Collectively, these operations can be used to identify newly installed applications.
- Event ID 9644 logs successful package uninstallations and can be correlated with Event ID 400 Deployment Remove operations to identify user-initiated uninstallations.
The following table maps specific Microsoft-Windows-AppXDeploymentServer/Operational.evtx Event IDs to corresponding SRHistory Actions:
Mapping of AppXDeploymentServer/Operational Event IDs to SRHistory ActionsComparing AppXDeploymentServer/Operational Logs to SRHistory Table:
While the SRHistory table requires examining the user’s SID to differentiate between system-initiated and user-initiated uninstallations (both logged as action 131074), the AppXDeploymentServer/Operational logs provide a clearer distinction by having separate deployment operation categories:
- Deployment Remove: User-initiated uninstallations
- Deployment DeStage: System-initiated uninstallations
These distinct categories allow investigators to easily determine the origin of an uninstallation without additional SID analysis.
Case Study: Putting It All Together
Consider a scenario in which an unauthorized instant messaging application was discovered on a user’s system. When questioned, the user steadfastly denies installing the application and claims that he does not know how the application came to be present on his system.
To investigate this case, two parallel lines of inquiry can be pursued:
- Circumstantial Analysis: Identify evidence that may provide insight into the user’s intent or motive.
- Technical Analysis: Determine whether the application installation was initiated by the user or by the system.
By leveraging the forensic artifacts discussed in the preceding sections, as well as additional familiar sources, we can develop a structured plan of action to reconstruct the installation timeline and assess the origin of the application.
Conclusion
Forensic analysis of Microsoft Store applications requires a multifaceted approach that combines registry data, system databases, Windows event logs, and user interaction artifacts. By examining these sources, investigators can determine how and when applications were installed, updated, or removed, and crucially, distinguish between user-initiated and system-initiated actions.
This post offers a practical framework for leveraging key artifacts to reconstruct installation timelines and user behaviour, empowering forensic analysts to uncover actionable insights. As Microsoft continues to evolve the Store platform, continued research and adaptation of forensic methods will remain essential for maintaining investigative accuracy.
Apps Leave Traces: Forensic Insights from the Microsoft Store was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: https://detect.fyi/apps-leave-traces-forensic-insights-from-the-microsoft-store-b771c054c14c?source=rss----d5fd8f494f6a---4