A Closer Look at IoT Cyber Attacks

Article By : Perry Lea

IoT security is a complex problem, requiring a systematic approach for understanding possible threats and corresponding mitigation methods. We take a closer look at some of the more effective IoT cyber attacks to date.

The area of cybersecurity is a broad and massive topic beyond the scope of this article. However, it is useful to understand three types of IoT-based attacks and exploits. Since the topology of the IoT consists of hardware, networking, protocols, signals, cloud components, frameworks, operating systems, and everything in-between, we will now detail three forms of prevalent attacks:

  • Mirai: The most damaging denial of service attack in history that spawned from insecure IoT devices in remote areas.

  • Stuxnet: A nation-state cyber weapon targeting industrial SCADA IoT devices controlling substantial and irreversible damage to Iran's nuclear program.

  • Chain Reaction: A research method to exploit PAN area networks using nothing but a lightbulb—no internet needed.

By understanding the behaviors of these threats, the architect can derive preventative technologies and processes to ensure similar events are mitigated.


Mirai is the name of malware that infected Linux IoT devices in August of 2016. The attack came in the form of a botnet that generated a massive DDOS storm. High-profile targets included Krebs on Security, a popular internet security blog, Dyn, a very popular and widely used DNS provider for the internet, and Lonestar cell, a large telecom operator in Liberia. Smaller targets included Italian political sites, Minecraft servers in Brazil, and Russian auction sites. The DDOS on Dyn had secondary effects on other extremely large providers that used their services such as Sony Playstation servers, Amazon, GitHub, Netflix, PayPal, Reddit, and Twitter. In total, 600,000 IoT devices were infected as part of the botnet collective.

Mirai source code was released on hackforums.net (a hacker blog site). From the source and through traces and logs, researchers have uncovered how the Mirai attack worked and unfolded:

  1. Scan for victims: Perform a rapid asynchronous scan using TCP SYN packets to probe random IPV4 addresses. It specifically looked for SSH/Telnet TCP port 23 and port 2323. If the scan and port attached successfully, it entered phase two. Mirai included a hardcoded blacklist of addresses to avoid. The blacklist consisted of 3.4 million IP addresses and contained IP addresses belonging to the US Postal Services, Hewlett Packard, Ge, and the Department of Defense. Mirai was capable of scanning at about 250 bytes per second. This is relatively low as far as a botnet is concerned. The attacks like the SQL Slammer generated scans at 1.5 Mbps, the principle reason being that IoT devices typically are much more constrained in processing power than desktop and mobile devices.
  2. Brute Force Telnet: At this point Mirai attempted to establish a functional Telnet session with a victim by sending 10 username and password pairs randomly using a dictionary attack of 62 pairs. If a login was successful, Mirai logged the host to a central C2 server. Later variants of Mirai evolved the bot to perform RCE exploits.
  3. Infect: A loader program was then sent to the potential victim from the server. It was responsible for identifying the operating system and installing device-specific malware. It then searched for other competing processes using port 22 or 23 and killed them (along with other malware that could already be present on the device). The loader binary was then deleted and the process name was obfuscated to hide its presence. The malware did not reside in persistent storage and didn't survive a reboot. The bot now stayed dormant until it received an attack command.

The devices targeted were IoT devices comprising IP cameras, DVRs, consumer routers, VOIP phones, printers, and set-top boxes. These consisted of 32-bit ARM, 32-bit MIPS, and 32-bit X86 malware binaries specific to the IoT device being hacked.

The first scan occurred on August 1, 2016, from a US web hosting site. The scan took 120 minutes before it found a host with an open port and password in the dictionary. After one additional minute, 834 other devices were infected. Within 20 hours, 64,500 devices were infected. Mirai doubles in size in 75 minutes. Most of the infected devices that turned into botnets were located in Brazil (15.0%), Columbia (14.0%), and Vietnam (12.5%), although the targets of the DDOS attacks were in other regions.

The damage was confined to DDOS attacks. The DDOS attacks came in the form of SYN floods, GRE IP network floods, STOMP floods, and DNS floods. Over the course of five months, 15,194 individual attack commands were issued by the C2 servers and hit 5,042 internet sites. On September 21, 2016, the Mirai botnet unleashed a massive DDOS attack on the Krebs on Security blog site and generated 623 Gbps of traffic. That accounted for the single worst DDOS attack of all time. The following is a real-time screenshot captured during the Mirai attack using www.digitalattackmap.com: a collaboration between NETSCOUT Arbor and Google Jigsaw.

click for larger image

A view of the Mirai DDOS attack on the Krebs on Security website; courtesy of www.digitalattackmap.com



Stuxnet was the first known documented cyber weapon released to permanently damage another nation's assets. In this case, it was a worm that was released to damage SCADA- based Siemens *Programmable Logic Controllers (PLC) *and used a rootkit to modify the rotational speed of motors under the direct control of the PLC. The designers went out of their way to ensure the virus targeted only devices with rotational spin rates of slave variable frequency drives attached to Siemens S7-300 PLCs rotating at 807 Hz and 1210 Hz, as they are typically used for pumps and gas centrifuges for uranium enrichment.

The attack presumably started in April or March of 2010. The infection process followed these steps:

  1. Initial infection: The worm started by infecting a host Windows machine exploiting vulnerabilities found in previous virus attacks. It is thought to have spread by the insertion of a USB drive in the initial machine. It used four zero-day exploits simultaneously (this is an unprecedented level of sophistication). The exploits used a rootkit attack using user-mode and kernel-mode code and installed a stolen yet properly signed and certified device driver from Realtek. This kernel-mode signed driver was necessary to hide Stuxnet from wary antivirus packages.
  2. Windows attack and spread: Once installed through the rootkit, the worm began to search the Windows system for files typical of a Siemens SCADA controller, WinCC/PCS 7 SCADA, also known as Step-7. If the worm happened to find Siemens SCADA control software, it attempted to access the internet through a C2 using malformed URLs (mypremierfutbol.com and www.todaysfutbol.com) to download more recent versions of its payload. It then dug further into the filesystem to search for a file called s7otbdx.dll, which served as a critical communications library between the Windows machine and the PLC. Step-7 included a hardcoded password database which was exploited through another zero-day attack. Stuxnet inserted itself between the WinCC system and the s7otbdx.dll to act as a Man-in-the-Middle attacker. The virus started its operation by recording the normal operation of the centrifuges.
  3. Destruction: When it decided to coordinate the attack, it replayed the pre-recorded data to the SCADA systems which had no reason to believe anything was compromised or behaving erratically. Stuxnet delivered its damage by manipulating the PLCs with two different coordinated attacks to damage the entire array of Iran's facility. The damage to the rotors of the centrifuge occurred slowly over time, running in 15 or 50-minute increments separated by 27 days of normal operation. This resulted in improperly enriched uranium as well as cracked and destroyed rotor tubes in the centrifuges.

It is believed that over 1,000 uranium enrichment centrifuges were crippled and damaged by this attack on Iran's main enrichment facility in Natanz, Iran. Today the Stuxnet code is available online and is essentially an open source playing field to create derivative exploits.

Chain Reaction

Chain Reaction is an academic study that shows a new breed of cyber attacks focused on PAN mesh networks which can be executed without any link to the internet. Additionally, it shows how vulnerable remote IoT sensor and control systems can be. The attack vector was Philips Hue light bulbs typically found in consumer homes that can be controlled by the internet and smartphone apps. The exploit can be scaled up to smart city attacks and initiated by simply inserting one single infected smart light.

Philips Hue lights use the Zigbee protocol to establish a mesh. Zigbee lighting systems fall under a program called the Zigbee Light Link (ZLL) to force a standard method for lighting interoperability. ZLL messages are not encrypted or signed but encryption is used to secure keys exchanged if a light is added to the mesh. This master key is known to everyone in the ZLL alliance and was subsequently leaked. ZLL also forces light bulbs joining the mesh to be in very close proximity to the initiator. This prevents one from taking over their neighbor's lights. Zigbee also offers an Over-the-Air (OTA) reprogramming method; however, the firmware bundles are encrypted and signed.

The researchers used a four-phase attack plan:

  1. Break the encryption and signing of the OTA firmware bundle.
  2. Write and deploy a malevolent firmware upgrade to a single light bulb using the broken encryption and signing keys.
  3. The compromised bulb would join the network based on the stolen master key and exploit the proximity security through a found zero-day defect in the popularly used Atmel AtMega part.
  4. After successfully joining a Zigbee mesh, it would then send its payload to neighboring lights and infect them rapidly. This would expand based on Percolation Theory and infect entire city populations of lighting systems.

Zigbee uses AES-CCM (part of IEEE 802.15.4 standard and covered later in this chapter) encryption to encrypt OTA firmware updates. To break the firmware encryption, the attackers used Correlation Power Analysis (CPA) and Differential Power Analysis (DPA). This is a sophisticated form of attack where a device such as the light bulb controller hardware is placed on a bench and the power that it consumes is measured. Given sophisticated control, one can measure the dynamic power used by a CPU executing an instruction or moving data (for example, when an encryption algorithm is executed). This is called simple power analysis, in which it is still very difficult to crack the key. CPA and DPA extend capabilities beyond simple power analysis by using a statistical correlation. Rather than attempt to determine one bit at a time in cracking a key, CPA can resolve byte-wide quantities. Power traces are captured by an oscilloscope and split into two sets. The first set assumes an intermediate value being cracked is set to 1 and the other set assumes it is set to 0. By subtracting the mean of these sets, the true value of an intermediate value is exposed.

Using both DPA and CPA, the researchers broke the Philips Hue lighting system as follow:

  • Used the CPA to crack the AES-CBC. The attackers had no key, no nonce, no initialization vector. This resolved the key, which was used in the same manner to attack the nonce.
  • Used DPA to crack the AES-CTR counter mode to break the firmware bundling encryption. Researchers found 10 locations that the AES-CTR seemed to execute which created 10x the possibilities.
  • Researchers then focussed on breaking the Zigbee proximity protection for joining a network. The zero-day exploit was the result found by inspecting Atmel's source code for the bootloader on the SOC. Upon reviewing the code, they found that the proximity check was valid when starting a scan request in Zigbee. If they started with any other message, the proximity check was bypassed. This allowed them to join any network.

A true attack could force an infected bulb to infect others within a few hundred meters with a payload to remove the firmware update ability of each bulb so they can never be recovered. The bulbs would effectively be under malicious control and would have to be destroyed. The researchers were able to build a fully automated attack system and attached it to a drone that systematically flew within range of Philips Hue lights in a campus environment and hijacked each one.

More information on the CPA attack on Zigbee can be found here: E. Ronen, A. Shamir, A. O. Weingarten and C. O’Flynn, "IoT Goes Nuclear: Creating a ZigBee Chain Reaction," 2017 IEEE Symposium on Security and Privacy (SP), San Jose, CA, 2017, pp. 195-212. An excellent tutorial and the source code to generate a CPA attack can be found on the ChipWhisperer Wiki.

Leave a comment