https://michlstechblog.info/blog/windows-identify-a-wpbt-binary-in-biosuefi/

To identify if your Windows system is executing a WPBT binary check if
file C:\Windows\system32\wpbbin.exe exists.

The idea is to delete or rename the file, but I've seen other articles
(one of which I cited) that says the absence of this file is not
definitive proof WPBT won't happen after booting into Windows, and
Windows finding the .exe in the ACPI WPBT table. I don't have this
file, but I want better assurance WPBT is dead on my setup. Microsoft
might install a different executable in an update, or have some sneaky
way to effect WPBT without this particular file.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Johnny <johnny@invalid.net> wrote:

Published June 11, 2023

A cybersecurity company called Eclypsium has made a startling
discovery. They found a hidden backdoor in the firmware of motherboards
(the main circuit board in a computer) made by a Taiwanese company
called Gigabyte, and this backdoor makes the motherboards easily
accessible for hackers to break into.

Gigabyte apparently integrated a Windows executable file into the
firmware of its motherboards. This file is executed when the computer
starts up, meaning that each time you restart your computer, the
firmware's code activates Gigabyte's app center. This app center then proceeds to download and run a file from the internet.

Continued:

https://www.foxnews.com/tech/pcs-motherboard-hidden-vulnerability-risk

A Windows executable file. That means the OS has to be available to
support running a Win32 executable. Well, if Windows gets loaded by the
BIOS then what's the point of later re-loading it after the POST screen?
More likely its an ASM executable (machine code). Also, this program is
used to update the firmware (BIOS/UEFI) of the mobo. Why would you let
anyone change the brains of your computer? That is major surgery.
*YOU* decide when you have prepared for a firmware update before doing
it. Maybe it's safe in presenting a prompt/GUI asking for your
permission to perform the firmware update, but that would be a nuisance
on a perfectly functioning computer in nagging you to update when likely
the new firmware version will give you nothing. *YOU* are supposed to investigate what a new firmware version gives you before applying it.
If your BIOS has a firmware-based option to auto-update the firmware,
*TURN IT OFF*.

Many mobos give you software (that runs under an OS, not machine code to
run raw) to check for firmware and ancilliary software updates, but you
have to run them. They don't load automatically during the boot
process. They load by you after the OS has loaded. I have an Asrock
mobo whose BIOS has no setting to disable WPBT, but they provide
user-loaded software to run after Windows boots to do firmware updating.
The *user* decides if and when to run this program. I might've had this
tool installed when first setting up the new build, but I got rid of it. Instead of a tool to check for updates, and download the installers, I
just go to Asrock's web site to check on updates, investigate what the
update does for me, and then download it and run it. I don't need a
tool to get the update installers. There is a BIOS option for "Internet Flash", but I should've disabled it when reviewing all the BIOS settings
(can't check now because I have to boot to get into BIOS settings).

As far as securing the mobo firmware, well, if you can run software (or Gigabyte during boot) then so can malware. The same program you run to
flash the firmware is the same code that malware could use. However,
the trick is to con the user into allowing the update, and Gigabyte
apparently took away that safety step.

Although the Fox article is dated today (June 11), it is old.

https://www.bleepingcomputer.com/news/security/gigabyte-releases-new-firmware-to-fix-recently-disclosed-security-flaws/

Dated June 5, and says a firmware update was released 5 days earlier.
Also notes:

"The WPBT allows vendors and OEMs to run an .exe program in the UEFI
layer. Every time Windows boots, it looks at the UEFI, and runs the
.exe. It's used to run programs that aren't included with the Windows
media," explains Microsoft.

So, it is NOT a firmware-based auto-updater. It is a file desposited
into UEFI which if found /after/ Windows boots then Windows will run.
The above article says how to disable the feature in Gigabyte's BIOS
settings, so *TURN IT OFF*, and /you/ decide when you have prepared to
check for firmware updates, check if they really apply to you, and apply
them knowing you risk the brain surgery committed on your mobo.

I'm hunting around for how to disable Windows Platform Binary Table
(WPBT) available in Windows 8+. So far, I found:

https://github.com/Jamesits/dropWPBT

You can use Nirsoft's FirmwareTablesView to see the firmware tables
(ACPI, SMBIOS), but I'm yet not sure what to look for, you're just
viewing, and where the .exe is stored in UEFI is not identified.

https://www.nirsoft.net/utils/firmware_tables_view.html

I don't see a WPBT labelled ACPI table in the list from Nirsoft's tool.
As I recall, Windows 7 was the first OS on this computer build, and WPBT
didn't show up until Windows 8, and later.

More info on Windows Platform Binary Table (WPBT) at:

https://download.microsoft.com/download/8/a/2/8a2fb72d-9b96-4e2d-a559-4a27cf905a80/windows-platform-binary-table.docx

WPBT is Microsoft's rootkit method. Can be used for firmware updates, anti-theft software, or whatever the UEFI-embedded .exe does.

"Everyone Gets A Rootkit" https://eclypsium.com/research/everyone-gets-a-rootkit/

They mention using Windows Defender's App Control feature to mitigate
the WPBT vulnerability (if it exists for your mobo). See:

https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview

So, instead of keeping the barn door closed and controlling horses can
exit through the barn door, you close the gate to a fence surrounding
the barn, and control which horses can go through the gate. But you
have the problem of not knowing which horses to exit through the fence
gate ("How Odysseus Tricked Polyphemus the Cyclops to Escape", https://www.greekboston.com/culture/mythology/odysseus-tricked-polyphemus/).

Rather than go through all that shit, I'll just check my BIOS has no auto-update settings to its firmware, and see if it's easier to disable
WPBT to eliminate the vulnerability from the Windows end.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Carlos E.R." <robin_listas@es.invalid> wrote:

AFAIK it is loaded by UEFI before Windows loads. You can't stop it.

Nope. The .exe is deposited into the WPBT ACPI table in UEFI, and
Windows, after booting, will run wpbbin.exe to check if there is an .exe
there, and if so run the .exe under the Windows OS.

An .exe alone (no OS) wouldn't run. It would have to be a machine code
program (specific to the mobo hardware) that still some dispatcher would
have to load into memory to run the machine code. From the
vulnerability description, it's a Win32 .exe file which requires it get
loaded by Windows' dispatcher into memory and execution started along
with support from the Win32 and C runtimes provided by Windows. That's
why it's called a Windows executable stored in the UEFI. The program
file is there, but an OS has to load to load and run it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Carlos E.R." <robin_listas@es.invalid> wrote:

Having a windows executable in the firmware is interesting. Would Linux computers be at risk?

See my other reply (to Johnny). It's a Windows 8+ "feature": Windows
Platform Binary Table (WPBT) - a built-in UEFI-based rootkit. Deposit
an .exe into the WPBT ACPI table, and Windows (after booting) will run
the .exe if found -- ANY .exe that's there. It's a Windows 8+ thing
(well, along with UEFI). You would have to check if Linux after booting
will load executables stored in the UEFI.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)