There is WPBT ACPI table which may contain PE executable saved as \Windows\System32\Wpbbin.exe and executed at boot time (supported by Windows 8 and above). Official specification is here: https://download.microsoft.com/download/8/A/2/8A2FB72D-9B96-...
Also there is an unofficial method of running firmware-initiated VBScript in the all versions Windows starting from Windows 2000. There is a special type of ACPI devices (PNP0C14, "Windows Management Instrumentation Device") which is handled by Windows builtin driver WMIACPI.SYS. This type of ACPI device can export (via ACPI bytecode) various data fields and methods for Windows subsystem WMI/WBEM (think CPU thermal sensors; laptop backlight control; on/off switches for builtin camera/wifi/bluetooth hardware, which can be managed by Windows tray utility supplied by laptop vendor etc), as well as binary MOF which contains WMI metadata for these fields and methods. Besides primary purpose, this binary MOF can be constructed in such way that VBScript code is executed immediately in the MOF parser context (wmiprvse.exe, a builtin Windows service). Windows DDK has various MOF-related tools like compiler, verifier etc; as well as some samples. Binary MOF is compressed, but its format has been reverse engineered (it uses an old compression algorithm from Microsoft DoubleSpace). This method for running firmware-initiated VBScript works for all versions of Windows starting from Windows 2000, including WinPE-based Windows Setup (Vista+).
You mentioned the two methods I had in mind. These days there is a third one, but it seems to require cooperation from Windows Update. MSI (for example) uses it. As far I as can see, they simply create a fake ACPI node for which Windows Update will silently download a "driver", which in turn downloads the crapware.
Fun thing is that laptop OEMs exposing useful 'value-added functionality' (like custom fan control) via pre-defined WMI ACPI callouts is actually the sensible choice to make.
I've seen laptop OEMs that rely on a custom kernel driver for this, and then if you want to reimplement their pile of 'overly modular everything control suite' you're stuck loading a generic read/write-memory driver which is blocklisted by every antimalware and anticheat solution in existence.
(In addition, it seems some WMI/CIM/MOF ACPI stuff is supported on Linux fine, too, as long as OEMs try to stick to standard DMTF-spec stuff I guess... so one can also just do 'generic' user-space stuff there if lucky)
Could you elaborate? Sounds very sinister