A lot of the information seen on DShield honeypots [1] is repeated bot traffic, especially when looking at the Cowrie [2] telnet and SSH sessions. However, how long a session lasts, how many commands are run per session and what the last commands run before a session disconnects can vary. Some of this information could help indicate whether a session is automated and if a honeypot was fingerprinted. This information can also be used to find more interesting honeypot sessions.

To get an idea of what that variety looks like, I reviewed about 3 years of data from 6 honeypots. Some of the honeypots have been running for different periods of time, but it should give a good overview of different attacks seen on telnet/SSH honeypots. Since I already made a python script [3] that summarizes some of this data for me, it made the process a bit easier. Before going into the details, some of the basic information:

Data Timeframe: 4/13/2022 - 3/21/2026
Number of Sessions: 1,206,566

Figure 1: Basic statistics for Cowrie session durations and number of commands run per session.

In most sessions, we see about 20 commands and a session lasts for about 20 seconds. 

Number of Commands Per Session

When a Cowrie session is allowed through, the client connection has the option of running commands. They client may decide to disconnect, run an automated script or run commands manually. Most of the time, there are usually under 30 commands run per session, but there are some sessions that have had over 25,000 commands run in a single session. 

Figure 2: There are many telnet/SSH sessions interacting with DShield honeypots that run over 25,000 commands in a single session, but most are much lower. 

Figure 3: Looking at most frequenty occuring number of commands run per telnet/SSH session, the majority are under 50 commads with the most frequent being 22 commands in a session. 

Figure 4: The top 10 most commonly seen number of commands run in a session accounts for about 94% of the telnet/SSH sessions.

Are the sessions with 22 commands similar? To help commands for differnet sessions the commands per session were concatenated and then hashed to arrive at a value that could be compared across sessions. This value would be the same if the same commands were run in the same order. This seemed like a great idea until I found a very small number of similar hashes when looking at sessions with 22 commands. Rather than seeing tens or hundreds of thousands of similar hashes, there were only 4. Looking more closely at the data demonstrated what was missed. 

Figure 5: Cowrie sessions with matching command hashes, but with data that changed based on script inputs, in this case, passwords. 

Many attacks will often try to change passwords, but these comamnds will often change since differnet passwords may be successful on a honeypot and new password used could also be different. Trying to simplify the search and ignoring command by command details, 99.95% of sessions with a total command count of 22 may be similar (461,344 out of 461,561).

select count(sessions.session) from sessions, commands where sessions.total_commands="22" and sessions.session=commands.session and commands.command LIKE "%Enter new UNIX password:%";

The total number of commands run may be a good indicator of bot scripts being run. Even though many sessions may run the same commands in the same order, the duration of the sessions has a wide range.

SELECT 
    printf('%.10f', min(cast(session_duration as real))),
    printf('%.10f', max(cast(session_duration as real)))
FROM sessions, commands
WHERE sessions.total_commands = "22"
  AND sessions.session = commands.session
  AND commands.command LIKE "%Enter new UNIX password:%"
  AND cast(session_duration as real) != 0;

Minimum Duration: 1.63 seconds
Maximum Duration: 233.05 seconds (a little under 4 minutes)

While a shorter session time may indicate automation, a longer session duration doesn't neccessarily mean that there is a person behind the keyboard.

Session Durations

Session durations had much more variety than expected. They can range from about a second to upwards of 26 minutes. Taking into account only those command counts where we had at least two sessions:

Figure 6: Breakdown of session durations grouped by the number of commands run per session. 

Looking at one of the sessions with a higher frequency of command run shows an ELF executable being constructed byte by byte (command count 440, 12.80 commands per second).

Figure 7: ELF exeutable being constructed byte by byte (file name "anthrax") [4]. 

The file being constructed is shown as benign on VirusTotal, but similar sessions with the file "/tmp/anthrax" has also been noted as being a Mirai variant [5] and affiliated with other benign files [6]. 

Last Command Before Session Disconnect

Commands run usually have a purpose. Maybe it's to create an executable, gain persistence or even fingerprint a honeypot. Looking at the last command run on a honeypot may help indicate why a session disconnection happened. If the attacker things they have run into a honeypot, there may be no value into performing other actions.

Figure 8: The 10 most frequently run "last command" before a Cowrie session ends, which accounts for almost 93% of sessions. 

Since I wanted to see, from these examples, what the output looked like for a honeypot in comparison to a real system, I set up a Ubuntu VM for testing. This may not fit an IoT scenario, but it's just a starting point. I also wanted to see output from Cowrie, so I set it up using a docker container on the same system. Some troubleshooting was needed to get the configuration to function based on the Cowrie download for the DShield honeypot, but I've been able to repeat the setup multiple times with success.

#install docker
sudo apt update
sudo apt install ca-certificates curl -y
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

#download DShield Cowrie
curl https://www.dshield.org/cowrie.zip > cowrie.zip
unzip cowrie.zip

#copy and configure settings for honeypot
cd cowrie/docker
sed -i 's/context: context/context: ./' docker-compose.yml
sed -i 's/- cowrie-etc:\/cowrie\/cowrie-git\/etc/- .\/etc:\/cowrie\/cowrie-git\/etc/' docker-compose.yml
sed -i 's/- cowrie-var:\/cowrie\/cowrie-git\/var/- .\/var:\/cowrie\/cowrie-git\/var/' docker-compose.yml
sed -i 's|- ./var:/cowrie/cowrie-git/var|- ./var:/cowrie/cowrie-git/var\n      - ./honeyfs:/cowrie/cowrie-git/honeyfs|' docker-compose.yml
sed -i 's|- ./honeyfs:/cowrie/cowrie-git/honeyfs|- ./honeyfs:/cowrie/cowrie-git/honeyfs\n      - ./share:/cowrie/cowrie-git/share|' docker-compose.yml
cp ../requirements.txt ./requirements-output.txt
cp -r ../src .
cp ../setup.py . 
cp ../setup.cfg . 
cp ../pyproject.toml .
cp -r ../honeyfs .
cp -r ../etc .
cp -r ../var .
cp -r ../share .

#change settings to all passwords attempted are allowed
cp etc/userdb.example etc/userdb.txt
echo "*:x:*" >> etc/userdb.txt
sudo chown -R 1000:1000 var/log var/lib
sudo chmod -R 777 var/log var/lib

#run Cowrie in docker
sudo docker compose up -d

#connect to cowrie
ssh root@localhost -p 2222

Figure 9: Comparison of different command outputs for a Cowrie versus Ubuntu VM.

Some of these commands will be different for any system, but the most notable in this comparison were:

• df -h | head -n 2 | awk 'FNR == 2 {print $2;}'
• /bin/busybox cat /proc/self/exe || cat /bin/echo
• kill %1
• cat /proc/uptime 2 > /dev/null | cut -d. -f1
• /bin/busybox cat /proc/self/exe || cat /proc/self/exe

This was a limited comparison since they didn't account for any of the preceeding commands, which may change the output. However, it gives a process that can be used for comparison and improving honeypot configurations. Modifying the file system or text outputs could be options to test how differences in returned data impact honeypot interactions [7]. At the very least, some additional data, such as the number of commands run in a session, could help highlight interesting honeypot data.

Some future items to explore for this data:

• Improve identification similar sessions by removing data that may have variable input/output (password changes, URL downloads, etc)
• Modify Cowrie to better replicate responses to some of the examples from real systems
• Look at sessions that are outliers within the session durations and total command counts per session

How are you modifying your honeypots or finding interesting data? Let us know!

[1] https://github.com/DShield-ISC/dshield
[2] https://github.com/cowrie/cowrie
[3] https://github.com/jslagrew/cowrieprocessor
[4] https://www.virustotal.com/gui/file/bb403e1761fed33c966d99393630c16ae138ec887b9b32befe6f1bae5f2bc13d/details
[5] https://www.virustotal.com/gui/file/646af726da8182da9910c4a50aac4f648808de4f9f98bc26058ea190e9bf8e20
[6] https://www.virustotal.com/gui/file/b0d1282989c786cffe85093947f307a26f20601c2f039efc88e3b692d670d076/detection
[7] https://docs.cowrie.org/en/latest/README.html

--
Jesse La Grew
Senior Handler