Off the Beaten Path: Recent Unusual Malware

Executive Summary

Recently, we discovered several new malware samples with unique characteristics that made attribution and function determination challenging. While many threat actors will strictly use tools released by the offensive security community, we also encounter novel, custom-built malware – sometimes with new tricks and techniques. This article describes three particularly unusual malware examples we came across last year.

• The first malware sample is a passive Internet Information Services (IIS) backdoor developed in C++/CLI, a programming language very rarely used by malware authors.
• The second sample is a bootkit that uses an unsecured kernel driver to install a GRUB 2 bootloader for a rather unusual purpose.
• The third sample is a Windows implant of a cross-platform post-exploitation framework developed in C++.

Although the last example is a red team tool that doesn't use any novel methods, we believe it is worth reviewing due to significant deviation from other post-exploitation frameworks we've seen during the past year.

Palo Alto Networks customers are better protected from these malware samples through Advanced WildFire, with its different memory analysis features.

Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Example 1: C++/CLI IIS Backdoor

The C++/CLI programming language is an extension of the C++ programming language that can be used to write mixed-mode .NET applications. These mixed assemblies can have managed code (C#) and unmanaged code (C++). Analyzing these files is challenging because it can be hard to read their interoperation code in existing .NET decompilers.

This programming language is very rare among malware authors, likely because C++/CLI is poorly documented compared to other languages. One of the first public mentions of a malware sample coded in C++/CLI was a module of a toolkit that Positive Technologies described in 2018. However, this module and all other C++/CLI malware we have come across so far is not as complex as this particular IIS backdoor.

We found two versions of this passive IIS malware uploaded to VirusTotal, both submitted from Thailand. The later version, compiled on May 9, 2023, differs from the earlier one, compiled on April 28, 2023, in its approach to handling external commands. It uses a custom cmd.exe wrapper tool, as opposed to the earlier version which uses just the cmd.exe tool. This change was likely implemented to create less monitorable activity, as spawning cmd.exe directly from an IIS process could raise suspicion. These samples have been referred to as “Detele” [PDF] during a presentation by John Southworth at the LABScon conference in 2024.

Technical Analysis of the C++/CLI IIS Backdoor

The two samples of this passive IIS malware were compiled with different Visual C++/CLI compiler versions and also differ slightly in functionality.

• The newer and bigger assembly (SHA256 hash: 15db49717a9e9c1e26f5b1745870b028e0133d430ec14d52884cec28ccd3c8ab) is internally named proxyxml_v4 (described as version 2). This newer sample uses more AMSI/ETW patching and has a different implementation for the non-self-contained command-line features.
• The slightly older one (SHA256 hash: 8571a354b5cdd9ec3735b84fa207e72c7aea1ab82ea2e4ffea1373335b3e88f4) is named IISShellModule (described as version 1).

The author created the backdoor as an IIS module that uses the exported function RegisterModule to register itself for RQ_SEND_RESPONSE event notifications. Therefore, whenever the IIS server sends an HTTP response, it will call the backdoor’s registered OnSendResponse method. For callback traffic, the backdoor’s OnSendResponse method filters on the incoming HTTP request having the following attributes before calling its event handler:

• Request type: HTTP POST
• Request header field and value: X-ZA-Product : AbJc123!@#45!!
• Request header field and value: X-ZA-Platform : <any>

The custom HTTP request header field named X-ZA-Product is internally reassigned to PWD_HEADER, and its value AbJc123!@#45!! is reassigned as PWD_VALUE. This PWD_VALUE is encrypted using AES with a key of AQJBdmin!@#45!@## (internally called KEY) and the result is Base64-encoded.

The other HTTP request header field named X-ZA-Platform is processed by the malware as CMD_HEADER, and the CMD_VALUE represents the actual command data. This CMD_VALUE is also encrypted using AES with the same KEY as the PWD_VALUE and the result is also Base64-encoded.

The backdoor has an event handler that processes the data from X-ZA-Platform to parse the included commands. Figure 1 shows the event handler code that processes the implemented commands.

At first, the handler patches AMSI and ETW routines for the current process (copied and pasted from GitHub). Afterwards, the handler utilizes the X-ZA-Platform command data to extract the specific commands and corresponding data for each implemented command feature.

Table 1 shows the list of available commands in version 2 of this malware.

Table 1. Implemented commands in malware version 2.

The wrapper application (SHA256 hash: a28d0550524996ca63f26cb19f4b4d82019a1be24490343e9b916d2750162cda) used in ProcessCmdOperation is embedded in the .rdata section.

To load an assembly into a new process as part of the exec_builtin_cmd_net command, a small embedded loader DLL (SHA256 hash: aa2d46665ea230e856689c614edcd9d932d9edad0083bf89c903299d148634a2), also embedded in the .rdata section, is loaded into the process that in turn reflectively loads the assembly.

The returned result of each command (which can also be debug information in case of an error) is then AES-encrypted and Base64-encoded.

Malware version 1 has a slightly different implementation in functionality. It patches AMSI and ETW routines only in the routine that executes a .NET assembly in a new process and not at the beginning of the command data event handler like in version 2. Also, version 1 does not use an external command-line wrapper application for commands 3-5. Instead, it uses different implementations for these commands as shown in Table 2.

Table 2. Different commands in malware version 1 in comparison to version 2.

While using native Windows API functions is not mandatory for C++/CLI applications, this malware extensively uses them for all of its features. Overall, this malware appears to be coded by a seasoned, old-school Windows developer. The author uses the classic Hungarian notation throughout the code. For example the malware uses the following variable names:

• wszExe
• pszArg
• pNetExeBuffer
• dwNetExeBufferSize
• uiBaseAddress
• strCmdValueEncrypted
• g_hBackendIPCServer
• g_aryBackendIPCServer

This malware has some inconsistent notations, debug messages and a few typos throughout the code that indicate the malware was not created by someone who speaks English as a first language. For example, the following list shows an excerpt of the debug strings used in the malware:

• [+] PID:
• [-] Exec Failed.
• [+] Inject Succeed
• [-] Inject Failed
• [+] .Net Exec Succeed
• [-] .Net Exec Failed
• [-] .Net Exec Timeout (>20s). Result Maybe Incomplete
• [-] Cat File Left Content Failed
• [-] Cat File 0 size
• [-] Cat File Failed
• [+] Detele Succeed
• [-] Detele Failed
• unknow

The above list contains misspellings of the words unknown and delete. We also find inconsistent use of tense, where Succeed is present tense, while Failed is past tense. Also using Result Maybe Incomplete, where the proper spelling should be Result May Be Incomplete.

Summary of C++/CLI IIS Backdoor

This passive IIS backdoor written in C++/CLI has numerous functionalities and is likely under active development. All network traffic is encrypted and encoded. Even though it has been professionally created, there appear to be weak spots that facilitate detection and analysis. All (debug) strings are stored in cleartext, making analysis easier. Additionally, the malware uses hard-coded passwords and keys for authentication.

We assess this malware is quite uncommon, because we have not yet discovered any other comparable samples. This rarity indicates the malware could have been used in a targeted attack, especially with its unusual development language and sophisticated nature. However, we cannot yet attribute this malware to any known threat actor.

Example 2: A Dixie-Playing Bootkit

What started as an analysis of a possible new implant from the Equation Group turned out to be one of the most peculiar threats we saw in 2024 in terms of its behavior.

At a first glance, the sample looked similar to previous malware attributed to the Equation Group. This sample has the typical exported function name dll_u, it uses multiple API functions from msvcrt.dll, and it abuses a third-party driver to gain access to kernel-mode. All these characteristics have been seen in EquationDrug and SlingShot samples too. Additionally, some security vendors classify this as a new EquationDrug sample.

This sample is also interesting because of its associated VirusTotal submission data. The sample was submitted from Oxford, Mississippi. It was uploaded with the file name w32analytics.dll to VirusTotal from the directory path C:\Windows\System32. This at least indicates it’s from an actual ITW infection of a real victim, as this directory is reserved for the Windows operating system and commonly abused by malware. Beginning with Windows Vista, administrative privileges are required to write a file to the system32 directory. It indicates that this malware was placed there by an individual with admin privileges or another unidentified related malware that had administrative privileges. We have not found any other similar samples at this time.

This sample was compiled with MinGW and is signed by the University of Mississippi with an invalid certificate, with the issuer being it@olemiss[.]edu. These characteristics have not been seen in any previous samples from the stated threat actor. Finally, the malware’s behavior is the main reason the sample most likely has nothing to do with the Equation Group.

Technical Analysis of a Dixie-Playing Bootkit

The sample (SHA256 hash: 950243a133db44e93b764e03c8d06b99310686d010b52b67f4effa57f0d72e04) is a 64-bit DLL and has two exported functions, dll_u and install.

Invoking the install export deletes any previous installations of the malware and creates a new scheduled task for persistence by using the following command:

• schtasks /create /tn w32analytics /sc ONCE /st 07:00 /ru SYSTEM /tr \"rundll32 w32analytics.dll,dll_u\"

This creates a scheduled task named w32analytics that is set to run once at 7:00 AM under the SYSTEM account. When triggered, this task executes the exported function dll_u from w32analytics.dll using the rundll32 command.

The dll_u function first uses zlib to decompress an embedded payload into memory. The decompressed payload is a 35 MB disk image. This image is a hybrid GRUB 2 bootloader designed to be compatible with both BIOS and UEFI systems.

The image is made of the following:

• A GRUB 2 master boot record (MBR)
• A BIOS boot partition that is the second stage of a GRUB 2 BIOS bootloader
• An EFI system partition (ESP) that contains the necessary data and files to run on a UEFI system

The threat then installs the bootloader on every physical disk with one of two options depending on the Windows OS version.

For Windows Vista and above, it drops a legitimate signed kernel driver named ampa.sys (SHA256 hash: 01D51DF682136CCE453BB1DA8964073E6BC7297CE4DAE7301C753BB618A69469) to disk, which is embedded in the resource section. The driver is later abused for the installation of the GRUB 2 bootloader disk image.

The installation procedure is as follows:

1. Create the driver file in C:\Windows\System32\ampa.sys
2. Adjust the process token with SeLoadDriverPrivilege privilege
3. Create the driver service in the Windows registry and set the needed values under HKLM\System\CurrentControlSet\Services\ampa
4. Load the driver with NtLoadDriver
5. Delete the driver service in the registry

The malware installs the driver programmatically by dynamically resolving and executing the following API functions:

• NtLoadDriver
• NtUnloadDriver
• RtlInitAnsiString
• RtlAnsiStringToUnicodeString
• RtlFreeUnicodeString
• LookupPrivilegeValueA
• OpenProcessToken
• AdjustTokenPrivileges
• RegOpenKeyExA
• RegCloseKey
• RegCreateKeyExA
• RegDeleteKeyA
• RegQueryValueExA
• RegSetValueExA

Now that the driver is loaded into kernel space, it abuses its write dispatch routine to write the bootloader into the first sector of each disk with the help of the drivers’ symbolic link \\.\wowrt\DR\DISK%u.

When the malware is executed on a Windows version earlier than Vista, it uses the \.\PhysicalDrive%u symbolic link to install the bootloader.

After the bootloader is installed, it again creates the driver service in the registry to unload the driver from kernel space with NtUnloadDriver. When the driver is unloaded, it additionally overwrites the driver file on disk with zero bytes before it finally deletes it with DeleteFile.

Figure 2 shows the driver deletion routine.

Finally, the malware tries to get SeShutdownPrivilege token rights to force a system reboot with the ExitWindowsEx function to trigger the bootloader execution.

When rebooted, the GRUB 2 bootloader shows an image and periodically plays Dixie through the PC speaker. This behavior could indicate that the malware is an offensive prank. Notably, patching a system with this customized GRUB 2 bootloader image of the malware only works on certain disk configurations.

We performed multiple tests on various Windows 10 virtual machines (VM) using both BIOS and UEFI firmware options during installation. Table 3 shows the results of execution on those test VMs along their corresponding partition configurations and firmware versions.

Table 3. Test results of malware executed on different Windows 10 systems.

This code was found in the GRUB 2 image extracted from its configuration file:

The function load_video checks the availability of all video modules. If no video modules are available, it loads specified video modules.

The commands set linux_gfx_mode= and export linux_gfx_mode set and export the variable for the Linux graphics mode, while the load_video function call loads video modules. Modules for the graphics terminal and PNG images are loaded through insmod gfxterm and insmod png respectively.

The output of the terminal is set to the graphics terminal through the command terminal_output gfxterm. An image is set as a background image for the GRUB menu using the command background_image /image.png. The GRUB menu is paused for 60 seconds using the commands echo and sleep 60. The Dixie audio file is played during this pause using the command play /dixie.play. Lastly, the location of the main GRUB configuration file is specified through the command configfile /grub2/grub.cfg.

Summary of a Dixie-Playing Bootkit

To our knowledge, this is the first malware that installs a GRUB 2 bootloader. While having a few characteristics of previous Equation Group samples, we do not believe this malware is connected to this threat actor. We believe this malware is a PoC created by somebody from the University of Mississippi and they might have dropped it on a campus computer.

While the abused third-party driver was later also found to be vulnerable by Northwave Cyber Security, this malware merely abused it to write the bootloader to disk, because this driver is also unsecured. There is no exploit used, but it rather abuses the driver’s unsecured write dispatch routine. The usual term “bring your own vulnerable driver” (BYOVD) wouldn’t really fit in this case.

Example 3: A Red Team Framework Named ProjectGeass

This stood out from the various red team tools we came across in 2024 because it seems to be a new multi-platform post-exploitation framework written from scratch and still in development. This malware is named ProjectGeass and is a self-described beacon Windows sample. The term beacon commonly describes the agent of a post-exploitation toolkit.

This sample was submitted to VirusTotal from Singapore as the only file from that source.

This ProjectGeass sample was developed in C++ and contains several debug messages and artifacts with some indicators of other beacons for Android and Unix/Linux. The sample has the OpenSSL and Boost.Asio libraries statically linked, making it quite large at 6 MB.

Interestingly this tool uses the term “maneuver” for the execution of third-party files, indicating that this framework could have been used for a red team/blue team test.

Technical Analysis of a Red Team Framework Named ProjectGeass

The ProjectGeass beacon sample is a 64-bit Windows executable (SHA256 hash: cca5df85920dd2bdaaa2abc152383c9a1391a3e1c4217382a9b0fce5a83d6e0b) that was compiled on Oct. 31, 2023, with Microsoft Visual Studio C++. It has multiple project paths left as debug artifacts, giving a good impression of the inner structure of the project:

We can use a tool like SusanRTTI and GraphWiz to visualize the C++ Run-time type information (RTTI) to get a better understanding of the code structure. Figure 3 shows an excerpt of the class inheritances in this ProjectGeass sample.

As noted in Figure 3, the authors named multiple classes Windows or OnWindows, which implies there are other classes with the same purpose but for different operating systems. This ProjectGeass sample also contains a class named ListDirectoryCrossPlatform that hints at support for other platforms. Also, as part of the endpoint collection routines, this sample tries to figure out if the platform it’s executed on is Windows, Android, Unix or Linux. All these indicators suggest that ProjectGeass is a multi-platform post-exploitation framework supporting multiple operating systems.

The ProjectGeass beacon has the following features:

• File upload/download
• Execute Windows commands
• Get/set heartbeat data
• Sleep time adjustment
• Enumerate processes
• Start/stop keylogger
• Process listing/termination
• File manager (e.g., create/list/rename/delete directories, files, attributes)
• Receive and execute payloads
• Get endpoint information (e.g., network, disk, user)

While most strings are stored in cleartext, some are encrypted with a simple XOR-based algorithm with each string having its own key. Table 4 shows the decrypted strings with their connected features.

Table 4. Decrypted strings and their purposes.

The configuration data is located in the .data section and is RC4-encrypted. This data is implemented as a structure with the decryption key in cleartext (F5g3dsriT05L5RuTfHZlJX4dJfOVRJIsWjLC) followed by the encrypted configuration data.

Table 5 shows the decrypted configuration data.

Table 5. Decrypted beacon configuration data.

Summary of a Red Team Framework Named ProjectGeass

ProjectGeass is a post-exploitation framework that appears to have been developed for a professional or commercial purpose. As we have not yet found any other similar samples, this may be a private or non-public project. We cannot attribute it to any known company or organization. Since this malware uses a Chinese site (ipv4.renfei[.]net) to check its host's external IP address, the creator might be Chinese. However, that is all conjecture.

Conclusion

A number of new and interesting types of malware appeared in the past year, each using strategies that had not been reported before. This article reviewed three examples.

The first piece of malware we examined is a passive IIS backdoor that showed indications that attackers used it in targeted attacks. It was also developed in a programming language rarely used for malware, C++/CLI.

The second sample uses a third-party kernel driver to install a GRUB 2 bootloader, which we have not seen before.

The third sample, named ProjectGeass, appears to be a new post-exploitation framework in development. This may have been created for professional or commercial purposes, and possibly developed by a Chinese speaker.

Palo Alto Networks customers are better protected from these malware samples through Advanced WildFire, with its different memory analysis features.

Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

IIS Backdoor

SHA256 hash: 15db49717a9e9c1e26f5b1745870b028e0133d430ec14d52884cec28ccd3c8ab

• File size: 238,592 bytes
• File name: proxyscrape.dll
• File name internal: proxyxml_v4.dll
• File type: 64-bit Windows DLL
• Description: Main module version 2

SHA256 hash: aa2d46665ea230e856689c614edcd9d932d9edad0083bf89c903299d148634a2

• File size: 15,360 bytes
• File name: -
• File name internal: ReflectiveDLL.dll
• File type: 64-bit Windows DLL
• Description: Reflective loader embedded in main module version 2

SHA256 hash: a28d0550524996ca63f26cb19f4b4d82019a1be24490343e9b916d2750162cda

• File size: 19,456 bytes
• File name: VC_REDIST_CONFIG_X64.TXT
• File name internal: -
• File type: 64-bit Windows EXE
• Description: Wrapper application for cmd.exe embedded in main module version 2

SHA256 hash: 8571a354b5cdd9ec3735b84fa207e72c7aea1ab82ea2e4ffea1373335b3e88f4

• File size: 191,488 bytes
• File name: proxyxml.dll
• File name internal: IISShellModule.dll
• File type: 64-bit Windows DLL
• Description: Main module version 1

SHA256 hash: 94017628658035206820723763a2a698a4fd7be98fc2c541aad6aa0281ef090e

• File size: 14,848 bytes
• File name: -
• File name internal: ReflectiveDLL.dll
• File type: 64-bit Windows DLL
• Description: Reflective loader embedded in main module version 1

Bootkit

SHA256 hash: 950243a133db44e93b764e03c8d06b99310686d010b52b67f4effa57f0d72e04

• File size: 6,444,544 bytes
• File name: w32analytics.dll
• File name internal: loader.dll
• File type: 64-bit Windows DLL

ProjectGeass

SHA256 hash: cca5df85920dd2bdaaa2abc152383c9a1391a3e1c4217382a9b0fce5a83d6e0b

• File size: 6,040,576 bytes
• File name: -
• File name internal: -
• File type: 64-bit Windows EXE