Zeus malware. Packet capture analysis with Wireshark

I analyze a PCAP file that was captured on a machine infected with the Zeus malware.

In this blog post, I will analyze a PCAP file that was captured on a machine infected with the Zeus malware. The analysis will be run with Wireshark. The packet capture comes from the Malware-Of-The-Day archive on Active Countermeasures.

Zeus malware

Zeus is a Trojan-Banker, which is a type of malware designed to steal user account data relating to online banking systems. Terdot, a new evolution of Zeus, can also eavesdrop on and modify traffic on most social media and email platforms.

This is the setup of the lab for the Zeus malware on Active Countermeasures.


We will first get an overview of the malicious activity on this system by listing HTTP requests1. Then, we will analyze the conversations between the infected system and the C22 server.

We download zeus_1hr.pcap from here to our Kali Linux 2020.3 instance. We will use Wireshark 3.2.5 for the analysis.

HTTP Requests Analysis

We launch Wireshark and open zeus_1hr.pcap. Next, we list HTTP requests by HTTP host. What to select on the Wireshark GUI is listed under each screenshot.

Statistics > HTTP > Requests
117 HTTP requests (more than 95% of all HTTP requests) with the same string are made to a suspicious domain.

The first thing that stands out is that more than 95% of all HTTP requests are made to mahamaya1ifesciences.com. All 117 of them request the same JPG file. Let’s analyze each single HTTP host:

  • ocsp.digicert.com: This seems legit. OCSP is a protocol that checks whether an SSL certificate has been revoked.
  • tile-service.weather.microsoft.com: This seems legit. This is used to download updates to the Weather app Live Tile.
  • This seems legit. This is the IPv4 site-local address for the network protocol Simple Service Discovery Protocol.
  • mahamaya1ifesciences.com: This is suspicious because it modifies the legit domain mahamayalifesciences.com by replacing the “l” with a “1”. A quick search on the Internet shows that this is a known Zeus C2 domain.

TCP Stream Analysis

The next step is to zoom in onto the conversation between the infected machine and the C2 server. First, we need to find out the IP addresses of the machines involved. The target machine’s IPv4 is, whereas the C2 server’s IPv4 is as described in the lab setup3. By looking at all the conversations, we notice that and exchanged more than 25,000 packets (28 MB). This makes them the conversation pair with more traffic.

Statistics > Conversation > IPv4 and are the conversation pair with more traffic.
Right-click on conversation > Apply as Filter > Selected > A<->B
This updates the filter for the Wireshark instance so that we can zoom in onto the conversation between and

By updating the filter, we now only see the conversation between and Next, we follow the relative TCP stream and read the server response to the HTTP requests from the infected machine.

Right click on No. 1 > Follow > TCP Stream
This is the payload that the C2 server ( sends to the infected machine (

By following the TCP stream, we see that the C2 server sends a PowerShell command to the infected machine. This is made clear by the use of IEX. This is the alias for Invoke-Expression, which is a PowerShell cmdlet4. In this instance, IEX runs a command that decompresses and reads a gzip stream. This is done using System.IO modules.

All in all, we analyzed a PCAP trace with Wireshark and found out with a few clicks that the Zeus malware delivers its payload by a PowerShell one-liner5.

I hope you liked this post. If you have any questions, feel free to leave a comment in the comment section. Never stop learning!

How I made my website more secure

I will describe how I made my website more secure by integrating a free SSL certificate into my WordPress website with the Really Simple SSL plugin.

In this post, I will describe how I made my website more secure by integrating a free SSL1 certificate into my WordPress website with the Really Simple SSL plugin. Before doing that, I will give a brief introduction about how data is transferred over the Internet, and why encrypting and signing that data is very important.

Data over the World Wide Web is transferred with the HTTP (Hypertext Transfer Protocol) protocol2. HTTP messages can be categorized in two main groups: requests and responses. I will now briefly describe what HTTP requests and responses are.

An HTTP request is generated when a user interacts with their web-browser (e.g., Firefox). For example, when a user enters info.cern.ch in their URL bar and press enter, their browser will send a series of HTTP GET requests in order to get the information necessary to render that page.

The image here below, which I took while monitoring my WiFi traffic with Wireshark,3 shows how such a request looks like:

Example of an HTTP GET request

HTTP requests go to a server4 and that server generates an HTTP response which looks similar in its form to an HTTP request. As you can see, HTTP responses and requests are sent across the Internet as plain text. This means that any data, sensitive data included, that users send or receive can be read by anyone who is monitoring the session. Another problem with HTTP is that the recipient of a message cannot be confident that the message was sent by the legitimate sender, and that it hasn’t been changed while in transit.

The solution to this problem is called HTTPS, where the S stands for secure. HTTPS uses TLS/SSL5 to encrypt HTTP requests and responses. In this way, anyone monitoring your traffic will only see gibberish. Moreover, TLS/SSL signs your data. Both these results are achieved by using public and private keys6.

This is how a TLS/SSL encrypted HTTP request sent to my own website looks like when monitored with Wireshark:

Example of an HTTP over TLS request

My website didn’t have HTTPS when I opened it. In order to provide secure communication from/to my website server, I first got hold of an SSL certificate and then integrated it into my WordPress website using the Really Simple SSL plugin.

An SSL certificate is a data file hosted on a website’s origin server. It is what enables websites to move from HTTP to HTTPS7. It is possible to obtain a SSL certificate from Let’s Encrypt8 for free. Let’s Encrypt certificates need to be renewed every 90 days.

In order to request a Let’s Encrypt SSL certificate I first had to connect to my server via SSH9. After updating the packages on my instance, I installed Certbot – a client used to request a certificate from Let’s Encrypt and deploy it to a web server.

The next step was to request a Let’s Encrypt SSL wildcard certificate10. In order to do so, I had to prove that I owned the domain I asked a certificate for. I did this by adding TXT records to the DNS records of my domain. Once the TXT records had been propagated to the internet’s DNS, I completed the Let’s Encrypt certificate request.

As Certbot saved my SSL certificate, chain, and key files into /etc/letsencrypt/live/michelepariani.com/, I created links to these files in the Apache directory11 on my server.

Finally, I installed the Really Simple SSL plugin on my WordPress website and used it to integrate the SSL certificate with a few clicks on the website admin page.

A detailed tutorial about the steps described above can be found here: https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-using-lets-encrypt-certificates-with-wordpress.

I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!