[This is a Guest Diary by Christopher Von Reybyton, an ISC intern as part of the SANS.edu BACS program]

Introduction

During my internship with the Internet Storm Center I ran into an issue of wanting more information than the default logs would give me. I recalled one of the instructors saying "If we don’t have packets it didn’t happen". This inspired me to try to capture the packets hitting my honeypot. Initially I looked for ways to add logging capabilities to the DShield Honeypot [1]. I found very little information and the information I found I wasn’t able to get to work. Then I remembered that I owned a Great Scott Gadgets Throwing Star LAN Tap [2]. The Throwing Star LAN Tap is a passive Ethernet tap set between my router and the honeypot where I capture .pcap files with Wireshark.

Throwing Star LAN Tap

The Throwing Star LAN Tap can be purchased from greatscottgadgets.com and amazon.com. It has two pass-through ethernet adapters labeled J1 and J2. This allows the LAN Tap to sit between the router and an end device. There are two other ethernet adapters labeled J3 and J4. These adapters have capacitors connected to them and any packets are output to these monitoring ports. By connecting a device to these monitoring ports we are able to capture packets with apps such as Wireshark or tcpdump.
The following image is how the LAN Tap arrives unassembled.

Next is how the LAN Tap looks when assembled. Notice the placement of the capacitors.

Here is an image of the back of the LAN Tap after soldering.

Lastly here is a graphic showing the direction the packets travel to the monitoring ports.

Analysis

An example of how the packet information from Wireshark helps in attack observations can be found in the following screenshots.
First is output from the honeypot using the command "cat webhoneypot-2024-01-25.json | jq 'select(.sip == "80.94.95.226")'". This image shows output with a timestamp of 23:43:18. The attacker is trying to POST information to "/cgi-bin/luci"

The next screenshot shows the output from Wireshark using the filter "http.request.method == "GET" || http.request.method == "POST".  At No. 5181 and timestamp 23:43:17 we see the POST request from IP 80.94.95.226

If we then follow the HTTP Stream of this conversation, we end up with the next screenshot. If you look at the end of the output, you will see the username and password used by the threat actor. This is information that is absent in the DShield logs and gives added insight into the attackers’ behavior.

Identified problems

The main problem I ran into was that my Throwing Star LAN Tap was a kit. I had to solder the Ethernet connectors and diodes to the circuit board. As I don’t have a lot of experience with this it took some trial and error to make sure the connections were soldered on correctly. My first attempt after soldering seemed to have worked as I was able to receive packets for many hours. The next day that I connected I only captured packets that came from the honeypot. I had to disconnect the LAN Tap and go over the connections again to make sure the soldering was correct. The third attempt resulted in capturing full packets.

It should be noted that the reason I only captured packets coming from the honeypot on the second day is that since the Dshield honeypot resets every day the LAN Tap needs to be re-connected everyday as well. And that the monitoring ports only monitor traffic in one direction.

Why It Matters

Packets are how everything is communicated through networks. It doesn’t matter what protocol is used or where the device is located. And while collecting logs is important, being able to see the history of the logs communication in the form of packets is the basis for good information security. Information that may be passed in clear text in the packets may not be picked up by DSHield logs.

Benefits

The main benefit of capturing packets is that you have visibility into the communication going to and from the DShield honeypot. It’s nice seeing the SSH and HTTP logs that DShield collects, but being able to go through the packets gives a much deeper insight into what attacks are happening and how they are happening. For me parsing logs felt like only seeing part of the conversation. Being able to see the packets now makes parsing the logs more complete and easier to interpret. 

Conclusion

Capturing packets between the DShield honeypot and an externally facing router is a powerful tool to help with attack observations and identifying threat actors’ behavior for accurate documentation. In the future I would love to see packet capture capabilities added to the DShield, but until then using a LAN Tap can give us vital information to increase the scope of our attack documentation.

[1] https://isc.sans.edu/tools/honeypot/
[2] https://greatscottgadgets.com/throwingstar/
[3] https://www.sans.edu/cyber-security-programs/bachelors-degree/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu