Surfing The Security Tsunami - IoT Security Blog Series


A pragmatic approach to finding risks with regard to IoT in your environment.

Continuing where we left off in the blog post “Zombie Rodents in your Network” we will now outline a pragmatic approach to finding risks with regard to IoT in your environment. This starts with discovering what IoT is in the network and goes into detail about reverse engineering firmware.

Part One: IoT and the Columbus Method 

Discover it, then land on it

Every network or security practitioner that we interviewed for this series expressed dismay due to the lack of visibility regarding IoT devices that are resident in their networks. In most cases, departments within the company have employed the dreaded Shadow IT process for implementing IoT solutions outside of the organization’s IT protocols. Additionally, IoT devices also fall between the cracks and may not be de-provisioned once their service is no longer required.

Identifying all IoT devices in the network is not entirely straightforward as many of these endpoints are unmanaged. Fortunately, the industry is beginning to address this need with tools. 

As this blog series strives to be impartial to specific vendors, we will merely present several solutions that we have become aware of through our research and interviews. This will not constitute a review of capabilities, accuracy, or quality rather this is merely a list of some vendors and their claims. As with all IT purchases, caveat emptor is the rational approach: this is the principle that the buyer alone is responsible for ensuring suitability of a solution prior to procurement.

Selected IoT Asset Discovery Solutions

(NOTE: By no means is this a comprehensive list of IoT Asset Discovery solutions vendors. No slight has been intended or implied by the author due to omission from this list. Five vendors should be a sufficient sampling for this blog.)

  • Fortinet Fortiguard IoT Service: Helps customers significantly reduce their attack surface by enabling the Fortinet Security Fabric to automatically discover and segment IoT devices based on FortiGuard intelligence. Although this can be purchased a la carte, when used along with the Fortinet Security Fabric, identified IoT devices may be automatically assigned to a bulwarked VLAN.

    (NOTE: More on network segmentation as a risk mitigation strategy will be covered in the next blog in this series.)
  • Ōrdr Systems Control Engine: An IoT device security platform that will discover every connected device, profile device behavior and risks, and automate response. This is a cloud-based solution with two levels: Core identifies, classifies, and assesses behavior to provide a risk assessment. Premium provides all that plus integrations with selected security and networking solutions to automate mitigation.

    (NOTE: Agentless solutions are required for unmanaged IoT devices as most have no interface)
  • Armis: An agentless security platform for managed and unmanaged IoT devices. The claim of “discover every managed, unmanaged, and IoT device on and off of your network” may be worth unpacking with an Armis representative for clarification. Integration with CISCO ISE, ServiceNow Configuration Management DataBase, CheckPoint, NAC and SIEMS is a plus.
  • ThreatWarrior: Agentless IoT Security and driven by Machine Learning, this is a cloud-based, passive security platform for analysis and classification. Immunization from threats may be then enacted by Network and Security teams.
  • ForeScout: In order to present a solution to IoT security threats, ForeScout offers a no-charge “baseline visibility test”. The CounterAct Posture Assessment Engine and Library has a unique approach by using well-known default, commonly used and even custom login credentials to demonstrate.
  • Bastille Networks: This very unique solution works in the Radio Frequency (RF) realm, which is clearly a threat vector that is a major concern. Discovering rogue Wi-Fi hotspots, Pineapples (a type of honeypot from Hak5), Bluetooth devices, unauthorized cameras and other sensors is the first step in preventing bad actors from exploiting this frontier.

Weeding the Garden

The third post in this blog series is set to discuss securing IoT threats but it is self-evident that once the discovery phase is completed there will be obvious devices that have “volunteered” to be in the network outside of IT policies and protocols.

Just as in a vegetable garden, some discernment as to the desirability of particular volunteers should be made: beneficial IoT may be retained according to IT policies and other devices may simply be removed.

Part Two: Firmware Reverse Engineering

In this section, we will unwrap the approach and processes required to assess the security posture of a firmware package.


  • Extracting the firmware and code underneath it is often accomplished by simply downloading it from the vendors’ website. In some cases, vendors require a support agreement with them. In many cases the vendor must assume that only customers would download firmware because they own the device that uses it.
    • If the vendor uses open source code in the package it will fall under the “copyleft” obligations of General Public License (GPL) which means that they must avail the code to the public. Remember, Linux is GPL…we heard several complaints about this in the field and in our research.  If it is Linux-based (~95% of IoT) then the public is entitled to access the firmware.
    • Sniffing traffic over the wire is possible but may be tedious. The concept is to capture a firmware upgrade as it is on the way to the device.
    • When there is actual access to the device, it is plausible that there may be a physical method to get into it such as debug ports which may have UART, SPI or JTAG interfaces.
    • The goal is to access the flash storage chip. Most manufacturers make the pin-outs available in data sheets.  The chip should then be isolated from other electrical components. This may entail configuring reset pins or even de-soldering the chip and putting it in an emulator such as a SOIC chip-clip. For SPI’s there are hardware boards (such as a Shikra).  JTAG is interesting because it’s the industry standard instrumentation on chips. You can use a tool such as OpenOCD to perform boundary scans. 
  • Reverse Engineering Tooling may be limited to manual techniques, but new tools may eliminate some of this drudgery. The next step is to analyze the code and find it is encrypted or just compressed.  Many packages are just compressed for size constraints. Encrypted code is a horse of a different color.  If Its encrypted with XOR or AS, it does add a fair amount of complexity which will require more research. 
    • Once the firmware can be accessed in the clear it can be opened with a hex viewer. Browser such as Chrome and Mozilla have plugins that make this quite straightforward.    
    • Scope out where the filesystems, the boot loader, the kernel and even the memory reside (if not too protected). Take out the trusty, dusty Linux Grep command and either build scripts or perhaps use other tools to start the reconnaissance. Binwalk, Firmwalker, Firmware Mod Kit and Firmware Analysis Toolkit can be found on Github to make this less of a manual process.
  • Seek and Find
    • With a little luck, Telnet or SSH credentials may be found in the clear.
    • There may be backdoors that the developers have left open.
    • URLs referenced in the code may lead to well-known vulnerabilities that can be exploited.
    • With great luck, tokens may even be uncovered.
    • API keys are important to look for as they enable machine-to-machine communication.
    • Surfing the file paths may reveal where certificates (think PEM files) are stored.
    • Find any information regarding the versions of components and cross reference them to common vulnerability enumerations (CVEs) for known vulnerabilities that may establish a beachhead for traversing the code base.
  • Pentesting starts by mapping the attack surface in the firmware, filesystems, libraries, communication protocols and ports. Vendor manuals and public forums may yield valuable information.
    • Review the firmware, filesystems, libraries, communications protocols and physical ports. Most pen testing requires a team because, for example, communications are quite a bit different than firmware design so different skills, disciplines and experience are required.
    • Even if it looks like a vulnerable duck, it may not be. Sometimes by intention developers will obfuscate or hide certain aspects of what they are doing, and it may look like a bona fide CVE even though it’s not. It is critical that any suspected vulnerability be tested in a proof-of-concept to ensure that it can be compromised. An experienced practitioner will know how to prioritize the suspects by efficacy and risk.
  • Develop the remediation plan    
    • Bring the results to the developers if that is possible.
    • Crowd-sourced bug reporting or the Product Security Incident Response Team (PSIRT) may be engaged.
    • If the development team employs a Threat Modeling program, results from the pentest will help to improve institutional knowledge and possibly carry over into other development projects within the firm.
  • Discerning results from Pentesting: To illustrate which has been covered in the previous section, the author has chosen to use results from the IoT Inspector tool.
    (NOTE: IoT Inspector was selected for this blog series due to the author’s familiarity with the developers of the product. For objectivity, there are other tools that may deliver similar results such as Black Duck for open-source and Refirm Labs)
Excerpt from IoT an Inspector Report, 2020


Here are plugins in the tool that will be used:

Excerpt from an IoT Inspector Report, 2020


The IoT Inspector has a compliance matrix that may be helpful from the remediation perspective and even to get the developers on board with revising the firmware.

Excerpt from an IoT Inspector Report, 2020


Software component detection would typically include:

Excerpt from an IoT Inspector Report, 2020


Configuration vulnerabilities need to be assessed as well. In the case of the illustration below, there is a “Dangerous Service Launch”.

Excerpt from an IoT Inspector Report, 2020


In the next example from the report on the same firmware, hard-coded passwords are discovered.

Excerpt from an IoT Inspector Report, 2020


There is information leakage detection box at the bottom. It’s saying that the Apache subversion files can leak, and this is something you just want to know. 

Excerpt from an IoT Inspector Report, 2020


Additional aspects of a firmware analysis would include:

  • Extracting features (whether AMD, ARM or whatever)
  • Enumerating management protocols
  • Finding version-based vulnerabilities in the kernel
  • Search for private key detections – in this case there were some
  • Determine software and commands that are unwated. TCP dump is not necessary and could be problematic on an IoT device.
Excerpt from an IoT Inspector Report, 2020


The IoT Inspector tool summarizes the results by priority of the likelihood and severity of a potential exploitation. The confidence level indicates whether the vulnerability is proven or needs additional investigation or contextual analysis. For example, the hard-coded password hashes were proven, so the confidence was firm. 


Finding IoT devices in the network should be a periodic operational imperative. Fortunately, sufficient investment in solving this nettling issue is resulting in tools of various effectiveness by several vendors (even scheduling re-scans), all of whom seem to recognize the need to homologate or integrate with other vendors. Reverse engineering firmware, as demonstrated in this post, may exceed the capabilities of most enterprise IT staff and is laborious in any case. Again, tools may be employed that can be very exacting and meticulous and these are expected to improve as they are widely used and further developed.

In the final blog post in this series, we will explore methods and processes for applying Digital Security best-practices for maintain a reasonable security posture for the IoT Tsunami.


Special thanks: The research from which content for this blog series has been derived includes numerous books, articles, websites and interviews with IT professionals plus peer review by several SEC Consult experts. We would like to especially extend our gratitude to the authors of these two books in particular. We wholly recommend these two works for any practitioner desiring a deeper understanding of some key concepts that we have laid out in this series.

  • Veneri, Giacomo / Capasso, Antonio: Hands-On Industrial Internet of Things. Create a powerful Industrial IoT infrastructure using Industry 4. 0. 
  • Gupta, Aditya: The IoT Hacker's Handbook. A Practical Guide to Hacking the Internet of Things. 

Upcoming Event in February: Online Seminar "IoT Infrastructure Risks? An Approach to Enterprise IoT Security"

Are you interested in IoT? Join us in our next Online Seminar on February 25th, 2021, 4p.m. (CET).

Topic: IoT Infrastructure Risks? An Approach to Enterprise IoT Security

Experts from SEC Consult and IoT Inspector will talk about potential security issues, base-line security assurance for IoT and an approach for IoT security penetration tests.

Register for free. We are looking forward to see you there.

More On The Topic

About the author

Kelly Robertson
SEC Consult America, Inc.
CEO SEC Consult America

Mr. Robertson is an accomplished researcher, author and educator with a passion for the InfoSec tradecraft. He seeks in all endeavors to elevate risk awareness and to align InfoSec practitioners with the business objectives that organizations must meet. He is a CISSP and is also the Education Director for the Silicon Valley ISSA.