T1546.016
Installer Packages
Adversaries are packaging their fake installers with Microsoft’s latest installer format, MSIX.
Pairs with this songThreat sounds
While they might appear lifeless, MSIX packages are prime delivery vehicles for malicious fake installers.
Analysis
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 nameVersion
: the specific application versionArchitecture
: the processor architecture for which the package is builtResourceId
: a resource package identifier (this field is often empty or neutral)PublisherId
: the hash of the publisher attribute inAppxManifest.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:
- identifying software variants using the same signer in VirusTotal
- 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:
cw5n1h2txyewy | CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US |
8wekyb3d8bbwe | CN=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:
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
- Example:
- 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
- Root:
- 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:
{"Name":"Valve.Steam","Version":"3.0.7.3","Architecture":"x64","Publisher":"CN=IMPERIOUS TECHNOLOGIES LIMITED, O=IMPERIOUS TECHNOLOGIES LIMITED, L=Ringwood, C=GB","PublisherId":"cvpb331a1f8hw","PackageFullName":"Valve.Steam_3.0.7.3_x64__cvpb331a1f8hw","PackageFamilyName":"Valve.Steam_cvpb331a1f8hw","Languages":["ru-RU"],"Capabilities":["runFullTrust","allowElevation"],"CertPublisher":"CN=IMPERIOUS TECHNOLOGIES LIMITED, O=IMPERIOUS TECHNOLOGIES LIMITED, L=Ringwood, C=GB","CertThumbprint":"21A97512A2959B0E74729BE220102AEF1DCF56FD","Applications":{"Id":"Steam","Executable":"AI_STUBS\\AiStubX64Elevated.exe","FullTrust":true,"SHA256":"1EEB2F50BEBBFC02446619841816482C2F9C2CCA702566ECD3473687F56BA279","Publisher":"CN=IMPERIOUS TECHNOLOGIES LIMITED, O=IMPERIOUS TECHNOLOGIES LIMITED, L=Ringwood, C=GB","Thumbprint":"21A97512A2959B0E74729BE220102AEF1DCF56FD"},"PackageFilesFromManifest":["Registry.dat","SteamSetup.exe","SwapRegHelper20.zip","NEW_mormons_v1.ps1","StartingScriptWrapper.ps1","config.json","PsfRuntime64.dll","PsfRuntime32.dll","PsfRunDll64.exe","PsfRunDll32.exe","Assets\\Store50x50Logo.scale-100.png","TRUNCATED FOR BREVITY","Assets\\SteamBadgeLogo.scale-400.png","AI_STUBS\\AiStubX64Elevated.exe","AI_STUBS\\SteamSetup.0.ico","AppxManifest.xml"],"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 aconfig.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 toValve
orSteam
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 byValve
.
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:
- 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. - 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.
Take Action
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.
The Microsoft-Windows-AppXDeploymentServer/Operational
log will also log relevant details when apps are prevented from being installed per policy.
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.
The Microsoft-Windows-AppXDeploymentServer/Operational
log will also log relevant details when apps are prevented from being installed per policy.
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:
WDAC will also log the blocked execution as event ID 3077 in the Microsoft-Windows-CodeIntegrity/Operational
event 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
When disconnected from the network, however, a package with a revoked signature will install and the user will be presented with the publisher information.
Additional references
Visibility
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
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
%ProgramFiles%\WindowsApps\APPNAME_APPVERSIONNUM_APPARCHITECTURE__APPPUBLISHERHASH\EXENAME.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
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
:
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.
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" />
- The
- 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 thestartScript
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
orPsfRunDll64.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
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.
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">
<Extensions>
<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" />
</uap5:AppExecutionAlias>
With the above information, the Python app could then be executed with any of the following command-line invocations:
start shell:AppsFolder\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0!Python
python.exe
python3.exe
python3.11.exe