SANS Digital Forensics and Incident Response Blog

I was looking for a good example to highlight two very useful and often overlooked features of Wireshark: the flexibility of tshark and the tool suite's HTTPS/SSL decryption capability. The following example covers both, and goes a bit further to describe one way of investigating an attack to assess the likelihood of compromise. While contrived, make no mistake about it, this is reflective of a real-world attack seen recently, later linked to sophisticated adversaries.

We are in the business of risk management. As such, our response to suspicious activity should be guided by the components that risk is the product of. While terminology may vary, the breakdown I use is:

Impact

Vulnerability

Threat

An understanding of risk components in the context of a computer security incident is often evolutionary. Response changes according to the risk, which is constantly adjusted as the responders learn more about the potential impact to the organization, the vulnerability of assets targeted (or, conversely, success of the attack), and the actors behind the attack. Typically, the initial component addressed is vulnerability - was the attack successful. In the case of HTTPS attacks observed passively through network activity, answering this question can be very difficult. Indeed, without access to webserver logs, all investigations of intrusions that intersect HTTPS in any way are made much more difficult since no data above OSI layer 4 is visible.

Tipoff

In our example, we are informed by a network activity monitor that web traffic increased significantly to a particular server on our network - over 50% increase in 2 days.

Figure 1: 7-day moving average for web traffic to 10.1.1.55

This exposed server is in a DMZ, but provides proxied access to sensitive information (impact) and has had problems in the past (clue into potential vulnerability). At the same time, we are told by a partner that they had just experienced a compromise of a server by a sophisticated adversary intent on stealing intellectual property (targeted attacks for the purposes of stealing specific data - as high a threat level as you will find). While normally an increase in web activity could be the result of any number of thingsand would go ignored in a large company, the level of risk here, based loosely on the information available, seems that it could be very high. Even in the case of no compromise, the risk level is probably high enough to warrant investigation and follow-up to mitigate against the threat in the future.

Investigation

While contacting the administrator is always a good idea at this point, it's not always possible. That, and administrators tend to "help" by "fixing" the server in question and trampling valuable evidence. We'll proceed as far as we can without leveraging this option.

Responding to the incident in a timely manner, on a well-instrumented network, we are fortunate to have full packet captures over the period in question. Let's use tshark to take a look at the requests.

Tshark gives us access to the full suite of capabilities of Wireshark, using the same field reference nomenclature. Above, we see the default output. Notice how much it looks like Wireshark! Filtering works the same as it would in Wireshark, as a matter of fact. Let's take a look at the server in question:

So what's going on here? Perusing through the data, we see requests for multiple sites, and HTTPS requests (rut roh). Here's where tshark's field selection can come in handy. Using the same nomenclature as Wireshark, we can filter on anything Wireshark has access to, and also select any fields Wireshark has access to! Below, we'll look for all HTTP requests, and select the "hostname" field using the "-T fields" option.

Don't forget we saw that SSL activity too! I think you're probably getting the hang of tshark by now. Plotting this out, we see how dramatically SSL activity increased in one day, to cause the 7-day average to increase 50%.

Figure 2: Request trends for 10.1.1.55

If this is an attack, it's very wisely executed. While our traffic profile changed, we have no idea what happened in those HTTPS connections. If it was an attack, what kind was it? Was the attack successful? We can't answer these questions until we see what's going on inside those sessions. We've seen tshark's power, and by now you can imagine how to go about tearing apart those HTTP connections. Let's say there was nothing suspicious in there. What remains in assessing the situation is removing the SSL veil that accounts for the bulk of this activity.

Digging into the crypto

At this point, there is no avoiding getting in contact with the administrator. Wouldn't you know, the web service wasn't configured properly (surprise, surprise) and logging is disabled. Your only hope of explaining the activity is by decrypting the packets you've captured with the private key. NEVER FEAR! Current versions of wireshark, and therefore tshark, support session decryption if you can provide the private key. The only trick is a little bit of configuration - and, of course, getting the key in the first place.

We'll start with Wireshark. Looking at the data from the pcaps, we see the encryption makes the contents opaque.

Figure 3: HTTPS as seen by Wireshark

Fortunately, all we have to do is add a configuration parameter to Wireshark's preferences for the SSL protocol. The format is <ip>,<decrypt protocol>,<key file>.

Figure 4: Wireshark configuration menu for SSL decryption

Now, Wireshark decrypts the session and we can see into the packet.

Figure 5: Decoded HTTPS as seen by Wireshark

It really is that easy. Now, of course, you want to analyze this data statistically, and make broad statements about the attack. As a command-line tool, as we've already seen, tshark is scriptable and far more suited to our needs here. Once again, decryption is simply a matter of tool configuration, which means leveraging tshark's '-o' parameter to specify a preference setting, which will be the exact same text as provided in the SSL configuration of the GUI. IMO, this is even easier than the GUI tool, and provides the flexibility analysts need to assess what happened statistically via alternate scripting tools.

Well lookie thar! Of course, now we can do all (well, most of) the other field filtering tricks to select output once again, just as we did in the previous sections. The primary goal of this entry having been met, I'll leave that, and how to assess attacker success, as an exercise for the reader.

Michael is a senior member of an incident response team for a large defense contractor. He has lectured for various audiences from IEEE to DC3, and teaches an introductory class on cryptography. His current work consists of security intelligence analysis and development of new tools and techniques for incident response. Michael holds a BS in computer engineering and has earned GCIA (#592) and GCFA (#711) gold certifications alongside various others.

6 Comments

gleeda

Very interesting! One thing, it looks like you might have left out the port number in the Wireshark preferences window:"''The format is ,,.Figure 4: Wireshark configuration menu for SSL decryption"From the picture it shows:",,,"(hopefully the brackets show up correctly, I did html just in case)

trustedsignal

frost57565

Unfortunately, SSL decryption is often impossible these days. Modern web browsers and servers use ephemeral Diffie-Hellman ("DHE" or "EDH"), which uses the server certificate/key pair for authentication but then generates random keys for the encryption. Wireshark will report "dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39" or some such (0x39 is the index for cipher suite "TLS_DHE_RSA_WITH_AES_256_CBC_SHA").

mikecloppert

Interesting comment regarding Diffie-Hellman. In the handful of incidents which I have worked where HTTPS required analysis AND the server private key was available to me, Wireshark/tshark has not had any problems decrypting. I cannot say for sure whether EDH was being used (at that point I didn't care), but I will say that the client and server were both modern/recent versions.I'd be interested to hear the experiences of others as well.