Blog

Supply Chain Risk from Gigabyte App Center Backdoor

Updates: 

1. Gigabyte has published updates related to this issue. See the Gigabyte advisory for details. 

2. Eclypsium has released a PowerShell script to Github that can assist in determining whether a system is impacted. 

The script compares the motherboard model to the list of models known to be impacted. It also checks the Windows filesystem for the presence of the GigabyteUpdateService.exe executable and, if found, compares the SHA256 hash against the list of hashes seen by Eclypsium.

The script does not require administrative permissions to run, but it does require that the PowerShell ExecutionPolicy be configured to allow running scripts.

3. As a result of our ongoing monitoring of this issue, we have an updated list of affected models that has increased from 271 to 406.

Recently, the Eclypsium platform began detecting suspected backdoor-like behavior within Gigabyte systems in the wild. These detections were driven by heuristic detection methods, which play an important role in detecting new, previously-unknown supply chain threats, where legitimate third-party technology products or updates have been compromised. Our follow-up analysis discovered that firmware in Gigabyte systems is dropping and executing a Windows native executable during the system startup process, and this executable then downloads and executes additional payloads insecurely. It uses the same techniques as other OEM backdoor-like features like Computrace backdoor (a.k.a. LoJack DoubleAgent) abused by threat actors and even firmware implants such as Sednit LoJax, MosaicRegressor, Vector-EDK. Subsequent analysis showed that this same code is present in hundreds of models of Gigabyte PCs. We are working with Gigabyte to address this insecure implementation of their app center capability.

In the interest of protecting organizations from malicious actors, we are also publicly disclosing this information and defensive strategies on a more accelerated timeline than a typical vulnerability disclosure. This backdoor appears to be implementing intentional functionality and would require a firmware update to completely remove it from affected systems. While our ongoing investigation has not confirmed exploitation by a specific threat actor, an active widespread backdoor that is difficult to remove poses a supply chain risk for organizations with Gigabyte systems. At a high level, the relevant attack vectors include:

  • Compromise in the supply chain
  • Compromise in the local environment
  • Malware persistence via functionality of this firmware in systems

A more detailed analysis of these risks is provided with suggested mitigations below. After a more traditional vulnerability disclosure timeline, we plan to publish details about how this works.

Key Findings

There are two important aspects of our findings: 

  1. Eclypsium automated heuristics detected firmware on Gigabyte systems that drops an executable Windows binary that is executed during the Windows startup process.
  2. This executable binary insecurely downloads and executes additional payloads from the Internet. 

Since many more issues like this continue to be discovered, Eclypsium is continuously running at-scale analysis of the information technology supply chain. Look for additional findings on this blog and the Eclypsium Platform for your organization. 

Stage 1: Firmware dropping OS executable

An initial analysis of the affected UEFI firmware identified the following file:

8ccbee6f7858ac6b92ce23594c9e2563ebcef59414b5ac13ebebde0c715971b2.bin

This is a Windows Native Binary executable embedded inside of UEFI firmware binary in a UEFI firmware volume with the following GUID:

AEB1671D-019C-4B3B-BA-00-35-A2-E6-28-04-36. 

This Windows executable is embedded into UEFI firmware and written to disk by firmware as part of the system boot process, a technique commonly used by UEFI implants and backdoors. During the Driver Execution Environment (DXE) phase of the UEFI firmware boot process, the “WpbtDxe.efi” firmware module uses the above GUID to load the embedded Windows executable file into memory, installing it into a WPBT ACPI table which will later be loaded and executed by the Windows Session Manager Subsystem (smss.exe) upon Windows startup. The “WpbtDxe.efi” module checks if the “APP Center Download & Install” feature has been enabled in the BIOS/UEFI Setup before installing the executable into the WPBT ACPI table. Although this setting appears to be disabled by default, it was enabled on the system we examined.

This executable uses the Windows Native API to write the contents of an embedded executable to the file system at the following location:

 %SystemRoot%\system32\GigabyteUpdateService.exe

It then sets registry entries to run this executable as a Windows Service. The mechanism described here is similar to the methods used by other UEFI firmware implants such as LoJax, MosiacRegressor, MoonBounce, and Vector-EDK, referenced previously. 

Stage 2: Downloading and running further executables

The dropped Windows executable is a .NET application. It downloads and runs an executable payload from one of the following locations, depending on how it’s been configured:

  • http://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4
  • https://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4
  • https://software-nas/Swhttp/LiveUpdate4

Plain HTTP (the first bullet above) should never be used for updating privileged code as it is easily compromised via Machine-in-the-middle (MITM) attacks. However, we noticed that even when using the HTTPS-enabled options, remote server certificate validation is not implemented correctly. Therefore, MITM is possible in that case also. 

The firmware does not implement any cryptographic digital signature verification or any other validation over the executables. The dropped executable and the normally-downloaded Gigabyte tools do have a Gigabyte cryptographic signature that satisfies the code signing requirements of Microsoft Windows, but this does little to offset malicious use, especially if exploited using Living-off-the-Land techniques (like in the recent alert regarding Volt Typhoon attackers). As a result, any threat actor can use this to persistently infect vulnerable systems either via MITM or compromised infrastructure. 

Risks and Impact

These issues expose organizations to a wide range of risks and attack scenarios. 

  • Abuse of an OEM backdoor by threat actors – Previously, threat actors have taken advantage of legitimate but insecure/vulnerable “OEM backdoor” software built into the firmware of PCs. Most notably, Sednit group (APT28, FancyBear) exploited Computrace LoJack to masquerade as legitimate laptop anti-theft feature.
  • Compromise of the OEM update infrastructure and supply chain – Gigabyte does have documentation on their website for this feature so it may be legitimate, but we cannot confirm what is happening within Gigabyte. In August 2021, Gigabyte experienced a breach of critical data by the RansomEXX group and then experienced another breach in October 2021 by the AvosLocker group
  • Persistence using UEFI Rootkits and Implants – UEFI rootkits and implants are some of the stealthiest and most powerful forms of malware in existence. They reside in firmware on motherboards or within EFI system partitions of storage media, and execute before the operating system, allowing them to completely subvert the OS and security controls running in higher layers. Additionally, since most of the UEFI code exists on the motherboard instead of storage drives, UEFI threats will easily persist even if drives are wiped and the OS is reinstalled. The rate of discovery of new UEFI rootkits has accelerated sharply in recent years as seen by the discovery of LoJax (2018), MosaicRegressor (2020),  FinSpy (2021) ESPecter (2021), MoonBounce (2022), CosmicStrand (2022), and BlackLotus (2023). Most of these were used to enable persistence of other, OS-based malware. The Gigabyte firmware images and the persistently dropped Windows executable enable the same attack scenario. Often, the above implants made their native Windows executables look like legitimate update tools. In the case of MosaicRegressor, the Windows payload was named “IntelUpdater.exe”
  • MITM attacks on firmware and software update features – Additionally, the insecure nature of the update process opens the door to MITM techniques via a compromised router, compromised device on the same network segment, DNS poisoning, or other network manipulation. It is also important to note that the third connection option, https://software-nas/Swhttp/LiveUpdate4 , is not a fully qualified domain name, but rather, a machine name that would presumably be on the local network. This means an attacker on a local subnet could trick the implant into connecting to their system, without the need for DNS spoofing.
  • Ongoing risk due to unwanted behavior within official firmware – Backdoors hidden within UEFI or other firmware can be hard to remove. Even if the backdoor executable is removed, the firmware will simply drop it again the next time the system boots up. This challenge was demonstrated before when trying to remove Computrace LoJack and relates to vulnerabilities in Lenovo Service Engine on notebooks and desktops

Recommendations

We recommend exercising caution when using Gigabyte systems or systems with affected motherboards. Organizations can also take the following actions to minimize the risk:

  • Scan and monitor systems and firmware updates in order to detect affected Gigabyte systems and the backdoor-like tools embedded in firmware. Update systems to the latest validated firmware and software in order to address security issues like this one.
  • Inspect and disable the “APP Center Download & Install” feature in UEFI/BIOS Setup on Gigabyte systems and set a BIOS password to deter malicious changes.
  • Administrators can also block the following URLs:
    • http://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4
    • https://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4
    • https://software-nas/Swhttp/LiveUpdate4

Researchers at Eclypsium Labs are continuing to investigate for any signs of malicious activity related to this discovery. We will provide additional updates as new information becomes available. For more information or assistance contact Eclypsium at [email protected].

A list of affected models is available here.