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!

Thursday, January 23, 2014

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

Note: 日本語版の調査方法を別途書いたのでアクセスはこちらーー>「BLOG.0DAY.JP」
Note: For the step by step easy decoding using wireshark & browser (w/many screenshots, ps: different victim site) go to Japanese writing here (use Google Translation pls)ーー>「BLOG.0DAY.JP」
Note: CookieBomb 2.0 is using double cookie cushions, this post we decoded 1st cushion and quick decoding to "trigger" the redir URL only, the second cushion decoding notes and analysis report is in here -->>[Part 2]

Spoiler: The tweet of the front obfuscation design of CookieBomb 2.0:

Background

My college in local security community visited and dare me to check on an obfuscation he can not judge what malicious category the case is. Since I am in the health treatment for a recovery and he is so nice to visit, so I accepted the challenge and helping him out with it, under condition to share this knowledge to the world :-)

The case is a local school's web site that is suffering by a malicious code injection. It looks like a CookieBomb case, and it has been a while that I didn't crack one of the recent codes and this one looks different. The case is interesting, you can fetch the sample before we clean it up by the below simple wget (read: do not use your browser) method:

$ wget h00p://www.nose-highschool.ed.jp/
--2014-01-23 12:10:54--  h00p://www.nose-highschool.ed.jp/
Resolving www.nose-highschool.ed.jp (www.nose-highschool.ed.jp)... 210.152.144.19
Connecting to www.nose-highschool.ed.jp (www.nose-highschool.ed.jp)|210.152.144.19|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html'
    [ <=> ] 20,017      --.-K/s   in 0.07s
2014-01-23 12:10:54 (276 KB/s) - 'index.html' saved [20017]

CookieBomb v2: First Cushion Injected Code

The index.html on this site is obviously injected by the code below, right in the middle of the home page itself:

By the traces of the format used I can guess automation injection tool was used.

Decoding

It was not difficult to decode the garbled codes above (by using your favorite javascript deobfuscating flavor) to get the below redirection based on cookie-as-trigger concept (read: CookieBomb). Let's see the result below. I actually expect an IFRAME injection or similar redirection, instead we are seeing a full HTML page code of an injection (see the red color), with the link to 91.239.15.61/google.js (see another red color).

You will see two parts of JS function (yellow color parts) which was meant to be used to read a cookie (if exists), or to make you have the cookie as a "ticket" to detonate "something bad" that will follow all these.

I just release a decoding flow for this first cushion script of CookieBomb in the pastebin so you can see its step by step works, the access is here-->>[PASTEBIN]. I wrote it as novice as possible, hopefully the IR fols can follow and understand it. It is important NOT to depend 100% in automation for the threat like this since there are many evading method that can be used in javascript layer to fool the scanner.

Next. Let's snip into the google.js. My tip for handling cookie bomb cases is, do not get too hasty on decoding, just see where the things are flowing first. Accordingly I just fetch the url written in the code, which having some ideas in my head, so let's see which idea is correct:

// fetching the h00p://91.239.15.61/google.js
--2014-01-23 12:26:34--  h00p://91.239.15.61/google.js
Connecting to 91.239.15.61:80... connected.
 :
GET /google.js HTTP/1.1
Host: 91.239.15.61
HTTP request sent, awaiting response...
 :
HTTP/1.1 200 OK
Date: Thu, 23 Jan 2014 03:26:34 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Sat, 04 Jan 2014 20:39:44 GMT
ETag: "60ffc-8da-4ef2b06d38400"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 728
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/javascript
  :
200 OK
Length: 728 [application/javascript]
Saving to: 'google.js'
100%[=========================>] 728         --.-K/s   in 0s
2014-01-23 12:26:34 (13.4 MB/s) - 'google.js' saved [728/728]
Yes, I saved the file, and it contains another mistery as per snipped code below:

CookieBomb v2: Snippet of Second Cushion

I don't like the dirty code, so let's beautify it here -->>[PASTEBIN]
Following I will make explanation how to easy decoding this by using a notepad :-))

Quick "Detonating" Second Cushion Code (Not Decoding)

As per title in this section, this is a quicky, for the impatient friends who soon want to know where the next cushion is. So I will share you "a quicky" trick.
First, see the obfuscation data part is (as per below), all you must do is leave it as per it is, don't merge it, don't change anything, because instead of cracking the code your changes might destroy the obfuscation chain, and we really don't need to touch this part to solve this obfuscation:

You'll see also the three functions of getCookie, setCookie and checkCookie. The moronz behind this injection tools is making a useless effort by putting these functions to make us (read: good guys) wasting our time, so just ignore these functions too and let them be.

For the quick crack, the part that you should pay attention is this part only:

The red and orange marked parts are explaining a condition that should be passed (read: bypassed.) to detonate the decoding generator in line 174, well, to be specific the red part is obfuscating related condition and the orange one is a condition IF you have the desired cookie in your browser. So, by understanding this, you can detonate to figure the destination of forwarded URL of this new CookieBomb by eliminating those two silly functions and go straight to the value generated by deobfuscation generator logic, as the I coded below, just run it :-)

The URL that is being used to redirect the victim that is having a "ticket" (read: Cookie) for infection is marked in the red color.

Confirming the "Detonating" Result

Let's see IF the deobfuscation is correct, by accessing the URL..

--2014-01-23 13:02:31--  h00p://91.239.15.61/g.php
Connecting to 91.239.15.61:80... connected.
  :
GET /g.php HTTP/1.1
Referer: h00p://www.nose-highschool.ed.jp/
Host: 91.239.15.61
HTTP request sent, awaiting response...
  :
HTTP/1.1 302 Found
Location: h00p://goo.gl/Yun4bN
Date: Thu, 23 Jan 2014 04:02:32 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-4ubuntu2.4
Vary: Accept-Encoding
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Yep, the PHP is there alright. And..(why not?) try to trigger the "bomb" of this lame site w/the MMD's lame cookies ;-))
* About to connect() to 91.239.15.61 port 80 (#0)
*   Trying 91.239.15.61...
* Adding handle: conn: 0x28894100
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x28894100) send_pipe: 1, recv_pipe: 0
* Connected to 91.239.15.61 (91.239.15.61) port 80 (#0)
> GET /g.php HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
> Host: 91.239.15.61
> Accept: */*
> Referer: h00p://www.nose-highschool.ed.jp/
> Cookie: visited_uq=55;expires=Thu, 23 Jan 2014 14:40:07 GMT; path=/
>
< HTTP/1.1 302 Found
< Date: Thu, 23 Jan 2014 06:56:30 GMT
* Server Apache/2.2.22 (Ubuntu) is not blacklisted
< Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.4.9-4ubuntu2.4
< Location: http://goo.gl/Yun4bN
< Vary: Accept-Encoding
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
Yes, both efforts above were 302 redirected to some sites that is having some possibilities of redirection (read: TDS), with noted the short url used.
Meaning the CookieBomb PHP script (the server side tool) is in there and serving. If anyone can grab the data please let me know, I bet there is a new model of ESD.PHP used.

Infection Sources

The story is not end here, friends, you must feed the cookie request to this PHP file with the right parameter , use my previous writing here -->>[MMD Blog] and here -->>[MMD Blog] as guide to figure where this infection is heading :D - believe me, is not that difficult!
And that is for you to dig further, since I have to rest, so good luck! :-)

The injected code is having redirection to this IP (which is being utilized for CookieBomb PHP scripts):

91.239.15.61
And the below URL are definitely bad:
91.239.15.61/g.php
91.239.15.61/google.js
And you can guess the location of this IP :-)
The above information is the subject to clean up.

Next Post: Decoding of the Second Cushion Code

The full analysis of the second cushion of cookie cushion used in the google.js can be read here-->>[Part 2]
I am in purpose in separating the first cushion (this post) and second cushion in two series since the checking logic are actually very different, the connection is only at the infection traffic passed from the first to the second cushion. The second cushion will not reply on one script in the google.js but will use the TDS script that can be implemented in the same server as google.js itself OR other host < VERY important point. SO, this means that CookieBomb can be used to make infection chain jump around to one host into another in chains before really hit into "real stuff".

How to search CookieBomb v2

#MalwareMustDie!

Friday, January 3, 2014

MMD-0014-2014 - New Locker: Prison Locker (aka: Power Locker ..or whatever those bad actor call it)

Background

Malware bad actors just keep on coding and developing new threats with the stupid dream to get rich soon in their stupid heads. It's a serious moral corruption generated by whatever background they are raised, but that's a fact that is going on out there. Here is the case of those fact, but this one is escalated into quite harmful in threat level.. if released.. this will be more headache for researchers, industry and LEA (law enforcement agencies), so after internal meeting we decided to disclose it.

I suggest you pay attention for this disclosure. This post is a pure intelligence matter, we provided in comprehensive fact as evidence of crime, following by many of screenshots (with dates and some with URL) for your checking and comparison purpose.

As per previously post also mentioned, we (read: MalwareMustDie,NPO - Anti CyberCrime & Malware Research Group) work not only in defensive way but being active to spot the threat as early stage as possible, and inviting thus support law enforcement & CERT folks to initiate the crime case upon it.

Message to the Law Enforcement fellow is, all presented evidence in this post can be confirmed and checked by your side too, please don't let this malware spotted in the wild since judging by the current materials, boosted by some interest from the crooks that communicating each other in the bad bad forums, serious damage will be occurred for sure.
The idea to verdict of coding malware and an attempt to sell it (by himself) as business scheme (see the panels part) is already a serious crime that can be used as a base to act.

The promotion of Prison Locker

Started from the hacker forums we spotted the release attempt messages below:

Following by the next message:

The better snapshot is below:

Finally the public attraction in paste bin (click to link to the paste):

This is where the name of Power Locker emerged.

The text of the "release note(? whatever they call it)" is interesting:

Hello everyone,

A while ago (when I first joined this forum) I made a thread about my Prison Locker malware I am developing for use. I would like to let everyone know about the substantial progress that has been made in its development. I will list new and existing features here.
Uses 5+ anti VM and debugger methods to deter analysis.
Encrypts all files (except for system files and .exe s) on hard drive(s) and shared drive(s) with AES encryption. Each file has its own AES key.
Encrypts each AES key with RSA-2048, making the encryption practically uncrackable.
Startup (obviously).
Single file dropped and is put in hidden folder.
Once files are encrypted, locker is spawned.

Features of locker module:
Spawns a new desktop and displays window there.
One thread checks to make sure user is in the right desktop every few miliseconds, if the user is in another desktop it is immediately switched back
Windows and Escape key are disabled
Multiple Window s processes (including regedit.exe, taskmgr.exe, cmd.exe, etc) are disabled, rendering Ctrl+Alt+Del useless
Accepts BTC e-Vouchers, uKash, Paysafe (this list is not set, options can be changed)
Payment codes entered undergo testing to make fake codes extremely hard to enter (this also is not set, I may chance how this work)

All that is left is the completion of the GUI (I have hired someone to do this, they are working right now). Once the GUI is completed, I just have to tie together some ends (linking the input of the GUI to my program to test payment codes is really only thing left). Also I will need to debug/test on multiple OS s/fix any final issues.

This is a major improvement from my previous features, as encryption makes the bot much more valuable. Even if the user is able to somehow get out of locker screen, files will still be encrypted with practically unbreakable encryption. It has been shown that cryptolockers are very successful because without paying, the user has no chance of recovering files (so paying is in their best interest). I have a list of 3 people who have already expressed interest in the locker, and they along with another 2 people (so the first 5, of which 3 are already filled) will receive a bin at a discounted price of $50. The regular price will be $100. If you would like to express interest in buying, please either PM me or contact my jabber: gyx@jodo.im . Messaging me on Jabber will get a response much quicker (I have other forums to pay attention to than HF obviously). I will update this thread with developments in the future. S/O to betamonkey who I respect very much.
And has good responses from fellow crooks :-)

And in another forum also started some post of tutorials/manual:


For all good people's conveniences, the text grabbed:

URL: h00p://hackhound.org/forums/topic/3628-lock-a-window-in-place-tutorial/
 
Lock a Window In Place Tutorial

Started By gyx , Dec 16 2013 04:52 AM

gyx
Newbie
Members

Reputation: 0
Neutral
3 posts

Posted 16 December 2013 - 04:52 AM

Hello,

As my first tutorial here I would like to bring something I think that a lot of people can benefit from and may enjoy learning about. I will be providing a tutorial on how to lock a window in place using some basic methods, I have chosen this because I am in the final stages of developing a crypto locker which locks a window in place along with encrypting files. If you are interested in buying message me on jabber: gyx@jodo.im. Anyways, we will be using a couple of methods to lock our window in place. Keep in mind that all of this is being done from userland.

1. Disable a couple of important keys using a very simple SetWindowsHookEx.

Please Login or Register to see this Hidden Content

As you can probably tell by reading the functions, we disable both the right and left windows key, along with the escape key. This prevents the user from pressing the windows key to bring up the start menu (this actually doesnt matter, as we kill explorer.exe later anyways), or using the escape key. This is _not_ one of the most important parts of our locking code.

2. This next part is extremely handy, and BTW hooking the keys should be done after this next step or else it may not work properly. Basically, we will be creating a new desktop using the API CreateDesktop and then we will dedicate a thread to making sure we are in this desktop. By switching desktops we set up a fresh environment to work in with no other processes (other than those that Windows is always running of course). So Alt+Tab is of no use (this is used to toggle through open applications). The code for this is quite simple, and consists of two parts. The first is putting us in the right desktop if we are not there, and the second is running a thread to maintain this position. Here is some code:

Please Login or Register to see this Hidden Content

So we are first checking to make sure we are not for some odd reason already in our desktop, and then creating a desktop to switch to. We switch to it, and then start our thread to stay there. The thread simply checks every few miliseconds to see what desktop we are in, and switches to our "lockerdesktop" if we are not there. Very useful part.

3. I wont share the exact code for the next method because it takes up quite a bit of room and is pretty simple. But I will provide step by step instructions on what needs to be done. Basically we will be closing explorer.exe (to close the dock mostly) and then checking for and terminating taskmgr.exe, cmd.exe, regedit.exe, and any others of your choice. The function that will be a thread should:

Close explorer.exe using the command "taskkill /IM explorer.exe /F" using whatever API of your choice to execute a Windows command.
Enter a while(1) loop with maybe a Sleep(15) at the beginning. The loop should do the following over and over:
Enumerate all processes open (this is computationally heavy thats why I recommend a Sleep(15)), google how to do this if you dont know how ;)
Get the name of each process by using a simple for loop after opening the process (you should find some code if you google, hint: GetModuleBaseName for getting the process name). 
Compare the name to your list of applications to kill (strcmp(), it returns 0 if they are identical), and execute the following command if they are identical:
"taskkill /IM processname.exe /F". You cant close a Windows process such as taskmgr using a normal API call or even a normal taskkill /IM call, the easiest way to do this (that I have found) is using the taskkill command with /F (force) on there. You can again use whatever method for executing a Windows command that you choose, I use WinExec with the SW_HIDE parameter to prevent a cmd prompt from being displayed.
 
One thing I have noticed about this part is that you may need to play with the number of and locations of Sleep() commands, or else a bunch of cmd prompts may pop up over and over. Personal hint: split this up into two functions, one the enumerate all procs and one to get the name and terminate if it is on the list.

So in review, the sequence of steps for our basic locking mechanism should be:

Switch desktops and maintain our position there.
Lock the keys.
Kill explorer and moniter for our list of "bad" processes, kill them if they exist.
Create our window to display, it should be fullscreen (you can find how to do this with a quick google). This can go anywhere after switching desktops really, doesnt matter too much.
 
Well thats all I plan to put in this tutorial as I dont want to give out all my methods or spoonfeed you. But I hope you enjoy this and learned a little something. :)

Back to top

And then also some Q & A comment from the coder:

Another one:
Oh BTW please don't tell us that this guy is innocent..

This is the pastebin link for the DOX info, shared in 24H only-->>[PASTEBIN]
God bless the braves, thank you crusader!

Another attempt/vector for "other" threat post back then was also detected by the same bad actor:

Well, it looks like he was investigating some flaw in browser too < to be noted by internet browser's vendors.

The identification

The ID is obvious. Which all are lead you to the bad actor's ID below: (picture?)

It wasn't that hard to confirm the bad actor's (the malware coder's) ID, our team filled Google with its cache now (hope is enough) for the PoC:
Like this..)

..and this:

A bit shocky part is, "our suspect" was pretending (or) to be a researcher, see the ICQ number of the blog below for the comparison:

Can you figure which account he is owning in twitter? :-) the #w00tw00t attack is the clue :D
Following, the account he owned (twitter):

This person has a lot to explain and look forward to hear it. Summarizing of information centred and linked from that ICQ number is: (picture?)

Tweet Analysis shows:


OK, we leave it to the law enforcement to do the rest, but I suggest you all mark this IDs, friends. And I don't believe in coincidence. Additionally in the bottom of this post there is the ID of ICQ Account available-->>[LINK]

Commercial aspect of the malware - The panels

This is the panels screenshot promoted by the bad actor himself,
these were two nice panels to be nuked down :-)

Obviously our crusader also spotted same threat too, I should notice this sooner :-)

Pardon for the correction

The shares

All of the materials involved by this threat ail be shared offline to our partners & friends via secure vetted interface. Updates and mass investigation level is going to be released in our forum. Some data will be changed upon investigation progress.

(NEW) Recent Updates Information

1. We still monitor the case's progress and they realized that we extract the correct information. We also found that the plan to sell the malware (upon released) is still on schedule. Furthermore, the "marketer" actor of this malware product was responding to this blog disclosure as per pasted below:

We urge law enforcement to start the investigation and all of the materials posted in this blog is formed to be used as crime evidence.

2. The closest information to the identification of the bad actor via public access is:

3. The marketer "Prophyry" (lives in Michigan, US) burped a doubtful information:

4. Clarification & Static Analysis of Sample 17FB3E3B3FD3CA7FB9E5F59BBF2CF234

A clarification

For the clarification of some dilemma that may occurred we added this section;
We were not releasing information of the any sample or source codes we secured since there was no infection in the wild that can be described as the activity of malware infection, and there was NO RELEASE / FINAL version spotted at the time this blog's post was first written. What we spotted was the development effort and result of the software project that was designed to perform malicious ransom action by actors described in the above section in this post in details. As for the evidence we managed to secure some, and one of the sample was spotted in December 2013, with the hash of 17FB3E3B3FD3CA7FB9E5F59BBF2CF234, found & reported by our group's supporter during the surveillance session of this threat, further information can not be exposed due to the nature of security, intelligence and supporting to the work of our friends in law enforcement.
Our disclosure is to draw attention of the law to make swift action accordingly in order the disrupt the bad actor's plan to release the product in time.

Since there is a progress in public that may doubt the dangerous facts of the threat, we are releasing the static binary analysis of sample 17FB3E3B3FD3CA7FB9E5F59BBF2CF234 mentioned above. I used to analyze the sample in almost every cases posted in this blog, but in this case, to make the pure objectivity of the analysis result, I invited the expert of static binary analysis, the author of Windows PE binary analysis tool "PeStudio", Mr. Marc Ochsenmeier from Germany, to investigate the binary with the static analysis. as per below details.

Static Analysis

The binary was statically analyzed, with the method as per quoted below:
The goal of PeStudio is to detect anomalies, suspicious hints and other particularities of Windows Portable Executables and provide "Indicators" about the level of trust one can have about the image analyzed. The ultimate goal of PeStudio is to give a true/false about if an image is malware or not. The complete process is static. The image is never started. No attempt of any dynamic and/or runtime decryptor is made. No Reverse Engineering or code analysis is done.
Report of Marc's static binary analysis in the PDF can be viewed here -->>[Report in PDF]
Report Snapshot: (small size only)

Below are several screenshots of PeStudio tools GUI describing the malicious points explained in the report made by Marc, and if I may comment, PeStudio is a very useful tool (most of MalwareMustDie members are supporting the development and using it) to perform Windows PE static binary analysis, that can breakdown the details of the binary details to be easily reviewed and learned. A tool that I can recommend for malware research, here is the access-->>[HERE]

Malicious Sign Indicators:

Debug Information:

Imported Symbols:

Unclassified Strings:

By seeing thee above static analysis you maybe can tell whether the "sample" of PowerLocker is actually exist or not. The malware was not distributed widely because many of good people gather with us and making effort to interfere and disturb the bad actor's work, these gentlemen were actually spending their private time, taking many risk by doing hard work confronting the bad people while most of us were in New Year's holiday and celebrating.

Additional Analysis

PandaLabs Blog is just releasing a nice analysis of the threat in their blog here-->[PandaLabs]
Thank you very much for the link to our post! Greets to friends in Panda Labs for a good post: @Luis_Corrons @Panda_Security

We really hope that the coder and the marketer individuals who are supporting this malware's development can be stopped by law enforcement by an arrest, since we worry that they are still eager to release it as per planned.

Stay safe, friends. MalwareMustDie!

Thursday, January 2, 2014

MMD-0013-2014 - "Shadow Logger" - .NET's FUD Keylogger

Background

Our team found this threat and we decided to openly raise awareness about it. Is a Keylogger with bragging of being Fully Undetected (FUD), the sad part is, it is.. which causing the background of this disclosure. It crashed my IDA Pro during opening the bins, gotta break 2 of my RATs to run & analyze it, yes it is infected and a bad stuff that should be eliminated on the first attempt.

As per previously post also mentioned, we (read: MalwareMustDie,NPO - Anti CyberCrime & Malware Research Group) work not only in defensive way but being active to spot the threat as early stage as possible, and inviting thus support law enforcement & CERT folks to initiate the crime case upon it.

Source of the threat

During the analysis process of a new malware sample of "logger.exe" binary we received from a therat report, we figured further that the sample is the Shadow Logger, the malware keylogger binary. Checking deeper in some forums we found more details and the " sales product campaign banner" of this malware:

The longer information of the campaign info itself, which included the malicious purpose in details:



The Bad Actor's ID:

The message goes in pair with the account that promoting it. Below is the account that responsible for the threat (after while we also "suspect" that he's the coder) which is using the Skype ID of "allan.ridha" and living in Sweden:
His confession of his own Skype ID is as per below:


He is recently back to promote his malware keylogger (Shadow Logger):


He confessed his own name here:

*) Click the image above to be redirected to the forum's google cache URL to confirm.

Trails of IP address is showing where he is: (he confessed it himself with his photo :-) )
Tracked into Sweden..

Additionally he even made a TUTORIAL to build keylogger VB malware code in HIS youtube account-->>HERE
The video in 4:23 contains his email address: allan.ridha@gmail.com
PoC picture:

TO L.E.OFFICERS: URGENT: PLEASE DOWNLOAD THIS VIDEO BEFORE THE ACTOR ERASED IT FROM YOUTUBE!!

Following his M.O. in using SNS we can search his Facebook and Skype account easily too.
Here's his facebook--> https://www.facebook.com/allan.ridha contains his pictures:

In his facebook contents of timeline he is writing in swedish. so it's a proof supporting the fact that he's in Sweden.
Another proof that is showing he is living in Sweden is the example of picture the demonstration picture he is using for his keylogger which leavingthe trails of language he's living:
The account appeared in Skype Directory is showing same handle name used in promoting the Shadow Logger in some forums:
Be free to check by yourself all of the fact above, and please don't tell us that he is innocent. Any effort to build a malware, even by SKIDS, has to be terminated as soon as possible, otherwise you won't know what he will sell and code when he is 40 year old.
Please mark this bad actor and we hope this post is giving enough verdict to LE (Law enforcement), as coder and making effort to sell/promote keylogger malware, to open a legal case against him in LE side.

Malware Sample & FUD PoC

This is the PoC of FUD, /* click to link to VT page */

The detection today is showing the malicious result ratio:

Antivirus       Result                      Update  
----------------------------------------------------
AVG             PSW.MSIL.KNO              20140107
Ad-Aware        Trojan.GenericKD.1485223    20140108
AntiVir         TR/Dropper.MSIL.21049       20140107
Avast           Win32:Malware-gen           20140108
Baidu           Trojan.MSIL.Agent.aQh       20131213
BitDefender     Trojan.GenericKD.1485223    20140108
Bkav            W32.DropperArtemis.Trojan   20140108
DrWeb           BackDoor.Comet.731          20140108
ESET-NOD32      variant of MSIL/Kryptik.QZ  20140108
Emsisoft        Trojan.GenericKD.1485223(B) 20140108
F-Secure        Trojan.GenericKD.1485223    20140108
Fortinet        W32/Agent.DFZR!tr           20140108
GData           Trojan.GenericKD.1485223    20140108
Ikarus          Trojan-PWS.MSIL             20140108
K7AntiVirus     Trojan (0001140e1)          20140107
K7GW            Trojan (0001140e1)          20140107
Kaspersky       Trojan.MSIL.Agent.dfzr      20140108
Kingsoft        Win32.Troj.Agent.xh(kcloud) 20130829
Malwarebytes    Trojan.MSIL                 20140108
McAfee          RDN/Generic.dx!cwd          20140108
McAfee-GW-Ed.   Artemis!9E5848B5CE98        20140108
eScan           Trojan.GenericKD.1485223    20140108
Panda           Trj/CI.A                    20140107
Sophos          Mal/Generic-S               20140108
Symantec        Trojan Horse                20140107
TrendMicro      TROJ_GEN.R0CBC0EA814        20140108
TrendMicroHouse TROJ_GEN.R0CBC0EA814        20140108
nProtect        Trojan.GenericKD.1485223    20140108

Below is the sample to share w/usual password (click the pic)

Malware Binary Analysis (Verdict)

Here's the PE:

Some encryption..

Some PE strings-->>[PASTEBIN]

It'll generate this popup:

And here is the full sysinternals record of processes executed by the sample and you can find some traces of the suspicious behaviors that usually spotted in capturing process -->>[PASTEBIN]
Below is the stacks per modules loaded:

mscorwks.dll!CreateApplicationContext+0x6d4
mscorwks.dll!CorExeMain+0xa54
mscorwks.dll!ClrCreateManagedInstance+0x8aea
KERNEL32.dll!GetModuleFileNameA+0x1b4

ntoskrnl.exe!ExReleaseResourceLite+0x1a3
ntoskrnl.exe!PsGetContextThread+0x329
ntoskrnl.exe!FsRtlInitializeFileLock+0x83f
ntoskrnl.exe!FsRtlInitializeFileLock+0x87e
win32k.sys+0x2f52
win32k.sys+0x3758
win32k.sys+0x3775
ntdll.dll!KiFastSystemCallRet
USER32.dll!GetCursorFrameInfo+0x1cc
USER32.dll!SoftModalMessageBox+0x677
USER32.dll!MessageBoxIndirectA+0x23a
USER32.dll!MessageBoxTimeoutW+0x7a
USER32.dll!MessageBoxExW+0x1b
USER32.dll!MessageBoxW+0x45
System.Windows.Forms.ni.dll+0x2b5cd3
System.Windows.Forms.ni.dll+0x2b58e8

ntoskrnl.exe!ExReleaseResourceLite+0x1a3
ntoskrnl.exe!PsGetContextThread+0x329
ntoskrnl.exe!FsRtlInitializeFileLock+0x83f
hal.dll+0x2c35
mscorwks.dll!CorExeMain+0x17b3
mscorwks.dll!InitializeFusion+0x118ab
mscorwks.dll!InitializeFusion+0xf65b
mscorwks.dll!InitializeFusion+0xfa44
mscorwks.dll!InitializeFusion+0xf855
mscorwks.dll!InitializeFusion+0xfcba
mscorwks.dll!GetCLRFunction+0xe4b2
mscorwks.dll!CorLaunchApplication+0x24aa9
mscorwks.dll!NGenCreateNGenWorker+0x2f12f
mscorwks.dll!InstallCustomModule+0x8697
mscorwks.dll!InstallCustomModule+0x853d
mscorlib.ni.dll+0x2a31b3
The process after restarted showing PoC autostart:

The Autostart trace:
\REGISTRY\USER\S-1-5-21-1214440339-926492609-1644491937-1003\
Software\Microsoft\Windows\CurrentVersion\Run
With the below command line (cmd):
"C:\WINDOWS\system32\cmd.exe" /c reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" 
/f /v "gens" /t REG_SZ /d "C:\Documents and Settings\Administrator\Local 
Settings\Temp\breakfast.exe"
The .NET components in memory:

Some registry calls dumped from malware's memory area-->>[PASTEBIN]
The memory was mapped by these libraries:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\culture.dll 
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll 
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorrc.dll 
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll 
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscoreei.dll 
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\MSVCR80.dll 
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll 
C:\WINDOWS\WindowsShell.Manifest 
C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\sortkey.nlp 
C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\sorttbls.nlp 
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Drawing\c91f68c2920882e02aec00eeabb6b415\System.Drawing.ni.dll 
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\0c70e5d82578be2f6c0dde89182261c5\System.Windows.Forms.ni.dll 
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System\36dbfcf62e07d819b3de533898868ecf\System.ni.dll 
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\642534209e13d16e93b80a628742d2ee\mscorlib.ni.dll 
C:\WINDOWS\system32\CLBCATQ.DLL 
C:\WINDOWS\system32\COMRes.dll 
C:\WINDOWS\system32\MSCTF.dll 
C:\WINDOWS\system32\RichEd20.dll 
C:\WINDOWS\system32\SETUPAPI.dll 
C:\WINDOWS\system32\WININET.dll 
C:\WINDOWS\system32\cmd.exe 
C:\WINDOWS\system32\comctl32.dll 
C:\WINDOWS\system32\imm32.dll 
C:\WINDOWS\system32\l_intl.nls 
C:\WINDOWS\system32\mscoree.dll 
C:\WINDOWS\system32\rpcss.dll 
C:\WINDOWS\system32\shdocvw.dll 
C:\WINDOWS\system32\shell32.dll 
C:\WINDOWS\system32\urlmon.dll 
C:\Windows\AppPatch\sysmain.sdb
Additionally the registry change values:
HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{a1094da8-30a0-11dd-817b-806d6172696f}\ New Value: [ Drive ]
HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{a1094daa-30a0-11dd-817b-806d6172696f}\ New Value: [ Drive ]
HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders New Value: [ C:\Documents and Settings\Administrator\Application Data ]
HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders New Value: [ C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files ]
HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders New Value: [ C:\Documents and Settings\Administrator\Cookies ]
HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ New Value: [ 1 ]
HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ New Value: [ 1 ]
HKU\S-1-5-21-842925246-1425521274-308236825-500\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ New Value: [ 1 ]
HKU\​S-1-5-21-842925246-1425521274-308236825-500\​Software\​Microsoft\​Windows\​CurrentVersion\​Run New Value: [ gens = C:\​Documents and Settings\​Administrator\​Local Settings\​Temp\​breakfast.exe ]

I will update upon fixing my RAT, the data above are ones that I could recover so far. Be free to make your good analysis of this keylogger FUD.
Mr. Marc Ochsenmeier (@ochsenmeier/twitter), the author of binary analysis PEStudio, ‏was helping us in checking Shadow Logger (w/thank's) in PEStudio as per below tweets:

The Malware's Source Code - Crime Evidence

After digging a little further we "secured" the source code of this malware, this source code is passed to the AV industry, well-known malware researchers and law enforcement only.


Download -->>[HERE]
Mirror Download -->>[HERE]
read instruction in the video to unlock.

Additional:

Thank's to our crusader for very good detection & investigation!

#MalwareMustDie!