Keypoints
- Glupteba’s 2023 samples include a packed installer masquerading as csrss.exe that unpacks and executes code from executable RWX heap memory.
- The installer mounts the EFI system partition (ESP) as B:, renames original boot manager files, and writes embedded EFI components including Loader.efi and EfiGuardDxe.efi into the ESP.
- Glupteba’s EFI components are recompilations of the open-source EfiGuard project and use a loader to execute a DXE driver that hooks EFI boot services.
- The DXE driver hooks the EFI LoadImage function to intercept bootmgfw.efi, then applies a chain of patches that modify Windows boot components and ntoskrnl.exe to disable PatchGuard and DSE at boot time.
- The installer contains logic to choose among multiple DSE bypass methods (DSEFix, UPGDSED, or EfiGuard) depending on platform/OS, with EfiGuard added to Glupteba’s toolkit in 2023.
- There is no observed evidence in these samples of Secure Boot bypass; the implant modifies the ESP (not SPI flash) and relies on loader+DXE driver method to persist across reboots.
- Palo Alto Networks telemetry shows the file-write events in the ESP and their UEFI Protection module can detect and block these modifications.
MITRE Techniques
- None mentioned – The article does not reference specific MITRE ATT&CK technique IDs. “No MITRE techniques were explicitly cited in the report.”
Indicators of Compromise
- [File hash] Glupteba binaries from 2023 – cfc7111da7b09e7a93b93ce690f2a4d922cc1009fea8368300f06c6fa4f85472, 8e380777da39ad7a588f4d9b703adc18b4ba935c21b17f215a3da5792672f205, and 14 more hashes
- [Archive hash] Distribution ZIP files used in 2023 campaign – cb347e06d97fde4c7f8dd77be59b8f57d47f6e3f998d708d21a5963bc1620835, 46eb8b98738df13a3a8c923228ca82006c7d403c7a1aac2d6bc752023b432915, and 12 more
- [EFI binaries] EfiGuard components dropped to ESP – 9fdb7c1359f3f2f7279f1df4bde648c080231ed21a22906e908ef3f91f0d00ee, 01e86a4dfe6e0de7857b3cf2fafd041c8b3a3241e00844cb6bfbd3bfae2d36bc
- [Domain] Campaign infrastructure domains – weareelight[.]com, dpav[.]cc, and 10 more domains associated with distribution and command infrastructure
- [File name] Boot/ESP modifications – bootmgfw.efi (original Windows Boot Manager renamed and replaced), EfiGuardDxe.efi (UEFI DXE driver written to B:EFIBoot), Loader.efi (loader that loads EfiGuardDxe.efi)
- [File name] Installer masquerade – csrss.exe (malicious installer binary impersonating legitimate Windows process)
- [PDB path] Developer artifact – C:juroyologakibrihahoy71waxotobub.pdb (location of a program database file found in 2023)
The technical procedure begins with a packed Windows binary masquerading as csrss.exe; static and dynamic analysis shows it allocates RWX heap regions, writes unpacked PE resources into that memory, and then executes them. The main installer logic mounts the EFI System Partition as a drive (observed as B:), renames existing EFI files (for example renaming B:EFIMicrosoftBootbootmgfw.efi to B:EFIMicrosoftBootfw.efi and B:EFIBootbootx64.efi to B:EFIBootold.efi), and writes embedded assets: a modified boot manager, Loader.efi (replaces bootmgfw.efi), and EfiGuardDxe.efi into the ESP. Cortex XDR telemetry shows these specific file-write operations during installation.
The Loader.efi loads EfiGuardDxe.efi and continues the boot process; the DXE driver hooks the EFI Boot Service LoadImage to intercept the Windows Boot Manager image and execute a chain of in-memory patches that propagate through boot components (bootmgfw.efi → winload.efi) and ultimately patch ntoskrnl.exe to disable PatchGuard and driver signature enforcement (DSE) at boot. The samples are recompilations of the open-source EfiGuard project: Bindiff comparisons show strong similarity to EfiGuard’s Loader.efi and EfiGuardDxe.efi, but with logging removed and manual modifications that enforce the boot-time DSE-disable path. The project also documents an alternative backdoor using EFI SetVariable plus a user-mode EfiDSEFix utility; however, the observed Glupteba samples use the boot-time patch method and have removed the configuration checks that would select other paths.
Glupteba’s installer contains logic to select among different DSE bypass techniques (historically DSEFix and UPGDSED, and now EfiGuard) depending on system architecture and OS version, making the payload adaptable. These samples modify the ESP rather than SPI flash, and no evidence was found of Secure Boot being bypassed in these instances. Detection focuses on abnormal ESP writes (new/renamed bootmgfw.efi, presence of Loader.efi and EfiGuardDxe.efi) and installer behaviors (packed csrss.exe allocating RWX memory and performing EFI writes), which are effective indicators for triage and containment.
Read more: https://unit42.paloaltonetworks.com/glupteba-malware-uefi-bootkit/