{ "id": "4d2e4217-fdf3-445f-8207-45b004e1bdd7", "created_at": "2026-04-06T00:17:26.400717Z", "updated_at": "2026-04-10T13:11:36.732407Z", "deleted_at": null, "sha1_hash": "a3569125d589e24583207caf0422de4bdde1c074", "title": "The Untold Story of the BlackLotus UEFI Bootkit", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1641022, "plain_text": "The Untold Story of the BlackLotus UEFI Bootkit\r\nArchived: 2026-04-05 14:54:30 UTC\r\nby Alex Matrosov\r\nMy experience with the analysis and detection of rootkits and bootkits goes back more than 20 years. In the early\r\n2000s, the main challenge was dealing with infected machines when rootkits and bootkits modified the operating\r\nsystem kernel to conceal malicious components. It was such a fun time reverse engineering advanced threats in the\r\ngood old days that I co-wrote \"Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats,\"\r\na book full of the most interesting stories of our time going down the rabbit hole of advanced malware.\r\nWhen the major operating systems moved to UEFI support and Secure Boot was widely implemented, I really\r\nbelieved the golden age of bootkits had ended and the natural evolution would lead in the direction of firmware\r\nimplants. I was wrong. Last week, researchers at ESET published \"BlackLotus UEFI Bootkit: Myth Confirmed,\"\r\nconfirming the existence of UEFI bootkits all over again. UEFI bootkits like BlackLotus are not new and have\r\nbeen publicly seen since 2013 or even earlier. Modified or replaced bootloaders create very visible and noisy\r\nIndicators of Compromise (IOCs) that attackers who are focused on persistence want to avoid.\r\nNevertheless, BlackLotus has been detected in-the-wild by the end of 2022, which is surprising for a malware\r\nclass that has been around for 10+ years.\r\nDive into (in)secure boot and the CVSS scoring problem\r\nThis story also has a supply chain twist.  A critical aspect of the BlackLotus story lies in supply chain problems\r\nrelating to modern operating systems, their bootloaders, and UEFI firmware. In order to bypass Secure Boot at\r\nscale, BlackLotus exploits CVE-2022-21894, a vulnerability patched by Microsoft in January 2022. A proof-of-concept exploit was released in August 2022, seven months after Microsoft’s public disclosure.\r\nThe CVE-2022-21894 vulnerability’s CVSS score (4.4 medium) doesn't seem to indicate a serious vulnerability,\r\ndoes it?\r\nThe problem with most of the Secure Boot bypass vulnerabilities is that they require local or physical access to the\r\ntarget. This significantly affects CVSS scoring in terms of the impact. Since Secure Boot bypass attacks cross\r\nsecurity boundaries or allow the disabling of security features, we need to treat them as privilege escalation\r\nvulnerabilities to more accurately reflect the CVSS impact score.\r\nAs the operating system bootloader becomes the middle layer between the firmware and operating system during\r\nthe boot process, the bootloader provides a significant attack surface that can impact a lot of security features like\r\ndisk encryption and secure boot. Currently, there is little documentation on attacks against bootloaders and a lot of\r\ninconsistency in the published existing knowledge. Here are some Microsoft advisories related to Secure Boot\r\nbypasses and other bootloader vulnerabilities.\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 1 of 10\n\nAs an aside, the navigation on the Microsoft Security Response Center (MSRC) website is a complete disaster\r\nfrom the perspective of tracking retrospective vulnerabilities and attacks. According to CVSS scores, all of these\r\nissues fall under ‘medium-severity’ impact. Despite this, many of them allow bypassing Secure Boot and attacking\r\nthe bootloader with serious consequences.\r\nEven after the vendor fixes the secure boot bypass vulnerabilities shown in the figure above, the\r\nvulnerabilities can present long-term, industry-wide supply chain impact. Using CVE-2022-21894 as an\r\nexample shows how such vulnerabilities can be exploited in the wild after one year, even with a vendor fix\r\navailable.\r\nInterestingly, CVE-2022-21894 reminds me of previous findings MS16-094/CVE-2016-3287 and MS16-\r\n100/CVE-2016-3320 (also known as Golden Key vulnerabilities) discovered by the same researcher Clark\r\nZammis. The complexity of the modern Microsoft Windows Boot Manager (bootmgfw) grows with every new\r\nrelease of Windows, simultaneously expanding the attack surface. Modern UEFI-based Secure Boot schemes are\r\nextremely complicated to configure correctly and/or to reduce their attack surfaces meaningfully. That being said,\r\nbootloader attacks are not likely to disappear anytime soon.\r\nA record number of high-impact vulnerabilities (228) were disclosed by the Binarly REsearch team in UEFI\r\nsystem firmware within one year. By design, most of these vulnerabilities bypass Secure Boot and allow\r\nattackers to persist at the firmware level.\r\nThe example of BlackLotus shows how old tricks with less complicated malware can be used to gain persistence\r\nbelow the operating system via exploitation of a known secure boot bypass vulnerability. Still, it is quite difficult\r\nto mitigate the BlackLotus/CVE-2022-21894 secure boot bypass across the industry. The UEFI Forum is usually\r\nresponsible for coordinating and supporting the major vendor-independent mitigation of UEFI Revocation List\r\nFiles (DBX). This list contains the hashes of signed bootloaders or firmware components that were blacklisted.\r\nThe problem with every blacklist technology is that it will always miss known problems if it is not updated or well\r\nmaintained. In the history of UEFI Revocation List Files (DBX), Microsoft pushed mandatory updates only a\r\nhandful of times. Other than OS vendors, who else should be responsible for these updates? Device vendors with\r\nfirmware updates? As we all know, firmware updates typically occur only a few times a year, so any blacklist will\r\nbe near useless with such minimal update frequency, but it is better than nothing.\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 2 of 10\n\nWe can see from the figure above that any compromised signed UEFI component can break secure boot integrity\r\nand bypass it. My mind immediately goes to the Binarly REsearch team's discovery of BRLY-2021-003/CVE-2021-39297 (stack buffer overflow) vulnerability on HP devices last year (almost 8 months under disclosure\r\nprocess). Based on the demo below, an attacker can execute arbitrary code over HP Hardware Diagnostics UEFI\r\napplication.\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 3 of 10\n\nDuring its analysis of BlackLotus, the ESET research team discovered that the MokList NVRAM variable was\r\nmodified. The MokList variable contains a list of authorized Machine Owner Keys (MOKs) and hashes\r\n(EFI_SIGNATURE_LIST according to the UEFI specification). But it's another example of a supply chain issue\r\nwith broad secure boot implications in the field as the MokList variable can be modified in runtime. With the\r\nmodified MokList variable, an attacker can easily load any self-signed shim bootloader, which is actually another\r\nvulnerability in the chain used to keep secure boot active.\r\nIn the modern secure boot, there are many inconsistencies due to many factors, including legacy compatibility\r\nissues. The Binarly REsearch Team has discussed these weaknesses for years at multiple public conferences, but\r\nthe complexity of modern secure boot continues to increase.\r\nEnterprise defenders and CISOs need to understand that threats below the operating system are clear and\r\npresent dangers to their environments. Since this attack vector has significant benefits for the attacker, it is\r\nonly going to get more sophisticated and complex. Vendor claims about security features can be completely\r\nopposite to the reality. Binarly's small research team was able to discover and disclose 228 high-impact\r\nvulnerabilities across all major enterprise vendors in a year, which we believe only scratches the surface. This\r\nresearch continues, on both sides of the fence (defense and offense).  \r\nA new name for old tricks\r\nAre there any new techniques in the BlackLotus bootkit? My opinion is that BlackLotus is a good combination of\r\nwell-known techniques. Proof of concept code for CVE-2022-21894 (public since August 2022) was taken from\r\nthe GitHub repository of the researcher who found the vulnerability.\r\nBinarly REsearch discovered new interesting data points about the nature of the bootkit code. It appears the author\r\nof the BlackLotus bootkit based their development on code from the Umap GitHub project (Windows UEFI\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 4 of 10\n\nbootkit that loads a generic driver manual mapper without using a UEFI runtime driver) or coincidently arrived at\r\nthe same ideas. According to the first commit, Umap was released in April 2020.\r\nThis picture shows a comparison of the logic of the main function from BlackLotus and Umap. Both look very\r\nsimilar and contain exactly the same steps with a few minor changes.\r\nThe routines responsible for installing the hook chain (start with ImgArchStartBootApplication) are very similar as\r\nshown in the figure.\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 5 of 10\n\nBlackLotus trampoline code modification logic to setup hooks is identical to Umap code on GitHub.\r\nWith these new data points, we can see how UEFI bootkit code reused from 2020 can be combined with publicly\r\navailable proofs of concept for CVE-2022-1894 to lead to the creation of the BlackLotus bootkit. This relatively\r\nnew secure boot bypass vulnerability (which the vendor claims is low-impact) has led to widespread distribution\r\nof old malicious UEFI bootkit code.\r\nZero-knowledge detection of new threats\r\nBinarly has been focused from the beginning on developing proactive technology based on deep code inspection\r\nto detect unknown threats and vulnerabilities to help the industry recover from repeatable failures. The Binarly\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 6 of 10\n\nPlatform dashboard below shows code similarity proactive detection based on machine learning models guided by\r\ncode-based embeddings.\r\nUsing the BlackLotus components, we simulated infection on one of the machines available in our lab. Binarly\r\nPlatform was used to compare collected snapshots of the infected and clean EFI System Partitions (ESP). Based\r\non function similarity, we detect the replacement of bootmgfw.efi with the shim.\r\nThe BlackLotus anomaly was proactively detected with zero knowledge about this threat, and the explained code\r\nsimilarity failures make it actionable for the security and incident response teams to conduct further investigation.\r\nLet's explore the code similarity detection in more detail. The figure below shows the detailed output for the\r\ndetected anomalies from the BlackLotus malicious components added to ESP partition.\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 7 of 10\n\nCode similarity detects anomalies based on code changes and integrity checking heuristics as shown in the figure\r\nbelow.\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 8 of 10\n\nHere is a visual explanation of the outlier (compromised ESP partition) and details of the algorithm to detect\r\nanomaly:\r\nBinarly's Platform is able to analyze modules and executables based on semantic similarity. The figure above\r\nshows a visualization of the program embeddings for bootmgfw and the shim. For code function signatures, we\r\nused data clustering algorithm DBSCAN with a precomputed Gower distance to detect anomalies. This is where\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 9 of 10\n\nwe detect that additional suspicious modules were added. Afterwards, we visualized the results using the T-SNE\r\nalgorithm.\r\nWhat about detection based on FwHunt?\r\nWe continue to maintain the public FwHunt rules database and today we released a new semantic-based rule to\r\ncover malicious bootloader components from the BlackLotus bootkit.\r\nBlackLotus rule is included in FwHunt's GitHub repository. To use these rules you will need FwHunt Community\r\nScanner (fwhunt-scan).\r\nWe need to increase the industry awareness to firmware related threats and build more effective threat\r\nhunting programs with cross-industry collaboration between the vendors to mutually benefit customers and\r\nprovide better detection rates.\r\nSource: https://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nhttps://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_UEFI_Bootkit/index.html" ], "report_names": [ "index.html" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434646, "ts_updated_at": 1775826696, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a3569125d589e24583207caf0422de4bdde1c074.pdf", "text": "https://archive.orkl.eu/a3569125d589e24583207caf0422de4bdde1c074.txt", "img": "https://archive.orkl.eu/a3569125d589e24583207caf0422de4bdde1c074.jpg" } }