Seeing Through Darkleech Obfuscation: a Quick Hack to Iframes

By on

This blog post was written by Kalpesh Mantri.

Darkleech is an Apache module on the dark web that distributes malware. This tool, which appeared in 2012, was first used to infect many Apache servers and later sites running Microsoft IIS. The campaign infecting IIS sites was named pseudo-Darkleech because it resembles the Apache infector module. (In this post, we will use the term Darkleech to refer to both Apache and IIS campaigns.)

In early 2012, Darkleech scripts redirected users and led them to Blackhole exploit kit pages. After the Blackhole kit disappeared in October 2013, Darkleech moved to Fiesta exploit kits. From mid-2015 to today, Darkleech scripts switched occasionally between Neutrino and Angler exploit kits to deliver ransomware. Darkleech mostly redirects to Angler landing pages. (A detailed history of Darkleech can be found here.)

 

Finding Darkleech 

Since late 2015, Darkleech scripts have evolved drastically. They are now highly obfuscated, and we can’t easily determine the URLs they redirect to.

In this post we offer a quick hack for security researchers to find iframes and redirecting URLs from these heavily obfuscated scripts, which are injected into web pages. We will focus only on finding the iframe and URL; we will not discuss the functionality of the scripts or how they work. This hack does not require any special security tools. Using only Notepad and a browser (Firefox in this case), we can see the final iframe and its redirecting URL. This technique makes use of the browser’s “alert box” (message box) feature.

Warning: Do not directly run these scripts on a machine. Use VirtualBox or another virtual machine instead. Also, take caution while making use of the URLs in these scripts. They are usually exploit kit landing pages, which if active exploit vulnerabilities in users’ systems and download malware (mostly ransomware) to infect your system.

 

Find the sample

For our demonstration, we will use a Darkleech sample we found on VirusTotal that has a low detection rate.

SHA-256: 7ea431ca9980d5f1d92fc105cd89bc897774bbe970db5a8a32dcd6e73ef400ae

b1_1

This sample has a block of data between <span> tags. The data in this block is highly useful for decoding the final iframe. This data block is decoded using a script that is present just below the <span> block. This heavily obfuscated script lies within the <script> block of the HTML page:

b1_2

 

Follow these steps

Near the end of the script, you will find a function call with the following format:

  • Function_name(variable_name)();

In the script, the function appears like this:

b1_3

The variable_name is always a variable used to concatenate the entire script.

 

First step

Replace the function_name (in this case, fileUploadSetTimeout) with “alert” and remove the function call (the parentheses).

b1_4

After saving the file and opening this page in a browser, you will see the concatenated script string from this obfuscated code. The script will be displayed in a pop-up alert box.

b1_5

Copy and clean up the script:

b1_6

 

Second step

Append this discovered script to the current HTML sample page just below the first step. These scripts are designed to run only on Internet Explorer. So after appending the script, we need to tweak the script to make it run smoothly on Firefox (and other browsers). Change the script thus:

Modify the original statement at line 12 by changing the value of variable “i” to zero.

Original statement:        i = (+[window.sidebar]) + (+[window.chrome]);

Modified statement:      i = 0;

Also, remove the function call “()” and “[]” and modify the function call statement:

Original statement:        [][c][c](String.fromCharCode.apply(null, a))();

Modified statement:      temp = [c][c](String.fromCharCode.apply(null, a));

   alert(temp);

b1_7

Save this modified script into same sample. Running the sample again now gives us two alert pop-ups. The second pop-up outputs the concatenated script, which is itself a new deobfuscated script.

b1_8

Copy this script and clean it:

b1_9

 

Third step

Similar to the second step, append this script to the sample just after the second step script. Again, we tweak the script, four times, to make it run in Firefox or other browsers.

Modify the original statement at line 20 by replacing the value of variable “ArrayTry” to zero.

Original statement:        ArrayTry = (+[window.sidebar]) + (+[window.chrome]);

Modified statement:      ArrayTry = 0;

Change the if statement on line 23 to make the condition true:

Original statement:        if (navigator.userAgent.indexOf(pkcs11Typeof[throwImage]) > ArrayTry) {

Modified statement:      if (true) {

Also change the if statement on line 28 to skip the condition:

Original statement:        if (navigator.userAgent.indexOf(“MSIE 10”) > ArrayTry) {

Modified statement:      if (false) {

Finally, remove the function call “()” and “[]” and modify the function call statement:

Original statement:        [][“constructor”][“constructor”](setIntervalInfinity)();

Modified statement:      tempA = [“constructor”][“constructor”](setIntervalInfinity);

   alert(tempA);

b1_10

Save this modified script into the same sample. Running the sample again now gives us three alert pop-ups. The first two are the same as before. The third pop-up contains the final malicious iframe and URL that redirects the user.

b1_11

Copy and clean up the script:

b1_12

We can now easily see the document.write function call with iframe and URL.

 

Conclusion

With this simple three-step hack, anyone can easily analyze any Darkleech-injected obfuscated scripts to find the redirecting URLs. With the URLs, we can see which exploit kit landing page the script redirects to. Usually, these URLs are active for only a very short time.

Leave a Comment

Similar articles