Thursday, January 25, 2018

Quick Overview of new Ransomware Rapid

Yesterday I received a call about a system being infected with some kind of ransomware. I got told that files were encrypted with the file extension .rapid. A quick google search revealed a post about this kind of ransomware from 2 days ago

As the caller was unable to provide me with a sample at this time, I googled (rapid ransomware twitter) for rapid ransomware samples and found this tweet which contained Virustotal URLs to samples. And also a link to some russian blogpost .

A few minutes later I got a second call and told the customer to check the %APPDATA% folder for a file called "info.exe", with success. They provided me with this sample ( which I decided to take a look at. As time was of the essence I only had about an hour to check the capabilities of the ransomware and wanted to share my approach.

Step 1 - Running the sample

As usual I checked hybrid-analysis for the given sample which provided me with some basic information about the sample, especially about deleting shadow copies and terminating common database processes. I ran the sample and monitored with process monitor and process explorer from Sysinternals. I noticed some basic persistence and the capability to encrypt network drives, nothing unusual.

Step 2 - Basic overview in IDA

I opened the executable in IDA and got presented with an unusual looking WinMain function.

Several subfunctions also were huge and looked like obfuscation code.

I didn't have the time to deal with the obfuscation so I decided to run the sample in x64dbg. I noticed a call to LoadLibrary near the end of the WinMain-function and decided to put a breakpoint on it to see if any suspicious API-functions are loaded at run time. 
The breakpoint was hit 7-times and I noticed shell32.CryptDecrypt and shell32.ShellExecuteA on the stack. As it turned out this step wasn't necessary and one can simply put a hardware breakpoint on shell32.ShellExecuteA. (the malware seems to remove software breakpoints during execution)

I thought about the hybrid-analysis results containing "cmd.exe ..." to kill known database processes. As ransomware usually persists itself before starting to encrypt files. I had two options, either break on the resulting registry functions or trying to break on shell32.ShellExecuteA.

I put a breakpoint and continued to run the sample. On hit I followed the return value on the stack and found multiple plaintext strings. So I decided to dump the process and load it in IDA.

Step 3 - Unpacked binary in IDA

Opening the sort of unpacked binary I immediately checked the strings and found a couple of interesting ones. Which also indicate that the malware persists itself to Software\\Microsoft\\Windows\\CurrentVersion\\Run and kills oracle.exe, sqlite.exe and sql.exe. One can also see the hardcoded info.exe name, which will be the name of the persisted file as we will see later on.

I followed the ShellExecuteA return value from my debugging session and found the main ransomware function which is quite small and similar to other ransomware like crysis.

There are 6 calls to ShellExecute in total:
  1. Delete shadow copies (requires admin rights)
  2. This command disables booting in safe mode if I remember correctly (requires admin rights)
  3. Seems to be required to run 2. on enterprise version (requires admin rights) (
  4. Kill oracle
  5. Kill sqlite
  6. Kill sql
Afterwards %APPDATA% is resolved and the file itself is copied to %APPDATA% as info.exe and persisted. The malware also creates a file called recovery.txt which will also be run on reboot.

The function init_crypto writes new generated keys to HKEY_CURRENT_USER\Software\EncryptKets

The local_public_key is hardcoded in it's base64encoded form into the binary (BgIAAACkAABSU0ExAAgAAAEAAQB5HZZSge6GEPqkQTwzzugIrH3nOJHkLUsbUfm3m2bbJrLyNSM2FOQKxEMix1agNja0IgBmzzueh6nsn4ALDCD/fCwQAotsEDfnYpQDz9dKoHmMPMGCuXESkdMEiVm83PyAnJh4f4Zcq6Y1ONNmuMTfS6kTP0JUlqhM3VHWiafi+eaTL01x2kOeSupagrho+IqG6FH8Bl0weQXYpFjbxgpV3ldkKB4lf66rHFFfk93vOQhLvl2rDCg/fAMGFBIF5debBtCSi+t19biR+ze5Zau9/wd6+3Ec8DXRdpTjK7n8Q3hQouTONlY9RgjpHxLoPxsrWnyxPc6F/AUxKXkWeLW/) (also noted here:

The following screenshot shows the init_crypto function.

After initializing the crypto function the ransomware iterates all logical drives (the drives you see in your windows explorer) and determines whether a drive is a network drive or not. Running the sample it seems to prioritize network drives for encryption.

The final calls after the for loop start the multit-hreaded file encryption, display the ransom note (which actually doesn't work, you only see a cmd windows pop up) and sleep 30 seconds until the encryption process is restarted in an infinite loop. Which means if you create new files while the ransomware is active they will be encrypted ~ after 30 seconds. If you want to see the ransomware note just reboot the machine.

Detection using Sysinternals-Autoruns

To check if a server/machine is infected by rapid ransomware just run autorunsc.exe from sysinternals in a powershell with admin rights by issuing the following command

.\autorunsc.exe -a * * | grep info.exe (remember to accept the eula first)


The infection in this particular case happened via stolen/weak RDP credentials, the crooks just logged onto the system and started the ransomware with admin rights.
That's it for today.







Ransom Note

Public RSA Key (base64 encoded)


File Hashes

MD5: a5c1a9659108b23aa6564a4e4e2d8e83
SHA-1: 39a87293f440221581f18708befe1860cdd3822c