Analyzing Ruby malware

Oct 09th 2015

Using Ruby interpreter to evade analysis and backdoor the target machine

Malware running Ruby scripts against an interpreter may not be mainstream, but there’s certainly a long lineage, dating back almost a decade to the Metasploit framework being written in Ruby.  We see a trend now though of using high level languages regardless of the disadvantages (like needing the interpreter to run on the target) in order to evade analysis as we showed with COM malware in our recent post. We recently ran a sample (MD5 b727b40999396587cf41dcb0e0a65ec0 / SHA256 131fa083cb8cd7ed02f48f4fba0f5190ea60d700031c00542c366097b4657463) of such a malware through VMRay and got some interesting results.
Despite the obvious malicious nature of this malware, only 32 of 57 anti-virus vendors scored it as such on VirusTotal when this was submitted in September.

The sample file binb.exe creates a new directory inside the AppData folder. Using this folder which is normally hidden might be part of the malware’s stealth capabilities. Inside the created folder the sample drops a Ruby script called bind.rb and installs the Ruby interpreter. Then the executable runs the script bind.rb.
Since the VMRay Analyzer automatically extracts created files we can conveniently look at the started script.



Even at a glance the script’s intent seems obvious. The code starts by allocating executable memory with VirtualAlloc. Into this memory block the shellcode from the variable FzJnoy is stored. At the end a new thread is created to start the execution of the shellcode. Here the analysis becomes less straightforward. Disassembling the first few instructions indicates the usage of the “Shikata Ga Nai” shellcode encoder/decoder, which is often used to fool AV products.



This renders static analysis hard because we would have to write a decoder for Shikata Ga Nai first. However using dynamic analysis instead we have a look at the shellcode’s informative function logfile.



VMRay clearly shows the intention of the shellcode. The malware loads the ws2_32 dll which is used for network connections. After initializing the network library a socket is opened and a backdoor is installed on TCP port 10000. The malware authors overlooked adding a permissive firewall exception first before listening for incoming connections. This results in a security alert by the Windows firewall. VMRay has an AutoUI capability that by default will interact with dialog boxes and provided expected responses – such as ‘accepting’ the EULA in an installer. In this case the dialog is acknowledged automatically so that the execution can continue and no behavior is missed:



To summarise, this malware leverages a high-level language interpreter (Ruby) to mask its intent and evade analysis. It creates a backdoor on the target system listening on TCP port 10000.
We see more malware now using higher level programming languages and models to evade static and dynamic analyzers. VMRay’s technology is agnostic of the software mechanisms used and automatically adapts its monitoring granularity. In other words,when the analyzed piece of software issues API calls, VMRay monitors on the API level; if it issues direct system calls, VMRay monitors at syscall level, and if it invokes COM method calls, VMRay will monitor on COM level. Hence, nothing is missed and the highest semantic layer possible will be analyzed, resulting in undiluted detailed reports.