Cyber attack analysis with Wireshark

Posted on December 14, 2025 by tutorials 0

Wireshark is an amazing tool. While most people use Wireshark as a traffic capturing, and protocol analysis tool, it can do a lot more than that. In this blog post, we will walk through the steps of analyzing a multi-stage attack pcap file using Wireshark alone.

Go ahead and download Wireshark if you haven’t yet, and download the pcap file that we will use in this analysis. Once downloaded, unzip the file and open it in Wireshark.

  • The file has more than 103,000 packets. Therefore, we cannot examine all of them one by one. So, where do we start?
  • The first step is to look at the protocol hierarchy. Click on “Statistics” from the top menu, and then “Protocol Hierarchy”.

protocol

  • You can see that there is one ICMPv6 packet, which makes it unlikely to be the attack vector.
  • You can see there are 318 DNS packets, which makes it less likely that this is the attack vector. Therefore, we exclude DNS. Remember that DNS can also be abused, but in this context it is less likely, and therefore, we’re not inspecting it first.
  • The 22 ARP packets also are highly unlikely to be attack vectors. Most ARP attacks involve flooding (not all of them).
  • The most likely vector is HTTP because it is about 20% of the traffic, and then XML being 10%.
  • Close the statistics, and filter out ARP and DNS traffic using “!dns && !arp”
  • Next, try to locate the SSH traffic that we saw in the statistics. Add “&& ssh” to the filter, and you’ll notice that the SSH traffic is close to the end of the attack. Which means that the attacker probably gained access to SSH after succeeding in the first steps.
  • Therefore, we’ll leave SSH to the end. In general, there isn’t much that we can do since it is encrypted traffic. Remove the “&& ssh” from the filter.
  • By scrolling thought the remaining packets from the top, you will notice a large number of “HEAD” HTTP requests. What is HEAD used for?
  • This technique is used by attackers to enumerate files and folders by attempting common file names from a dictionary to see if any of these files exist and is accessible publicly. Mostly, the attacker tries to find any sensitive files that might contain passwords such as the database password, for example. Let’s filter to see these HEAD commands by adding the following to the existing filters && http.request.method == “HEAD”
  • Now, you’ll see that there are 137 of these requests. Which is not a usual number from a non-malicious actor. If you examine the responses to these requests, they’re all 404.
  • This can be considered the first step of the attack “File enumeration”. In this steps, the attacker is looking for sensitive files, such as wp-config.php, that have misconfigured permissions. If you look closer at the names of the files you’ll see that the attacker is trying to find a misconfigured file containing sensitive information such as the database username and password, which is usually stored in wp-config.php or backups of this file.
  • Another malicious indicator is the user-agent of the client request in these HEAD packets. This step ends at packet 326.

user-agent

  • This user agent is a well-known open-source offensive tool used to attack WordPress based websites.
  • Now, we move on with our analysis from packet 327 onwards.
  • The attacker tried to find if the website (now we know it is a WordPress website) supports the method called “wp.getUsersBlogs” using the XMLRPC API in the website. The website responds with 200, which means it is supported.
  • XMLRPC in WordPress is a backend method to access the website and connect it to mobile apps, or other websites.
  • You can see from there the attacker trying to access this service with different usernames and passwords. To see how many attempts, you can add the following to the existing filter:

http.request.method == “POST” && http.request.uri == “/xmlrpc.php”

  • You’ll see more than 10,000 attempts with varying usernames including (admin, jens, graham, mark, and sarah), and attempting different passwords for each of these users.
  • This is clearly a dictionary attack (a type of brute-force). We can consider it the second stage of the attack.
  • If we remove the additional filter we added previously, and scroll down from the last XMLRPC call, you can see the attacker visiting the admin page “/wp-admin/” and successfully logging packets 102789 to 102811. Actually, you can see the POST command in packet 102807 showing the username and password that the attacker successfully grabbed (mark, helpdesk01).

username

  • If you scroll down a few packets, to explore what the attacker did after login, you’ll see that they accessed a WordPress plugin called Plainview Activity Monitor.
  • Conduct a simple search online, and you’ll see that the plugin is actually vulnerable to a dangerous remote OS command injection vulnerability.
  • If you scroll down more, you’ll see the attacker exploiting this vulnerability using a POST command in packet 102996. The content of the packet shows clearly that the attacker created a reverse shell back to the attackers machine on port 9999. This looks very similar to the proof-of-concept code in the vulnerability exploit.
  • Now you can scroll down to see the reverse shell session going to port 9999 at the attacker’s machine. Right click on the first packet in the session and select “Follow” and then “TCP Session”. Now, you’ll see the whole exchange and everything the attacker did on the machine.

tcp

  • Reading through the session, you can see what the attacker did. What information did they get?
  • The username and password the attacker found on Mark’s desktop are probably the ones used to setup the SSH session. Mark is definitely going to be fired after this.
  • This concludes the third phase of the attack.

There isn’t much that we can do afterwards, because the SSH session is encrypted, and the attacker disconnected the reverse shell session. If we want to inspect this further, we would probably need access to some logs such as auth.log, and perhaps a command line log to see what the attacker did in the SSH session.

Decrypting Encrypted TLS Traffic Using Wireshark on Linux

Posted on April 18, 2024 by tutorials 0

Before we start, I have to clarify, this is not a way of “hacking” TLS to decrypt any encrypted traffic! This is (probably) not possible. What we will do in this tutorial is to temporarily extract the TLS session keys used in encrypting traffic going to the browser into a “TLS keys log file”, and then use this log file along with the captured pcap to decrypt the traffic and view it on Wireshark.

For this to work, you’ll need a browser such as Firefox, or Chrome, a Linux-based machine, and Wireshark.

First, make sure that you start Wireshark, but just don’t start capturing traffic yet. Then, close all open browser windows.

Second, use the following command:

export SSLKEYLOGFILE="/home/$USER/tlskeys.log"

This command, will instruct the OS to store all sessions keys in a file named tlskeys.log in the home folder of your user. there are a few things to note here;

This commands will work for this terminal session only. Once the terminal session windows is closed, the TLS keys will not be stored in the log file anymore. The storage of these keys applies to TLS keys of this process and all processes spawned from it only. this means that after running the command, if you start your browser from the GUI, the keys will not be stored. You need to start the browser from within the commands line. Before you do that, start capturing the traffic in Wireshark.

Now start your browser (such as Firefox) from the command line:

firefox &

Visit an HTTPS based website like, google.com and go through searches or even try to sign in. Then, stop the packet capturing, and take a look at the tlskeys.log file.

cat tlskeys.log

You’ll see a few session keys for each session. It’d probably look something like this:

 

Now, if you look at the traffic captured by Wireshark, you’ll see that it is encrypted, like this:

To use the TLS keys to decrpyt this traffic, go to Edit >> Preferences >> Protocols, and scroll down to get TLS. In the last field in the windows, you’l see “Pre-MasterSecret log filename”, click on “Browse…” next to it, and show Wireshark the location of the tlskeys.log file. Then, click “OK”.

Now, you’ll notice that the previously-encrypted TLS payload is now decrypted (mostly into HTTP2).

You’ll see that you’ll be able to extract a lot of HTTP objects that were not accessible before because of encryption.

 

How to Spoof a MAC Address in Linux

Posted on April 9, 2024 by tutorials 0

In some ethical hacking engagements, you might need to spoof the MAC address of a network interface card. This short list of steps help you do that:

1. Find the name of the interface you want to spoof the MAC of.

ifconfig

You’ll see interface names such as “eth0”, or “ens33”, depending on the Linux distro you’re using.

Note: If this command doesn’t exist, you can install the “net-tools” package through “apt”, “yum” or any other package manager you use.

2. Turn the interface off:

ifconfig ens33 down

Replace “ens33” with your interface name of choice.

3. Update the MAC address:

ifconfig ens33 hw ether 12:34:56:78:90:12

Replace the “12:34:56:78:90:12” with the MAC address of your choice.

4. Turn the interface on:

ifconfig ens33 up

That’s all!

 

Generating a Log file for Command Line Commands in Linux

Posted on April 3, 2024 by tutorials 0

This is one of these cases when you wonder why this isn’t there by default in all Linux-based systems. In many cases, it can be useful to look at the list of the command line commands that were used on a server, and perhaps look at the user accounts that were used to issue these commands. This could help accelerate forensic investigations and incident response. It could also help in identifying the scope of a breach.

In this short tutorial, we will use syslog services to capture all commands issued in the command line, the time of command issuance, the username of the account used, and if the command was issued using SSH, we will also capture the IP address that was used in this SSH session.

Step 1: Creating the log settings file, to tell the server where to store the log entries

Create a file named /etc/rsyslog.d/commands.confusing an editor of your choice, such as nano:

sudo nano /etc/rsyslog.d/commands.conf

Add the following two lines to the new empty file:

# Log every command executed by a user to a separate file
local6.* /var/log/commands.log

Save the file and exit. This will create a logger that would capture whatever you pass to local6 events and put it in the commands.log file.

Step 2: Configure your Bash shell to pass the information to the logger.

Edit your /etc/bash.bashrcfile to add these two lines:

# Set PROMPT_COMMAND to log every command to syslog
PROMPT_COMMAND='history -a >(logger -p local6.debug -t "[$USER] $SSH_CONNECTION")'
HISTCONTROL=null

The first command will tell bash to pass the required information to the logger called local6. The second command will tell the bash shell to capture all commands, including ones with spaces before them.

If you use other types of shell, such as zsh, or sh, make sure that you add the same two lines to their settings files to ensure that the log catches all commands used on all of these shells.

Step 3: Restarting services.

Restart syslog service:

sudo systemctl restart rsyslog

Close all open bash shell sessions, and start a new one. All of the commands types now will be captured in /var/log/commands.log file.

Example:

commands.log

Note: You might face a scenario where “logger” command needs to run with sudo to be able to capture the passed data.

Cracking a “shadow” password using John the Ripper

Posted on February 13, 2024 by tutorials 0

In this short article, I’ll walk you through the steps of cracking a password stored in the /etc/shadow file on a Linux machine. Keep in mind that in order to access the shadow and passwd files, you need root access.

Step 1:

Extract the user’s entry from the passwd file and the shadow file and put them in text files for John the ripper (replace the USERNAME with the username of your choice):

sudo cat /etc/passwd | grep USERNAME > passwd.txt
sudo cat /etc/shadow | grep USERNAME > shadow.txt

Step 2:

Use the unshadow tool that is part of John the ripper tool set to create a single text file that contains both entries of the user into on line:

unshadow passwd.txt shadow.txt > unshadow.txt

The resulting file would be a combination of the user’s entries from passwd and shadow. This step organizaes the data needed by John in a format that John recognizes.

Step 3:

Choose a dictionary of possible passwords, such as Kali’s rockyou.txt (contains over 14 million passwords), and run John:

john --wordlist=/usr/share/wordlists/rockyou.txt unshadow.txt

If the password is found within the given wordlist, you’d see the output like this:

password (USERNAME)

Step 4:

If you get the famous “No password hashes loaded”, then the cryptographic hashing algorithm used is not easily recognized by John.

Take a look at the unshadow.txt file. The field after the username (with a number or letter between two dollar signs) is the one that identifies the hash type used. It could be one of the following:

  1. $1$ is MD5
  2. $2a$ is Blowfish
  3. $2y$ is Blowfish
  4. $5$ is SHA-256
  5. $6$ is SHA-512
  6. $y$ is yescrypt

For $y$, for example, you can use the command:

john --format=crypt --wordlist=/usr/share/wordlists/rockyou.txt unshadow.txt

 

Visit my publons profile