Genetics of a Modern Internet of Things (IoT) Attack

When it comes to IoT attacks and malware, there is a perceptible pattern in which most intrusions manifest. It is good practice to study such patterns and draw conclusions so that we may extrapolate to future attacks. In this article, I cover a scenario of a modern IoT incursion and detail some of the top characteristics that come with IoT malware.

The Backstage of the Dark Side in IoT Attacks

Attackers usually start by setting up an infrastructure that supports their operation for a certain campaign. A campaign is a specific timeframe in which the perpetrators conduct their malicious operation with a specified goal in mind: either attacking a certain industry or a more focused set of target companies. The campaign might even be just a focused attempt at distributing a specific version of a new IoT malware to test its capabilities and assess its damage. Once the campaign is finished, the infrastructure has served its purpose and the actors will commonly tear it down and move on. More experienced actors either set up or rent (CaaS) a multi-layered infrastructure with usually 3–4 different servers each serving some distinctive purpose. Attackers prefer to have each of these servers sit on a different ASN or at different hosting providers so defenders have a harder time remediating or cleaning up these malicious assets. It is in the actors’ best interest to delay these sort of remediation attempts so their campaign can last as long as possible for maximum damage.

The Scanner

This individual server is commonly used in the reconnaissance phase of the attack, where assailants are explicitly looking to scan for vulnerable devices on a mass scale. The tools here could consist of either nmap, masscan, unicornscan or some custom-made scanning tool focused on a specific vulnerability. These open-source, proof-of-concept Python prototypes are usually released on GitHub, once researchers discovered the ins and outs of a certain vulnerability. The attackers then take this PoC code and modify it by including a payload into the scanner module: Once the tool detects that a certain device is vulnerable, it initiates the download for the payload. Here’s one example of HTTP POST requests that act like a scanner, including the payload if the device is deemed exploitable:

The Stager Script

The sole purpose of this VPS is to host the initial payload which is simply a stager script file. The bash downloader’s job (.sh) is to:

• Get the malicious binary for the corresponding target architecture.
• Modify the environmental settings of the target device for maximum damage
• Download additional binaries for multiple architectures (ARM, MIPS, SPARC, POWERPC, M68K, etc.)

Optionally, some malicious stager scripts will also include commands to download a cryptominer. The Kinsing (a prevalent malware family nowadays) stager script will set up persistence (crontab) for the binary in this stage. Also Kinsing, for example, will check whether the downloaded binary checks out by its MD5 hash sum.  

In most cases, stager scripts are bash downloader scripts. First, the script tries to navigate to a directory where the binary can be placed. This is usually /tmp, /var/run, /mnt or /root. Crooks commonly resort to getting their binaries by simply calling wget $URL or curl –O $URL. If those packages are not installed, some stager script will attempt to install it via apt or yum package maintainers. Once the binaries are in place, the bash script initiates a chmod 777 and +x command on them for the binary to have execute permission. Now that the script executed the malicious payload, it often leverages rm –rf to clean up the initial payload from disk.  IoT malware families that have started to employ this sort of stager approach include: Mirai variants, Gafgyt, Ouija, Kinsing, Kaiji and many others. 

 

The Binary Distributor

With many campaigns, actors try to distribute their infrastructure as much as they can. From the attacker’s perspective, the goal is to be rather all over the place, so naturally removing and neutralizing these malicious services will take more time – while attackers can still do significant damage. With distributed campaigns like this, removing one item (script serving server) from the chain might not be fully effective, as the other services are still serving, for example, the malicious binaries.  One simple way of looking for these kinds of servers is to do a Google Dork search: intitle:”Index of /bins” arm or more commonly scrape Shodan for this dork or other commonly used folders: the root /, /mozi, /ares, /kinsing, etc. 

 

The Command and Control (C2) Server

The C2 server is responsible for receiving and sending commands to the bots. With some malware families this is through a fixed TCP port both on client and server side, hardcoded inside the malicious binaries. Other families establish a random port on either client or server side to send commands through, but this may vary with each command.  Commands may include action to create new files, delete logs, exfiltrate important data, or even to initiate a DoS attacks. For instance, the infamous Mirai botnet supported many commands to do harm to targets. Each of these attack types would be launched with a different set of control instructions: 

greeth	GRE Ethernet flood
greip	GRE IP flood
dns	DNS resolver flood
http	HTTP flood
syn	SYN flood
ack	ACK flood
udpplain	UPD flood with lighter packets
udp	UDP flood
vse	Valve Source Engine flood
stomp	TCP stomp flood

 

Entry Vectors for Malicious Actors

Now that we shed some light on both the attackers’ and administrators’ sides, let’s see some top attack vectors that crooks leverage: 

• Weak, hardcoded or known default vendor passwords that are easily guessable, brute-forced or cracked via dictionary attacks 
• Unnecessary, deprecated and unsecure services often completely exposed to the public interface of the device, allowing anyone to probe and exploit 
• Vendor backdoor, that allows remote management on a specific port but has known hardcoded credentials or those credentials have been discovered through reverse-engineering the firmware 
• Lack of secure coding manifests in a vulnerability that is exploitable remotely often resulting in remote code execution 

We have seen many examples to all these points, and many times over, manufactures have been called out to improve on their security practices. But we are yet to see true change in the industry. Now even governments are pushing for these changes, as they have also realized the potential impact of botnets. 

 

Once Aboard 

Let’s get back to our scenario. Once the malicious binary is executed on the target device, we may observe certain techniques that are employed by IoT malware. For research purposes, it is a good practice to categorize them into certain behavioral categories. Generally, these would fall under the following observable tactics: 

• Evasion 
• Privilege escalation 
• Deception 
• Persistence 
• Exfiltration 
• Lateral movement 
• Clean-up 

MITRE has already created a framework for categorizing these behaviors systematically, and it is always recommended to follow industry–standard structures instead of trying to invent your own.  

Each of these tactics consists of a certain set of actions that can be described by deeper technical features or by the impact the malware made on the operating system. Interesting techniques employed by IoT malware include: 

Evasion	SELinux is set to permissive (setenforce 0) Disguising process name with a common system tool’s name Invoking nanosleep system calls Chroot() jail detection Kill suspicious processes or other malware
Deception	Faking system statistics (top, htop) Hiding files and folders by hooking getdents
Persistence	Setting a recurring cron job Flushing or modifying iptables list Changing file descriptor limit User level persistence in .bashrc or bash_profile Setting subsystem initialization in init.d File permissions set to 0 Host redirections via /etc/hosts LD_PRELOAD preloading Replacing pam_unix.so Backdoor access by abusing authorized_keys
Trace clean-up	Clearing bash_history, deleting residual files, rm –rf

 

Making the IoT Botnet

Now that the damage is done on the target device, some IoT malware families also pivot to other vulnerable devices on the local network. The malicious binary commonly includes additional scanner modules to achieve lateral movement: In our example attack scheme, this could mean that the malware will propagate onto the local thermostat or lightbulb if those are found to be vulnerable by the scanner module inside the binary. This shows that the initial elements of the attack (mass scanning) are also implemented into the binary itself, wielding the malware with a worm-like behavior to further multiply on the local network. One other interesting aspect of these attacks: Once the actual malicious payloads are downloaded to the target device and the payload is executed successfully, the device may turn into a reverse proxy and serve the downloaded malicious binaries to other potentially vulnerable devices. This behavior can be observed in the Dark Nexus malware family, for instance. 

Eventually, as more and more devices are infected and zombified, all will report back to the Command and Control server, forming into one single army of bots. At this stage, the controller of the C2 server usually resorts to launching Distributed Denial of Service (DDoS) attacks against significant targets. Depending on their motivation, these targets may be financial institutions, high-profile companies, and in general high-value corporate environments.   This scenario covers many aspects of a modern IoT attack. Crooks have learned to stay abreast and will always improve on their skill set. We also need to make sure that we understand their goals, motivation and tradecraft as well. We are continuously on the lookout for future changes regarding techniques and procedures that may put attackers at an advantage.  

Against Evolving IoT Attacks

As most IoT devices were not really designed with security in mind, and practicality and usability always had priority, it comes as no surprise that researchers frequently discover plenty of new vulnerabilities. The most disturbing thing about such vulnerabilities is the fact that these IoT devices are deployed at mass, and even if their manufacturers were to release an update, the operators in many cases simply forget to upgrade their devices with the latest security patches. Should these devices fall into the wrong hands, they would make up a significant threat together once controlled by a botnet operator. 

As consumers, our buying decisions have the power to improve the situation. We should choose to buy from vendors who have the security basics in place. 

As vendors, companies should:  

• Consult with the manufacturer if there is no update process for sold devices. 
• Turn off unnecessary services. 
• Change default settings and default passwords on services to safe credentials. 
• Encourage consumers to subscribe to manufacturer email notifications about security patches and vulnerability notices. 
• Educate consumers to apply the latest patches to their devices regularly. 

 

Glossary

• ASN – Autonomous System Number 
• VPS – Virtual Private Server 
• DoS – Denial of Service 
• DDoS – Distributed Denial of Service 
• Google Dork – A search string that uses advanced search operators to find information that is not readily available on a website 
• MITRE ATT&CK framework