UEFI threats shifting 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 analyze 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 latest discovery of the unrelated FinSpy bootkit, it’s now protected to say that real-world UEFI threats are not restricted to SPI flash implants, as utilized by Lojax.

The times of UEFI (Unified Extensible Firmware Interface) dwelling 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 a vital position in securing the pre-OS setting and loading the working system. And it’s no shock that such a widespread know-how has additionally develop into a tempting goal for menace actors of their seek for final persistence.

In the previous couple of years, now we have seen proofs of idea 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 this point (LoJax, found by our workforce 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.

Right now, we describe our latest 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 shopper part with keylogging and document-stealing functionalities, which is why we imagine ESPecter is especially used for espionage. Curiously, we traced the roots of this menace 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 levels of the system boot course of (see Determine 1), earlier than the working system is absolutely loaded. This enables ESPecter to bypass Home windows Driver Signature Enforcement (DSE) so as 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 further malware or executing C&C instructions.

Regardless that Safe Boot stands in the best way of executing untrusted UEFI binaries from the ESP, over the previous couple of years now we have been witness to varied UEFI firmware vulnerabilities affecting hundreds of units that permit 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 numerous distributors apply safety insurance policies and use UEFI companies isn’t all the time supreme.

Beforehand, now we have reported a number of malicious EFI samples within the type of easy, single-purpose UEFI purposes with out intensive performance. These observations, together with the concurrent discovery of the ESPecter and FinFisher bootkits, each absolutely useful UEFI bootkits, present that menace actors are usually not relying solely on UEFI firmware implants with regards to pre-OS persistence, but in addition are attempting to benefit from disabled Safe Boot to execute their very own ESP implants.

We weren’t in a position to attribute ESPecter to any recognized menace actor, however the Chinese language debug messages within the related user-mode shopper part (as seen in Determine 2) leads us to imagine with a low confidence that an unknown Chinese language-speaking menace 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 shopper part

Evolution of the ESPecter bootkit

After we checked out our telemetry, we had 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 technique and its authors had been constantly including help for brand 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 are usually not as vital as one would count on.

After all of the years of insignificant modifications, 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 professional Home windows Boot Supervisor binary (bootmgfw.efi) situated on the ESP whereas supporting a number of Home windows variations spanning Home windows 7 by means of Home windows 10 inclusive. As we talked about earlier, this technique has one downside – it requires that the Safe Boot function be disabled so as to efficiently boot with a modified boot supervisor. Nonetheless, it’s price mentioning that the primary Home windows model supporting Safe Boot was Home windows 8, that means that every one earlier variations are susceptible to this persistence technique.

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 attainable situations:

  • The attacker has bodily entry to the gadget (traditionally referred to as an “evil maid” assault) and manually disables Safe Boot within the BIOS setup menu (it’s common 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., person may dual-boot Home windows and different OSes that don’t help Safe Boot).
  • Exploiting an unknown UEFI firmware vulnerability that enables 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 function 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 organize the setting for the user-mode payloads and to load them within the early levels of OS startup by injecting them into particular system processes.
  • Consumer-mode payloads liable for communication with the C&C, updating the C&C configuration and executing C&C instructions.

For the whole scheme of the ESPecter bootkit an infection 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 normally 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 deal with so program circulation jumps to the start of the added part, as seen in Determine 4.

Determine 4. Comparability of unique (high) 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 function 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 liable for the loading and execution of the following part within the boot chain – the Home windows kernel (ntoskrnl.exe).

Determine 5. Typical Home windows UEFI boot circulation (left) in comparison with the boot circulation modified by ESPecter (proper)

How does ESPecter modify the UEFI boot course of?

With a purpose to efficiently drop its malicious payload, ESPecter must bypass integrity checks carried out by the Home windows Boot Supervisor and the Home windows kernel throughout the boot course of. To do that, it seems to be for byte patterns figuring out the specified features 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 liable 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 possibly can see how ESPecter searches reminiscence for BmFwVerifySelfIntegrity utilizing numerous byte patterns (to help many bootmgfw.efi variations) and modifies this operate in a approach that it all the time returns zero, indicating that verification was profitable.

As talked about earlier, the bootloader’s principal aim 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 seems to be for this operate so as 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 – trying to find 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 is going to be unloaded from reminiscence after getting back from its entry level operate. For this function, 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 liable for transferring execution to the OS kernel – OslArchTransferToKernel – so it may 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 liable 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. Regardless that this operate doesn’t instantly 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 determine 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 information. To decrypt the configuration, WinSys.dll:

  1. Base64 decodes the configuration information
  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 offered in Determine 8. A full checklist of IP addresses and domains from configurations embedded within the ESPecter bootkit samples that now we have 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 so as 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 approach.

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 isn’t dropped to the syslog file however stays hidden in sector 5 of the contaminated disk.

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

Kernel-mode driver

The motive force’s principal function is to load user-mode payloads, arrange the keylogger and, ultimately, delete itself. Establishing 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 liable for processing intercepted keystrokes.
  • Interception of keystrokes is finished by organising CompletionRoutine for IRP_MJ_READ requests for the keyboard driver object DeviceKeyboardClass0.

When executed, 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 further 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 the WinSys.dll to the file SystemRootTempmemlog, additionally in an encrypted kind, utilizing the identical encryption technique – 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 liable 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

Consumer-mode elements – WinSys.dll

WinSys.dll acts as a base replace agent, which periodically contacts its C&C server so as to obtain or execute further payloads or execute easy instructions. The C&C deal with, 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 may be loaded from:

  • DefaultConfig worth in HKLMSYSTEMCurrentControlSetControl registry
  • SystemRootTempsyslog file
  • or instantly from the particular 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 data figuring out this occasion of the malware.

In consequence, the C&C can reply with the command ID represented as a string, optionally adopted by command parameters. The total checklist of instructions is on the market in Desk 1.

Desk 1. WinSys part C&C instructions

Command ID Description URL
1 or 4 Exit.
2 Add numerous system data (CPU title, OS model, reminiscence dimension, ethernet MAC deal with, checklist of put in software program, and many others.) 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 put it aside within the registry. https://<ip>/ModifyIpaddr.aspx?ti=<drive_ID>

Consumer-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 numerous automated information exfiltration capabilities together with doc stealing, keylogging, and monitoring of the sufferer’s display screen by periodically taking screenshots. All the collected information is saved in a hidden listing, with separate subdirectories for every information supply – the complete checklist of listing paths used is on the market from our GitHub repository. Additionally be aware that interception of the keyboard is dealt with by the motive force and the shopper simply must register its logging operate by sending IOCTL 0x22C004 to the motive force’s gadget so as 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 data such because the C&C deal with and port, flags indicating what information needs to be collected (keystrokes, screenshots, information with particular extensions), time interval for the screenshotting thread, most file dimension for exfiltrated information and an inventory of file extensions.

C&C communication

The shopper 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 worth specifying the kind of message – that’s, a command request or the importing of collected information.

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 large string WBKP situated at offset 0x04, which makes it simpler to determine this malicious communication on the community stage.

Desk 2. Listing of Consumer C&C instructions

Command ID Description
0x0000 Cease backdoor.
0x0064 Execute command line acquired 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 numerous file system operations.
0x01F4 Add collected information and information.
0x0258 Execute numerous service-related instructions.
0x02BC Execute numerous process-related instructions.
0x0320 Modify configuration values.
0x0384 Cease/begin keylogger, relying on the worth of the parameter.


ESPecter exhibits that menace actors are relying not solely on UEFI firmware implants with regards 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, guarantee 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 stop adversaries from accessing privileged accounts needed for bootkit set up.

Indicators of Compromise (IoCs)

A complete checklist of IoCs and samples may 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 infecting 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 professional null.sys or beep.sys driver with its personal malicious one so as 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 Cover Artifacts: Hidden Information and Directories ESPecter’s Consumer.dll part creates hidden directories to retailer collected information.
T1564.005 Cover 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 Information or Data ESPecter makes use of single-byte XOR with subtraction to decrypt user-mode payloads.
T1562 Impair Defenses ESPecter patches Home windows kernel operate instantly in reminiscence to disable 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 beneath HKLMSYSTEMCurrentControlSetControl to retailer configuration.
T1601.001 Modify System Picture: Patch System Picture ESPecter patches numerous features in Home windows Boot Supervisor, Home windows OS loader and OS kernel instantly in reminiscence throughout the boot course of.
T1027.002 Obfuscated Information or Data: 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 instantly in reminiscence to disable DSE.
T1497.003 Virtualization/Sandbox Evasion: Time Primarily based Evasion ESPecter’s WinSys.dll part may 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 data to offer utility context.
T1083 File and Listing Discovery ESPecter’s Consumer.dll part can checklist file data for particular directories.
T1120 Peripheral Machine Discovery ESPecter’s Consumer.dll part detects the insertion of recent units by listening for the WM_DEVICECHANGE window message.
T1057 Course of Discovery ESPecter’s Consumer.dll part can checklist working processes and their loaded modules.
T1012 Question Registry ESPecter’s WinSys.dll part can verify for put in software program beneath the Registry key HKLMSoftwareMicrosoftWindowsCurrentVersionUninstall.
T1082 System Data Discovery ESPecter user-mode payloads can gather system data 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 routinely gather screenshots, intercepted keystrokes and numerous information.
T1025 Knowledge from Detachable Media ESPecter’s Consumer.dll part can gather information with specified extension from detachable drives.
T1074.001 Knowledge Staged: Native Knowledge Staging ESPecter’s Consumer.dll part shops routinely collected information right into a hidden native listing.
T1056.001 Enter Seize: Keylogging ESPecter has keylogging performance.
T1113 Display 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 Software Switch ESPecter’s user-mode elements can obtain further 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 routinely add collected information to the C&C.
T1041 Exfiltration Over C2 Channel ESPecter exfiltrates information over the identical channel used for C&C.
T1029 Scheduled Switch ESPecter’s Consumer.dll part is ready to add collected information to the C&C each 5 seconds.

Leave a Reply

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

Related Posts