Analyzing 404 Keylogger / Snake Malware Network Traffic with PacketSnitch

I recently got my hands on a packet capture containing traffic from 404 Keylogger / Snake malware (thanks malware-traffic-analysis.net ), and decided it would make a good real-world test of PacketSnitch, the network analysis software I have been developing. PacketSnitch is designed to take PCAP/PCAPNG captures and turn the raw traffic into something a little easier to tear apart: hosts, streams, credentials, files, certificates, geographic information, protocol data, content classifications, and other useful artifacts are correlated together instead of leaving you to manually dig through thousands of packets one at a time. Malware traffic is a particularly good usecase for this, because sometimes the interesting part isn’t one individual packet, but what several different connections tell you when you start putting them together.

For anyone who would rather watch me go through the capture, I also recorded a screencast of the 404 Keylogger/Snake analysis. The complete report generated from the capture is also available as a PacketSnitch malware analysis summary.

What is in the capture?

The PCAP itself is relatively small: 2,021 packets spread across 11 streams totaling about 2.26 MB, but there is quite a bit going on inside it. Eight hosts were observed, six of which were Internet hosts, and PacketSnitch decoded DNS, FTP, HTTP, and WebSocket traffic over TCP/UDP. What immediately makes this capture nice for analysis is that almost none of it is encrypted. Out of 2,021 packets, 2,018 are unencrypted, leaving quite a bit of application data hanging out in the open.

The internal machine at 10.1.14.131 is involved throughout the capture, while several external hosts start becoming interesting once we look at what they were actually doing. The largest remote conversation is with 23.39.148.32, an Akamai-associated address, at 1,570 packets. More interesting from the malware-analysis perspective are 91.92.243.152, 193.122.6.168, and 188.127.239.250. Taken independently, none of those connections necessarily tells us much. Taken together, however, we start getting something that looks considerably less like normal user traffic.

An interesting HTTP payload

One of the first things that really stuck out was an HTTP request to 91.92.243.152 for a strangely named file:

1

GET /dealer/agwofile.txt HTTP/1.1

The remote server answered with HTTP/1.1 200 OK and returned roughly 360 KB of text data. The headers identify the server as Apache 2.4.58 running on Win64, with PHP 8.0.30 and OpenSSL 3.1.3 also disclosed by the server. Despite being served as text/plain, the contents aren’t something that resembles an ordinary text document. PacketSnitch measured the data at around 4.91 entropy and identified the beginning of the object as long Base64-like/encoded-looking ASCII data.

That is exactly the sort of thing I want to notice when looking at malware traffic. An oddly named .txt file by itself isn’t particularly exciting. An oddly named .txt file containing hundreds of kilobytes of encoded-looking data, being transferred by a suspicious host in a malware capture, deserves a much closer look.

More interestingly, reconstruction and analysis of the HTTP data exposed what appears to be a credential-stealer artifact. The recovered data contained a “VIP Recovery” style log referencing a machine named DESKTOP-WIN11PC, with credential-related information from Thunderbird as well as Edge/Chromium browser data associated with sites including eBay, Amazon, Facebook, and LinkedIn. That starts giving us a much better idea of what the malware traffic represents: we’re not just looking at random HTTP requests, but traffic associated with collection and movement of potentially stolen information.

Credentials flying around in cleartext

The HTTP traffic wasn’t the only interesting part. PacketSnitch’s keystore picked up credential material associated with an FTP endpoint at:

1

188.127.239.250

The FTP authentication information occurs across several packets in the capture. Because FTP authentication is plaintext, this is exactly the sort of thing that falls right out of a PCAP once the protocol is decoded. PacketSnitch correlated these artifacts into its keystore along with HTTP URI/URL information, TCP secrets, and a certificate observed elsewhere in the session.

This is one of the reasons I added the keystore functionality in the first place. When you’re analyzing a capture, I don’t particularly want to search through 2,000 packets wondering if a username, password, certificate, URL, or other useful piece of data appeared somewhere. If PacketSnitch can identify it while decoding the traffic, it gets pulled out and put somewhere useful for the analyst.

There is an important distinction here, too: finding FTP credentials in a packet capture does not automatically tell us whether they belong to the malware operator, a compromised machine, a staging server, or something else entirely. It gives us another artifact to correlate. Malware analysis is usually a lot more useful when you resist the temptation to immediately label every IP and credential you find and instead start building relationships between them.

The malware checks its public IP

Another connection that caught my attention was an HTTP request involving checkip.dyndns.org. The request uses an ancient-looking User-Agent:

1

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR1.0.3705;)

The service responds with its normal “Current IP Check” page containing the externally visible IP address. The same IP-check behavior appears more than once in the decoded traffic.

This is useful behavior to identify because malware frequently needs to know something about the environment it is running inside. Discovering the public IP can be useful for identifying a victim, tracking an infected system behind NAT, associating collected data with a machine, or simply reporting network information back as part of the victim profile. By itself, querying a “what is my IP” service obviously isn’t malicious — plenty of legitimate software does that — but sitting beside credential-stealing artifacts, FTP authentication, and unusual HTTP transfers, it becomes another piece of the puzzle.

This is also a good example of why context matters so much in packet analysis. Looking only at that HTTP request gives you “a program checked its public IP.” Looking at it in the context of everything else gives you “a machine involved in suspected credential-stealing activity checked its externally visible IP while also communicating with several other pieces of infrastructure.”

Following the trail

Overall, the traffic looks like a combination of host identification, credential activity, and data transfer/staging. PacketSnitch classified content in the capture as everything from ordinary ASCII through compressed/binary and executable-looking data. MIME detection included application/octet-stream, application/x-dosexec, application/zlib, text/plain, and text/html, among others. These signatures shouldn’t individually be taken as proof that each corresponding file type was intentionally transferred — file identification against arbitrary network data can generate some weird matches — but they give us useful places to start digging.

One thing I found particularly useful about this capture is how clean it was from a network-analysis standpoint. There were zero undecodable packets and zero TCP retransmissions, with only six out-of-order segments. That makes reconstructing the application data considerably nicer than working with a noisy or incomplete capture. PacketSnitch was able to correlate 1,753 packets through its heatmap and pull the higher-level artifacts together without losing the ability to drop down into individual packets and streams when something looked interesting.

And that is really the idea behind PacketSnitch. Wireshark and other packet tools are incredibly useful, but I wanted something aimed more directly at answering “what is interesting in this capture?” before I start spending hours manually dissecting it. PacketSnitch takes the capture, inventories the hosts and protocols, extracts things such as credentials and certificates, identifies transferred content, correlates streams and endpoints, performs threat-intelligence enrichment, and then gives me places to start digging deeper. The analyst still has to decide what the evidence actually means — which is exactly how it should be.

Conclusion

This 404 Keylogger/Snake capture ended up being a pretty good demonstration of that workflow. Starting with only a couple thousand packets, we can quickly move from “some Windows machine talked to some Internet hosts” to identifying a large suspicious HTTP transfer, recovered credential-stealer data, plaintext FTP credentials, repeated public-IP discovery, and the infrastructure involved in those conversations. From there we can start pivoting on the hosts, credentials, payloads, timestamps, and other indicators to figure out what belongs to the malware and what is simply incidental traffic.

If you want to dig through the complete results yourself, I published the full PacketSnitch-generated analysis here. I also recorded a video walkthrough of my analysis, where you can see the actual workflow inside PacketSnitch rather than just reading the final results.

PacketSnitch itself is open source and available from packetsnitch.com. I’m actively developing it, and real malware captures like this are some of the best tests I have found for figuring out what an analyst actually needs when staring at a pile of packets.

Hope you’ve enjoyed the analysis, and happy hacking!