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