A Look Into Purple Fox’s Server Infrastructure

Operating system execution via SQL Server

Purple Fox focuses on SQL servers as its target as opposed to normal computers for the former’s cryptocurrency-mining activities. This is mainly because of the more powerful hardware configuration — for both CPU and memory — that the servers would usually have. More specifically for SQL servers, the combination of CPU, memory, and disk factors should scale with the database-related operations to avoid bottlenecks in performance.

These machines normally possess much greater computing power compared to normal desktops, as such servers are usually fitted with hardware such as the Intel Xeon line of CPUs that produces a significantly higher amount of hash-based calculations (hash rates), making a server more advantageous to coinmining compared to a typical desktop computer.

Since SQL databases support different vectors for executing operating system commands directly, Purple Fox has leveraged the stealthiest method of having a binary inserted in the SQL server database that can be executed via TSQL commands. The following interfaces are available from the SQL components for the malicious actors to use when targeting an SQL server:

Table 2. The available interfaces from the SQL components

Purple Fox opted to go with the .NET method using CLR Assemblies, a group of DLLs that can be imported into a SQL Server, in its infection chain instead of the more popular xp_cmdshell, which is heavily monitored by security analysts. Once the DLLs have been imported, they can be linked to stored procedures that can be executed via a TSQL script. The affected versions for this vector start from SQL Server 2008.

This method, which requires a system administrator role by default, executes as an SQL Server service account. By leveraging this interface, an attacker is able to compile a .NET assembly DLL and then have it imported into the SQL server. It is also able to have an assembly stored in the SQL Server Table, create a procedure that maps to the CLR method, and finally, run the procedure.

The CLR Assemblies method is reported to have been used before by groups other than Purple Fox, such as MrbMiner and Lemon Duck.

The C&C servers used in the communication schemes that have been described here are infected servers that are part of the botnet used to host the various payloads for Purple Fox. We deduced this via the following facts:

• The C&C servers are SQL Servers themselves.
• The HTTP server header is mORMot, which is written in Delphi, the same language used for the various components.
• There is a large number of servers (1,000+ in just over a week).

Both initial DNS requests are CNAMEs to subdomains under kozow[.]com, which is a free dynamic domain service provided by dynu[.]com. This service can be updated with an API to make it point to different IP addresses — a technique the attacker uses to change the IP address at a regular interval.

Using our telemetry, we found non-server systems infected with Purple Fox, indicating that there are other possible initial access methods other than the SQL Server brute-force attack to spread the malware.

This activity is similar to the ones seen in Lemon Duck attacks and even shares some techniques, like the use of PowerSploit for reflective PE loading and implementing the same backdoor, evilclr.dll, for the SQL Server assembly. Both attacks also share the same goal of mining Monero.

Upon observing any suspicious activities related to the Purple Fox botnet on a SQL server, we recommend the following steps to completely remove all the malicious remnants from the infection.

• Review all the SQL Server’s Stored Procedures and Assemblies for any suspicious assemblies not recognized by the DBAs. Remove any of these assemblies if detected.
• Execute the following TSQL script to remove the following remnants of malicious CLR assemblies that are inserted into the database:         
• USE [master]
• GO
• DROP ASSEMBLY [fscbd]
• GO
• Disable all the unknown accounts on the database server and change all the passwords.
• As a defensive posture, do not publish externally exposed port TCP 1433 to an untrusted zone. In addition, secure the SQL server hosts via a perimeter firewall in a DMZ zone with well-protected access policies.
• Implement proper network microsegmentation and network zoning while also applying a zero trust policy via your network security controls.
• Restrict the traffic to and from SQL servers. These servers have a very specific function; therefore, they should only be allowed to communicate with other trusted hosts. Inbound and outbound internet accessibility should also be controlled.

Trend Micro Vision One™️ with Managed XDR focuses on both the early stages of the attack kill chain (covered in the previous research) and the final payloads intended to do the actual damage, thereby protecting users of this service against the damage caused by the latest evolution of this botnet.  

Both the Vision One platform and Managed XDR threat experts can correlate the suspicious activities observed from the protected SQL servers. An environment that has any of the behavioral detections found in our Vision One heuristics rules might mean that the SQL servers within the environment have already been affected by an attack. This  extends even to stealthy malware, such as Purple Fox, that does not store majority of its files on the disk.

• Since servers have a predictable network footprint and behavior, unusual or unexpected network patterns could be a sign of botnet propagation.
• The same goes for unusual and unexpected SQL server application login failures that seem like brute-force attacks . The main propagation method for Purple Fox when infecting SQL servers uses brute-force attacks rather than acting as a worm that exploits only the vulnerable services.
• When a SQL server starts having unusual traffic related to UDP and TCP, there should be a massive surge in traffic since it scans public IP addresses and the local network. This will create a domino effect within an environment due to most organizations having more than one SQL server, such as standby or backup servers.
• Unusual network traffic patterns and login failures on the SQL server are also a good indicator for this threat.
• A sudden and unexpected spike in CPU utilization on the SQL server could also be a sign of SQL bottlenecks or an infection with the XMR Coinminer. Furthermore, there could also be unusual amounts of network traffic on the server as it joins the mining pool.