With low overhead and risk of prosecution, ransomware attacks have outpaced banking Trojans in sheer number of incidents, if not profit. Ransomware’s rapidly growing popularity has spawned dozens of variants, subtypes, and families as threat actors seek to outmaneuver researchers and competitors. In this dynamic threat landscape, alongside monitoring the established ransomware families for any change in tactics, techniques, or procedures, we monitor social media and underground markets for emerging threats. Through this process, our team was alerted to and began an investigation of what is likely a new threat actor’s first attempt at ransomware design and distribution.
Recently we observed a new type of ransomware, called Alma Ransomware, being delivered via exploit kit. Often hidden on web servers, exploit kits (EK) are toolkits used by threat actors that exploit vulnerabilities in visiting users’ web browsers to deliver malicious payloads. Alma Ransomware (MD5 Hash: 92f8a916975363a371354b10070ab3e9) was observed being delivered via the RIG Exploit Kit. The malicious payload tripped only one indicator on VirusTotal at 2016-08-22 14:51:15 UTC:
Figure 1: VirusTotal indicator from day 1 of circulation.
Further investigation reveals the file’s copyright property contains a string, in which the author tries to indicate the malicious binary belongs to Apple. The user is attempting to use a well-known and trusted brand in an effort to gain the user’s trust and prevent them from removing the infection. Upon seeing a notification about the file, the user may ignore it as they may believe it to be a false indication of malicious activity.
Figure 2: Alma Ransomware’s file properties. This is metadata that describes important information about the file, such as its’ purpose.
The executable itself makes use of Address Space Layout Randomization (ASLR) enabled per a flag found in the PE Header. ASLR is a protection mechanism in which the operating system randomizes the memory locations of the program in order to make it less susceptible to buffer overflow attacks. However, to less experienced malware analysts or to those unfamiliar with the concept, it also makes it more difficult to analyze as locations for certain functions will change upon each execution of the payload. This is easily defeated by changing the corresponding value found within the header of the executable.
Figure 3: CFF Explorer showing the ASLR flag set in the executable header.
Inside the File’s Behavior
Upon execution, we observed the payload creating new files with encrypted content with a common pattern including a random multi-character file extension. Files with the following extensions were being targeted:
.1cd, .3ds, .3gp, .accdb, .ai, .ape, .asp, .aspx, .bc6, .bc7, .bmp, .cdr, .cer, .cfg, .cfgx, .cpp, .cr2, .crt, .crw, .csr, .csv, .dbf, .dbx, .dcr, .dfx, .dib, .djvu, .doc, .docm, .docx, .dwg, .dwt, .dxf, .dxg, .eps, .htm, .html, .ibank, .indd, .jfif, .jpe, .jpeg, .jpg, .kdc, .kwm, .max, .md, .mdb, .mdf, .odb, .odc, .odm, .odp, .ods, .odt, .orf, .p12, .p7b, .p7c, .pdf, .pef, .pem, .pfx, .php, .pl, .png, .pps, .ppt, .pptm, .pptx, .psd, .pst, .pub, .pwm, .py, .qbb, .qbw, .raw, .rtf, .sln, .sql, .sqlite, .svg, .tif, .tiff, .txt, .vcf, .wallet, .wpd, .xls, .xlsm, .xlsx, .xml
The ransomware payload begins its process of encrypting the user’s files by calculating a SHA256 hash of a particular string that is generated via each run. The result of which is subsequently used as input to an AES 128-bit encryption key via a large loop executing these API functions: ReadFile, CryptEncrypt, and then WriteFile.
Figure 4: The initial encryption routine shown in IDA Pro.
Payload’s Network Activity
Upon execution, Alma attempts to resolve a .onion address to check-in. This behavior can be observed in Figure 5 where Alma performs an HTTP POST with base64-encoded data about the victim’s machine.
Figure 5 – Alma initial check-in.
When the values being “POST”-ed are decoded, we are able to view what parameters and information about the victim Alma Ransomware is using. The first value p=16n8x93IpeZzXeMbLsHpXNAB is the encryption / decryption key used by Alma Ransomware. This is obviously the most important parameter and demonstrates a major flaw in the design of Alma Ransomware. We have leveraged this flaw to decrypt the victim’s files without paying the ransom. The other parameters identify whether antivirus is present on the victim’s machine, the infected user, the operating system version, the victim’s personal identifier, and the file extension of encrypted files.
Most ransomware payloads perform a check-in process with a command and control center. The payload subsequently encrypts contents with the generated key or key pair shared with the server. The user is then presented with a ransom message indicating the amount needed to be paid before they are able to retrieve their original file contents. Shortly after check-in, Alma will then present a notice to the user informing them their files have been encrypted. A personal identifier is then generated for the user that is used to identify the victim. This identifier is then used in the ransom payment.
Figure 6: Ransom message showing the user’s identifying number and instructions of how to get their data back.
In this two-stage ransomware variant, the decrypter is the second-stage of the infection. The victim now has the option to download the decrypter and view the decryption instructions presented by Alma's author. The following figure displays the decrypter’s metadata via the ‘Exeinfo PE’ tool:
Figure 7 – The decrypter file’s metadata.
Once the decrypter is downloaded and run, it performs a check-in with the command and control server (CNC).
Figure 8 – decrypter check-in and payment identification.
Above in figure 8, the decrypter will POST the victims personal identifier to the server, informing the author that the victim has downloaded the decryption tool. The server will then respond notifying the decrypter of the Bitcoin address, multi-character file extension, hours left to pay the ransom, and the cost of the ransom. The decryption tool then performs a check to identify if the victim has paid the ransom of 1 Bitcoin (at the time of writing this blog, 1 BTC = $589.41). Figure 9 below shows the interface of the decryption tool. Note that the victim is given 120 hours from the time the decryption tool is downloaded, not the time of infection.
Figure 9 – decrypter (Second-Stage) checking for payment before decrypting.
Analyzing Alma’s decrypter
Alma ransomware’s encryption capabilities are significantly weakened by its usage of un-obfuscated .NET code, seen below in figure 11. By utilizing Red Gate’s .NET Reflector we can view the decrypter’s source code and identify the parameters used for decryption. Using these parameters, we are able to craft our own decryption tool.
Figure 10 – Ransom verification code found in the decrypter.
As seen in Figure 11, the encryption process is using AES 128-bit encryption with a key provided by a response from the server:
Figure 11 – Decryption routine found in the decrypter.
Decrypting for free with a Man-in-the-Middle technique
Through our analysis we determined that the decryption tool is vulnerable to a man-in-the-middle (MITM) technique that allows all victims to decrypt their files. Figure 12 below shows a simple text file after Alma Ransomware has performed its encryption.
Figure 12 – Encrypted File Metadata.
Upon opening the file, the victim can verify that Alma Ransomware encrypted the contents, illustrated in below.
Figure 13 – Contents of the encrypted file.
Now we can execute a MITM technique on the decrypter (or write your own) to restore your files. We made use of Fiddler, a popular HTTP proxy developed by Telerik to modify the responses from the command and control server. Before the responses can be modified, you need to enable filtering so that breakpoints can be set on POST requests. Figure 14 shows the parameters that need to be set before the man-in-the-middle attack can be completed.
Figure 14 – Man-in-the-middle Setup using Fiddler as Interceptor.
As displayed in Figure 8, when the decrypter is run, it attempts to check-in with the command and control by issuing a POST request to I.php. The server will then respond with several values (Bitcoin wallet, file extension, hours left to pay, amount to pay). Figure 15 below displays that you can run the POST request and break on the response. Here we are able to supply Fiddler with a .dat file containing parameters we specify. This allows manipulation of any of these values, including amount to pay and time left to pay.
Figure 15 – Interception of traffic from command and control center using Fiddler.
After we have supplied Fiddler with the data file, we can then click “Run to Completion”. The decrypter will then issue a request POSTing the Bitcoin Address to c.php. If the victim has not paid the ransom, the server will respond with nothing. We can craft a data file containing the key generated by the Alma Ransomware payload and break on the response. Figure 16 below exhibits our state at this point.
Figure 16 – Second intercept of traffic from command and control center using Fiddler.
After supplying fiddler with the data file containing the victims key, we are able to pass that on to the decrypter via “Run to Completion”.
Figure 17 – decrypter with intercepted values and decryption enabled.
Figure 17, shows our MITM attack is successful using the values supplied by our data files and Fiddler. We are now granted the ability to decrypt any of our previously encrypted files. We want to decrypt our PlainText.txt file from Figures 12 and 13 and our results are displayed in figure 18 below.
Figure 18 – Decrypted file.
Conclusion
The author’s failure to implement any sort of protection or obfuscation into their payload and decrypter alongside the limited network support infrastructure indicate a threat actor new to malware scripting. Shortly after the payload’s distribution into the wild, the command and control server began responding with a 500 internal server error, leaving victims unable to decrypt their files. The infrastructure surrounding this campaign was not very robust and ultimately resulted in the downfall of Alma Ransomware's first run. Despite the amateurish nature of Alma Ransomware, this author is not likely to cease production and we should expect to see more from them in the near future.
In the future, for anyone who encounters the Alma Ransomware payload, our team has written a decrypter to assist your efforts in retrieving the encrypted file’s contents.
{{cta('22f2fe97-c748-4d6a-9e1e-ba3fb1060abe')}}
MD5 Hashes
Ransomware Payload ( Initial Infector ) – Delivered via RIG Exploit Kit
92f8a916975363a371354b10070ab3e9 [ syncli.exe ]
decrypter ( Second-Stage )
35474c174f8d867625461b437d51126c [ decrypter.exe ]
Indicators of Compromise
Initial Infection Vector
RIG Exploit Kit
109.234.35.106
decrypter
hxxp://jjuwnj2ejjmafg74.torstorm.org/decrypter.exe
hxxp://jjuwnj2ejjmafg74.onion.nu/decrypter.exe
hxxp://jjuwnj2ejjmafg74.onion.cab/decrypter.exe
hxxp://jjuwnj2ejjmafg74.onion.link/decrypter.exe
Decryption Instructions
hxxp://jjuwnj2ejjmafg74.torstorm.org
hxxp://jjuwnj2ejjmafg74.onion.nu
hxxp://jjuwnj2ejjmafg74.onion.cab
hxxp://jjuwnj2ejjmafg74.onion.link
hxxp://jjuwnj2ejjmafg74.onion.to
Command and Control
Initial Check-In
hxxp://jjuwnj2ejjmafg74.onion.link/n.php
decrypter Check-In
hxxp://jjuwnj2ejjmafg74.onion.link/i.php
hxxp://jjuwnj2ejjmafg74.onion.link/c.php