Technical Analysis of RiseLoader Reveals Similarities with RisePro’s Communication Protocol

Introduction

In October 2024, Zscaler ThreatLabz came across malware samples that use a network communication protocol that is similar to RisePro. However, unlike RisePro which has primarily been used for information stealing, this new malware specializes in downloading and executing second-stage payloads. Due its distinctive focus and similarities with RisePro’s communication protocol, we named this new malware family RiseLoader. RiseLoader’s emergence is interesting, as the threat actor selling RisePro announced in June 2024 on Telegram that its development was discontinued. Based on these factors, ThreatLabz assesses with moderate confidence that the threat group behind RisePro and PrivateLoader is also behind RiseLoader.

In this blog, we explore RiseLoader’s TCP-based binary protocol, and highlight the similarities between RiseLoader and RisePro.

Key Takeaways

• RiseLoader is a new malware loader family that was first observed in October 2024.
• The malware implements a custom TCP-based binary network protocol that is similar to RisePro.
• Many RiseLoader samples have used VMProtect to obfuscate the malware’s code.
• RiseLoader has been observed dropping malware families including Vidar, Lumma Stealer, XMRig, and Socks5Systemz – similar to those distributed by PrivateLoader.
• RiseLoader collects information about installed applications and browser extensions related to cryptocurrency.

Technical Analysis

The following sections describe some of the features in RiseLoader. 

Anti-analysis techniques

Most of the RiseLoader samples analyzed by ThreaLabz are packed with VMProtect. In addition, the malware obfuscates important strings. For example, all RiseLoader samples included the following strings related to malware analysis and debugging:

• ollydbg.exe
• processhacker.exe
• tcpview.exe
• filemon.exe
• procmon.exe
• regmon.exe
• procexp.exe
• ida.exe
• ida64.exe
• binaryninja.exe
• immunitydebugger.exe
• wireshark.exe
• dumpcap.exe
• hookexplorer.exe
• importrec.exe
• petools.exe
• lordpe.exe
• sysinspector.exe
• proc_analyzer.exe
• sysanalyzer.exe
• sniff_hit.exe
• windbg.exe
• joeboxcontrol.exe
• joeboxserver.exe
• apimonitor.exe
• apimonitor-x86.exe
• apimonitor-x64.exe
• x32dbg.exe
• x64dbg.exe
• x96dbg.exe
• cheatengine.exe
• scylla.exe
• charles.exe
• cheatengine-x86_64.exe
• reclass.net.exe

These strings are defined in a global array, but are not used during execution. This may indicate that anti-analysis features are currently in development and will potentially be implemented in future versions.

Note that RiseLoader does not currently use stack-based string obfuscation, which is present in RisePro and PrivateLoader.

Behavioral analysis

The malware starts by creating a mutex using hardcoded strings for the name. The mutex name will be a combination of three strings such as: winrar8PROMEMEKGAmaV3_2_8. The mutex is formed from a prefix (winrar8), a campaign_id value (PROMEMEKG), and a hardcoded suffix (AmaV3_2_8). If the mutex exists, RiseLoader will terminate. Samples analyzed by ThreatLabz have lacked a persistence mechanism, although this may be a configurable parameter (similar to other malware loaders).

Next, RiseLoader randomly selects a C2 server from a hardcoded list and opens a TCP connection. This process is repeated up to 10 times until a connection is established. If unsuccessful, RiseLoader terminates. Upon successful communication with the C2 server, a new thread is launched to continuously check for commands, process them, and send system information as requested. Additionally, another thread handles the PAYLOADS data from the C2 server, creating a randomly generated folder in the user’s temporary directory to process each payload. This thread also creates an infection marker by creating a registry key under certain conditions and prepares the arguments and delays for each payload.

Finally, a new thread is created to download and execute each payload from URLs provided by the C2 server using libcurl. DLL files are launched with rundll32, while executables are started by creating a new process. After all payloads are downloaded and executed, RiseLoader terminates.

Network communication

After establishing the TCP three-way handshake with the C2 server, RiseLoader expects the server to respond with a message containing XOR keys used for subsequent communications. If the server does not send this message within a 10-second timeout, the malware will attempt to “wake up” the server by sending a KEEPALIVE message. If the server is online, it will respond with a KEEPALIVE_RES message, and the malware will reset its timeout. If the server does not respond, the malware will either attempt to reconnect or close the connection, and call ExitProcess after 10 failed attempts.

After receiving the XOR keys, the malware sends a campaign_id and other information to the server, then waits for the PAYLOADS command. The server can close the connection at any time without notifying the client. Additionally, a SEND_SHUTDOWN command will immediately terminate the malware. The server periodically sends KEEPALIVE messages to ensure continuous communication. If the PAYLOADS command is received, RiseLoader processes the packet and sends either an SL_TASKS_EXECUTED or PL_TASKS_EXECUTED message with the task information. Once the task commands are received, the server closes the connection. The message types exchanged in both directions share a common structure, as defined below:

struct message {
   uint32_t magic_bytes;  // Hardcoded to 0x00020001
   uint32_t data_size;
   uint32_t message_type;
   byte data[data_size];
}

The magic_bytes field may represent a protocol version (i.e., version 1.0.2.0 in little endian byte format), although it is too early to determine the value’s exact meaning since this malware family is new.

Not all messages contain data; for these, the data_size will be zero. For messages that contain data, the structure varies. Some messages use a UTF-8 encoded JSON string, while others, like the SET_XORKEYS and SEND_ID message types, use a byte structure.

Throughout the communication process, the data field will be encoded using one of the XOR keys defined by the C2 server in the SET_XORKEYS message. 

The RiseLoader message types are shown in the following table:

Table 1: RiseLoader message types exchanged between the client and the server.

The figure below shows a high-level view of RiseLoader’s network communication protocol.

Figure 1: RiseLoader network communication protocol.

Network communication starts with the server sending a SET_XORKEYS message that contains two 1-byte XOR keys: the first for encrypting messages from the client, and the second for decrypting messages received from the server. After establishing the encryption keys for the session, the client sends either a SEND_ID_NEW_VICTIM or SEND_ID message. RiseLoader will determine which of these messages to use  based on the existence of a specific registry key (HKEY_CURRENT_USERSOFTWAREdmdsaodgmarksmdkgsa). 

Immediately after sending the campaign_id to the C2 server, RiseLoader will scan the victim’s file system to gather information about cryptocurrency wallets, extensions, and specific programs (shown in the Appendix). This information will be sent to the server using the SEND_VICTIM_INFO message type, followed by a SYS_INFO packet. Once the system information is sent, the server will maintain the connection by exchanging KEEPALIVE and KEEPALIVE_RES messages with RiseLoader.

RiseLoader waits for a PAYLOADS command containing a JSON encoded structure with payload URLs to download and execute on the victim’s system. The malware will then send SL_FL_TASKS_EXECUTED and PL_TASKS_EXECUTED messages to report the tasks that were executed.

During the processing phase for payloads, RiseLoader may create a registry key depending on the value specified by the so field in the PAYLOADS data structure or when receiving the FORCE_REPORT_SL_FL command from the C2 server. This registry key appears to serve as an infection marker and is located at HKEY_CURRENT_USERSOFTWAREdmdsaodgmarksmdkgsa. Under this key the registry name var1 is created with a hardcoded value set to 0x00b2. The actual value is not relevant for execution, as RiseLoader only checks for the presence of the registry key when choosing to send either SEND_ID or SEND_ID_NEW_VICTIM messages.

After processing all payloads, RiseLoader downloads a resource from a URL specified in the lo parameter of the PAYLOADS structure. Currently, this URL resolves to a 1×1 pixel PNG file, likely serving as a tracking method since the PNG file has no clear purpose in the malware code. After downloading and executing the payloads and downloading the URL from the lo parameter, RiseLoader will terminate its execution.

Comparison of the RiseLoader and RisePro communication protocols

The similarities between RiseLoader and RisePro are described below: 

• Both use a custom binary TCP-based protocol with encoded JSON messages encrypted by a single byte key.
• The message structure is very similar: magic bytes, followed by a 4-byte payload size, and a 4-byte command type as shown in the figure below.

Figure 2: A comparison of RiseLoader’s C2 handshake and RisePro’s handshake, showing a similar structure. 

• The initialization process is similar; however, RiseLoader has been simplified.

Conclusion

The security research community has tentatively linked RiseLoader to PrivateLoader, which is also developed by the same threat actor behind RisePro. This may be due to behavioral similarities, since both have been dropping similar malware families. However, RiseLoader has a distinct communication protocol that is far more similar to RisePro than PrivateLoader.

RiseLoader and RisePro share several similarities in their network communication protocols, including message structure, the initialization process, and payload structure. These overlaps may indicate that the same threat actor is behind both malware families. RiseLoader appears to still be in development with potential upcoming features for information stealing and anti-analysis.

Zscaler Coverage

Zscaler’s multilayered cloud security platform detects indicators related to the new variant of RisePro at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for RiseLoader.

Figure 3: Zscaler sandbox report for RiseLoader.

Indicators Of Compromise (IOCs)

Appendix

Cryptocurrency websites targeted by RiseLoader

Cryptocurrency wallet software targeted by RiseLoader

Cryptocurrency wallet browser extensions targeted by RiseLoader