MSIX helps developers package Windows apps for easy installation. While it’s user-friendly, it demands access to code signing certificates, making it an attractive target for resourceful threat actors.
Additionally, MSIX packages can be distributed and installed without administrative privileges, potentially allowing malicious software to evade traditional security controls.
Cybersecurity researchers at Elastic Security Labs recently discovered a campaign using signed MSIX apps for initial access with a stealthy loader called GHOSTPULSE.
Users likely download malicious MSIX packages via compromised websites or SEO tricks, masquerading as popular apps like-
The “Install” button seems normal, but secretly, a PowerShell script downloads and runs GHOSTPULSE without any alerts.
Weaponized MSIX Packages
To execute a final payload, the GHOSTPULSE loader was broken down into 3 distinctive stages by the security researchers for its easy and comprehensive in-depth analysis.
Here below, we have mentioned all the stages:-
- Stage 0: The PowerShell script in the malicious MSIX installer is stage 0, and under this stage, it downloads a GPG-encrypted file and decrypts it. This file contains an executable VBoxSVC.exe, which sideloads a malicious DLL, allowing the threat actor to evade file-based scanning.
- Stage 1: GHOSTPULSE’s first stage is in a malicious DLL sideloaded by a legitimate executable. It builds an Import Address Table (IAT) and reads encrypted data from “handoff.wav.” The malware decrypts and decompresses the data, loads a library (e.g., mshtml.dll), and executes the Stage 2 shellcode in the loaded DLL’s .text section using “module stomping.”
- Stage 2: Stage 2 constructs a new IAT by using the CRC32 for API hashing; then, it reads ntdll.dll and directly invokes NT APIs. GHOSTPULSE establishes persistence by creating a .lnk file via COM objects. It XOR encrypts data with the machine name and saves it to the user’s temporary folder, then initiates a child process and redirects execution to malicious code in mshtml.dll using Wow64SetThreadContext.
- Stage 3: This stage loads and executes the final payload and then overwrites instructions for evasion. It uses CRC32 for Function Import Table, employs “heaven’s gate,” and can disable WOW64 file system redirection. It decrypts the payload from a temporary file and injects it using Process Doppelganging, ensuring evasion and persistence.
The final payload differs in each sample, often being an info stealer like:-
- SectopRAT
- Rhadamanthys
- Vidar
- Lumma
- NetSupport
Detection recommendations
Here below, we have mentioned all the detection recommendations offered by security analysts:-
- Make sure to perform a DNS Query to a Potentially Suspicious Top-Level Domain.
- Library Load of a File Written by a Signed Binary Proxy.
- Suspicious API Call from an Unsigned DLL.
- Suspicious Memory Write to a Remote Process.
- Process Creation from Modified NTDLL.
Protect yourself from vulnerabilities using Patch Manager Plus to patch over 850 third-party applications quickly. Try a free trial to ensure 100% security.