How Risen Ransomware Works: An IDA Pro Deep Dive

Ransomware remains one of the most disruptive and costly threats in the digital landscape. For cybersecurity analysts, understanding how these malicious programs operate is key to building better defenses. Recently, as part of a malware analysis challenge on the LetsDefend platform, I got my hands on a sample of the Risen ransomware.

In this deep dive, we’ll use IDA Pro to peel back the layers of this sample, piece by piece. We’ll follow its execution flow from the moment it runs to its final, destructive payload, transforming technical disassembly into a clear story of how it attacks a system.

Part I: Securing the Beachhead: Initial Execution and Evasion

Like many well-designed pieces of malware, Risen’s first actions are all about survival and ensuring it can operate without interference.

First, it creates a mutex named RISEN_MUTEX. A mutex (short for “mutual exclusion”) acts as a flag to ensure that only one instance of the program can run on a system at any given time. This prevents multiple instances from trying to encrypt the same files, which could corrupt them or create unnecessary noise that might trigger security alerts.

Figure 1: Risen creating the RISEN_MUTEX to ensure singleton execution.

Next, it performs a clever act of self-preservation: geo-fencing. The malware calls the GetSystemDefaultUILanguage API to check the computer’s default language. It then compares the result against a hardcoded list of five language codes. If the system’s language matches one on its “do not attack” list, the ransomware terminates immediately. This is a common tactic used by threat actors to avoid attacking systems in their own country or allied nations, reducing their risk of attracting local law enforcement.

Figure 2: calling the GetSystemDefaultUILanguage API

During this setup, it also creates a log file named Risenlogs.txt, likely a remnant from its development phase for debugging purposes.

Figure 3: Creating the Risenlogs.txt file

Part II: Staying Power: Persistence and Discovery

Once Risen has confirmed it’s in a targetable environment, its next priority is to ensure it can survive a system reboot.

To achieve this, it establishes persistence by creating a scheduled task. Using the Windows schtasks.exe command-line utility, it sets up a task named SystemDefense. The name is deliberately chosen to sound like a legitimate system process, allowing it to blend in and evade casual inspection by a user or administrator. This task ensures the ransomware will automatically run again if the system is restarted before encryption is complete.

Figure 4: All instances of SCHTASKS

Figure 5: Scheduled task being setup

With persistence secured, the malware begins to “case the joint.” It needs to find what to encrypt. It does this by enumerating the system’s drives, calling the GetDriveTypeW API to identify which volumes are local hard drives (like C: or D:). This discovery phase is guided by an internal array located at off_44CB08, ensuring it focuses on high-value local files and avoids potentially problematic network or removable drives.

Figure 6: Risen enumerating drives to identify encryption targets

Part III: The Payload: Encryption and Extortion

This is the main event. After identifying the target drives, Risen begins its primary mission: encrypting the victim’s files. It recursively scans the directories and uses a cryptographic algorithm to lock away data, making it completely inaccessible.

After this digital devastation is complete, it needs to tell the victim what happened and how to pay. We found a hardcoded string containing the threat actor’s contact information: the Telegram username @tokyosupp. This serves as the communication channel for the victim to negotiate payment and — if they’re lucky — receive a decryption key. Unlike more sophisticated operations that use Tor hidden services, this reliance on a public platform suggests a less-resourced but still highly dangerous threat actor.

Figure 7: The hardcoded Telegram username for ransom negotiations.

The Blueprint: Mapping Risen’s Behavior to MITRE ATT&CK®

MITRE ATT&CK Mapping

To put our findings into a strategic context, we can map Risen’s techniques to the MITRE ATT&CK® framework. This helps us understand not just what the malware does, but how its actions fit into a recognized attack lifecycle.

• Execution Guardrails (T1480.001): The geo-fencing check based on system language is a classic example of environmental keying.
• Scheduled Task/Job (T1053.005): The creation of the SystemDefense task is its method for both Persistence and Execution.
• File and Directory Discovery (T1083): It uses GetDriveTypeW to discover local drives to target for encryption.
• Data Encrypted for Impact (T1486): This is the primary objective and impact of the ransomware.
• Web Service (T1102): It uses a public-facing service (Telegram) as a Command and Control channel for communication with the victim.

For the Defenders: Indicators of Compromise (IoCs)

This analysis yields several high-fidelity indicators that security teams can use for threat hunting and detection. If you see these on your network, you may be dealing with Risen.

Final Thoughts

This exercise on the LetsDefend platform was a fantastic opportunity to dissect a real-world style of threat in a safe environment. The Risen ransomware, while not the most complex variant in circulation, is a textbook example of an effective and destructive tool. Its straightforward approach — evade, persist, discover, and encrypt — serves as a powerful reminder that even less advanced threats can cause significant damage.

By breaking down its behavior, we not only understand this specific threat better but also reinforce the fundamental analysis techniques that are crucial for defending against the next one.