Monday, July 31, 2017

TOPransom: From eMail Attachment to Powning the Attacker's Database

Hi folks, today I want to share a quick but intensive experience in fighting cybercrime. I wish you would appreciate the entire process from getting an email attachment to powning the ransom server trying to stop the infection and to alert everybody about the found threats. As a second step I would try to identify the attacker in order to give additional information to law enforcements, those actions would not be published. 

But, let's start by having a little bit of context:

During the past few days a colleague of mine (MarcoT.) gave me an interesting eMail attachment called: 71878378709_708463.zip (sha256:fdd1da3bdd8f37dcc04353913b5b580dadda94ba).
By unzipping the attachment, it was interesting to see a single .vbs file. By double clicking a .vbs file the victim would run it through microsoft wscript.exe which fires up the infection process. The eMail belongs to a more complex spamming set spread over USA and coming few days ago to Europe as well.

The visual basic script was obfuscated, as you may appreciate from the following image, but the used obfuscation technique was quite weak to reverse. In fact only one round of packing was adopted and after few substitutions "clear text strings" were observable.

Obfuscated Dropper

Interesting techniques were introduced in this dropper. First of all a lot of junk code (apparently good code) was added in order to make reverse engineering process much harder. Very interesting the choice of such a code apparently taken from real droppers but not linked to the analized one. Another interesting adopted technique was on the "User-Agent" settings, which happened to be the key-factor to download the real payload.  The dropper per-se is not interesting anymore. It basically uses a romantic WScript.Shell to execute a 'MZ' file once downloaded from compromised websites (IoC later on). The Dropped file is returned directly into the HTTP response body and saved with a static name in temporary user folder: saToHxy.exe. The dropper file renamed VB objects and VB functions to make everything a little harder.

Saving Dropper into user temporary file with static name

As today the dropping URLs are the following ones:
  • castillodepalazuelos.es/rf734rgf?
  • 2010.sggt-wh.de/rf734rgf?
  • actt.gr/rf734rgf?
As mentioned a romantic Shell.Run would execute the dropped payload. The Payload (sha356:6a51d0cd9ea189babad031864217ddd3a7ddba84) looks like a one-stager payload. No heavy encryption nor multi staging delivery is involved, clear and intuitive user functions within enabled debugging headers.


No Packing found

Firing up IDA and reversing the sample showed up small encoded payload through XOR and some anti debugging tricks such as the timing control and performance monitoring as follows:


Anti-Debugging tricks: Timing and Performante control
Following on the analysis it becomes clear the spread use of Secure Handler Exception Chain exploiting technique. By triggering exceptions the attacker calls modified exception handler functions able to decode the payload and to allocate it directly on the new memory pages, ending up on "call eax" section. The following image shows the decoding loop.

Decoding Loop on 0x3001220
Following a piece of decoded memory area (configuration file), decoded by 0x03001220.

Decoded Memory Area
Dynamic Analysis took out the evidence of a Ransomware payload. In fact following on the decoded payload by getting far on memory site the analyst could observe the ransom HTML page (next image). I would prefer to show out a rendered "ransom request page" rather than a junk of hexadecimal bytes. (sha256: cdb3fef976270ab235db623d6a4a97ea93c41dd1) The ransom page looks looks like the following image.

Ransom Request Rendered File
I will call this Ransomware the "TOPransom" since the funny and evident mistake the attacker made in writing the ransom request file in where he suggested to download the TOP Browser rather then the TOR Browser :D (LOL). The TOPransom encrypts files and changes the file extensions with a alphanumeric extension, usually made of 3 characters (why "usually" ? Because looking at the attacker's db it looks like that, but I didn't find evidence on that). The modified extension is used as a hidden parameter in the ransom page. The following image shows some hidden features used by the attacker to bring informations to the control server.

POST request to buy the decrypter
Particularly interesting (at least in my persona point o view) the hidden input type called "FB" which looks like piggy backing two informations to the command and control (ransom server) such as: the extension and some hexadecimal content included in a crafted tag called "pre". By clicking on "Yes I want to buy" the victim POST such a data and are prompted to the following page asking for 0.18 BTC in order to get files back.

Request for ransom
 The FB hidden value "made me curious". By changing the first value (the one before the statement "pre") you would appreciate different BTC wallets with different asking prices. The following image shows the different results.

Request for ransom 2

This makes the system vulnerable to "balance enumeration" and to "denial of resources". In fact by enumerating the attacker wallet space I will perform a duplice action: if the wallet exists I'll take its balance, if the wallet does not exists the backend will create a new wallet, filling up the attacker reserved space for wallet creation. This action could block the new wallet creation ergo new infections.  So lets' write a simple dirty python script to force new wallet creation and money mapping.


Forcing New Wallets to limitate further infections (please do not consider this script as production ready script. Do not consider it as best implementation for such a goal)


Following on the analysis by playing a little bit further with that parameter (FB) I figured out it was vulnerable to SQL Injection. What a nice surprise !! The vulnerable parameter was the crafted tag called "pre" which vulnerable to code injection, which triggered SQLinjections.

SQLi on C&C server !

So let's try to pown the Attacker ! As first sight you may observe a MySQL error with not a latin characters. Google Translator says it is a Russian language ! Now we know that the attacker belongs, with high probability, to the Russian community. By investigating a little bit harder on the DB, only TOR availability and super slow, I found the botids and the relatives tasks. Please have a look to incremental ids and try to immagine how big was that network.

Bot Ids and relative locations

Another interesting topic was to investigate which were the system users(a.k.a the attackers). In other words the users of such a ransomware-as-a-service-platform" which happened to be the real attackers. Since It looks like a "Ransomware as a service" platform figuring out how many dollars the attackers were able to gain over time its my next goal. The following obfuscated image shows some of the found usernames, passwords (chipertext) and wallets the attackers used to gain profit.

Attackers Username, Passwords and Wallets
My attention ended up on that guy: god.true@xmpp.jp
That guy is related to the following private wallet: 1P3t56jg5RQSkFDWkDK3xBj9JPtXhSwc3N


As you might guess there are two main wallet types:
- Public wallets which store the victim's money. They are the public available wallets, everybody got infected must now them in order to pay the ransom.
- Private wallets which are the "real ones" belonging to attackers.  Private wallets got money from public wallet once reached the end of the attack. Platform charges are applied during that transaction.

Having the private wallet means to have the possibility to track down transactions history. Transactions history is a great source to figure out if that guy made more illegal activity over the past months. Following the go.true@xmpp.jp 's private wallet. We may observe interesting transactions as showed in the following image


Transaction From   1P3t56jg5RQSkFDWkDK3xBj9JPtXhSwc3N

That wallet which is DB-related to god.true@xmpp.jp, made huge amount of transactions back on 2017-04-23 and 2017-04-20 by moving out from its wallet 81,87 BTC harvested by many small and similar transactions! If we include the harvested BTC from this attack which currently have balance 13 BTC,  he or she is close to 100 BTC transactions. How about 2017-04 (do you remember any famous attack on that time ? :P) With high probability the attacker looks like abusing illegal activities (such as ransomware activities) more then once a time, this boy/girl -- with a high probability -- is a recurring attacker. By investigating a little bit more on that email address it's easy to find heavy relations between got.true@xmpp.jp and https://vlmi.su/ which is a Russian based Market Place where attackers buy and sell attacking tools, information and experiences.

After few more crafted SQL queries I was able to extract the "inst" talbe. Fields names are the following ones:

ID, IP, FB, OS, TIMED, TIMEIN. COUNTRY, BRWSER

Yes come one ! This table records the infected clients, let's see if we can do something to help them ! 
A simple DB count showed me more 2k infections so far. Not bad for being a plain new ransomware  as a service. The Targets look like being very spread all over the world. So far it's possible to extract the following country distribution.

TOPransom Victims Distribution

I will not disclosure IP addresses in order to guarantee victims privacy. Another interesting data comes from the victim browser distribution (another parameter collected by the attacker). Curiously the most used browser on windows devices is Chrome as the following image shows. [remember] The infection vector wasn't through web browser but through wscript.exe which opens .vbs by double click on it. [/remember]

TOPransomware victims browser distribution


On this post I've been describing the activity that took me from an email attachment to drop the entire attacker's database on a Ransomware as a Service platform that I called TOPransom. I've being trying to enumerate attacker's income and to mitigate the spreading vector by filling up wallets creation per user by writing a quick and durty python script.

Following IoC for your detection systems. Have fun !


IoC (summing up):
  • dropper .vba (sha256:fdd1da3bdd8f37dcc04353913b5b580dadda94ba)
  • saToHxy.exe (sha256:6a51d0cd9ea189babad031864217ddd3a7ddba84)
  • castillodepalazuelos.es/rf734rgf?
  • 2010.sggt-wh.de/rf734rgf?
  • actt.gr/rf734rgf?
  • https://n224ezvhg4sgyamb.onion.link/efwdaq.php
  • RECOVER-FILES-html (sha256: cdb3fef976270ab235db623d6a4a97ea93c41dd1)
  • Bot location: http://oeirasdigital.pt
  • Bot Location: http://jflo.ca/
  • TOP Browser

No comments: