Adwind Redux

Got a new sample from a friend, and ran it through Virustotal:

 

 

 

 

 

 

 

Interesting that this seems to be another copy of Adwind, which I received in a different format not too long ago. This one came inside a Word document. Opening this file, we see:

 

 

 

 

Seems legit.

In looking at the various behaviors of this sample, it definitely seems similar to the other one, but this sample doesn’t go as far as the other one did. The other copy installed itself and achieved persistence – this one doesn’t even go that far. Rebooting showed no new malware process and no network traffic. My guess is that for some reason this copy carries out whatever detection it normally does and doesn’t proceed further (the other copy gathered system info but that was after installing itself). This copy doesn’t create a copy of itself (beyond the microsoft.jar file that drops after opening the document). This copy also doesn’t hide the directories that it uses like the other copy did. It does create a text file to store a UUID.

Unlike the other sample, this one doesn’t try to resolve a host but rather just tries to connect (unsuccessfully) to 212.7.208.81 on port 1664 with TCP. The 3-way handshake gets attempted over and over but never succeeds. This particular address is similar to one listed in the Kaspersky report on Adwind, and has the same whois info:

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the “-B” flag.
% Information related to ‘212.7.208.0 – 212.7.208.255’
% Abuse contact for ‘212.7.208.0 – 212.7.208.255’ is ‘abuse@dediserv.eu’
inetnum: 212.7.208.0 – 212.7.208.255
netname: PL-DEDISERV-20100812
descr: Dediserv Dedicated Servers Sp. z o.o.
descr: XEN
country: NL
geoloc: 52.39097535181442 4.66494083404541
admin-c: DS7840-RIPE
tech-c: DS7840-RIPE
status: ASSIGNED PA
mnt-by: MNT-DEDISERV
mnt-routes: LEASEWEB-MNT
created: 2015-07-02T10:51:40Z
last-modified: 2016-02-12T12:01:34Z
source: RIPE
person: Dino Strzeminski
address: Dediserv Dedicated Servers Sp z o.o.
address: ul. Jaracza 3/49
address: 00-378 Warsaw
address: Poland
phone: +48 221001361
nic-hdl: DS7840-RIPE
created: 2010-08-03T11:35:20Z
last-modified: 2014-11-17T15:19:33Z
source: RIPE
mnt-by: MNT-DEDISERV
% Information related to ‘212.7.208.0/21AS60781’
route: 212.7.208.0/21
descr: routed via LeaseWeb
origin: AS60781
mnt-by: LEASEWEB-NL-MNT
created: 2014-03-11T14:28:00Z
last-modified: 2015-09-30T22:59:59Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.87.3 (DB-2)

 

 

 

The internals of this file again show obfuscation/encryption, and while the overall structure looks similar the values used are different, making me think that this file was generated with a different key than the other sample:

 

 

 

 

 

 

 

That’s about it on this one. I didn’t want to spend too much time on it since it’s basically what I analyzed last time, but it was interesting to take a look at what was different in this variant.

 

References:
https://securelist.com/securelist/files/2016/02/KL_AdwindPublicReport_2016.pdf
https://blog.malwarebytes.org/threat-analysis/2013/04/malware-in-a-jar/
https://blog.fortinet.com/2014/12/01/analysis-of-a-jar-obfuscated-malware-packer
https://en.m.wikipedia.org/wiki/Universally_unique_identifier
https://www.crowdstrike.com/blog/native-java-bytecode-debugging-without-source-code/
https://www.robtex.com/
https://www.mindmeister.com/

Findings and observations:
Cross-platform RAT, per Kaspersky et al. It’s difficult to attribute this sample to a particular group due to it being MaaS. A single IP address was used for communication. This particular sample does not achieve persistence.

Recommendations:
– Boilerplate recommendation against opening mysterious attachments via email, particularly from unknown senders with broken commands of the language of the target
– Block access to 212.7.208.81
– Since destination ports for TCP traffic is typically pre-set, block outgoing traffic to port 1664 if possible (unless you’re running Netview, I suppose)
– Removal appears to be straightforward – reboot and delete the executable to prevent it from being run again
– One could also remove the JRE entirely, if not needed for other legitimate uses by the user(s)

Conclusion:
Definitely a serious, professionally executed sample, but there are various mitigation tactics to both detect and remove this threat.

Hashes (of the .docx file):
MD5:dd23d91a9dbb06950c9ed775fe53c536
SHA1:9dab177105e60281f986aa3649831ad96a64730a
SHA256:6cdf99f2a771b841af2ad088b6b72e953ecacd8b45d270d0980bf71fbeda16c8
ssdeep:3072:SFfXYRu6GYDp90fx3y4Vt3pZWm5uTdDZPDsLcr8DAz4yJdWfIaqso52e+k:SxquoQfx3tLpZP5YdDVD4K8yJAfIaqsK

Hashes (of the .jar file):
MD5:e2be8fc564898d8e226399c75fa06c8b
SHA1:dc329ffceeb0ebe7ae016d69944a4f9db80ed9f3
SHA256:c1630a6043fdd0cf3c5ac99297d1a7d74ba538c4cf8062822124522c793462e3
ssdeep:3072:hkzYjp90fx3g4VtfpZWmXu7rDZFDCPGrMt2z4Wuj:rwfx3nrpZPXSrDXDUO8B

Adwind

I received yet another shady email, this time with a .ZIP file attached. Inside of “Invoice.ZIP” was another .ZIP file and then a .JAR file. After having spent time analyzing those two documents from previously received email and coming up with basically nothing interesting, I threw this new file into Virustotal to see if I should even bother looking at it:

 

 

 

 

 

 

 

 

 

Looks like I finally found something worth analyzing!

I started up a few tools to do a quick initial run, because I was actually a bit too excited to get everything set up for a full run. Here’s the structure that was within the .JAR. I don’t have any experience with this format, but even so this looked obfuscated.  I also notice some names of services or applications: Instagram, Jabber, Netflix, Telegram. I wonder if this might mean that this sample targets these services in particular, or maybe it uses these services and applications for some sort of communication with C2.

I looked up this sample on Kaspersky Labs’ site, and they have an outstanding report published on this malware. One important conclusion is that this sample is a Remote Administration Tool (RAT). RATs are used to achieve a comprehensive level of control over a targeted computer, and often there’s a specific goal in mind (i.e., credential theft). Sikorski and Honig point out some specifics about RATs in their excellent book, Practical Malware Analysis:
– RATs typically control relatively few hosts due to the more intimate interaction made possible by the RAT
– Because of the much finer level of control allowed by RATs, these are often used in targeted attacks of some sort

For some specific reasons why you should be worried about this type of malware, see these Adwind capabilities as documented by Kaspersky Labs:
– collect keystrokes
– steal cached passwords and grab data from web forms
– take screenshots
– take pictures and record video from the webcam
– record sound from the microphone
– transfer files
– collect general system and user information
– steal keys for cryptocurrency wallets
– manage SMS (for Android)
– steals VPN certificates

After reading through a couple of articles from Fortinet and Malwarebytes, I downloaded a bunch of tools to help with this sample:

– Java SDK and JRE 8 u 92 (32- 64-bit)
– JD GUI 1.4.0
– Eclipse IDE SR1 (32- and 64-bit)
– JMD (Java Multipurpose Deobfuscator)
– Dr. Garbage’s Bytecode Visualizer (an interesting tool I heard about in a Crowdstrike post)

I tried using JMD on this sample and none of the transformers it had worked. I tried various ways of disassembling/debugging this sample, and at this point I’m not getting anywhere. This is my first time looking at Java and I’m just not getting anywhere with the “casual” stuff which is about where my skills are when it comes to Java. I’m going to shift more towards seeing what I can observe dynamically.

Running the file caused a hidden directory to be created in the \users\[user]\ folder. The names of the directories remained the same throughout various executions:

– Creates a hidden directory under c:\users\[user]\cCTkcspgEWg\
– Creates a directory under c:\users\[user]\cCTkcspgEWg\IzUMUCujSzD\
– Creates a hidden file under c:\users\[user]\cCTkcspgEWg\ID.txt that contains UUID info
– Copies itself as a hidden file under c:\users\[user]\cCTkcspgEWg\QkAjGExTaCD.UbAPgH

The ownership of these directories and files remains with the current user who ran the malware.

I noticed that this sample will still run even if another instance of the malware is currently running, and the new instance doesn’t terminate. There must be some check for existing processes, however, because the file system changes above are not overwritten with new data nor is another set of directories and files created. The registry entries are also not duplicated.

The UUID appears to be a version 4 UUID based on the specification info from Wikipedia. I’ll take an analytical leap of faith and say that this is used to track each instance/installation of this malware.

Looking in Autoruns, I notice that a key and value have been added that will run the installed copy of the malware at startup:

I tried editing this registry entry so that this wouldn’t run the installed copy, and I did not see this sample run again when I rebooted, so I’ll conclude that this was the only persistence mechanism for Windows-based machines. I’m a bit surprised that this was the only persistence method used.

I let the malware run for about 45 minutes while I captured traffic with Wireshark and events in Process Monitor. I noticed that this sample spawned many child processes, which performed these main functions:

– Installed the malware to a normally hidden area on the hard drive, and then hid those files and directories, as well as added itself as a program to be run at startup via the registry
– Ran scripts to check for the presence of AV or firewalls
– After installing itself, ran WMIC to do an inventory of the system
– Then appeared to become idle

Here is a map showing the various processes spawned during the run:

 

 

 

 

 

 

 

The sample leaves itself in place during the initial run, which makes me think that it was intended to simply run from an email sent to the victim (or perhaps from a malicious link followed by a target).

I noticed in the Process Monitor results that four .VBS files were dropped. These files always had names following the format Retrive[18 or 19 random numbers].vbs but I could not locate these files and did not see them being deleted. I created a very simple batch file that I could run in the directory where these files dropped so that I could make a backup when the dropped. The batch file is really simple:

:loop
copy *.vbs *.vbs.bac
goto loop

This allowed me to get copies of the four .VBS files – it turns out that it’s the same two files dropped in each execution of the malware:

The contents of the first .VBS file:

Set oWMI = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\SecurityCenter2”)
Set colItems = oWMI.ExecQuery(“Select * from AntiVirusProduct”)
For Each objItem in colItems
  With objItem
    WScript.Echo “{“”AV””:””” & .displayName & “””}”
  End With
Next

And the second .VBS File:

Set oWMI = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\SecurityCenter2”)
Set colItems = oWMI.ExecQuery(“Select * from FirewallProduct”)
For Each objItem in colItems
  With objItem
    WScript.Echo “{“”FIREWALL””:””” & .displayName & “””}”
  End With
Next

These files get deleted by using SetDispositionInformationFile to set Delete:True. One final note about the files – the names contain a string of 18 random numbers during the first run, but the files dropped by the installed malware contain a string of 19 random numbers.

I visited several sites that would seem to be good targets for keylogging such as Santander, Bank of America, the Apple Store, Yahoo! Mail, etc. but I did not see any log files drop or get written to.

Turning to the captured traffic, I noticed that the malware resolves darlington.hopto.org [78.128.92.118], which appears to reside in Bulgaria according to robtex.com:

After this, I noticed traffic going to 78.128.92.118, apparently TCP traffic. Traffic was being sent from port 49338 on my machine to port 1212 on the destination machine. In the beginning we saw what appeared to be a regular TCP 3-way handshake followed by a an ACK coming from the malware author’s machine with a bit of data in it (1514 bytes total) followed by what appeared to be pretty regular back and forth traffic. I saw a few strings buried in this large packet, “assylia” and some random numbers.

 

 

 

 

Since the data in these packets looked encrypted or at least obfuscated, I had Wireshark use the SSL dissector on these packets instead, and that seemed to fit as you can see.

I was then able to find this inside one of the packets:

 

 

 

 

Pretty interesting, even though I wasn’t able to do much more at this point. I couldn’t find much about an Assylias, Inc in France, but I also didn’t look terribly hard (yet). Following this initial set up from the list of packets above, the malware settled into a very regular exchange of packets back and forth consisting of:

– Outgoing (port 49338 to 1212 on the malware author’s machine) TLS1.2 packet, 155 bytes
– Incoming (port 1212 to 49338 on my machine) ACK packet, 60 bytes

This repeated about every 300 milliseconds until I shut off the capture and brought the VM down.

Even though I couldn’t get through the obfuscation in the malware or its traffic, I still got a lot of interesting info out of this, and at least captured some signatures both in the file system and network that could be used to mitigate this file. My preference is to take things apart in excruciating detail, but failing that, figuring out how to recognize the sample is arguably more useful.

I may return to this sample in the future, and if so, I plan to:
– Get into Java so I have a better understanding of what I’m looking at with Java malware
– Find other techniques that might allow me to deobfuscate the code
– Try this on an actual physical machine in case the malware wasn’t fully functional due to detecting VirtualBox (which I sort of suspect happened, since I saw a few ways that the sample could have detected the presence of the VM and I didn’t see much behavior on the part of the malware)
– Since this is a cross-platform sample, try it out on other PC-based operating systems such as Linux but also on mobile devices
– Do some digging around on both the host in Bulgaria and this Assylias, Inc.

Again, please note Kaspersky Labs’ outstanding report on this malware:
https://securelist.com/securelist/files/2016/02/KL_AdwindPublicReport_2016.pdf

References:
https://blog.malwarebytes.org/threat-analysis/2013/04/malware-in-a-jar/
https://blog.fortinet.com/2014/12/01/analysis-of-a-jar-obfuscated-malware-packer
https://en.m.wikipedia.org/wiki/Universally_unique_identifier
https://www.crowdstrike.com/blog/native-java-bytecode-debugging-without-source-code/
https://www.robtex.com/
https://www.mindmeister.com/

Findings and observations:
A sophisticated, cross-platform RAT. While this sample definitely shows sophistication, other behaviors seemed a bit odd such as checking for AV and firewalls during every instance but only doing deeper system reconnaissance during the 2nd execution of the installed malware. A single domain and IP address which stayed available over the duration of the analysis suggests that it could be relatively straightforward to mitigate this sample.

Recommendations:
– Boilerplate recommendation against opening mysterious attachments via email, particularly from unknown senders with broken commands of the language of the target
– Block access to darlington.hopto.org / 78.128.92.118
– Since destination ports for TCP traffic is typically pre-set, block outgoing traffic to port 1212 if possible
– Removal appears to be straightforward – delete or modify registry key to prevent autorunning of this sample followed by reboot
– One could also remove the JRE entirely, if not needed for other legitimate uses by the user(s)

Conclusion:
A serious, professionally executed sample, but there are various mitigation tactics to both detect and remove this threat.

Hashes (of the .JAR)
MD5:a99041586a202ab4ec000401f31ce2b2
SHA1:342310461cb0bf9b18c4ac41206746c6f063043e
SHA256:b4c943f17728021211f238e27dfbc1cdd67a713a85456e11aac1575a85cdd359
ssdeep:3072:WwLuUTiZuGwFOBVpjX7TDnsnrtAlEiUzS/Y+xcFOx4sMWH/:jveZuNFOBVBX7TDkAizS/YW0shH/

Egyptian Hak

I decided to check out an unusual file I received in my Hotmail account. This one was much older (received in November of 2014) but I thought it was interesting because it was a 9 mb Rich Text file. The sender was humansettlements001@gmail.com. Some excerpts from the letter can be found below in the raw notes. I think a nice touch is that the letter is signed “Mr. Andrew Moor” but the signature appears to be Abraham Lincoln’s.

I went through the RTF specification looking for control words that could offer information about the author or lead to code execution and the like. Checking various tags didn’t reveal much, however I did see some info such as:

Author: user [oh, him]
Operator: PC13
Company: egyptian hak
Generator: Microsoft Word 11.0.5604

The reference to Egyptian Hak is a whole other topic that I might address at some point, but for now let’s leave it at this: There seems to be a cracked version of Windows XP SP3 (that comes packaged with several cracked utilities) circulating through the Arabic-speaking world (and concentrated in Egypt) and it was created by someone calling themselves Egyptian Hak. At some point I’d like to sit down and really dig into this but that’s all I want to do for now. My working assumption is that whoever created this document was running a copy of this XP “variant”, if you could call it that.

The version and build of this version of Word is interesting. The version indicates that this document was created with Word 2003. I would expect to see two numbers, one indicating the build number for the program and the second for build of the core Office shared library (MSO). This build number doesn’t seem to adhere to this format, but according to David Vielmetter’s website, this appears to be an original MS Office Word 2003 build (i.e., not a Service Pack build).

There is a reference to a website in this file:

 

This is interesting to me because this link goes to what appears to be a legitimate website and organization (a museum in British Columbia). I wonder if 1) this is a legitimate image that happens to have been hosted there for legitimate reasons that has been appropriated by the document author or 2) if this image itself is malicious and/or was put there due to some sort of unauthorized access on the part of the document author.

Running this through various sandboxes revealed nothing too special. I’m a bit frustrated because it seems like I have this document file that doesn’t seem to be much else other than a written scam (no links, no executables, no shellcode signatures detected, etc.). Opening the file didn’t indicate anything happening – no files written/dropped (aside from the usual), no network traffic, no registry changes. I can’t believe that people would bother to send out documents that are nothing more than form letters – I could be looking for something that isn’t there, so I should be careful not to find things that aren’t there, but I also feel like I need to dig deeper into this sample.

My next step was to look through the document for anything that might indicate shellcode. Where the images are displayed in the Rich Text Format, you see lots of raw data:

I searched the text of the file for any sections that might look like code to convert to a binary file. As you can see, there were two strings with three instances of NOP which are going to be where I’ll focus. The first hit at offset 0x8B20E3 also had three instances of opcode 0x4F, which would be DEC EDI in x86 assembly, following the NOPs (these two groups being separated by 00). The second group of NOPs at offset 0x8B1C8A didn’t have any opcodes in the 0x40 to 0x4F range following it, but I’ll look at that offset anyway.

I searched for occurrences of at least three of the following opcodes, and I got the following results:

table1

My list of “interesting” offsets, such as the already mentioned triple NOPs and also other areas where I saw many possible opcodes together (e.g., a string like 4242424A4A4A424242 or up to five occurrences of the same potential opcode) is as follows:

table2

At this point, I feel that these are probably the most promising areas to look at in terms of possible shellcode. To save the trouble of converting these sections into binary files, I decided to use the online disassembler at disassembler.io again.

Going through the disassembly of all these areas was disappointing, as it all resulted in garbage. I even put the entire file through just to see if anything stood out, and nothing resulted. The .JPG that the file links to didn’t have any triple occurrences (or more) or any of these opcodes either.

I’m pretty much at a dead end with this one. I also went back through procmon in detail and didn’t see anything interesting going on in the system. If nothing else this was a good exercise on the Rich Text Format. I’m also going to reach out to the website’s admin and see if they know about this file and how it’s being used.

References:
davidvielmetter.com/tips/microsoft-office-executable-version-numbers/
blogs.msdn.microsoft.com/jensenh/2005/11/11/decoding-office-build-numbers/

Findings and observations:
RTF file containing written instructions for some sort of financial scam, clumsily executed. Possible Arabic speaker as author. No dynamic behavior observed myself or via sandbox.

Recommendations:
Usual guidelines against opening strange attachments still stand. Admin of the site linking the image might want to review security, specifically around how that file appeared on their site.

Conclusion:
Scam message, no apparent malicious activity. Possible that any exploits in this sample might just not be effective running on the current test system.

Report:
MalRTF_001

Hashes
MD5:e2e2d91211ed870d44c6df85f58976fe
SHA1:3d2ec090b308e27e4490a3082901784110e06324
SHA256:66096c1c1692b8f1a4e8e9b678351601ded0a189241e7cbfeffc01c5bd379b93
ssdeep:24576:nOowJRsxdhW5DubB5UOG7Pz+UfOowJRsxdhW9DubB5UOG7Pz+UqOowJRsxdhWyDz:I

First attempt at analyzing a “real” file

I collected a bunch of presumably malicious documents from my Hotmail account that has turned into a great repository of spam and malware over the years. I’ve had this email address since 1997 and I regularly get phishing email sent to me, containing both links and files (typically MS Office documents, .PDFs, and various compressed files). Since I just finished working through Practical Malware Analysis, I thought I’d try analyzing some of the crap that gets sent to me on a daily basis.

I created a shady Russian email address that I use for forwarding all my malicious email. I don’t really want to have my email account that I actually use open while I open or run any of these attachments, so I just forward the messages to this new address and then use that to download the attachments. I access the account through a VM running on a different platform than the guest OS (in this case, I run Linux as the host and Win7 as the guest) on a burner laptop so that any “containment” issues hopefully won’t become too much of a problem.

It’ll be interesting to go through these files to see what types of malware one tends to find here. In speaking with people at conferences and reading various documents over time, I have gotten the impression that downloaders/launchers are probably what I’m going to find in my inbox. You could think of these as the “first stages” that help to get malware into orbit. You might have a piece of malware that’s particularly large, so the downloader/launcher might check the target system for certain conditions before downloading and launching the payload. For instance, you might have a downloader that might check for a particular vulnerability, or maybe check for various indicators of an analysis environment, such as being run within a virtual machine. Another reason one might want to use a downloader/launcher is so that the actual malware payload isn’t delivered until it seems “safe” to do so, so that any analyst doesn’t have much to work with.

This particular email came from testa@rarejet.com on 28APR2016. This domain appears to have been registered about a month and a half ago. While it was registered in Malaysia, we are meant to believe that the owner is in the USA based on the whois information (though I can see that this name and email address associated with that person also appears to be associated with some other shady activities). This email also contains a link to download a purported PC Clean Up tool as well as a single link to an actual SANS webpage.

testaemail

 

After downloading these files, I ran them through some basic static tools like Strings and KANAL, and then through various .PDF Python scripts such as those from Didier Stevens. The only interesting things I saw were a bunch of URI functions that linked to sketchy sounding websites and files such as PcCleanUp.exe. PDFStreamDumper suggested that there might be something hidden in a few streams.

I started up a bunch of tools for dynamic analysis and then opened the document, but didn’t observe anything special happening. The .PDF itself is a very ugly looking advertisement for SANS cyber security training classes, with links to various files such as an .EXE, a .ZIP file, a WinACE compressed file, an .SCR file (possibly a screen saver or a Steam-associated file), and an .RTF file. I would have really liked to have gotten some of the hosted files to look at, but by the time I opened these attachments (about two weeks after receipt), the links were already dead.

I didn’t get much out of this file with some of the online malware sites. Virustotal has only a 1/55 detection ratio (Sophos only Sophos detected what it thought to be a trojan). Malwr indicated that no hosts were contacted, but did detect some shellcode byte patterns and a SQLite 3.x database dropping.

vtpdf

 

I went back for another look through this sample to check out the SQLite db and the possible shellcode. Malwr says that the SQLite db dropped was in a file called SharedDataEvents, so I went and found that in an Adobe directory for the current user (see raw notes below for specifics). Some reading revealed that a SQLite db file will begin with the string “SQLite format 3\000”. It seems that any random binary could be given this string in the beginning and then create a false positive, so I went and got the SQLite file format from https://www.sqlite.org/fileformat2.html and took a look through the header.

The header seemed to check out. Everything seemed to be in the right place – the file size (3072 bytes) makes sense given the page size at offset 16 (1024 bytes) and size of DB in pages at offset 28 (3). Text encoding (offset 56) for the db is UTF-8. Opening this file in DB Browser shows two tables, pref_events and version_table. pref_events held no records while version_table held only a single record consisting of the integer “4”.

Looking on my main machine, though, this db just seems to be a part of Acrobat Reader’s normal operation. A little searching also indicated that you should see Acrobat making use of a SQLite db, so this seems to fit. I took a .PDF that I knew to be fine and ran that through the same sandbox, and got inconsistent results. With this clean .PDF, it didn’t report that it saw a SQLite db drop (though if you look in the files dropped area on the websiet, the db did drop, and in the same manner as with the the malicious .PDF). The clean .PDF also doesn’t show any shellcode signatures detected(which is to be expected). As interesting as it is to go through how Acrobat and .PDF files work, I’m going to conclude at this point that there’s nothing nefarious about this or other files that were observed being dropped or written to.

Moving on to search for shellcode, I had looked through the file in a couple of areas where PDFStreamDumper indicated there might be something hidden, but didn’t see anything that looked like obvious shellcode. I went back through the file again, this time looking for any instances of the following opcodes which would indicate a call or various kinds of jumps or loops (thanks again to PMA):

0xE8
0xEB
0xE9
0xE0
0xE1
0xE2
0x70 through 0x7F

I should note that disassembly and debugging is a bit of a challenge as I am working with the free license of IDA Pro (5.0) which will only support up to 32-bit disassembly, and I have a similar situation with Olly and Immunity. At some point, budget-permitting, I definitely plan to upgrade my license. I have a few different tools I can use for 64-bit, though, so I’ll rotate through them and see what I can get.

I noticed a few areas where there were bytes that could be used to make jumps, so I turned those into code in IDA to see what would happen. These led me to other areas where there might be code, but in looking at what IDA disassembled there in response to the earlier jumps, these sections don’t look like they actually do anything. I’m not seeing call/pop combinations or other things I would expect to see if this were shellcode. I see a few popa instructions but these also don’t appear to be used in ways that I would expect.

Trying with Arkdasm (a 64-bit disassembler) revealed even fewer instructions that made sense. X64dbg can’t attach to any of the processes associated with this file. Copying all this stuff from the .PDF file into Online Disassembler and then setting it to 64-bit results in more garbage. I even tried attaching Olly to a new Acrobat parent and child process but this just resulted in more junk (not surprisingly).

At this point I’m setting this file aside to move on to other samples that have come in more recently. I’m disappointed that I wasn’t able to get to the links before they were taken down, and I would have been particularly interested to see what the .EXE and .RTF files were doing. In the future I’m going to try to analyze these attachments as soon as I can after they arrive.

Findings and observations:
Sample is a .PDF file that was received in an Hotmail account that has been compromised multiple times over the years. This sample contains several links to download files from a few different sites, however upon trying to activate these links they had already been taken down. The sites linked to were generic file sharing sites, and file types included .EXE, .ACE, .RTF, .ZIP and .SCR files. The email was received from a domain currently registered in Malaysia and associated with a person purported to be living in Kansas, which could lead to further information about the source.

Recommendations:
Try to examine samples within 72 hours of receipt next time. Upgrade licenses to enable better analysis of 64-bit code.

Conclusion:
Missed the window to obtain additional files that would have been downloaded/launched by this document. Act faster on similar samples in the future. Online virus scanning sites may be ineffective in detecting malicious files such as these, and can also produce false positives and/or flag normal program behavior as suspicious.

Report:
20160526 MalPDF_001

Hashes
MD5:e34be1974edb9f4e5da79341e1e37ba0
SHA1:1850e0df012645032a3c3590321c3724ef79a894
SHA256:13ece20c212f01cff1532c25d2635aeb04aef432e63a161ac6a0953f6929de9a
ssdeep:24576:WNZ4hqDYFuf9SZm+QbgmOMmF/USoyZY4VIhZyzNOa:WNsCaBQeM01e4VIuNOa