Ransom32 is a new ransomware implemented in a very atypical style. Emisoft provides a good description of its functionality here. In our post, we will focus on some implementation details of the malicious package.
Analyzed sample: 09f21eefaf8f52496d4e8b06920fe6fa
Overview
Ransom32 is delivered as an executable, that is in reality a autoextracting WinRAR archive. By default it is distributed as a file with .scr extension:
The WinRAR script is used to drop files in the specified place and autorun the unpacked content.
- Setup=chrome i – Setup value specifies the executable that is going to be run after file extraction. In this case it is chrome.exe
- TempMode means files are going to be dropped in the %TEMP% folder
- Silent=1 means installation will be done without additional pop-ups about the progress
Installation directory created in %TEMP%:
The unpacked content consist of following files:
chrome.exe spoofs Google’s browser, but in reality it is an element responsible for preparing and running the Node JS application (that is the main part of the ransomware).
After the chrome.exe is run from the %TEMP% folder, it installs the above files into %APPDATA% -in folder Chrome Browser:
Files stored in the folder Chrome Browser are just the environment to run the real malware.
Although the package as a whole is eclectic and contains various files belonging to various technologies, the core responsible for malicious actions consists of JavaScript files (NodeJS package). They are unpacked again into %TEMP% – in a new folder (its name follows the pattern: nw[number]_[number]). Let’s take a look…
Scripts
Content of the malicious NodeJS package:
The file package.json is a manifest, that defines a startup configuration and dependencies. [code language=”css”]{ “name”: “app”, “version”: “1.0.0”, “description”: “”, “main”: “index.html”, “single-instance”: false, “scripts”: { “test”: “echo “Error: no test specified” && exit 1″ }, “chromium-args”: “–disable-accelerated-video”, “author”: “”, “window”: { “frame”: false, “resizable”: false, “visible-on-all-workspaces”: true, “show_in_taskbar”: true, “toolbar”: false, “width”: 800, “height”: 500, “show”: false, “title”: “Ransom32”, “icon”: “icon.png” }, “license”: “ISC”, “dependencies”: { “minimatch”: “^2.0.10”, “ncp”: “^2.0.0”, “node-rsa”: “^0.2.26”, “socksv5”: “^0.0.6” } } [/code] Entry point of the package is defined to be in index.html, that looks as below:
The heart of the ransomware is inside binary.bin – a JavaScript compiled to a native code and loaded using function evalNWBin. All other components are called from inside of this binary.
It is responsible for encrypting and decrypting files, as well as for displaying ransom note and guiding a victim. Compiling the javascript to a native code has been used as a form of protection. However, strings of binary.bin can tell us a lot about the functionality of this application.
We can find for example:
- attacked extensions
- names of functions deployed by the binary
- names of other binaries deployed from inside
- configuration of AES used to encrypt files: CTR (Integer Counter Mode) with 128 bit key
- CSS used to format the ransom information window
- the ransom note.
- instructions how to buy bitcoins
- the message displayed if the payment was received
- 3 base64 encoded elements – a png, a gif and an ogg (audio).
After encrypting the files, the ransom nag-window is displayed. The gui is generated by javascript, with the layout defined by the included CSS.
The internet connection is operated via included Tor client – renamed to rundll32.exe
The tor client spawned by chrome.exe:
When we click a button “Check payment” a request is sent via Tor client, in order to verify if the payment has been received:
Users who don’t know how to use bitcoins are provided with extensive list of helpful links, available after clicking the button “How to buy Bitcoins”:
Other used elements are in the folder node_modules (written in NodeJS):
It uses open source components:
- minimatch: https://github.com/isaacs/minimatch
Conclusion
In the past, malware authors cared mostly about small size of their applications – that’s why early viruses were written in assembler. Nowadays, technologies used and goals have changed. The most important consideration is not the size, but the ability to imitate legitimate applications, for the purpose of avoiding detection.
Authors of Ransom32 went really far in this direction. Their package is huge in comparison to typical samples. It consists of various elements, including legitimate applications – i.e the tor client (renamed to rundll32.exe). The technology that they have chosen for the core – Node JS – is a complete change of direction from the malware written in low-level languages.
However, compiled Java Script (although it works about 30 percent slower than not compiled) is not very popular and there is lack of tools to analyze it – which makes it a good point for malware authors, who gain some level of code protection.
Appendix
Other posts about Ransom32:
See also our posts about other examples of ransomware: