{
	"id": "4af956a6-825b-4656-9f36-a302a8f7961a",
	"created_at": "2026-04-10T03:20:27.189494Z",
	"updated_at": "2026-04-10T03:22:17.253611Z",
	"deleted_at": null,
	"sha1_hash": "ea40707e4da15931b7ea144abdb1cc6f8c838980",
	"title": "UEFI threats moving to the ESP: Introducing ESPecter bootkit",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 947681,
	"plain_text": "UEFI threats moving to the ESP: Introducing ESPecter bootkit\r\nBy Martin SmolárAnton Cherepanov\r\nArchived: 2026-04-10 02:35:58 UTC\r\nESET researchers have analyzed a previously undocumented, real-world UEFI bootkit that persists on the EFI System\r\nPartition (ESP). The bootkit, which we’ve named ESPecter, can bypass Windows Driver Signature Enforcement to load\r\nits own unsigned driver, which facilitates its espionage activities. Alongside Kaspersky’s recent discovery of the unrelated\r\nFinSpy bootkit, it is now safe to say that real-world UEFI threats are no longer limited to SPI flash implants, as used by\r\nLojax.\r\nThe days of UEFI (Unified Extensible Firmware Interface) living in the shadows of the legacy BIOS are gone for good.\r\nAs a leading technology embedded into chips of modern computers and devices, it plays a crucial role in securing the pre-OS environment and loading the operating system. And it’s no surprise that such a widespread technology has also\r\nbecome a tempting target for threat actors in their search for ultimate persistence.\r\nIn the last few years, we have seen proof-of-concept examples of UEFI bootkits (DreamBoot, EfiGuard), leaked\r\ndocuments (DerStarke, QuarkMatter) and even leaked source code (Hacking Team Vector EDK), suggesting the existence\r\nof real UEFI malware either in the form of SPI flash implants or ESP implants. Despite all of the above, only three real-world cases of UEFI malware have been discovered so far (LoJax, discovered by our team in 2018, MosaicRegressor,\r\ndiscovered by Kaspersky in 2019, and most recently the FinSpy bootkit, whose analysis was just published by\r\nKaspersky). While the first two fall in the category of SPI flash implants, the last falls in the ESP implants category, and\r\nsurprisingly, it’s not alone there.\r\nToday, we describe our recent discovery of ESPecter, just the second real-world case of a UEFI bootkit persisting on the\r\nESP in the form of a patched Windows Boot Manager to be analyzed. ESPecter was encountered on a compromised\r\nmachine along with a user-mode client component with keylogging and document-stealing functionalities, which is why\r\nwe believe ESPecter is mainly used for espionage. Interestingly, we traced the roots of this threat back to at least 2012,\r\npreviously operating as a bootkit for systems with legacy BIOSes. Despite ESPecter’s long existence, its operations and\r\nupgrade to UEFI went unnoticed and have not been documented until now. Note that the only similarity between\r\nESPecter and the Kaspersky FinSpy find is that they share the UEFI boot manager compromise approach.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 1 of 18\n\nFigure 1. Comparison of the Legacy Boot flow (left) and UEFI boot flow (right) on Windows (Vista and newer) systems\r\nBy patching the Windows Boot Manager, attackers achieve execution in the early stages of the system boot process (see\r\nFigure 1), before the operating system is fully loaded. This allows ESPecter to bypass Windows Driver Signature\r\nEnforcement (DSE) in order to execute its own unsigned driver at system startup. This driver then injects other user-mode\r\ncomponents into specific system processes to initiate communication with ESPecter’s C\u0026C server and to allow the\r\nattacker to take control of the compromised machine by downloading and running additional malware or executing C\u0026C\r\ncommands.\r\nEven though Secure Boot stands in the way of executing untrusted UEFI binaries from the ESP, over the last few years\r\nwe have been witness to various UEFI firmware vulnerabilities affecting thousands of devices that allow disabling or\r\nbypassing Secure Boot (e.g. VU#758382, VU#976132, VU#631788, …). This shows that securing UEFI firmware is a\r\nchallenging task and that the way various vendors apply security policies and use UEFI services is not always ideal.\r\nPreviously, we have reported multiple malicious EFI samples in the form of simple, single-purpose UEFI applications\r\nwithout extensive functionality. These observations, along with the concurrent discovery of the ESPecter and FinFisher\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 2 of 18\n\nbootkits, both fully functional UEFI bootkits, show that threat actors are not relying only on UEFI firmware implants\r\nwhen it comes to pre-OS persistence, but also are trying to take advantage of disabled Secure Boot to execute their own\r\nESP implants.\r\nWe were not able to attribute ESPecter to any known threat actor, but the Chinese debug messages in the associated user-mode client component (as seen in Figure 2) leads us to believe with a low confidence that an unknown Chinese-speaking\r\nthreat actor is behind ESPecter. At this point, we don’t know how it was distributed.\r\nFigure 2. Example of Chinese debug messages in the user-mode client component\r\nEvolution of the ESPecter bootkit\r\nWhen we looked at our telemetry, we were able to date the beginnings of this bootkit back to at least 2012. At its\r\nbeginning, it used MBR (Master Boot Record) modification as its persistence method and its authors were continuously\r\nadding support for new Windows OS versions. What is interesting is that the malware’s components have barely changed\r\nover all these years and the differences between 2012 and 2020 versions are not as significant as one would expect.\r\nAfter all the years of insignificant changes, those behind ESPecter apparently decided to move their malware from legacy\r\nBIOS systems to modern UEFI systems. They decided to achieve this by modifying a legitimate Windows Boot Manager\r\nbinary (bootmgfw.efi) located on the ESP while supporting multiple Windows versions spanning Windows 7 through\r\nWindows 10 inclusive. As we mentioned earlier, this method has one drawback – it requires that the Secure Boot feature\r\nbe disabled in order to successfully boot with a modified boot manager. However, it’s worth mentioning that the first\r\nWindows version supporting Secure Boot was Windows 8, meaning that all previous versions are vulnerable to this\r\npersistence method.\r\nFor Windows OS versions that support Secure Boot, the attacker would need to disable it. For now, it’s unknown how the\r\nESPecter operators achieved this, but there are a few possible scenarios:\r\nThe attacker has physical access to the device (historically known as an “evil maid” attack) and manually disables\r\nSecure Boot in the BIOS setup menu (it is common for the firmware configuration menu to still be labeled and\r\nreferred to as the “BIOS setup menu”, even on UEFI systems).\r\nSecure Boot was already disabled on the compromised machine (e.g., user might dual-boot Windows and other\r\nOSes that do not support Secure Boot).\r\nExploiting an unknown UEFI firmware vulnerability that allows disabling Secure Boot.\r\nExploiting a known UEFI firmware vulnerability in the case of an outdated firmware version or a no-longer-supported product.\r\nTechnical analysis\r\nDuring our investigation, we discovered several malicious components related to ESPecter:\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 3 of 18\n\nInstallers, only for the older MBR versions of the bootkit, whose purpose was to set up persistence on the machine\r\nby rewriting the MBR of the boot device.\r\nBoot code in the form of either a modified Windows Boot Manager (bootmgfw.efi) on UEFI systems or a\r\nmalicious MBR in the case of Legacy Boot systems.\r\nA kernel-mode driver used to prepare the environment for the user-mode payloads and to load them in the early\r\nstages of OS startup by injecting them into specific system processes.\r\nUser-mode payloads responsible for communication with the C\u0026C, updating the C\u0026C configuration and\r\nexecuting C\u0026C commands.\r\nFor the complete scheme of the ESPecter bootkit compromise, see Figure 3.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 4 of 18\n\nFigure 3. ESPecter bootkit components\r\nAchieving persistence – UEFI boot\r\nOn systems using UEFI Boot mode, ESPecter persistence is established by modifying the Windows Boot Manager\r\nbootmgfw.efi and the fallback bootloader binary bootx64.efi, which are usually located in the ESP directories\r\n\\EFI\\Microsoft\\Boot\\ and \\EFI\\Boot\\, respectively. Modification of the bootloader includes adding a new section called\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 5 of 18\n\n.efi to the PE, and changing the executable’s entry point address so program flow jumps to the beginning of the added\r\nsection, as seen in Figure 4.\r\nFigure 4. Comparison of original (top) and modified (bottom) Windows Boot Manager (bootmgfw.efi)\r\nSimplified boot chain\r\nAs shown in the scheme on the left in Figure 5, the boot process on UEFI systems (ignoring the firmware part) starts with\r\nexecution of the bootloader application located in the ESP. For the Windows OS, this is the Windows Boot Manager\r\nbinary (bootmgfw.efi) and its purpose is to find an installed operating system and transfer execution to its OS kernel\r\nloader – winload.efi. Similar to the boot manager, the OS kernel loader is responsible for the loading and execution of the\r\nnext component in the boot chain – the Windows kernel (ntoskrnl.exe).\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 6 of 18\n\nFigure 5. Boot flow modified by ESPecter\r\nHow does ESPecter modify the UEFI boot process?\r\nIn order to successfully drop its malicious payload, ESPecter needs to bypass integrity checks performed by the Windows\r\nBoot Manager and the Windows kernel during the boot process. To do this, it looks for byte patterns identifying the\r\ndesired functions in memory and patches them accordingly.\r\nStarting with the bootloader, in our case Windows Boot Manager (bootmgfw.efi), the bootkit begins by patching the\r\nBmFwVerifySelfIntegrity function. This function is responsible for verification of the boot manager’s own digital\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 7 of 18\n\nsignature and is intended to prevent execution of a modified boot manager. In Figure 6 you can see how ESPecter\r\nsearches memory for BmFwVerifySelfIntegrity using various byte patterns (to support many bootmgfw.efi versions) and\r\nmodifies this function in a way that it always returns zero, indicating that verification was successful.\r\nAs mentioned earlier, the bootloader’s main goal is to find an installed operating system and transfer execution to its OS\r\nkernel loader. For the Windows Boot Manager, this happens in the Archpx64TransferTo64BitApplicationAsm function;\r\ntherefore, ESPecter looks for this function in order to catch the moment that the OS loader is loaded into memory, but still\r\nhasn’t been executed. If found, ESPecter patches this function to insert its own detour function, which can easily modify\r\nthe loaded OS loader in memory at the right moment.\r\nFigure 6. Hex-Rays decompiled code – searching for and patching the BmFwVerifySelfIntegrity function\r\nModification of the OS loader does not include patching of any integrity checks or other functionality. At this stage it’s\r\nimportant for the bootkit to reallocate its code, because as a UEFI Application it will be unloaded from memory after\r\nreturning from its entry point function. For this purpose, it uses the BlImgAllocateImageBuffer or\r\nBlMmAllocateVirtualPages function (depending on the pattern found). After this reallocation, the bootkit inserts a detour\r\n(located in the previously allocated buffer) to the function responsible for transferring execution to the OS kernel –\r\nOslArchTransferToKernel – so it can patch the Windows kernel in memory, once it is loaded but before it is executed.\r\nThe final stage of the bootkit’s boot code is responsible for disabling DSE by patching the SepInitializeCodeIntegrity\r\nkernel function (see Figure 7 for details).\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 8 of 18\n\nFigure 7. Comparison of Hex-Rays decompiled SepInitializeCodeIntegrity function before (left) and after (right) it is\r\npatched in memory\r\nInterestingly, the boot code also patches the MiComputeDriverProtection kernel function. Even though this function does\r\nnot directly affect successful loading of the malicious driver, the bootkit does not proceed to the driver dropping if it does\r\nnot find and patch this function in kernel memory. We were not able to identify the purpose of this second patch, but we\r\nassume this modified function may be used by other, as yet unknown, ESPecter components.\r\n\\SystemRoot\\System32\\null.sys (driver)\r\n\\SystemRoot\\Temp\\syslog (encrypted configuration)\r\nThe configuration is used by the WinSys.dll user-mode component deployed by the kernel driver and consists of a one-byte XOR key followed by the encrypted configuration data. To decrypt the configuration, WinSys.dll:\r\n1. Base64 decodes the configuration data\r\n2. XORs the data with the XOR key\r\n3. Base64 decodes each value delimited by “|” separately\r\nAn example of a configuration dropped by the EFI version of ESPecter is presented in Figure 8. A full list of IP addresses\r\nand domains from configurations embedded in the ESPecter bootkit samples that we have discovered (both Legacy Boot\r\nand UEFI versions) is included in the IoCs section.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 9 of 18\n\nFigure 8. Decryption of configuration delivered by the EFI version of the ESPecter bootkit\r\nAchieving persistence – Legacy Boot\r\nAs already mentioned, there are ESPecter versions supporting UEFI, and others supporting Legacy Boot, modes. In the\r\ncase of Legacy Boot mode, persistence is achieved by the well-known technique of modifying the MBR code located in\r\nthe first physical sector of the disk drive; therefore, we won’t explain it in detail here, but will just summarize it.\r\nHow does ESPecter modify the Legacy Boot process?\r\nThe malicious MBR first decrypts code previously copied to disk sectors 2, 3 and 4 by the installer, hooks the real-mode\r\nINT13h (BIOS sector read-write services) interrupt handler and then passes execution to the original MBR code, backed\r\nup to the second sector (sector 1) by the installer. Similar to other known MBR bootkits, when the INT13h interrupt\r\nhandler is invoked, hook code (located in sector 0) checks for service 0x02 (Read sectors from drive) and 0x42 (Extended\r\nread sectors from drive) being handled in order to intercept loading of bootmgr – the legacy version of the Windows Boot\r\nManager. Note that ESPecter legacy versions do not need to patch the BmFwVerifySelfIntegrity function in bootmgr,\r\nbecause the bootmgr binary wasn’t modified in any way.\r\nFrom this point, the functionality of the boot code is almost the same as in the UEFI version, resulting in dropping the\r\nmalicious driver (located contiguously on Track 0, starting at sector 6) into one of the following locations, depending on\r\nthe architecture:\r\n\\SystemRoot\\System32\\drivers\\beep.sys (x86)\r\n\\SystemRoot\\System32\\drivers\\null.sys (x64)\r\nIn this case, the encrypted configuration is not dropped to the syslog file but stays hidden in sector 5 of the compromised\r\ndisk.\r\nFigure 9. Modified disk scheme used by the legacy ESPecter version\r\nKernel-mode driver\r\nThe driver’s main purpose is to load user-mode payloads, set up the keylogger and, in the end, delete itself. Setting up the\r\nkeylogger is done in two steps:\r\nAt first, it creates a device named \\Device\\WebBK that exposes a function handling\r\nIRP_MJ_DEVICE_CONTROL requests from the user-mode components. This function supports one IOCTL\r\n(Input/Output Control) code (0x22C004), which can be used to trigger registration of an asynchronous procedure\r\ncall routine responsible for processing intercepted keystrokes.\r\nInterception of keystrokes is done by setting up CompletionRoutine for IRP_MJ_READ requests for the keyboard\r\ndriver object \\Device\\KeyboardClass0.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 10 of 18\n\nWhen done, any process can start logging intercepted keystrokes by defining its own routine and passing it to the created\r\ndevice object using the custom IOCTL 0x22C004.\r\nBy default, the driver tries to load two base payloads – WinSys.dll and Client.dll – which have the ability to download\r\nand execute additional payloads. The first one, WinSys.dll, is an MPRESS-packed DLL embedded in the driver’s binary\r\nin an encrypted form. The second one, Client.dll, is downloaded by WinSys.dll to the file \\SystemRoot\\Temp\\memlog,\r\nalso in an encrypted form, using the same encryption method – a simple one-byte XOR with subtraction – but not the\r\nsame keys. Both libraries are decrypted and dropped to the system directory \\SystemRoot\\System32\\ by the driver.\r\nExecution of both WinSys.dll and Client.dll libraries is achieved by injecting them into svchost.exe and winlogon.exe,\r\nrespectively. To do this, the driver registers the image load callback routine NotifyRoutine using\r\nPsSetLoadImageNotifyRoutine, which is used to execute:\r\nThe MainThread export from Client.dll, in context of the winlogon.exe process\r\nThe MainThread export from WinSys.dll, in context of the svchost.exe process\r\nNotifyRoutine hooks the entry point of the winlogon.exe and svchost.exe process images in memory before being\r\nexecuted; this hook is then responsible for loading and executing the appropriate payload DLL. As shown in Figure 10,\r\nonly the first svchost.exe or winlogon.exe image being loaded is processed by the routine.\r\nFigure 10. Hex-Rays decompiled NotifyRoutine checking if svchost.exe or winlogon.exe is being loaded\r\nUser-mode components – WinSys.dll\r\nWinSys.dll acts as a base update agent, which periodically contacts its C\u0026C server in order to download or execute\r\nadditional payloads or execute simple commands. The C\u0026C address, along with other values like campaign ID, bootkit\r\nversion, time between C\u0026C communication attempts and active hours range, are located in the configuration, which can\r\nbe loaded from:\r\nDefaultConfig value in HKLM\\SYSTEM\\CurrentControlSet\\Control registry\r\n\\SystemRoot\\Temp\\syslog file\r\nor directly from the specific disk sector (in the Legacy Boot version)\r\nIf both registry- and disk-stored configurations exist, the one from the registry is used.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 11 of 18\n\nC\u0026C communication\r\nWinSys.dll communicates with its C\u0026C using HTTPS and the communication is initiated by sending an HTTP GET\r\nrequest using the following URL format:\r\nhttps://\u003cip\u003e/Heart.aspx?ti=\u003cdrive_ID\u003e\u0026tn=\u003ccampaign_ID\u003e\u0026tg=\u003cnumber\u003e\u0026tv=\u003cmalware_version\u003e\r\nwhere drive_ID is the MD5 hash of the serial number of the main system volume and the other parameters are further\r\ninformation identifying this instance of the malware.\r\nAs a result, the C\u0026C can respond with the command ID represented as a string, optionally followed by command\r\nparameters. The full list of commands is available in Table 1.\r\nTable 1. WinSys component C\u0026C commands\r\nCommand ID Description URL\r\n1 or 4 Exit. -\r\n2\r\nUpload various system info (CPU name, OS\r\nversion, memory size, ethernet MAC address,\r\nlist of installed software, etc.) to the predefined\r\nURL using the HTTP POST.\r\nhttps://\u003cip\u003e/GetSysteminfo.aspx\r\n3\r\nDownload or download and execute file into one\r\nof the predefined locations (listed in IoCs ) from\r\nthe predefined URL using HTTP GET.\r\nhttps://\u003cip\u003e/UpLoad.aspx?ti=\u003cdrive_ID\u003e\r\n5\r\nRestart PC via ExitProcess (for Windows Vista\r\nonly).\r\nN/A\r\n6\r\nDownload new configuration from the\r\npredefined URL using HTTP GET and save it in\r\nthe registry.\r\nhttps://\u003cip\u003e/ModifyIpaddr.aspx?ti=\u003cdrive_ID\u003e\r\nUser-mode components – Client.dll\r\nThe second payload deployed by the malicious driver, if available, is Client.dll. It’s a backdoor that supports a rich set of\r\ncommands (Table 2) and contains various automatic data exfiltration capabilities including document stealing,\r\nkeylogging, and monitoring of the victim’s screen by periodically taking screenshots. All of the collected data is stored in\r\na hidden directory, with separate subdirectories for each data source – the full list of directory paths used is available from\r\nour GitHub repository. Also note that interception of the keyboard is handled by the driver and the client just needs to\r\nregister its logging function by sending IOCTL 0x22C004 to the driver’s device in order to save intercepted keystrokes to\r\nthe file (Figure 11).\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 12 of 18\n\nFigure 11. Client payload setting up keylogger function by sending IOCTL to the bootkit's device driver\r\nConfiguration for the Client component should be located in an encrypted form in the file’s overlay. It contains\r\ninformation such as the C\u0026C address and port, flags indicating what data should be collected (keystrokes, screenshots,\r\nfiles with specific extensions), time period for the screenshotting thread, maximum file size for exfiltrated data and a list\r\nof file extensions.\r\nC\u0026C communication\r\nThe client sets its own communication channel with the C\u0026C. For communication with the C\u0026C, it uses the TCP\r\nprotocol with single-byte XOR encryption applied to non-null message bytes that are different from the key, which was\r\n0x66 in the campaign analyzed here. Communication is initiated by sending beacon messages to the IP:PORT pair\r\nspecified in the configuration. This message contains the drive_ID value (the MD5 hash of the serial number of the main\r\nsystem volume) along with a value specifying the type of message – that is, a command request or the uploading of\r\ncollected data.\r\nAfter execution of the C\u0026C command, the result is reported back to the C\u0026C specifying the result code of the executed\r\noperation, command ID and, interestingly, each such resulting report message contains a watermark/tag representing the\r\nwide string WBKP located at offset 0x04, which makes it easier to identify this malicious communication at the network\r\nlevel.\r\nTable 2. List of Client C\u0026C commands\r\nCommand ID Description\r\n0x0000 Stop backdoor.\r\n0x0064 Execute command line received from C\u0026C and capture output using pipes.\r\n0x00C8\r\nExecute power commands logoff, power off, reboot, or shutdown, depending on the value of this\r\nC\u0026C command’s parameter.\r\n0x012C\r\nTake screenshot of foreground window, full screenshot, or change automatic screenshotting\r\nparameters, depending on the value of the parameter.\r\n0x0190 Execute various file system operations.\r\n0x01F4 Upload collected data and files.\r\n0x0258 Execute various service-related commands.\r\n0x02BC Execute various process-related commands.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 13 of 18\n\nCommand ID Description\r\n0x0320 Modify configuration values.\r\n0x0384 Stop/start keylogger, depending on the value of the parameter.\r\nConclusion\r\nESPecter shows that threat actors are relying not only on UEFI firmware implants when it comes to pre-OS persistence\r\nand, despite the existing security mechanisms like UEFI Secure Boot, invest their time into creating malware that would\r\nbe easily blocked by such mechanisms, if enabled and configured correctly.\r\nTo keep safe against threats similar to the ESPecter bootkit, make sure that:\r\nYou always use the latest firmware version.\r\nYour system is properly configured and Secure Boot is enabled.\r\nYou apply proper Privileged Account Management to help prevent adversaries from accessing privileged accounts\r\nnecessary for bootkit installation.\r\nIndicators of Compromise (IoCs)\r\nA comprehensive list of IoCs and samples can be found in our GitHub repository.\r\nESET detections\r\nEFI/Rootkit.ESPecter\r\nWin32/Rootkit.ESPecter\r\nWin64/Rootkit.ESPecter\r\nC\u0026C IP addresses and domains from configurations\r\n196.1.2[.]111\r\n103.212.69[.]175\r\n183.90.187[.]65\r\n61.178.79[.]69\r\nswj02.gicp[.]net\r\nserver.microsoftassistant[.]com\r\nyspark.justdied[.]com\r\ncrystalnba[.]com\r\nLegacy version installers\r\nABC03A234233C63330C744FDA784385273AF395B\r\nDCD42B04705B784AD62BB36E17305B6E6414F033\r\n656C263FA004BB3E6F3EE6EF6767D101869C7F7C\r\nA8B4FE8A421C86EAE060BB8BF525EF1E1FC133B2\r\n3AC6F9458A4A1A16390379621FDD230C656FC444\r\n9F6DF0A011748160B0C18FB2B44EBE9FA9D517E9\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 14 of 18\n\n2C22AE243FDC08B84B38D9580900A9A9E3823ACF\r\n08077D940F2B385FBD287D84EDB58493136C8391\r\n1D75BFB18FFC0B820CB36ACF8707343FA6679863\r\n37E49DBCEB1354D508319548A7EFBD149BFA0E8D\r\n7F501AEB51CE3232A979CCF0E11278346F746D1F\r\nCompromised Windows Boot Manager\r\n27AD0A8A88EAB01E2B48BA19D2AAABF360ECE5B8\r\n8AB33E432C8BEE54AE759DFB5346D21387F26902\r\nMITRE ATT\u0026CK techniques\r\nThis table was built using version 9 of the MITRE ATT\u0026CK framework.\r\nTactic ID Name Description\r\nExecution T1106 Native API\r\nESPecter leverages several Windows APIs: VirtualAlloc ,\r\nWriteProcessMemory, and CreateRemoteThread for process\r\ninjection.\r\nPersistence\r\nT1542.003 Pre-OS Boot: Bootkit\r\nESPecter achieves persistence by compromising Windows Boot\r\nManager (bootmgfw.efi) located on the ESP, or by modifying\r\nthe MBR on Legacy Boot systems.\r\nT1547\r\nBoot or Logon\r\nAutostart Execution\r\nESPecter replaces the legitimate null.sys or beep.sys driver with\r\nits own malicious one in order to be executed on system startup.\r\nDefense\r\nEvasion T1055.001\r\nProcess Injection:\r\nDynamic-link Library\r\nInjection\r\nESPecter’s driver injects its main user-mode components into\r\nsvchost.exe and winlogon.exe processes.\r\nT1564.001\r\nHide Artifacts: Hidden\r\nFiles and Directories\r\nESPecter’s Client.dll component creates hidden directories to\r\nstore collected data.\r\nT1564.005\r\nHide Artifacts: Hidden\r\nFile System\r\nESPecter bootkit installers for Legacy Boot versions use\r\nunallocated disk space located right after the MBR to store its\r\ncode, configuration and malicious driver.\r\nT1140\r\nDeobfuscate/Decode\r\nFiles or Information\r\nESPecter uses single-byte XOR with subtraction to decrypt\r\nuser-mode payloads.\r\nT1562 Impair Defenses\r\nESPecter patches Windows kernel function directly in memory\r\nto disable Driver Signature Enforcement (DSE).\r\nT1036.003\r\nMasquerading:\r\nRename System\r\nUtilities\r\nESPecter bootkit installers for Legacy Boot versions copy\r\ncmd.exe to con1866.exe to evade detection.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 15 of 18\n\nTactic ID Name Description\r\nT1112 Modify Registry\r\nESPecter can use DefaultConfig value under\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control to store\r\nconfiguration.\r\nT1601.001\r\nModify System Image:\r\nPatch System Image\r\nESPecter patches various functions in Windows Boot Manager,\r\nWindows OS loader and OS kernel directly in memory during\r\nthe boot process.\r\nT1027.002\r\nObfuscated Files or\r\nInformation: Software\r\nPacking\r\nESPecter’s WinSys.dll component is packed using the MPRESS\r\npacker.\r\nT1542.003 Pre-OS Boot: Bootkit\r\nESPecter achieves persistence by modifying Windows Boot\r\nManager (bootmgfw.efi) located on the ESP or by modifying\r\nthe MBR on Legacy Boot systems.\r\nT1553.006\r\nSubvert Trust\r\nControls: Code\r\nSigning Policy\r\nModification\r\nESPecter patches Windows kernel function\r\nSepInitializeCodeIntegrity directly in memory to disable Driver\r\nSignature Enforcement (DSE).\r\nT1497.003\r\nVirtualization/Sandbox\r\nEvasion: Time Based\r\nEvasion\r\nESPecter’s WinSys.dll component can be configured to\r\npostpone C\u0026C communication after execution or to\r\ncommunicate with the C\u0026C only in a specified time range.\r\nCredential\r\nAccess\r\nT1056.001\r\nInput Capture:\r\nKeylogging\r\nESPecter has a keylogging capability.\r\nDiscovery\r\nT1010\r\nApplication Window\r\nDiscovery\r\nESPecter’s Client.dll component reports foreground window\r\nnames along with keylogger information to provide application\r\ncontext.\r\nT1083\r\nFile and Directory\r\nDiscovery\r\nESPecter’s Client.dll component can list file information for\r\nspecific directories.\r\nT1120\r\nPeripheral Device\r\nDiscovery\r\nESPecter’s Client.dll component detects the insertion of new\r\ndevices by listening for the WM_DEVICECHANGE window\r\nmessage.\r\nT1057 Process Discovery\r\nESPecter’s Client.dll component can list running processes and\r\ntheir loaded modules.\r\nT1012 Query Registry\r\nESPecter’s WinSys.dll component can check for installed\r\nsoftware under the Registry key\r\nHKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall.\r\nT1082\r\nSystem Information\r\nDiscovery\r\nESPecter user-mode payloads can collect system information\r\nfrom the victim’s machine.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 16 of 18\n\nTactic ID Name Description\r\nT1124\r\nSystem Time\r\nDiscovery\r\nESPecter’s WinSys.dll component can use GetLocalTime for\r\ntime discovery.\r\nCollection\r\nT1119 Automated Collection\r\nESPecter’s Client.dll component can automatically collect\r\nscreenshots, intercepted keystrokes and various files.\r\nT1025\r\nData from Removable\r\nMedia\r\nESPecter’s Client.dll component can collect files with specified\r\nextension from removable drives.\r\nT1074.001\r\nData Staged: Local\r\nData Staging\r\nESPecter’s Client.dll component stores automatically collected\r\ndata into a hidden local directory.\r\nT1056.001\r\nInput Capture:\r\nKeylogging\r\nESPecter has keylogging functionality.\r\nT1113 Screen Capture\r\nESPecter’s Client.dll component has screen capture\r\nfunctionality.\r\nCommand\r\nand\r\nControl\r\nT1071.001\r\nApplication Layer\r\nProtocol: Web\r\nProtocols\r\nESPecter’s WinSys.dll component communicates with its C\u0026C\r\nserver over HTTPS.\r\nT1573.001\r\nEncrypted Channel:\r\nSymmetric\r\nCryptography\r\nESPecter’s Client.dll component encrypts C\u0026C traffic using\r\nsingle-byte XOR.\r\nT1105 Ingress Tool Transfer\r\nESPecter’s user-mode components can download additional\r\npayloads from C\u0026C.\r\nT1104 Multi-Stage Channels ESPecter’s user-mode components use separate C\u0026C channels.\r\nT1095\r\nNon-Application\r\nLayer Protocol\r\nESPecter’s Client.dll component uses TCP for C\u0026C\r\ncommunication.\r\nExfiltration T1020\r\nAutomated\r\nExfiltration\r\nESPecter’s Client.dll component creates a thread to\r\nautomatically upload collected data to the C\u0026C.\r\nT1041\r\nExfiltration\r\nOver C2\r\nChannel\r\nESPecter exfiltrates\r\ndata over the same\r\nchannel used for C\u0026C.\r\nT1029\r\nScheduled\r\nTransfer\r\nESPecter’s Client.dll\r\ncomponent is set to\r\nupload collected data\r\nto the C\u0026C every five\r\nseconds.\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 17 of 18\n\nSource: https://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/"
	],
	"report_names": [
		"uefi-threats-moving-esp-introducing-especter-bootkit"
	],
	"threat_actors": [],
	"ts_created_at": 1775791227,
	"ts_updated_at": 1775791337,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ea40707e4da15931b7ea144abdb1cc6f8c838980.pdf",
		"text": "https://archive.orkl.eu/ea40707e4da15931b7ea144abdb1cc6f8c838980.txt",
		"img": "https://archive.orkl.eu/ea40707e4da15931b7ea144abdb1cc6f8c838980.jpg"
	}
}