Installer Packages

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\CodeIntegrity.cat (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\CodeIntegrity.cat.

Installation footprint

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

<Name>_<Version>_<Architecture>_<OptionalResourceId>_<PublisherId>

Example directory name:

Valve.Steam_3.0.7.3_x64__cvpb331a1f8hw 

(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

Subject    : CN=IMPERIOUS TECHNOLOGIES LIMITED, O=IMPERIOUS TECHNOLOGIES LIMITED, L=Ringwood, C=GB

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:

signature:21A97512A2959B0E74729BE220102AEF1DCF56FD

When an MSIX file has any PE files (EXE or DLLs), the app package will also have the following file: AppxMetadata\CodeIntegrity.cat. 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:

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:
  • 1.3.6.1.5.5.7.3.3 – “Code Signing”
  • 1.3.6.1.4.1.311.10.3.6 – “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:
  • 1.3.6.1.5.5.7.3.3 – “Code Signing”
  • 1.3.6.1.4.1.311.76.3.1 – “Windows Store”
  • 1.3.6.1.4.1.311.76.5.100 – “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:
  • 1.3.6.1.5.5.7.3.3 – “Code Signing”
  • 1.3.6.1.4.1.311.76.3.1 – “Windows Store”
  • 1.3.6.1.4.1.311.76.5.200 – “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.

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 1.3.6.1.4.1.311.76.3.1 (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:

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:

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.

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: