Skip Navigation


Installer Packages

Adversaries are packaging their fake installers with Microsoft’s latest installer format, MSIX.

Pairs with this song

Analysis Icon



Note: Installer Packages is a broadly scoped sub-technique, and so we decided to focus our analysis on emerging tradecraft related to MSIX.

What is MSIX?

MSIX is a packaging format for Windows that eases the packaging, installation, and update process for applications. It is intended to improve upon the limitations of the MSI format. MSIX is an evolution of the APPX format designed originally just for Universal Windows Platform (UWP) applications (i.e., “modern” apps), which were subject to restrictive execution constraints. MSIX makes packaging a software installer easy without imposing execution restraints. As such, it makes for an enticing format for packaging malicious fake installers.

An MSIX file has the .msix file extension but similar file extensions would include any of the following: .appx, .appxbundle, .msixbundle, and .appinstaller. While there are subtle differences between each file type, an actual .msix file can also be renamed to any of those file extensions without affecting installation. An MSIX file is a ZIP file consisting of files related to the installation. The set of files contained within an MSIX file is called an app package. When properly signed, an MSIX will contain the following minimum set of files:

1. AppxManifest.xml

This document specifies how the package is to be installed and executed. When analyzing a suspicious MSIX file, this is the first file that should be inspected.

2. AppxSignature.p7x

This file consists of a code-signing certificate that serves as the publisher of the MSIX file. It also contains the signed hashes of AppxManifest.xml and AppxBlockMap.xml. This file represents the signer of the entirety of the app package. The signature present in AppxSignature.p7x (along with AppxBlockMap.xml) is used to validate the integrity of installation and execution along with AppXMetadata\ (if there are executable files present in the package).

3. AppxBlockMap.xml

This document specifies the files present in the package and their corresponding hashes. It’s used to validate installation and execution of the entire package payload, that is, all files in the app package besides AppxManifest.xml, AppxSignature.p7x, and AppXMetadata\

Installation footprint

When an MSIX is installed, it is installed as a directory in %ProgramFiles%\WindowsApps with the following naming scheme:


Example directory name:


(Note: ResourceId is absent, which is why there are two underscores in a row between the architecture and the publisher ID.)

This naming scheme refers to an application Package Full Name that includes:

  • Name: the application’s name
  • Version: the specific application version
  • Architecture: the processor architecture for which the package is built
  • ResourceId: a resource package identifier (this field is often empty or neutral)
  • PublisherId: the hash of the publisher attribute in AppxManifest.xml

Signature and certificate analysis

The unique signer of an MSIX package is identified by retrieving the signature from the package’s AppxSignature.p7x. Extracting the package signature and analyzing the corresponding certificate for the package will be helpful for:

  1. identifying software variants using the same signer in VirusTotal
  2. distinguishing between Microsoft and non-Microsoft applications


PowerShell can be used to extract signer information using the Get-AuthenticodeSignature cmdlet:

(Get-AuthenticodeSignature AppxSignature.p7x).SignerCertificate | Select-Object -Property Thumbprint, Subject


Example output:

Thumbprint : 21A97512A2959B0E74729BE220102AEF1DCF56FD



The thumbprint value can then be used to identify other signed samples. The following VirusTotal Intelligence query would identify all other files signed by the above signer:


When an MSIX file has any PE files (EXE or DLLs), the app package will also have the following file: AppxMetadata\ This file is signed with the same certificate as AppxSignature.p7x, and it is used to validate the integrity of all PE files in the app package. The .cat file (catalog file) itself consists of the Authenticode hashes of the PE files. The Authenticode hash of a file can be displayed using Sigcheck (sigcheck -a) and inspecting the PESHA1 and PE256 hash values.

Microsoft-specific PublisherId values

It can be useful to be able to identify a Microsoft or Microsoft Store-originating app just based on the PublisherId value in the app package full name or package family name. The following list shows Microsoft-specific publisher IDs and their corresponding publisher name:

cw5n1h2txyewyCN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
8wekyb3d8bbweCN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US


Any other publisher ID likely corresponds to a non-Microsoft app package. Considering the publisher ID is included in the execution path of an app package, knowing when an app is not a Microsoft app is useful for triage.

The AppxSignature.p7x file can help determine the origin of the app. App packages can be classified into the following groups:

  • system apps
  • first-party Microsoft Store apps
  • third-party Microsoft Store apps
  • developer-signed apps
System apps
  • A system app is an app package that is bundled with Windows and receives updates via Windows Update.
  • Unique enhanced key usage object identifier (OID) values:
    • – “Code Signing”
    • – “Windows System Component Verification”
  • Example system apps (by package family name)
    • Microsoft.LockApp_cw5n1h2txyewy
    • Microsoft.Windows.SecureAssessmentBrowser_cw5n1h2txyewy
    • Microsoft.Windows.ParentalControls_cw5n1h2txyewy
    • Microsoft.WindowsAppRuntime.CBS_8wekyb3d8bbwe

Microsoft Store first-party app
  • A first-party Microsoft Store app is a Microsoft application that is often bundled with Windows but can be uninstalled and reinstalled and updated via the Microsoft Store.
  • Unique enhanced key usage OID values:
    • – “Code Signing”
    • – “Windows Store”
    • – “First-Party Store Software”
  • Example Microsoft Store first-party apps (by package family name)
    • Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
    • Microsoft.Paint_8wekyb3d8bbwe
    • Microsoft.WindowsCalculator_8wekyb3d8bbwe
    • Microsoft.WindowsStore_8wekyb3d8bbwe

Microsoft Store third-party app
  • A third-party Microsoft Store app is any non-bundled, non-Microsoft app that originates and is updated via the Microsoft Store.
  • Unique enhanced key usage OID values:
    • – “Code Signing”
    • – “Windows Store”
    • – “Third-Party Store Software”
  • Common subject value: GUID
    • Example: 4975D53F-AA7E-49A5-8B49-EA4FDC1BB66B
  • Common certificate chain:
    • Root: Microsoft Root Certificate Authority 2011
    • Intermediate CA: Microsoft MarketPlace PCA 2011
    • Intermediate CA: Microsoft Marketplace CA G 024
    • Leaf: GUID value
  • Example Microsoft Store third-party apps (by package family name)
    • 4DF9E0F8.Netflix_mcm4njqhnhss8
    • PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0


It is not common for Microsoft Store apps to be installed as .msix files directly, but if they are, they are indicated appropriately as a Microsoft Store App.


Microsoft Store App prompt asking to install Python 3.11

Developer-signed apps

A developer-signed app is an app package where AppxSignature.p7x does not exhibit any of the above signer properties. The most straightforward method of identifying a developer-signed app is when the certificate that signed AppxSignature.p7x does not have the (Windows Store) OID. Every malicious MSIX analyzed by Red Canary has been a developer-signed app. There are legitimate developer-signed apps, however, some of which are the following:

  • Microsoft.WinDbg_8wekyb3d8bbwe
  • MSTeams_8wekyb3d8bbwe
  • Microsoft.MicrosoftEdge.Stable_8wekyb3d8bbwe

Note: In the above examples, the legitimate developer-signed app packages are easily identified as Microsoft-signed, as the package family name ends with 8wekyb3d8bbwe.

Unlike Microsoft Store apps, developer-signed apps will not show Microsoft Store App in the installer UI. Examples:

Screenshot of Microsoft Store app prompt asking to install Steam


Screenshot of Microsoft Store app prompt asking to install Manager

Suspicious MSIX package triage

When analyzing a suspicious MSIX package, it is easy to get overwhelmed when a package contains many files and you’re not sure which ones are relevant. To ease this challenge, we developed a PowerShell triage script called Get-AppPackageTriageInfo to assist with performing initial MSIX installer triage. The only step required to use it is to first rename the .msix file to .zip and extract the contents of the ZIP to a directory.

Here is the output of Get-AppPackageTriageInfo for the following malicious MSIX sample:

  "Name":  "Valve.Steam",
  "Version":  "",
  "Architecture":  "x64",
  "PublisherId":  "cvpb331a1f8hw",
  "PackageFullName":  "Valve.Steam_3.0.7.3_x64__cvpb331a1f8hw",
  "PackageFamilyName":  "Valve.Steam_cvpb331a1f8hw",
  "Languages":  [
  "Capabilities":  [
  "CertThumbprint":  "21A97512A2959B0E74729BE220102AEF1DCF56FD",
  "Applications":  {
    "Id":  "Steam",
    "Executable":  "AI_STUBS\\AiStubX64Elevated.exe",
    "FullTrust":  true,
    "SHA256":  "1EEB2F50BEBBFC02446619841816482C2F9C2CCA702566ECD3473687F56BA279",
    "Thumbprint":  "21A97512A2959B0E74729BE220102AEF1DCF56FD"
  "PackageFilesFromManifest":  [
  "PSFConfiguration":  {
    "Id":  "Steam",
    "Executable":  null,
    "ScriptExecutionMode":  null,
    "StartScriptPath":  "NEW_mormons_v1.ps1",
    "StartScriptArguments":  null,
    "EndScriptPath":  null,
    "EndScriptArguments":  null
  "Metadata":  [
      "Name":  "OperatingSystem",
      "Version":  "10.0.17763.1"
      "Name":  "AdvancedInstaller",
      "Version":  "20.2 (2c3f1cf9)"
      "Name":  "ProjectLicenseType",
      "Version":  "professional"
      "Name":  "SignTool.exe",
      "Version":  "10.0.20348.1"
      "Name":  "MakePri.exe",
      "Version":  "10.0.20348.1"

Notable observations from this sample:

  • When the app is launched, AiStubX64Elevated.exe is what first executes. This is indicative of Advanced Installer PSF execution, which means that there will be a config.json, which indeed there is.
  • NEW_mormons_v1.ps1 executes prior to the execution of the app executable. The contents of the script download and load and execute a malicious .NET app.
  • Based on the metadata, the MSIX was built with Advanced Installer.
  • The app package was built in the Russian language.
  • The publisher CN=IMPERIOUS TECHNOLOGIES LIMITED, O=IMPERIOUS TECHNOLOGIES LIMITED, L=Ringwood, C=GB does not appear to be related to Valve or Steam in any way.
  • The package runs as full trust, which means that it will not run in a restricted container environment.
  • The included SteamSetup.exe is a legitimate installer signed by Valve.

Why do adversaries use MSIX?

MSIX offers the following advantages to an adversary:

  • They can use it to bundle legitimate software alongside malicious code.
  • The Windows App Installer app that is responsible for installing MSIX packages offers an easy and consistent installation experience. There aren’t multiple dialog click-throughs like there often are with MSI installers.
  • MSIX packages are not subject to SmartScreen inspection when Mark-of-the-Web is applied to an MSIX file.
  • Until recently, MSIX packages could be downloaded and installed directly from a web browser using the ms-appinstaller protocol handler.


From an adversary’s perspective though, delivering malicious MSIX packages is not without its risks:

  • The installation artifacts must be installed to disk, so they’re subject to additional scrutiny and will leave more forensic artifacts.
  • In most cases, MSIX packages must be signed with a valid code-signing certificate, which makes it easier for defenders to track adversary operations.

How do adversaries use MSIX?

Nearly every instance of a malicious MSIX package we’ve encountered tricks a victim into installing what they believe is legitimate software. The malicious MSIX package is packaged in one of two ways most often:

  1. The legitimate software is included in the MSIX package, but a malicious PowerShell script executes beforehand by employing the Package Support Framework (PSF). In these cases, the MSIX package includes the malicious script, which is executed as specified in an included config.json file.
  2. The MSIX package only includes a malicious executable without packaging the legitimate software. In these cases, it is unlikely that a PSF PowerShell script will be used.

Adversaries may also utilize the DesktopAppMigration element in AppxManifest.xml to persist a shortcut for the app package to the user’s Start Menu Startup directory.

There are many options available to mitigate or prevent the execution of malicious app packages.

Prevent the installation of apps that do not originate from the Microsoft Store

The installation and execution of apps that do not originate from the Microsoft Store is referred to as “sideloading.” An administrator can disable sideloading in either Group Policy or Microsoft Intune by disabling the AllowAllTrustedApps policy.

Screenshot depicting Steam installation failure due to sideloading

The Microsoft-Windows-AppXDeploymentServer/Operational log will also log relevant details when apps are prevented from being installed per policy.

Screenshot of Microsoft-Windows-AppXDeploymentServer/Operational log

Error code 0x80073CFF indicates that the sideloading policy prevented successful installation.

Prevent non-admins from installing app packages

Administrators can deploy the BlockNonAdminUserInstall policy in either Group Policy or Microsoft Intune, which will prevent non-admin users from installing app packages.

Screenshot depicting Steam installation failure with Access Denied error message

The Microsoft-Windows-AppXDeploymentServer/Operational log will also log relevant details when apps are prevented from being installed per policy.

Screenshot of The Microsoft-Windows-AppXDeploymentServer/Operational log

Employ Windows Defender Application Control (WDAC)

WDAC is extremely effective at blocking the execution of unauthorized app packages. Note that WDAC will block execution; it will not block the installation of unauthorized packages. When WDAC blocks execution, the user will be presented with the following dialog:

Windows Defender Application Control dialog box showing block

WDAC will also log the blocked execution as event ID 3077 in the Microsoft-Windows-CodeIntegrity/Operational event log:

Screenshot of event ID 3077 in the Microsoft-Windows-CodeIntegrity/Operational log

Validate MSIX packages with revoked signatures

MSIX packages that were signed with a revoked signature will fail to install when a network connection is active to validate revocation. Performing a UI install of the revoked package won’t reveal the fact that the package was revoked but installation with Add-AppPackage in PowerShell makes the error explicit:

PS > Add-AppPackage -Path Steam-x64.msix

Add-AppPackage : Deployment failed with HRESULT: 0x800B010C, A certificate was explicitly revoked by its issuer.

error 0x800B010C: Opening the package from location Steam-x64.msix failed.                                                                            NOTE: For additional information, look for [ActivityId] 4856f352-3f24-0001-fbd6-5948243fda01 in the Event Log or use the command line                 Get-AppPackageLog -ActivityID 4856f352-3f24-0001-fbd6-5948243fda01                                                                                    At line:1 char:1                                                                                                                                      + Add-AppPackage -Path Steam-x64.msix

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : NotSpecified: (C:\Test\Steam-x64.msix:String) [Add-AppxPackage], Exception

+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand

Visibility icon


Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

File monitoring

An MSIX package is a zip file that is written to disk, extracted and installed to %ProgramFiles%\WindowsApps. Files are subsequently executed from within that directory.

Process monitoring

MSIX installation and execution spawn several processes as described in the Collection section.

Command monitoring

Process command line strings will indicate app package execution when %ProgramFiles%\WindowsApps is in the command-line path. If PSF is also used, the powershell.exe processes will indicate which script executed from disk.

Script monitoring

When PSF is used, PowerShell scripts execute from disk.

Collection Icon


Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Process telemetry

Process telemetry is valuable for observing and detecting suspicious MSIX activity, which is collected by countless tools and log sources. There are two primary methods of MSIX installation and execution: interactive execution via a user double-click and PowerShell installation with the Add-AppPackage (aliased to Add-AppxPackage) cmdlet.

Method #1: Interactive Double-Click

When a full-trust (most common in malicious MSIX files) MSIX is launched interactively (via a user double-clicking), the following process hierarchy template is exhibited:

  • %windir%\system32\svchost.exe -k netsvcs -p -s UserManager
    • %windir%\system32\sihost.exe
      • %ProgramFiles%\WindowsApps\Microsoft.DesktopAppInstaller_APPVERSIONNUM_APPARCHITECTURE__APPPUBLISHERHASH\AppInstallerFullTrustAppServiceClient.exe


Example process hierarchy from a malicious installer:

  • C:\Windows\system32\svchost.exe -k netsvcs -p -s UserManager
    • C:\Windows\system32\sihost.exe
      • C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.21.3482.0_arm64__8wekyb3d8bbwe\AppInstallerFullTrustAppServiceClient.exe
      • C:\Program Files\WindowsApps\Valve.Steam_3.0.7.3_x64__cvpb331a1f8hw\AI_STUBS\AiStubX64Elevated.exe


Screenshot of malicious installer process tree


Note: AppInstallerFullTrustAppServiceClient.exe runs side by side with the malicious executable, AiStubX64Elevated.exe in this case. Both are child processes of sihost.exe. All the PowerShell and other child processes in the above screenshot are specific to the execution of this malware.

Method #2: PowerShell Installation

When an MSIX is installed using the Add-AppPackage, the AppX Deployment Service (AppXSVC) is responsible for writing the package files (Command line: C:\Windows\system32\svchost.exe -k wsappx -p -s AppXSvc). Add-AppPackage will not launch the app though.

There are many different methods of launching the app, but PowerShell can be used to execute an app directly by specifying the app Package Family Name and the Application ID to execute. For example:

Start-Process -FilePath 'shell:AppsFolder\Valve.Steam_cvpb331a1f8hw!Steam'

The process hierarchy will be the same as above but it will launch from explorer.exe instead of sihost.exe:

Screenshot of malicious installer launching from sihost.exe

Event Log

As indicated in the Mitigation section, the Microsoft-Windows-AppXDeploymentServer/Operational event log is extremely valuable at highlighting app package installation both successful and failed (as in cases where mitigations successfully blocked installation).

When PSF PowerShell scripts are used, they will be logged as Microsoft-Windows-PowerShell/Operational event ID 4104 scriptblock events just like any other PowerShell script execution. PowerShell code is also subject to AMSI introspection by endpoint security products.

Icon-threat detection

Detection opportunities

Some of the following detection strategies may be feasible within your enterprise:

Alert on .msix file creation in user-writable directories

This will not indicate suspicious behavior on its own, but in environments where MSIX packages are not expected to be installed outside of the Microsoft Store, this heuristic could be valuable.

Alert on app package process path execution where the app is not a Microsoft app based on the Publisher ID

When a process path contains %ProgramFiles%\WindowsApps but does not contain one of the Microsoft publisher IDs (8wekyb3d8bbwe or cw5n1h2txyewy), consider alerting if you do not expect non-Microsoft apps to run.

Consider detecting app packages built with Advanced Installer that run PSF PowerShell scripts

Look for execution of any of the following executables:

  • *\AI_STUBS\AiStubX64Elevated.exe
  • *\AI_STUBS\AiStubX86Elevated.exe
  • *\AI_STUBS\AiStubX64.exe
  • *\AI_STUBS\AiStubX86.exe

Common malware patterns

The following patterns have been observed in MSIX malware that Red Canary has analyzed:

  • They are typically built with Advanced Installer, which will include uniquely identifying metadata in the app package. Example: <build:Item Name="AdvancedInstaller" Version="20.2 (2c3f1cf9)"/>
    • The 2c3f1cf9 appears to correspond to a specific installation of Advanced Installer, which can help to uniquely identify threat actors in addition to signer information.
    • Many legitimate MSIX files are built with Visual Studio and will bear metadata accordingly. Example: <build:Item Name="VisualStudio" Version="17.0" />
  • They typically include a Package Support Framework (PSF) PowerShell script. This information is contained within config.json, and the script is most often configured to run via the startScript property.
  • A hallmark execution artifact of Advanced Installer PSF execution is the execution of any of the following EXE paths:
      • *\AI_STUBS\AiStubX64Elevated.exe
      • *\AI_STUBS\AiStubX86Elevated.exe
      • *\AI_STUBS\AiStubX64.exe
      • *\AI_STUBS\AiStubX86.exe
    • These will all have an original filename of popupwrapper.exe.
    • Additionally, PsfRunDll32.exe or PsfRunDll64.exe will execute as a child process of the AiStub processes.
  • Most malicious app packages will run as full trust so that they are not bound by app container restrictions. An application runs as full trust when either of the following attributes are specified in the Application element in AppxManifest.xml:
    • EntryPoint="Windows.FullTrustApplication"
    • uap10:TrustLevel="mediumIL"
    • An artifact of full trust execution is that %ProgramFiles%\WindowsApps\Microsoft.DesktopAppInstaller_APPVERSIONNUM_APPARCHITECTURE__APPPUBLISHERHASH\AppInstallerFullTrustAppServiceClient.exe is executed.

Testing Icon


In order to test the installation and execution of MSIX app packages, you’ll need an existing .msix file to work with or you can package one yourself using MakeAppx.exe or Advanced Installer.

One way to obtain legitimate app package files (.msix or .appx) is from this online link generator for Microsoft Store apps. The site accepts both Microsoft Store app download links and the package family name of an existing app which can be retrieved with the Get-AppPackage cmdlet.

For example, if you were to obtain the MSIX for the Python app, it could then be installed outside of the Microsoft Store.

There are two primary methods of installing an app package:

UI Installation

Simply double-click the file to install and optionally launch it.

Microsoft Store App prompt asking to install Python 3.11

PowerShell Add-AppPackage Cmdlet
> Add-AppPackage -Path PythonSoftwareFoundation.Python.3.11_3.11.2032.0_x64__qbz5n2kfra8p0.Msix
> Get-AppPackage -Name PythonSoftwareFoundation.Python.3.11

Name              : PythonSoftwareFoundation.Python.3.11
Publisher         : CN=4975D53F-AA7E-49A5-8B49-EA4FDC1BB66B
Architecture      : X64
ResourceId        :
Version           : 3.11.2032.0
PackageFullName   : PythonSoftwareFoundation.Python.3.11_3.11.2032.0_x64__qbz5n2kfra8p0
InstallLocation   : C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.11_3.11.2032.0_x64__qbz5n2kfra8p0
IsFramework       : False
PackageFamilyName : PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0
PublisherId       : qbz5n2kfra8p0
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

To launch the app, it can be executed from the Windows Menu. Alternatively, app packages can be executed at the command-line via an execution alias (if they have one defined) or by specifying the application name along with the package family name. This information can be obtained from the package’s AppxManifest.xml file. Here is a portion of an Application element that supplies the information needed:

<Application Id="Python" Executable="python3.11.exe" EntryPoint="Windows.FullTrustApplication" desktop4:SupportsMultipleInstances="true">
    <uap5:Extension Category="windows.appExecutionAlias">
      <uap5:AppExecutionAlias desktop4:Subsystem="console">
        <uap5:ExecutionAlias Alias="python.exe" />
        <uap5:ExecutionAlias Alias="python3.exe" />
        <uap5:ExecutionAlias Alias="python3.11.exe" />

With the above information, the Python app could then be executed with any of the following command-line invocations:

  1. start shell:AppsFolder\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0!Python
  2. python.exe
  3. python3.exe
  4. python3.11.exe


Back to Top