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):