The percent of encrypted web traffic has doubled between 2015 and 2019. In this article, you'll learn how to make the best use of packet captures for troubleshooting even when the information you need has been encrypted.
Tracking down BitTorrent activity with packet captures We love the exercises at malware-traffic-analysis.net, and occasionally we’ll pick some that we try to solve using CloudShark and its tools.
This time however, we’re going through one armed with tools that we learned from Brad’s class (the author of malware-traffic-analysis) at Sharkfest US 2018, where he gave an in-depth class on using packet captures for malware analysis, as well as a presentation on Analyzing Windows malware traffic.
In August of 2018, the Internet Engineering Task Force (IETF) moved Transport Layer Security (TLS) Version 1.3 to RFC 8446. In the world of networking standards, this means it has been properly vetted by the community and is officially ready for showtime on clients and servers.
About these captures
We're able to look at TLS 1.3 handshakes thanks to support for the protocol
in tshark 2.6. CloudShark 3.5 and later versions have support for TLS 1.
During the last week of February in 2018, several big internet sites started seeing a huge increase in a particular style of DDoS attack, taking advantage of the memcached protocol. Being the packet geeks we are, we wanted to explore the attack on one of our own internal servers and get a capture of what’s happening at the packet level so you can see it in action.
What is memcached?
CloudShark developer and packet guru Tom Peterson gives us another example from malware-traffic-analysis.net to learn how to best use CloudShark and our Threat Assessment add-on to get to the root of malicious activity. Let’s join him now for his latest exercise.
The exercise: Two Malicious E-mails, Two PCAPs to Analyze In this exercise, we need to find out what happened when some users downloaded some suspicious attachments and executed the attachments contained therein.
As many are aware (as it’s now become national news), a vulnerability was recently discovered in OpenSSL dubbed Heartbleed. The attack centers around the implementation of the Heartbeat extension in OpenSSL which causes a server to return the contents of memory that should be protected. This blogpost by Troy Hunt describes the vulnerability in detail: Everything you need to know about the Heartbleed SSL bug.
Being packet geeks, naturally we wanted to get a capture of the Heartbleed attack in action.
While CloudShark’s packet capture holding capacity is limited only by the size of the disks available to it, many of our CloudShark users are curious about what to do if they want to automatically delete captures after a certain period of time. Some may have certain security requirements about capture contents, or others want to make sure that sensitive data isn’t used for nefarious purposes later.
Whatever the reason, automatically deleting captures is possible with a little scripting and the CloudShark API.
If you don’t already know, one of CloudShark’s main features is the ability to manage RSA keys and allow those keys to be used to decrypt SSL traffic, allowing users to view encrypted data without ever having to give out your RSA keys.
But what about other types of encryption? We were recently approached about support for Kerberos in CloudShark captures. CloudShark can actually support the decryption of Kerberos encrypted data using the Wireshark preferences file that we showed you before for fixing your RTP decode settings.
Note: Here is Intel’s official statement - it is important to note that this had little to do with Intel and only a specific manufacturer.
In 2013, the creator of AstLinux, Kristian Kielhofner, discovered a bug in certain model and version of Intel based Gigabit Ethernet implementations that can result in a “packet of death” that will bring down the network interface, requiring a power cycle of the interface in order to restore functionality.
Years ago, an apparent Man-In-The-Middle (MITM) Attack on the popular code sharing site github.com occurred, which seemed to originate from China for users trying to traverse the “Great Firewall”. This was strange, as there had been many news stories not even two days before about China blocking and then subsequently unblocking access to github.
Whatever the reason, a subject of the attack was able to create a packet trace of it, and uploaded it to our free cloudshark.