Alright so I figured I might as well post a little tutorial on what I
have been working on for the past couple of weeks. I have been doing
analysis on some traffic captures of exploit kit attacks primarily to
look at the grit of how they work and how their load distribution
servers work (might do a paper or something on this sometime it is
actually more interesting then it might seem at first glance). Anyways
enough foreplay, on to the tutorial.
Setup:
First you will need a couple of tools to follow along. I use these but I am sure there are other ways out there, use what your are comfortable with.
Note: JPEXS is only necessary if you want to decompile the swf of the flash exploits to mess around with them.
I also highly recommend setting up wireshark this way for easier analysis of web traffic: http://www.malware-traffic-analysis.net/tutorials/wireshark/index.html
We will be analyzing this file: http://www.malware-traffic-analysis.net/2014/12/04/2014-12-04-traffic-analysis-exercise.pcap
Basic Identification:
The first step in analysis is to determine some basic information such as the ip of the compromised host and the exploit kits landing page. So lets open the pcap up in both wireshark and CapTipper to open it in CapTipper use the command: python CapTipper.py -s <name of pcap file>. The -s is just because we do not want to use the web server feature since it would be somewhat dangerous considering it would be practically be like mirroring an exploit kit onto a server. I recommend making CapTIpper.py executable and soft linking it to your bin folder for ease of use. Once you have it open in CapTipper it should show you a list of conversations:
Also limit your wireshark view to http requests by using the filter http.request. With a quick glance at wireshark we can see that the only client throughout the capture is 192.168.137.62 so we can assume that this is the compromised client; however, to prove this we can look at CapTipper. Scrolling through my eyes were drawn to request 52 since CapTipper thinks a binary was dropped. Lets hexdump it to see whats up there. The syntax is hexdump <req> <number of bytes>. I dumped just the header and suprise where the magic number for an executable should be there are some seemingly random numbers and the usual string is not there. This indicates the binary is encrypted (most likely with a simple xor). Knowing that makes it extremely likely that this is the exploit kit's payload. For further confirmation I dumped about 2000 bytes. Here we see something strange at around 0550 and at 0700. Signatures like this are often listed by researchers so lets do a little google magic. I found this link: http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html which indicates that this is the xor key for Angler EK so we could decrypt this binary if we wanted to using xortools, but this confirms that this host is the malicious site. Type info 52 to find out information about the request that lead to the download. So looks like qwe.mvdunalterableairreport.net is the host. Now we should go about finding the landing page. To do that we should find the first time the client hits that host. Type hosts into captipper and find qwe.mvdunalterableairreport.net. You should see that 49 is the first request to the EK. To confirm that this is the landing page we should dump this to a file. First we have to expand the file since it was compressed, the syntax for that is ungzip <req>. The syntax to dump a request is dump <obj> <dump file>. Dump the object that CapTipper created, but be careful and dump it with a different extention to html to avoid accidentally infecting yourself just in case (I believe the host is down but I have not checked). Open the file in a text editor and you will see something strange. If you are not familiar with Angler the strange text at the top might confuse you. These strange headers are often included on Angler landing pages. The obfuscated script at line 200 further confirms that his is the landing page. You can use jsbeautify to get a better look at the script.
Extraction and deobfuscation:
Alright lets drill down on one of the exploits it tried to serve up. Lets look at the flash exploit since it takes more effort to extract than the html exploit. Dump 63 since that is the swf that the host serves up. Now you need JPEX to decompile the swf. First you need to decompress it which can be done with ffdec -decompress <infile> <outfile>. Then you can export the scripts and elements of the flash file by using ffdec -export all <outdirectory> <infile (outfile from before)>. To make this exploit usable we would have to deobfuscate the actionscript which is quite complex and I am not nearly qualified to try to teach the process as I am not sure I could deobfuscate it myself. If people want to post some sources or advise on that topic that would be great.
General Attack Flow:
After drilling down now we can zoom back out and look at the general flow of the attack using wireshark. Looking at the first couple requests, the host visits google then searches earsurgery.org and clicks on the link. That traffic is pretty normal. Now that we hit earsurgery.org we see it has the client make a bunch of GET requests. I found it easier to work backwards in this case. So lets click on the landing page (first request to qwe.mvdunalterableairreport.net) and open up the HTTP Headers. Looking at the headers we can see that the referrer is lifeinsidedetroit.com. Getting the referrer to that it looks like adstairs.ro redirected to lifeinsidedetroit which redirects to the exploit kit. Looking at adstairs.ro we can see that it was loaded by www.earsurgery.org. So the path of the client looks like www.earsurgery.org -> adstairs.ro -> lifeinsidedetroit.com-> qwe.mvdunalterableairreport.net. Looking at this we can hypothesize that www.earsurgery.org was compromised but lets confirm that by looking at the source of earsurgery.org. For some reason CapTipper does not get the index html for me so I just clicked on the first GET on earsurgery.org and followed the tcp stream. Save the response and open it up in your preferred editor. Then search for that adstairs url we found earlier. You should find a flash object that is setup that embeds the adstairs.ro script. Honestly at first when I only saw the traffic flow I thought it was malvertising but looking at the source it appears that the website was actually hacked by some method and the attackers made their url look similar to an ad site to try to delay detection. I did some more analysis to determine how the load balancing was working but it is more of the same so I'll just summarize. The way the exploit kit authors do this is strange. The adstairs swf loads content from the url that is passed to it in the FlashVars I think this is to allow for malleability and usability. You can think of the swf hosted at adstairs to literally be a shell that is filled with whatever content is passed to it. That content is retrieved from lifeinsidedetriot. That domain's php script acts as the loadbalancer and the strings that are passed to it are used to separate different compromised urls etc. Now this next conclusion is mere speculation but I suspect that the attackers who compromised the site and own adstairs.ro are simply costumers of the EK's host so the load balancer also acts to separate customers so that the proper binary is deployed.
BYE!
Setup:
First you will need a couple of tools to follow along. I use these but I am sure there are other ways out there, use what your are comfortable with.
- CapTipper: https://github.com/omriher/CapTipper
- WireShark: https://www.wireshark.org/
- JPEXS: https://www.free-decompiler.com/flash/
Note: JPEXS is only necessary if you want to decompile the swf of the flash exploits to mess around with them.
I also highly recommend setting up wireshark this way for easier analysis of web traffic: http://www.malware-traffic-analysis.net/tutorials/wireshark/index.html
We will be analyzing this file: http://www.malware-traffic-analysis.net/2014/12/04/2014-12-04-traffic-analysis-exercise.pcap
Basic Identification:
The first step in analysis is to determine some basic information such as the ip of the compromised host and the exploit kits landing page. So lets open the pcap up in both wireshark and CapTipper to open it in CapTipper use the command: python CapTipper.py -s <name of pcap file>. The -s is just because we do not want to use the web server feature since it would be somewhat dangerous considering it would be practically be like mirroring an exploit kit onto a server. I recommend making CapTIpper.py executable and soft linking it to your bin folder for ease of use. Once you have it open in CapTipper it should show you a list of conversations:
Also limit your wireshark view to http requests by using the filter http.request. With a quick glance at wireshark we can see that the only client throughout the capture is 192.168.137.62 so we can assume that this is the compromised client; however, to prove this we can look at CapTipper. Scrolling through my eyes were drawn to request 52 since CapTipper thinks a binary was dropped. Lets hexdump it to see whats up there. The syntax is hexdump <req> <number of bytes>. I dumped just the header and suprise where the magic number for an executable should be there are some seemingly random numbers and the usual string is not there. This indicates the binary is encrypted (most likely with a simple xor). Knowing that makes it extremely likely that this is the exploit kit's payload. For further confirmation I dumped about 2000 bytes. Here we see something strange at around 0550 and at 0700. Signatures like this are often listed by researchers so lets do a little google magic. I found this link: http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html which indicates that this is the xor key for Angler EK so we could decrypt this binary if we wanted to using xortools, but this confirms that this host is the malicious site. Type info 52 to find out information about the request that lead to the download. So looks like qwe.mvdunalterableairreport.net is the host. Now we should go about finding the landing page. To do that we should find the first time the client hits that host. Type hosts into captipper and find qwe.mvdunalterableairreport.net. You should see that 49 is the first request to the EK. To confirm that this is the landing page we should dump this to a file. First we have to expand the file since it was compressed, the syntax for that is ungzip <req>. The syntax to dump a request is dump <obj> <dump file>. Dump the object that CapTipper created, but be careful and dump it with a different extention to html to avoid accidentally infecting yourself just in case (I believe the host is down but I have not checked). Open the file in a text editor and you will see something strange. If you are not familiar with Angler the strange text at the top might confuse you. These strange headers are often included on Angler landing pages. The obfuscated script at line 200 further confirms that his is the landing page. You can use jsbeautify to get a better look at the script.
Extraction and deobfuscation:
Alright lets drill down on one of the exploits it tried to serve up. Lets look at the flash exploit since it takes more effort to extract than the html exploit. Dump 63 since that is the swf that the host serves up. Now you need JPEX to decompile the swf. First you need to decompress it which can be done with ffdec -decompress <infile> <outfile>. Then you can export the scripts and elements of the flash file by using ffdec -export all <outdirectory> <infile (outfile from before)>. To make this exploit usable we would have to deobfuscate the actionscript which is quite complex and I am not nearly qualified to try to teach the process as I am not sure I could deobfuscate it myself. If people want to post some sources or advise on that topic that would be great.
General Attack Flow:
After drilling down now we can zoom back out and look at the general flow of the attack using wireshark. Looking at the first couple requests, the host visits google then searches earsurgery.org and clicks on the link. That traffic is pretty normal. Now that we hit earsurgery.org we see it has the client make a bunch of GET requests. I found it easier to work backwards in this case. So lets click on the landing page (first request to qwe.mvdunalterableairreport.net) and open up the HTTP Headers. Looking at the headers we can see that the referrer is lifeinsidedetroit.com. Getting the referrer to that it looks like adstairs.ro redirected to lifeinsidedetroit which redirects to the exploit kit. Looking at adstairs.ro we can see that it was loaded by www.earsurgery.org. So the path of the client looks like www.earsurgery.org -> adstairs.ro -> lifeinsidedetroit.com-> qwe.mvdunalterableairreport.net. Looking at this we can hypothesize that www.earsurgery.org was compromised but lets confirm that by looking at the source of earsurgery.org. For some reason CapTipper does not get the index html for me so I just clicked on the first GET on earsurgery.org and followed the tcp stream. Save the response and open it up in your preferred editor. Then search for that adstairs url we found earlier. You should find a flash object that is setup that embeds the adstairs.ro script. Honestly at first when I only saw the traffic flow I thought it was malvertising but looking at the source it appears that the website was actually hacked by some method and the attackers made their url look similar to an ad site to try to delay detection. I did some more analysis to determine how the load balancing was working but it is more of the same so I'll just summarize. The way the exploit kit authors do this is strange. The adstairs swf loads content from the url that is passed to it in the FlashVars I think this is to allow for malleability and usability. You can think of the swf hosted at adstairs to literally be a shell that is filled with whatever content is passed to it. That content is retrieved from lifeinsidedetriot. That domain's php script acts as the loadbalancer and the strings that are passed to it are used to separate different compromised urls etc. Now this next conclusion is mere speculation but I suspect that the attackers who compromised the site and own adstairs.ro are simply costumers of the EK's host so the load balancer also acts to separate customers so that the proper binary is deployed.
BYE!
No comments :
Post a Comment