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/
I searched for occurrences of at least three of the following opcodes, and I got the following results:
