Thursday, January 30, 2014

..And another "detonating" method of CookieBomb 2.0 - Part 2

Background

On the previous 1st part, I explained the first decoding of the new design in CookieBomb (version 2) threat with the easy decoding (read: "Detonating") for novices to get the quick URL redirection reference of the next infection. The access of the analysis is in here -->>[MMD-BLOG]

New Design of CookieBomb v2 in words..

The new design of the CookieBomb implemented two combination of cookie cushion, the first cushion of cookie forwarding condition and checking was performed and upon success the victim will be redirected to the NEXT cushion of cookie checking scheme: which is the well-known URL of [URL]/google.js in our caase. So in order to get the right path of infection on malware possibility researchers will need to have (read: to fool and fake) two cookies.
We are going to discuss in this post in details.
First Cushion of cookie condition (in javascript obfuscation ) is redirecting you to the remote Second Cushion of cookie condition (in javascript obfuscation), Each cusion has different condition check of cookies used and the Second Cushion of cookie (will be discussed below) is checking the REFERER of search engine list BEFORE redirecting you into the main TDS forwarder script (in this case is the file: g.php).

CookieBomb v2: Decoding & Analysis of Second Cushion

In this part I will decode the second cushion used by the CookieBomb injected code in some compromised sites that call to below URL: 

91.239.15.61/google.js

First is the PoC of fetching the file: 

--2014-01-30 02:43:56--  91.239.15.61/google.js
Connecting to 91.239.15.61:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2266 (2.2K) [application/javascript]
Saving to: 'google.js'
100%[==========================>] 2,266       --.-K/s   in 0s
2014-01-30 02:43:57 (36.3 MB/s) - 'google.js' saved [2266/2266]

And I re-pasting the obfuscation code below and the beautified code here-->>[PASTEBIN]

After our internal discussion with the MMD Germany decoder members (thank you for pointing out some unseen points), from the pattern of obfuscation seen, we came into conclusion of the usage of obfuscator tool(s) that had been used to encode the original code is like this one here --->>[LINK/GOOD SITE]

Moving along, after taking a look into the first obfuscation to find the hexadecimal sets that leads to ASCII characters, stored in the array of var _0xe2b8:

In the picture above I marked the first 13 strings only (sorry, is just too many..and I was too tired), if you replace it you'll get the below arrays: 

var _0xe2b8==
    ["referrer","google","yahoo","bing","yandex","baidu",
    "gigablast","soso","blekko","exalead","sogou","duckduckgo",
    "volunia","length","indexOf","location",
    "h00p://91.239.15.61/g.php","cookie"," ","=",";","substring","getDate","setDate","","; expires=","toUTCstring",
　　"referrerRedirectCookie", "do not redirect";
Replacing these array into below obfuscation code:

And you will get the below result:

Which making some senses that the access for the google.js in effect is needed a REFERER (point 1; noted, yes I know it misses an R), the var se means Search Engines..meanings the access that coming from this will be fit to the next process (point 2), and also (see point 3) the redirection access using javascript on window object with changing the location method.

"The Cookie scheme" of 2nd Cushion Parts

The set of cookie operation functions started from the grabbing logic of the cookie as per the decoded code below (the variable name was adjusted):

As you can see, the checks runs to some possibilities that cookie data was stored by the browsers and the grabbed data is stored in var c_value.

And it will be followed by calling the checking procedure of the cookies as per below code:

Noted that "Go" and "No go" flag is stated on "true" and "false" result on this function.. If the result is "false" then you can't go to the stated redirection, and the cookie for you to visit next time to be redirected will be made for you via the code below:

Debug the CookieBomb v2

Our team was testing the flow by the debugger to simulate some possibilities covered by this 2nd part of Cookie logic: 

// debug
03:39AM "cookie",17
03:39AM " ",18
03:40AM "=",19
03:40AM ";",20
03:40AM "substring",21
03:40AM "getDate",22
03:40AM "setDate",23
03:40AM "",24
03:40AM "; expires=",25
03:40AM "toUTCString",26
03:40AM "referrerRedirectCookie",27
03:40AM "do not redirect"];var from=document[Referer];var i;var "; expires=",28
03:40AM "toUTCString",29
03:40AM "referrerRedirectCookie",30
03:40AM "do not redirect"31
And it runs as per described in the log above if you don't have the ticket for infection (read: necessary cookies).

CookieBomb v2: Google.JS (2nd Cushion) in Graph

To make things easier to understand for the second cushion cookie check scheme in CookieBomb v2, I made the simple graph as per below, sorry for some note in JP that I made:

Regarding to the 91.239.15.61/g.php TDS redirector, it has the redirection function, and so far, as per posted in Part 1, still go to parking domain site. We are searching the server side code of this threat now, if you happen to see and can access the infected sites contains the file of (or like) g.php mentioned in this post, please ping me in the comment part.

The IP is dead now, is in NL, but a coincidence to know that is registered by Rusian living in Russia, Saint-Petersburg: 

inetnum:        91.239.15.0 - 91.239.15.255
netname:        VYMPELSTROY-NET
descr:          'VympelStroy ltd.'
country:        NL
org:            ORG-Vl112-RIPE
admin-c:        SAN188-RIPE
tech-c:         SAN188-RIPE
status:         ASSIGNED PI
mnt-by:         RIPE-NCC-END-MNT
mnt-lower:      RIPE-NCC-END-MNT
mnt-by:         MNT-VYMPELSTROY
mnt-routes:     MNT-VYMPELSTROY
mnt-routes:     ETICAPRIM-MNT
mnt-domains:    MNT-VYMPELSTROY
source:         RIPE # Filtered

organisation:   ORG-Vl112-RIPE
org-name:       VympelStroy ltd.
org-type:       OTHER
address:        'Russia, Saint-Petersburg', the 8th line of Vasilievkiy island, 79
mnt-ref:        MNT-VYMPELSTROY
mnt-by:         MNT-VYMPELSTROY
source:         RIPE # Filtered

person:         Sentsov Anatoliy Nikolaevich
address:        'Russia, Saint-Petersburg', the 8th line of Vasilievkiy island, 79
phone:          '+7 812 756 93 32'
nic-hdl:        SAN188-RIPE
mnt-by:         MNT-VYMPELSTROY
source:         RIPE # Filtered

How bad the infection so far?

is very very BAD!!!, attacking all over the web..

Epilogue

Hope this writing helping in understanding the evolution of the CookieBomb threat, blocking for the next URL/IP AFTER being redirected from CookieBomb first cushion will be a very good idea.

Some scribbles of our decoding text-->>[HERE]

Stay safe - #MalwareMustDie!

Posted by unixfreaxjp at