Exploring MSI Files: The Good, the Bad, and the Ugly

22 min readSep 18, 2024

Disclaimer:
The code and techniques provided in this blog are intended for educational purposes only. They are designed to help individuals understand the underlying principles of cybersecurity, ethical hacking, and software development. Under no circumstances should the information or code be used for unauthorized access, illegal hacking, or any activities that violate the law.
The author and publisher do not endorse or condone any illegal activities, and they will not be held responsible for any misuse of the information provided. By reading this article, you agree to use the information solely for lawful and ethical purposes.

An MSI file is a Microsoft Installer file, used for installing software on Windows operating systems.

Origin

Development: MSI files were introduced by Microsoft with the release of Windows 2000 and Windows Installer 1.0. They are a part of the Windows Installer service, which is a component of the Windows operating system used for installing, maintaining, and removing software.
Purpose: The Windows Installer technology standardizes the installation process, ensuring that software can be installed, updated, and uninstalled in a consistent manner across different applications and versions.

Why MSI Files are Required

Standardization: MSI files provide a standardized method for software installation, making it easier for users and administrators to manage software.
Rollback and Repair: Windows Installer supports features like rollback and repair. If an installation fails or if the software becomes corrupted, Windows Installer can revert the system to its previous state or attempt to repair the installation.
Configuration: MSI files support detailed configuration of the installation process, allowing administrators to customize installation paths, feature sets, and other settings.
Uninstallation: MSI files facilitate proper uninstallation, ensuring that all files and registry entries created by the application are removed when the software is uninstalled.
Updates and Patches: MSI files can be used to distribute updates and patches for installed software, ensuring that updates are applied consistently and reliably.

How MSI Files Are Used

Installation: Users or administrators run MSI files to install applications. The Windows Installer service processes the MSI file, executing the installation commands and configuring the system according to the MSI file’s contents.
Administration: IT administrators can use tools like Group Policy or System Center Configuration Manager (SCCM) to deploy MSI files across multiple computers in a network.

Structure of MSI file

An MSI file is a complex database file that conforms to the Windows Installer schema. Its structure can be understood through its main components, tables, and data types. Below is a detailed breakdown of its structure:

Main Components of an MSI File

Database Tables

File Table: Contains information about the files that will be installed, including file names, sizes, and paths.
Component Table: Describes the components of the application and their relationships to features and files.
Feature Table: Defines the features of the application and which components are associated with each feature.
Directory Table: Lists the directories in which files will be installed.
Property Table: Contains property names and values used during installation, such as installation paths.
Shortcut Table: Describes shortcuts to be created on the user’s system.

Custom Actions

Custom actions are scripts or executable programs that run during the installation, upgrade, or removal process. They are defined in the CustomAction Table and executed based on specified conditions.

Dialogs

MSI files can include custom dialogs to guide the user through the installation process. These dialogs are defined in the Dialog Table and are part of the user interface.

Summary Information Stream

This contains metadata about the MSI file, such as the product version, author, and other descriptive information.

InstallScript

Some MSI files include InstallScript code (e.g., written in VBScript or JavaScript) that executes during the installation process.

Transforms and Patches

MSI files can be modified by transforms (MST files) or updated with patches (MSP files). Transforms adjust installation behavior or appearance, while patches update the installed application.

Example: Sample MSI File Structure

Let’s consider a hypothetical MSI file named SampleAppInstaller.msi. Here’s a detailed breakdown of its structure:

File Table

Filename       | FileSize | FilePath
--------------------------------------
SampleApp.exe  | 500000   | C:\Program Files\SampleApp\
README.txt     | 1024     | C:\Program Files\SampleApp\

Component Table

Component      | Directory_ | ComponentId                      | Guid
--------------------------------------------------------------------------
MainAppComponent | INSTALLDIR | {12345678-1234-1234-1234-1234567890AB} | {ABCD1234-ABCD-ABCD-ABCD-1234567890AB}

Feature Table

Feature         | ComponentId                      | FeatureLevel
-------------------------------------------------------------
MainFeature     | {12345678-1234-1234-1234-1234567890AB} | 1

Directory Table

Directory       | DirectoryId | Parent | DirectoryName
------------------------------------------------------
TARGETDIR       | TARGETDIR   | NULL   | Program Files
INSTALLDIR      | INSTALLDIR  | TARGETDIR | SampleApp

Property Table

PropertyName | PropertyValue
-----------------------------
INSTALLDIR   | C:\Program Files\SampleApp\

CustomAction Table

Action       | Type | Source   | Target
----------------------------------------
CustomAction1 | 3074 | CustomScript.vbs |

Dialog Table

Dialog       | DialogId | Title       | ControlId
-----------------------------------------------------
WelcomeDlg   | Welcome  | Welcome to SampleApp | NextButton

Summary Information Stream

Property      | Value
-----------------------
ProductName   | SampleApp
ProductVersion| 1.0.0.0
Manufacturer  | Sample Company

Tools for Viewing MSI File Contents

Orca

A Microsoft tool that allows users to view and edit the tables in an MSI file. Orca is part of the Windows SDK.
Usage: Open Orca, then open the MSI file to explore its tables and data.

InstEd

A third-party MSI editor that provides an interface for viewing and editing MSI file contents.
Usage: Install InstEd, then open the MSI file to navigate its structure.

WiX Toolset

A set of tools for creating MSI files, which also includes utilities for inspecting and modifying MSI files.
Usage: Use Heat.exe and Dark.exe for inspecting MSI files and converting them into XML format for analysis.

MSI Explorer

A tool for inspecting and analyzing MSI files, focusing on a user-friendly interface for exploring the file’s contents.
Usage: Install MSI Explorer, open the MSI file, and view its structure.

Components of MSI

Installation Database: Contains the files, registry keys, and other installation settings.
InstallScript: Optionally includes custom scripts that are executed during the install, upgrade, or uninstall phases.
Installation Logic: Defines how and when files are copied, and how the application is configured.

How Windows OS Handles an MSI File

When Windows OS handles an MSI file for installation, updating, or deletion, it relies on the Windows Installer service (msiexec.exe). This service is responsible for executing the instructions within the MSI file and managing the installation process. Here’s a detailed breakdown of how Windows handles MSI files, focusing on function calls, native APIs, and interactions with system components:

1. Installation

Process Overview

Initialization:

When an MSI file is executed, the Windows Installer service (msiexec.exe) is invoked. It initializes by calling functions from the Windows Installer API (MSI APIs) to read the MSI file and begin the installation process.

Reading MSI File:

The installer reads the MSI file’s database tables using the MsiOpenDatabase API to open the MSI database and MsiDatabaseOpenView to execute SQL queries on the database.

Custom Actions:

Custom actions defined in the CustomAction table are handled. The installer calls MsiDoAction to execute custom actions. These may involve running scripts or executables as defined in the CustomAction table.

File and Registry Operations:

Files: Files listed in the File table are copied to their specified directories. The Windows Installer service calls file system APIs (e.g., CreateFile, WriteFile, CopyFile) to handle file operations.
Registry: Registry changes specified in the Registry table are made using Windows Registry APIs (e.g., RegCreateKeyEx, RegSetValueEx).

UI and User Interaction:

If the MSI file includes custom dialogs (from the Dialog table), the Windows Installer service uses Windows UI APIs to display these dialogs and handle user input.

Commit and Rollback:

Upon successful completion, the installation is committed using MsiCommitTransaction. If errors occur, the installation can be rolled back using MsiRollback.

Key APIs and Function Calls

MsiOpenDatabase: Opens the MSI database.
MsiDatabaseOpenView: Opens a view of the database for executing queries.
MsiGetComponentPath: Retrieves the installation path of a specified component.
MsiInstallProduct: Installs a product from an MSI file.
MsiDoAction: Executes a custom action.

2. Updating

Process Overview

Update Detection:

Updates are applied using patch files (MSP files) or transforms (MST files). The Windows Installer checks for applicable patches using MsiQueryFeatureState and MsiApplyPatch.

Applying Patches:

The installer uses MsiApplyPatch to apply MSP patches. This function updates the MSI database and applies the changes specified in the patch.

Transformations:

Transform files modify the installation database according to the transformations specified. MsiTransformDatabase applies these transformations.

Key APIs and Function Calls

MsiApplyPatch: Applies a patch to an installed product.
MsiTransformDatabase: Applies a transform to the MSI database.
MsiGetPatchInfo: Retrieves information about an installed patch.

3. Deletion (Uninstallation)

Process Overview

Initiation:

To uninstall an MSI-installed application, the Windows Installer service invokes msiexec.exe with the /x command-line switch, specifying the product code.

Uninstallation Process:

Component Removal: The installer refers to the Component table to identify which components to remove. It deletes files using file system APIs and removes registry entries using registry APIs.
Custom Actions: Any custom actions defined for the uninstallation process are executed using MsiDoAction.

Rollback:

If an error occurs during the uninstallation, MsiRollback can be called to revert changes.

Cleanup:

After uninstallation, the installer cleans up by removing shortcuts and other related artifacts.

Key APIs and Function Calls

MsiConfigureProduct: Configures (or uninstalls) a product.
MsiRemovePatches: Removes applied patches.
MsiGetProductInfo: Retrieves product information, useful for uninstallation checks.

Detailed Interaction with System Components

Windows Installer Service (msiexec.exe):

Coordinates all installation, updating, and uninstallation operations.
Utilizes MSI APIs to interact with MSI files and manage the installation lifecycle.

File System:

Managed using standard Windows file system APIs (e.g., CreateFile, WriteFile, DeleteFile).
Handles file copying, deletion, and other operations defined in the File table.

Registry:

Managed using Windows Registry APIs (e.g., RegCreateKeyEx, RegSetValueEx).
Updates and deletes registry entries as specified in the Registry table.

Custom Actions:

May involve scripts or executables that interact with the system beyond the standard installation process.
Executed based on entries in the CustomAction table.

UI Components:

Dialogs and user prompts are managed using Windows UI APIs.
Custom dialogs specified in the Dialog table are presented to the user during the installation process.

Sample MSI File for Notepad++

Below we have discussed a simple WiX source file representing an MSI file for installing Notepad++.

What is a WiX Source File:

WiX (Windows Installer XML) is a toolset that builds Windows installation packages from XML source files.
Purpose: WiX is used to create MSI files by defining the installation logic in XML format. It provides a way to write and manage installation packages in a more structured and readable way compared to manually crafting MSI files.
Components: WiX source files use XML to define the product, package, directories, components, and features, which are then compiled into an MSI file using the WiX Toolset.

How it works:

Write XML: Define installation details in WiX XML source files (.wxs).
Compile: Use WiX tools like candle.exe and light.exe to compile the XML into an MSI package.

candle.exe: Compiles the WiX source file into an intermediate object file.
light.exe: Links the object files into a final MSI file.

Example Commands:

candle.exe NotepadPlusPlus.wxs
light.exe NotepadPlusPlus.wixobj -o NotepadPlusPlus.msi

WiX source file representing an MSI file for installing Notepad++

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="Notepad++" Language="1033" Version="1.0.0.0" Manufacturer="Your Company" UpgradeCode="PUT-GUID-HERE">
    <Package InstallerVersion="500" Compressed="yes" InstallScope="perMachine" />

    <Media Id="1" Cabinet="product.cab" EmbedCab="yes" />

    <Feature Id="ProductFeature" Title="Notepad++" Level="1">
      <ComponentGroupRef Id="ProductComponents" />
    </Feature>

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLFOLDER" Name="Notepad++">
          <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
            <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
          </Component>
        </Directory>
      </Directory>
    </Directory>

    <Fragment>
      <DirectoryRef Id="INSTALLFOLDER">
        <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
          <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
        </Component>
      </DirectoryRef>
    </Fragment>
  </Product>
</Wix>

Explanation of Code Blocks:

Product Element

<Product Id="*" Name="Notepad++" Language="1033" Version="1.0.0.0" Manufacturer="Your Company" UpgradeCode="PUT-GUID-HERE">

Id: The product code, which is a GUID that uniquely identifies the product. Using * lets Windows Installer generate it automatically.
Name: The name of the product (Notepad++).
Language: Language ID (1033 is for English).
Version: The version of the product.
Manufacturer: The name of the manufacturer.
UpgradeCode: A GUID used to identify a family of products for upgrading purposes.

2. Package Element

<Package InstallerVersion="500" Compressed="yes" InstallScope="perMachine" />

InstallerVersion: The version of Windows Installer required to install the package.
Compressed: Indicates whether the MSI file is compressed.
InstallScope: perMachine means the installation is available to all users on the machine.

3. Media Element

<Media Id="1" Cabinet="product.cab" EmbedCab="yes" />

Cabinet: Specifies the cabinet file that contains the installation files.
EmbedCab: Indicates whether the cabinet file is embedded within the MSI.

4. Directory Structure

<Directory Id="TARGETDIR" Name="SourceDir">
  <Directory Id="ProgramFilesFolder">
    <Directory Id="INSTALLFOLDER" Name="Notepad++">
      <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
        <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
      </Component>
    </Directory>
  </Directory>
</Directory>

TARGETDIR: The root directory for the installation.
ProgramFilesFolder: Standard folder for program files.
INSTALLFOLDER: The folder within Program Files where Notepad++ will be installed.
Component: A unique identifier for the component. Each component has a GUID.
File: Specifies the file to be installed (Notepad++.exe).

5. Feature Element

<Feature Id="ProductFeature" Title="Notepad++" Level="1">
  <ComponentGroupRef Id="ProductComponents" />
</Feature>

Id: Unique identifier for the feature.
Title: Name of the feature.
Level: The level of installation for the feature.

6. Fragment Element

DirectoryRef: References the directory where the components will be installed.

<Fragment>
  <DirectoryRef Id="INSTALLFOLDER">
    <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
      <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
    </Component>
  </DirectoryRef>
</Fragment>

Explanation of MSI Tables in the WiX Source File

In the above provided WiX source file, the elements map to specific MSI tables that Windows Installer uses to manage the installation. Here’s how each part of the WiX code relates to these tables:

Product Table

<Product Id="*" Name="Notepad++" Language="1033" Version="1.0.0.0" Manufacturer="Your Company" UpgradeCode="PUT-GUID-HERE">

MSI Table Mapping:

Product Table: This table contains information about the product, such as its name, version, and manufacturer. The attributes in the WiX Product element correspond to columns in the MSI Product table:
ProductCode: Identified by Id="*" which lets Windows Installer generate a unique GUID.
ProductName: The name of the product.
ProductVersion: The version of the product.
Manufacturer: The name of the company manufacturing the product.
UpgradeCode: A GUID used to identify the product family for upgrades.

2. Package Table

<Package InstallerVersion="500" Compressed="yes" InstallScope="perMachine" />

MSI Table Mapping:

Package Table: Contains information about the package itself, such as the installer version required and whether the package is compressed. This maps directly to:
InstallerVersion: The version of Windows Installer required.
Compressed: Indicates whether the MSI is compressed.
InstallScope: Indicates whether the installation is for a single user or all users (perMachine).

3. Media Table

<Media Id="1" Cabinet="product.cab" EmbedCab="yes" />

MSI Table Mapping:

Media Table: Contains information about the media (e.g., cabinet files) used to distribute the installation files. The attributes map to:
Cabinet: The name of the cabinet file.
EmbedCab: Whether the cabinet file is embedded in the MSI.

4. Directory Table

<Directory Id="TARGETDIR" Name="SourceDir">
  <Directory Id="ProgramFilesFolder">
    <Directory Id="INSTALLFOLDER" Name="Notepad++">
      <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
        <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
      </Component>
    </Directory>
  </Directory>
</Directory>

MSI Table Mapping:

Directory Table: Defines the directory structure for the installation. The Directory elements in WiX map to:
DirectoryId: Unique identifier for each directory.
DirectoryName: The name of the directory.
Parent: Specifies the parent directory.

5. Component Table

<Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
  <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
</Component>

MSI Table Mapping:

Component Table: Describes each component of the application. Each component has a unique GUID and contains files, registry entries, or other resources.
ComponentId: Unique identifier for the component.
ComponentGuid: The GUID of the component.
File: References files associated with the component.

6. Feature Table

<Feature Id="ProductFeature" Title="Notepad++" Level="1">
  <ComponentGroupRef Id="ProductComponents" />
</Feature>

MSI Table Mapping:

Feature Table: Defines features of the application that users can install or remove. Features are collections of components.
FeatureId: Unique identifier for the feature.
Title: The name of the feature.
Level: Indicates whether the feature is installed.

7. Fragment Element

<Fragment>
  <DirectoryRef Id="INSTALLFOLDER">
    <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
      <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
    </Component>
  </DirectoryRef>
</Fragment>

MSI Table Mapping:

Component Table (continued): The Fragment element is used to include additional definitions for components, especially in large projects. It helps to organize and include parts of the installation.

Installation, Update, and Deletion

1. Installation

Installation Process: The Windows Installer reads the MSI file and follows the instructions to install Notepad++ into the specified directories.
File Operations: Files listed in the File table are copied to their destination. The File table in the WiX example specifies Notepad++.exe for installation.
Directory Creation: Directories are created as specified in the Directory table.
Custom Actions: If any custom actions were defined (not in this example), they would be executed during installation.

2. Update

Updates: Updates to the MSI can be applied using MSP patches or MST transforms.
Patches: Patches (MSP files) can modify the existing MSI by applying changes to the components or features. The MsiApplyPatch API is used to apply patches.
Transforms: Transforms (MST files) modify the MSI database schema and can be used to update installation paths, add or remove features, etc.

3. Deletion

Uninstallation Process:
File Removal: The Windows Installer removes files listed in the File table. It uses file system APIs to delete these files.
Directory Cleanup: Directories created during installation are cleaned up.
Component Removal: Components and registry entries associated with the product are removed.

Ways to Craft MSI Files for Attacks

Malicious Payload Delivery

Embedded Executables: MSI files can include malicious executables or scripts embedded within the package. These files can be installed or executed during the installation process.
Custom Actions: Custom actions in MSI files can be used to execute arbitrary code or scripts. Attackers can leverage this to run malicious commands or deploy malware.

Exploit Vulnerabilities in MSI Components

Buffer Overflows: Exploiting vulnerabilities in the Windows Installer service, such as buffer overflow vulnerabilities, to execute arbitrary code.
DLL Hijacking: Placing malicious DLLs in directories where the installer expects to find legitimate DLLs. If the installer loads the malicious DLL, it can execute the attacker’s code.

Manipulation of MSI Tables

Modification of Component Tables: Altering the component table to include malicious components or files.
Registry Key Manipulation: Modifying registry keys during installation to achieve persistence or escalate privileges.

MSI File Manipulation

Creating Malicious Transforms (MST): Applying transforms to modify the behavior of MSI files in a way that includes malicious actions.
Using Patches (MSP): Distributing patches that modify existing installations to include malicious code.

Exploitation of InstallScript

Malicious InstallScript Code: Embedding harmful scripts or code in the InstallScript that runs during installation, leading to system compromise or data exfiltration.

Types of Attacks Using MSI Files

Privilege Escalation

Exploitation of Custom Actions: Custom actions running with elevated privileges can be exploited to execute commands or scripts with higher privileges, allowing attackers to gain administrative access.

Persistence

Registry Key Manipulation: Adding or modifying registry keys to ensure that malicious software remains on the system even after reboots or uninstalls.

Data Exfiltration

Data Theft: Custom actions or scripts can be crafted to collect and send sensitive information from the system to an attacker-controlled server.

Malware Delivery

Trojan Horses: MSI files can be crafted to deliver and install malware, such as backdoors or ransomware, during the installation process.

System Compromise

Exploit Vulnerabilities: Using MSI files to exploit vulnerabilities in the Windows Installer service, potentially leading to system compromise or unauthorized access.

Examples of MSI-Based Attacks

Malicious Custom Actions

An attacker can create an MSI file with a custom action that downloads and executes a malicious payload from the internet.
Example: An MSI with a custom action calling powershell.exe to download and execute a script from a remote server.

DLL Hijacking

An MSI can place a malicious DLL in a location where it will be loaded by a legitimate application, leading to the execution of the attacker’s code.
Example: An MSI installs a DLL in the application directory of a legitimate program that is loaded by the application, executing malicious code.

Exploit Windows Installer Vulnerabilities

Crafting an MSI file to exploit known vulnerabilities in the Windows Installer service, such as buffer overflows or improper input validation, to execute arbitrary code.
Example: An MSI file containing specially crafted data that triggers a vulnerability in the Windows Installer, allowing remote code execution.

There have been several notable real-world attacks that leveraged MSI files for malicious purposes. One such attack is the SolarWinds Orion supply chain attack, which, while not exclusively an MSI-based attack, did involve MSI files as part of the broader attack vector. Here’s an in-depth look at the attack:

SolarWinds Orion Supply Chain Attack

Origin

Attack Group: The attack was attributed to a sophisticated nation-state actor, often linked to Russia, specifically the APT29 group (also known as Cozy Bear or The Dukes).
Date: The attack was discovered in December 2020, but it is believed to have started earlier in 2020.

Modus Operandi

Compromise of SolarWinds Software

SolarWinds Orion Platform: The attackers targeted the SolarWinds Orion software, which is used by many organizations for network monitoring and management.
Infection Vector: The attackers inserted malicious code into legitimate software updates for the SolarWinds Orion platform. This was done by compromising SolarWinds’ build system and injecting a backdoor into the software.

Injection of Malicious Code

MSI Files: Although the primary payload was not directly an MSI file, the update process involved various installation packages and components. The compromised software updates included the Sunburst backdoor, which was deployed via the Orion Platform.
Backdoor (Sunburst): The Sunburst backdoor was delivered through the compromised updates and was capable of executing remote commands, exfiltrating data, and facilitating further infiltration.

Execution and Spread

Command and Control: Once installed, the Sunburst backdoor communicated with the attacker’s command-and-control (C2) servers. It used sophisticated methods to avoid detection and to blend in with legitimate network traffic.
Credential Harvesting and Lateral Movement: The backdoor allowed attackers to harvest credentials and move laterally within the victim’s network, compromising additional systems and data.

Exfiltration and Impact

Data Exfiltration: The attackers exfiltrated sensitive data from the compromised networks, targeting a range of sensitive and high-value information.
Impact: The attack affected numerous high-profile organizations, including government agencies, cybersecurity firms, and other critical infrastructure entities.

Type of Organizations Attacked

Government Agencies: Various U.S. government departments and agencies were affected, including the Department of Homeland Security (DHS) and the Treasury Department.
Technology Companies: Major technology and cybersecurity firms were targeted, including FireEye, which was among the first to detect the attack.
Critical Infrastructure: The attack also impacted organizations involved in critical infrastructure, posing significant risks to national security.

Key Details and Lessons Learned

Supply Chain Attacks: The SolarWinds attack highlighted the risks associated with supply chain attacks, where compromise occurs through trusted software providers.
MSI Files in the Attack: While the primary attack vector involved compromised updates rather than standalone MSI files, the use of installation packages and update mechanisms (including MSI-based components) played a role in deploying the backdoor.
Detection and Response: The attack emphasized the need for robust detection mechanisms and response strategies for supply chain and software update-related threats.
Security Practices: Organizations were urged to adopt improved security practices, including regular monitoring for anomalous activity, employing multi-factor authentication, and scrutinizing software supply chains.

Modified Sample MSI File for Malicious Use

To demonstrate how an MSI file can be crafted to facilitate an attack, we’ll modify the sample MSI file created for Notepad++ to include a malicious payload. We’ll focus on how different parts of the MSI file can be exploited, including the Install, Update, and Delete phases.

Here’s a modified version of the MSI file that includes a malicious payload. For this example, let’s assume the malicious payload is a script that will be executed during installation.

Modified WiX Source File (`NotepadPlusPlus_Malicious.wxs`)

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="Notepad++" Language="1033" Version="1.0.0.0" Manufacturer="Your Company" UpgradeCode="PUT-GUID-HERE">
    <Package InstallerVersion="500" Compressed="yes" InstallScope="perMachine" />

    <Media Id="1" Cabinet="product.cab" EmbedCab="yes" />

    <Feature Id="ProductFeature" Title="Notepad++" Level="1">
      <ComponentGroupRef Id="ProductComponents" />
    </Feature>

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLFOLDER" Name="Notepad++">
          <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
            <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
            <!-- Malicious Component -->
            <File Id="MaliciousScript" Source="malicious_script.bat" KeyPath="yes">
              <Publish Event="InstallExecute" Value="[SystemFolder]cmd.exe /c [#MaliciousScript]" />
            </File>
          </Component>
        </Directory>
      </Directory>
    </Directory>

    <Fragment>
      <DirectoryRef Id="INSTALLFOLDER">
        <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
          <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
          <!-- Malicious Component -->
          <File Id="MaliciousScript" Source="malicious_script.bat" KeyPath="yes">
            <Publish Event="InstallExecute" Value="[SystemFolder]cmd.exe /c [#MaliciousScript]" />
          </File>
        </Component>
      </DirectoryRef>
    </Fragment>
  </Product>
</Wix>

Explanation of Modified Code

Adding a Malicious Component

<File Id="MaliciousScript" Source="malicious_script.bat" KeyPath="yes">
  <Publish Event="InstallExecute" Value="[SystemFolder]cmd.exe /c [#MaliciousScript]" />
</File>

File Element: This element includes the malicious script malicious_script.bat, which is the payload that will be executed.
KeyPath: Specifies that this file is the key path for the component, meaning its presence determines the installation status of the component.
Publish Element: Executes the malicious script using cmd.exe when the installation is performed. This effectively runs the script during the installation phase.

Impact on MSI Phases

1. Installation Phase

Code Section: The Publish element under the File component for MaliciousScript is responsible for executing the malicious script during installation.
MSI Table: This modification affects the CustomAction Table because the Publish element defines a custom action (in this case, executing a command) that occurs during the install process.

2. Update Phase

Modifications: Updates can be crafted using transforms (MST files) or patches (MSP files). For example, an attacker could distribute an MST file that modifies the installation process to add or change the malicious components or actions.
MSI Table: Updates might involve changes in the Component Table and File Table to include or modify malicious components. The Patch Table is used to apply these updates.

3. Deletion Phase

Code Section: During uninstallation, if the malicious component is not correctly managed, it might leave residual files or modify system settings (e.g., registry keys) that persist after removal.
MSI Table: The Component Table and Directory Table are involved in the removal process. Proper cleanup should be defined in these tables, but if the attacker manipulates them, the malicious payload might persist or cause further damage.

Specific Table Attributes and Reasons

CustomAction Table: Used for defining and executing custom actions like the malicious script. This is critical because it allows execution of arbitrary commands or scripts.
Component Table: Defines the components that are installed or removed. Modifications here add or alter components to include malicious files.
File Table: Contains information about files being installed. Malicious files are included here to be installed during the process.

To demonstrate how MSI files can be crafted for attacks during the update and uninstallation phases, we can modify the sample MSI file to include malicious payloads and actions specifically designed for these phases.

Attacking During the Update Phase

For the update phase, attackers can use MSI transforms (MST files) or patches (MSP files) to introduce or modify malicious components. Here’s how you can create a transform file (MST) that modifies the MSI file to include a malicious component or change the behavior of existing components.

Example MST File for Malicious Update (`MaliciousUpdate.mst`)

MST files modify existing MSI files by applying changes like adding new components or altering the installation logic. In this case, we’ll use an MST file to add a malicious script that gets executed during the update.

<?xml version="1.0"?>
<Transform xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <!-- Define the malicious script to be added -->
  <Fragment>
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLFOLDER" Name="Notepad++">
          <Component Id="MaliciousUpdateComponent" Guid="PUT-GUID-HERE">
            <File Id="MaliciousScriptUpdate" Source="malicious_script_update.bat" KeyPath="yes">
              <Publish Event="InstallExecute" Value="[SystemFolder]cmd.exe /c [#MaliciousScriptUpdate]" />
            </File>
          </Component>
        </Directory>
      </Directory>
    </Directory>

    <!-- Add the new component to the Feature -->
    <Feature Id="ProductFeature" Title="Notepad++" Level="1">
      <ComponentGroupRef Id="ProductComponents" />
      <ComponentRef Id="MaliciousUpdateComponent" />
    </Feature>
  </Fragment>
</Transform>

Explanation:

Component Addition: Adds a new component MaliciousUpdateComponent that includes the malicious script malicious_script_update.bat.
Feature Modification: Updates the feature to include the new component so that it is installed or updated when the MST file is applied.

Applying the Transform:

msiexec /i NotepadPlusPlus.msi TRANSFORMS=MaliciousUpdate.mst

Attacking During the Uninstallation Phase

For the uninstallation phase, you can modify the MSI file to include actions or scripts that execute when the application is uninstalled. This can be done using custom actions that are triggered during the uninstallation process.

Modified WiX Source File for Malicious Uninstallation (NotepadPlusPlus_Malicious_Uninstall.wxs)

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="Notepad++" Language="1033" Version="1.0.0.0" Manufacturer="Your Company" UpgradeCode="PUT-GUID-HERE">
    <Package InstallerVersion="500" Compressed="yes" InstallScope="perMachine" />

    <Media Id="1" Cabinet="product.cab" EmbedCab="yes" />

    <Feature Id="ProductFeature" Title="Notepad++" Level="1">
      <ComponentGroupRef Id="ProductComponents" />
    </Feature>

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLFOLDER" Name="Notepad++">
          <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
            <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
            <!-- Malicious Uninstallation Script -->
            <File Id="MaliciousUninstallScript" Source="malicious_uninstall.bat" KeyPath="yes">
              <Publish Event="InstallExecute" Value="[SystemFolder]cmd.exe /c [#MaliciousUninstallScript]" />
            </File>
          </Component>
        </Directory>
      </Directory>
    </Directory>

    <Fragment>
      <DirectoryRef Id="INSTALLFOLDER">
        <Component Id="NotepadPlusPlusExe" Guid="PUT-GUID-HERE">
          <File Id="NotepadPlusPlusExe" Source="Notepad++.exe" />
          <!-- Malicious Uninstallation Script -->
          <File Id="MaliciousUninstallScript" Source="malicious_uninstall.bat" KeyPath="yes">
            <Publish Event="UninstallExecute" Value="[SystemFolder]cmd.exe /c [#MaliciousUninstallScript]" />
          </File>
        </Component>
      </DirectoryRef>
    </Fragment>
  </Product>
</Wix>

Explanation:

Malicious Uninstall Script: Includes a script malicious_uninstall.bat that will be executed during the uninstallation process.
UninstallExecute Event: Specifies that the script should be executed when the application is uninstalled.

Executing the Uninstall:

msiexec /x NotepadPlusPlus.msi

Summary of Modifications and Implications

Update Phase:

Modification: Added a malicious component via an MST file.
MSI Table: Changes impact the Component Table and Feature Table, introducing new components and altering features during updates.
Purpose: To execute malicious code or perform additional harmful actions when the application is updated.

Uninstallation Phase:

Modification: Included a malicious script that executes during uninstallation.
MSI Table: Affects the CustomAction Table and Component Table to define and execute custom actions during uninstallation.
Purpose: To execute arbitrary code or leave persistent artifacts on the system even after uninstallation.

These modifications illustrate how MSI files can be used to deliver malicious payloads during various phases of software management. Understanding these techniques emphasizes the importance of securing software installation processes and validating updates or patches from trusted sources.

Detecting and mitigating malicious files like those embedded within MSI files requires a combination of proactive hunting queries, SIEM rules, and other approaches such as behavioral analysis, threat intelligence, and signature-based detection. Below are some strategies for hunting malicious MSI files and suspicious behavior.

Hunting Queries for Malicious MSI File Activity

a) Windows Event Log Query (Sysmon/Windows Event ID 4688)

Look for suspicious msiexec.exe execution or malicious processes that might run alongside MSI installation. This query detects MSI executions (msiexec.exe) with suspicious command-line arguments like /qn (quiet installation), which is often used by attackers to hide MSI installations without user interaction.

EventID=4688
| where NewProcessName contains "msiexec.exe"
| where CommandLine contains ".msi" and CommandLine contains "/qn"  // MSI with silent execution
| project TimeCreated, NewProcessName, CommandLine, ParentProcessName, User

b) PowerShell Execution with MSI File

Detect MSI files being downloaded or installed using PowerShell, a common method in phishing attacks. This query looks for PowerShell scripts that invoke Start-Process to execute MSI files, which is often associated with malicious file execution.

EventID=4104
| where ScriptBlockText contains "Start-Process" and ScriptBlockText contains ".msi"
| project TimeCreated, ScriptBlockText, User, HostName

c) Sysmon File Creation Detection (Event ID 11)

Monitor for suspicious MSI file creation, often seen in staging or persistence methods. This Sysmon event detects file creation events. The query looks for .msi files being dropped or created, which may indicate an attacker preparing a malicious installation.

EventID=11 and TargetFilename endswith ".msi"
| project TimeCreated, TargetFilename, ProcessId, ProcessCommandLine, Image, User

d) Registry Modification (Event ID 13)

Track registry changes related to MSI installations, often used for persistence. This query looks for modifications to the uninstall registry key, which is related to MSI installations and uninstallation. Attackers may alter this key to gain persistence.

EventID=13 and TargetObject contains "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall" 
| where EventData contains ".msi"
| project TimeCreated, TargetObject, Details, ProcessCommandLine, User

SIEM Detection Rules

a) Silent MSI Installation Detection (Custom Rule for SIEM)

Rule Name: Silent MSI Installation Detection
Trigger: MSI installation using silent switches

Condition:

Process = msiexec.exe
Command Line contains /qn or /quiet

(msiexec\.exe)\s.*(\/qn|\/quiet)

b) MSI Executed from Untrusted Source

Rule Name: MSI Execution from Non-Standard Directory
Trigger: MSI files executed from non-standard directories (not Program Files or C:\Windows).

Condition:

Process = msiexec.exe
File path NOT containing C:\Program Files\ or C:\Windows\

(msiexec\.exe)\s.*NOT in (C:\\Program Files|C:\\Windows)

c) Detecting Suspicious File Creation Using MSI

Rule Name: Suspicious File Creation During MSI Execution
Trigger: MSI file execution resulting in uncommon file creation

Condition:

Process = msiexec.exe
File extensions created: .dll, .exe, .bat, or .vbs

(msiexec\.exe)\s.*(\.dll|\.exe|\.bat|\.vbs)

Additional Detection Approaches

a) YARA Rules for MSI Files

Purpose: Identify MSI files with specific suspicious behaviors (e.g., certain custom actions, scripts embedded in MSI files).

This rule detects MSI files that contain embedded executable files, scripts (like .bat or .vbs), or references to PowerShell.

rule Suspicious_MSI
{
    meta:
        description = "Detect MSI files with embedded malicious scripts or executables"
        author = "Your Name"
        date = "2024-09-18"
    strings:
        $exe = ".exe"
        $bat = ".bat"
        $ps = "powershell"
        $vbs = ".vbs"
    condition:
        uint16(0) == 0xD0CF && ($exe or $bat or $ps or $vbs)
}

b) File Integrity Monitoring (FIM)

Implement File Integrity Monitoring on directories where MSI files are commonly installed or executed (C:\Windows\Installer, C:\Program Files, etc.).
Action: Trigger alerts on unauthorized changes, MSI installations, or updates.

c) DNS Queries for Malicious MSI Download

Monitor DNS requests for domains known to serve malicious MSI files.
Use threat intelligence feeds to block these requests and generate alerts in your SIEM.

EventID=22 // Sysmon DNS Lookup
| where QueryName in ("known-malicious-site1.com", "known-malicious-site2.com")

d) Threat Intelligence and Reputation-based Blocking

Integrate threat intelligence feeds with your SIEM or endpoint detection platform to block MSI files downloaded from known malicious IPs, URLs, or hashes.
Action: Automatically quarantine or block MSI files with poor reputations or hashes matching known malware samples.

Mitigation Techniques

a) Application Control / Whitelisting

Use Windows Defender Application Control (WDAC) or AppLocker to block unauthorized MSI files from running:
Block MSI execution from non-standard directories.
Whitelist MSI files from trusted vendors only.

b) Endpoint Detection and Response (EDR)

Leverage EDR tools like CrowdStrike, Carbon Black, or SentinelOne to monitor behaviors related to MSI file executions, such as:
Unusual file creation during installation.
Attempts to disable security controls using MSI files.
Anomalous custom actions within MSI installers.

c) Network Segmentation

Prevent the spread of malicious MSI files within an organization by segmenting the network. If one workstation is compromised, network segmentation can prevent lateral movement of the malicious files.

d) User Awareness & Training

Train users to recognize phishing attempts and avoid downloading MSI files from untrusted sources.
Implement email filtering to block malicious attachments or suspicious MSI file URLs.

#MSIInstaller #MSIFiles #Hunting #WindowsInternals

Exploring MSI Files: The Good, the Bad, and the Ugly

Origin

Why MSI Files are Required

How MSI Files Are Used

Structure of MSI file

Main Components of an MSI File

Example: Sample MSI File Structure

Tools for Viewing MSI File Contents

Components of MSI

How Windows OS Handles an MSI File

1. Installation

2. Updating

3. Deletion (Uninstallation)

Detailed Interaction with System Components

Sample MSI File for Notepad++

Explanation of Code Blocks:

Explanation of MSI Tables in the WiX Source File

Installation, Update, and Deletion

1. Installation

2. Update

3. Deletion

Ways to Craft MSI Files for Attacks

Types of Attacks Using MSI Files

Examples of MSI-Based Attacks

SolarWinds Orion Supply Chain Attack

Origin

Modus Operandi

Type of Organizations Attacked

Key Details and Lessons Learned

Modified Sample MSI File for Malicious Use

Modified WiX Source File (NotepadPlusPlus_Malicious.wxs)

Explanation of Modified Code

Impact on MSI Phases

1. Installation Phase

2. Update Phase

3. Deletion Phase

Specific Table Attributes and Reasons

Attacking During the Update Phase

Example MST File for Malicious Update (MaliciousUpdate.mst)

Attacking During the Uninstallation Phase

Summary of Modifications and Implications

Hunting Queries for Malicious MSI File Activity

a) Windows Event Log Query (Sysmon/Windows Event ID 4688)

b) PowerShell Execution with MSI File

c) Sysmon File Creation Detection (Event ID 11)

d) Registry Modification (Event ID 13)

SIEM Detection Rules

a) Silent MSI Installation Detection (Custom Rule for SIEM)

b) MSI Executed from Untrusted Source

c) Detecting Suspicious File Creation Using MSI

Additional Detection Approaches

a) YARA Rules for MSI Files

b) File Integrity Monitoring (FIM)

c) DNS Queries for Malicious MSI Download

d) Threat Intelligence and Reputation-based Blocking

Mitigation Techniques

a) Application Control / Whitelisting

b) Endpoint Detection and Response (EDR)

c) Network Segmentation

d) User Awareness & Training

Written by Nikhil gupta

No responses yet

Modified WiX Source File (`NotepadPlusPlus_Malicious.wxs`)

Example MST File for Malicious Update (`MaliciousUpdate.mst`)