IOT Penetration Testing

  1. Home
  2. IOT Penetration Testing

Uncovers hardware and software vulnerabilities in Internet of Things devices, including default passwords, insecure protocols, open APIs, misconfigurations and more. In the hyper connected world of today this kind of penetration testing has become a necessary evil.

The main difference between traditional and non-traditional penetration testing is the diversity in IoT. With traditional testing, the penetration tester is usually confronted with Windows or Linux x86/x64-bits systems, known TCP/UDP protocols and applications. But, when you switch to IoT, you have new architectures that are uncommon for most penetration testers (ARM, MIPS, SuperH, PowerPC, etc.). Different communication protocols like ZigBee, SDR (Software Defined Radio), BLE (Bluetooth Low Energy), NFC (Near Field Communication), that requires new expertise and tools to test them.

An IoT environment mostly consists of includes the following components:

  • Network: An IoT environment runs on and is updated over a network, such as the Internet, BLE, 4G, LTE, Zigbee, LoRA, WiFi, MQTT, 802.11.15.4, etcor others.
  • Applications: IoT applications manage device- Web App, Mobile App,, and they can be web apps, mobile apps, or APIs (SOAP, REST)).
  • Firmware: This is the device’s software and operating system.
  • Encryption: Encryption protects communications and data stored on the device.
  • Hardware: This is the IoT device hardware (Chip, such as a chip set, Storagestorage, JTAG, UART ports, Sensors, Camera etc.) port, sensor, camera, or other device.

To test IoT devices you have to have a good mix of skills from every other security testing practice, plus a few unique to embedded devices:

  • A tester has to be good at network security to determine what protocols are being used and what information may be at risk.
  • A tester has to be good at normal web tests, to see if there are any weaknesses with any web based configuration interface on the device.
  • A tester has to be good at embedded engineering, and engineering tools to find and back door testing interfaces
  • A tester has to be good at testing obscure OS instances. While a large number of these devices will run some variation of Linux, there are many running QNX, VXworks, Windows embedded, and sometimes custom one-off operating systems.
  • A tester has to be good at reverse engineering and decompiling applications from extracted firmware. Some devices, will not have an OS and will run straight on the metal. For these tests the tester will have to fully reverse engineer the application to determine if it’s vulnerable to attack.