Firmware Security Testing: The Attack Surface Your Annual Pentest Is Missing

What Firmware Is and Why It Matters

Firmware is the low-level software permanently embedded in a hardware device — the code that initializes the hardware, manages its operating environment, and provides the management interface you use to configure it. Every device on your network that isn't a general-purpose server or workstation is running firmware: your Cisco, Fortinet, or Palo Alto firewalls; your Juniper or Arista switches; your IP cameras (Hikvision, Dahua, Axis); your network attached storage (QNAP, Synology); your building management systems and HVAC controllers; your printers and multifunction devices; and the Baseboard Management Controllers (BMC, iDRAC, iLO) embedded in every server in your rack.

Unlike application software, firmware runs below the operating system you manage. It cannot be protected by your EDR agent, cannot be inspected by your SIEM, and in many cases cannot be fully updated without physical access to the device. When a firmware vulnerability is exploited, the attacker gains a foothold that is invisible to every layer of your standard monitoring stack.

The practical consequence is significant: a compromised device can persist through a factory reset, through network quarantine, and through a complete rebuild of the surrounding infrastructure. If an attacker has implanted a backdoor at the firmware level, reimaging the server behind the firewall accomplishes nothing. The firewall itself is the problem.

The Threat Actor Calculus: Why APTs Target Edge Devices

Nation-state threat actors have spent years developing techniques to embed themselves in network edge devices, and the reason is straightforward: edge devices are the one class of infrastructure that organizations consistently fail to patch, fail to monitor, and fail to include in their security assessments.

Volt Typhoon, the China-nexus threat group focused on US critical infrastructure, specifically targets SOHO routers, VPN concentrators, and firewall appliances as hop points for living-off-the-land operations. The group's documented tradecraft involves compromising edge devices and using them as intermediate relay nodes — maintaining persistent access to target environments without ever touching a managed endpoint that EDR might detect. CISA, NSA, and the FBI published a joint advisory in 2024 specifically describing Volt Typhoon embedding persistent implants in edge device firmware to survive reboots and standard incident response procedures.

The Ivanti Connect Secure and FortiGate exploitation waves of 2024 and 2025 demonstrated exactly what firmware-level compromise looks like at scale. In both cases, attackers exploited vulnerabilities in the device management interfaces — code that runs as firmware — to achieve persistent root access that survived device reboots. Organizations that patched the disclosed CVE and rebooted their devices later discovered that some had been re-implanted during the window between disclosure and patching, and the implants had survived. The attacker's access was not in the network; it was in the device.

This is not an academic risk. Every organization that runs managed network appliances and has not formally assessed their firmware security posture has an unknown quantity of unexamined attack surface sitting on their perimeter.

Common Firmware Vulnerability Classes

Firmware vulnerabilities are not exotic. The same categories appear repeatedly across vendors and device types, and many have been present in production devices for years before being discovered or disclosed.

Hardcoded Credentials

One of the most common firmware findings is credentials baked directly into the firmware binary — accounts that cannot be changed through normal administrative interfaces because they exist below the management layer. These range from obvious defaults (admin/admin, root/root, ubnt/ubnt) to vendor-specific maintenance accounts with complex passwords that are nonetheless identical across every device shipped with a given firmware version.

A concrete example: FastNetMon's MikroTik integration plugin shipped with hardcoded API credentials (api / api123) that were baked into the plugin binary. These credentials were the same across all installations and could not be rotated through the product's management interface — a finding we documented as CVE-2026-48695. This pattern is not unique to that product; it appears in network management software, industrial control systems, and consumer routers alike.

Hardcoded credentials are particularly dangerous because they are not visible to standard network scanning. A Nessus or Qualys scan will not tell you that a device has a hidden account with a vendor-assigned password that has never changed. Only firmware analysis reveals them.

Outdated Embedded Third-Party Components

Most network appliance firmware is built on Linux, and most of that Linux environment is assembled from open-source components: BusyBox for a minimal Unix shell environment, OpenSSL for TLS, lighttpd or nginx for the management web server, dnsmasq for DNS, and dozens of other libraries. Vendors integrate these components at a point in time, ship the device, and rarely update the embedded components between major firmware releases.

The result is that a device manufactured in 2021 and still in service in 2026 may be running BusyBox 1.29 (2018), OpenSSL 1.0.2 (end-of-life 2019), and lighttpd 1.4.55 (2021). Each of these carries known CVEs. The vendor's firmware update process may address product-specific vulnerabilities while leaving the underlying component versions untouched for years.

A firmware assessment surfaces this systematically. After extracting the filesystem, the analysis identifies every binary and library, maps it to a version, and cross-references against the CVE database. Organizations routinely discover that devices they consider "patched" are running embedded components with critical CVEs that the vendor has simply not addressed.

Command Injection in Management Interfaces

Web-based management interfaces for network appliances are frequently implemented as thin PHP or CGI wrappers that pass user-supplied parameters directly to shell commands. When input sanitization is absent or incomplete, attackers who can reach the management interface — whether from an internal network, through a credential obtained elsewhere, or through an authentication bypass — can execute arbitrary OS commands with root privileges.

ASUS router firmware has been the subject of multiple CVEs documenting this exact pattern: parameters passed to the management interface being used in shell command construction without sanitization. D-Link and Netgear have published similar advisories over the years. The Hikvision camera backdoor (CVE-2021-36260) allowed unauthenticated remote command execution through exactly this type of flaw — a parameter in the device's web management service was passed to a shell command without validation. By 2022, Shodan indexing showed over 80,000 exposed Hikvision devices still running the vulnerable firmware version.

Insecure Firmware Update Mechanisms

Many devices implement firmware updates without cryptographic signature verification. The update process accepts any binary image uploaded through the management interface (or in some cases, downloaded from a configurable update server URL) and flashes it to the device. An attacker who has compromised the management interface, or who can intercept or redirect the update request, can push malicious firmware that survives all subsequent remediation attempts.

Even devices with signature verification sometimes implement it incorrectly: checking the signature on the outer archive but not the extracted payload, accepting signatures from any key in the vendor's PKI rather than requiring a hardware-bound key, or implementing the verification in a component that can itself be bypassed.

Exposed Debug Interfaces

Production firmware frequently ships with debug interfaces left enabled from the development and manufacturing process. UART serial consoles — exposed on test pads or header pins on the PCB — often provide access to the bootloader (U-Boot) or a root shell at 3.3V or 1.8V TTL levels, requiring nothing more than an inexpensive FTDI adapter and physical access. JTAG interfaces allow hardware-level debugging and direct memory access. Telnet services listening on management or internal network interfaces provide shell access that the web management layer never advertises.

For organizations deploying devices in shared facilities, data centers with contractor access, or any environment where physical access is not fully controlled, exposed debug interfaces represent a meaningful risk. For hardware product manufacturers, shipping devices with enabled debug interfaces to customers is a significant vulnerability in any regulated market.

How Firmware Is Extracted and Analyzed

Firmware security assessment begins with obtaining a copy of the firmware. The method depends on what the vendor provides and how much access is available.

Firmware Acquisition

The simplest path is downloading the firmware image directly from the vendor's support site. Most vendors publish firmware binaries for download, and many of these can be unpacked with standard tools even when the vendor has not intended them to be user-accessible. When vendor downloads are not available or produce encrypted images, physical extraction becomes necessary:

• UART serial interface: Physical access to the device, identification of UART TX/RX/GND pads on the PCB (typically exposed on unpopulated header pads or test points), connection via an FTDI USB-to-serial adapter, and interaction with the bootloader or Linux init process. Many devices will drop to a root shell on the serial console without authentication, or allow bootloader interruption to access filesystem contents.
• JTAG: Hardware debugging interface present on most embedded processors. With the right adapter (Bus Pirate, SEGGER J-Link, or similar), JTAG allows halting the processor, reading memory contents, and dumping the full flash contents to an image file. More invasive but more reliable than UART for devices with secure boot.
• Flash chip desoldering: SPI NOR flash and NAND flash chips can be removed from the board and read directly with a chip programmer (such as a Dediprog or CH341A). This is the fallback when all other interfaces are disabled or secured. It requires soldering skill but provides the raw flash contents with certainty.

Static Analysis Methodology

With a firmware image in hand, analysis follows a structured process:

• binwalk: The starting point for most firmware analysis. binwalk scans the binary image for recognized file signatures — compressed archives (LZMA, gzip, zlib), filesystem headers (SquashFS, JFFS2, CRAMFS, ext2), and executable formats — and extracts the embedded components. Most network appliance firmware uses SquashFS as its root filesystem, which binwalk extracts to a navigable directory tree.
• strings and grep: After extraction, quick reconnaissance with strings identifies embedded plaintext — credentials, API tokens, private keys, URLs, internal path references. Targeted grep patterns (password, api_key, BEGIN RSA PRIVATE, secret, token) surface the most actionable findings rapidly.
• firmwalker: Automated scanning of the extracted filesystem for credentials, certificates, private keys, configuration files, and known-weak patterns. Useful for systematic coverage before deeper manual analysis.
• FACT (Firmware Analysis and Comparison Tool): A more complete framework for firmware analysis that combines extraction, component identification, vulnerability cross-referencing, and comparison across firmware versions. Particularly useful when analyzing multiple firmware versions to track how a vulnerability landscape evolves across updates.
• Ghidra / IDA Pro: Binary analysis of specific executables of interest — the management web server, the update daemon, authentication handlers, or any binary identified as interesting during initial reconnaissance. Static analysis reveals the logic of functions that grep found suspicious, confirms whether sanitization is actually performed, and identifies code patterns that lead to exploitable conditions.
• QEMU emulation: Many firmware images targeting MIPS, ARM, or ARM64 processors can be run under QEMU emulation without physical hardware. This enables dynamic testing — actually running the management web server and sending it crafted requests, observing process behavior, testing update flows — in a controlled environment.

Real Incidents That Illustrate the Risk

Firmware vulnerabilities are not theoretical. They have driven some of the most consequential security incidents of the past decade.

Juniper Networks ScreenOS Backdoor (2015)

In December 2015, Juniper disclosed that unauthorized code had been present in its ScreenOS firewall operating system. The code included two components: one that enabled passive VPN traffic decryption using a modified Dual EC DRBG constant (linked to NSA involvement in the original algorithm), and a second that added a hardcoded SSH password permitting unauthenticated access to any ScreenOS device. The backdoor had been present in production firmware for years. Organizations running Juniper NetScreen firewalls had an undetected authentication bypass in their perimeter devices that they had no way to discover through standard security testing.

Hikvision CVE-2021-36260

A command injection vulnerability in Hikvision IP cameras allowed unauthenticated remote code execution via the device's web management interface. No credentials were required. The flaw existed because a parameter in an HTTP request handler was passed directly to a system command. Hikvision published a patch, but uptake was poor — Shodan data published by security researchers in 2022 showed over 80,000 devices still running the vulnerable firmware. Camera networks at corporate offices, warehouses, hospitals, and government facilities remained exploitable years after the patch was available.

QNAP NAS Ransomware Campaigns

Beginning in 2021 and recurring through 2023, multiple ransomware groups including Qlocker and DeadBolt systematically targeted QNAP NAS devices by exploiting known firmware vulnerabilities — in some cases vulnerabilities that had been patched years earlier but for which users had never applied the update. Because NAS devices often sit on internal networks with broad file access, a compromised NAS device provided attackers with direct access to organizational data stores. The campaign illustrated both the risk of unpatched firmware and the organizational tendency to treat NAS devices as infrastructure rather than security-relevant endpoints.

Volt Typhoon and SOHO Router Implants

The ongoing Volt Typhoon campaign documents the most sophisticated end of the firmware threat spectrum. The group specifically seeks out end-of-life SOHO routers — devices whose vendors no longer publish firmware updates — and compromises them to build a proxy network of legitimate-looking IP addresses. Because the compromised devices belong to US organizations (often small businesses and home offices), traffic routed through them appears to originate from domestic infrastructure. CISA's advisories specifically note that some compromised devices had firmware modifications that persisted through factory resets, requiring hardware replacement rather than software remediation.

Standard Network Pentest vs. Firmware Security Assessment

The table below illustrates why these are complementary disciplines rather than substitutes. A standard network penetration test is essential and well-defined. It simply does not reach the attack surface that firmware assessment addresses.

Who Needs Firmware Security Testing

Firmware assessment is not exclusively for large enterprises. The following situations create clear requirements or strong justification:

Organizations with Compliance Scope That Includes Hardware

• PCI DSS: Payment card networks and point-of-sale systems involve embedded device firmware. PCI DSS 4.0 Requirement 6 (Develop and Maintain Secure Systems and Software) explicitly covers all system components in the cardholder data environment, including firmware on payment terminals and network appliances in-scope.
• HIPAA: Covered entities and business associates deploying medical IoT devices — infusion pumps, patient monitoring equipment, imaging systems, building access control in clinical facilities — are responsible for the security of those devices under the HIPAA Security Rule technical safeguards requirements.
• CMMC / NIST 800-171: Defense contractors processing CUI on networks that include unassessed firmware in network appliances may have gaps in their system security plan. NIST 800-171 control families covering configuration management and system and communications protection apply to all components of the system boundary.
• ISO 27001: Annex A control A.8.9 (Configuration management) and A.8.8 (Management of technical vulnerabilities) both apply to firmware on in-scope devices. ISO 27001 assessors are increasingly asking about firmware patching processes and embedded device inventories.

Organizations with Edge Devices Not Updated in 12+ Months

If your firewall, VPN gateway, or managed switches have not received a firmware update in over a year, and particularly if any of those devices are end-of-life with no available updates from the vendor, a firmware assessment is the only way to understand what vulnerabilities are present and whether workarounds or compensating controls are required.

Organizations Building or Shipping Hardware Products

Any company developing an IoT device, network appliance, or embedded hardware product for commercial sale has a product security obligation. Pre-release firmware assessment identifies vulnerabilities before they ship to customers. Post-release assessment validates that updates have addressed reported issues and that new firmware versions have not introduced regressions. Hardware manufacturers subject to FTC enforcement actions, EU Cyber Resilience Act requirements, or FDA medical device cybersecurity guidance have regulatory requirements to demonstrate security testing.

Organizations That Have Experienced a Network Perimeter Compromise

If your organization has been through a security incident involving network appliances — particularly if the incident involved a firewall, VPN gateway, or router — firmware analysis is a necessary component of incident response. Standard forensics on these devices is insufficient. Confirming that a device is clean requires analysis at the firmware level, not just a review of log files and running processes.

Incorporating Firmware Into Your Security Program

You do not need to treat every network-connected device as in scope for a comprehensive firmware assessment simultaneously. A pragmatic approach involves prioritizing by exposure and consequence:

• Tier 1 — Network edge and internet-facing appliances: Firewalls, VPN gateways, load balancers, edge routers. These devices have the highest attacker interest and the greatest consequence if compromised. They should be assessed first, and firmware update processes for these devices should be documented and actively maintained.
• Tier 2 — Internal infrastructure with broad network access: Core switches, NAS devices, management servers, BMCs. A compromised NAS or BMC provides lateral movement opportunities or persistent administrative access that is extremely difficult to detect and remediate.
• Tier 3 — Operational and IoT devices: IP cameras, printers, building management systems, HVAC controllers, physical access control. Lower attacker priority in most environments, but often the least-patched and most-overlooked devices on the network.

Firmware assessment should also be incorporated into hardware procurement criteria. Before deploying a new network appliance vendor, reviewing their firmware security history, their vulnerability disclosure program, and the update delivery mechanism should be standard practice. Vendors who do not sign their firmware updates, do not publish CVEs, or have a pattern of shipping EOL open-source components deserve additional scrutiny before they are placed at your network perimeter.

Finally, firmware should appear in your asset inventory alongside every other managed system. If your CMDB does not include firmware version information for your network appliances, you cannot assess patching compliance or triage new vulnerability disclosures. The first step is knowing what you have and what version it is running.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

Lorikeet Security helps modern engineering teams ship safer software. Our work spans web applications, APIs, cloud infrastructure, and AI-generated codebases — and everything we publish here comes from patterns we see in real client engagements.

Practical security, written by practitioners.