By Alex Teague
Welcome to part two of my blog detailing the process, and implications of deep IoT and OT device vulnerability research.
6. Insecure Remote Access Implementations
The proliferation of remote access in OT has introduced a new category of vulnerabilities that sits at the boundary between IT and OT security.
Many OT vendors provide proprietary remote access solutions cloud-connected gateways, VPN appliances, or vendor-specific remote desktop tools that allow engineers and support teams to access field devices from anywhere in the world. The security of these solutions varies enormously, and in my experience, they are frequently the weakest link in an otherwise reasonably segmented OT network.
Common issues include, predictable or hardcoded credentials for the remote access portal, lack of multi-factor authentication, insufficient access controls that allow a remote user to access devices beyond the scope of their authorisation, insecure communication between the on-premises gateway and the cloud infrastructure, and logging failures that prevent the detection of unauthorised access.
There is also the matter of supply chain risk. A vendor’s remote access solution may be used across thousands of customer sites, meaning that a single vulnerability in the solution or a compromise of the vendor’s own infrastructure could provide an attacker with simultaneous access to a vast number of operational environments.
What I look for: Authentication mechanism assessment, MFA enforcement, access control boundary testing, communication security between gateway and cloud infrastructure, logging and audit trail completeness, supply chain risk assessment.
7. Web Interface and Management Plane Vulnerabilities
The majority of IoT and OT devices now ship with an embedded web server providing a management interface. These interfaces range from simple configuration pages to sophisticated dashboards with real-time process visualisation, and they present a substantial attack surface.
The vulnerability classes here are familiar to any web application security researcher SQL injection, cross-site scripting, cross-site request forgery, command injection, path traversal, authentication bypass but they occur in a context where the consequences are dramatically amplified. A command injection vulnerability in the web interface of an industrial router does not merely compromise a web application. It provides a foothold on a device that sits at the boundary of the OT network, from which lateral movement becomes possible.
A pattern I encounter with concerning regularity is the presence of undocumented API endpoints in device web interfaces endpoints that were created during development or testing, not removed before production, and not protected by authentication. These endpoints sometimes expose sensitive configuration data, in some cases they have allowed configuration changes or command execution.
Directory traversal vulnerabilities in embedded web servers are similarly common, arising from implementations that do not adequately validate file path components. On a device where the web server runs as root which is, again, common in embedded systems a path traversal vulnerability provides read access to the entire filesystem, including stored credentials, private keys, and configuration files.
What I look for: Full enumeration of web interface functionality including undocumented endpoints, authentication mechanism testing, standard web vulnerability assessment (injection, XSS, CSRF, IDOR), privilege separation assessment, filesystem access boundary testing.
8. Insecure Data Storage and Transmission
The final category I will cover here concerns how devices store sensitive information and how they protect data in transit two areas where the findings are, frankly, often quite poor.
Sensitive data credentials, cryptographic keys, configuration parameters are frequently stored in plaintext on device filesystems or in configuration files. In one instance the decryption key was stored alongside the ciphertext! Firmware images extracted from devices routinely yield private keys, API credentials, and hardcoded passwords that can be used to compromise not only the device itself but the backend infrastructure it connects to.
Data in transit is similarly exposed. Many OT protocols transmit process values, commands, and even credentials in cleartext. Where encryption is implemented, it is often optional, disabled by default, or implemented with deprecated cipher suites that provide little practical protection. The 2022 OT:ICEFALL findings included several instances where vendors had added encryption as a feature but shipped devices with it disabled.
What I look for: Firmware filesystem analysis for sensitive data, TLS/SSL configuration and cipher suite assessment, protocol-level traffic analysis, assessment of whether security features are enabled by default or require explicit configuration.
The Research Process: How This Work is Actually Done
For those unfamiliar with hardware and embedded security research, it may be useful to briefly describe the practical mechanics of this work. Vulnerability research in this space is a long way from the popular image of a hacker typing furiously at a terminal. It is, in reality, a slow, methodical, and often painstaking process.
Hardware acquisition and reconnaissance is the starting point. Obtaining the target device which may require purchasing it commercially, borrowing a unit from a client, or, in some cases, significant effort to source from specialist suppliers is followed by a detailed reconnaissance phase: reviewing all available documentation, firmware release notes, vendor security advisories, prior CVEs, and academic or conference research touching on the device or its underlying components.
Firmware acquisition is frequently the first technical challenge. Some devices serve firmware images directly from the vendor’s website, others require extraction from the device itself. Hardware-based extraction using JTAG or UART interfaces for debugging access, or directly interfacing with the flash storage chip using an SPI programmer is a core skill in this work. The ability to obtain the raw firmware image is the foundation of almost everything else.
Firmware analysis using tools such as Binwalk, and Ghidra allows me to unpack the filesystem, and begin static analysis of binaries of interest. This phase often yields significant findings directly hardcoded credentials, embedded keys, insecure configuration defaults before any dynamic testing has begun.
Protocol analysis involves capturing network traffic between the device and its associated software (engineering workstation, cloud platform, mobile app etc) and dissecting the protocols in use. Wireshark, with appropriate dissectors where available, and custom tooling where not, is central to this work. Understanding the protocol is a prerequisite to fuzzing it effectively.
Dynamic testing and fuzzing exposes the running device to unexpected inputs malformed packets, boundary-condition values, unexpected sequences of valid commands to identify crash conditions and potential memory corruption vulnerabilities. Effective fuzzing requires understanding the protocol and the device well enough to generate inputs that reach interesting code paths rather than being rejected at the first parsing stage.
Exploitation and proof of concept development is the final stage not for operational use, but to demonstrate that a vulnerability is genuinely exploitable rather than merely theoretical, and to provide the vendor with a concrete demonstration of impact that can drive prioritisation and remediation effort.
Why This Research Matters to Your Organisation
Having described what this research involves and what it finds, I want to turn to the question that rightly occupies the minds of CISO, operations directors, and board members. Why should an organisation invest in it?
Understanding Your True Risk Posture
Organisations routinely commission penetration tests of their IT infrastructure, their web applications, and their cloud environments. Far fewer undertake rigorous security assessment of the OT and IoT devices that underpin their operations. The consequence is a significant blind spot in their risk posture one that threat actors are increasingly aware of and actively targeting.
Independent vulnerability research on the devices you operate provides a factual basis for risk assessment that no amount of vendor assurance can substitute for. Vendors have commercial incentives to minimise the severity of vulnerabilities in their products and to characterise insecure-by-design features as acceptable trade-offs. An independent researcher has no such incentive. The findings from a rigorous device assessment tell you, with specificity, what an attacker who gains access to your OT network can actually do not what the vendor’s marketing materials suggest they cannot.
Prioritising Remediation Effort
Not all vulnerabilities are equal, and not all remediation options are equally viable in OT environments. Understanding the specific vulnerabilities present in your environment and their exploitability in the context of your network architecture, your threat model, and your operational constraints allows you to prioritise mitigation effort rationally rather than in response to vendor advisories that may not reflect the actual risk in your specific context.
In many cases, device-level vulnerabilities cannot be patched in a timely fashion the vendor patch may not yet exist, or operational constraints preclude downtime for firmware updates. In these cases, understanding the vulnerability in detail is essential to designing compensating controls, network segmentation rules that prevent an attacker from reaching the vulnerable interface, monitoring signatures that detect exploitation attempts, or procedural controls that reduce the window of exposure.
Informing Procurement Decisions
The findings from vulnerability research on OT and IoT devices provide organisations with a powerful lever in procurement discussions. Vendors who are aware that their products are subject to independent security scrutiny have a stronger incentive to invest in secure development practices. Procurement teams armed with specific, technical security requirements derived from research findings can hold vendors to a higher standard and make informed decisions between competing products.
Sustained pressure from the customer base including the credible threat of independent security assessment is one of the mechanisms by which that pressure on manufacturers to improve the security of their products can be brought to bear.
Regulatory Compliance and Cyber Resilience Frameworks
The regulatory environment around OT and IoT security is evolving rapidly. In the United Kingdom, the Network and Information Systems (NIS) Regulations and their successor, NIS2, which continues to shape domestic regulatory thinking impose requirements on operators of essential services to take appropriate and proportionate technical and organisational measures to manage security risks.
Demonstrating that you have rigorously assessed the security of your OT and IoT devices including through independent vulnerability research is increasingly relevant to regulatory compliance conversations. It provides evidence of due diligence that a tick-box questionnaire approach cannot. Equally importantly, it generates the technical understanding of your environment that meaningful cyber resilience planning requires.
Reducing Mean Time to Detection and Response
One of the outputs of thorough device vulnerability research is a detailed understanding of what exploitation looks like at the network and protocol level. This understanding directly informs the development of detection logic for security monitoring systems whether a dedicated OT/ICS security platform such as those offered by Claroty, Dragos, etc, or a broader SIEM implementation.
Knowing that a particular vulnerability is exploitable via a specific sequence of protocol commands, or that a compromised device will exhibit specific network behaviour, allows a security operations team to develop detection signatures that are grounded in reality rather than generic threat intelligence. This translates directly into reduced mean time to detection when an attacker actually attempts exploitation.
Supply Chain Risk Management
Many of the most significant findings in this space arise not from bespoke vulnerabilities in a single product but from shared components, reference designs, or libraries that are used across multiple vendors’ products. A vulnerability in a widely-used TCP/IP stack can affect hundreds of distinct products from dozens of vendors.
Vulnerability research that maps the component supply chain of your OT and IoT devices identifying shared firmware components, underlying operating systems, and third-party libraries provides insight into your exposure to these systemic vulnerabilities. It also informs your monitoring and incident response planning: if a critical vulnerability is disclosed in a component used across your estate, understanding which devices are affected is the first step to an effective response.
Responsible Disclosure and the Vendor Relationship
A word on the process by which findings from this research reach vendors and, ultimately, the public. Responsible disclosure the practice of notifying a vendor of a vulnerability in private, allowing a reasonable period for remediation before public disclosure, and then publishing findings in a way that informs the broader community is the standard I hold myself to and advocate for in this industry.
The vendor relationship in OT and IoT security research is not always straightforward. Some vendors engage constructively with disclosures, assign CVEs promptly, develop patches in a timely fashion, and provide clear communication to customers. Others are less responsive dismissing findings, disputing severity ratings, or fail to produce patches within any reasonable timeframe.
Independent research provides insight into vulnerabilities that have not yet been disclosed and, in the case of insecure-by-design issues, vulnerabilities that may never receive a formal advisory because they are not acknowledged as vulnerabilities by the vendor.
Conclusion: The Case for Taking This Seriously
The OT:ICEFALL research was significant not because it revealed something unknown, but because it demonstrated with clarity and rigour what those of us in this field had long observed: that insecure-by-design practices are endemic across the OT device market, that major vendors with well-resourced engineering organisations have shipped and continue to ship products with fundamental security failures, and that the devices controlling our critical infrastructure are, in many cases, far more vulnerable than the organisations operating them understand.
This is not a counsel of despair. The situation is improvable, and it is improving albeit slowly. Vendor investment in secure development practices is increasing. Regulatory frameworks are strengthening. The community of researchers working in this space is growing, and the quality of the research being produced is rising. Organisations that engage seriously with OT and IoT security that invest in understanding their device estate, that demand security assurance from vendors, that implement the monitoring and segmentation controls that make exploitation harder and detection more likely are meaningfully reducing their risk.
The question is not whether to take OT and IoT device security seriously. The question is whether to do so proactively, on your own terms, with the benefit of detailed technical understanding or reactively, after an incident has demonstrated the cost of the alternative.
In my experience, the organisations that have engaged most seriously with this work are not those that have suffered a breach. They are those that looked carefully at what an attacker could do with their OT estate, understood it clearly, and decided that was not a risk they were prepared to carry.
That is, I would argue, precisely the right response.
This post reflects the author’s own research experience and professional perspective. References to specific research programmes including OT:ICEFALL are drawn from published, publicly available material. For enquiries about independent OT and IoT device security assessments, please get in touch.
