The Hunt for the Lost Soul: Unraveling the Evolution of the SoulSearcher Malware

FortiGuard Labs Research

Affected Platforms: Windows
Impacted Users: Windows Users
Impact: Collects sensitive information and executes additional malicious modules
Severity Level: Critical

A threat report published by Symantec in October 2021 recently caught our attention. It discusses an unknown threat actor conducting an espionage campaign in Southeast Asia using a new custom malware arsenal. What piqued our curiosity most was the mention of a DLL payload loaded from the registry that had yet to be discovered.

The reason the module was difficult to find became apparent after analyzing its loader. The module is stored as a compressed blob with a custom header in the registry. It is never written to disk, rendering it unlikely to appear in datasets like VirusTotal.

And so, we embarked on a journey to hunt for the lost module. We have now uncovered a sample of the module and a plethora of components and variants dating as far back as 2017. Reverse engineering the samples has allowed us to observe the progression of the development of this malware throughout the years. Over time, custom code was added, components were upgraded, capabilities expanded, the code became neater, and modularity increased.

This blog will examine the different components of this malware and their progression over time, thereby mapping the evolution of the Soul malware framework.

Theory of Evolution

In the earliest phase, the attackers used a backdoor that incorporated code of the open-source Gh0st RAT and NetBot Attacker tools, albeit with considerable modifications. The backdoor is embedded as a compressed blob in its dropper executable, which writes it to disk and runs it.

Within a year, the backdoor’s code was refactored and had custom code added to it, completing its transformation into what we refer to as a Soul module. Its loader, which we dubbed SoulSearcher, changed as well. Instead of dropping the payload to disk, the compressed module is stored in the registry and is loaded in-memory.

Since the beginning of 2020, we have detected increasingly intricate SoulSearcher variants, some of which support loading multiple modules from the registry. They have significantly transformed over time, and their configuration artifacts shed light on possible Soul module capabilities.

Aside from the backdoors, additional tools were used, such as keyloggers and a custom-compiled 7zr tool (reduced standalone 7-zip).

A complete timeline of the various components is depicted below, beginning in 2017 with the first keylogger and backdoor and ending with the recent SoulSearcher variants found in November 2021.

Side note: This timeline is based on compilation timestamps, and although these can be tampered with, in the case of this malware framework, we consider them to be authentic. This is partly because the time distribution of the collected samples correlates with our understanding of the components’ capabilities and their sightings in the wild. Furthermore, related samples such as loaders and their payloads were compiled within seconds of each other.

Several characteristics are common in all of the components we found:

• DynamiCall import obfuscation from the leaked source code of the notorious Hacking Team’s
• RCS backdoor
• Stack strings
• Data structure similarity, such as the configuration structure
• Encryption and compression algorithms
• Names of mutexes, events, and file mappings
• Adjacent compilation timestamps

The Original Soul Backdoor

This is the backdoor used in the earliest phase by the threat actor. It was compiled in October 2017 and used revised code from public repositories and other malware leaked online, such as:

• DynamiCall
• Gh0st RAT
  • File manipulation functions
  • CMD shell code
  • Communication messages and structures
• HTran (an open-source connection bouncer tool)
• 7zip

The backdoor is a DLL dropped to the disk by a simple dropper. The dropper LZMA-decompresses the backdoor and a configuration that they both share. The dropper writes the backdoor to a path specified by the configuration and appends the configuration to it as an overlay. Depending on the command-line argument passed to the dropper, the backdoor is executed with LoadLibrary or rundll32.exe. Finally, the dropper deletes itself from the disk.

Configuration

The backdoor reads its configuration from its file overlay and decrypts it by subtracting and XORing each byte with 0x13.

The configuration begins with a sequence of bytes whose significance is unknown but is identical in all the samples we found. Other fields are the backdoor file name or full path, the C2 address, and the port in little-endian. The configuration also contains a service name and description, both unused. In one sample, the string “NetBot” is set as the file name.

Two other fields, an array of DWORDs and a flag (highlighted at offset 0x1f0), control if and when the backdoor should suppress command-related communication.

The array’s values determine the days and hours to accept commands. In this sample, all values are 2. Each index represents a particular day of the week and the hour of the day. If the value at a given index is 0, requests for commands are withheld on the corresponding day and hour.

The flag determines if receiving commands should be suppressed while there is activity on the machine, according to the following conditions:

• Other than the current session, there is an active console session in the system
• Other than the current session, there is an active or connected RDP session in the system

The sessions are monitored by using the WTSRegisterSessionNotification and WTSEnumerateSessions APIs.

Depending on the configuration, the backdoor can receive commands in active mode (as a client) or passive mode (as a server). There are two port numbers, one for each mode.

• If the server port is not 0, the backdoor contacts the server to receive commands.
• If the listening port is not 0, the backdoor listens on that port and awaits commands from incoming connections (only one connection may be active at a time).

Communication

Messages to the C2 server, including requests for commands, have a fixed structure. Every request to the server is composed of hardcoded HTTP headers impersonating legitimate network traffic to taboola[.]com.

The structure of the HTTP body sent to the server is depicted below. CompressedBuffer is zlib-deflated data.

Receipt of commands begins when the backdoor sends information about the machine to the server with a MessageType of 0x11000000:

• Hostname
• IP address(es)
• CPU architecture
• RAM size

The server response structure is similar to that of the request:

In a separate thread, the backdoor may signal the server if command receipt suppression is currently in effect with MessageType 0x1100000B.

Commands

When the server sends a command, it is one of the CommandType values in the table below, and the CompressedBuffer field is empty. The backdoor sends out an additional request for the command’s parameters, with a MessageType value specified according to the specific command.

The same is true when the backdoor works in passive mode, except it is limited to handling file manipulation, CMD, and close socket commands.

The Soul-Searching Loaders

SoulSearcher is a type of second-stage loader seen in the wild since November 2018. All the samples we found are DLLs with a similar flow of operation. They are responsible for executing the Soul module payload and parsing its configuration.

The major differences between the SoulSearcher variants are the type of configuration passed to the payload and the location where the configuration and payload are stored.

Binary SoulSearcher

These are the earliest SoulSearcher samples in our possession. One of these samples has its payload—a Soul module—embedded in it. Every sample exports two functions: DumpAnalyze and DumpAnalyzeEx.

First, SoulSearcher searches for the module and configuration, either in its overlay data or files on the disk. If they are found, it saves the module to the registry. Regardless, SoulSearcher then fetches the payload from the registry, reflectively loads it, and passes the configuration to it as an argument.

The configuration is located at the end of the overlay and is decrypted using SUB-XOR 0x13. It has the same format as that of the original Soul backdoor, with an additional field that determines the size of the compressed Soul module in the overlay. Another part of the configuration is retrieved from the HKCUSoftwareOIfkO2i1 registry value and decrypted with SUB-XOR 0x79. If it doesn’t exist, this path is also queried in the other users’ registry hives.

If the argument “-h <HANDLE>” was passed to the SoulSearcher’s export, the configuration and the payload are extracted from sdc-integrity.dat instead of the overlay. They are extracted in the exact same way as before. The supplied argument is a handle to a DLL used to retrieve the directory path in which the .dat file resides.

In any case, the module is saved to the registry at HKCUSoftwarekuhO6Ba0kT.

XML SoulSearcher

Every XML SoulSearcher begins with obtaining the configuration previously dropped by an unknown component. Most samples retrieve it from the registry, and some have the option of retrieving it from a file mapping object or a file on the disk.

For example, one sample retrieves the configuration from one of the following, depending on whether it is running as a service:

• A value name in the format of a GUID under the service parameters at HKLMSYSTEMCurrentControlSetServices<ServiceName>Parameters
• A file mapping object named GlobalCacheDataMapping

The retrieved binary data has the following structure:

The structure is processed in the following manner to retrieve the XML configuration:

1. Verify that the size of CompressedConfig is equal to CompressedConfigSize
2. Verify that CompressedConfigSize and ConfigSize are not 0
3. Verify that both MD5 checksums are not 0
4. Ensure that Magic ​​​​​​​holds the byte sequence 86 AE 00 00
5. Perform MD5 checksum validation of the compressed configuration
6. LZMA-decompress the configuration
7. Perform MD5 checksum validation of the decompressed configuration

In one variant, an extra step is taken at the start to decrypt the registry data using AES-256 CBC. The key is retrieved from one of two hardcoded paths.

Older samples deserialize the resulting string with the CreateXmlReader API, while newer samples use the TinyXML open-source library. The XML attribute names shed light on the Soul modules loaded from the registry.

Semicolon SoulSearcher

Beginning in August 2021, SoulSearcher variants began using a hardcoded semicolon-separated configuration instead of an XML one from the registry. The first variant of this type was compiled just over a full month before the release of Symantec’s report.

This configuration lacks the indicative XML attribute names, like those in the XML configurations, resulting in a more obscure tool. Nevertheless, here is what we can say about some of these fields:

• We believe the first field, do5Kc1diLHgq5f6 represents the configuration type. In the XML configurations, the type is represented by the string X6bmLMbAL29AlxB.
• One of the values states whether the SoulSearcher was installed as a service. If so, the configuration includes fields for details about the service, such as its name.
• Some of the values determine which Soul modules should be loaded.
• One field may contain a registry path from which to load a Soul module (while other modules are loaded from hardcoded paths).

When the Soul is Found

Older SoulSearcher variants load a single Soul module, while some more recent XML and Semicolon SoulSearchers may load up to four, depending on their configuration.

Every module is fetched from the registry in a similar manner as the configuration:

1. Verify that the size of CompressedModule is equal to CompressedModuleSize
2. LZMA-decompress the module
3. Perform MD5 checksum validation of the decompressed module
4. Ensure that the architecture of the module matches the architecture of the SoulSearcher

This procedure is identical in every SoulSearcher sample apart from the Binary SoulSearchers, whose structure slightly differs.

The SoulSearcher reflectively loads the module in-memory and calls its Construct export. Some earlier variants also call additional exports of the module.

Soul Backdoor Reincarnated

We found that one Binary SoulSearcher sample from November 2018 had an embedded payload.

This Soul module closely resembles the original backdoor in terms of functionality, although its code is much neater. Thorough examination revealed that the code of the original backdoor was reorganized as various exports. For instance, the code responsible for sending and receiving HTTP messages was divided into the SendMsg ​​​​​​​and RecvMsg ​​​​​​​exports.

Configuration

The SoulSearcher calls the module’s BeginConnect export with the configuration as an argument. The configuration has the same binary format as the original backdoor’s configuration but without the service-related fields.

Communication

Unlike the original backdoor, this Soul module only receives commands as a client.

If resolving the server address via gethostbyname API fails, the backdoor also tries querying two hardcoded DNS servers using an undocumented feature of the DnsQuery API:

• 193.0.14.129 (DNS root server)
• 8.8.8.8 (Google Public DNS)

The constant headers of the request have been changed to impersonate traffic to s-microsoft[.]com, and the GetSubInfo export collects the machine information.

Commands

The message structures are the same as those of the original backdoor. As seen in the table below, several new command codes were not present in the original backdoor. When one of the five named commands is received, the backdoor downloads and executes a DLL from the server. The command names are disclosed in the binary and are passed to the command DLLs as part of their arguments. Because the DLLs themselves are unknown to us, we can only speculate on their functionality based on their names and the implementations of the same command types in the original backdoor code.

An additional socket connection is created to download a command DLL from the server. First, the backdoor sends a message of type 0x1100000C with a buffer that contains the constant value 0x4096C083. Like all requests, it is sent via SendMsg in the aforementioned BackdoorRequest structure. Next, it sends another message of the same type, but this time the buffer is structured as shown below. The Architecture field contains a value of either 32 or 64 depending on the backdoor’s architecture.

The server replies to the backdoor with the following structure:

The backdoor uses the structure to load the command DLL in the following manner:

1. Validate MD5 checksum of compressed module
2. LZMA-decompress the compressed module
3. Validate MD5 checksum of decompressed module
4. If steps 2 or 3 fail, reissue the request to the server
5. Reflectively load the module in memory
6. Call the module’s Construct export with arguments that include, among other things:
   1. The constant value 0x4096C083 (same value sent to the server priorly)
   2. The name of the command (such as “File” or “UsbNtf”)
   3. The backdoor configuration
   4. The CommandResponse structure received from the server

More Souls Than One

As mentioned earlier, each XML SoulSearcher parses an XML-formatted configuration that contains attributes with informative names. Based on such artifacts, we were able to classify potential payloads of various samples in our possession.

Backdoor

These SoulSearcher samples are closely coupled to their payloads to the extent that they are intricate orchestrators rather than plain loaders. In addition to parsing a configuration, they invoke multiple exported functions of the Soul module to create full backdoor logic. The configuration fields and imported function names indicate remote shell capability and the utilization of Dropbox.

Advanced RAT

One SoulSearcher parses numerous configuration fields different from the backdoor:

If the EnableDropbox attribute is set to true, the SoulSearcher loads a module from the path specified by ServiceRegValueName_MemMod3. If the EnableKeylog ​​​​​​​ is set, a module is loaded from the path specified by ServiceRegValueName_MemMod1.

Proxy

These samples’ configuration indicates proxy capabilities over HTTP and HTTPS, as well as the ability to run CMD commands.

Additional Components

First Stage Loader

As mentioned before, SoulSearcher is a second-stage component. We also identified a first-stage loader of the Binary SoulSearcher variant.

This loader is a DLL with a single exported function, named SntpService, and depends on a utility DLL named SntpService.dll, which is expected to already reside on disk. These names are likely used to resemble a legitimate security software product of Sophos of the same name (as seen here).

The loader checks if its process name is either MSDTC.exe or svchost.exe prior to running SntpService in a new thread. In the latter case, a mutex named DBWinMutex_1 is created (also used in the Soul module).

The loader performs two operations. First, it decrypts two .dat files from its directory and saves the output to the registry:

• sdc-integrity.dat is written to HKCR.ratPersistentHandlerTypeFace
• scs-integrity.dat is written to HKCR.ratPersistentHandlerMagicNumber

The decryption scheme is AES-256 CBC with the SHA256 hash of a hardcoded value used as the key. Both files are then deleted from the disk, implying this procedure occurs only on initial infection or when updates are deployed.

Second, the data from the TypeFace ​​​​​​​value is used to load SoulSearcher. It consists of a structure that contains a buffer and its size. The loader skips the buffer’s last 0x3d0 ​​​​​​​bytes, as those are its configuration, and passes the rest of the buffer to the Decrypt_ByteToByte function of SntpService.dll. The output is a PE, which the loader reflectively loads and then invokes its DumpAnalyze ​​​​​​​export. The loader passes a handle of itself to the SoulSearcher as an argument, both as a pointer and in string format: “-h <HANDLE>”.

 Additional exports of SntpService.dll are also resolved:

We found a variant of the utility DLL uploaded to VirusTotal with the name of Kaspersky Antivirus’s AvpCon.dll. Similar to the Sophos case cited earlier, this is likely done to appear legitimate. Despite its exports being named “Encrypt” and “Decrypt”, all functions actually perform LZMA compression or decompression. This correlates with a Binary SoulSearcher sample that we found compressed, not encrypted.

Keyloggers

The keyloggers were compiled between mid-2017 to late 2020. They all share very similar code, with few changes between them. In addition to the keyloggers Symantec reported on, we found another sample from September 2020. Although its keylogging function is identical to the other samples, the rest of the code has significant differences.

The keyloggers read their configuration from a file with the same name but with the .dll extension trimmed. Our sample, however, uses a configuration from the registry, and the file acts as a kill-switch: if it exists, the keylogger terminates. This sample also has stack strings and DynamiCall obfuscations not present in previous samples.

The keylogger ensures it is running in Explorer.exe and retrieves its configuration by reading its own last 0x208 bytes and decrypting them. The decryption is done by adding and XORing each byte with constant values. Next, the encrypted configuration is set in the registry at HKCUSoftwareF32xhfHX. On future executions, the configuration will be fetched from this key. The configuration contains two paths:

• Keylogger module file – C:WindowsSndVolSSO.DLL
• Keylogging output file – C:usersminhAppDataLocalOneDriveCache.dat

Interestingly, the output file path includes a username, hinting that this sample may have been intended for a specific target machine.

The keylogger monitors keystrokes using GetRawInputData and clipboard data and logs them in an output file as plaintext. The output file is timestomped to make its timestamp identical to svchost.exe on the infected machine. Errors returned from GetRawInputData are logged to C:ProgramDataUsers.inf. The keylogger also logs IME virtual-key codes, which support some Asian languages.

Command-Line Executer Service

This is a lightweight service DLL that executes a CMD command from the registry key HKCR.cTypeType00. It runs the command on 20:00, and if no process named powershell.exe is active on the system. It is compiled with DynamiCall obfuscation.

7zr.exe

This custom-compiled 7zr executable is modified to include DynamiCall obfuscation.

Conclusion

The Soul malware framework has been in active use since 2017, and the threat actors have been steadily evolving their tools and capabilities to this day. It should be emphasized that despite the reliance of the earlier tools on open-source code, custom keyloggers were already in use at the time, and significant development of custom code has transpired since. Its modular, multi-stage, reflectively executed payloads demonstrate competent adversarial tradecraft and are signs of a well-resourced group. Although the attackers’ identity is currently unknown, we believe that they are possibly state-sponsored.

The details shared in this report stem from the comprehensive analysis of numerous samples. Nevertheless, we have a feeling that this is just the tip of the iceberg, with more payloads and capabilities in the group’s arsenal to expose in the future.

Fortinet Solutions

FortiEDR detects and blocks these threats out-of-the-box without any prior knowledge or special configuration. It does this using its post-execution prevention engine to identify malicious activities:

All network IOCs have been added to the FortiGuard WebFiltering blocklist.

The FortiGuard AntiVirus service engine is included in Fortinet’s FortiGate, FortiMail, FortiClient, and FortiEDR solutions. FortiGuard AntiVirus has coverage in place as follows:

W64/SoulSearcher.B7D1!tr
W32/SoulSearcher.B7D1!tr
W64/SoulSearcherKeyLogger.B7D1!tr.spy
W32/SoulSearcher.B7D1!tr 
Data/SoulSearcher.B7D1!tr

In addition, as part of our membership in the Cyber Threat Alliance, details of this threat were shared in real-time with other Alliance members to help create better protections for customers.

Learn more about Fortinet’s FortiGuard Labs threat research and intelligence organization and the FortiGuard Security Subscriptions and Services portfolio.