UEFI threats transferring to the ESP: Introducing ESPecter bootkit

UEFI threats moving to the ESP: Introducing ESPecter bootkit

ESET analysis discovers a beforehand undocumented UEFI bootkit with roots going again all the best way to not less than 2012

ESET researchers have analyzed a beforehand undocumented, real-world UEFI bootkit that persists on the EFI System Partition (ESP). The bootkit, which we’ve named ESPecter, can bypass Home windows Driver Signature Enforcement to load its personal unsigned driver, which facilitates its espionage actions. Alongside Kaspersky’s current discovery of the unrelated FinSpy bootkit, it’s now protected to say that real-world UEFI threats are now not restricted to SPI flash implants, as utilized by Lojax.

The times of UEFI (Unified Extensible Firmware Interface) residing within the shadows of the legacy BIOS are gone for good. As a number one know-how embedded into chips of contemporary computer systems and units, it performs an important function in securing the pre-OS setting and loading the working system. And it’s no shock that such a widespread know-how has additionally change into a tempting goal for risk actors of their seek for final persistence.

In the previous couple of years, we’ve got seen proof-of-concept examples of UEFI bootkits (DreamBoot, EfiGuard), leaked paperwork (DerStarke, QuarkMatter) and even leaked supply code (Hacking Staff Vector EDK), suggesting the existence of actual UEFI malware both within the type of SPI flash implants or ESP implants. Regardless of all the above, solely three real-world circumstances of UEFI malware have been found to date (LoJax, found by our crew in 2018, MosaicRegressor, found by Kaspersky in 2019, and most lately the FinSpy bootkit, whose evaluation was simply printed by Kaspersky). Whereas the primary two fall within the class of SPI flash implants, the final falls within the ESP implants class, and surprisingly, it’s not alone there.

At the moment, we describe our current discovery of ESPecter, simply the second real-world case of a UEFI bootkit persisting on the ESP within the type of a patched Home windows Boot Supervisor to be analyzed. ESPecter was encountered on a compromised machine together with a user-mode consumer part with keylogging and document-stealing functionalities, which is why we consider ESPecter is especially used for espionage. Curiously, we traced the roots of this risk again to not less than 2012, beforehand working as a bootkit for methods with legacy BIOSes. Regardless of ESPecter’s lengthy existence, its operations and improve to UEFI went unnoticed and haven’t been documented till now. Observe that the one similarity between ESPecter and the Kaspersky FinSpy discover is that they share the UEFI boot supervisor compromise method.

Determine 1. Comparability of the Legacy Boot circulation (left) and UEFI boot circulation (proper) on Home windows (Vista and newer) methods

By patching the Home windows Boot Supervisor, attackers obtain execution within the early phases of the system boot course of (see Determine 1), earlier than the working system is absolutely loaded. This permits ESPecter to bypass Home windows Driver Signature Enforcement (DSE) in an effort to execute its personal unsigned driver at system startup. This driver then injects different user-mode elements into particular system processes to provoke communication with ESPecter’s C&C server and to permit the attacker to take management of the compromised machine by downloading and working extra malware or executing C&C instructions.

Despite the fact that Safe Boot stands in the best way of executing untrusted UEFI binaries from the ESP, over the previous couple of years we’ve got been witness to numerous UEFI firmware vulnerabilities affecting hundreds of units that enable disabling or bypassing Safe Boot (e.g. VU#758382, VU#976132, VU#631788, …). This exhibits that securing UEFI firmware is a difficult process and that the best way varied distributors apply safety insurance policies and use UEFI companies is just not all the time ultimate.

Beforehand, we’ve got reported a number of malicious EFI samples within the type of easy, single-purpose UEFI functions with out intensive performance. These observations, together with the concurrent discovery of the ESPecter and FinFisher bootkits, each absolutely purposeful UEFI bootkits, present that risk actors should not relying solely on UEFI firmware implants in relation to pre-OS persistence, but in addition try to make the most of disabled Safe Boot to execute their very own ESP implants.

We weren’t in a position to attribute ESPecter to any recognized risk actor, however the Chinese language debug messages within the related user-mode consumer part (as seen in Determine 2) leads us to consider with a low confidence that an unknown Chinese language-speaking risk actor is behind ESPecter. At this level, we don’t know the way it was distributed.

Determine 2. Instance of Chinese language debug messages within the user-mode consumer part

Evolution of the ESPecter bootkit

Once we checked out our telemetry, we have been in a position to date the beginnings of this bootkit again to not less than 2012. At its starting, it used MBR (Grasp Boot File) modification as its persistence methodology and its authors have been constantly including help for brand spanking new Home windows OS variations. What’s attention-grabbing is that the malware’s elements have barely modified over all these years and the variations between 2012 and 2020 variations should not as important as one would anticipate.

After all of the years of insignificant adjustments, these behind ESPecter apparently determined to maneuver their malware from legacy BIOS methods to trendy UEFI methods. They determined to realize this by modifying a respectable Home windows Boot Supervisor binary (bootmgfw.efi) situated on the ESP whereas supporting a number of Home windows variations spanning Home windows 7 by way of Home windows 10 inclusive. As we talked about earlier, this methodology has one disadvantage – it requires that the Safe Boot function be disabled in an effort to efficiently boot with a modified boot supervisor. Nevertheless, it’s value mentioning that the primary Home windows model supporting Safe Boot was Home windows 8, which means that every one earlier variations are susceptible to this persistence methodology.

For Home windows OS variations that help Safe Boot, the attacker would want to disable it. For now, it’s unknown how the ESPecter operators achieved this, however there are a number of doable eventualities:

  • The attacker has bodily entry to the gadget (traditionally often known as an “evil maid” assault) and manually disables Safe Boot within the BIOS setup menu (it is not uncommon for the firmware configuration menu to nonetheless be labeled and known as the “BIOS setup menu”, even on UEFI methods).
  • Safe Boot was already disabled on the compromised machine (e.g., consumer may dual-boot Home windows and different OSes that don’t help Safe Boot).
  • Exploiting an unknown UEFI firmware vulnerability that permits disabling Safe Boot.
  • Exploiting a recognized UEFI firmware vulnerability within the case of an outdated firmware model or a no-longer-supported product.

Technical evaluation

Throughout our investigation, we found a number of malicious elements associated to ESPecter:

  • Installers, just for the older MBR variations of the bootkit, whose objective was to arrange persistence on the machine by rewriting the MBR of the boot gadget.
  • Boot code within the type of both a modified Home windows Boot Supervisor (bootmgfw.efi) on UEFI methods or a malicious MBR within the case of Legacy Boot methods.
  • A kernel-mode driver used to arrange the setting for the user-mode payloads and to load them within the early phases of OS startup by injecting them into particular system processes.
  • Person-mode payloads accountable for communication with the C&C, updating the C&C configuration and executing C&C instructions.

For the whole scheme of the ESPecter bootkit compromise, see Determine 3.

Determine 3. ESPecter bootkit elements

Attaining persistence – UEFI boot

On methods utilizing UEFI Boot mode, ESPecter persistence is established by modifying the Home windows Boot Supervisor bootmgfw.efi and the fallback bootloader binary bootx64.efi, that are often situated within the ESP directories EFIMicrosoftBoot and EFIBoot, respectively. Modification of the bootloader contains including a brand new part referred to as .efi to the PE, and altering the executable’s entry level tackle so program circulation jumps to the start of the added part, as seen in Determine 4.

Determine 4. Comparability of authentic (prime) and modified (backside) Home windows Boot Supervisor (bootmgfw.efi)

Simplified boot chain

As proven within the scheme on the left in Determine 5, the boot course of on UEFI methods (ignoring the firmware half) begins with execution of the bootloader utility situated within the ESP. For the Home windows OS, that is the Home windows Boot Supervisor binary (bootmgfw.efi) and its objective is to search out an put in working system and switch execution to its OS kernel loader – winload.efi. Just like the boot supervisor, the OS kernel loader is accountable for the loading and execution of the following part within the boot chain – the Home windows kernel (ntoskrnl.exe).

Determine 5. Boot circulation modified by ESPecter

How does ESPecter modify the UEFI boot course of?

In an effort to efficiently drop its malicious payload, ESPecter must bypass integrity checks carried out by the Home windows Boot Supervisor and the Home windows kernel in the course of the boot course of. To do that, it appears to be like for byte patterns figuring out the specified capabilities in reminiscence and patches them accordingly.

Beginning with the bootloader, in our case Home windows Boot Supervisor (bootmgfw.efi), the bootkit begins by patching the BmFwVerifySelfIntegrity operate. This operate is accountable for verification of the boot supervisor’s personal digital signature and is meant to stop execution of a modified boot supervisor. In Determine 6 you may see how ESPecter searches reminiscence for BmFwVerifySelfIntegrity utilizing varied byte patterns (to help many bootmgfw.efi variations) and modifies this operate in a method that it all the time returns zero, indicating that verification was profitable.

As talked about earlier, the bootloader’s principal purpose is to search out an put in working system and switch execution to its OS kernel loader. For the Home windows Boot Supervisor, this occurs within the Archpx64TransferTo64BitApplicationAsm operate; due to this fact, ESPecter appears to be like for this operate in an effort to catch the second that the OS loader is loaded into reminiscence, however nonetheless hasn’t been executed. If discovered, ESPecter patches this operate to insert its personal detour operate, which may simply modify the loaded OS loader in reminiscence on the proper second.

Determine 6. Hex-Rays decompiled code – looking for and patching the BmFwVerifySelfIntegrity operate

Modification of the OS loader doesn’t embody patching of any integrity checks or different performance. At this stage it’s vital for the bootkit to reallocate its code, as a result of as a UEFI Software it will likely be unloaded from reminiscence after coming back from its entry level operate. For this objective, it makes use of the BlImgAllocateImageBuffer or BlMmAllocateVirtualPages operate (relying on the sample discovered). After this reallocation, the bootkit inserts a detour (situated within the beforehand allotted buffer) to the operate accountable for transferring execution to the OS kernel – OslArchTransferToKernel – so it may well patch the Home windows kernel in reminiscence, as soon as it’s loaded however earlier than it’s executed. The ultimate stage of the bootkit’s boot code is accountable for disabling DSE by patching the SepInitializeCodeIntegrity kernel operate (see Determine 7 for particulars).

Determine 7. Comparability of Hex-Rays decompiled SepInitializeCodeIntegrity operate earlier than (left) and after (proper) it’s patched in reminiscence

Curiously, the boot code additionally patches the MiComputeDriverProtection kernel operate. Despite the fact that this operate doesn’t immediately have an effect on profitable loading of the malicious driver, the bootkit doesn’t proceed to the motive force dropping if it doesn’t discover and patch this operate in kernel reminiscence. We weren’t in a position to establish the aim of this second patch, however we assume this modified operate could also be utilized by different, as but unknown, ESPecter elements.

  • SystemRootSystem32null.sys (driver)
  • SystemRootTempsyslog (encrypted configuration)

The configuration is utilized by the WinSys.dll user-mode part deployed by the kernel driver and consists of a one-byte XOR key adopted by the encrypted configuration knowledge. To decrypt the configuration, WinSys.dll:

  1. Base64 decodes the configuration knowledge
  2. XORs the information with the XOR key
  3. Base64 decodes every worth delimited by “|” individually

An instance of a configuration dropped by the EFI model of ESPecter is introduced in Determine 8. A full listing of IP addresses and domains from configurations embedded within the ESPecter bootkit samples that we’ve got found (each Legacy Boot and UEFI variations) is included within the IoCs part.

Determine 8. Decryption of configuration delivered by the EFI model of the ESPecter bootkit

Attaining persistence – Legacy Boot

As already talked about, there are ESPecter variations supporting UEFI, and others supporting Legacy Boot, modes. Within the case of Legacy Boot mode, persistence is achieved by the well-known strategy of modifying the MBR code situated within the first bodily sector of the disk drive; due to this fact, we received’t clarify it intimately right here, however will simply summarize it.

How does ESPecter modify the Legacy Boot course of?

The malicious MBR first decrypts code beforehand copied to disk sectors 2, 3 and 4 by the installer, hooks the real-mode INT13h (BIOS sector read-write companies) interrupt handler after which passes execution to the unique MBR code, backed as much as the second sector (sector 1) by the installer. Just like different recognized MBR bootkits, when the INT13h interrupt handler is invoked, hook code (situated in sector 0) checks for service 0x02 (Learn sectors from drive) and 0x42 (Prolonged learn sectors from drive) being dealt with in an effort to intercept loading of bootmgr – the legacy model of the Home windows Boot Supervisor. Observe that ESPecter legacy variations don’t must patch the BmFwVerifySelfIntegrity operate in bootmgr, as a result of the bootmgr binary wasn’t modified in any method.

From this level, the performance of the boot code is nearly the identical as within the UEFI model, leading to dropping the malicious driver (situated contiguously on Monitor 0, beginning at sector 6) into one of many following places, relying on the structure:

  • SystemRootSystem32driversbeep.sys (x86)
  • SystemRootSystem32driversnull.sys (x64)

On this case, the encrypted configuration is just not dropped to the syslog file however stays hidden in sector 5 of the compromised disk.

Determine 9. Modified disk scheme utilized by the legacy ESPecter model

Kernel-mode driver

The driving force’s principal objective is to load user-mode payloads, arrange the keylogger and, in the long run, delete itself. Organising the keylogger is finished in two steps:

  • At first, it creates a tool named DeviceWebBK that exposes a operate dealing with IRP_MJ_DEVICE_CONTROL requests from the user-mode elements. This operate helps one IOCTL (Enter/Output Management) code (0x22C004), which can be utilized to set off registration of an asynchronous process name routine accountable for processing intercepted keystrokes.
  • Interception of keystrokes is finished by organising CompletionRoutine for IRP_MJ_READ requests for the keyboard driver object DeviceKeyboardClass0.

When performed, any course of can begin logging intercepted keystrokes by defining its personal routine and passing it to the created gadget object utilizing the customized IOCTL 0x22C004.

By default, the motive force tries to load two base payloads – WinSys.dll and Consumer.dllwhich have the flexibility to obtain and execute extra payloads. The primary one, WinSys.dll, is an MPRESS-packed DLL embedded within the driver’s binary in an encrypted kind. The second, Consumer.dll, is downloaded by WinSys.dll to the file SystemRootTempmemlog, additionally in an encrypted kind, utilizing the identical encryption methodology – a easy one-byte XOR with subtraction – however not the identical keys. Each libraries are decrypted and dropped to the system listing SystemRootSystem32 by the motive force.

Execution of each WinSys.dll and Consumer.dll libraries is achieved by injecting them into svchost.exe and winlogon.exe, respectively. To do that, the motive force registers the picture load callback routine NotifyRoutine utilizing PsSetLoadImageNotifyRoutine, which is used to execute:

  • The MainThread export from Consumer.dll, in context of the winlogon.exe course of
  • The MainThread export from WinSys.dll, in context of the svchost.exe course of

NotifyRoutine hooks the entry level of the winlogon.exe and svchost.exe course of photos in reminiscence earlier than being executed; this hook is then accountable for loading and executing the suitable payload DLL. As proven in Determine 10, solely the primary svchost.exe or winlogon.exe picture being loaded is processed by the routine.

Determine 10. Hex-Rays decompiled NotifyRoutine checking if svchost.exe or winlogon.exe is being loaded

Person-mode elements – WinSys.dll

WinSys.dll acts as a base replace agent, which periodically contacts its C&C server in an effort to obtain or execute extra payloads or execute easy instructions. The C&C tackle, together with different values like marketing campaign ID, bootkit model, time between C&C communication makes an attempt and energetic hours vary, are situated within the configuration, which could be loaded from:

  • DefaultConfig worth in HKLMSYSTEMCurrentControlSetControl registry
  • SystemRootTempsyslog file
  • or immediately from the precise disk sector (within the Legacy Boot model)

If each registry- and disk-stored configurations exist, the one from the registry is used.

C&C communication

WinSys.dll communicates with its C&C utilizing HTTPS and the communication is initiated by sending an HTTP GET request utilizing the next URL format:

https://<ip>/Coronary heart.aspx?ti=<drive_ID>&tn=<campaign_ID>&tg=<quantity>&television=<malware_version>

the place drive_ID is the MD5 hash of the serial variety of the principle system quantity and the opposite parameters are additional info figuring out this occasion of the malware.

Consequently, the C&C can reply with the command ID represented as a string, optionally adopted by command parameters. The complete listing of instructions is obtainable in Desk 1.

Desk 1. WinSys part C&C instructions

Command ID Description URL
1 or 4 Exit.
2 Add varied system data (CPU identify, OS model, reminiscence dimension, ethernet MAC tackle, listing of put in software program, and so forth.) to the predefined URL utilizing the HTTP POST. https://<ip>/GetSysteminfo.aspx
3 Obtain or obtain and execute file into one of many predefined places (listed in IoCs ) from the predefined URL utilizing HTTP GET. https://<ip>/UpLoad.aspx?ti=<drive_ID>
5 Restart PC by way of ExitProcess (for Home windows Vista solely). N/A
6 Obtain new configuration from the predefined URL utilizing HTTP GET and reserve it within the registry. https://<ip>/ModifyIpaddr.aspx?ti=<drive_ID>

Person-mode elements – Consumer.dll

The second payload deployed by the malicious driver, if out there, is Consumer.dll. It’s a backdoor that helps a wealthy set of instructions (Desk 2) and incorporates varied automated knowledge exfiltration capabilities together with doc stealing, keylogging, and monitoring of the sufferer’s display screen by periodically taking screenshots. The entire collected knowledge is saved in a hidden listing, with separate subdirectories for every knowledge supply – the total listing of listing paths used is obtainable from our GitHub repository. Additionally notice that interception of the keyboard is dealt with by the motive force and the consumer simply must register its logging operate by sending IOCTL 0x22C004 to the motive force’s gadget in an effort to save intercepted keystrokes to the file (Determine 11).

Determine 11. Consumer payload organising keylogger operate by sending IOCTL to the bootkit’s gadget driver

Configuration for the Consumer part needs to be situated in an encrypted kind within the file’s overlay. It incorporates info such because the C&C tackle and port, flags indicating what knowledge needs to be collected (keystrokes, screenshots, information with particular extensions), time interval for the screenshotting thread, most file dimension for exfiltrated knowledge and an inventory of file extensions.

C&C communication

The consumer units its personal communication channel with the C&C. For communication with the C&C, it makes use of the TCP protocol with single-byte XOR encryption utilized to non-null message bytes which are completely different from the important thing, which was 0x66 within the marketing campaign analyzed right here. Communication is initiated by sending beacon messages to the IP:PORT pair specified within the configuration. This message incorporates the drive_ID worth (the MD5 hash of the serial variety of the principle system quantity) together with a price specifying the kind of message – that’s, a command request or the importing of collected knowledge.

After execution of the C&C command, the result’s reported again to the C&C specifying the end result code of the executed operation, command ID and, curiously, every such ensuing report message incorporates a watermark/tag representing the extensive string WBKP situated at offset 0x04, which makes it simpler to establish this malicious communication on the community stage.

Desk 2. Checklist of Consumer C&C instructions

Command ID Description
0x0000 Cease backdoor.
0x0064 Execute command line obtained from C&C and seize output utilizing pipes.
0x00C8 Execute energy instructions logoff, energy off, reboot, or shutdown, relying on the worth of this C&C command’s parameter.
0x012C Take screenshot of foreground window, full screenshot, or change automated screenshotting parameters, relying on the worth of the parameter.
0x0190 Execute varied file system operations.
0x01F4 Add collected knowledge and information.
0x0258 Execute varied service-related instructions.
0x02BC Execute varied process-related instructions.
0x0320 Modify configuration values.
0x0384 Cease/begin keylogger, relying on the worth of the parameter.


ESPecter exhibits that risk actors are relying not solely on UEFI firmware implants in relation to pre-OS persistence and, regardless of the prevailing safety mechanisms like UEFI Safe Boot, make investments their time into creating malware that will be simply blocked by such mechanisms, if enabled and configured appropriately.

To maintain protected towards threats much like the ESPecter bootkit, ensure that:

  • You all the time use the newest firmware model.
  • Your system is correctly configured and Safe Boot is enabled.
  • You apply correct Privileged Account Administration to assist forestall adversaries from accessing privileged accounts needed for bootkit set up.

Indicators of Compromise (IoCs)

A complete listing of IoCs and samples could be present in our GitHub repository.

ESET detections


C&C IP addresses and domains from configurations


Legacy model installers


Compromised Home windows Boot Supervisor


MITRE ATT&CK strategies

This desk was constructed utilizing model 9 of the MITRE ATT&CK framework.

Tactic ID Identify Description
Execution T1106 Native API ESPecter leverages a number of Home windows APIs: VirtualAlloc , WriteProcessMemory, and CreateRemoteThread for course of injection.
Persistence T1542.003 Pre-OS Boot: Bootkit ESPecter achieves persistence by compromising Home windows Boot Supervisor (bootmgfw.efi) situated on the ESP, or by modifying the MBR on Legacy Boot methods.
T1547 Boot or Logon Autostart Execution ESPecter replaces the respectable null.sys or beep.sys driver with its personal malicious one in an effort to be executed on system startup.
Protection Evasion T1055.001 Course of Injection: Dynamic-link Library Injection ESPecter’s driver injects its principal user-mode elements into svchost.exe and winlogon.exe processes.
T1564.001 Conceal Artifacts: Hidden Recordsdata and Directories ESPecter’s Consumer.dll part creates hidden directories to retailer collected knowledge.
T1564.005 Conceal Artifacts: Hidden File System ESPecter bootkit installers for Legacy Boot variations use unallocated disk area situated proper after the MBR to retailer its code, configuration and malicious driver.
T1140 Deobfuscate/Decode Recordsdata or Info ESPecter makes use of single-byte XOR with subtraction to decrypt user-mode payloads.
T1562 Impair Defenses ESPecter patches Home windows kernel operate immediately in reminiscence to disable Driver Signature Enforcement (DSE).
T1036.003 Masquerading: Rename System Utilities ESPecter bootkit installers for Legacy Boot variations copy cmd.exe to con1866.exe to evade detection.
T1112 Modify Registry ESPecter can use DefaultConfig worth underneath HKLMSYSTEMCurrentControlSetControl to retailer configuration.
T1601.001 Modify System Picture: Patch System Picture ESPecter patches varied capabilities in Home windows Boot Supervisor, Home windows OS loader and OS kernel immediately in reminiscence in the course of the boot course of.
T1027.002 Obfuscated Recordsdata or Info: Software program Packing ESPecter’s WinSys.dll part is packed utilizing the MPRESS packer.
T1542.003 Pre-OS Boot: Bootkit ESPecter achieves persistence by modifying Home windows Boot Supervisor (bootmgfw.efi) situated on the ESP or by modifying the MBR on Legacy Boot methods.
T1553.006 Subvert Belief Controls: Code Signing Coverage Modification ESPecter patches Home windows kernel operate SepInitializeCodeIntegrity immediately in reminiscence to disable Driver Signature Enforcement (DSE).
T1497.003 Virtualization/Sandbox Evasion: Time Based mostly Evasion ESPecter’s WinSys.dll part could be configured to postpone C&C communication after execution or to speak with the C&C solely in a specified time vary.
Credential Entry T1056.001 Enter Seize: Keylogging ESPecter has a keylogging functionality.
Discovery T1010 Software Window Discovery ESPecter’s Consumer.dll part studies foreground window names together with keylogger info to supply utility context.
T1083 File and Listing Discovery ESPecter’s Consumer.dll part can listing file info for particular directories.
T1120 Peripheral Gadget Discovery ESPecter’s Consumer.dll part detects the insertion of latest units by listening for the WM_DEVICECHANGE window message.
T1057 Course of Discovery ESPecter’s Consumer.dll part can listing working processes and their loaded modules.
T1012 Question Registry ESPecter’s WinSys.dll part can test for put in software program underneath the Registry key HKLMSoftwareMicrosoftWindowsCurrentVersionUninstall.
T1082 System Info Discovery ESPecter user-mode payloads can acquire system info from the sufferer’s machine.
T1124 System Time Discovery ESPecter’s WinSys.dll part can use GetLocalTime for time discovery.
Assortment T1119 Automated Assortment ESPecter’s Consumer.dll part can robotically acquire screenshots, intercepted keystrokes and varied information.
T1025 Knowledge from Detachable Media ESPecter’s Consumer.dll part can acquire information with specified extension from detachable drives.
T1074.001 Knowledge Staged: Native Knowledge Staging ESPecter’s Consumer.dll part shops robotically collected knowledge right into a hidden native listing.
T1056.001 Enter Seize: Keylogging ESPecter has keylogging performance.
T1113 Display screen Seize ESPecter’s Consumer.dll part has display screen seize performance.
Command and Management T1071.001 Software Layer Protocol: Internet Protocols ESPecter’s WinSys.dll part communicates with its C&C server over HTTPS.
T1573.001 Encrypted Channel: Symmetric Cryptography ESPecter’s Consumer.dll part encrypts C&C site visitors utilizing single-byte XOR.
T1105 Ingress Instrument Switch ESPecter’s user-mode elements can obtain extra payloads from C&C.
T1104 Multi-Stage Channels ESPecter’s user-mode elements use separate C&C channels.
T1095 Non-Software Layer Protocol ESPecter’s Consumer.dll part makes use of TCP for C&C communication.
Exfiltration T1020 Automated Exfiltration ESPecter’s Consumer.dll part creates a thread to robotically add collected knowledge to the C&C.
T1041 Exfiltration Over C2 Channel ESPecter exfiltrates knowledge over the identical channel used for C&C.
T1029 Scheduled Switch ESPecter’s Consumer.dll part is about to add collected knowledge to the C&C each 5 seconds.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts