MSIX installer malware delivery on the rise across multiple campaigns

We’ve seen multiple distinct adversaries leveraging MSIX installers to deliver a variety of malware payloads in recent months.

Starting in July 2023, Red Canary began investigating a series of attacks by adversaries leveraging MSIX files to deliver malware. MSIX is a Windows application package installation format that IT teams and developers increasingly use to deliver Windows applications within enterprises.

The adversary in each intrusion appeared to be using malicious advertising or SEO poisoning to draw in victims, who believed that they were downloading legitimate software such as Grammarly, Microsoft Teams, Notion, and Zoom. Victims span multiple industries, suggesting that the adversary’s attacks are opportunistic rather than targeted.

Threat clusters abusing MSIX installers to deliver malware

Analysis of the intrusions revealed three clusters of activity stretching from July to December 2023.

Cluster 1: FIN7

The first cluster of activity we’ve observed seems to bear the hallmarks of a financially motivated threat group known as FIN7 that’s been active since at least 2015. They’ve leveraged many malicious tools over the years and represent a significant risk to organizations, in part because FIN7 activity has frequently preceded ransomware deployment. We’ve detected activity within this cluster attempting to install malicious instances of NetSupport Manager RAT.

In the detections we’ve observed within this cluster, the adversary leverages the MSIX-PackageSupportFramework tool to create their malicious MSIX files. When the victim opens the MSIX, the StartingScriptWrapper.ps1 component of the MSIX package support framework launches an embedded PowerShell script.

The PowerShell script employs process injection to execute POWERTRASH and Carbanak malware, which in turn deliver NetSupport Manager RAT as a follow-on payload. Notably, the NetSupport RAT binaries in these intrusions contain metadata associated with an entity called “Crosstec Corporation” rather than the expected “NetSupport Corporation.” Recent research from Microsoft corroborates our assessment that FIN7, which Microsoft tracks as Sangria Tempest, may be behind these incidents.

Cluster 2: Zloader

The adversary in Cluster 2 uses Advanced Installer—a development utility widely used for building software installation packages—to create MSIX files. These MSIX files leverage the legitimate Advanced Installer binary AiStub.exe to execute the malicious payload inside.

The payload is named Install.exe and is constructed using compiled Python code. Red Canary’s analysis of the Python payloads reveal at least some consistent overlap with Zloader (aka BatLoader), including using OpenSSL commands to decrypt components and the use of GetAdmin.vbs scripts. The same research from Microsoft (referenced above) suggests this cluster also overlaps or aligns with a group Microsoft identifies as Storm-0569.

Cluster 3: FakeBat

Similar to Cluster 2, the adversary in Cluster 3 also uses Advanced Installer to create MSIX files. The Cluster 3 payload is a malicious PowerShell script, which AiStub.exe executes via the legitimate component StartingScriptWrapper.ps1.

Adversaries in Cluster 3 intrusions have used ArechClient2 or Redline stealer in the same chain of activity. The adversary’s packages have also delivered a DLL-sideloading payload consistent with GHOSTPULSE, as well as using GPG decryption tools and tar to decompress files in a manner consistent with FakeBat. FakeBat has also been used in MSIX packages to distribute additional payloads in the past, notably IcedID. Research from Microsoft suggests this cluster overlaps or aligns with a group they call Storm-1113.

Turn on high-powered security operations fueled by Microsoft data

Learn more

Why should organizations care about this?

Security is a cat-and-mouse game between adversaries and defenders, and the intrusions Red Canary observed and responded to demonstrate that preventative security controls alone are not adequate.

Following an uptick of malware delivered via MSIX, Microsoft disabled the ms-appinstaller protocol from February 2022 up until August 2022 to address a vulnerability that allowed attackers to distribute remote MSIX packages that appear to be from a trusted source. While this mitigated some threats, other security researchers noted that legitimate code-signing certificate services could be acquired illicitly from criminal forums, and that MSIX installers could still distribute malware if they were downloaded locally to a victim’s system first.

In December 2023, Microsoft again disabled the protocol to address increased MSIX use to distribute malware from remote URLs. In this case, Microsoft chose to leave the protocol disabled by default, requiring a configuration change to enable it. As with previous encounters with MSIX files, this disabling solution does not fully eliminate the threat of MSIX files, it merely requires the malicious MSIX files to be intentionally downloaded to disk before execution.

Preventative security controls alone are not adequate.

Since at least December 2022, adversaries have also abused advertisement solutions such as Google Ads to deliver malware of various types, including MSIX files, posing as legitimate software. Google Ads provide methods for companies to advertise using their product—namely, by putting promoted advertisements ahead of organic results. While Google and other search companies have attempted to curb SEO poisoning and malicious advertising, adversaries have continued to modify their tactics to evade anti-SEO poisoning efforts.

Victims of the malware distributed using these MSIX installers are often prime targets for follow-on activity through persistent access via remote access tools or credential access attempts with stealers.

What can you do about malicious MSIX installers?

While the increase in abuse of malicious MSIX installers is certainly an emergent trend, the adversaries behind it are still at least partially reliant on fairly well understood tradecraft. Fortunately, we can share a few pseudo-detectors that have helped us catch these and other threats. For prevention, organizations that use application allow-listing solutions such as AppLocker can explore allowing or denying MSIX execution with AppLocker policies.

Detection opportunity 1: Launching PowerShell scripts from windowsapps directory

This pseudo-detector looks for the execution of PowerShell scripts from the windowsapps directory. There are instances where benign PowerShell scripts run from this directory, but analysts can sort out malicious or suspicious activity by investigating follow-on actions and network connections. However, in this case we see the adversary calling StartingScriptWrapper.ps1 from the windowsapps directory to execute their malicious payload script.

parent_process_path_includes (‘\\windowsapps\\’) && process == (‘powershell.exe’) && command_includes (‘windowsapps' && '-file ' && '.ps1')

Detection opportunity 2: NetSupport running from unexpected directory

In the instances where the adversary delivered NetSupport Manager RAT as a follow-on payload, our existing detection coverage for malicious NetSupport installation served us well. Under normal circumstances, you should expect NetSupport Manager to run from the program files directory. If you find NetSupport Manager—often identifiable as client32.exe—running outside the program files directory, particularly from the programdata directory, then it’s worth investigating.

Detection opportunity 3: Abusing PowerShell to disable Defender components

We also observed at least one of these adversaries abusing PowerShell to exclude certain files or processes from Windows Defender scanning. Luckily, this is common tradecraft for which we’ve shared similar detection ideas on multiple occasions. The following may unearth this and other threats:

process == (‘powershell.exe’) && command_line_includes (‘Set-MpPreference’ || ‘Add-MpPreference’) && command_line_includes (‘ExclusionProcess’ || ’ExclusionPath’)

Detection opportunity 4: PowerShell -encodedcommand switch

We also observed at least one of these adversaries abusing the shortened -encoded PowerShell command switch to encode PowerShell commands. This is another common bit of tradecraft that we’ve discussed many times on the Red Canary blog, in the Threat Detection Report, and elsewhere. The following should help detect it.

process == ('powershell.exe') && command_includes ('-e' || '-en' || '-enc' || '-enco'|| [any variation of the encoded command switch])*

*Note that PowerShell will recognize anything from the shortened -e to the full -encodedcommand and encode commands accordingly.

Detection opportunity 5: MSBuild without commands

In some detections, we observed the Microsoft Build Engine (msbuild.exe) making outbound network connections to IPs associated with the ArechClient2 remote access tool. In general, it is suspicious for msbuild.exe to execute without a corresponding command line, which is precisely what we observed here. Simply looking for execution of msbuild.exe without a corresponding command line and examining surrounding activity for suspicious network connections and child processes could help detect this threat.

In the tables below, you’ll find indicators of compromise (IOC) and MITRE mappings for each of the three activity clusters.

Cluster 1 indicators of compromise

Cluster 2 indicators of compromise

Cluster 3 Indicators of compromise

Cluster 1 MITRE mapping

'xcopy.exe' 'C:\Users\\AppData\Roaming' 'C:\Users\\AppData\Local\Packages\manager_c4g82jgbfsn1c\LocalCache\Roaming' /e /s /y /c /h /q /i /k

Powershell.exe -ExecutionPolicy RemoteSigned -file '.\kjlalsndlkasndaskjdn.ps1'

net group 'Domain Admins' /domain

nltest /domain_trusts /all_trusts

csvde.exe -r '(&(objectClass=Computer))' -l samAccountName,description,IPv4Address,info,operatingSystem -f 01cp.txt csvde.exe -r '(&(objectCategory=person)(objectClass=User))' -l samAccountName,description,info,mail,middleName,displayName,title,department,lastLogon -f 01usr.txt

Cluster 2 MITRE mapping

wmic computersystem get domain

whoami /groups

openssl enc -aes-256-cbc -d -in code9.exe.enc -out code9.exe -pbkdf2 -pass pass:[redacted]

Cluster 3 MITRE mapping

'xcopy.exe' 'C:\Program Files\WindowsApps\GoogleLLC.Chrome_115.0.5790.173_x64__cvpb331a1f8hw\VFS\AppData' 'C:\Users\\AppData\Local\Packages\GoogleLLC.Chrome_cvpb331a1f8hw\LocalCache\Roaming' /e /s /y /c /h /q /i /k 

Powershell.exe -ExecutionPolicy RemoteSigned -file 'C:\Program Files\WindowsApps\GoogleLLC.Chrome_115.0.5790.173_x64__cvpb331a1f8hw\kin_mix+notion _new_21.08.ps1