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 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
% Note: this output has been filtered.
% To receive output for a database update, use the “-B” flag.
% Information related to ‘ –’
% Abuse contact for ‘ –’ is ‘’
inetnum: –
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
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
% Information related to ‘’
descr: routed via LeaseWeb
origin: AS60781
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.



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.

– Boilerplate recommendation against opening mysterious attachments via email, particularly from unknown senders with broken commands of the language of the target
– Block access to
– 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)

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

Hashes (of the .docx file):

Hashes (of the .jar file):


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:

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

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

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 [], which appears to reside in Bulgaria according to

After this, I noticed traffic going to, 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:


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.

– Boilerplate recommendation against opening mysterious attachments via email, particularly from unknown senders with broken commands of the language of the target
– Block access to /
– 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)

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

Hashes (of the .JAR)