Author Archives: Marco Ramilli

Unprotecting VBS Password Protected Office Files

Posted on by
Hi folks,
today I’d like to share a nice trick to unprotect password protected VB scripts into Office files. Nowadays it’s easy to find out malicious contents wrapped into OLE files since such a file format has the capability to link objects into documents and viceversa. An object could be a simple external link, a document itself or a more complex script (such as Visual Basic Script) and it might easily interact with the original document  (container) in order to change contents and values.
Attackers are frequently using embedded VB Scripts to perform malicious actions such as for example (but not limited to): payload downloading, landing steps, environment preparation and payload execution. Such a technique needs “the user agreement” before the execution takes place, but once the user gave the freedom to execute (see the following image) the linked code on the machine, the VB script would be free to download content from malicious website and later on to execute it the victim machine.
Enable “Scripting” Content
Cyber Security Analysts often need to read “raw code”  by opening it and eventually digging into obfuscation techniques and anti-code analysis in order to figure out what it really does. Indeed contemporary malware performs evasive techniques making the simple SandBox execution useless and advanced attackers are smart enough to block VB code through complex and strong passwords. Those techniques make the “raw code analysis” hard if the unlocking password is unknown. But again, the a Cyber Security Analyst really needs to open the document and to dig into “raw code” in oder to defend victims. How would I approach this problem ?
Following a simple method to help cyber security analysts (NB: this is a well known technique) to bypass password protected VB Scripts.
Let’s suppose you have an Excel file within Visual Basic code, and you want to read the password protected VB Script. Let’s call such a first Excel file: victim_file.
As a first step you need to open the victim_file. After opening it you need to create a additional excel file. Let’s call it: injector_file.xlsm. Open the VB editor and add the following code into Module1.



Now create a new module: Module2 with the following code. It represents the “calling function”. Run it and don’t close it. 

It’s time to come back to your original victim_file, let’s open the VB Editor and: here we go ! Your code is plain clear text !
At that point you are probably wondering how this code works. So let’s have a quick and dirty explanation about it. Once the VBProject gets opened it visualizes a dialogBox asking for a password (a String). The WinAPI eventually checks if the input string is equals to the encoded static string (file body not code body) and it returns “True” (if the strings are equals) or “False” (if the strings are not equals). The function Hook() overrides the User32.dll DialogBoxParamA returning parameter by making it returns always the value “True”.  
Technically speaking:
  • Raw 45 saves the original “call” (User32.dll DialogBoxParamA) parameters into TmpBytes
  • If the password is correct TempBytes(0) gets the right pointer to the current process 
  • If the password is not correct the script saves the original bytes into OriginalBytes (length 6)
  • Raw 50  takes the address of MwDialogBoxProgram
  • Raw 52  forces the right handler 
  • Raw 53  saves the current value
  • Raw 54  forces the return par as True
  • Raw 56  moves the just crafted parameters into the right location into user32.dll
Have nice VBA Password un-protection 😀
Disclaimer:
This is a well-known method: it is not new.
I wrote it down since it becomes useful for cyber security analyst to fight against Office Macro malware. Don’t use it unlawfully.
Do not use it to break legal documents.
I am not assuming any responsibility about the usage of such a script.
It works on my machine 😀  and I will not try to get it working on your 😀 (programming Horror humor)

The post Unprotecting VBS Password Protected Office Files appeared first on Security Boulevard.

Continue reading Unprotecting VBS Password Protected Office Files→

Posted in SBN

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

Posted on by
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 😀 (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

Continue reading TOPransom: From eMail Attachment to Powning the Attacker’s Database→

Posted in SBN

A quick REVENGE Analysis

Posted on by
Another free weekend, another suspicious link provided by a colleague of mine and another compelling feeling to understand “how it works”.  The following analysis is made “just for fun” and is not part of my professional analyses which have to follows a complete different process before being released. So please consider it as a “sport activity”.

A colleague of mine provided me a suspicious link which I decided to analyze.

The infection starts by redirecting the browser to the page “see.aliharperweddings.com” through a GET request with the following parameters:

biw=diamonds.104wh99.406v6e7i0&que=diamonds.124if80.406v5h6e9&qtuif=3654&fix=diamonds.108bf93.406p9e7i4&oq=CeliDpvspJOdZNQOyj0SGfwZkm4pcBwhH9Pqqj0bWmxCag57W9CW9UU4HupE&q=z3jQMvXcJwDQDoTBMvrESLtEMU_OHEKK2OH_783VCZ39JHT1vvHPRAPytgW&ct=diamonds&tuif=6124

The page is not build to return rendered content but rather to return three different scripts. Indeed the returned visible page holds a weird displayed content as follows:

Weird visible content by: see.aliharperweddings.com

Getting a little deeper on the page source code it is easy to experience nice obfuscated scripts, which look like (at least to my experience) a first infection stage. Let’s have fun and try to understand how this new sample works. The following image shows an obfuscated piece of code portion. We are getting into the first stage of analysis.

First Stage: The fun begins.

Just few steps on google V8 engine to de-obfuscate the first stage which uses a couple of techniques to run VBscript on the target machine. The first implemented trick, as shown in next image, is to use the classic  but “ever green” window.execScript which is no longer supported on Explorer >= 11. execScript takes two parameters: “the code to be run” and the “used programming language”. The function invokes the right interpreter depending on “programming language” parameter.

Second Stage: Running VBScript

The second trick is to use eval to de-obfuscate the second stage and later on to run its functions through VBArray technique.  Decoding the second stage was easier if compared to the first stage since less obfuscation rounds are involved. Once de-obfuscated the second stage I’ve run into another “browser” stage (let’s call it Third Stage) written in VisualBasic Language as follows:

Third Stage: The VBScript saving Windows PE

The resulting script is quite simple to read no further obfuscated loops were involved.  The script per se is quite big so I am not going to describe every single line of code but just the most interesting one (at least in my personal opinion), so let’s focalize on the “random function” (showed in the following image) which returns strLen number of “random” letters from a well defined alphabet :).

Third Stage: Implemented “random” function

This function is used later on to save the PE FileSystemObject into temporary file by using the number “8” as parameter to the rnds function. A nice and dirty IoC would be: “8 letters” from “abcdehiklmnoprstuw02346” alphabet “.exe” into system temporary directory as shown in the next image. 

Third Stage: Saving PE Object using 8 “random” (not really) characters

The FileSystemObject is then executed through the WScript.Shell technique as shown in the next image.

Third Stage: Running the fake shell32.dll

A key argument is defined as “gexywoaxor” and a stream is taken from an url as shown in the following image.

Third Stage: Key and Stream

A special function is crafted to decrypt the stream having as a key the defined one. The decoded stream is getting saved and launched according to the fake shell32.dll.

Third Stage: Decryption stream function (key= gexywoaxor)
Most of you would recognize RIG Exploit kit which used to decrypt streaming (ADOBE StreamObj) objects through inline xor. That decrypt function would not use a simple xor, and for such a reason I would consider it as new version of RIG Exploit Kit. The overall behavior looks like standard RIG EK having threes infection browser scripts and stream decoding procedure.
Finally I’ve got a Windows PE on my temporary directory and a script launching it from browser ! 
Let’s move on and see what it does. A first run the PE file gets information from its Command and Control server which, on my time, happened to be: 193.70.90.120 (France)
It downloaded a Public Key (maybe for encrypting files ?) as follows:
Fourth Stage: Downloaded Public Key

This behavior reminds me a romantic Ransomware attack, which happens to fit pretty well with RIG distribution rings. The sample starts with simple http GET but later on it keeps trace of its malicious activity (encrypted files) by posting, on the same C&C, the number of encrypted files and a unique serial number as well. The sample returns back two parameters: id and count.

Fourth Stage: POST to C&C

id is different for every infection while it could be consider as a unique constant for a given one. count constantly increases its value as a counter depending to the number of encrypted files.
The sample presents some tricks to control the running environments such as (but not limited to): IsDebugPresent and VolumeChecking. The sample is a multi-thread encryptor which spawns an encrypting thread for each found system folder (limiting to 10 per times). The sample is not packed/encrypted from a well known packer/encryptor as the following image shows, but the real code (payload) is encoded into a Fourth Stage (let me define the Windows PE as fourth stage of infection).

Fourth Stage: No known packers/encrypters are found

The following image shows the real payload dynamically build in the heap of the fourth stage. As analyst I decided to not extract it but rather following on the original sample in order to understand how happens the control flow switch.
Stage Fifth: HEAP built payload 

The fifth stage is run by the following code which after having built the payload straight into the memory gets the control flow by simple dynamic “call” to dynamic memory [ebp+var_4].

Fifth Stage: getting control by call [ebp+var_4]

This is the last stage where the payload runs over the folders, read files and encrypt them by using a dynamically loaded cryptbase.dll and the downloaded public key. The payload per-se saves itself and get persistence by infiltrating on register keys. The following images show where the payload copies itself in the target machine

Fifth Stage: Payload Persistence
Te payload saves itself as svchost file creating a folder named Microsofts\ Windows NT\svchost.exe as the most classic payloads does ! Cryptobase.dll functions are dynamically loaded, only few library functions have been involved which takes easy to track them down (the following images show the tracking down imported libraries).

Stage Fifth: Cryptobase.dll tracking functions
Finally the SaveFile function write the ransom file: # !!!HELP_FILE!!! #.TXT  to physical drives having the following content and encrypts file through .REVENGE extension

Ransom File
Since the implemented languages are: English, Italian, German, Polish and Korean  it is easy t believe this ransomware attack would target European countries mainly.
While the infected website (see.aliharperweddings.com) has promptly been closed (now it belongs to GoDaddy) the Command and Control page is still up and running. Indeed the command and control appears to be an old vulnerable fake website created on 2016-10-07T08:19:40Z weaponized with an ancient content back to November 2014. The website is not a real one, it’s a simple “lorem ipsum” with no apparent purpose. The following images shows the apparent not real website.

Command and Control Vulnerable Web Site

Conclusions

Despite the reverse engineering difficulty and/or the technical details I addressed in this quick and dirty post, I found an unusual C&C behavior. Usually attackers want to protect their C&C and are the first system (page, connection, services) to be closed and/or moved after a first disclosure. Indeed the attacker wont be “syncholed” by receiving injection commands into her malicious network. Contrary in this example the current C&C looks to be alive from October 2016. Please note that I am not saying it servers RIG from 2016 but it might have served many different EK over time, which makes me thinking to a well defined operation attributable to a RIG as a service group.

Useful IoC:
– url: see.aliharperweddings.com
– url: far.nycfatfreeze.com
– ip: 193.70.90.120
– ip: 188.225.38.186
– email: rev00@india.com
– email: revenge00@writeme.com
– email: rev_reserv@india.com
– string: 5427136ABEE9451E
– string: # !!!HELP_FILE!!! #.TXT
– string: gexywoaxor 
– file extension: REVENGE
– File Name: 8 characters from {abcdehiklmnoprstuw02346}.exe

BONUS:
A similar dropper (Third Stage) has been published on March 9th 2017 on pastebin.

Continue reading A quick REVENGE Analysis→

Posted in SBN

Crypt0l0cker Revival !

Posted on by
A couple of days ago a colleague of mine gave me a “brand new” malicious content delivered by a single HTML page. The page was sent to an email box as part of a biggest attack. I found that vector particularly fun and so I’d like to share some of the steps who took me through a personal investigation path made not for professional usage but just for fun.

At first sight the HTML page looks like the following image.

Figure1: Attack Vector. A simple HTML page

A white backgrounded HTML page with a single line test on it saying: “print this document please”. But what document ? Honestly I am in front of one of the ugliest “fake email” I ever seen. But let’s move on and se what it really carries on. Opening the HTML content with a simple editor we might see a suspicious obfuscated Javascript. We are facing a first obfuscation stage. 

Figure2: Obfuscated First Stage

Since Javascript is an interpreted language (such as .NET or .Java) is not hard to understand its behavior, indeed after some rounds of “substitutions” and “concatenations” it easy to get the following clear text result showing the end of the first stage.

Figure3: Clear Text First Stage
That script is going to create an additional “script tag” on the current document by injecting an external script from: “https://s3-us-west-2.amazonaws.com/s.cdpn.io/14082/FileSaver.js“. The injected script will be called with the following code signature: “saveAs(blob, ‘image.js’);” with 2 arguments: 
  1. blob. The raw content of “big_encoded_data” (please refer to Figure3)
  2. image.js. The saving name
In order to better understand what that function saveAs(blob, image.js) does we need to analyze the external FileServer.js. The entry point of the external script is the function “saveAs(arg1, arg2)” which has been defined as follows:
Figure4: FileServer.js Original Entry

saveAs(blob, name) is a simple wrapper function headed to FileServer constructor which is defined as follows:

Figure5: FileServer.js constructor

The script saves the “blob” content to the temporary folder giving to it a specific name (image.js in our case). As you might notice from the script content: “Apple do not allow window.open, see http://bit.ly/1kZffRI ” if the victims opens the file with Safari/Mail the attack vector will have no effect since Safari/Mail does not allow you to trigger the script on “window.open” event. This is why I did’t see any file when I opened the infected HTML content. Back to the original script (Figure3) we see the aveAs function called on page.load so the resulting image.js is going to be saved in the temporary local folder, in case of email clients, it will be triggered as soon as saved! So lets move on our next stage: the big_encoded_data variable (Figure3) which is going to be saved as image.js file. The big_encoded_data owns a first obfuscation stage made by encoding the downloader in base64. Once decoded from base64 and beautified the results looks like the following image

Figure6: Stage 2 base64 decoded obfuscated downloader

The downloader is still obfuscated by a high number of simple returning array-strings variables. It took almost 45 minutes to decode the entire second stage downloader. The resulting downloader is shown in the following image.

Figure7: Second Stage Downloader
A first check on fileSystem API and on the Element Type is super interesting (at least to me). We are analyzing an attack based on a specific file system, Windows native. The deobfuscated downloader grabs a file from “http://mit.fileserver4390.org/file/nost.bgt” and saves it to a temporary directory. By using ActiveXObject (Windows native) it saves the file and it runs it through command line c[“run”](“cmd.exe /c “ + f + g, “0”); where f takes the temporary folder f = b[“GetSpecialFolder”](“2”); and g takes the temporary name g = b[“GetTempName”]();.

This is the end of the second stage downloader.

The downloaded file is a PE Executable packed as well. Fortunately the used packer is the PiMP Stub by Nullsoft: a quite famous installer used by several software house.

Figure8: NullSoft Installer

The PiMP installer takes .dlls and runs them as the resulting software. The used resources are compressed in its own body by a well known algorithm: .7zip. Kation.DLL is the only DLL included in the dropped file and so it is the run DLL by PiMP installer. Kation wraps out ADVAPI32.DLL and KERNEL32.DLL as you might see from Figure9. ADVAPI32 is a core Microsoft library which includes the Microsoft encryption libraries such as: EncryptFileA, EncryptFileW and so on and so forth. It’s not hard to guess a new Ransomware infection from that API calls.

Figure9: Usage of Encryption Libraries

From a static analysis prospective it becomes clear that some of the used strings are dynamically allocated. For example in sub_10001170 (frame 0XBC) several UFT-16 strings within decryption loop are involved showing out the control flow passing to Etymology.Vs (Figure11).

Figure10: Setting the running pointer

Figure11: Decoding Functions

The real behavior is hidden into the Etymology.Vs encrypted file included in the PiMP solution as well. Running the infected sample it disclosures its real behavior: shown in Figure12.

Figure12: Ransom Request

Here we go,  we have just discovered a brand new Crypt0L0cker ! it asks for bitcoin (Figure13), of course.  Looking at network communications, a Domain Name Generator Algorithm (DNGA), [wow, it sounds new from CryptoL0Cker !] fires up as soon as the dropped file is executed. It looks for valid registered subdomains belonging with divamind.org.  Until a valid Command and Control answers to the CryptoLocker client it hides itself and performs simple DNS query as follows:

 28  imadyxaro.divamind.org 
 29  irel.divamind.org 
 30  awwtodufir.divamind.org 
 31  ogisirigu.divamind.org 
 32  yzijyvy.divamind.org 
 33  uqekfr.divamind.org 
 34  ydoc.divamind.org 
 35  yzukyfyku.divamind.org 
 36  upenigy.divamind.org 
 37  qhera.divamind.org 
 38  ijywiqezy.divamind.org 
 39  efuca.divamind.org 
 40  ygbm.divamind.org 
 41  ejrdip.divamind.org 
 42  usen.divamind.org 
 43  ahydenuj.divamind.org 
 44  ghxsykegaja.divamind.org 
 45  ekohob.divamind.org 
 46  ifyvas.divamind.org 
 47  iqimub.divamind.org 
 48  usegi.divamind.org 
 49  yjeqicoht.divamind.org 
 50  rtibola.divamind.org 
 51  ucnpive.divamind.org 
 52  aminevkjude.divamind.org 
 53  pwiregaty.divamind.org 
 54  irol.divamind.org 
 55  abswuhupnt.divamind.org 
 56  erelo.divamind.org 
 57  ulefuw.divamind.org 
 58  ogax.divamind.org 
 59  ezelilijxn.divamind.org 
 60  ulymobutol.divamind.org 
 61  obehilebac.divamind.org 
 62  yfycodolul.divamind.org 
 63  iwesvxynd.divamind.org 
 64  kcoma.divamind.org 
 65  ydqpibc.divamind.org 
 66  ykotifehut.divamind.org 
 67  ewuzivy.divamind.org 
 68  imocyfyt.divamind.org 
 69  fjep.divamind.org 
 70  ibeb.divamind.org 
 71  isafexuh.divamind.org 
 72  izemireli.divamind.org 
 73  kgorihukyho.divamind.org 
 74  udupose.divamind.org 
 75  iqyk.divamind.org 
The process to contact the Command and Control in order to exchange key and to notify the attacker could be very time consuming, in some of my runs it took until 2 hours depending on the available Command and Control at the time being. It would be very nice to have extra time to reverse the DNGA but unfortunately my weekend time is ending up. 
Figure13: Ransom Request Web Page

Development language is French, and many piece of code reminds me the “gaming world”.   The main Command and Control domain is registered in Moscow (RU) and the registrant is “privacy protected”.

Results for Target: divamind.org
Created Date : 2017-02-07T12:37:10Z
Updated Date : 2017-02-08T10:38:54Z
WHOIS Server: whois.pir.org
Results for Target: divamind.org
Created Date : 2017-02-07T12:37:10Z
Updated Date : 2017-02-08T10:38:54Z
WHOIS Server: whois.pir.org

The ransom page (available on the following link) is registered by EPAG Domain Sercives GmbH (Bonn, Germany) and is written in Franc language: 

http://x5sbb5gesp6kzwsh.hoptrop.pl/uum2j9ku.php?user_code=&user_pass=&page_id=0

Ok Let’s have some brand new IoC:

Malicious hashes:
2649cba6ca799e15c45fa59472031cc9087a5ade
6ef0e56b27cfd3173aeded9be9d05e97d8e36da3
7292f20a0909f5f9429d5c1ec2896cf8f57a40a2
0b7b7201310638a74dba763c228d8afe77303802
2d36b1bf1c37d6f5b47fe36bd2c5bac81b517774

Malicious urls:

http://mit.fileserver4390.org/file/nost.bg
http://x5sbb5gesp6kzwsh.hoptrop.pl
http://xiodc6dmizahhijj.onion

DNGA:
– base dns: XXXXXXX.divamind.org

Extension:
.?????? (6 characters)

Strings:
HOW_TO_RESTORE_FILES

Enjoy your new IoC

Continue reading Crypt0l0cker Revival !→

Posted in SBN