{
	"id": "2e439af7-a24e-4d18-a0cc-7f4abe232049",
	"created_at": "2026-04-06T00:07:00.296711Z",
	"updated_at": "2026-04-10T13:12:02.851519Z",
	"deleted_at": null,
	"sha1_hash": "1ec421e593d55cce1fb0161cb04c5f331204e7cb",
	"title": "Technical Analysis of RiseLoader | ThreatLabz",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 424489,
	"plain_text": "Technical Analysis of RiseLoader | ThreatLabz\r\nBy ThreatLabz\r\nPublished: 2024-12-16 · Archived: 2026-04-05 22:01:58 UTC\r\nThe following sections describe some of the features in RiseLoader. \r\nAnti-analysis techniques\r\nMost of the RiseLoader samples analyzed by ThreaLabz are packed with VMProtect. In addition, the malware\r\nobfuscates important strings. For example, all RiseLoader samples included the following strings related to\r\nmalware analysis and debugging:\r\nollydbg.exe\r\nprocesshacker.exe\r\ntcpview.exe\r\nfilemon.exe\r\nprocmon.exe\r\nregmon.exe\r\nprocexp.exe\r\nida.exe\r\nida64.exe\r\nbinaryninja.exe\r\nimmunitydebugger.exe\r\nwireshark.exe\r\ndumpcap.exe\r\nhookexplorer.exe\r\nimportrec.exe\r\npetools.exe\r\nlordpe.exe\r\nsysinspector.exe\r\nproc_analyzer.exe\r\nsysanalyzer.exe\r\nsniff_hit.exe\r\nwindbg.exe\r\njoeboxcontrol.exe\r\njoeboxserver.exe\r\napimonitor.exe\r\napimonitor-x86.exe\r\napimonitor-x64.exe\r\nx32dbg.exe\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 1 of 9\n\nx64dbg.exe\r\nx96dbg.exe\r\ncheatengine.exe\r\nscylla.exe\r\ncharles.exe\r\ncheatengine-x86_64.exe\r\nreclass.net.exe\r\nThese strings are defined in a global array, but are not used during execution. This may indicate that anti-analysis\r\nfeatures are currently in development and will potentially be implemented in future versions.\r\nNote that RiseLoader does not currently use stack-based string obfuscation, which is present in RisePro and\r\nPrivateLoader.\r\nBehavioral analysis\r\nThe malware starts by creating a mutex using hardcoded strings for the name. The mutex name will be a\r\ncombination of three strings such as:  winrar8PROMEMEKGAmaV3_2_8 . The mutex is formed from a prefix\r\n( winrar8 ), a  campaign_id value ( PROMEMEKG ), and a hardcoded suffix ( AmaV3_2_8 ). If the mutex exists,\r\nRiseLoader will terminate. Samples analyzed by ThreatLabz have lacked a persistence mechanism, although this\r\nmay be a configurable parameter (similar to other malware loaders).\r\nNext, RiseLoader randomly selects a C2 server from a hardcoded list and opens a TCP connection. This process is\r\nrepeated up to 10 times until a connection is established. If unsuccessful, RiseLoader terminates. Upon successful\r\ncommunication with the C2 server, a new thread is launched to continuously check for commands, process them,\r\nand send system information as requested. Additionally, another thread handles the  PAYLOADS data from the C2\r\nserver, creating a randomly generated folder in the user’s temporary directory to process each payload. This thread\r\nalso creates an infection marker by creating a registry key under certain conditions and prepares the arguments\r\nand delays for each payload.\r\nFinally, a new thread is created to download and execute each payload from URLs provided by the C2 server\r\nusing libcurl. DLL files are launched with  rundll32 , while executables are started by creating a new process.\r\nAfter all payloads are downloaded and executed, RiseLoader terminates.\r\nNetwork communication\r\nAfter establishing the TCP three-way handshake with the C2 server, RiseLoader expects the server to respond with\r\na message containing XOR keys used for subsequent communications. If the server does not send this message\r\nwithin a 10-second timeout, the malware will attempt to “wake up” the server by sending a  KEEPALIVE message.\r\nIf the server is online, it will respond with a  KEEPALIVE_RES message, and the malware will reset its timeout. If\r\nthe server does not respond, the malware will either attempt to reconnect or close the connection, and\r\ncall  ExitProcess after 10 failed attempts.\r\nAfter receiving the XOR keys, the malware sends a  campaign_id and other information to the server, then waits\r\nfor the PAYLOADS command. The server can close the connection at any time without notifying the client.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 2 of 9\n\nAdditionally, a  SEND_SHUTDOWN command will immediately terminate the malware. The server periodically\r\nsends  KEEPALIVE messages to ensure continuous communication. If the  PAYLOADS command is received,\r\nRiseLoader processes the packet and sends either an  SL_TASKS_EXECUTED or  PL_TASKS_EXECUTED message with\r\nthe task information. Once the task commands are received, the server closes the connection. The message types\r\nexchanged in both directions share a common structure, as defined below:\r\nstruct message {\r\n uint32_t magic_bytes; // Hardcoded to 0x00020001\r\n uint32_t data_size;\r\n uint32_t message_type;\r\n byte data[data_size];\r\n}\r\nThe  magic_bytes field may represent a protocol version (i.e., version 1.0.2.0 in little endian byte format),\r\nalthough it is too early to determine the value’s exact meaning since this malware family is new.\r\nNot all messages contain data; for these, the data_size will be zero. For messages that contain data, the structure\r\nvaries. Some messages use a UTF-8 encoded JSON string, while others, like the  SET_XORKEYS and  SEND_ID\r\nmessage types, use a byte structure.\r\nThroughout the communication process, the data field will be encoded using one of the XOR keys defined by the\r\nC2 server in the  SET_XORKEYS message. \r\nThe RiseLoader message types are shown in the following table:\r\nMessage Type\r\nMessage\r\nValue\r\nDescription and Payload Source\r\nSEND_VICTIM_INFO 0x2B\r\nSends information related to cryptocurrency\r\nwebsites, wallets, and web browser extensions.\r\nSent by\r\nthe client.\r\nSYS_INFO 0x2F\r\nSends information related to the victim’s machine in\r\na JSON format:\r\nap : Unused.\r\nbn : Windows build number. \r\nmi : Minor version.\r\nmj : Major version. \r\nc1 : Indicates if WoW64 process is present.\r\ntp : Indicates if this is a workstation.\r\nSent by\r\nthe client.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 3 of 9\n\nMessage Type\r\nMessage\r\nValue\r\nDescription and Payload Source\r\nSEND_ID_NEW_VICTIM 0x16C64\r\nSends the  campaign_id after checking that there is\r\nno former infection.\r\nSent by\r\nthe client.\r\nSEND_ID 0x16C63\r\nSends the  campaign_id if RiseLoader previously\r\nexecuted payloads on the victim’s system.\r\nSent by\r\nthe client.\r\nSL_FL_TASKS_EXECUTED 0x23E9\r\nSends a list of task IDs, which were downloaded and\r\nexecuted successfully. This message type is used\r\nonly for the payload URLs that were included in the\r\nJSON keys  sl and  fl .\r\nSent by\r\nthe client.\r\nPL_TASKS_EXECUTED 0x0b2f09\r\nSends a list of task IDs, which were downloaded and\r\nexecuted successfully. This message type is used for\r\nthe payload URLs that were included in the JSON\r\nkey  pl .\r\nSent by\r\nthe client.\r\nSET_XORKEYS 0xB6\r\nThe C2 server provides encryption keys that are used\r\nfor subsequent messages.\r\nThe first byte encodes message payloads from the\r\ninfected system and the second byte decodes\r\nmessage payloads coming from the C2 server.\r\nSent by\r\nthe\r\nserver.\r\nCHANGE_ID 0x20C9\r\nThe C2 server sends a new  campaign_id to the\r\nvictim.\r\nSent by\r\nthe\r\nserver.\r\nSEND_SHUTDOWN 0x1CCD Terminates execution.\r\nSent by\r\nthe\r\nserver.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 4 of 9\n\nMessage Type\r\nMessage\r\nValue\r\nDescription and Payload Source\r\nFORCE_REPORT_SL_FL 0x9C04\r\nForces sending a  SL_FL_TASKS_EXECUTED command\r\nwhile executing  pl tasks.\r\nSent by\r\nthe\r\nserver.\r\nPAYLOADS 0x4DCF\r\nThe C2 server sends a structure with several\r\npayloads to download and execute on the victim’s\r\nsystem in a JSON format.\r\nThere are three different arrays for\r\npayloads:  pl ,  fl , and  sl , each containing a\r\nsimilar structure where:\r\npl : Task ID.\r\nu : URL of the payload.\r\nag : The arguments when launching the\r\npayload.\r\nd : The delay of the download.\r\nf : The filename payload on the victim’s\r\nsystem.\r\nIn addition, the  so parameter will instruct the\r\nsample to set an infection marker by creating a\r\nregistry key, while  sp will specify the delay in\r\nmilliseconds between the execution of  fl and  sl\r\npayloads. The final parameter,  lo , will contain a\r\nURL of an image that is potentially used for tracking\r\npurposes.\r\nSent by\r\nthe\r\nserver.\r\nKEEPALIVE 0x6B5 Requests a response from  KEEPALIVE_RES .\r\nSent by\r\nboth the\r\nclient and\r\nthe\r\nserver.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 5 of 9\n\nMessage Type\r\nMessage\r\nValue\r\nDescription and Payload Source\r\nKEEPALIVE_RES 0x4B7C The response to the  KEEPALIVE message.\r\nSent by\r\nboth the\r\nclient and\r\nthe\r\nserver.\r\nTable 1: RiseLoader message types exchanged between the client and the server.\r\nThe figure below shows a high-level view of RiseLoader’s network communication protocol.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 6 of 9\n\nFigure 1: RiseLoader network communication protocol.\r\nNetwork communication starts with the server sending a  SET_XORKEYS message that contains two 1-byte XOR\r\nkeys: the first for encrypting messages from the client, and the second for decrypting messages received from the\r\nserver. After establishing the encryption keys for the session, the client sends either a  SEND_ID_NEW_VICTIM\r\nor  SEND_ID message. RiseLoader will determine which of these messages to use  based on the existence of a\r\nspecific registry key ( HKEY_CURRENT_USER\\SOFTWARE\\dmdsaodgmarksmdkgsa ). \r\nImmediately after sending the  campaign_id to the C2 server, RiseLoader will scan the victim's file system to\r\ngather information about cryptocurrency wallets, extensions, and specific programs (shown in the Appendix). This\r\ninformation will be sent to the server using the  SEND_VICTIM_INFO message type, followed by a  SYS_INFO\r\npacket. Once the system information is sent, the server will maintain the connection by exchanging  KEEPALIVE\r\nand  KEEPALIVE_RES messages with RiseLoader.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 7 of 9\n\nRiseLoader waits for a  PAYLOADS command containing a JSON encoded structure with payload URLs to\r\ndownload and execute on the victim’s system. The malware will then send  SL_FL_TASKS_EXECUTED\r\nand  PL_TASKS_EXECUTED messages to report the tasks that were executed.\r\nDuring the processing phase for payloads, RiseLoader may create a registry key depending on the value specified\r\nby the  so field in the  PAYLOADS data structure or when receiving the  FORCE_REPORT_SL_FL command from the\r\nC2 server. This registry key appears to serve as an infection marker and is located\r\nat  HKEY_CURRENT_USER\\SOFTWARE\\dmdsaodgmarksmdkgsa . Under this key the registry name  var1 is created with a\r\nhardcoded value set to  0x00b2 . The actual value is not relevant for execution, as RiseLoader only checks for the\r\npresence of the registry key when choosing to send either  SEND_ID or  SEND_ID_NEW_VICTIM messages.\r\nAfter processing all payloads, RiseLoader downloads a resource from a URL specified in the  lo parameter of\r\nthe  PAYLOADS structure. Currently, this URL resolves to a 1x1 pixel PNG file, likely serving as a tracking method\r\nsince the PNG file has no clear purpose in the malware code. After downloading and executing the payloads and\r\ndownloading the URL from the  lo parameter, RiseLoader will terminate its execution.\r\nComparison of the RiseLoader and RisePro communication protocols\r\nThe similarities between RiseLoader and RisePro are described below: \r\nBoth use a custom binary TCP-based protocol with encoded JSON messages encrypted by a single byte\r\nkey.\r\nThe message structure is very similar: magic bytes, followed by a 4-byte payload size, and a 4-byte\r\ncommand type as shown in the figure below.\r\nFigure 2: A comparison of RiseLoader’s C2 handshake and RisePro’s handshake, showing a similar structure. \r\nThe initialization process is similar; however, RiseLoader has been simplified.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 8 of 9\n\nSource: https://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-riseloader\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/technical-analysis-riseloader"
	],
	"report_names": [
		"technical-analysis-riseloader"
	],
	"threat_actors": [],
	"ts_created_at": 1775434020,
	"ts_updated_at": 1775826722,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1ec421e593d55cce1fb0161cb04c5f331204e7cb.pdf",
		"text": "https://archive.orkl.eu/1ec421e593d55cce1fb0161cb04c5f331204e7cb.txt",
		"img": "https://archive.orkl.eu/1ec421e593d55cce1fb0161cb04c5f331204e7cb.jpg"
	}
}