Assessing Enterprise Firmware Security Risk in 2020

Download the PDF >

5 questions to evaluate and improve your firmware security posture


2019 had the most firmware vulnerabilities ever discovered, marking a 43% rise over the previous record in 2018, and a staggering growth of 750% since 2016. In many ways it was a transformative year in which firmware security hit the mainstream. Leading analysts sounded the alarm on the immediate need for better firmware security for enterprise devices and the risk to organizations that fail to adapt. Firmware gained increased focus for regulatory compliance as standards continued to map to the NIST Cybersecurity Framework and its detailed focus on risks and threats at the firmware layer.  Manufacturers further validated the growing risk by stepping up their efforts to address firmware and hardware security at the platform level. 

In addition to the ongoing surge in vulnerabilities, attacks in the wild continued to target firmware in order to achieve persistence, evade security controls, and further strategic attacks. F-Secure found that compromised firmware was the 3rd most common infection vector in 1H 2019, accounting for 12% of attacks disrupting companies, public entities and other organizations. Attacks followed a variety of paths including the well-worn progression of malware attacks, network-based attacks, as well as hardware and supply chain attacks.

With these developments in mind, this report aims to give security teams and their leaders a way to self-assess their firmware security in light of the biggest trends of the past year. In each section we pose a fundamental question concerning firmware security readiness and why it is important based on the events of the previous year. While not an exhaustive list of firmware security topics, we hope that these questions can give organizations a way to begin evaluating their risk with regard to firmware.

1 | Do You Have Visibility Into Your Firmware Vulnerabilities and Assets?

1 | Do You Have Visibility Into Your Firmware Vulnerabillities and Assets?

Vulnerability management is unquestionably one of the most fundamental aspects of a solid security program. And while vulnerability scanning and patching efforts are standard practice for software and operating systems, most organizations lack that same rigor for the firmware in their devices. These lapses have become a serious liability in 2019 both in terms of potential risk and realized threats.

First, the discovery of new firmware vulnerabilities has continued to skyrocket. 2019 was the third consecutive year to set a new record for firmware vulnerabilities, growing 43% over 2018. The total number of CVEs was 7.5 times larger than what was documented just three years ago. Firmware vulnerabilities can also be found in virtually any component within a device including the system firmware such as UEFI or BIOS as well as drives, network adapters, memory, processors, graphics cards, and so on.

Firmware Vulnerabilities by Year 2016-2019 Chart

Weaknesses in firmware can be particularly high impact vulnerabilities due to the privileges and control they can provide to attackers. The combination of  privileges with stealth translates to real-world impact, which can be seen in the MITRE ATT&CK framework where firmware is featured prominently in the categories of Defense Evasion (T1109), Persistence (T1019, T1109) and Impact (T1495).

In addition to vulnerabilities, organizations must have visibility into the reliability of their assets. Devices should be running up-to-date and supported firmware in order to ensure their best performance.  However, most organizations lack the basic visibility to know if the firmware in a device is current or even supported at all in the case of legacy devices.

As you consider the organizational risk of firmware and its impact on your asset and vulnerability management programs, we encourage you to review some of the recent Eclypsium research. These provide examples of real-world, exploitable vulnerabilities that you can use to help assess your visibility and management. The table below summarizes some of the most notable vulnerabilities found by Eclypsium in the past year.

TopicSummaryFurther Reading
Driver VulnerabilitiesDiscovery of widespread issues affecting more than dozens of drivers across 17 different vendors. These powerful drivers can be used by attackers and malware to escalate privileges and potentially add firmware implants that can subvert the boot process and the OS itself.

Screwed Drivers

The Mother of All Drivers
Remote Server VulnerabilitiesVulnerabilities in baseboard management controllers (BMCs) of servers, which allow an attacker to easily connect to a server and virtually mount any USB device of their choosing to the server, remotely over any network including the Internet.

USB Anywhere
Vulnerabilities in the Supply ChainDiscovery of vulnerabilities in a 3rd party firmware vendor, and how those vulnerabilities ended up affecting multiple enterprise-class servers.

Vulnerabilities in the Firmware Supply Chain
Vulnerabilities in Cloud HostingDiscovery of vulnerabilities in the hardware underlying bare metal hosting services. This style of vulnerability can allow an attacker to install a firmware implant that persists from one customer to the next.Bare Metal Cloud Vulnerabilities

Unfortunately, the firmware blindspot is translating into real impact for organizations. A study by Forrester found that “63% of companies have experienced a data compromise or breach within the past 12 months due to an exploited vulnerability in hardware- or silicon-level security”. The impacts of these compromises even extended into critical infrastructure when attackers used simple scripts to attack unpatched Cisco devices, resulting in a denial-of-service against the US power grid. Looking forward, Gartner published a prediction that by 2022, 70% of enterprises without a firmware upgrade plan will be breached due to a firmware vulnerability. The clear consensus is that organizations that ignore firmware vulnerabilities will face an increasingly tough present and future.


  • Gain greater visibility into your potential attack surface by adding firmware attributes to the data collected as part of your asset management program.
  • Integrate managing firmware with existing hardware and operating system lifecycle programs.
  • In addition to system firmware, ensure you have visibility into firmware vulnerabilities in device components.
  • Add regular automated vulnerability scanning for firmware vulnerabilities and misconfigurations.
  • Incorporate firmware vulnerability metrics into your existing vulnerability management program reports.
  • Conduct an assessment of the discoverability of vulnerabilities in external facing assets using tools such as Shodan and Nmap to understand what adversaries may uncover as part of initial reconnaissance activities.
  • Consider tools to streamline the firmware update process.

2 | Can Your Organization Detect Firmware Tampering?

2 | Can Your Organization Detect Firmware Tampering
Detect firmware tampering

Once organizations have visibility into their attack surface, they need to be able to detect the signs of attack. This can include continuous monitoring to detect any tampering of firmware as well as on-demand interrogations in response to suspicious activity. Unfortunately, this is often a challenge when it comes to firmware and hardware. Traditional security controls are often limited to the OS and software layers, and lack visibility into threats at lower levels. 

Defense evasion is one of the major motivating factors that drives attackers to the firmware layer in the first place. The ability to hide at the firmware layer provides attackers with some of the most reliable persistence possible, with the ability to persist across full system re-imaging or even replacement of storage drives. Likewise, malicious code within firmware can give attackers the highest levels of privilege, disrupt the boot process of the device, patch the OS itself, and gain near-omnipotent control over the device. 

2019 provided ample examples of such threats in the wild:

  • QSnatch Malware: A new strain of malware was discovered targeting network attached storage (NAS) devices made by technology vendor, QNAP. The malware modified the firmware of victim devices to achieve a variety of ends including stealing usernames and passwords, preventing the update of firmware, and controlling regularly scheduled jobs and scripts. Cr1ptT0r ransomware also infected NAS devices from D-Link in 2019.
  • JungleSec Ransomware: JungleSec attacked devices over the network by targeting the IPMI interfaces used for the out-of-band management of enterprise servers. Vulnerabilities in IPMI and baseboard management controllers (BMCs) are quite common, and compromises can allow attackers to steal data or disable the affected server entirely.
  • DoS Attacks Against U.S. Power Plants: Network outages in U.S. power plants were attributed to firmware vulnerabilities in Cisco ASA firewalls. NERC provided a detailed ‘Lesson Learned’ analysis entitled Risks Posed by Firewall Firmware Vulnerabilities. This attack also underscores the importance of including the often overlooked area of network devices in the enterprise security model.
  • Hackers also went after Cisco RV320/RV325 routers, two models very popular among internet service providers and large enterprises, taking advantage of vulnerabilities that allow a remote attacker to get sensitive device configuration details and inject and run admin commands on the device without a password.

And, within the first two weeks of January, 2020 attackers began exploiting Citrix vulnerabilities in the wild, using public proof-of-concept exploit code for CVE-2019-19781, a vulnerability in Citrix enterprise equipment that can allow hackers to take over devices and access a companies’ internal networks over the internet, without authentication credentials.

These are just a few examples of how firmware can be attacked. Traditional attacks at the software layer such as malware can be extended to the firmware layer via firmware vulnerabilities or readily available drivers as detailed in our recent analysis. Firmware attacks can also be launched over the network as seen in the JungleSec ransomware and the USB Anywhere research. 

Likewise, attacks can also come via physical access using USB, Thunderbolt, PCIe, or other external devices. While these techniques can be applied to any device, they are of particular concern to laptops, which are often exposed to physical attack and can easily be compromised during travel. With just a few minutes of access to a laptop, such as in a hotel room, an attacker could compromise the firmware of the device in a way that would be virtually undetectable by traditional security software.

In all of these cases, an exploit can lead to the installation of a known or unknown firmware implant. This multitude of potential attack vectors and the high impact of a firmware compromises make it critical for organizations to be able to detect threats in this fundamental layer.


  • Review existing capabilities to detect firmware attacks and asset tampering, paying particular attention to travel and other high-risk environments. Assess the likelihood of attack and the impact if such attacks go undetected.
  • Consider incorporating firmware attacks into planned 2020 red and purple team engagements.
  • Add security tools to automatically monitor the integrity of system and component firmware and alert to any compromises.
  • Include a combination of whitelisting, threat signatures, and behavioral analysis to detect both known and unknown firmware implants.

3 | Do You Have Visibility Into and Control Over Risks in Your Technology Supply Chain?

3 | Do You Have Visibility Into & Control Over Risks in Your Technology Supply Chain?
Firmware security risks in supply chain

While most organizations are quite accustomed to dealing with traditional malware and network-based threats, the technology supply chain itself has rapidly emerged as an important threat vector. Compromises in the supply chain can be particularly challenging to catch given the scale that new devices are introduced into most organizations and that initial presumed “good” state of the device may already be compromised. Even after a device is deployed, compromises to a vendor’s update process can allow an attacker to take advantage of the trust between an enterprise and its vendors. 

To make matters even more complicated, many manufacturers’ source components include code from a variety of third-party vendors, which can all be a source of weakness or compromise that affect a multitude of targets. Organizations can easily inherit these risks from a manufacturer or the firmware security issues of their trusted partners, exposing potentially serious impact to devices and operations.

Unfortunately, 2019 once again provided examples of vulnerabilities and attacks in an organization’s supply chain:

  • ShadowHammer Attack: In early 2019 attackers were able to compromise one of the world’s largest computer manufacturers, and use the vendor’s official update tool to push malware to hundreds of thousands of customers. Specifically, attackers were able to use ASUS’s Live Update tool to deliver malware that was validly signed by ASUS. This tool included the ability to update both software and firmware. The potential for completely valid systems to be compromised underscores the importance of behavioral monitoring of firmware to detect actions that inconsistent with normal operations.

  • Vulnerable Firmware in the Supply Chain of Enterprise Servers: Eclypsium researchers initially discovered a vulnerability in the BMC of a Lenovo ThinkServer. However, further analysis revealed that the underlying issue was due to code from a third party vendor, and the same vulnerability was passed on to a variety of vendors including Gigabyte and Acer. 

The complexity of modern technology supply chains means that organizations need the ability to independently verify the safety of their supply chains both in terms of the integrity of firmware as well as evaluating technology for potential weaknesses.


  • Add scanning processes to evaluate newly acquired hardware for firmware integrity and the presence of vulnerabilities, particularly for assets that serve critical functions or roles in the organization.
  • Establish processes to scan acquired hardware infrastructure during any M&A process. 
  • Evaluate prospective technology and service providers in terms of firmware security as part of the overall supplier evaluation and due diligence process.
  • Regularly monitor firmware behavior to identify malicious or anomalous firmware behaviors.
  • Ensure your procurement and vendor engagement programs include assigning responsibility to appropriate parties for the assurance of 3rd party components involved in the delivery or products and services. When delegating responsibility to groups outside your organization, ask for details describing how they manage this risk that you inherit.
  • Establish appropriate runbook sections for how your organization will deal with potential issues that extend to your vendors/partners via supply network chain related firmware issues.

4 | Are your SOC and IR Teams Equipped to Deal With Firmware Threats?

4 | Are your SOC and IR Teams Equipped to Deal With Firmware Threats?
Firmware threats to laptops and enterprise devices

As discussed previously, persistence and defense evasion are some of the prime reasons that attackers target firmware in the first place. By infecting the firmware of a device, an attacker can significantly increase the likelihood  their code survives a complete re-imaging of the victim system. This toehold can be used to regain control over the system and the new OS and ultimately resume the attack. 

This capability has a major impact on the efficacy of both threat hunting as well as how IR teams approach the recovery of compromised devices. Without the ability to verify the integrity of a device’s firmware, many traditional device recovery processes could lead to a never-ending cycle of reinfection. 

This means that organizations should consider firmware across a wide range of IR-related activities including:

  • Alerting – Organizations need to understand how the existing alerting infrastructure applies to firmware. Does the SIEM handle firmware-based alerts? Do security solutions generate alerts based on firmware integrity and behavior, malicious add-on devices, and BMC connections?

  • Forensics and Hunting – Do forensics procedures extend to firmware analysis? Do threat hunters have tools to look for anomalous firmware behavior in the environment? Do hunters have tools to facilitate the analysis of suspicious firmware?

  • IR Playbooks and Knowledge Base – Are IR teams trained to know when to include firmware as part of their triage and response process? Does the IR knowledge base cover firmware as possible initial infection vectors? Do teams have runbooks before travel devices are reconnected to the network?

Examples from 2019 highlight the critical importance of including firmware as a part of standard IR efforts:

  • LoJax Malware: While first discovered in 2018, ongoing analysis from NetScout found that LoJax domains were still going strong in 2019. LoJax was one of the first widespread malware campaigns to use firmware for long-term persistence even after re-imaging.
  • QSnatch Ransomware: As we saw earlier in the example of QSnatch ransomware, the malware specifically targeted the firmware of the victim device and even added measures to ensure that the firmware couldn’t be updated. 

As other forms of malware continue to adopt this strategy, it makes it evermore important for IR and hunt teams to be able to analyze the firmware of a device.


  • Include firmware scanning as a standard component of incident response of devices that are potentially compromised.
  • Use firmware scanning to verify the integrity of all firmware before returning a device to service.
  • Arm threat hunters with tools that monitor for unusual firmware behavior to further analyze suspicious devices.
  • Identify any gaps in how firmware-related alerts are handled both in existing security tools as well as the SIEM.
  • Add firmware processes to standard IR triage and response runbooks.
  • Evaluate and update the IR Knowledge Base to include firmware-related information.

5 | Are You Prepared for Firmware-Related Business Risks?

5 | Are You Prepared for Firmware-Related Business Risks?
Firmware security risks to business

The rise of firmware security is not limited solely to enterprise security teams. Industry analysts, regulatory bodies, and even the general public have all dedicated increased focus to the firmware layer. This can bring new scrutiny and potential business risks that organizations need to be prepared for. 

In recent reports, Gartner and Forrester have both provided stark warnings on the state of firmware security and the risk to enterprises that don’t address it. This is a strong indicator that the reach of these threats has grown well beyond the realms of nation-state attacks and hot topics at hacker conferences. And with this added attention, organizations should expect additional questions from management, partners, and customers in terms of how the firmware layer is being secured. 

Regulatory compliance is one area where firmware is gaining additional attention. Multiple NIST documents, including the Cybersecurity Framework, heavily focus on the importance of firmware in both the management of risk as well as the implementation of security controls. In response to industry demand, the PCI Security Standards Council published a mapping between PCI DSS v. 3.2.1 and the NIST Cybersecurity Framework v. 1.1. FISMA controls also clearly and repeatedly emphasize the need to secure firmware.

These efforts show that organizations are increasingly looking for ways to standardize their efforts to secure every layer of the technology stack. Given the rise in attention that firmware and hardware related security issues have received, it is no surprise that a spotlight is falling on this aspect of every enterprise network. While the specific implementation of these requirements will naturally vary for each organization, it is important for organizations to clearly understand that firmware and hardware are now a critical part of compliance, both for the organization itself and for any 3rd party suppliers.


  • Define and document the role of firmware and firmware security in the organization’s security policies, practices, and procedures.
  • Review regulatory requirements in terms of hardware and firmware to fully understand the organization’s obligations.
  • Consider implementing risk management and security controls aimed at the firmware layer of the enterprise. 
  • Add appropriate language to contracts of vendors who may be considered 3rd party suppliers to your customers and partners.


Firmware is rapidly becoming a fundamental and essential part of a modern enterprise security practice. Recommendations from industry analysts, changes in industry regulations, and ongoing developments in the vulnerability and threat landscape all indicate the growing importance of firmware security. 

We hope that the information in this report provides a practical resource for both understanding the real-world issues that are driving these changes, as well as a way to evaluate your own approach to firmware security. For convenience, these recommendations are available as a separate checklist.

Of course, the included recommendations should not be seen as an exhaustive list of steps related to firmware security. Requirements will naturally vary from organization to organization based on their unique traits and their tolerance for risk. If you would like to learn more about any of the topics in this report, please contact the Eclypsium team at

Anatomy of a Firmware Attack

Download the PDF >

Listen to firmware security experts Ron Talwalkar and Alex Ivkin discussing the anatomy of a firmware attack in this recorded webinar.

Attacks against the hardware and firmware of a device stand as some of the highest impact threats facing modern organizations. Firmware retains the highest privileges, allows attackers to bypass traditional controls, and grants a higher level of persistence. The firmware layer has also quickly become one of the most active areas of cybersecurity with attackers increasingly setting their sights on the area of the enterprise where vulnerabilities are plentiful and defenses are often weakest.

Firmware and hardware attacks are also significantly different from traditional malware and network threats. Security teams must be prepared to defend against a new set of attacker strategies, vectors, and understand how the wide variety of firmware components can be used as part of a persistent attack. This provides an introduction to these key topics and follows the progression of a firmware attack including:

  • Attacker motivations
  • Key firmware components and their role in attacks
  • Attack vectors against firmware
  • The role firmware plays in persistent attack
  • Real-world examples of firmware threats in the wild

With this insight into the anatomy of firmware attacks and how they work, organizations can make informed decisions to better defend their data and assets. 

Understanding the Rise of Firmware and Hardware Attacks

Firmware has always been a staple component of computing but has only recently become an active area of attack. This rise of interest in firmware stems from a variety of factors. First, a series of high profile leaks from 2013 to 2016 (Vault7, HackingTeam, Shadow Brokers) revealed a consistent trend. Firmware implants and backdoors were some of the go-to tools for the world’s most sophisticated attackers who wanted to evade detection and persist on a host. This is due both to improvements in the security found at the software and OS layers, making the unguarded firmware the path of least resistance.

However, in the same way that nation-state exploits such as EternalBlue were quickly incorporated in widespread malware campaigns (e.g. WannaCry, Trickbot), firmware threats have likewise steadily became more mainstream. For example, the first widespread malware campaign to incorporate a UEFI rootkit arrived in 2018, and was quickly followed by additional large-scale ransomware campaigns and other destructive attacks against firmware.

Likewise, firmware vulnerabilities quickly became one of the most active areas of security research, leading to a flood of newly discovered vulnerabilities in all types of devices ranging from laptops to servers and networking equipment. Not only had firmware become the path of least resistance, it was omnipresent in every enterprise device.

This combination of active threats and plentiful vulnerabilities made firmware a top priority for cybersecurity leaders. NIST repeatedly called out the importance of securing firmware and has made it a staple component of FISMA compliance. PCI-DSS and other regulations have likewise taken NISTs lead by mapping to the requirements set out by FISMA. Industry analysts including Gartner have similarly elevated the importance of firmware security, both citing it as a top security priority and most recently by predicting that “By 2022, 70% of organizations that do not have a firmware upgrade plan in place will be breached due to a firmware vulnerability”.

Attacker Motivations

While actions in the real world make it clear that firmware is a priority, it is important to understand why. By compromising firmware, attackers gain a variety of advantages beyond what can be accomplished via traditional attacks, which we have summarized below.

  • The Highest Levels of Privilege – Attackers naturally seek out the highest privileges possible for furthering their attacks. At a user level this traditionally meant raising privilege within userspace (Ring 3) such as escalating from user to Administrator privileges, or seeking out kernel privileges (Ring 0) at the system level. And while these are the highest privileges available to the OS, firmware sits beneath the kernel. As a result, malicious code in the firmware has the potential to subvert the kernel and thus conceptually possess even higher privileges than Ring 0. These privileges are sometimes referred to as Rings -1 through -3. Control over these layers provide attackers with the highest level of privilege on the device and the ability to subvert all higher layers.
  • Bypass of Traditional Security -The ability to subvert higher layers most importantly allows attackers to avoid controls and security measures that run at higher layers or only see down to Ring 0. This includes traditional security running at the operating system and virtual machine layers. For example, compromised firmware can easily allow an attacker to control how a system boots, to patch the operating system itself, to read privileged data off of hardware, or control assets that the operating system can’t see into. In the case of servers, compromises to the firmware can also allow attackers to further compromise the hypervisor and virtual machine layer in an organization’s cloud assets.
  • Persistence – The ability to hide from and evade the operating system provides attackers extreme levels of persistence on a compromised device. In addition to evading controls, any malicious code in the firmware is naturally tied to the hardware of the device as opposed to the software. This means the attacker’s code would naturally persist even across a full re-imaging of system. Such capability is particularly strategic for an attacker as it is often essential to furthering the broader campaign by maintaining command and control points and facilitating the ongoing attack.
  • Stealth – Compromised firmware also enables attackers to perform a variety of critical attack functions without being detected. For example, by controlling the firmware of hard disk or SSD, an attacker could hide malware in a section of the disk that is not reported to the OS, allowing it to avoid scanning by antivirus tools. Likewise, attacks against the management components of a device such as Intel’s Management Engine have allowed attackers to send command-and-control traffic through independent channels that aren’t monitored by host-based firewalls running at the OS level.
  • Damage – Lastly, access to the firmware layer enables attackers to cause irrevocable damage to a device. By damaging the firmware itself, attackers can “brick” the device permanently. This can potentially cause organizations to rethink their recovery models since it shifts the response from data recovery and reinstallation to complete device replacement. Additionally the act of effectively disabling a device can have enormous impacts to an organization by disrupting business, services, and even critical infrastructure.
The Building Blocks of a Firmware Attack

Firmware attacks involve a variety of components and techniques that are often not seen in more traditional software-based attacks. In this section, we will introduce some of the most important firmware components within a device, how they can be abused as part of an attack, and the strategies and techniques attackers use against them. This section is neither exhaustive or definitive, but rather is to provide an introduction to the key concepts of firmware attacks. 

Key Firmware Components

When it comes to firmware, the first thing that comes to mind is often the system firmware such as BIOS or its more modern replacement, UEFI. This system firmware is particularly powerful, but it is only one of dozens of components within modern devices that rely on firmware and can play key roles in an attack. The table below introduces several of these key components and their role in an attack. However, for a more thorough analysis of firmware components and their exposure if compromised, we encourage you to refer to the online Know Your Own Device resource on the Eclypsium website.

Firmware ComponentRole in an Attack
System Firmware and Other Boot Firmware (BIOS, UEFI, EFI, MBR)This critical firmware is the first code to run on startup and can subvert the operating system by changing bootcode, patching the OS kernel, as well as compromising hypervisors and virtual machines. System firmware can also be used to deliver malicious firmware to other components in the system.
System Management Mode (SMM)SMM and similar firmware focus on the runtime operation of the device and allow the system to manage low-level behavior on the system completely independently of the OS. This can allow an attacker virtually unfettered access to the system without the knowledge of the OS.
ProcessorsBy exploiting vulnerabilities in the CPU, attackers are able to view information that should remain protected such as keys that typically remain in privileged memory. Processor vulnerabilities also have the potential to be exploited remotely, which further raises their risk. Vulnerabilities in CPUs are particularly concerning because they can affect any system or operating system even if there are no vulnerabilities in the software and all OS-level protections are enabled. Additionally, patching processor vulnerabilities can be challenging, requiring the installation of firmware updates, processor microcode updates, OS updates, VMM updates and software updates.
Intel MEIntel’s Management Engine (ME) is a common component built into personal computers to enable out-of-band management of the device. ME is also known as TXE in Atom platforms and CSME in Skylake and newer platforms. The firmware within ME includes technology known as Active Management Technology (AMT) and its functions and networking are completely independent of the host operating system and can be used by attackers for command-and-control, data exfiltration, and a variety of other functions.
Baseboard Management Controllers (BMC)BMCs provide out-of-band management for servers and likewise have their own independent networking, firmware, and resources. Attacks against BMCs can allow attackers complete control over the server and all the higher layer data and services it contains, and can even be used to permanently brick the server entirely.
USB DevicesUSB devices can contain malware in their firmware, allowing them to spoof other USB devices, exploit OS kernel and drivers and can even deliver malware or malicious firmware to other vulnerable or unprotected components.
Network Cards and PCIe DevicesThe PCIe bus provides connection to a wide variety of critical components such as GPUs, network interfaces and much more. The firmware of PCIe cards and PCIe-connected devices can be infected both over software as well as the network. When compromised that can perform devastating DMA attacks which read and write system memory and execute malicious code in the context of the victim operating system.
Dozens of additional components and modulesVirtually every device or component within a system relies on firmware, and their use in an attack will vary based on the function of the component. DRAM, GPUs, network interfaces, and drives are just a few examples. Refer to the Know Your Own Device page to learn more.

Attack Vectors

Now that we have identified some of the critical pieces of the firmware attack surface we can take a look at the methods attackers can use to target the firmware. Attackers typically need to establish a path to the firmware, and this can be done in a few general ways. Either the attacker can move from the traditional network or software layer down to firmware, or move from the hardware up.

Software Down 

The “software down” approach to firmware often follows a similar path as traditional malware infections. The initial compromise may come via phishing, drive-by-downloads, or social engineering. At this point, the attacker could directly attack vulnerabilities in vulnerable firmware to deliver an implant or could use additional tools such as vulnerable drivers to escalate privileges and control firmware as needed. Both options are very straightforward for attacker. The first is a straightforward exploitation of a vulnerability, and the latter represents the standard trojan/dropper model used by malware for years.

Unfortunately, lack of updates and patching makes firmware vulnerabilities extremely common. In fact, Eclypsium has found that well over 95% of devices contain at least one vulnerability in real-world environments. A vulnerability could be as simple as a component not requiring firmware updates to be signed, thus allowing an attacker to replace the firmware with a malicious image.

However, attackers can also use a variety of tools to move from user space to firmware. Tools such as RWEverything (read-write everything) can allow an attacker to directly write to the firmware on a component. Ironically, our research shows that some of the most powerful tools are often the drivers designed to manage the hardware and components themselves. These drivers can be abused to install the attackers code into UEFI and other components. These techniques were recently used in the Slingshot APT campaign as well as by LoJax malware.

Hardware Up

Attackers can also take a more hardware-focused approach to the firmware, and this strategy can take many forms. Compromising a device in the supply chain provides one of the most direct paths to a device’s hardware and its firmware. Malicious or intentionally vulnerable firmware can be introduced into a product if a vendor or one of its suppliers is compromised. This is actually quite a large attack surface given the many components and extensive underlying supply chain that goes into a modern device. Likewise, as shown in the recent ShadowHammer attacks, the supply chain can be attacked even after a device is delivered by compromising the official updates delivered by a vendor. In either case, an attacker is able to compromise a system that an organization typically assumes to be safe.

Next, firmware can be compromised by an attacker with physical access to a system. Malicious firmware within a USB device can be used to compromise the firmware of a victim system within minutes via “evil maid” attacks. Thunderbolt ports are likewise potential methods of entry as evidenced by the sonic screwdriver implant. And in some cases, this style of attack can even be launched remotely when USB ports are made available via virtual media services.

Lastly, system and component firmware can be attacked directly over the network. UEFI, BMCs, and other firmware components often have their own independent networking capabilities designed for providing out-of-band updates. This can potentially expose vulnerable components directly to the Internet. Similarly, weaknesses in the update process can allow an attacker to directly compromise the components firmware remotely.

Malicious Techniques

Once the firmware is compromised, the attacker will naturally want to use the position to continue the attack. This can include establishing persistence, compromising additional firmware components, capturing privileged information, exfiltrating data, impacting performance, and even disabling the device completely.

  • Altering Boot Process – By compromising the system firmware or firmware within the Trusted Platform Module, attackers can establish persistence by disrupting the secure boot process of a system. This can include directing the system to an attacker-supplied boot image, directly patching the OS kernel, or avoiding firmware integrity checks during startup. Attackers can also use Option ROM attacks to alter other firmware at boot time.. In fact, almost any firmware component can alter the boot process. For example, compromised NIC or BMC can do a DMA attack in the middle of the boot process and compromised SSD can alter the data used during the boot process, bypass boot time full-disk encryption etc.

  • Option ROM Attacks – Option ROM attacks can be used as part of an initial infection or to spread malicious firmware from one component to another. Option ROM is normally used by components to obtain the appropriate firmware during the boot process. Compromising the Option ROM firmware to offer an initial method of infection to provide a persistent modification of the boot process without directly modifying the system UEFI firmware.

  • Direct Memory Access (DMA) – DMA attacks are yet another common technique used in firmware-based attacks. DMA is normally used to give components direct access to system memory without going through the operating system. This approach gives components and peripherals improved performance. However, this access can allow a compromised component to read memory and privileged information, cryptographic keys, and other data in memory. Attackers could likewise use this access to install malicious code on the system. DMA attacks are particularly common PCI-connected devices and the device’s DRAM.

  • Processor Level Exploits – Attacks such as Rowhammer can allow an attacker to flip bits in areas of RAM in order to escalate privileges. Likewise the now infamous Spectre and Meltdown vulnerabilities allow side-channel access to potentially protected information on the processor.

  • Disabling Devices – Lastly, firmware can be used to temporarily or permanently disable a device. Firmware provides a natural way to disable a device since it is the first code that runs and plays a critical role in the rest of the boot process. These techniques can be used against virtually any device including servers

Case Study: LoJax Attack

Next we can take a look at a recent malware campaign to see how firmware is being used in a real-world context. There are multiple potential paths of a LoJax malware attack. 

For example, the initial access could stem from any number of traditional malware infection vectors including email attachments, drive-by-downloads, XSS attacks, inserting USB drives or physical access from an attacker, just to name a few. While the LoJax campaign was primarily driven through email phishing, a similar attack could easily begin via a compromised USB or Evil Maid attack.

When a user opened a malicious attachment, the malware used a vulnerable driver like those described in our “Screwed Drivers” research to gain arbitrary access to physical busses within the platform. It then leveraged this direct hardware access to talk to the SPI controller in the chipset which controls access to the SPI chip containing the UEFI system firmware. The next step was to use this access to write a malicious DXE application to the UEFI system firmware which will run at each subsequent boot. When this added DXE application runs during the boot process, it drops applications embedded within itself into the drive containing the operating system and modifies the registry before Windows starts to ensure that its services run on every boot even if the system was wiped and re-imaged.

Next, with control over the operating system, the malware is able to drive the ongoing process of attack. This includes the ability to read files and collect data on the system, launch exploits against other systems and services, and use RPC to create a command-and-control channel.

Firmware attacks constitute some of the most high impact threats facing organizations today. With control over the firmware layer attackers are able to persist on the device, evade traditional security, and ensure access to the highest levels of privilege on the device. These fundamental capabilities can apply to almost any phase of attack from command-and-control to lateral movement to the theft and destruction of data and assets.

Attackers also have many paths they can take to reach the firmware layer. By leveraging weaknesses in firmware or vulnerable drivers, attackers can extend traditional software and malware based attacks to the firmware layer. Additionally, attackers can target the hardware directly via the hardware supply chain, exposed ports, or even over the network via remote media or firmware update processes.

These are just some of the ways that firmware can be attacked today. As part of our ongoing research we will continue to keep this resource updated with the latest techniques, strategies, and example attacks based on changes in the wild. If you have any questions about the information presented here or would like to learn more about the Eclypsium solution, please contact us at

FISMA Compliance—Firmware Security Best Practices

Download the PDF >

Read the Quick Reference >

FISMA, and the NIST documents supporting it, repeatedly underscore the importance of firmware security as part of a modern security program. Yet, this area remains one of the most overlooked and poorly understood areas of risk within government agencies. This document walks through the requirements and guidance that the law establishes in regard to firmware, and provides practical guidance and recommendations that organizations can use to not only comply with FISMA, but also to build a stronger security program.



The Federal Information Security Management Act (FISMA) defines the information security requirements for all federal agencies. It extends across the lifecycle of a security program from planning, implementation, and ongoing administration of a security program. And in addition to covering all federal agencies, it also applies to any contractors, any entities that handle federal information, and even state agencies that administer federal funds.

FISMA is also quite different from many other regulatory security standards. Notably, the FISMA security controls clearly and repeatedly establish firmware security as being in scope. This is not surprising given that firmware implants and other firmware threats have long been a favorite tool for nation-state attackers who would naturally target federal information systems. This has become an even higher priority as firmware-based threats have recently spread to large-scale network-based and malware-based campaigns. Likewise supply-chain security has become a top priority for NIST, DoD, and many others both inside and outside of the government sector.

However, firmware security has often been challenging for many organizations. Historically it has been time-consuming, required specialized and rare security skills, and teams often lacked the tools to automate the work. Fortunately, new tools and innovations are changing the situation for the better. In this paper, we will take a closer look at some of the FISMA requirements, how they relate to firmware security, and specific steps you can take to bolster your security programs.

FISMA Overview

FISMA establishes far-reaching requirements that are guided heavily by two important NIST documents. SP 800-37 lays out a Risk Management Framework (RMF) and SP 800-53 addresses Security and Privacy Controls. At a high level, the Risk Management Framework establishes a lifecycle approach that guides the creation and ongoing administration of a security program. SP 800-53 then provides additional details on the types of controls that may be implemented and considerations for each.

Both documents identify firmware as a critical part of the security program and consistently use the phrase “hardware, software, and firmware” when describing the components of technology and devices to be protected.

However, that does not mean that all organizations subject to FISMA are necessarily mandated to adopt firmware security controls. FISMA gives organizations considerable flexibility over the details of a program. The guiding direction is that security controls should be “customized for the specific missions, business functions, risks, and operating environments of the organization.” In short, some organizations, environments, or specific devices may need firmware security controls while others may not. With that in mind, the remaining sections of this paper will look at firmware security in the context of various FISMA requirements and direction, and then provide specific examples of firmware controls that may be appropriate.

Prepare: Understanding the Firmware Attack Surface

The Prepare phase is the first step of the RMF and it covers a lot of important ground. This is where organizations define their high-level risk strategy based on their unique mission, tolerance for risk, types of threats such as cyber-attacks, and other factors. Given the historic use of firmware implants and backdoors by state-supported adversaries, many organizations will likely want to consider their firmware attack surface.

In particular, the Prepare phase covers important requirements such as the need for system-level vulnerability assessments. However, many organizations have historically ignored the firmware layer during vulnerability assessments simply due to pragmatic challenges. Teams have always been able to rely on highly automated vulnerability scanners for analyzing ports, services, and applications, but firmware security assessments were often far more manual, time-consuming, and required specialized skills. This lack of basic visibility into firmware-related risks has led many organizations to develop a persistent blind-spot in regard to firmware security in spite of the heavy attention it receives from sophisticated adversaries.

However, licensed tools as well as open-source frameworks such as CHIPSEC have evolved to make this a much more automatable process. Organizations can now scan their devices to identify the presence of outdated firmware, vulnerable firmware, and a wide variety of missing device protections that could put the device at risk. With visibility into the firmware attack surface, organizations can make much more informed decisions about how and when to prioritize firmware security for the organization.

Eclypsium Guidance and Considerations: Perform an initial firmware vulnerability assessment of critical devices or assets. Consider using licensed or open-source tools to automate the analysis of devices. Firmware analysis should include system-level firmware such as BIOS or UEFI, but should also extend to firmware of hardware components within the system such as drives, processors, and network adapters. Scans should be able to identify the following:

Systems with out of date firmware

Systems with firmware vulnerabilities

Systems with missing hardware protections

Categorize: Understanding Devices in Terms of Susceptibility and Impact of Firmware Threats

The Categorize phase requires organizations to classify their systems and assets based on the impact of a loss of confidentiality, integrity, or availability of that system. This applies to the system itself as well as any information the system processes, stores, or transmits.

In this context it is important to understand the power of firmware-based threats and why they have become so strategically important to sophisticated attackers. First, firmware represents the most fundamental code of a device. System firmware such as BIOS or UEFI run prior to the operating system and threats at this level can subvert the operating system and any higher level security controls that depend on the operating system.

Likewise, firmware is present in virtually every hardware component of the system from drives, to network adapters, to interfaces such as baseboard management controllers that manage the system. As a result, firmware threats could have insight into data stored on the system or transmitted over its network connections. Additionally, devices could easily be disabled altogether at the firmware level.

As a result, firmware threats would have high impacts to the confidentiality, integrity, and availability of the system. Likewise, these threats provide attackers with long-term persistence on a victim device by being able to subvert traditional security controls and surviving across common incident response processes such as reinstalling the host operating system to a known “gold” version.

Eclypsium Guidance and Considerations: Organizations may want to consider the impact of firmware-based threats to the following high-value devices during the categorization phase:

High-Value Laptops: While all devices are potentially subject to attacks on their firmware, laptops are often exposed more often than other assets. An attacker with physical access to a device can often compromise the firmware in as little 5 minutes. Thus organizations may want to consider firmware security controls for devices that carry high-value information and/or travel to untrusted environments.

Critical Servers: Firmware provides an ideal path to
both steal data or deny access to it altogether. This is particularly true of high-value servers. In particular, the baseboard management controllers (BMCs) that enable remote and out-of-band management of servers have incredible power over the data and operation of servers, an area where firmware vulnerabilities have been particularly common.

Networking and Security Gear: Recent large-scale Russian attacks have shown that networking gear presents a particularly powerful prize for attackers. By subverting the network infrastructure, attackers could easily read, manipulate, or even redirect content on the network. Likewise the very network controls charged with securing the network could likewise be targets of attack. As called out in the AC-4 control of SP 800-53, organizations may want to “consider the trustworthiness of filtering/inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement.

Controls and Continuous Monitoring

Once systems have been properly categorized, organizations will select and implement controls that are appropriate for the system and the organization’s tolerance for risk. It is important to note that these controls are not applied as a single, one-time event. While an annual FISMA assessment represents a point-in-time check view of the security program, the standard requires organizations to implement ongoing monitoring programs to identify changes in risks and threats and to confirm that controls are having their intended effect. As with other FISMA requirements, the frequency of monitoring will vary based on the risk profile of the organization as stated below in SP 800-53:

Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security and privacy to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess security and privacy controls and associated risks at a frequency sufficient to support risk-based decisions.

As discussed previously, manual analysis of firmware security is often prohibitively time-consuming for staff to perform on a regular cadence. As such, organizations will likely want to consider tools to automate firmware security for those systems that have been prioritized.

There are several specific families of security and privacy controls defined by SP 800-53 where firmware security may naturally apply. Five such areas are highlighted below, but organizations may naturally want to consider firmware-based controls in other areas as well.

Applicable NIST SP 800-53 Controls:

Control Reference Eclypsium Detections
SI—System and Information Integrity

SI-2 Flaw Remediation

SI-4 Information System Monitoring

SI-7 Software, Firmware, and Information Integrity

In-the-wild implants (eg. HackingTeam, Lojax)
  1. Confirm firmware integrity
  2. Identify insecure firmware and apply updates
  3. Ensure that all firmware updates are cryptographically signed and that devices require any firmware updates to be signed
  4. Monitor devices for signs of malicious firmware behavior
  5. Analyze systems to ensure the integrity of the boot process and boot firmware
  6. Detect firmware threats such as implants, backdoors, and rootkits
SA—System and Services Acquisition

SA-12 Supply Chain Protection

SA-19 Component Authenticity

Supply chain interdictions
  1. Evaluate prospective technology for firmware security and avoid products that can be easily modified at the firmware level
  2. Check all newly acquired devices to confirm the integrity of the firmware
  3. Monitor devices for signs of malicious firmware behavior
CM—Configuration Management

CM-2 Baseline Configuration

CM-5 Access Restrictions for Change

CM-7 Least Functionality

Secure ConfigurationPLATINUM malware campaign
  1. Record expected configuration and behavior of device firmware and hardware
  2. Activate firmware and hardware security features
  3. Analyze critical devices to ensure unnecessary features are disabled, particularly remote management interfaces that are not used
AC—Access Control

AC-6 Least Privilege

Firmware Storage Vulnerabilities
  1. Ensure any unnecessary debug functionality is not enabled
  2. Ensure firmware storage is properly protected
RA—Risk Assessment

RA-5 Vulnerability Scanning

Firmware and hardware vulnerabilities (eg. Speculative execution side-channels, vulnerable firmware storage, insecure SMM code)
  1. Prioritize the analysis and monitoring of firmware and hardware vulnerabilities
  2. Regular scans should be able to identify
    1. Systems with out of date firmware
    2. Systems with firmware vulnerabilities
    3. Systems with missing protections
IR—Incident Response

IR-4 Incident Handling

IR-10 Security Analysis Team

Attackers using firmware implants to persist across system re-imaging.
  1. Perform firmware scans of devices related to incident to track scope
  2. Verify integrity of firmware of all affected hosts during system recovery
  3. Arm staff with tools to assist in forensic analysis of firmware-based threats

MA-3 Maintenance Tools

BMC, IPMI, and Intel AMT as potential attack vectors
  1. Monitor management interfaces for vulnerabilities or signs of compromise
  2. Scan management resources for vulnerabilities
  3. Only enable remote management tools for devices that have an operational need

SI—System and Information Integrity

The System and Information Integrity family of controls is heavily focused on the detection of and response to threats. This includes the important topics of Flaw Remediation, Malicious Code Protection, System Monitoring, and specifically Software, Firmware, and Information Integrity. A firmware security platform should be able to address all of these key areas.

Control SI-7 specifically address the topic of Software, Firmware and Information Integrity. Items SI-7(9) and SI-7(10) specifically address the need to ensure the integrity of the system boot process and well as the integrity of the boot firmware. The section specifically notes:

Unauthorized modifications to boot firmware may be indicative of a sophisticated, targeted attack. These types of targeted attacks can result in a permanent denial of service or a persistent malicious code presence. These situations can occur, for example, if the firmware is corrupted or if the malicious code is embedded within the firmware. System components can protect the integrity of boot firmware in organizational systems by verifying the integrity and authenticity of all updates to the firmware prior to applying changes to the system component; and preventing unauthorized processes from modifying the boot firmware.

Additionally, SP 800-53 calls out that organizations may want to consider both signature based and non-signature based approaches to the detection of malicious code. Eclypsium applies both types of analysis to the detection of firmware-based backdoors, implants, and rootkits. In addition to checking for known implants and threat, Eclypsium monitors the behavior of the firmware and components to identify firmware threats that are unknown or do not have a known signature.

SA—System Acquisition

FISMA and the supporting NIST documents strongly highlight the importance of the supply chain to a security program. Section 2.8 of the Risk Management Framework is dedicated to Supply Chain Risk Management (SCRM) and calls out the risk as follows:

The growing dependence on products, systems, and services from external providers, along with the nature of the relationships with those providers, present an increasing amount of risk to an organization. Risk may increase based on the likelihood of occurrence and adverse impact from threat events such as the insertion of counterfeits, unauthorized production, tampering, theft, insertion of malicious software and hardware, as well as poor manufacturing and development practices in the supply chain, including the failure to build in security or privacy capabilities that enable an organization to better manage risk in its environment.

Likewise 880-53 section SA focuses on system acquisition with SA-12 dedicated to supply chain risk management, and SA-19 on component authenticity. These two sections bring focus to the need to have intelligence about the supply chain, including how easily it would be for attackers to compromise the supply chain, as well as the ability to detect if a system has been altered in any way before delivery.

Detecting threats in the supply chain can be particularly challenging, particularly at the firmware level. If a system or one of its components has been tampered with in the supply chain, then that change could easily be included as part of a “known-good” or “golden” configuration.

A firmware security platform can be instrumental both in the initial selection of hardware and components as well as verifying the integrity of all newly acquired assets. For instance, during the evaluation of the potential products, firmware scans can be performed to ensure that the systems are not vulnerable to modification of firmware components. Selecting appropriately secure devices would reduce the opportunities for a device to be tampered with while in the supply chain.

Likewise, each newly acquired system should be scanned to ensure that the firmware has not been tampered with in the supply chain by matching the firmware to known good firmware from the manufacturer. However, as was the case recently, vendors themselves can be compromised including their official signed updates. For these cases it is important to monitor newly acquired systems for anomalous behavior at the firmware level to detect firmware threats.

Eclypsium Guidance and Considerations:
For systems that have been categorized as priorities, consider implementing the following SCRM controls for firmware:

  • Evaluate prospective technology for firmware security and avoid products that can be easily modified at the firmware level (accepting unsigned firmware updates, etc.)
  • Check all newly acquired devices to confirm the integrity of the firmware
  • Monitor newly acquired devices for signs of malicious firmware behavior
  • Organizations may want to require firmware scans from partners in their supply chain in order to identify and isolate where any unwarranted changes are introduced

CM—Configuration Management

It is important to ensure that the systems are configured properly and that any changes to the system are performed securely. Regular firmware scanning can ensure that firmware is updated, protections are properly enabled, and that the firmware has not been modified or tampered with. SP 800-53 CM-5 calls out the importance of only using updates that have been cryptographically signed as follows:

Software and firmware components prevented from installation unless signed with recognized and approved certificates include, for example, software and firmware version updates, patches, service packs, device drivers, and basic input output system (BIOS) updates.

Eclypsium research has identified widespread issues of systems that do not require firmware updates to be cryptographically signed. In addition to scanning for outdated or vulnerable firmware, the organizations may want to use tools such as Eclypsium to identify systems that do not require signed updates and are thus far more vulnerable to malicious firmware.

Eclypsium Guidance and Considerations:
Check device setting and configurations that could allow attackers to easily modify firmware.

  • Activate firmware and hardware security features.
  • Ensure that systems require firmware to be signed before applying an update.
  • Analyze critical devices to ensure unnecessary features are disabled, particularly remote management interfaces that are not used.

AC—Access Controls

Section AC-6 is dedicated to one of the most fundamental aspects of information security – the concept of least privilege. These controls are focused on making sure that users and processes are only granted an appropriate level of access in order to deliver their business function. And while we often think of access controls in terms of human users, the standard specifically notes that this should apply to processes as well.

This concept is highly relevant to firmware as organizations need to know how users are able to modify firmware, and likewise what privileges the firmware has to modify the device. For example, if debug features are available on the machine, it can make it very easy for a human attacker to modify firmware on the device via evil-maid attacks. Likewise, the firmware itself can be allowed to configure hardware in an insecure manner. Either of these issues could allow an attacker to gain control over a system. As a result, organizations need to remember that least privilege isn’t limited to user policies and Active Directory permissions. Firmware is in scope, and if not properly secured, could subvert all higher-level user policies.

Eclypsium Guidance and Considerations:
Extend the concept of least privilege to user’s ability to control firmware, as well as firmware’s ability control the device:

  • Check devices for any enabled debug features that could provide any user with visibility and control over firmware that should be limited to developers or administrators.
  • Ensure that firmware storage is protected properly to prevent attackers from accessing and modifying firmware.
  • Evaluate systems for any vulnerabilities where the firmware is allowed to insecurely configure hardware components.


While the Risk Management Framework addresses the important of vulnerability scanning, section RA-5 is dedicated the specific tools and controls needed to do the job. Specifically, RA-5 calls the importance of tracking both the depth and breadth of any vulnerability scanning. As discussed in earlier sections, many organizations lack the ability to perform automated vulnerability scans of the firmware attacks surface at all, leading to high rates of outdated and unpatched firmware.

However, firmware also resides in a wide variety of components within a device, and this breadth is highly important for vulnerability scanning. Weaknesses in a system drive, or network adapter, or BMC could lead to complete loss of either integrity, confidentiality, or availability of a system. As such, vulnerability scanning should extend to component-level firmware in addition to system level firmware.

Eclypsium Guidance and Considerations:
Perform regular vulnerability scans of system and component firmware:

  • Regularly scan all devices for outdated firmware
  • Scan for known firmware vulnerabilities
  • Extend scanning to critical device components

IR—Incident Response

The IR set of controls helps an organization operate during an attack or incident and coordinates the response and return to a secure state. This can include analyzing systems that were involved in a security incident and identifying other systems that may have been contaminated.

Malware and sophisticated attackers will often attempt to implant code in firmware in order to persist in the network, and even survive across a complete re-imaging of the host. As such, organizations should consider firmware when performing forensic analysis and hunting for other devices that may have been compromised. Likewise, integrity checks of the firmware should be a standard part of the recovery process for any device involved in an attack.

Eclypsium Guidance and Considerations:
For systems that have been categorized as priorities, organizations may want to implement firmware controls in the following areas:

  • Identify insecure firmware and apply updates
  • Ensure that all firmware updates are cryptographically signed and that devices require any firmware updates to be signed
  • Analyze systems to ensure the integrity of the boot process and boot firmware
  • Detect both known and unknown firmware threats such as implants, backdoors, and rootkits
  • Integrate firmware checks into incident response procedures


Section MA-3 calls out the importance of the security of the tools that administrators often use when servicing a system. The document provides the following guidance:

Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, intentionally or unintentionally, into a facility and subsequently into systems.

This is once again a very important area as it applies to firmware security. Modern servers are designed to be remotely administered via IPMI and the system’s baseboard management controllers (BMCs). Firmware in BMCs has been a very common source for vulnerabilities, which could allow an attacker to compromise or even completely disable a system. Some vulnerabilities even enable the system to be compromised remotely. These BMCs are designed to provide out-of-band management for the servers, so compromises at this level would give an attacker complete control over the server and its data.

Laptops and other systems will likewise have similar tools designed for remote management. Attackers have recently been observed using Intel’s Active Management Technology (AMT) to communicate with a compromised system without being detected by security controls running at the operating system level.

Eclypsium Guidance and Considerations:
Ensure the security of remote management tools and firmware components:

  • Prioritize the analysis and monitoring of server BMCs for vulnerabilities and signs of attack
  • Analyze critical devices to ensure remote management tools are not enabled if not necessary.


This document highlights some of the many areas where firmware security can play an important role in FISMA compliance and the overarching goal of protecting an agency’s mission. Of course the prioritization of firmware security will vary from organization to organization. However, in the past, firmware security was often overlooked not by choice, but due to a lack of tools to automate the work. We believe that through our work at Eclypsium as well as others in the industry, this is changing. The recommendations in the document should in no way be considered exhaustive, but rather to highlight some of the common areas where firmware security can provide immediate value. If you have any questions or concerns related to topics in this document, please contact the Eclypsium team at

The Top 5 Firmware and Hardware Attack Vectors

Download the PDF >


As firmware-level threats continue to gain traction in the wild, security teams need to quickly get up to speed on how these threats work and how their devices can be targeted and attacked. In this paper we demystify the most common types of firmware threats today and analyze their path into an organization.


For many years, firmware-level vulnerabilities and threats have largely been out of sight, out of mind for many security teams. However recent changes to the threat landscape are bringing those days to a close. The Meltdown and Spectre vulnerabilities introduced the world to the power of hardware-level weaknesses, LoJax malware brought UEFI rootkits into the wild, and US-CERT alerted the industry to widespread Russian-backed attacks targeting network infrastructure. The ability for attackers to compromise device firmware remotely, while users are traveling with their laptops, and even in the hardware supply chain itself, makes firmware security uniquely challenging.

And while these types of attacks may be new to many security teams, they are very real and are quickly becoming a top priority for regulatory bodies, industry analysts, and virtually any organization that faces advanced attackers. This paper provides an introduction to the most common firmware and hardware attack vectors, and what you need to know in order to start defending yourself.

Attacks against firmware are especially appealing to attackers. Once they have compromised the firmware, they can safely persist on the device and evade your OS, application or software levels of security. Since the malicious code lives within the firmware of physical components, the threat can easily survive a complete reimaging of the system or even replacement of the hard drive(s).

This sort of persistent attack would typically occur as a second stage of malware infection. Once a system is initially compromised, malware could then look for vulnerabilities in the firmware and missing device protections that could allow malicious code to be implanted in the firmware itself. Two of the most well-known examples from the real-world are the recently discovered LoJax malware and the infamous Hacking Team UEFI Rootkit.

In both of these examples, the malware targeted the system’s UEFI firmware. These attacks took advantage of specific vulnerabilities and many other vulnerabilities have been discovered over the past few years in UEFI and related components. However, in some cases attackers don’t need to exploit a vulnerability at all in order to install their malicious implants. Older systems and even some recent servers lack basic protections like signed firmware updates. These attacks can apply to virtually any device that can be compromised with malware. As a result, it is imperative that organizations have the tools to find firmware vulnerabilities, missing protections, and both known and unknown implants in order to secure enterprise devices.

While malware represents a common attack vector, research has shown that firmware can also be exploited remotely. This attack vector has a lot to do with the growing set of networking options found within UEFI components themselves. In short, the standard UEFI codebase now includes a rich set of network capabilities for Ethernet, WiFi, and even Bluetooth that allow the firmware to communicate remotely and even perform a full HTTP boot from a remote server across the internet. Additionally, vendors have individually been implementing “update over the Internet” features that allow the computer to check for and download firmware updates from a remote server before the host operating system is ever loaded.

Eclypsium researchers found that in some cases the update over the Internet functionality was downloaded unverified and in the clear. The host would try to contact a remote update server using plain HTTP without SSL or any verification. This means that simple man-in-the-middle or other redirection techniques (e.g. DNS/ARP/route poisoning) could be used to modify the response returned to the client and exploit the vulnerability. As a result, our research showed that we could remotely deliver malicious code resulting in buffer overflows and arbitrary code execution just by checking if a newer version of the firmware exists.

The important point to remember is that with network connectivity comes the opportunity for remote exploitability—just as with every other connected device and component in history. Networking has become a standard part of firmware and certainly doesn’t show signs of going away. This means that whether from malware or remote exploits, an organization’s firmware vulnerabilities are increasingly accessible to attackers.

Devices are also often open to compromise by an attacker who has physical access to the machine. These threats have been dubbed “Evil Maid” attacks referring to a scenario where a malicious hotel room maid can install a rootkit on a laptop left in the room. This sort of attack is especially relevant to organizations whose employees travel. Any time their laptop is out of the user’s control, an attacker can potentially compromise the device at the firmware level without opening the case. This particular attack vector is often tied to the presence of hardware and device debug mechanisms. Debug mechanisms are standard components that assist in tracing the source of faults in virtually all platforms. These mechanisms are primarily used before a platform reaches production, but also are often used for refurbishing and fixing returned platforms. Security researchers have repeatedly published attacks using debug features. Eclypsium research confirmed that debug access over USB enables installation of persistent rootkits in UEFI firmware and runtime SMM firmware on systems that do not securely set debug policy (CVE-2018-3652).

While this may seem like it requires specialized equipment and detailed knowledge, it is actually quite easy in most cases. Most firmware is stored on a Serial Programmable Interface (SPI) flash chip. This creates a physical standard for reads and writes to the storage chip, and SPI flash programmers are relatively easy to buy or create. Other researchers have developed a generic proof-of-concept backdoor that can be easily installed into most firmware modules. One could say that the ease and availability of these tools and techniques make firmware rootkits accessible to non-experts or “script kiddies”. Using these techniques we have demonstrated the ability to install a rootkit on an enterprise laptop with no more than 4 minutes of physical access.

While all enterprise devices have a hardware/firmware attack surface, the problem goes even deeper when it comes to remote management. High value servers and even modern laptops are designed to be supported via remote out-of-band management. In the case of servers this is often the role the baseboard management controller (BMC) and standards such as IPMI play. This includes the ability to monitor and manage everything about the server including the ability to update firmware, change the host operating system, and boot or cycle the host. And since no one wants to physically run to a server and cable everytime there is an issue, these functions are available over the network, often on its own dedicated management subnet.

While IPMI and BMCs serve a critical need for data centers, they also present a massive risk. A remotely accessible interface that can control most aspects of the host even when the host is powered off would be an obvious goldmine for attackers. Unfortunately, this critical area is often overlooked when it comes to security. BMCs often use default, widely-known passwords, and administrative access is often not logged. An attacker who gained access to the server via IPMI, could easily gain full control over the power of the data center. Attacks against BMCs have been a particularly busy area of research in the industry, with a variety of new weaknesses being disclosed.

However, the same issues exist for laptops as well. Intel’s Active Management Technology (AMT) provides for out of band management for laptops. This functionality provides remote management for laptops in much the same way that IPMI supports servers. Malware has already seized on this functionality for a variety of communication and evasion techniques.

Most of our examples thus far have consisted of attackers compromising a deployed, active system. However, devices can be modified in the supply chain before they are ever unboxed by the eventual owner. This type of attack can be incredibly difficult for most organizations to detect given that even the earliest baseline state of the device is already compromised. Recent reports have debated to what degree this style of attack has been successful. However, what is not up for debate is that security leaders, analysts, and governments have made supply chain security a top priority.

NIST recently updated its Framework for Improving Critical Infrastructure Cybersecurity to include a Supply Chain Risk Management (SCRM) category, while greatly improving the guidance related to SCRM throughout the framework. Likewise, the UK’s NCSC Cyber Threat to UK Business Report highlighted the recent increase in supply chain attacks as a major area of focus moving forward. Additionally, in Gartner’s recent Top 6 Security and Risk Management Trends for 2018, the firm highlighted the importance of “origin over pricing” when evaluating technology purchases and the need to carefully consider the upstream and downstream relationships of all technology suppliers.

Needless to say, security teams will need new tools and safeguards when devices can potentially be compromised “out-of-the-box”. This puts greater importance on being able to ensure that all firmware is valid and hasn’t been tampered with.


This paper serves as an introduction to firmware-level threats and high-level approaches that attackers can use to target your infrastructure.Whether servers, networking gear, or personal laptops, firmware is increasingly a target. Building security countermeasures to defend and mitigate these threats is essential, and Eclypsium is purpose-built for this task. However, we also encourage organizations to use the opensource CHIPSEC project to begin looking for firmware issues in your devices today. With the many avenues attackers have to your enterprise firmware, it is critical that firmware security controls become a standard part of your security operations. If you would like to learn more about Eclypsium and our products, please reach out to us at

The Enterprise Hardware Attack Surface and How to Defend It

Download the PDF >

Attackers are increasingly targeting the largely unprotected hardware and firmware within all types of devices. Firmware vulnerabilities are common and difficult to manage, and once exploited, allow attackers to subvert traditional security and gain long-lasting persistence within a network. In this paper, we will explore the nature of the risk, why it has become a priority now, and how organizations can protect themselves today.


All computing devices, from the most advanced servers and network devices to the lowliest USB drives, all function from the physical layer up. Internal logic on the motherboard, internal components, and the processors themselves provide the bedrock of computing that supports the operating system, which in turn supports applications, virtual hosts and services.

While this hierarchy is obvious and well-understood, it has not been incorporated into the security model for most organizations. In most cases, information security is addressed from the operating system up, with the hardware layer being ignored and assumed to be secure.

This assumption is proving to be a mistake, as real-world attackers are increasingly targeting the physical layer where devices remain largely undefended and unmonitored. Devices of all types within an enterprise depend on proprietary firmware code that is typically not audited, not verifiable, contains many vulnerabilities and is difficult to patch. Once compromised, attackers are free to subvert many of the carefully crafted security controls installed at the operating system and above.

While hardware-level vulnerabilities and attacks are not new, the landscape has changed and continues to evolve rapidly. What was once considered a largely academic pursuit has rapidly turned into one of the most active areas of conflict between attackers and defenders. In this paper we will look at the factors driving the change, the challenges to the traditional security model, and introduce a new layer of security going forward.

The unprotected hardware and firmware layer

Hardware Gets the Spotlight

Firmware, BIOS, and chip-based logic has been around since the earliest days of computing. As such, it is fair to wonder why this attack surface would be overlooked for years and suddenly become a priority now.

While there are variety of factors at play, two issues seem to be taking priority. First, the barriers to analyzing firmware have been drastically reduced, meaning that the firmware layer is suddenly far more accessible to anyone in the security community. This means that now the code in firmware and other infrastructure is open to scrutiny in much the same way that traditional software has been for years.

Secondly, the industry has faced a major spike in the use of hardware and firmware implants by advanced actors in the wild. In short, advanced attackers have proven the value of attacking below the operating system, and less skilled attackers now have the tools to follow in their footsteps.

Hardware Vulnerabilities Go Mainstream

Vulnerabilities in the physical/firmware layers have always been present, but until recently they were very difficult to see. In the past, analyzing firmware and chip-level code required specialized and expensive tools. It was also much more time consuming for researchers to do an adequate analysis of firmware as opposed to traditional software. This meant that research was limited to a very small fraction of the security community.

All of this has changed in the past few years. New tools have come to market that have lowered the costs of hardware analysis by an order of magnitude. Today researchers can insert a USB drive and begin analyzing a chip directly. With fewer barriers, the code in the hardware and firmware layer is suddenly fair game both for ethical researchers as well as attackers. While such exposure has been standard for traditional software, it is very new for hardware, where for years the code was assumed to be unreachable.

An Untended Garden of Vulnerabilities

Unfortunately with this new visibility, researchers have found the hardware layer to be inundated with flaws. Every device is inundated with proprietary code that is often vulnerable, hard to audit, and even harder to patch. The Spectre and Meltdown vulnerabilities illustrated that even the giants of the industry such as chip manufacturers are not immune to serious problems. However, the more unsettling prospect for security teams is that they likely represent the best case scenario of hardware vendors.

Whereas some larger manufacturers invest heavily in product security and research, many hardware providers do not. Given that very few researchers could look for hardware vulnerabilities in the past, the majority of the hardware supply chain has been driven by cost and not security. As a result, devices from servers, to PCs, to phones are packed with motherboards, disk drives, network cards and a variety of other hardware components that were chosen based on price and were never expected to be part of a security attack surface. That assumption is increasingly proving false, bringing large amounts of insecure code into the light of day.

Over the last few years the industry has seen a spike in the amount of critical vulnerabilities and implants that have been discovered including:

UEFI, Mac EFI, and SMM firmware

“Lights out” management controllers

Computer components and peripherals

Hardware vulnerabilities and exploitation techniques

Fixing problems can be a challenge even once they are found. Unlike traditional software vulnerabilities, firmware updates are far less frequent. In some cases a low-cost component provider may never get around to delivering an update, or it may go unaddressed for years. Even when firmware updates are available, many organizations lack programs to update the firmware on their devices [1, 2]. This means that not only are there many vulnerabilities in hardware, they tend to have particularly long tails as well.

This has led system manufacturers to build defenses into the hardware such as the recently revealed Google Titan chip. However, these hardware mitigations may not always be available and even when they are, these security chips have been found to contain vulnerabilities themselves. This was the case with vulnerable firmware inside Infineon Trusted Platform Module or inside AMD Platform Security Processor. The very devices intended to protect our systems at a hardware level can be compromised and host stealthy implants.

Many Targets to Choose From

Attackers have many options when they target the hardware layer. Not only do all devices have firmware, many of system’s individual components will have their own independent firmware. BIOS and the more modern UEFI or Mac EFI provide the gateway to the system firmware on a device’s motherboard. Recent Eclypsium research demonstrated how UEFI can be attacked remotely and the discovery of LoJax UEFI rootkit in the wild demonstrated how attackers are using firmware attacks to subvert the host operating system and persist across system re-imaging and even hard drive replacement.

However, the problem extends well beyond the motherboard. Hard drives, network or WiFi cards, graphics cards, system-on-chip and variety of other components have their own internal controllers and firmware that drive their behavior. Compromising these devices provides an attacker with direct and fundamental access to the most sensitive information on the system.

Within servers, baseboard management controllers (BMCs) and IPMI are used to deliver dedicated “lights out” management to servers using hardware and interfaces that are independent of the host operating system. However, out of band management is not limited only to servers. Intel Management Engine (ME) and Active Management Technology (AMT) provides the same functionality for traditional PCs as well. Backdoors have likewise been found within the firmware of network routers and firewalls, allowing attackers to not only backdoor the network, but the very security products charged with defending it. Even seemingly lowly USB peripherals contain their own internal controller code that can be compromised and used to subvert the operating system of a system it is connected to.

The sum total of all of these devices make for a complex ecosystem even on an individual host device. The problem gets vastly more complex when you begin to look at vulnerabilities at the organizational level. Enterprises often have a dizzying combination of corporate laptops, networking gear, white-box servers supporting virtual environments, and the list goes on. Simply trying to track a single known vulnerability in a chip or hardware component can be incredibly difficult in the best of circumstances.

Backdoors and Implants in the Wild

With the sudden accessibility of the hardware layer, it should be no surprise that attackers are starting to take notice. Many examples have been predictably associated with advanced actors intent on maintaining silent persistence within a target.

LoJax, one of the first UEFI rootkits seen in the wild, and the Black Energy attack against infrastructure in the Ukraine both bore the clear signs of nation-state actors. Likewise the disclosure of EFI and BIOS implants for Macs and PCs and the Equation Group implants targeting firewalls, networking gear, hard drives and other infrastructure confirmed that implants had made the jump to use in the wild.

Network devices and servers have become a key target for advanced actors. The US Department of Homeland Security recently issued an alert for a large-scale state-sponsored attack targeting enterprise network devices such as routers, switches, and firewalls. Once compromised, attackers would modify the device firmware to gain near full visibility and control over the victim network. The VPNFilter malware also targeted networking devices and contained code to disable the device by overwriting its firmware. Research from Mandiant uncovered backdoors in Cisco routers dubbed SYNful knock that allowed an attacker to take control of the device using specially crafted TCP packets.

Additionally, devices can be compromised in the hardware supply chain even before they are unboxed by the eventual owner. Recent reporting suggests that malicious actors were able to infiltrate over 30 companies using devices compromised in the supply chain. NIST recently highlighted the importance of this style of risk by adding an entire Supply Chain Risk Management (SCRM) category to its Critical Infrastructure Cybersecurity framework.

While these examples exhibit the handiwork of advanced actors, they show that these threats are real, and are critical tools for attackers who want to maintain persistence in an environment without detection. And as we have seen in the past with malware and other threats, the disclosure of new techniques from advanced actors quickly spread to other targeted attack groups and ultimately the criminal ecosystem as well. With the breadth and depth of the attack surface and the widespread lack of controls at the hardware level, there is every reason to believe that this trend will continue.

Subverting the Traditional Security Model

The ability for firmware implants and backdoors to subvert traditional security controls makes them almost invaluable to advanced attackers. By acting at the hardware level, attackers can bypass security controls running at the OS or container level, effectively hiding their malicious activity from detection. This provides attackers with long-term, nearly undetectable persistence while still retaining direct access to data on drives, in memory, or sent over the network. By nature, these attacks are often long-term, strategic, and can evolve over months and years to target or destroy an organization’s most valuable assets.

Going Below the OS

Firmware, BIOS, and chip-based logic has been around since the earliest days of computing. As such, it is fair to wonder why this attack surface would be overlooked for years and suddenly become a priority now.

While there are variety of factors at play, two issues seem to be taking priority. First, the past few years have shown a major spike in the use of hardware and firmware implants by advanced actors in the wild. Secondly, the barriers to security research have been drastically reduced, meaning that the firmware layer is suddenly far more accessible to anyone in the security community.

This means that now the code in firmware and other infrastructure is open to scrutiny in much the same way that traditional software has been for years. In short the high-end attackers are leading the way, and the lower-end attackers now have the tools to emulate them.

This is of particular relevance as the industry increasingly adopts more and more virtualization. While computing trends toward increasing layers of abstraction with apps and services running in VMs and containers, all of those virtual assets eventually depend on the hardware. Instead of trying to compromise the virtual environment, attackers could simply exploit the hardware that the virtual world rides upon.

Attacks targeting BMCs and IPMI make this concern even more troubling. These interfaces are designed to ensure servers are remotely manageable even when the host OS isn’t running. By controlling this management infrastructure within the server, an attacker could modify the virtual environment and even change the operating system itself. With security solutions not monitoring software and firmware running on the BMCs and most organizations not monitoring BMC management network, attackers are able control the management network of data centers while staying hidden in the organization’s infrastructure.

It is important to note that this same idea applies to traditional user PCs as well. Intel’s Management Engine (ME/AMT) provide out of band management for PCs in much the same way that IPMI is used by servers. This likewise means that it is possible to attack a laptop even when it is powered off.

Remediation Avoidance

The problem persists even when we consider security remediation. When a security team suspects a device is compromised, one of the standard responses is to simply reimage the machine. However, simply reinstalling the operating system will have no effect on a device compromised at the firmware level. Not only is the firmware not replaced during a fresh install, it also runs before the OS. The firmware controls how the operating system is loaded or communicates with the hardware, and thus has incredible power over the machine and how it will run.

Vulnerabilities and Patching

While the hardware attack surface has suddenly been thrust into the spotlight, most organizations have almost nothing to help them manage vulnerabilities. First of all, firmware updates are often very few and far between. Known vulnerabilities can persist for years. Hardware vendors who are largely focused on providing stable hardware are often unable to keep up with advanced attackers in a race to constantly update firmware for products that are already released and introduce mitigations to rapidly changing exploitation techniques which general purpose operating systems have.

Secondly, updating firmware can be tricky. It can be difficult to even find devices that are vulnerable due to a lack vulnerability scanning at the hardware level. And unlike software updates, which are highly automated, firmware updates are often complicated and require significant time and manual effort for administrators. Recent examples with process firmware updates causing instability and unexpected reboots in servers further discourage security teams from deploying firmware updates in their critical infrastructure.

The result is that organizations often lack the tools to know where they are vulnerable, to address known vulnerabilities, and to detect and mitigate any active compromises. Let’s take a look at new model that can address these challenges.

Protection From the Hardware Up

Eclypsium introduces a new layer of security dedicated to protecting enterprises at the hardware and firmware level. The technology allows organizations to find vulnerabilities in their devices, detect known implants active in systems of an organization or tampering with the firmware, and actively isolate any affected systems. Key features and capabilities are summarized below:

  1. Attack Surface Management

    • Risk analysis of all monitored hosts—Analysis of firmware versions, and known vulnerabilities in the hardware and firmware. Analysis of hardware components, configuration and hardware protections supported by the system
    • Firmware update management—Centralized management of system firmware updates, and other firmware components.
  2. Detection and Containment of Threats

    • Firmware integrity monitoring and implant detection–Detection of implants in system firmware, hardware components (motherboards, network interface cards, baseboard management controllers, graphics cards, HDD and SSD storage devices, etc) as well as OS boot level implants.
    • Runtime behavior monitoring—Analysis of device, firmware, and OS behavior to identify signs of compromise or stealthy implant behavior.
    • Remediation—Reliable containment for any affected systems via hardware based mechanisms.

The Eclypsium user interface makes it easy to quickly check the overall posture of your environment, find any active threats, and drill down into details for any threat or host. Administrators can see information about firmware and hardware available on any monitored host including release dates of firmware components, and even check for the availability of updates from the vendor. Users can then verify the integrity of all firmware components, run on-demand assessments or scans, monitor runtime heuristics of the device, and review any identified threats.


Firmware is in every device in the modern enterprise from user devices like mobile phones and laptops to the servers, switches, and networking gear that define our data centers and the network itself. While the code and logic within this layer has been largely ignored for many years, a wave of new attacks has shown that organizations can no longer afford to rely on “security by obscurity” when it comes to their hardware. Vulnerabilities in the hardware layer are common, remain unpatched for long periods of time, and provide attackers with incredible power and ongoing stealth.

As with all types of information security, it is not enough to simply hope for our assets to defend themselves. For example, while operating systems are packed with security features, it is no substitute for layers of dedicated security. This is increasingly true of security at the hardware level as well. Even as hardware vendors begin to focus more on security, organizations need the independent visibility into their hardware attack surface with the ability to proactively detect and respond to threats. Eclypsium provides this critical layer of security. While this paper introduces many of the key concepts behind the solution, it is by no means exhaustive. We hope that you will be inspired to learn more on the subject, and we look forward to discussing how Eclypsium can help to protect the hardware layer of your organization.