February 4, 2017

Hunting with Network Forensics (MTA Challenge Writeup)

Hello guys! This is going to be my first blog post in English. According to my personal intention that I don't want to spend my precious time to attend English writing course and also want to improve my technical skill at the same time, then this came out as the result. You, as a reader and grammar police, can send me any comments if you see something wrong or have any suggestions. Thanks in advance and enjoy reading :)

Today, I'm going to talk about malware hunting by examining network artifacts from captured network traffic. The PCAP I'm going to use for this time came from latest Brad's traffic analysis exercise which available on well known malware analysis site Malware-Traffic-Analysis.net (Thanks Brad!) The goals of hunting are to understand what actually happened when someone accidentally started to lose his or her data and control of the system and find answers to the exercise's questions.


For the entire analysis process, I'm going to use Wireshark to handle our PCAP file. So, let's get started!
  • What I need to do first is get the big picture from the PCAP file that can be done by using tools in Statistics menu. I roughly passed through with Resolved Address, Protocol Hierarchy, and Conversations and then found many interesting information likes
    • In Resolved Addresses window, we can see some suspicious (and may be malicious) domains which we are not similar:
      • tyu.benme.com
      • spotsbill.com
      • www.homeimprovement.com
      • retrotip.visionurbana.com.ve
      • p27dokhpz2n7nvgr.1jw2lx.top
    • In Protocol Hierarchy Statistics window, we can see the percentage for each protocol that has been captured in the PCAP file. It looks like 19.1% of 22.0% UDP is data, quite interesting. For HTTP protocol, it is only 5.5% of 78.0% but we still have to examine and clarify what is the purpose of domains we have seen above on Resolved Addresses window.
    • In Conversations window IPv4 tab, if we sort all captured data by a number of packets in descending order, we can see that our host ( sent 2,147 IPv4-based packets to (dual.a-0001.a-msedge.net), 1,433 packets to (tyu.benme.com) and then 301 packets to (p27dokhpz2n7nvgr.1jw2lx.top).
  • Back to the main Wireshark program window. We already know from the PCAP's overview that we can ignore and filter some noises out to make it easier to analyze. So, I am going to filter out all DHCP, LLMNR and NBNS packets by this expression: not llmnr and not nbns and not bootp.option.type == 53. I am going to ignore plain TCP packets but allow HTTP which is TCP-based packets too by this expression: http or not tcp.
  • After dealing with filter expression, we are ready to analyze the PCAP file. My first spot is in the stream of requests to www.bing.com. It looks like user entered www.bing.com to find something. We can see on packet no. 1870 and 1876 which is search query suggestion feature and the actual search query that indicate what was this user looked for: "home improvement remodeling your kitchen". But what was the link user clicked from search results? The answer is on packet no. 2619, 2625 and 2632: www.homeimprovement[dot]com/remodeling-your-kitchen-cabitnets.html.
  • Between the DNS response packet no. 2625 and the HTTP 200 OK packet no. #2659, there is one DNS query for retrotip.visionurbana.com[dot]ve. We can assume from this point that remodling-your-kitchen-cabitnets.html has contained some objects from retrotip.visionurbana.com[dot]ve, forces the browser to find this object's origin before display to the user. It looks like retrotip.visionurbana.com[dot]ve has been called because embedded dle_js.js file
  • We can use Export feature in Wireshark to take a closely look at what is the web server's response as a file. In remodeling-your-kitchen-cabinets.html, dle_js.js has been called from line 15. The purpose of dle_js.js is inject an iframe from tyu.benme[dot]com. I think that the part of </ifr' + 'ame> on dle_js.js is tried to make iframe detection mechanism on anti-malware solution do its job a little bit harder but not that much.
  • If you look at packet no. 2852, you will notice the different between tyu.benme[dot]com's payload in dle_js.js and what was sent. This will lead you to the second injected iframe in remodeling-your-kitchen-cabinets.html line 125 as "Vivaldi" request. Another connection from dle_js.js's injected iframe was sent after the "Vivaldi" as "Amaya".
  • There are patterns between two HTTP GET payloads but they are not significant enough when it is encoded.
  • The response from Vivaldi is packet no. 2913 and the response from Amaya is packet no. 2917 in HTML format. Both HTML files have the different part only in NormalURL variable. Inspect both two HTML files show us the "profiling" step. You can see Vivaldi's HTML file here. They try to collect target's environment information e.g.
    • What is the browser? By looking on current browser's User-Agent
    • What is the platform of running browser? Is it mobile or not?
    • What is the version of the browser?
    • The attached script will try to determine is the browser real or bot. If the browser is not on a mobile platform and is possibly Internet Explorer, Google Chrome or Mozilla Firefox, the script will try to find each browser's unique feature (e.g. ActiveXObject, mozInnerScreenX, WebKit*) and increase its reputation score.
    • If browser variable (from User-Agent) is not the same as browser_real (from determined browser's feature) variable, set browserObj.is_bot to true and will show nothing. But if browser_real is IE, go to NormalURL.
  • Bad luck user is here. It looks like the current using browser is IE, causes sending of NormalURL in packet no. 2936 for Vivaldi and packet no. 2937 for Amaya. The response of both packets have different hash value but same size HTML files and well obfuscated. I will talk about this obfuscated code later, otherwise, this article is going to be longer.
  • Vivaldi and Amaya keep continue. After went through those obfuscated code, Vivaldi turns to SeaMonkey but Amaya still the same in packet no. 3108 and 3109. They both got identical (SHA256: b3669ec83fb4bba5257da8c68b32dc15d1a08e9e8c22c7483698f29de2839b5f) application/x-shockwave-flash file as responses. According to 2017-01-27 - MORE AFRAIDGATE RIG-V from MTA, this is Rig-V flash exploit.
  • When the malicious actor(s) is successfully exploited the system by Rig-V flash exploit, then they try to download unknown application/x-msdownload program. According to binutil's file program and binwalk, it is just a random data. But why?
  • All of HTTP traffics end here but it is not the last stop. Our target system started to fire UDP packet to, for the first round and, and for second round. All sent UDP packets was from source port 58978 to 6892. For the first round, payload data is e7eea3d97c8d008c171000097 and for the second round, payload data is e7eea3d97c8df7. This is the identical behavior of well-known ransomware variant, Cerber.
  • After massive UDP flood, the target system sent to bitcoin web service BlockCypher.com for the information of the owner of 17gd1msp5FnMcEMF1MitTNSsYs7w7AQyCt wallet ID and current blockchain status in packet no. 5127, 5128, 5133, 5158, 5160 and 5161. Finally, the ransom note was appeared from possibly onion address p27dokhpz2n7nvgr.1jw2lx.top. You will see that the string e7eea3d97c8d008c171000097 and e7eea3d97c8df7 are relate to Cerber's ID for this computer EE7E-AD39-7D8C-080C-18BF.
  • Note: I can't find any reference to spotsbill.com. So, this possibly came from the obfuscated HTML file that I haven't try to deobfuscate it yet.


  • Basic questions
    • What was the date and time of the infection?
      • Answer: I'm not sure about what are precisely date and time of the infection. So, my  answer is 2017-01-27 22:54:42 by the time of the first redirection (packet no. 2806)
    • What is the MAC address of the infected Windows computer?
      • Answer: Turn off all filter expressions and simply look at packet no. 1. DHCP ACK request came from default gateway to our host then look at data layer. It's 5c:26:0a:02:a8:e4 (Dell_02:a8:e4)
    • What is the IP address of the infected Windows computer?
      • Answer: Easy one. It's
    • What is the host name of the infected Windows computer?
      • Answer: Remove all filter expressions and look for data in LLMNR and NBNS which both are related to local name resolution and service protocol. It's STEWIE-PC.
    • What type of malware was the computer infected with?
      • Answer: Got attacked by exploit kit and then Cerber ransomware.
  • Advanced questions
    • What is the name of the malware that infected the user's computer?
      • Answer: According to the ransom note, It's Cerber.
    • What exploit kit was used to infect the user's computer?
      • Answer: I guess Rig-based exploit kit.
    • What compromised website kicked off the infection chain of events?
      • Answer: www.homeimprovement[dot]com/remodeling-your-kitchen-cabitnets.html
  • More advanced questions
    • Before the Windows computer was infected, what did the user search for on Bing?
      • Answer: Look at packet no. 1870 and 1876 I mentioned before. The search query is home improvement remodeling your kitchen.
    • Which campaign(s) used the exploit kit noted in the pcap?
      • Answer: I'm very not sure about this. So, I guess pseudoDarkleech and ElTest.
    • What are the indicators of compromise (IOCs) from the pcap?
      • Answer: IPs in suspicious IP list I mentioned before and also the hash of Flash exploit with Cerber hash.