{"id":45877,"date":"2022-03-25T00:00:00","date_gmt":"2022-03-25T00:00:00","guid":{"rendered":"urn:uuid:3a0ba19e-9a0f-65c4-9dff-c2cc12f9c034"},"modified":"2022-03-25T00:00:00","modified_gmt":"2022-03-25T00:00:00","slug":"purple-fox-uses-new-arrival-vector-and-improves-malware-arsenal","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/purple-fox-uses-new-arrival-vector-and-improves-malware-arsenal\/","title":{"rendered":"Purple Fox Uses New Arrival Vector and Improves Malware Arsenal"},"content":{"rendered":"

<\/p>\n

<\/div>\n
\n
\n

In previous campaigns in 2019, HTTP file servers (HFS) were used by Purple Fox to run the C&C servers that host files on the infected bots. In this most recent investigation, we found an exposed HFS that the Purple Fox group uses to host all the second stage samples with their update timestamps. We were able to track the frequency of the second stage updated packages pushed to this exposed server using the timestamp data. Figure 3 shows the number of different second stage malicious packages that received updates. They are still actively updating their components at the time of writing. <\/p>\n<\/p><\/div>\n<\/p><\/div>\n

\n
\n

Notable Purple Fox tools and techniques<\/span><\/p>\n

Disguised packages and malicious components in svchost.txt<\/b><\/p>\n

We noted that some of the software they were impersonating were commonly used by Chinese users. The following list shows the recently used software and the corresponding malicious payload for the second stage of the infection. As mentioned above, the different payloads will be served by the C&C upon execution based on the last character in the module filename.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n

\n
\n

We tracked a server hosting the second stage payloads and saw a compressed RAR archive holding the second stage loaders along with the file svchost.txt<\/b>, which contains all the malicious portable executable (PE) module components that will be dropped in the second stage.    <\/p>\n

The order of the PE modules inside svchost.txt is dependent on the package requested by the malicious installers. As previously mentioned, the last character in the installer filename will determine the final set of the auxiliary modules that will be stuffed inside svchost.txt.<\/p>\n

Shellcode user-mode loader and anti-forensics methods<\/b><\/p>\n

A specific set of portable executable (PE) modules found in one of the most distributed clusters from the malware had a wide range of capabilities in terms of AV evasion. This cluster is noteworthy for various reasons as well \u2014 it has links to older families, it loaded a previously documented Purple Fox MSI installer, and it had different rootkit capabilities in the auxiliary PE modules. More details about this cluster can be found in our technical brief<\/a>. <\/p>\n

After analyzing all the observed malicious execution parents delivering different clusters, we found that the shellcode component at the prologue of the dropped svchost.txt was similar across all the different variants, regardless of the actual payloads embedded after the shellcode. It has two different implementations across all the clusters. <\/p>\n

The first shellcode implements four main functions for the intended functionality, as shown in Figure 4.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n

\n
\n

Meanwhile, the new shellcode is more minimalistic because it implements only important functionalities to load a PE in memory and parse several system APIs addresses. It resolves different system APIs from the first one we mentioned. <\/p>\n

One more thing to note: the Purple Fox group implements a customized user-mode shellcode loader that leaves little traces for cybersecurity forensics. It minimizes both the quantity and quality of the forensic evidence as the execution doesn\u2019t rely on the native loader and doesn’t respect the PE format for a successful execution.<\/p>\n

The use of FatalRAT and incremental updates<\/b><\/p>\n

After the shellcode loads and allocates memory for the PE modules inside svchost.txt, the execution flow will call into the first PE module found after the shellcode. This is a remote access trojan (RAT) that inherits its functionality from a malware known as FatalRAT, a sophisticated C++ RAT that implements a wide set of remote capabilities for the attackers.  <\/p>\n

The executed FatalRAT variants shown in Figures 5 and 6 differ across each cluster, illustrating that the attackers are incrementally updating it.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n

\n
\n

The RAT is responsible for loading and executing the auxiliary modules based on checks performed on the victim systems. Changes can happen if specific AV agents are running or if registry keys are found. The auxiliary modules are intended as support for the group\u2019s specific objectives. <\/p>\n

New capabilities to evade cybersecurity mechanisms <\/b><\/p>\n

One of the analyzed executables embedded in svchost.txt is a user-mode client used to interface with the accompanying rootkit module. This client supports five different commands, each command implements a specific functionality to be executed from the kernel driver with the appropriate input\/output control (IOCTL) interface exposed. Table 2 shows the details of each command: <\/p>\n<\/p><\/div>\n<\/p><\/div>\n

\n
\n

The functionality to \u201ckill a mini-filter\u201d is notable in terms of AV evasion. File systems are targets for input-output (I\/O) operations to access files, and file system filtering is the mechanism by which the drivers can intercept calls sent to the file system \u2014 this specifically is useful for AV agents. The model called \u2018file system mini-filters\u2019 was developed to replace the legacy filter mechanism. Mini-filters are easier to write and are the preferred way to develop file system filtering drivers in almost all AV engines.<\/p>\n

We looked deeper into the mini-filter driver killer and how the attackers implemented this functionality. The driver first enumerates all the registered mini filter drivers on the system using the system API FltEnumerateFilters<\/b>, then it gets the targeted mini-filter object information it is searching for by calling FltGetFilterInformation<\/b>. Lastly, it creates a new system thread to unregister the mini-filter driver and terminate the created system thread (PsCreateSystemThread<\/b>, FltUnregisterFilter<\/b>).<\/p>\n

Figure 7 shows the specific call graph for the system APIs used for this functionality.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n

\n
\n

The uses of revoked code signing certificates<\/b><\/p>\n

To control the quality of the code that runs in the address space of the kernel-land, Microsoft only allows signed drivers to run in kernel mode. They do this by enforcing kernel-mode code signing (KMCS) mechanisms.<\/p>\n

Due to performance issues and backward compatibility, Windows actually allows the loading of a kernel driver signed by a revoked code signing certificate. So, by testing a previous kernel driver and allowing it to be revoked, it can be loaded successfully. This design choice allows mature threat actors to chase and pursue any stolen code signing certificate and add it to their malware arsenal. If the malware authors acquire any certificate that has been verified by a trusted certificate authority and by Microsoft, even if it was revoked, attackers can use it for malicious purposes.<\/p>\n

Links to previous Purple Fox activities and artifacts <\/span><\/p>\n

Analyzing the artifacts dropped by this new infection chain, we first looked at the stolen code signing certificates used to sign the kernel drivers\u2019 modules. This led us to analyze other signed malicious samples in our malware repository, which revealed links to previously known intrusion sets.<\/p>\n

There were three different stolen code signing certificates confirmed to be related to this campaign with links to Purple Fox:<\/p>\n