.png?width=40&height=40&name=search%201%20(1).png){kind=small}
One of the best ways to learn how to protect against malware is to learn how to detect malware traffic. Towards this end, we are constantly searching the Internet for as many types of malware pcaps as we can find.
This blog focuses on the use of a fake SSL session where the TCP session starts with an SSL handshake but doesn’t actually do the handshake – it is a fake.
We will also show in this blog how to detect this type of fake SSL using the powerful yet flexible pcap analytics.
Join me in this deep dive...
A research group in the Czech Technical University in Prague has published a relevant and interesting list of malware pcap files. While studying this pcap file, a specific SSL session caught my eye. While a typical SSL handshake sequence starts with the client side sending CLIENT_HELLO message and the server side sending the messages SERVR_HELLO, CERTIFICATE, SERVER_HELLO_DONE, I did not see any sign of the SERVER_HELLO or CERTIFICATE messages in the following pcap:
While it is true that a Server CERTIFICATE message could be so big that is spans over 1 or 2 packets, I have never seen a server side message so big that it could span over at least 8 1514-byte TCP data frames! My curiosity lead me to examine the TCP data of the first server data packet (see the highlighted part in the following):
This data is by no ways an SSL message, which has a very well-defined structure. A typical such response would start with something like (all hex): 22 03 01 00 51. The “01” and “00 51” may change slightly due to the version and the actual length, but it's clear that the server response in the pcap (highlighted part in the above snapshot) is not an SSL message.
This is not surprising, since we should be anticipating malware traffic in such samples, but it is still very interesting to see this “new” method of evasion being employed in C&C communications.
So, how do we detect this evasion automatically? The idea is simple: if the first data packet from the server side doesn't begin with bytes 0x22 and 0x03 on a connection to port 443 (the standard SSL port), there is something suspicious. The challenge is how to implement this simple idea. If someone plans on using Wireshark to do the search/detection, he/she will immediately run into the problem of specifying the first data packet from the server side. Wireshark does not support stateful packet searching, which is required in the logic for this simple technique. Fortunately, CapStar Packet Analyzer (CPA) is designed from the start to support stateful search and is, in fact, the perfect tool for this.
The following is a simple analytic that can perform this logic and find these fake SSL sessions:
|
int marked; data: |
The output shows that there 3 such fake SSL sessions:
In the above analytic, we use the per-session variable “marked” to indicate when a session is marked. By default, it is 0. If we encounter a server data packet that is the first server data packet for this session, we will check whether the first two bytes are as specified. Regardless, we set the value of this variable (session.marked) so we will know not to bother analyzing other packets in this session.
CPA not only has the most flexibility when it comes to performing complex packet analysis and search, but it also performs these actions very fast. CapStar can chew through 1GB of pcap data in a second, making it easier for an investigator to quickly test out various ideas. This speed and flexibility can greatly improve the productivity of a security investigation where the investigator will never need to worry about the following dilemma facing many talented investigators: "Should I spend the next 2 hours writing a script to do the search for a complex, potentially promising pattern, knowing that the result may not be interesting and I may end up wasting the 2 hours?"
In this blog, we provide a detailed explanation of how to automatically detect a fake SSL session with CPA. If you want to know more about the capacity and power of CPA when it comes to analyze huge pcaps, or if you would like to have a demo, or try an evaluation, please don’t hesitate to send us a note at info@capstarforensics.com.