RansomHub Ransomware Detection Guide
Behavioral Indicators
RansomHub exhibits several distinct runtime behaviors. Monitor process creation for suspicious chains, particularly where a parent process like cmd.exe, powershell.exe, or wscript.exe spawns a binary that immediately begins high-volume file system activity. The ransomware process will typically attempt to delete Volume Shadow Copies (VSS) to hinder recovery. This is done via commands like vssadmin delete shadows /all /quiet or wbadmin delete catalog -quiet. Look for the creation of vssadmin.exe or wbadmin.exe as child processes of the initial malware binary.
The malware performs aggressive credential access. It uses Windows API calls to enumerate and access network shares, often impersonating logged-on users. Monitor for processes making unusual calls to NetShareEnum, WNetOpenEnum, and CredEnumerate. RansomHub also attempts to harvest credentials from the Local Security Authority Subsystem Service (LSASS) memory. Look for process handle requests to lsass.exe from a non-standard process, which may indicate an attempt to dump credentials for lateral movement.
A key behavioral signature is the systematic encryption routine. The process will open numerous files in rapid succession, read their contents, write new encrypted data (often appending a specific extension), and delete the original. This generates a distinct pattern of high read/write disk I/O from a single process. The malware also typically terminates or interferes with database services, backup software processes, and security tools to prevent interference with encryption.
Network Indicators
RansomHub communicates with its command-and-control (C2) infrastructure to receive encryption keys, configuration, and to exfiltrate stolen data prior to encryption. C2 communication often occurs over HTTPS to blend with normal traffic. Look for HTTPS POST requests from infected hosts to newly registered or suspicious domains that do not align with corporate web services. The payload is typically encrypted or obfuscated within the HTTP body.
Beaconing intervals can vary but often follow a low-and-slow pattern post-infection, with periodic check-ins. Prior to the encryption trigger, there may be a surge in traffic correlating with data exfiltration. This exfiltration often uses protocols like HTTP/S, FTP, or SCP to transfer compressed archives (e.g., .zip, .rar) to external IP addresses or domains. DNS queries may reveal calls to algorithmically generated domain names (DGA) or domains with recent creation dates that are not in your organization’s normal whitelist.
Monitor for SMB traffic spikes from a single host targeting multiple network shares, which is indicative of the ransomware’s network enumeration and encryption phase. Connections to standard remote administration tool ports (e.g., 3389 for RDP, 5985/5986 for WinRM) from the infected host may also signal lateral movement attempts using stolen credentials.
File System Artifacts
The primary artifact is the ransom note, typically named README.txt, RECOVER-FILES.txt, or HOW_TO_DECRYPT.html. These are placed in every encrypted directory. The note contains instructions for contacting the threat actors, often via a Tor payment site.
Encrypted files receive a new extension appended by RansomHub. This extension has varied across campaigns but often includes the victim’s unique ID or the string “ransomhub,” such as .ransomhub, .rhub, or .[id].rhub. The original file is usually deleted after encryption.
The malware binary itself is often dropped in temporary directories (%TEMP%, %APPDATA%, or C:\Windows\Temp\) with a seemingly benign name like update.exe, setup.exe, or a string of random characters. Look for recently created executable files in these locations, especially those with low prevalence or signed with invalid certificates. RansomHub may also drop and execute legitimate but vulnerable driver files (e.g., WinRing0x64.sys) to gain kernel-level privileges for disabling security software.
Log files or configuration files may be created in %APPDATA% or %LOCALAPPDATA% under folders named after the malware or containing the victim ID. These can contain encryption keys, victim information, or lists of targeted files.
Registry and Persistence Mechanisms
RansomHub often uses run keys for persistence, ensuring execution after reboot. Common registry paths to investigate include:
HKCU\Software\Microsoft\Windows\CurrentVersion\RunHKLM\Software\Microsoft\Windows\CurrentVersion\RunHKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
Check these keys for entries pointing to the dropped executable in a temp or appdata path.
Scheduled tasks are another frequent persistence mechanism. Look for newly created tasks with names that mimic system tasks (e.g., “SystemUpdateCheck”, “AdobeFlashPlayerUpdate”) but which execute a payload from a user writable location. Use your endpoint detection tool to audit scheduled task creation and examine the Actions for suspicious command lines.
The malware may create or modify Windows Services for persistence, particularly if it gains administrative privileges. Inspect recently created services (especially those with SERVICE_AUTO_START) where the ImagePath points to a non-standard location. It may also use fileless persistence techniques, such as injecting malicious code into a benign, trusted process and writing a registry key to maintain the injection.
Registry keys may also be used for operational purposes, such as storing the victim identifier, encryption status, or configuration. Check for unusual keys or values under paths like HKCU\Software\ or HKLM\Software\ that contain random-looking strings or the “ransomhub” name.
YARA Rule Guidance
When developing YARA rules for RansomHub, focus on both broad and specific characteristics. Target unique strings found in ransom notes, such as specific phrases like “RansomHub”, “Your files are encrypted”, “to recover your data”, and the Tor payment URL format (.onion). Also, look for the specific file extensions used in recent campaigns, which can be embedded as strings within the binary.
Analyze the binary’s import address table (IAT). RansomHub samples consistently import APIs critical for its function: CryptEncrypt and CryptDecrypt from ADVAPI32.dll for cryptography; FindFirstFileW and FindNextFileW from KERNEL32.dll for file enumeration; DeleteFileW for removing originals; and NetShareEnum from NETAPI32.dll for network propagation.
Examine the code section for byte sequences related to its specific encryption algorithm (often a combination of RSA and AES) and the routines for deleting shadow copies. Look for the command strings used for vssadmin and wbadmin. The malware often contains error messages or debug strings that can be distinctive, even if obfuscated.
Since RansomHub operators may repack or slightly modify binaries, combine string-based detection with structural logic. Use conditions that check for the presence of multiple indicative strings, a high entropy level (indicative of packing or encryption), and a section count typical of packed executables. Prioritize writing rules that target the unpacked code in memory during runtime detection, as this is more consistent than the packed on-disk form.
For the latest samples, file hashes, and specific indicators of compromise, please refer to the dedicated resource pages: