…or why you need to add firmware integrity checks to your IR and recovery process
Over the past two years, firmware threats have gone from being the secret weapons of nation-state threat actors to everyday, commoditized threats used in some of the most widespread malware, ransomware, and attack campaigns in the world. Yet, many organizations are still in the earliest phases of building out their firmware security strategy, which can leave a gap for attackers.
And while implementing a strategy can take time, there are some highly tactical and practical steps that all organizations can and should be taking today. As a case in point, organizations should ensure that their IR and recovery teams have the tools to check the firmware integrity of any device directly impacted by malware or other threat.
So why is this so important? Three reasons:
#1 – Common Malware Is Already Scanning Your Firmware
TrickBot is estimated to be the #1 most common form of malware affecting enterprises today. TrickBot is a highly modular trojan that specializes in persistence and lateral movement and is an enabler for a wide range of other malware such as Conti and Ryuk ransomware.
More than a year ago TrickBot introduced new firmware-specific functionality called TrickBoot. This module checks an infected device to see if it can write to the device’s firmware, which could let the malware install an implant or backdoor into the UEFI firmware. This means that if an organization has had TrickBot in its environment within the past year, attackers may already know more about the organization’s firmware attack surface than the internal security team.
#2 – Firmware Implants Can Lead to a Cycle of Reinfection
Threats increasingly look to the firmware layer because it lets attacker code run below (and before) the operating system and also provides a place to store malicious code that is not on a system drive. Both of these factors are key factors for maintaining ongoing persistence on a device. By running below the operating system, an attacker can subvert the OS itself and any security controls running within the OS. Additionally, the attacker’s code would be able to survive a complete reinstallation of the OS or replacement of the physical device drives. This means that an attacker could easily persist across the reimaging process and reinfect the host after it was returned to service.
#3 – Adding Firmware to the Incident Response Life Cycle is Easy
Fortunately, with modern tools, it easy for teams to add firmware verification to their existing IR and recovery process. In the past, firmware analysis required specialized tools, manual analysis, and considerable firmware expertise. Today a simple scan can identify low-level vulnerabilities, misconfigurations, integrity changes, and a variety of threats. This type of analysis can supplement multiple phases of the IR lifecycle as defined by NIST SP-800-61 r2 (PDF).
As part of the “Detection and Analysis” phase, teams should verify the integrity of all critical firmware on the device. This will help identify any secondary infections or malicious code that is tied to the incident. This can be done by cryptographically comparing firmware to “known good” firmware for each component. Teams can also scan for IOCs of known implants and threats. Lastly, behavioral analysis can be performed to identify any unknown firmware threats. Firmware security tools such as Eclypsium can easily automate these tasks for almost any critical enterprise devices including laptops, servers, and networking devices.
Many of these same steps will apply to the “Containment, Eradication, and Recovery” phase as well. Here, teams will want to ensure that there are no firmware threats that could allow the attack to spread or reinfect the host after the recovery process. As a result, the same checks for valid firmware, known threats, and unknown threats would apply. Additionally, teams will want to ensure that any devices have all available firmware and boot protections properly enabled and that firmware is free from vulnerabilities before they are returned to service.
Once again, firmware security tools can make this a simple automated process. A quick scan can verify that devices are clean at the firmware level. Focusing on the IR team also allows security teams can get up and running quickly and start getting hands-on experience with firmware as part of their existing processes and response playbooks. If you would like to learn more about Eclypsium and how to augment your existing IR and recovery processes, please contact the team at [email protected].
