{
	"id": "f83971a5-b984-4f34-8467-fa66c990bc47",
	"created_at": "2026-04-06T00:12:36.790787Z",
	"updated_at": "2026-04-10T03:20:55.693271Z",
	"deleted_at": null,
	"sha1_hash": "65e11ffbe3868bcbd2f0ca35186905b80fe91846",
	"title": "RisePro Malware Analysis: New Version's C2 Communication",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 118143,
	"plain_text": "RisePro Malware Analysis: New Version's C2 Communication\r\nBy ANY.RUN\r\nArchived: 2026-04-05 19:17:38 UTC\r\nRisePro is a malware-as-a-service info-stealer, first identified in 2022. Recently, we’ve detected a spike in it’s activity and\r\ndecided to conduct an investigation, which led to interesting findings. \r\nRisePro is a well-documented malware, but we quickly realized that the network traffic patterns of our samples did not\r\nmatch the existing literature. It seemed like we had a new version on our hands. \r\nFurther analysis revealed that RisePro changed the way it communicates with C2 and that it has gained new capabilities —\r\nin particular, remote-control functions, making it capable of operating as a RAT. \r\nThis article will focus on this malware’s new network communication patterns, but first, a quick refresher about what\r\nRisePro malware is. \r\nWhat is RisePro malware?\r\nRisePro, an information-stealing malware, was first detected by cybersecurity firms Flashpoint and Sekoia. It is distributed\r\nthrough fake cracks sites operated by the PrivateLoader pay-per-install (PPI) malware distribution service. It is designed to\r\nsteal credit cards, passwords, and crypto wallets from infected devices. \r\nRisePro is potentially based on the Vidar password-stealing malware and it employs a system of embedded DLL\r\ndependencies. RisePro’s modus operandi includes fingerprinting the compromised system, writing stolen data to a text file,\r\ntaking screenshots, and then bundling and sending this data to the attacker’s server. \r\nThe PrivateLoader service, which distributes RisePro, is known for disguising malware as software cracks, key generators,\r\nand game modifications. It was first spotted by Intel471 in February 2022. Sekoia’s findings indicate that RisePro shares\r\nsignificant code overlaps with PrivateLoader, suggesting a deeper connection between the two. \r\nLike we said earlier, our analysis focuses on the recent changes in RisePro’s C2 communication and network traffic patterns\r\nof its latest version, which differ drastically from previous iterations. \r\nTraffic analysis of the new RisePro malware sample \r\nThere’s a big change to highlight right of the bat. Our sample uses custom protocol over TCP for communication.  This\r\nindicates a complete overhaul of the communication method, which previously transmitted instructions over HTTP. \r\nLet’s start our deep dive into this variant’s communication patterns. Here’s a screenshot of a network packet from ANY.RUN\r\nonline malware sandbox, which was the starting point of our investigation:\r\nComparing encrypted (left) and decrypted (right) packet content\r\nUpon examining the packet bytes (right column), it’s evident that the traffic is encrypted, making it indecipherable. The first\r\ntask, then, was to decrypt it. \r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 1 of 20\n\nSekoia researchers have already cracked this encryption, so, to start, we decided to try and apply their decryption algorithm.\r\nSurprisingly, it successfully decrypted the data. This means the same encryption is still used. \r\nThe encryption algorithm is a basic substitution cipher followed by XOR with key 0x36. By Testing it with different ports\r\nwe were able to find multiple keys. For example, the key for port 50500 is 0x36, and for port 50505 it is 0x79. Interestingly,\r\nopcodes take on different meanings depending on the port. In this article we will provide examples for port 50500. \r\nDiving deeper in the packet analysis \r\nBut let’s get back to the traffic analysis. Since we decrypted the TCP stream, we can begin to understand the structure of\r\neach packet.\r\nEach packet has 3 blocks that follow a set pattern\r\nIn the image above, we see several packets (the first being the initialization packet). Three distinct blocks are noticeable,\r\nfollowing a clear pattern. We can represent this structure as follows: \r\nPacket structure\r\nThe first 4 bytes, labeled as magic, are always repeated and determine the beginning of the packet. \r\nThe next 4 bytes define the length of the data attached to the packet, labeled as payload_len. \r\nAnd, as you can see from the screen above, immediately following is packet_type. \r\nDuring the analysis, we discovered the following packet_types, which represent various opcodes: \r\nPacket type  Value  Payload  Description \r\nSERVER_PING  0x2710 \r\n(OPTIONAL) text\r\nstring \r\nDefault response,  Keep-Alive (heartbeat) \r\nCLIENT_PING  0x2711    Keep-Alive (heartbeat) \r\nSERVER_INIT  0x2712  24 bytes string   Server Hello  \r\nSET_TIMEOUT  0x2713  Number string \r\nServer/client timeout for\r\naction (e.g. upload) \r\nCLIENT_REQUEST_FILE  0x2714  File name (string)  Request file from server\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 2 of 20\n\nPacket type  Value  Payload  Description \r\nSERVER_SEND_FILE  0x2715 \r\nFile name, compressed\r\nfile (zlib) \r\nUsed by server to send\r\nadditional libraries \r\nCLIENT_CONFIRM_IP  0x2716  Response string  IP receive confirmation \r\nSERVER_SEND_MARKS  0x2717  JSON string  List of marks configs \r\nCLIENT_CONFIRM_MARKS  0x2718  Response string  Marks receive confirmation \r\nSERVER_SEND_GRAB_CONFIG  0x2719  JSON string  Settings and grabbers \r\nCLIENT_CONFIRM_GRAB_CONFIG  0x271A  Response string \r\nSettings receive\r\nconfirmation \r\nSERVER_SEND_LOADER_CONFIG  0x271B  JSON string \r\nList of loader configs,\r\nincludes urls and execution\r\nconditions \r\nCLIENT_CONFIRM_LOADER_CONFIG  0x271C  Response string \r\nLoader configs receive\r\nconfirmation \r\nSERVER_SET_FILE_FILTER  0x271D  JSON string  List of file filtration rules \r\nCLIENT_CONFIRM_LOADER_EXECUTION  0x271E \r\nName from loader\r\nconfig \r\nConfirmation of execution\r\nload target from particular\r\nconfig \r\nCLIENT_SEND_FILE  0x271F \r\nFile name, response\r\nstring, build id,\r\ncompressed file (zip) \r\nExfiltrated files in archive\r\nwith name representing\r\ngeolocation and IP address \r\nCLIENT_INIT  0x2720 \r\n(OPTIONAL) text\r\nstring \r\nClient Hello, optional\r\nauthentication in format\r\n“{HWID}|{response\r\nstring}” \r\nSERVER_SEND_IP  0x2721  IP string \r\nUsed by server to send\r\nclient’s public IP \r\nCLIENT_SEND_UNKNOWN  0x2722    Mentioned in code, not\r\nused \r\nSERVER_SEND_UNKNOWN  0x2723   \r\nMentioned in code, not\r\nused  \r\nSERVER_SEND_HWID  0x2724  HWID string \r\nUsed by server to send\r\nHWID as step of HVNC\r\nmaintenance \r\nSERVER_SEND_FORCE_QUIT  0x272B   \r\nForce client to call\r\nExitProcess(0) \r\nIt is evident that this is a client-confirmed protocol, as most messages include a CONFIRM response. From the table above\r\nwe can see that the protocol supports functionalities like loading configuration settings, sending files, and more. \r\nExamining various packets reveals that the payload is typically an encrypted UTF-8 encoded string. However, it’s worth\r\nnoting that the payload length can be zero. \r\nMoreover, there are two distinct packet types that deviate from the usual string payload: CLIENT_SEND_FILE and\r\nSERVER_SEND_FILE.  \r\nPacket_type 0x271F (CLIENT_SEND_FILE) has this payload structure, represented here:\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 3 of 20\n\npacket_type 0x271F (CLIENT_SEND_FILE)\r\nAnd here’s representation of packet_type 0x2715 (SERVER_SEND_FILE):\r\npacket_type 0x2715 (SERVER_SEND_FILE) \r\nAs you can see from the images above, these packets contain substructures in place of strings to handle file data.\r\nPacket order \r\nHaving established the packet structure, we can now observe the typical sequence in which they arrive. If we were to\r\nillustrate the entire communication sequence in a flowchart, it would be represented as follows:\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 4 of 20\n\nCommunication flow of RisePro illustrated in a flow chart \r\nThe communication protocol with the Command and Control (C2) server is broken down into three main stages: \r\nInitialization: This is the first step where the client establishes a connection with the server and initializes the\r\ncommunication session. \r\nGetting the configuration: In this stage, the client retrieves configuration details from the server, which may include\r\ncommands, operational parameters, or target information. \r\nPerforming stealer and loader functions: Here, the client executes its intended malicious activities such as stealing\r\ndata (stealer function) and confirming receipt of payloads (loader function).\r\nThere’s also an optional 4th Stage – HVNC launch: it involves the initiation of Hidden Virtual Network Computing\r\n(HVNC), allowing for remote control without detection.\r\nLet’s delve into each stage one by one for a detailed understanding. \r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 5 of 20\n\nStage 1: Initialization \r\nThe default initialization flow for the communication with the C2 server is as follows, with the dotted line indicating an\r\noptional packet:\r\nInitialization flow\r\n1. Communication begins with a SERVER_INIT packet following the establishment of the connection. \r\n2. The client may send a CLIENT_INIT packet right after connecting, before the server sends its packet. If the client\r\ninitiates with CLIENT_INIT, the server responds with a SERVER_PING by default. \r\n3. The SERVER_INIT packet includes a session token, which is used to uniquely identify the session. \r\n4. Subsequently, the server sends the public IP address of the victim to the client. \r\n5. The client acknowledges the IP address by sending back a confirmation along with an additional string in its\r\nresponse. \r\nWith these steps, the connection initialization between the client and the server is completed. \r\nStage 2: Getting the configuration \r\nThe configuration stage involves the server sending configurations in a particular order, and the client sending back\r\nconfirmations with additional payload.\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 6 of 20\n\nGetting the configuration\r\nThe server sends the marks_config, grab_config, and loader_config in a strict sequence to set the malware’s behavior.\r\nHaving received the configurations, we can now examine what they entail. \r\nA deeper look at the config \r\nThe first thing that comes from the server is marks config, shown below:\r\nScreenshot of the marks_config\r\nThe configuration we’re looking at likely dictates how the domain-related data, as presented, will be color-highlighted. This\r\nseems to correspond to the color coding of data within the admin panel. It’s an unusual feature — the purpose of which is\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 7 of 20\n\nnot completely clear for the client. \r\nMoving on, the server always sends a grab_config, which is illustrated in the screenshot below:\r\nScreenshot of the grab_config \r\nThe grab_config specifies the data collection scope, the destination for the collected information, and the functions the\r\nmalware will utilize. \r\nFor instance, it enables the malware to configure a proxy server on the victim’s computer, initiate HVNC, and transmit data\r\nto Telegram (with tg_ids specifying the recipients of the message and tg_token being the bot token within Telegram).\r\nAdditionally, the malware is capable of capturing a screenshot at the time of execution (grab_screen) and exfiltrating data\r\nfrom applications like Telegram and Discord. \r\nFollowing this, we have the loader_config, as seen below: \r\nScreenshot of the loader_config\r\nHere are some noteworthy details from the configuration: \r\nld_geo: This setting likely activates a geographical filter. If set, it probably checks for a specific country code,\r\nallowing the loader to execute only if there’s a match. \r\nld_marks: These are additional conditions that determine when the loader should be activated. \r\nld_name: This is the identifier for the specific configuration. \r\nld_url: This specifies the source URL from which the payload will be downloaded. \r\nThis configuration structure differs in new and old samples of this malware. It is noteworthy, that when the server is\r\nupdated, older versions of the malware, such as earlier iterations of RisePro, will continue to function. However, they might\r\nignore some of the new data or configuration values introduced in the updates. \r\nStage 3: Performing stealer and loader functions \r\nAt this stage in the process, the server issues a command specifying the data to be collected, and in response, the client\r\ncompiles and sends back a .zip archive containing all the stolen data.\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 8 of 20\n\nNetwork communication for performing stealer and loader functions\r\nThe server essentially sets the type of data to be collected.\r\nSetting exfiltration scope and stealing data  \r\nHere’s an example of the rules for data exfiltration:\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 9 of 20\n\nAn example of data exfiltration rules \r\nHere are some key aspects to note in these rules: \r\nrule_collect_recursv: This indicates that the malware will search through folders recursively, delving into subfolders\r\nto locate files. \r\nrule_exceptions: This defines specific locations or files that the malware should avoid. \r\nrule_files: This is a pattern or set of file extensions that the malware targets for theft. \r\nrule_folder: This specifies the path from which files, as defined by the environment configurations, will be\r\nextracted. \r\nrule_name: This is the internal identifier for the rule. There can be multiple such rules, as observed.  \r\nrule_size_kb: This likely sets a maximum file size limit. Files larger than this specified value will not be collected. \r\nExfiltrated data \r\nUpon receiving the configuration, the client steals specific data and sends it back in a zip archive. In our case, the contents\r\nof this archive were as displayed on the screenshot below:\r\nContents of the archive containing exfiltrated data \r\nPackets that transmit this data have a set structure, which we can express as follows:\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 10 of 20\n\nStructure of packets that transmit data\r\nThe structure of the packet for sending stolen data includes the country code, followed by an underscore (_), then the IP\r\naddress, and finally the .zip extension. For instance, “DE_127.0.0.1.zip“. \r\nAn additional name, formatted as described, accompanies the archive. This includes the response code and the build\r\nidentifier, which specify which client is to process or merge the data.\r\nThis stage involves actions that are contingent on the specified configuration, like loader functions. \r\nPerforming loader functions is optional \r\nIf a loader config is provided, the client will download a file and execute it using scheduled tasks (schtasks). This indicates\r\nthat the malware has loader functions. \r\nFurther details are encompassed in the “CLIENT_CONFIRM_LOADER_EXECUTION” packet. Following the\r\nexecution, the client sends a confirmation back to the server, including the value of “ld_name.” Above is an example\r\nillustrating how the client communicates with the server to download additional malicious code and the corresponding\r\nserver response.\r\nReferring to the flowchart above, the first packet contains the number 9. This corresponds to LD-name, which is the\r\nidentifier for the first loader configuration. \r\nStage 4: Optional HVNC launch \r\nThis new version of RisePro also possesses remote control capabilities, which means it can now function as a Remote\r\nAccess Trojan. The ability to enable HVNC is included in the grab_config, as shown in the screenshot provided. \r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 11 of 20\n\nUse of HVNC is set to true in the grab_config\r\nIf HVNC is enabled, RisePro initiates another instance of itself, specifically to download a DLL and run a server for the\r\nremote control functionality. \r\nMultiple TCP streams as seen in ANY.RUN\r\nThe screenshot above reveals an interesting aspect of the malware’s operation: communication occurs across multiple TCP\r\nstreams. \r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 12 of 20\n\nNetwork communication involved in HVNC \r\nFirst connection (process 2600): This includes all the previously discussed stages, such as initialization,\r\nconfiguration, and data exfiltration. \r\nTwo connections from process 2612: These represent two distinct activities:\r\nThe first connection is for receiving a DLL module.\r\nThe second connection is for maintaining an HVNC server, which facilitates remote connections. \r\nStage 4.1: Requesting HVNC module \r\nTo understand how the HVNC connection is established, let’s examine the process as it occurs in the second TCP stream.\r\nThis will provide insights into the steps and communications involved in initiating an HVNC connection. Using a flowchart,\r\nthe process can be described as follows: \r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 13 of 20\n\nInitial stage of HVNC launch\r\nLet’s explain what actually takes place step-by-step:  \r\nClient’s file request: The client sends a request for a DLL file, including a string that specifies the file name. \r\nServer’s response and file transmission: The server acknowledges the request, sends a token for the session, and\r\nthen transmits the requested file.\r\nHaving established the sequence, let’s examine the structure of these packets in pseudocode:\r\nPacket structure in the HVNC communication sequence \r\nStage 4.2: Third connection  \r\nIn the third connection, if the server initiates the communication, the process generally unfolds as follows:\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 14 of 20\n\nData transmission during the second stage of HVNC launch and maintaining conneciton\r\nDuring the third connection, the communication involving HVNC is characterized by two main stages: \r\n1. Data transmission from server: Initially, the server sends specific data related to the HVNC operation. \r\n2. Cyclic pinging: Subsequently, to maintain the connection, the server periodically sends ping messages to the client. \r\n \r\nUnfortunately, we weren’t able to analyze the packet structure when someone connects to the victim using this system, so\r\nwe can’t provide specific details about that aspect of the communication process. \r\nData exfiltration \r\nHaving explored network communication patterns of RisePro, we can move on to examine the contents of the files sent by\r\nthe malware. This will help us understand what data the malware is designed to collect and transmit. \r\nWe’ll examine a file called information.txt first, shown below:\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 15 of 20\n\nInformation.txt file\r\nThis file contains various details. Here are some of the higlights: \r\nMalware version: Specifies the version of the malware. \r\nLaunch date: The date when the malware was activated. \r\nGUID: Likely used to uniquely identify the computer. \r\nHardware ID: A unique identifier for the hardware of the infected system. \r\nLaunch path: The file path from where the malware was executed. \r\nTemporary data storage folder: A folder created by the malware to temporarily store stolen data. \r\nVictim’s computer data: Information like IP address, locale, system details, and other typical computer\r\nspecifications. \r\nHardware information: Details about the video card, processor, RAM, etc. \r\nRunning processes: Names and IDs of system processes, likely used to check if any antivirus software is active. \r\nRegistered software: Lists software registered in the machine’s registry. \r\nIn addition, the malware sends out stolen passwords in a separate file named passwords.txt. It is formatted rather\r\nelaborately: \r\npasswords.txt file\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 16 of 20\n\nImmediately noticeable is a conspicuous link to a Telegram support group associated with the malware’s operation, likely\r\nprovided for further assistance or instructions. The file also lists passwords that have been extracted from databases of\r\nbrowsers, email clients, and other software. \r\nFor each set of credentials, the following details are included: \r\n1. URL of the Site: The web address for which the credentials are used. \r\n2. Login: The username or login ID. \r\n3. Password: The corresponding password. \r\nWrapping up: a look at the known versions \r\nThere are numerous versions of RisePro, and we have only analyzed one specific variant. Consequently, the details may\r\nvary across different versions. \r\nAs of November 22, 2023, the current version is labeled as 1.0. It appears that the versioning was reset to the beginning\r\nwhen the communication protocol underwent significant changes.  \r\nAdditionally, it is noted on the malware’s Telegram support channel that there are two main versions of this stealer: one\r\nwritten in C# and another in C++. The C++ version of the stealer is usually protected with VMProtect and is obfuscated to\r\nevade detection and analysis. \r\nC++ version of the stealer is usually protected with VMProtect \r\nThis C# malware is obfuscated, potentially using Confuser.Core. You can see the C# version of RisePro in this sample.\r\nC# version of RisePro is obfuscated, potentially using Confuser.Core\r\nС++ version of RisePro can inject into processes. This behavior is evident in this task. \r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 17 of 20\n\nInjection behaviour\r\nAs usual, we’ll leave you with some essential resources for detecting this malware and IOCs we’ve collected during our\r\nresearch:\r\nIOCs \r\nRisePro v0.9, C++ build, HVNC\r\nSample: https://app.any.run/tasks/01a74cc5-b571-4879-9104-e3f2383ba391/ \r\nSHA256: e95d8c7cf98dc1ed3ec0528b05df7c79bae2421ba2ad2b671d54d8088238f205 \r\nFiles:\r\nC:\\Users\\admin\\AppData\\Local\\MaxLoonaFest1\\MaxLoonaFest1.exe  e95d8c7cf98dc1ed3ec0528b05df7c79bae2421ba2ad2b671d54d808823\r\nIP: 194[.]169.175.128\r\nURL: http://91[.]92.245.23/download/k/KL.exe \r\nRisePro v0.7, C++ build, loader\r\nSample: https://app.any.run/tasks/992ee8b9-b53a-489f-a97a-49798b125183/ \r\nSHA256: 973867150fd46e2de4b3d375d9c2d59eeda808a9dd1d137bd020b2f15c155ede \r\nFiles:\r\nC:\\Users\\admin\\AppData\\Local\\Microsoft\\Windows\\Temporary\r\nInternet Files\\Content.IE5\\K78MRVB5\\KL[1].exe \r\nf327c2b5ab1d98f0382a35cd78f694d487c74a7290f1ff7be53f42e23021e599 \r\nIP: 194[.]169.175.123 \r\nURL: http://91[.]92.245.23/download/k/KL.exe \r\nRisePro v0.6, C# build\r\nSample: https://app.any.run/tasks/88f133ad-338b-43bb-a2fd-e093616219d5 \r\nSHA256: ba7f4474a334d79dd16cfb8a082987000764ff24c8a882c696e4c214b0e5e9cf \r\nFiles:\r\nC:\\Users\\admin\\AppData\\Local\\Temp\\tempAVS1DYR2zldnwaG\\sqlite3.dll  0c7cd52abdb6eb3e556d81caac398a127495e4a251ef600e6505a81\r\nIP: 194[.]169.175.128 \r\nRisePro v0.9, C++ build, C# injector\r\nSample: https://app.any.run/tasks/d34ad531-7b30-46cb-922a-718e4bd6a9d8/ \r\nSHA256: D440EEB8FD204EF2B3845894FE4E256E6505796B75FE5201CFFA7F5453C2FB5F\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 18 of 20\n\nFiles:\r\nC:\\Users\\admin\\AppData\\Local\\LegalHelper130\\LegalHelper130.exe  D440EEB8FD204EF2B3845894FE4E256E6505796B75FE5201CFFA7\r\nIP: 194[.]49.94.53\r\nRisePro botnet version, communication over TCP:50505\r\nSample: https://app.any.run/tasks/f841e850-d97a-4395-93cb-c2dff7e7bf7e/ \r\nSHA256: 4435DA81D8BC840408AFED9E993B3F0CC1AA08FF1CD03BBEC609379517EC1379 \r\nFiles:\r\nC:\\ProgramData\\WinTrackerSP\\WinTrackerSP.exe  7F17D3D47F053498A3EFECAB532932DCC8018E3EE0DA60FB090BE\r\nC:\\Users\\admin\\AppData\\Local\\Temp\\tmpSTLpopstart\\stlmapfrog  (encrypted json, contains start timestamp and IP) \r\nC:\\Users\\admin\\AppData\\Local\\Temp\\tmpSTLpopstart\\todelete  (json with file paths) \r\nIP: 194[.]169.175.128\r\nSIGMA\r\ntitle: RisePro Rule\r\nid: aba15bdd-657f-422a-bab3-ac2d2a0d6f1c\r\nstatus: experimental\r\ndescription: Detects RisePro malware\r\nauthor: ANY.RUN\r\ndate: 2023/11/17\r\ntags:\r\n - windows\r\n - RisePro\r\nlogsource:\r\n category: file_event\r\n product: windows\r\ndetection:\r\n selection:\r\n TargetFilename|regex:\r\n - \"(?i)\\\\\\\\AppData\\\\\\\\Local\\\\\\\\Temp\\\\\\\\.*\\\\\\\\passwords\\\\.txt$\"\r\n - \"(?i)\\\\\\\\AppData\\\\\\\\Local\\\\\\\\Temp\\\\\\\\.*\\\\\\\\information\\\\.txt$\"\r\n condition: selection\r\nlevel: medium\r\nYARA\r\nWe’ve created a YARA rule to detect these updated versions of RisePro. You can find it in our GitHub.\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 19 of 20\n\nTCP stream decoder (python script) \r\nFor further investigation, we’ve prepared for you a script, that can be used to decrypt and parse the TCP stream to a JSON\r\nfile. This allows for easier visualization and processing of RisePro communication. The script can be found in our GitHub \r\nSURICATA Rule structure \r\nAfter detecting RisePro traffic in our sandbox environment, we shared our insights on network rule configurations with the\r\nEmergency Threats community. You can view the thread discussing these network rules with the ET community here.  \r\nThe Suricata rules are defined by multiple conditions:\r\nConditions in the rule  Value  Description \r\ntcp $HOME_NET any -\u003e $EXTERNAL_NET !\r\n[80,443,445,5938]\r\ntcp  TCP protocol \r\n$EXTERNAL_NET  Direction to external network \r\n![80,443,445,5938]  Unused port exceptions \r\ndsize:\u003e1100;  1100  TCP packet payload size \r\ncontent:\"|00 1F 27 00 00|\"; offset:7; depth:5\r\n00  \r\nLimit uploaded file length values to\r\nthree bytes \r\n1F 27 00 00;   Packet type CLIENT_SEND_FILE \r\nSuricata IDS rules for detecting RisePro are available at Emerging Threats — Suricata Rules. Relevant rule IDs include\r\n2046267, 2046269, 2046268, 2046266, 2046270, and 2049060.\r\nSource: https://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nhttps://any.run/cybersecurity-blog/risepro-malware-communication-analysis/\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://any.run/cybersecurity-blog/risepro-malware-communication-analysis/"
	],
	"report_names": [
		"risepro-malware-communication-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775434356,
	"ts_updated_at": 1775791255,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/65e11ffbe3868bcbd2f0ca35186905b80fe91846.pdf",
		"text": "https://archive.orkl.eu/65e11ffbe3868bcbd2f0ca35186905b80fe91846.txt",
		"img": "https://archive.orkl.eu/65e11ffbe3868bcbd2f0ca35186905b80fe91846.jpg"
	}
}