11 Jan 2016

The Botnet of the Internet of Things



Last month we released our report on the Inception Framework and as part of that report outlined how a nation-state level attack compromised over 100 embedded devices on the Internet to use them as a private proxy to mask their identity. Since the release of the paper we have further discovered that the attackers not only targeted MIPS-el devices but also had binaries for ARM, SuperH, and PowerPC embedded processors. In light of this the 100 devices that we knew about is most likely only the tip of the iceberg and the total count was much, much more.


This network of proxies was managed by a central backend that tunneled attacks through an ever-cycling list of compromised devices, thus changing the IP address their attacks came from every few minutes. The whole system for tracking which compromised devices were available and managing the change in proxies at regular intervals had to be a fairly complex system, but the benefit to the attackers was clear. No one entity would have full insight into their attacks, only portions of it and it is hard for investigators to put together a puzzle with only a handful of the pieces.


However, it seems we dug up enough of their infrastructure to scare the attackers. With in 48 hours of our release the attacks stopped. The tasking of compromised computers via the cloud and the whole system for tracking compromised devices went dark.


Once that investigation came to a close I begain looking for new things to play with. Being intrigued by Inception's use of the Internet of Things as a weapon I wondered what other groups are weaponizing the Internet of Things. To find out I set up an emulated embedded system as a Honeypot over the Holiday break. The system I built ran a very minimal build of Linux on an ARM processor. A typical build for many Internet enabled devices like routers, web cams, etc… The system was designed with outdated versions of software and default passwords so to be horribly unsecure. I was hoping to see what other malware there was that is designed for the Internet of Things and I was not disappointed by my findings.


Over the course of the two weeks I received over 150 compromises from unique IPs resulting in three different botnet families. The first remote shell occurred in less then 2 hours after I stood up the honeypot. I was shocked how little time it took for these crawlers to find me. Let this be a word of warning for anyone who plugs an Internet enabled device directly into the Internet with plans to configure it in place.


That first remote shell access went to work immediately to install its backdoor and botnet agent. Here is a segment of the script that runs once execution is gained.





Each of those wget requests is for the same binary only compiled for different embedded architectures. The script tries running each one knowing only the one for the correct processor architecture would actually succeed. The payloads are known as Linux.Backdoor.Fgt forwhich we have collected over 200 hashes associated with this family. This family of malware has the capabilities of a backdoor, botnet agent, and worm combined into one and can run on a myriad of architectures.


When executed Linux.Backdoor.Fgt first registers with its command server, afterwhich the malware is then open to receiving commands from the C2 Server. The following table lists commands and their purpose.





SH

Execute a command on the shell


PING

Ping Command Server


GETLOCALIP

Gets local IP address


SCANNER

Disable/enable the telnet scanner


DNS

Perform DNS based DoS attack


JUNK

Flood garbage data to destination IP:PORT


HOLD

Similar to JUNK


UDP

Perform UDP based DoS attack


RANDOM

Similar to UDP


TCP

Perform TCP based DoS attack


KILLATTK

Halt any concurrent attacks


LOLNOGTFO

Kill the botnet agent on device



The malware also starts performing a scan of random IPs looking for devices with default credentials via telnet. This is how my honeypot was hit and it explains why it was so quick to find me. This group has thousands of compromised devices always scanning the Internet for new devices to become part of their botnet.


Earlier today, Krebs on Security identified the group behind this botnet as the “Lizard Sqaud” which is peddling the “stresser” services available via this botnet. The article points out that the majority of the devices in this botnet are home routers and speculates that other devices are included. From out telemetry we’ve observed DVR recorders and web cams that belong to this botnet too.


The next sample observed from this honey pot is known as powbot. We first observed this malware during the Bash Bug shenanigans last October. However, the threat observed back then was much cruder and only designed for x86 or x64 Linux systems.


The install for this one is a little quieter than the script for Linux.Backdoor.Fgt. Instead of throwing spaghetti at the wall and see which binary sticks Powbot will cat /bin/sh to the terminal and based on the output use wget to pull down the correct binary and not expose all the other versions needlessly. In my case hxxp://37.220.109.6:61050/wb.arm. Noticing that the file extension is the architecture type I tried a few different extensions and found samples for SuperH, PowerPC, MPIS, x86, and AMD64 processors too.


Powbot is similar to Linux.Backdoor.Fgt in that it is a botnet agent designed to facilitate DDoS attacks. What makes this one unique are the types of DDoS attacks it is capable of. It supports the typical HTTP, DNS, UDP, or SYN DDoS attacks but can perform a SSL DDoS and has a command to perform a DDoS specifically designed for Minecraft Servers.


The third sample that hit my honeypot was the most interesting of the three. This sample is currently undetected by any of the engines in Virustotal. It is actually a series of binaries and compressed files that make up this botnet on the compromised system. First, it starts off by collecting some basic information about the system it is on such as processor type, free memory, and mount points. Then it creates its own tmpfs mount under /dev/netslink and starts building a decoder binary via printf commands.





The ELF file header is clearly visible in the first printf command. Once that is complete it executes the binary and passes an encoded string to it via STDIN. That encoded string is yet another binary that also gets dropped to the tmpfs mount.





This binary is ultimately responsible for dropping a Perl interpreter and compressed Perl library blob. Before starting this process the binary alters its process information to appear to be /sbin/if-watch to mask its identity. Such precations seem unessasry since nobdy is watching the embedded systems for malware but none the less, I thought it worth mentioning.


Decompressing the perl library and browsing through the code I was able to determine this is a botnet/worm with a peer-2-peer infrastructure. Each of the nodes in the network acts as a simple file server for the key components of the botnet to be downloaded by peers. As part of this each peer keeps a list files necessary for every targeted architecture, their size, and hash in a file called ‘!Whisper’. Here's the output of mine.


mips1-sf/bn 2600694 7b0e85574671301deee08db03a8e6670268c0df66ff874f1e67f356b9a8fd10f

armgeb-sf/rf 2258 04a6a13ff7da430a58bf0c53d525404d44220749913c0188dc68d996764e574e

armeb-sf/dl 5066 161250dc959e7e520118155286314cb56025f7c5ca3976712ecb5090dcb7746d

arm-sf/rf 2160 4d5af001c48c1dd37d932003a6780ccb28e1537b9dee197a694e8d437d16ee9b

mipsel1-sf/dl 6912 5a674ac420193c225a4d041f2d38ef36ba010bec7428450dffc2a6c09415eb8f

armgeb-sf/tn 13914 68903a2c82c07b0b3c72500adee34e034fdac7c5c388a617fc08c0d79af13bda

x86/bn 1768445 28af19831c28ec5e58d8dc8cbc1dedc8a9b47fc93781ea65e983fb11749df244

mips1-sf/rf 3218 6e237d4ff8ba216f433adc0040701c161a8ee99e3f9df1a411fa6f6aa6d09621

sh4b-sf/tn 7741 7d7f5048346b904664e6b25caf55d35966ec1a4d158dd1425ca2b2dceb6f9c6e

x86/rf 1981 50578cc804a3ba11f5fbfbbed9bb1403ecf1470fc011d0fde1f423f6c1d588cb

arm-sf/dl 5100 df13514f1f94a30d83b103ed92130c66159d417ce71fc2367cfc550fc9eb10f3

sh4b-sf/dl 4457 48e1fc4b2a12aaab1163a2e4c0ef1e841f113596cf9bb86bca3d282ff466ebb1

arm-sf/tn 8360 b70203bc092be0d8e7b8c1e9f3a2424ae22857fc25550af217e3fad19b7bd913

armeb-sf/bn 1997858 fe42c8e22025654c81e10f7a93f82c1ef5d2c40c30604ee0ffcec2102fd99604

armeb-sf/rf 2182 f8a3dc935ecb9aadff73236da954ad85474ebd68f99ba3cc085f580f52706394

sh4l-sf/rf 2189 5b8d6057aecd9815b2d88330f5b1c72af5530cd744756cf3ebec91467156574d

x86/dl 3965 cefc86696e6852b9800450cdf0c0a49bf2bd6b74725cfa9289087ac9c399befe

x86/tn 7345 73d4d001273425840cbb3110050f61b4aaeb542bc979abf71036eae01304ded5

ppc-sf/rf 2662 513527ad13f47d2f7a188d3688d788e0ba4370b3d602501940516248d5847f33

mips1-sf/dl 6846 0fc73fb359675fbebf7102bc369e2f1455e94ae23c16a0e330a3a4f7fe7956a7

ppc-sf/tn 9236 a08ef2aabde32abb9ba23b4339d843a973a6804a41cd22d66c1de449d0e0c0c0

mipsel1-sf/bn 2599808 677e0ff1579781e471f6182518de39224a31002b3491c23236044bd29bbaa8d8

armgeb-sf/bn 2010188 52eb7b862f6558288854710b5d7f61e9275c1068ac3aaa77ac8ffdb962983fe5

sh4l-sf/tn 7669 3a8496923be89b5cd5f6b0eca58205b3cb0855c243d2175ca26770a4b1873ff3

mipsel1-sf/rf 3236 267be689437edf064dc4219f00b8fed6300d79c99e4ff6a2726416429cf9ec4c

sh4l-sf/dl 4509 f432f68320ccb101efc55ec2d51d090a71b56fceeb85ec3d95350d282d0833cc

armgel-sf/bn 2010188 500b017c585181f230c1b9b2b9a03548551a28410c5f0dd640d90abe0abe6454

mips1-sf/tn 11666 8223cc8e0ed3ac448fc020dbc8f81d9bdd6bc930e41bca77315f08f5cd8f9876

mipsel1-sf/tn 11556 d1685a38f747f8e192d16c1059de0c4a7c114a25754649970ff907a653d79f27

sh4b-sf/bn 1776725 4ad5157c950c0ad261d562eeb2ee9341c07bc3dcae834e9967a5d36b21c00e5b

armgel-sf/rf 2258 1f465a9b36991ceee39840f23b2397752a04386c3a96cb48bb74c7d15a96ac57

ppc-sf/bn 2083380 c377f1eddfdbbfae880c5fc11b444d21d3061923a93767d922e66b9f72344a8e

sh4l-sf/bn 1776725 f3e76b7489a189b74e36cb37acd13f374fa00d7ebded06b447709de02cee1954

sh4b-sf/rf 2189 f8176cc1a800d17acfeecd13a7322eb38a50ef94bb7418f841c58e9160196448

ppc-sf/dl 5344 affc527803844bf5d7c0a7a5b4e13df30d9c65bc635c7a3e06ac9146e566879a

armgel-sf/dl 10450 94cedd5dfe733422de2ee23c78821eab6938a1f3ccd876dbeec5659e38e909ff

armgeb-sf/dl 10406 ef1c47602c1f7fcc8c790debf77e7ab1be9cbb0d0bec655308faebd6a8a8a3d0

armeb-sf/tn 8362 87f0bf620835c18ecfc330616192e484e182632a727b1bdb85dce453f942b321

armgel-sf/tn 13802 88b0f1cc969703b068b9c771602744fc9661254ae8bbda91098a1d3325228454

arm-sf/bn 1993760 97960d3dea228c875cd1bd965450279a2c019f99e8a3a4fa5fba9cf17eecc401


I originally discovered this botnet while doing work on the Inception camping back in October but had to shelve it due lack of free time. Since then the independent malware hunter Loot has released two great technical write-ups on it part1 part2. By letting the bot run and harvesting the list of peers periodically Loot was able to determine this Peer-2-Peer network is at least 13000 nodes large, if you want more information on this botnet I highly suggest reading his write ups.


The if-watch botnet as Loot calls it has 0 detections in VirusTotal and even the other samples are relatively undetected for any architecture other than the standard x86 or AMD64 systems. This is where web-filtering solutions really shine. WebPulse easily detects the traffic patterns used by these samples regardless of the system architecture where they hide.




https://www.bluecoat.com/security-blog/2015-01-09/botnet-internet-things