Decoding malware SSL using Burp proxy

When performing dynamic analysis of malware, you will occasionally encounter SSL being utilized for network communication, thus preventing you from analyzing the content.  Typically Wireshark is utilized to examine network traffic at the packet level. Wireshark has an SSL dissector that allows for the decryption of SSL traffic if you provide the decryption keys. This technique is described in detail on the Wireshark wiki.   However, I prefer to use an intercepting proxy to attempt the SSL analysis. The proxy will use its own SSL server certificate to negotiate and establish an encrypted session with the remote host. Essentially you are using the proxy to "Man-in-the-Middle" the malware's connection to the remote server.

My proxy of choice is BurpSuite, however you can utilize other proxies such as Paros, Webscarab, or Fiddler.  Burp has a very cool feature called "Invisible proxying" that handles non-proxy style requests.  This can be of good use when the malware you are analyzing generates its own HTTP or HTTPS requests outside of a browser framework.

I'll first provide an example where a particular malware specimen was utilizing SSL to communicate with Craigslist.  In this case, the malware appeared to be retrieving a variety of fake postings associated with various email addresses.  The posting title and description contained what is likely encrypted data.  The following image shows Wireshark displaying SSL traffic between the malware infected host and Craigslist.  The SSL negotiation and data are evident in the stream, however being SSL, you can't read it !

However when using Burp as an intercepting proxy, you can easily see the SSL traffic and get a pretty good idea of what the malware is doing.  Here, you can see the client GET to https://post.craigslist.org

The following images show the Raw, html, and rendered page views of the server response.

Burp also allows you to export the proxied traffic to an XML file. There is also an option to Base64 encode all requests and responses. The image below shows an example of the exported data.

Now that we've seen an example of SSL decoding using Burp, I'll describe the basic setup and configuration of my environment.  You certainly don't have to use this exact setup, as I'm just describing what I do and what works for me.  Make adjustments accordingly to suit what you are using.

• I use VMWare workstation Version 7 on an Ubuntu Linux 10.04 Server host. My guest virtual machine is Windows XP SP3. The virtual machine is setup in bridged networking mode.  I have the Burp proxy and Wireshark installed on my linux host.

• You will need to allow the linux host to forward network traffic from the virtual machine. In order to do this, you need to enable IP forwarding via the following:
• user@linux1:~$ sudo su
• root@linux1:/home/user# echo 1 > /proc/sys/net/ipv4/ip_forward

• Next, you'll need to setup an iptables rule to redirect http and https traffic to the Burp proxy which is listening by default on port 8080. This is done via:
• user@linux1:~$ sudo iptables -P FORWARD ACCEPT
• user@linux1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
• user@linux1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8080

• Boot your guest virtual machine and manually configure your network settings as follows:
• Manually set the IP address of the guest to an unused IP address on the same subnet as your linux host
• Set the Gateway to the IP address of the your linux host.
• Set the DNS server IP address to that of a host on your subnet that will forward DNS requests. This isn't strictly required, as you can also set it to any public DNS server. For consistency, I set mine to my local router.

• Turn OFF the XP Firewall.

• Configure Burp to do invisible proxying and to listen on all interfaces.  If you don't want Burp to intercept each request, you can disable that at this time.

• Shutdown your guest virtual machine and take a snapshot.  Restart the guest and test the proxy by browsing to any web site. You should see the traffic in Burp.  If you browse to a site using https, you will also see a browser warning error about the SSL certificate. This is because the certificate presented by Burp is not signed by a trusted authority, so the browser gives a warning.  Keep this in mind as we begin to see malware utilizing SSL certificates.  Now, you can shutdown the guest VM, revert to the recent snapshot, and be ready to go.  I also like to run wireshark on the host to match up the packet level traffic with the Burp data.   I'd recommend using a capture filter on Wireshark that only captures traffic to/from the guest VM.

This post showed how the use of an intercepting proxy can allow you to decode an SSL traffic stream and better support your dynamic malware analysis efforts.  Decoding SSL traffic is just one small part of what can be done with this tool.  It's well worth the investment to utilize an intercepting proxy with its many other features as a routine part of your analysis process.