Join Us at Our Upcoming Events Events
Skip to Main Content

Analyzing a Log4j Exploit at the Packet Level with Omnipeek for Windows

By now everyone in IT is all too aware of the Log4j exploit. We’ve all read many articles about how this vulnerability can be exploited, but are you curious about how this exploit looks at the packet level? Being in the packet analysis business, of course, we’re curious, so we found a good capture that included the vulnerability online and dug in with Omnipeek for Windows.

You don’t have Omnipeek? No problem, you can get a touch with a LiveAction expert and start your 30-day trial.

A good unencrypted capture file showing this vulnerability can be found here. Thanks to Brad at for posting the file and allowing us to reference it in this blog.

To load the file in Omnipeek, just extract it and copy it to your file storage and open it with Omnipeek for Windows.

First, we need to create some filters to find the relevant packets, and then we’ll analyze the packets. In this case, we are looking only at unencrypted traffic. Omnipeek can also analyze encrypted traffic if the keys are known, but that’s not the point of this blog.

Finding the Relevant Packets

Go to “View/Filters” or press CNTRL+M. You can either create the filters as described below, or just import the attached filters.

To create a filter, click on “Insert”. A new windows appears, now click on “Type: Advanced”.
Give the filter a name, then create a new filter condition by clicking “And” and “Protocol” and “Or” and “Pattern”.

1blogpic 2blogpic

Build a filter that detects packets used in the Log4j exploit as shown on the right above using the GUI filter builder and click “OK”.

In addition we need to create a TCP-SYN flag filter that we can use to track communications with the infected server. Enter the following values to a newly created and name it “Value Filter”.


After having created the filters we are ready to load the file.

Analyzing the Packets

First, let’s identify if this packet file contains Log4j related traffic. After opening the packet file, add the Log4j filter to the decode view in the filter bar with the command “filter(Log4J)”. In the new window that appears click “Hide Unselected Packets”, which will put only packets that match the filter into the new window, making analysis much easier.
Navigate to the Web Analysis tab. Under “Request” you can see all requests containing “jndi”.


Now let’s see where all these packets are coming from.

Navigate to “Statistics/Nodes” and you should see the following:


You can add the city by left-clicking into the columns and selecting “City”


The details are in the Packets

Let’s dive into the details of one packet.

Navigate to the packets view under “Capture/Packets”, and look at the first packet, #444.

Focus on the HTTP/User Agent part.


We see that a base64 encoded command is being used. Sometimes cleartext is used, or encoded URLs.
To see what is going on we need to decode the base64 value. With Omnipeek for Windows this is very easy. Just left click into the field you want to copy and select “Copy” or press “Cntrl+C

Now you can copy it to any other tool, like to convert it to text.

We see that we have a “wget;chmod +x;./” in there.

So, what does this mean? The attacker wants the server load, make it executable, and have the server run it. In other words, it’s attempting to infect the server.

Has the Server Talked to Someone?

Once we know there’s been an attempt on one server, we want to see if the server has reacted and does a TCP SYN to any other servers out there.
To do that we need to reset the former filter by clicking on 7blogpic or pressing “Cntrl +U”. After doing that all packets are available for analysis again.

To see if the infected server has reached out to other servers, we need to add this filter “|  (filter(‘TCP-SYN’) & addr(type: ip, addr1:, dir: 1to2))” to the filter bar and press the “run” button. We see only the same packets we saw before, implying the server has done nothing wrong.

How can we assure that the filter works? We need to reset the filter again with “Cntrl +U” then we can change the direction by changing “…dir: 1to2” to “…dir: 2to1” and hitting the “run” button again. Now you can see all packets where the attacked server was the destination.

This capture file can show us many more things, but we just focused on how this attack looks from a packet perspective.

In summary, if you want to search if this vulnerability is on your network, you need to have unencrypted packets from the servers and the Log4j filter, and then follow the above steps. To get the packets, you can use our TCPDUMP adapter to capture on any TCPDUMP supporting server, including proxy servers.