{
	"id": "709bc263-437b-47b0-8949-85817ca1825b",
	"created_at": "2026-04-06T00:16:13.712655Z",
	"updated_at": "2026-04-10T03:35:34.357432Z",
	"deleted_at": null,
	"sha1_hash": "0d148b307aa8c0170a846997e316f35e90f2a1f0",
	"title": "Conti Targets Critical Firmware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 842715,
	"plain_text": "Conti Targets Critical Firmware\r\nBy Ariella Robison\r\nPublished: 2022-06-02 · Archived: 2026-04-05 13:11:48 UTC\r\nIntroduction\r\nIn late February of this year, an unknown individual began leaking internal information and communications from\r\nthe notorious Conti ransomware organization. These leaks appear to confirm the long-suspected connections\r\nbetween Conti and the Russian FSB, and provide key insight into the development of new threats and techniques.\r\nNotably, these leaked chats exposed a new front in the ongoing evolution of firmware-based attacks. In addition to\r\nclassical attacks that target UEFI/BIOS directly, attackers are now targeting the Intel Management Engine (ME) or\r\nIntel Converged Security Management Engine (CSME). ME is a physical microcontroller that is part of the\r\nchipset of modern Intel-based systems. It supports a variety of capabilities such as out-of-band management.\r\nThere are several different variations of this component to be aware of, Management Engine (before Skylake, also\r\nsometimes known as Intel Manageability Engine), Intel Converged Security and Management Engine (Skylake\r\nand newer), Intel Trusted Execution Environment (Atom platforms). In addition, there’s an alternate firmware\r\nfamily used in servers known as Server Platform Services. But in general, all of these refer to an out-of-band\r\nmanagement processor which is built into the Intel chipset and runs independently from the CPU(s). For\r\nsimplicity, we’ll use the term ME firmware or simply, the chipset, to refer to this set of Intel management\r\nprocessors. \r\nIt is important to note that no new or unmitigated vulnerabilities have been identified and that Intel chipsets are no\r\nmore or less vulnerable than any other code. The issue is that most organizations do not update their chipset\r\nfirmware with the same regularity that they do their software or even the UEFI/BIOS system firmware. This can\r\nleave some of the most powerful and privileged code on a device susceptible to attack.\r\nCompromising the Management Engine of a system would have considerable value on its own, but the leaks show\r\nthat the group is using the unique privileges of the ME firmware as a way to gain indirect access to the\r\nUEFI/BIOS, drop additional payloads, and gain runtime control of the system below the operating system using\r\nSystem Management Mode (SMM). Such level of access would allow an adversary to cause irreparable damage to\r\na system or to establish ongoing persistence that is virtually invisible to the operating system.\r\nLeaked conversations indicate that the Conti group had already developed proof-of-concept code for these\r\nmethods nine months ago. We expect that these techniques will be used in the wild in the near future if they\r\nhaven’t already so we wanted to share our insight into ME firmware in order to help organizations make better\r\nthreat and impact-informed security decisions. Analysis includes:\r\nChipset Vulnerabilities – While it is known that these adversaries are actively analyzing the ME for new\r\nvulnerabilities, we wanted to identify the known vulnerabilities that attackers could use so that\r\norganizations can reduce their firmware attack surface.\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 1 of 12\n\nAttack Flow and Scenarios – We show different attack scenarios based on the low-level settings and\r\nprotections set on a system, including in cases where the BIOS is properly write-protected.\r\nAttacker Objectives and Impact Analysis – Review of how attackers can use the ME and system\r\nfirmware to achieve the greatest possible damage and impact to target organizations.\r\nMitigations and Best Practices – Key steps that organizations should be taking today to defend their\r\ndevices from these and similar threats.\r\nAbout Intel ME and AMT:\r\nAs defined by Intel, the Intel® Management Engine (ME) is “an embedded microcontroller (integrated on some\r\nIntel chipsets) running a lightweight microkernel operating system that provides a variety of features and services\r\nfor Intel® processor–based computer systems” including out-of-band management services. These remote\r\nmanagement capabilities enabled by the ME are known as Intel Active Management Technology (AMT). Thus the\r\nME is the physical controller and AMT is one of the services provided by the ME.\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 2 of 12\n\nThe ME portion of the chipset is conceptually similar to the baseboard management controllers (BMCs) used for\r\nout-of-band management of enterprise servers. In addition to having its own kernel, ME has access to its own\r\nflash memory stored in the SPI (which also contains the UEFI/BIOS), a dedicated connection to the network\r\ninterface, and has power that is independent of the operating system. These capabilities allow “the Intel®\r\nManagement Engine to be up before the main operating system is started,” and to “respond to OOB commands\r\nfrom the IT management console without having to wake up the rest of the system.” And while ME/CSME are\r\nconceptually similar to a BMC, it is important to note that these components are integrated into a very wide range\r\nof devices, enabling attacks that would be far more scalable and generic than BMC attacks.\r\nHow Adversaries are Targeting Chipset and UEFI Firmware\r\nAnalysis of internal Conti communications revealed that attackers were deeply investigating vulnerabilities related\r\nto ME firmware as well as BIOS_WP (BIOS Write Protection). This is a significant change in tactics from the\r\nmost recent firmware threats. For example, well-known firmware threats such as TrickBoot, MosaicRegressor, and\r\nLoJax all looked for a well-known vulnerability resulting from the misconfiguration of the BIOS Control register\r\nin the SPI controller as a way of writing the SPI and manipulating the UEFI/BIOS firmware of the device.\r\nHowever, this vulnerability is well known and often patched. By shifting focus to Intel ME as well as targeting\r\ndevices in which the BIOS is write protected, attackers could easily find far more available target devices.\r\nOur analysis found that Conti was focusing research in the following areas.\r\n1. Fuzzing the Management Engine Interface and finding undocumented commands and vulnerabilities. Note\r\nthat the Management Engine Interface (MEI) was previously named the Host Embedded Controller\r\nInterface (HECI) and is referred to as HECI within the exposed chats, but both names are still commonly\r\nused.\r\n2. Attempting to access SPI (the flash memory used by the UEFI/BIOS system firmware) from the ME in\r\norder to generically bypass other protections. Provisioning AMT or changing other ME configurations\r\nfrom the host could expose ME vulnerabilities, leading to code execution. With code execution in the ME,\r\naccess to SPI flash and other resources can bypass the usual protections.\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 3 of 12\n\n3. They are considering not only a dropper (placing malware on the host OS) from UEFI but also a System\r\nManagement Mode (SMM) implant. SMM is a runtime CPU mode controlled by the UEFI/BIOS that is\r\nmore privileged than the “Ring-0” operating system kernel. The operating system kernel doesn’t have the\r\nability to examine SMM code or block it from executing. As a result, an SMM implant could modify the\r\nkernel on the fly with complete stealth and without the OS being able to do anything to prevent it.\r\nExcerpts from the chat below illustrate the progression of Conti’s investigations and development of proof-of-concept (POC) code.\r\nTranslated chat discussing the research and proof-of-concept development of using ME to rewrite flash and\r\ngain SMM execution.\r\nChats confirming completion of POC for SMM.\r\nDeep Analysis and Threat Modeling\r\nBased on the available insights into attacker goals and methods, the Eclypsium team aimed to dig deeper to\r\nunderstand how a real-world attack would take place. There are several aspects to consider, but at a very high\r\nlevel we can look at an attack as three important phases.\r\n1. Attacker gains access to a target host – This can be done via any number of common methods (either\r\nlocal or remote), whether via spear-phishing, exploiting a common OS or application vulnerability, an\r\ninsider, or during any phase of the distribution, warehousing, or delivery phase of the device’s supply chain\r\nlifecycle.\r\n2. Attacker gains control over ME – This would be done either by a new 0-day vulnerability or via known\r\nvulnerabilities that provide remote code execution (RCE) and privilege escalation (PE). Because some of\r\nthe ME vulnerabilities can be exploited remotely, this can make the previous step optional and an attacker\r\ncan directly gain control of the ME without first exploiting a vulnerability in the host side of the platform.\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 4 of 12\n\n3. Use ME to rewrite UEFI/BIOS or gain SMM Execution – The ME firmware is inside the UEFI Trusted\r\nComputing Base (TCB), which opens the potential for an attacker to infect the UEFI from the ME.\r\nAttackers just need to bypass SPI Descriptor and BIOS Control register protections. We will look at\r\nmultiple scenarios showing how this would work in a real attack. \r\nMapping the Path to Exploiting ME\r\nFirst, we need to map out the various ways that an attacker could gain control over the ME firmware. It is\r\nimportant to note that ME has its own dedicated access to the network adapter of the host, which is independent of\r\nthe host operating system. Attackers such as the PLATINUM group have used this capability in the past to hide\r\ncommand-and-control from OS-level security controls.\r\nAttackers also could exploit the chipset after gaining initial access to the system via virtually any traditional vector\r\nsuch as phishing, malware, or supply chain compromise. Attackers would once again be able target vulnerabilities\r\nenabling code execution, but with the advantage of not having to rely solely on vulns that can be exploited over\r\nthe network. It is important to note that the leaks indicate that Conti engineers are seeking out new ME firmware\r\nvulnerabilities. However, we have compiled a list of the known ME and AMT vulnerabilities most likely to be\r\ntargeted based on their potential to enable remote code execution (RCE) and/or privilege escalation (PE). We have\r\nincluded a table of these vulnerabilities as an appendix here, which includes the relevant Intel security advisories,\r\naffected versions, and CVEs. \r\nAttackers could also target ME in a more direct way via phishing by luring a user into executing a malicious ISO\r\nas observed in recent Quantum ransomware attacks. This method takes advantage of the HECI driver that provides\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 5 of 12\n\naccess to the ME. The HECI driver is installed on any system that has ME and enables privileged users to\r\ncommunicate with ME. Thus an attacker could embed a malicious ISO within an email, gain application execution\r\nby tricking the user into opening the file, then run the attack by using HECI to communicate with ME.\r\nKnown High-Impact Vulnerabilities in Intel ME\r\nIntel\r\nAdvisory\r\nAffected Versions\r\nRelated\r\nCVEs\r\nNotes\r\nIntel-SA-00086\r\nME –\r\n6.x/7.x/8.x/9.x/10.x//11.0/11.5/11.6/11.7/11.10/11.20\r\nCVE-2017-\r\n5705CVE-2017-\r\n5711CVE-2017-5712\r\nCVE-2017-\r\n5712 is\r\nexploitable\r\nremotely over\r\nthe network in\r\nconjunction\r\nwith a valid\r\nadministrative\r\nIntel®\r\nManagement\r\nEngine\r\ncredential.\r\nIntel-SA-00112\r\nManageability Engine Firmware version\r\n3.x,4.x,5.x,6.x,7.x,8.x,9.x, 10.x,11.x\r\nCVE-2018-\r\n3628\r\nRCE on same\r\nsubnet\r\nIntel-SA-00118\r\nManagement Engine version 11.x\r\nCVE-2018-\r\n3627\r\nExecute\r\narbitrary code\r\nIntel-SA-00125\r\nCSME before version 11.21.55\r\nCVE-2018-\r\n12147\r\nLocal privilege\r\nescalation\r\nIntel-SA-00131\r\nCSME before version 11.8.55, 11.11.55, 11.21.55,\r\n12.0.6\r\nCVE-2018-\r\n3643\r\nLocal execute\r\narbitrary code\r\nIntel-SA-00141 \r\nCSME versions before version 12.0.5\r\nCVE-2018-\r\n3657CVE-2018-3616\r\nLocal execute\r\narbitrary code.\r\nSide channel\r\nattack to get\r\nsession key via\r\nnetwork.\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 6 of 12\n\nIntel-SA-00185\r\nCSME before version 11.8.60, 11.11.60, 11.22.60 or\r\n12.0.20\r\nCVE-2018-\r\n12196CVE-2018-\r\n12200CVE-2018-12190\r\nLocal execution\r\nof arbitrary\r\ncode and local\r\nprivilege\r\nescalation.\r\nIntel-SA-00213\r\nCSME before versions 11.8.65, 11.11.65, 11.22.65,\r\n12.0.35\r\nCVE-2019-\r\n0091CVE-2019-\r\n0086 CVE-2019-\r\n0153CVE-2019-0096 \r\nUnprivileged\r\nuser privilege\r\nescalation and\r\nnetwork\r\nprivilege\r\nescalation.\r\nIntel-SA-00241AMT versions 11.0 thru 11.8.65, 11.10 thru\r\n11.11.65, 11.20 thru 11.22.65, 12.0 thru 12.0.35,\r\n13.0, 14.0.0\r\nLPE:\r\nCVE-2019-\r\n11147CVE-2019-\r\n11105CVE-2019-\r\n11104 CVE-2019-\r\n11097CVE-2019-\r\n11103CVE-2019-\r\n11087CVE-2019-\r\n11106CVE-2019-\r\n11110CVE-2019-11108\r\nAPE:\r\nCVE-2019-\r\n0169CVE-2019-11088\r\nNPE:CVE-2019-\r\n11132CVE-2019-\r\n11131CVE-2019-11107\r\nLocal privilege\r\nescalation.\r\nAdjacent\r\nprivilege\r\nescalation,\r\nnetwork\r\nprivilege\r\nescalation of\r\nunauthenticated\r\nuser.\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 7 of 12\n\nIntel-SA-00295\r\nCSME Versions 11.0 through 11.8.76, 11.10 through\r\n11.12.76, 11.20 through 11.22.76, 12.0 through\r\n12.0.63, 13.0 through 13.0.31, 14.0 through 14.0.32,\r\n14.5.11.\r\nCSME, AMT, I ISM, DAL and DAL Software\r\nbefore versions 11.8.77, 11.12.77, 11.22.77, 12.0.64,\r\n13.0.32, 14.0.33, 14.5.12\r\nNPE:\r\nCVE-2020-\r\n0594CVE-2020-0595\r\nLPE:\r\nCVE-2020-\r\n0586CVE-2020-\r\n0542CVE-2020-\r\n0533CVE-2020-0541\r\nNetwork\r\nprivilege\r\nescalation of\r\nunauthenticated\r\nuser, local\r\nprivilege\r\nescalation.\r\nIntel-SA-00307\r\nCSME versions before 12.0.49 (IOT only: 12.0.56),\r\n13.0.21, 14.0.11.\r\nCVE-2019-\r\n14598\r\nLocal privilege\r\nescalation\r\nIntel-SA-00391CSME and AMT versions before 11.8.82, 11.12.82,\r\n11.22.82, 12.0.70, 13.0.40, 13.30.10, 14.0.45 and\r\n14.5.25\r\nNPE:\r\nCVE-2020-\r\n8752\r\nLPE:\r\nCVE-2020-\r\n12297CVE-2020-\r\n12303CVE-2020-\r\n12354CVE-2020-\r\n8744CVE-2020-8757\r\nCVE-2020-\r\n8756CVE-2020-8760\r\nUnauthenticated\r\nnetwork\r\nprivilege\r\nescalation.\r\nLocal privilege\r\nescalations.\r\nIntel-SA-00404\r\nAMT and ISM versions before 11.8.79, 11.12.79,\r\n11.22.79, 12.0.68 and 14.0.39.\r\nCVE-2020-\r\n8758\r\nLocal privilege\r\nescalation\r\nIntel-SA-00459CSME versions before 11.8.86, 11.12.86, 11.22.86,\r\n12.0.81, 13.0.47, 13.30.17, 14.1.53, 14.5.32 and\r\n15.0.22\r\nCVE-2020-\r\n8703\r\nLocal privilege\r\nescalation\r\nIt is important to note that many systems are vulnerable to CVEs covered in these Intel advisories. For example, a\r\nrecent analysis of a production network found that 72.3% of devices were vulnerable to CVEs in Intel SA00391,\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 8 of 12\n\nwhich contains the potential for network privilege escalation. Likewise, 61.45% of devices were vulnerable to\r\nissues covered in SA00295, which also enables privilege escalation over a network. These two security advisories\r\ninclude vulnerabilities from the Ripple20 disclosure and additional remotely-exploitable vulnerabilities in the\r\nTreck TCP/IP stack found by Intel as a followup to the initial Ripple20 disclosure.\r\nMoving From ME to UEFI/SMM\r\nME is a highly privileged component within the system, and has its own flash memory within the SPI. An attacker\r\nwith control over the ME can then use that access to overwrite the UEFI system firmware and gain SMM code\r\nexecution. The details of how this is done will vary depending on the types of protections and settings of the target\r\nsystem. Two of the most important settings in this regard is if BIOS write protection (BIOS_WP) is properly set\r\non the device, and if ME firmware has the privileges to modify different SPI regions in the access control table\r\nwithin the SPI Descriptor. \r\nWe will look at three scenarios in more detail. \r\nScenario #1\r\nSystem State: \r\nME has access to overwrite the SPI Descriptor in the SPI Descriptor access control table\r\nSPI Controller BIOS Write Protections are properly configured\r\n51% of firmware update images with SPI descriptor had this level of access\r\nBy using ME to modify the SPI Descriptor, an attacker could change the BIOS Region layout, thus moving the\r\nBIOS outside the area protected by BIOS_WP. The attacker could then modify the firmware to install their own\r\nmalicious implant code.\r\nAttacker uses ME to move BIOS region outside of Write Protection region and inserts implant\r\ninto firmware\r\nScenario #2\r\nSystem State:\r\nME has access to BIOS Region in SPI Descriptor access control table\r\nSPI Controller BIOS Write Protections are properly configured\r\n52% of firmware update images with SPI descriptor had this level of access\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 9 of 12\n\nMany systems have the SPI descriptor configured by the OEM to grant the ME write permission to the BIOS\r\nregion. This could be used to allow the ME to write to the BIOS region in the SPI flash to modify UEFI firmware.\r\nIn the case that the SPI controller BIOS Write Protections are configured and prevent writes to the BIOS region\r\neven by the ME, the ME can trigger the CPU to enter SMM mode and issue SPI transactions while the CPU is\r\nrunning in SMM. The SPI controller is designed to allow the BIOS region to be updated even when the BIOS\r\nControl register is configured properly when the CPU is in SMM.\r\nScenario #3\r\nSystem State:\r\nME does not have access to BIOS Region in SPI Descriptor access control table\r\nSPI Controller BIOS Write Protections are properly configured\r\nAnother useful capability of the ME is the ability to reboot the host CPU and force it to boot from virtual media.\r\nThis is intended to be used to (re)install operating systems and other maintenance tasks. The way that this is\r\nimplemented is that the ME can trigger a Host Partition Reset which causes the host CPU to be reset and\r\nPLTRST# to be asserted. When this happens, several PCH protection mechanisms are unlocked, such as the BIOS\r\nControl register in the SPI controller.\r\nThis could be used by a compromised ME to use its DMA engine to inject code into the host processor DRAM to\r\nget arbitrary code execution at a point when SMRAM and the SPI protections have not been locked yet. This\r\nwould allow the ME to write to SPI flash even when the SPI descriptor and BIOS Control register protections are\r\nimplemented correctly. This could also be used to install malicious SMI handlers before SMRAM is locked to\r\nleave an undetectable rootkit running while the operating system loads and runs, though we did not develop proof\r\nof concept code to confirm this.\r\nAttacker Objectives and Impact Analysis\r\nIt is important to understand why attackers are investing resources in developing these new paths to a system’s\r\nfirmware. Control over firmware gives attackers virtually unmatched powers both to directly cause damage and to\r\nenable other long-term strategic goals. \r\nDestruction of Assets\r\nIn terms of damage, an attacker can effectively “brick” a system permanently by overwriting the system firmware.\r\nSimilarly, an attacker could use this level of access to wipe the Master Boot Record or other high-value files on a\r\nsystem. Wipers such as WhisperGate and HermeticWiper have played a major and ongoing role in the Russian\r\ninvasion of Ukraine and provide a stark reminder of the damaging potential of low-level attacks on devices. While\r\nsuch low level wiper attacks have averaged about one major event per year, in the first quarter of 2022, there have\r\nbeen 6 or more wipes discovered in the wild. Attacker motives are shifting to destructive objectives, whether\r\nAPTs, ransomware, or high profile criminal espionage actors such as LAPSUS$.\r\nPersistence\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 10 of 12\n\nHowever, firmware also provides long-term persistence capabilities that would be particularly valuable to a group\r\nsuch as Conti. Attackers are able to use the unique privileges of firmware to evade a wide variety of security\r\nfeatures, and security products in order to establish ongoing persistence on a device. Groups like Conti directly\r\nmonetize such persistence by reselling access to other threat actors, or even dropping additional ransomware\r\npayloads at a later date.\r\nEvasion of AV/EDR/XDR Products\r\nThis ability to maintain persistence is tied to the ability for an attacker’s code to reside off of the traditional system\r\nstorage drives, and most importantly, the ability to evade security controls. By sitting below the operating system,\r\nattackers can hide in areas where traditional security tools lack visibility. Antivirus and EDR have very limited\r\ncoverage of firmware threats and lack the ability to proactively verify the integrity of a device’s firmware. This\r\nmakes it relatively easy for attackers to evade detection. Additionally, traditional products lack visibility into\r\ncomponents outside of UEFI such as ME firmware. This ability to shift the attack to areas that security tools fail to\r\nprotect gives attackers incredible advantages.\r\nEven when antivirus, EDR, and other endpoint security tools do query a system’s firmware, they typically rely on\r\nthe operating system in order to do so. However, if the firmware is already compromised, a malicious firmware\r\nimplant can easily report false information to the operating system in order to evade those security controls. Such\r\ntechniques were recently observed in the wild. Likewise, the use of SMM allows attackers to execute code that is\r\ncompletely invisible to the operating system, and likewise, the security products running within the OS.\r\nThe focus on evading security tools was confirmed in the chats, which showed the group was actively acquiring\r\nendpoint security tools for developing evasion techniques and testing. Additional chats confirmed that the actors\r\nwere able to bypass up to eight well-known EDR products, while struggling to evade at least three of them.\r\nIndeed, the driving motive behind exploring ways to attack and access the UEFI, is to be able to disable any of the\r\noverlying security controls and third party security stack that resides at the OS layer.\r\nEvasion of Device Protections\r\nIn addition to evading security products, attackers can use compromised firmware in order to evade many of the\r\nprotections built into modern systems. This includes features such as BitLocker, Windows Virtual Secure Mode\r\n(VSM), Credential Guard, and Early Launch AntiMalware (ELAM). \r\nMitigations and Best Practices\r\nBased on the information disclosed in the Conti leaks, organizations should take action to reduce their exposure\r\nand develop capabilities to detect and respond to these new techniques. There are several key steps that we\r\nrecommend:\r\n1. Scan Devices for Exploitable Versions of ME – We have provided a list of the known CVEs most likely\r\nto be used in an attack. Device scans should include CVEs as well as detecting versions of firmware that\r\ngives ME access to the BIOS Region in the SPI Descriptor access control table. Organizations should use a\r\ntool that specializes in firmware vulnerabilities (e.g. CHIPSEC, Eclypsium), as many traditional\r\nvulnerability scanners lack the necessary drivers and access to scan down to the level of ME.\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 11 of 12\n\n2. Monitor ME for Any Configuration Changes – Organizations should check to verify that the ME\r\nfirmware on their devices matches a valid, known version of firmware from Intel. Any changes would\r\nindicate that the firmware may have been compromised or tampered with. Ideally, organizations should\r\nverify this information using mechanisms that are independent of the operating system.\r\n3. Verify the Integrity of the SPI Flash and Monitor for Any Configuration Changes – The same\r\nintegrity checking and monitoring should be applied to the SPI flash firmware as well as the UEFI/BIOS of\r\nthe device. Once again, firmware should match known good versions, and teams should be alerted to any\r\nchanges particularly tied to anomalous or unreleased code.\r\nConclusions\r\nThe recent Conti leaks mark a critical phase in the rapidly evolving role of firmware in modern attacks. Threats\r\nsuch as TrickBoot, MosaicRegressor, and dozens of new forms of wiper malware have continued to drive attacks\r\nbelow the level of the operating system. However, the Conti leaks exposed a strategic shift that moves firmware\r\nattacks even further away from the prying eyes of traditional security tools. The shift to ME firmware gives\r\nattackers a far larger pool of potential victims to attack, and a new avenue to reaching the most privileged code\r\nand execution modes available on modern systems. \r\nAs the realities of the threat landscape continue to evolve, it is critical that organizations continue to inform their\r\ndefenses based on the latest intelligence available. The Eclypsium team will continue to strive to provide updated\r\ninsight and guidance into these and other firmware threats as they become available. For any questions related to\r\nthis research, please contact the Eclypsium team at info@eclypsium.com.\r\nSource: https://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nhttps://eclypsium.com/2022/06/02/conti-targets-critical-firmware/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://eclypsium.com/2022/06/02/conti-targets-critical-firmware/"
	],
	"report_names": [
		"conti-targets-critical-firmware"
	],
	"threat_actors": [
		{
			"id": "be5097b2-a70f-490f-8c06-250773692fae",
			"created_at": "2022-10-27T08:27:13.22631Z",
			"updated_at": "2026-04-10T02:00:05.311385Z",
			"deleted_at": null,
			"main_name": "LAPSUS$",
			"aliases": [
				"LAPSUS$",
				"DEV-0537",
				"Strawberry Tempest"
			],
			"source_name": "MITRE:LAPSUS$",
			"tools": [
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "d4b9608d-af69-43bc-a08a-38167ac6306a",
			"created_at": "2023-01-06T13:46:39.335061Z",
			"updated_at": "2026-04-10T02:00:03.291149Z",
			"deleted_at": null,
			"main_name": "LAPSUS",
			"aliases": [
				"Lapsus",
				"LAPSUS$",
				"DEV-0537",
				"SLIPPY SPIDER",
				"Strawberry Tempest",
				"UNC3661"
			],
			"source_name": "MISPGALAXY:LAPSUS",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "7d8ef10e-1d7b-49a0-ab6e-f1dae465a1a4",
			"created_at": "2023-01-06T13:46:38.595679Z",
			"updated_at": "2026-04-10T02:00:03.033762Z",
			"deleted_at": null,
			"main_name": "PLATINUM",
			"aliases": [
				"TwoForOne",
				"G0068",
				"ATK33"
			],
			"source_name": "MISPGALAXY:PLATINUM",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "e61c46f7-88a1-421a-9fed-0cfe2eeb820a",
			"created_at": "2022-10-25T16:07:24.061767Z",
			"updated_at": "2026-04-10T02:00:04.854503Z",
			"deleted_at": null,
			"main_name": "Platinum",
			"aliases": [
				"ATK 33",
				"G0068",
				"Operation EasternRoppels",
				"TwoForOne"
			],
			"source_name": "ETDA:Platinum",
			"tools": [
				"AMTsol",
				"Adupib",
				"Adupihan",
				"Dipsind",
				"DvDupdate.dll",
				"JPIN",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"RedPepper",
				"RedSalt",
				"Titanium",
				"adbupd",
				"psinstrc.ps1"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "2347282d-6b88-4fbe-b816-16b156c285ac",
			"created_at": "2024-06-19T02:03:08.099397Z",
			"updated_at": "2026-04-10T02:00:03.663831Z",
			"deleted_at": null,
			"main_name": "GOLD RAINFOREST",
			"aliases": [
				"Lapsus$",
				"Slippy Spider ",
				"Strawberry Tempest "
			],
			"source_name": "Secureworks:GOLD RAINFOREST",
			"tools": [
				"Mimikatz"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "52d5d8b3-ab13-4fc4-8d5f-068f788e4f2b",
			"created_at": "2022-10-25T16:07:24.503878Z",
			"updated_at": "2026-04-10T02:00:05.014316Z",
			"deleted_at": null,
			"main_name": "Lapsus$",
			"aliases": [
				"DEV-0537",
				"G1004",
				"Slippy Spider",
				"Strawberry Tempest"
			],
			"source_name": "ETDA:Lapsus$",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "33f527a5-a5da-496a-a48c-7807cc858c3e",
			"created_at": "2022-10-25T15:50:23.803657Z",
			"updated_at": "2026-04-10T02:00:05.333523Z",
			"deleted_at": null,
			"main_name": "PLATINUM",
			"aliases": [
				"PLATINUM"
			],
			"source_name": "MITRE:PLATINUM",
			"tools": [
				"JPIN",
				"Dipsind",
				"adbupd"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434573,
	"ts_updated_at": 1775792134,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0d148b307aa8c0170a846997e316f35e90f2a1f0.pdf",
		"text": "https://archive.orkl.eu/0d148b307aa8c0170a846997e316f35e90f2a1f0.txt",
		"img": "https://archive.orkl.eu/0d148b307aa8c0170a846997e316f35e90f2a1f0.jpg"
	}
}