Blockchain & Brainwallet cracking

img_1293The blockchain is the underlying technology that enables the bitcoin cryptocurrency to exist. A foundational component of this technology is its complex cryptosystem. The blockchain cryptosystem relies on public key algorithms based on Elliptic Curve and message digest functions like SHA-256 and RIPEMD-160. When you create a bitcoin wallet, under the hood you are creating an Elliptic Curve key pair based on Secp256k1 curves. The key pair has a private key and a public key. The private key is the one you keep secret and allows you to sign transactions. For example, when you send bitcoins to someone, you are signing this transaction with your private key and then you announce it to the network. The miners will pick up your transaction and verify that the transaction signature is valid and broadcast to the network until enough miners have validated the transaction and thus achieving consensus. The checks and balances of the Blockchain ledger are updated and when consensus is achieved, your transaction is written in “digital stone”.

On the other hand, the public key is the one used to create your bitcoin wallet address. The public key allows you to receive bitcoins. However, your bitcoin wallet address is not your raw Elliptic Curve public key There are additional steps performed in order to create an address. First, a digital representation of your public key is computed using SHA-256 followed by RIPEMD-160. Second, a byte with network id is prepended to this string. Third, a checksum of this string is computed by performing SHA-256 twice. From these results the first 4 bytes are appended to the string produced in second step. This string is encoded in Base58 and this is your bitcoin wallet address. The picture below illustrates this steps in a non-automated way.

generatebitcoinaddr

There are many forms to store your bitcoins as well as to create wallets. One of the early methods to create bitcoin wallets was known as brain wallets. Unfortunately, this user-friendly method allowed you to enter a password or passphrase which was then hashed using an algorithm such as SHA-256 and used as seed to generate your private key. Due to its popularity and easy usage, many Brain wallets were used in the last few years with weak passwords or passphrases, transforming the Blockchain wallet address hashes in password or passphrases representation of your private key. This weak way of generating your private key allowed attackers to steal your bitcoins just by doing password cracking against the hashes stored in the Blockchain.

Although, this attack has been known for years,  it only got widely known recently due to the work made by Ryan Castellucci. Ryan’s released on 7th August 2015 at DEFCON 23 the results of his work cracking brain wallets in conjunction with a tool called BrainFlayer : A proof-of-concept cracker for cryptocurrency brain wallets and other low entropy key algorithms. You can view Ryan’s talk here.  Two months after Ryans’ initial release of BrainFlayer, he released a faster version. This was the result of the work done by Nicolas Courtois, Guangyang Song from
International Association for Cryptologic Research (IACR), University College London, and Ryan’s to optimize the speed of computing secp256k1 bitcoin elliptic curve. This has been detailed in the paper Speed Optimizations in Bitcoin Key Recovery Attacks.  Furthermore, this year at the Financial Cryptography and Data Security conference, Marie Vasek presented another article The Bitcoin Brain Dain: A Short Paper on the Use and Abuse of Bitcoin Brain Wallets. This paper published the results of evaluating 300 billion passwords against Blockchain hashes and their findings about 884 brain wallets that had funds at a given time, suggesting they might have been drained by active attackers.

So, how do you perform such attack?

The attempt to recover a password just by knowing its encrypted representation can be made mainly using three techniques. Dictionary attacks, which is the fastest method and consists of comparing the dictionary word with the password hash. Another method is the brute force attack, which is the most powerful one but the time it takes to recover the password might render the attack unfeasible. This is of course dependable on the complexity of the password and the chosen algorithm. Finally, there is the hybrid technique which consists of combining words in a dictionary with word mangling rules.

With that being said let’s go over the steps needed to perform this attack against the Blockchain hash160 hashes using a dictionary. This is done in 6 steps:

  • Bootstrap the Blockchain.
  • Parse the Blockchain by running Blockparser and get allBalances.
  • Extract hash160 strings.
  • Create a Bloomfilter.
  • Run BrainFlayer with your favorite dictionary.
  • Use Addressgen to generate key pair.

First step is to bootstrap the blockchain. To perform this, we need to download, install and run the bitcoin software on a system connected to the Internet. The system then becomes a node and part of the peer-to-peer blockchain network. The first task performed by the node is to download the entire database of records i.e., the public transaction ledger and verify it using the transaction engine. In other words, the node downloads the entire blockchain and verifies the validity of all blocks by performing a series of checks   This needs a lot of bandwidth and computing power. As I write this the Blockchain size is 90.633 Gb and contains 438556 blocks. The data contains every transaction that has been made in the blockchain since the genesis block was created on the 3rd of January 2009 at 18:15:05 GMT. To download the entire Blockchain, took me more than 72 hours . The image below illustrates the steps needed to perform the download, installation and running the bitcoin software.

installbitcoin

Then, the picture below illustrates the steps needed to perform the configuration and running the bitcoin software. You can view the progress by executing the getblockchaininfo command and check the number of blocks that have been already downloaded.

runbitcoin

After downloading the entire Blockchain we move into the second step. Parse the Blockchain.  The tool to perform this heavy lifting exercise is called Blockparser and is a powerful utility, open source, written in C++ that was created by Znort987. The tool doesn’t seem to be maintained anymore but is still able to perform its work. When blockparser performs the parsing, it creates and keeps the index in RAM which means with the current size of the blockchain you need enough RAM to be able to parse it in reasonable amount of time. The tool can perform various task but for this exercise we are interested in the allBalances command. To perform the parsing, I used a system with 64 GB ram and the process was smooth. I tried it on a system with 32Gb and stopped it due to the heavy swapping that was happening. The allBalances produced a 30Gb text file. The image below exemplifies these steps.

blockchainparsing

Third step is to extract the hash160 addresses from the allBalances. We are interested in the hash160 because this field contains the representation of the Bitcoin public key. Below you can see the output of allBalances.

allbalances

Forth step, we create a bloom filter with the tool hex2blf which is part of the brainflayer toolkit. We also need to create a binary file containing all the hashes sorted in order to be used with the bloom filter. This will reduce the false positives.

Fifth step, we launch brainflayer using our favorite dictionary against the bloom filter file we generated in the previous step. If there is a match you will see the password or passphrase and the corresponding hash. In the output of cracked password you could see C or U in the second column. This is to indicate if the key is Compressed or Uncompressed. In the below image you can see these steps.

brainflayer

Sixth step and last step is to create the Elyptic Curve key pair using the known password or passphrase. This can be done using the tool Addressgen created by sarchar. Addressgen is a utility written in Python 3 to generate private keys and their corresponding addresses using secp256k1. This utility will allow you to generate the ECDSA key pair which can be used to take over the wallet.

generateaddress

Financial gain is a significant incentive to have people performing all kinds of activities in order to attempt to steal your coins. If you are interested in attacks against the Blockchain I would suggest looking at the different papers created by the professor Dr. Nicolas Courtois and available on his website. On a different note, there are other researchers that are brute forcing the entire bitcoin private key keyspace in order to find private keys for addresses that have funds. There is one project that has the code name Large Bitcoin Collider which is a distributed effort with a pool where people can contribute computing power. The thread on Bitcointalk forum is quite interesting and the author has the following aim for this project: “allow the Bitcoin community to actually have a better shot at risk assessment of this threat vector. Right now, the math says the danger is negligible. Should there at some point be evidence or indication of the contrary, then it’s still better to have a project like this for analysis/experimentation of this concrete attack vector”. The author also writes that the project is a derivative of brainflayer and supervanitygen. Moreover, brainflayer can also perform brute force attack, sequentially against the entire private key space. This would be unfeasible to perform in a reasonable time frame but better to view the talk “Stealoing Bitcoin with Math – HOPE XI” given by Fillippo Valsorda and Ryan’s where among other things they show how quick brain wallets get drained, attacks against newer Brainwallet implementations and other attacks against Eliptic Curve Digital Signature Algorithm (ECDSA).

 

References:
Mastering Bitcoin – Unlocking Digital Cryptocurrencies by Andreas M. Antonopoulos

Tagged , , , ,

RIG Exploit Kit Analysis – Part 3

Over the course of the last two articles (part 1 & part 2), I analyzed a recent drive-by-download campaign that was delivering the RIG Exploit Kit . In this article, I will complete the analysis by looking at the shellcode that is executed when the exploit code is successful.  As mentioned in the previous articles, each one of the two exploits has shellcode that is used to run malicious code in the victims system. The shellcode objective is the same across the exploits: Download, decrypt and execute the malware.

In part 1, when analyzing the JavaScript that was extracted from the RIG landing page we see that at the end there was a function that contained a hex string of 2505 bytes. This is the shellcode for the exploit CVE-2013-2551.  In a similar way but to exploit  CVE-2015-5122 on the second stage Flash file, inside the DefineBinaryData tag 3, one of the decrypted strings contained a hex string of 2828 bytes.

So, how can we analyze this shellcode and determine what it does?

You can copy the shellcode and create a skeletal executable that can then be analyzed using a debugger or a dissassembler. First, the shellcode needs to be converted into hex notation (\x). This can be done by coping the shellcode string into a file and then running the following Perl one liner “$cat shellcode | perl -pe ‘s/(..)/\\x$1/g’ >shellcode.hex”. Then generate the skeletal shellcode executable with shellcode2exe.py script written by Mario Villa and later tweaked by Anand Sastry.  The command is “$shellcode2exe.py –s shellcode shellcode.exe”. The result is a windows executable for the x86 platform that can be loaded into a debugger.  Another way to convert shellcode is to use the converter tool from http://www.kahusecurity.com

Next step is to load the generated executable into OllyDbg. Stepping through the code one can see that the shellcode contains a deobfuscation routine. In this case, the shellcode author is using a XOR operation with key 0x84. After looping through the routine, the decoded shellcode shows a one liner command line.

rigexshellcodeolly

After completing the XOR de-obfuscation routine the shellcode has to be able to dynamically resolve the Windows API’s in order to make the necessary system calls on the environment where is being executed. To make system calls the shellcode needs to know the memory address of the DLL that exports the required function. Popular API calls among shellcode writers are LoadLibraryandGetProcAddress. These are common functions that are used frequently because they are available in the Kernel32.dll which is almost certainly loaded into every Windows operating system.  The author can then get the address of any user mode API call made.

Therefore, the first step of the shellcode is to locate the base address of the memory image of Kernel32.dll. It then needs to scan its export table to locate the address of the functions needed.

How does the shellcode locate the Kernel32.dll? On 32-bit systems, the malware authors use a well-known technique that takes advantage of a structure that resides in memory and is available for all processes. The Process Environment Block (PEB). This structure among other things contains linked lists with information about the DLLs that have been loaded into memory. How do we access this structure? A pointer exists to the PEB that resides insider another structure known as the Threat Information Block (TIB) which is always located at the FS segment register and can be identified as FS:[0x30](Zeltser, L.). Given the memory address of the PEB the shellcode author can then browse through the different PEB linked lists such as the InLoadOrderModuleList which contains the list of DLL’s that have been loaded by the process in load order. The third element of this list corresponds to the Kernel32.dll.  The code can then retrieve the base address of the DLL. This technique was pioneered by one of the members of the well-known and prominent virus and worm coder group 29A and written in volume 6 of their e-zine in 2002. The figure below shows a snippet of the shellcode that contains the different sequence of assembly instructions in order for the code to find the Kernel32.dll.

rigekshellcodeapildr

The next step is to retrieve the address of the required function. This can be obtained by navigating through the Export Directory Table of the DLL. In order to find the right API there is a comparison made by the shellcode against a string. When it matches, it fetches its location and proceeds.  This technique was pioneered and is well described in the paper “Win32 Assembly Components” written in 2002 by The Last Stage of Delirium Research Group (LSD). Finally, the code invokes the desired API. In this case, the shellcode uses the CreateProcessA API where it will spawn a new process that will carry out the command line specified in the command line string.

rigekshellcodecreateproc

This command will launch a new instance of the Windows command interpreter, navigate to the users %tmp% folder and then redirect a set of JavaScript  commands to a file. Finally it will invoke Windows Script Host and launch this JavaScript file with two parameters. One is the decryption key and the other is the URL from where to fetch the malicious payload. Essentially this shellcode is a downloader. The full command is shown in the figure below.

rigekshellcodedecoded

If the exploits are sucessfull and the shellcode is executed then the payload is downloaded. In this case the payload is variant of Locy ransomware and a user in Windows 7 box would see the User Account Control dialog box popping up asking to run it.

rigekuac

That’s it! We now have a better understanding how this variant of the RIG Exploit Kit works and what it does and how. All stages of the RIG Exploit Kit enforce different protection mechanisms that slow down analysis, prevent code reuse and evade detection. It begins with multiple layers of obfuscated JavaScript using junk code and string encoding that hides the code logic and launches a browser exploit. Then it goes further by having multiple layers of encrypted Flash files with obfuscated ActionScript. The ActionScript is then responsible to invoke an exploit with encoded shellcode that downloads encrypted payload. In addition, the modular backend framework allows the threat actors to use different distribution mechanisms to reach victims globally. Based on this modular backend different filtering rules are enforced and different payloads can be delivered based on the victim Geolocation, browser and operating system. This complexity makes these threats a very interesting case study and difficult to defend against. Against these capable and dynamic threats, no single solution is enough. The best strategy for defending against this type of attacks is to understand them and to use a defense in depth strategy – multiple security controls at different layers.

References:

SANS FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques
Neutrino Exploit Kit Analysis and Threat Indicators

Tagged , , , , , , , ,

RIG Exploit Kit Analysis – Part 2

Continuing with the analysis of the RIG exploit kit, let’s start where we left off and understand the part that contains the malicious Adobe Flash file. We saw, in the last post, that the RIG exploit kit landing page contains heavily obfuscated and encoded JavaScript. One of the things the JavaScript code does is verifying if the browser is vulnerable to CVE-2013-2551. If it is, it will launch an exploit followed by shellcode, as we saw in the last post. If the browser is not vulnerable, it continues and the browser is instructed to download a malicious Flash file. The HTTP request made to fetch the Flash file is made to the domain add.alislameyah.org. As you could see in the figure below, the HTTP answer is of content type x-shockwave-flash and the data downloaded starts with CWS (characters ‘C’,’W’,’S’ or bytes 0x43, 0x57, 0x53). This is the signature for a compressed Flash file.

rigekflash

Next  step of our analysis? Analyze this Flash file.  Before we start let’s go over some overview about Flash. There are two main reasons why Flash is an attractive target for malware authors. One is because of its presence in every modern endpoint and available across different browsers and content displayers. The other is due to its features and capabilities.

Let’s go over some of the features. Adobe Flash supports the scripting language known as ActionScript. The ActionScript is interpreted by the Adobe ActionScript Virtual Machine (AVM). Current Flash versions support two different versions of the ActionScript scripting language. The Action Script (AS2) and the ActionScript 3 (AS3) that are interpreted by different AVM’s. The AS3 appeared in 2006 with Adobe Flash player 9 and uses AVM2. The creation of a Flash file consists in compiling ActionScript code into byte code and then packaging that byte code into a SWF container. The combination of the complex SWF file format and the powerful AS3 makes Adobe Flash an attractive attack surface. For example, SWF files contain containers called tag’s that could be used to store ActionScript code or data. This is an ideal place for exploit writers and malware authors to conceal their intentions and to use it as vehicle for launching attacks against client side vulnerabilities. Furthermore, both AS2 and AS3 have the capability to load SWF embedded files at runtime that are stored inside tags using the loadMovie and Loader class respectively. AS3 even goes further by allowing referencing objects from one SWF to another SWF. As stated by Wressnegger et al., in the paper “Analyzing and Detecting Flash-based Malware using Lightweight Multi-Path Exploration ” this allows sophisticated capabilities that can leverage encrypted payloads, polymorphism and runtime packers .

Now, let’s go over the analysis and dissection of the Flash file. This is achieved using a combination of dynamic and static analysis. First, we look at the file capabilities and functionality by looking at its metadata. The command line tool Exiftool created by Phill Harvey can display the metadata included in the analyzed file. In this case, it shows that it takes advantage of the Action Script 3.0 functionality.  Information that is more comprehensive is available with the usage of the swfdump.exe tool that is part of the Adobe Flex SDK, which displays the different components of the Flash file. The output of swfdump displays that the SWF file contains the DoABC and DefineBinaryData tags.  This suggests the usage of ActionScript 3.0 and binary data containing other elements that might contain malicious code executed at runtime.

Second, we will go deeper and dissect the SWF file. Open source tools to dissect SWF files exist such as Flare and Flasm written by Igor Kogan. Regrettably, they do not support ActionScript 3.  Another option is the Adobe SWF Investigator. This tool was created by Peleus Uhley and released as open source by Adobe Labs. The tool can analyze and disassemble ActionScript 2 (AS2), ActionScript 3 (AS3) SWFs and include many other features. Unfortunately, sometimes the tool is unable to parse the SWF file in case has been packed using commercial tools like secureSWF and DoSWF.

One good alternative is to use JPEXS Flash File Decompiler (FFDec). FFDec is a powerful, feature rich and open source flash decompiler built in Java and originally written by Jindra Petřík. One key feature of FFDec is that it includes an Action Script debugger that can be used to add breakpoints to allow you to step into or over the code. Another feature is that it shows the decompiled ActionScript and its respective p-code.

One popular tool among Flash malware writers is doSWF. doSWF is a commercial product used to protect the intellectual property of different businesses that use Adobe Flash technology and want to prevent others copying it. Malware authors take advantage of this and use it for their own purposes. This tool can enforce different protections to the code level in order to defeat the decompiler. In addition to the different protections done to the code logic, doSWF can perform literal strings encryption using RC4 or AES. Also, it can be used to wrap an encrypted SWF inside another SWF file using the encrypted loader function.  The decryption occurs at runtime and the decrypted file is loaded into memory.

Opening the SWF file using FFDec and observing its structure using Action Script you can see the different strings referencing doSWF which is an indication that the file has been obfuscated using doSWF. FFDec has a P-Code deobfuscation feature that can restore the control flow, remove traps and remove dead code. In addition, there is a plugin that can help rename invalid identifiers.  The figure below shows a snippet of the ActionScript code after it has been deobfuscated by FFDec.

rigekfirststageflash

As seen in other Exploit Kits such as Angler and Neutrino, the first flash file is only used as carrier and malicious code such as exploit code or more Flash files are encrypted and obfuscated inside this first stage flash file.. The goal here is to perform static analysis of the Action Script code and determine what is happening behind the scenes. Normally, the DefineBinaryData contains further Flash files or exploit code but you need to understand the code and get the encryption keys in order to extract the data. Because my strengths are not in programming I tried to overcome this step before rolling up my sleeves and spending hours trying to understand the Action Script code like I did for Neutrino with the help of some friends. One way to carve the data is to use the Action Script debugger available in FFDec.  Essentially, setting a breakpoint in the LoadBytes() method. Then running the Flash file and then when the breakpoint is triggered, use the FFDec Search SWF in memory plugin in order to find SWF files inside the FFDec process memory address space. But for this sample I used SULO.

During Black Hat USA 2014, Timo Hirvonen presented a novel tool to perform dynamic analysis of malicious Flash files. He released an open source tool named SULO. This tool uses the Intel Pin framework to perform binary instrumentation in order to analyze Flash files dynamically. This method enables automated unpacking of embedded Flash files that are either obfuscated or encrypted using commercial tools like secureSWF and DoSWF.  The code is available for download on F-Secure GitHub repository (https://github.com/F-Secure/Sulo) and it should be compiled with Visual Studio 2010. The compilation process creates a .DLL file that can be used in conjunction with Intel Pin Kit for Visual Studio 2010. There are however limitations in the versions of Adobe Flash Player supported by SULO. At the time of writing only Flash versions 10.3.181.23 and 11.1.102.62 are supported. Nonetheless, one can use SULO with the aim to extract the packed Flash file in a simple and automated manner. In this case, I used the stand alone Flash player flashplayer11_1r102_62_win_sa_32bit.exe.

When using SULO to analyze the Flash file, the second stage Flash file is extracted automatically. The command shown in figure below will run and extract the packed SWF file.

rigeksulo

In this particular case, SULO manages to extract 2 SWF files. So, the next step is to analyze these second stage SWF files. Once again, using FFDec and observing its structure and Action Script code. The second stage Flash files are interesting because one contains the code and the other makes extensive use of DefineBinaryData tag’s to store encrypted data.  As a starting point, the analysis steps here are the same. Invoke the P-Code deobfuscation feature in order to restore the control flow, remove traps and remove dead code. In addition, the plugin to rename invalid identifiers was executed. After performing these two steps, the Action Script code is more readable.

In this post I won’t bother you with the details about the Action Script code. Nonetheless, one thing to mention about the code is that if you follow the site malware.dontneedcoffee.com and the amazing work done by Kaffeine on hunting down, analyzing and documenting Exploit Kits you might have noticed that he calls this version of RIG “RIG-v Neutrino-ish“. The reason might be due to the usage of the RC4 key to decrypt the payload and also the similarities in the way the Flash files are encoded and obfuscated.

Anyhow, understanding the code is important but is also important to understand what the Flash file is hiding from us. In a nutshell, one of the second stage Flash files contain several defineBinaryTags which contain encrypted strings that are used throughout the code in the other second stage Flash file. The data can be obtained by decrypting the data using RC4 keys that are also inside the defineBinaryTags. The figure below ilustrates this.

rigex-2ndstageflash

In summary DefineBinaryData tag 2 contains an array of one 16-byte RC4 key. DefineBinaryData tag 1 contains 19 (0x13) RC4-encrypted strings. The first dword contains the total number of strings. Then each string starts with a dword that contains the size of the string, followed by the RC4-encrypted data.

The DefineBinaryData tag 3 contains an array of three 16-byte RC4 keys. DefineBinaryData tag 4 contains 6 (0x06) RC4-encrypted strings. The first dword contains the total number of strings. Then each string starts with a dword that contains the size of the string, followed by the RC4-encrypted data. The RC4 decryption routine uses the 3 RC4 keys iteratively across the 19 strings.

The decrypted strings are used on different parts of the code. One of the strings is relevant because it contains shellcode that is nearly identical to the one seen in the JavaScript exploit inside the landing page.

Based on the decrypted strings it seems the Flash contains code to exploit CVE-2015-5122. This exploit has a CVSS score of 10 and is known as Adobe Flash ActionScript 3 opaque Background Use-After-Free Vulnerability. This exploit was found as a result of the public disclosure of the Hacking Team leak. In a matter of hours, the exploit was incorporated in the Angler Exploit Kit.

… and with a so lengthy post, that’s it for today. In the following post I will cover how to analyze the Shellcode to understand what is done behind the scenes when one of the exploits is successfully triggered.

First stage Flash file MD5: d11c936fecc72e44416dde49a570beb5
Second stage Flash file MD5: 574353ed63276009bc5d456da82ba7c1
Second stage Flash file MD5: e638fa878b6ea20fa8253d79b989fd7e
References:

Neutrino Exploit Kit Analysis and Threat Indicators

Tagged , , , , , , ,

RIG Exploit Kit Analysis – Part 1

One of the Exploits kits that has been in the news lately is the RIG Exploit Kit. Some of the infections seen by the community seem to be part of a campaign called Afraidgate. I had the chance to capture one infection from this campaign. So, I decided to give it a try and write a small write-up about this multistage weaponized malware kit. The following analysis focus is on a drive-by-download campaign observed few days ago. It leverages the RIG Exploit Kit to infect systems and drop a new version of Locky ransomware (Odin).

Due to the complex nature of Exploit Kits, in order to perform analyses I use a combination of both dynamic and static analysis techniques. For the dynamic analysis part, I used an enhanced version of the setup described here “Dynamic Malware Analysis with REMnux’.

As usual, the infection starts with a innocent victim browsing to a compromised website. The compromised website replies with a HTTP response similar to the one in the figuyre below. The response does not always include the malicious payload. The compromised web server contacts the RIG back-end infrastructure in order perform various checks before it delivers the malicious JavaScript code. Checks include verification of the victim IP address and its Geo-location. Furthermore, within the malicious JavaScript code, there are new domain names and URLs that are generated dynamically by the backend for each new infection. As you could see in the figure, inside the HTTP response, blended with the page content, there is code to invoke a malicious JavaScript code. In this particular case, the malicious code is retrieved from the URL /js/stream.js” hosted on “monro.nillaraujo.com”. Noteworthy is the fact that for each new request to the compromised site there is a new domain and URL generated dynamically by the Exploit Kit. This is a clever technique and is much more challenging to build defenses that block these sites

rigex1

To reach out to the server “monro.nillaraujo.com ” the operating system performs a DNS query in order to finds its IP address. The name server (NS) who is authoritative for the domain gives the DNS response. In this case the NS server for this domain is “ns1.afraid.org “. This server belongs to the Free DNS hosting. They provide everyone with free DNS access. In this case the threat actors take advantage of this. I think the name of the Afraidgate campaign might have derived from the fact that the DNS domains used in the gates are being answered by afraid.org. Brad Duncan might be able to answer this! Another interesting fact is that the answer received by the DNS server have a short time to live (TTL). This technique is often leveraged by the threat actors behind the EK because this will make the domain only available for of a limited amount of time, allowing them to shift infrastructure quickly. This makes the blocking and analysis much more difficult. The below figure show the DNS answer for the domain  “monro.nillaraujo.com”.

rigexafraiddnsreply

This particular domain at the time of the analysis was resolved to the IP 139.59.171.176. Then, after the DNS resolution, the browser makes the HTTP request in order to fetch the malicious JavaScript code. The HTTP answer is shown below.

rigex2

The line of code that contains the <iframe> tag is instrumental in the infection chain. This line of code will instruct the browser to make a request to the URL / ?xniKfreZKRjLCYU=l3SKfPrfJxzFGMSUb-nJDa9BNUXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KTKvgJQyfu0SaGyj1BKeO10hjoUeWF8Z5e3x1RSL2x3fipSA9weEYQ4U-ZWVE7g-iVukmrITIs0uxRKA4DRYnuJJVlJD4xgY0Q
that is hosted in the server add.ALISLAMEYAH.ORG. This is the server hosting the RIG Exploit landing page for this particular infection and points to an IP address in Russia. When the browser processes this request, the victim lands in the Exploit Kit landing page that in turn delivers a HTML page with an script tag defined in its body. This script tag contains heavily encoded and obfuscated JavaScript code.

The widespread install base of JavaScript allows malware authors to produce malicious web code that runs in every browser and operating system version.  Due to its flexibility, the malware authors can be very creative when obfuscating the code within the page content.  In addition, due to the control the threat actors have over the compromised sites, they utilize advanced scripting techniques that can generate polymorphic code. This polymorphic code allows the JavaScript to be slightly different each time the user visits the compromised site.  This technique is a challenge for both security analysts and security controls.For each new victim request there is a different landing URL and slightly different payload. The figure below shows the JavaScript code inside the HTTP response. This is the RIG Exploit kit landing page.

rigeklanding

From an analysis perspective, the goal here is to understand the result of the obfuscated JavaScript. To be able to perform this analysis one needs to have a script debugger and a script interpreter. There are good JavaScript interpreters like SpiderMonkey or Google Chrome v8 that can help in this task. SpiderMonkey is a standalone command line JavaScript interpreter released by the Mozilla Foundation (SpiderMonkey). Google Chrome v8 is an open source JavaScript engine and an alternative to SpiderMonkey (Introduction Chrome V8).

In this particular case, the JavaScript contains dependencies of HTML components. Because of this, it is necessary to use a tool that can interpret both HTML and JavaScript. One tool option is JSDetox created by Sven Taute (JSDetox). JSDetox allows us to statically analyze and deobfuscate JavaScript.

Another great Java Script debugger suite is Microsoft Internet Explorer Developer Tools, which includes both a debugger for JavaScript and VBScript. This tool allows the user to set breakpoints. In this case by stepping through the code using the Microsoft IE Developer tool and watching the content of the different variables, the deobfuscation can be done.  Another option is to use Visual Studio client side script debugging functionality in conjunction with Internet Explorer.

In this case, I used the Microsoft Internet Explorer Developer. After some time analyzing the deobfuscation loop, stepping over the lines of code, inserting breakpoints in key lines and watching the different variables, some of the code is revealed.  The result is JavaScript code that triggers the exploit code based on the browser version and if you have Adobe Flash installed it will trigger the download of a malicious Flash file.

For the IE Browser, the RIG EK should leverage two or more exploits at a given time. In my setup I was limited to the the JavaScript code that seems to leverage CVE-2013-2551. This exploit has a CVSS score of 9.3 and exploits a Use-after-free vulnerability in Microsoft Internet Explorer 6 through 10. This vulnerability was initially discovered by VUPEN and demonstrated during the Pwn2Own contest at CanSecWest in 2013. After the detailed post from VUPEN, different exploit kits started to adopt it. According to the NTT Global Threat Intelligence Report 2015, this highly reliable exploit made its way to the top of being one of the most popular exploits used across all Exploit Kits today.

rigieexploit

The code is quite large so I won’t post it here but in the figure above you could see the last part of it. It contains the Shellcode and the URL plus RC4 key that are used to fetch the malicious payload and decrypt it e.g, Locky ransomware.

That’s it for today. In the following post I will cover the malicious Flash file and how to analyze the Shellcode to understand what is done behind the scenes when the exploit is successfully triggered.

References:

Neutrino Exploit Kit Analysis and Threat Indicators

Tagged , ,

Malware Analysis – Dridex Loader – Part 2

On our last blog post, we performed malware analysis of Dridex and found out how to decode its strings. This gave us more visibility into its intent and functionality. In this part we will continue the analysis and move into getting the Dridex configuration settings and XML messages that are generated and exchanged with the C&C.

Please note that a bit of familiarity with OllyDbg is needed in order to follow the steps described.

Dridex is known to contain an initial configuration which contains the campaign ID and the addresses of the C&C. In the previous post, one of the strings that we obtained from decoding the chunk at virtual address 0x00411020 was “%d.%d.%d.%d:%d”. This string is interesting because it’s a format string that denotes the format of an IP address and port. Provided with this information we start our analysis and step through the code and try to determine where is used. Essentially, at some point in time, after going back and forth in the debugger, setting breakpoints and restarting the debugging session, we can see that there is a function at virtual address 0x00404408 that is responsible to read a chunk of data stored in virtual address 0x004164e0 (file offset 0x000154E0). Stepping through the execution of this function we can see in the stack our string being used and moments after, the first IP address of the C&C appears in the stack view. Going over this function a couple of times and verifying what it does we can determine that the Botnet ID, number of C&C and the C&C addresses are retrieved from this chunk of data. Below is a print screen that shows the instructions that perform this operation.

dridex-readcncip

After reading the values, the C&C addresses are converted to ASCII and the value is returned by the wvnsprintfA() API using the format  string “%d.%d.%d.%d:%d”. The list of C&C for this sample are:

  • 94.73.155.12:2448
  • 103.252.100.44:4493
  • 89.108.71.148:8443
  • 221.132.35.56:8443

Now that we know where this information resides, we can also get the C&C addresses outside of the debugger. We know the file offset where the configuration settings are. Then we can use the command line to get the hex values for the botnet ID and IP addresses and convert them using the printf command and the format string “%d.%d.%d.%d:%d”.

dridex-cncips-file

After this, the approach is the same. Stepping through the code, setting breakpoints, restarting the debug session and repeating this for several times until we find what we are looking for. In this case we can see that the next string to be used is the following:

dridex-loaderstring

This will be the next step performed by the loader. Gathering information to populate this XML message which will then be used to report to the C&C in order to retrieve the C&C nodes and further down the road retrieve the DLL module. Now, how does the loader generate the values that are used to populate this XML message? Let’s go over each one.

The unique=”%s” value is generated by querying different values from the Windows registry and then computing a hash of these values using MD5 as algorithm. In order to query the values from the Registry, Dridex uses the RegOpenKeyExA() and RegQueryValueExA() API’s. By setting a breakpoint in these API’s we can see the different registry keys and subkeys being queried. An example is shown in the following image.

dridex-regqueryvalue-computername

The values obtained are from the subkeys ComputerName, USERNAME and InstallDate. We can obtain the values by setting a breakpoint in the RegQueryValueExA() and then view the contents of the buffer address.
The full registry keys are:

dridex-regqueryvalues

This information is then concatenated and 4 null bytes are appended to it. This is then passed to a hashing routine to compute a MD5 hash. To perform this operation this sample uses CryptAcquireContextW(), CryptCreateHash(), CryptHashData() and CryptGetHashParam() API calls.  How do we know its MD5? We can set a breakpoint in CryptCreateHash() and determine the algorithm used by looking at the stack view and look at the different arguments. Specifically the alg_id has the value 0x00008003. By looking at the MSDN website, we can verify that this number corresponds to MD5. Then by setting a breakpoint on CryptHashData() and stepping into its execution we can see the buffer of data as shown in the below picture.

dridex-crypthashdata

The generation of the botnet ID value can be replicated by copying the 12 bytes of the buffer and computing the md5 hash with command seen in the below picture.

dridex-uniqueidmd5

Then the botnet value is retrieved from the configuration settings hardcoded in the binary, as we saw previously, and has the value 220 (0x00DC). The bit value is the system architecture. Finally, the Soft XML tag is populated by the list of software installed in the machine. This is accomplished by opening the registry key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall” and querying the values “DisplayName” and “DisplayVersion”. Once again this information can be seen by setting a breakpoint in the RegOpenKeyExA() and RegQueryValueExA() API’s.  After gathering all the information, the loader configuration XML message will look similar to the following:

dridex-loaderlistsw

This message on my system is temporarily saved at virtual address 0x0069B008. Stepping through the code you will see that this message becomes gibberish. Essentially, this XML message is passed to a function that transform this message into gibberish. Dridex is known to use RC4, so it would be a matter of time (.. and some help) in order to understand where this encryption is done and if is RC4.

Going back and forth in the debugger we found a function at virtual address 0x00409504 that performs the encryption. To figure out thefunction where the encryption routine is performed the article “An Introduction to Recognizing and Decoding RC4 Encryption in Malware” was very helpful.

This sample uses a 2048-bits RC4 key to encrypt the data. The key is obtained from the decoded strings. In this sample the RC4 key is: “Yhc3XUIiv2rNzgy968TWCcx6PjBvLnuyT0ofNA9lvif8EIoZrLshPJ2kYi1WFXMDsuihGkT”. In the picture below we can see the data before encrypted at virtual address 0x00698b008.

dridex-rc4encryption

After encryption, the data is sent over the network using a HTTPS request. In the debugger we can see that the request uses the POST verb by setting a breakpoint on HttpOpenRequestW(). We can also see the body of the request and its size by setting a breakpoint on HttpSendRequestW() and looking at the contents of the virtual address used by the buffer parameter.

dridex-httpsendrequest

In the network we can see the exact same data by doing SSL interception using Burp proxy.

dridex-httpsendburp

Then, the C&C replies back with RC4 encrypted message which we can observe in the network also using Burp.

dridex-httpsreply

Following that, the HTTPS response is processed and the payload is retrieved by InternetReadFile() API and passed to the RC4 decryption routine. Because RC4 is a symmetric algorithm we can use the encryption key to decrypt the payload. If we save the HTTPS response captured by Burp and use the RC4 key to decrypt the body of the HTTP response, we get the following message:

dridex-httprespdecrypt

Before we continue is important to refer that this XML message contains the list of C&C nodes which will be used by the bot module (DLL) . To obtain the list of C&C, the data needs to be base64 decoded and then decoded with a 4-bytes XOR key which is stored at byte 128. In our case is 0x162b0e0f. After decoding, the data needs to be decompressed. The below picture illustrates how to obtain the nodes list.

dridex-nodeslist

This message named “list” is then saved for persistence by being used to populate a startup config XML message that is retrieved from the encoded strings and has the following format: <cfg net=”%d”><startup>%s</startup><del>%S</del></cfg>

After the XML message has been populated, it gets encoded with a XOR key that is created by computing the MD5 of the values that are retrieved from the below registry keys plus a value of 0x1c that is appended to it.

dridex-regvaluescslid

The encoded data is then saved into the registry into the following registry key:

dridex-regpersistclsid

Where “%s” will be substituted by the XOR key that was generated previously. In our case the encoded data will be saved into the registry entry “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{6B39CE2E-3F5E-4C33-366C-31C00F47FD68}\ShellFolder”. The operation of saving the encoded data into the Windows Registry can be observed by setting a breakpoint into the RegSetValueExA().

dridex-regsetvalue-clsid

Following that, the Loader creates a Mutex that is generated by computing a MD5 hash of the values retrieved from the same registry keys as the previous step, plus a value of 0x02 that is appended to it.  Then, the last step of the loader is to create a new XML message  that is used to check-in into the C&C and retrieve the DLL module. The XML message has the format: “<loader><get_module unique=”%s” botnet=”%d” system=”%d” name=”%s” bit=”%d”/>” . This message is populated with the values we already seen previously. Then is encrypted and sent over the network in a HTTPS POST request as we can see in Burp.

dridex-httpretrievemodule

The C&C replies back with a response.

dridex-httpreplyretrievedll

Noteworthy, that the content length of this message is much bigger than previous messages. The response gets processed as previously and then decrypted. The message decrypted contains the Dridex DLL module saved in base64.

dridex-dllb64

The DLL md5 is ccd94e452b35f8820b88d1e5856e8196 and can be obtained either by decrypting the network traffic using the RC4 key or by dumping the memory contents to a file using OllyDbg. After that the DLL is injected into explorer.exe.  To achieve this Dridex uses a technique known as DLL injection which consists in copying the malicious DLL into the address space of the target process i.e., explorer.exe and then creates a new thread which points to the malicious DLL. This technique is well explained in the Practical Malware Analysis book from Michael Sikorski and Andrew Honig.

Essentially, Dridex will browse the opened processes until it finds the one it wants to inject to. This is done using the API functions CreateToolhelp32Snapshot(), Process32First(), and Process32Next(). Then it opens the desired process with OpenProcess(), allocates memory in the target process with VirtualAllocEx() and it injects the malicious DLL and a piece of shellcode with WriteProcessMemory(). Following that it creates a remote thread using CreateRemoteThread(). The below picture illustrates some of the steps performed during the DLL injection.

dridex-dllinject

The loader process then exits and the DLL module will take over and do its job.

Before we conclude our analysis, there is one thing that is worth to mention. Its how Dridex creates a persistence mechanism to survive reboots. Dridex only creates the persistence mechanism when the operating system is rebooted or shutdown. This is a clever technique and difficult to detect. The DLL is dumped to the disk during the shutdown and a registry key is created under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run that invokes rundll32.exe to invoke the malicious DLL using an obfusctated export name. This will make sure the DLL is injected into explorer.exe when the operating system starts. Then the registry key is deleted. This key can been seen by starting the operating system in safe mode.

dridex-regpersistence

That’s it.  In this series of articles we covered different techniques used by Dridex. Dridex features and functionality go much more beyond the loader and one of its strengths  resides in the different modules and injection capabilities it has. Even in the loader there are features that we didn’t saw because we were running with admin rights in a Windows XP machine. The loader has other capabilities when is running in a more recent operating systems without admin rights such as bypassing UAC. Many of the features and modules are covered in the references articles. Nonetheless, hopefully this gives a good overview about the Dridex loader and its functionality.

These articles were possible due to the help from two good friends (you know who you are) that gave me some hints on some aspects of the analysis.

Loader MD5:c2955759f3edea2111436a12811440e1
DLL MD5:ccd94e452b35f8820b88d1e5856e8196

References:

http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/dridex-financial-trojan.pdf
https://www.cert.pl/news/single/talking-dridex-part-0-inside-the-dropper/
http://christophe.rieunier.name/securite/Dridex/20150608_dropper/Dridex_dropper_analysis.php
https://www.virusbulletin.com/virusbulletin/2015/07/dridex-wild/
https://sar.informatik.hu-berlin.de/research/publications/SAR-PR-2015-01/SAR-PR-2015-01_.pdf
https://cdn2.hubspot.net/hubfs/507516/ANB_MIR_Dridex_PRv7_final.pdf
https://www.lexsi.com/securityhub/how-dridex-stores-its-configuration-in-registry/?lang=en
http://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html
https://www.blueliv.com/downloads/documentation/reports/Network_insights_of_Dyre_and_Dridex_Trojan_bankers.pdf

Tagged , , , , ,
gb_master's /dev/null

... and I said, "Hello, Satan. I believe it's time to go."

Source Code Auditing, Reversing, Web Security

Finding Hidden codes in the software

BruteForce Lab's Blog

security, programming, devops, visualization, the cloud

Count Upon Security

Increase security awareness. Promote, reinforce and learn security skills.

Naked Security

Computer Security News, Advice and Research

Didier Stevens

(blog \'DidierStevens)

malwology

Adventures in double-clicking malware / by Anuj Soni

Rational Survivability

Hoff's Ramblings about Information Survivability, Information Centricity, Risk Management and Disruptive Innovation.

SANS Internet Storm Center, InfoCON: green

Increase security awareness. Promote, reinforce and learn security skills.

TaoSecurity

Increase security awareness. Promote, reinforce and learn security skills.

Schneier on Security

Increase security awareness. Promote, reinforce and learn security skills.

Technicalinfo.net Blog

Increase security awareness. Promote, reinforce and learn security skills.

Lenny Zeltser

Increase security awareness. Promote, reinforce and learn security skills.

Krebs on Security

In-depth security news and investigation