{ "id": "92113474-0017-4b84-80a4-05926f058a52", "created_at": "2026-04-06T00:17:30.647547Z", "updated_at": "2026-04-10T13:12:54.366094Z", "deleted_at": null, "sha1_hash": "d17d7a58671e1c59d85d396e61f8408fe9615b63", "title": "A deeper UEFI dive into MoonBounce", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1192212, "plain_text": "A deeper UEFI dive into MoonBounce\r\nArchived: 2026-04-05 21:21:26 UTC\r\nby Binarly Team\r\nAfter uncovering FinSpy several months ago, an APT threat targeting UEFI bootloaders, in the morning of\r\nJanuary 20th 2022, Kaspersky Lab has released a new report on their latest discovery, a very interesting UEFI\r\nfirmware threat dubbed MoonBounce.\r\nLast year, the ESET researchers discovered ESPecter another threat which also targets EFI bootloaders.\r\nMoonBounce, FinSpy and ESPecter are examples of APT malware comprising components that target both UEFI\r\nand Legacy BIOS boot processes.\r\nTo kickstart our investigation, we leveraged VirusTotal Intelligence and discovered an archive exhibiting the\r\ndetections mentioned in the Kaspersky Lab’s MoonBounce report.  Recently, a user uploaded the related samples,\r\nwhich surprised us greatly since we did not expect to find them that quickly by just querying using the detection\r\nname.\r\nLet’s dive into the dark waters of the MoonBounce firmware implant. In this blog we want to discuss some of the\r\nfacts which weren’t covered by the original report and are interesting to share.\r\nKaspersky Lab’s original report emphasizes that the aforementioned malware consists of a number of known\r\nmalware components and frameworks: Microcin, Mimikat SSP, xTalker, etc.\r\nhttps://www.binarly.io/posts/A_deeper_UEFI_dive_into_MoonBounce/index.html\r\nPage 1 of 6\n\nBinarly Research Team has analyzed the samples found in VirusTotal and discovered that the UEFI component\r\n(the first stage in the malware boot process) is quite old too. It was compiled with borrowed code from an\r\nunknown old malware project, most likely previously discovered in the wild on some Dell systems back in 2018\r\n(according to GitHub repository information) and reconstructed in detail in the GitHub repository called\r\n“BootLoader”.\r\nBinarly investigation focused on the firmware research of the UEFI component to provide additional technical\r\ninformation to the already detailed original report on MoonBounce threat.\r\nOur deep dive uncovered similarities between the MoonBounce UEFI component and the binaries available in the\r\nBootLoader GitHub repository. Diving into the BootLoader code, visually the hooking routine\r\nSearch_OslArchTransferToKernel() piqued our interest, as it is almost identical with the textual disassembly of the\r\nMoonBounce’s CORE_DXE firmware dump component:\r\nhttps://www.binarly.io/posts/A_deeper_UEFI_dive_into_MoonBounce/index.html\r\nPage 2 of 6\n\nCode from CORE_DXE of MoonBounce firmware dump\r\nDisassembled 32-bit code of BootLoader binary\r\nDuring early runtime of the DXE phase, it is a known practice employed by malicious actors to modify or hook\r\nDXE Services to intercept a boot flow inside the firmware. From a forensics perspective, such modifications are\r\nvery visible and can be detected using common integrity firmware monitoring approaches.\r\nDisassembly code from CORE_DXE of MoonBounce firmware dump\r\nThis code from MoonBounce component is pretty similar with code flow from BootLoader.asm. These\r\nobservations lead to the conclusion that MoonBounce's authors are the same or use similar code techniques or\r\nframeworks to embed their modification into the firmware and Windows kernel.\r\nAdditional details can be found in the original Kaspersky report “Technical details of MoonBounce’s\r\nimplementation” (p. 6, “Code that set up a hook in the ExAllocatePool function within ntoskrnl.exe”).\r\nAnother technical detail we'd like to highlight here relates to the multiple infection delivery paths. The original\r\nreport explains the usage of CoreCreateEventInternal() hook - as support for both UEFI boot and Legacy boot\r\nmode (assuming it’s targeting deprecated Compatibility Support Module (CSM)).\r\nhttps://www.binarly.io/posts/A_deeper_UEFI_dive_into_MoonBounce/index.html\r\nPage 3 of 6\n\nCompatibility Support Module (CSM) - this module emulates the legacy BIOS in UEFI systems and was developed\r\nby Intel to ease the transition to UEFI world. It's pretty common on hardware released before 2020. For newer\r\nenterprise hardware is usually disabled by default.\r\nThe reason for using CoreExitBootServices() is to hook a call from Windows loader (Winload) and prepare the\r\nnext steps for the MoonBounce boot interception process. What is the point of hooking InternalAllocatePool() at\r\nthe beginning? The possible motivation for this could be to avoid storing the shellcode in a virtual address space\r\nalong the Windows kernel, by placing it in a physical memory and then executing it directly from there. Such a\r\ntechnique can be used for fileless in memory code execution which would be orchestrated directly from the\r\nfirmware. During incident response, this will cause complications from a forensic perspective.\r\nUpon further analysis, we found that CORE_DXE contains the target firmware name as a string constant\r\n\"E7846IMS.M30\".\r\nTherefore, we became curious to determine the exact targeted platform. The first forensic artifact is the PE header\r\ntimestamp for the CORE_DXE module (Fri Jul 18 03:29:55 2014).\r\nPE Tree snapshot of the CORE_DXE module\r\nOn the same day, Taiwanese company MSI released a firmware update for their hardware platform which is very\r\nsimilar to the firmware that has been infected by MoonBounce.\r\nhttps://www.binarly.io/posts/A_deeper_UEFI_dive_into_MoonBounce/index.html\r\nPage 4 of 6\n\nSearching on Google for the string constant \"E7846IMS.M30\", we found the following website:\r\nhxxps://www.mmnt[.]net/db/0/13/lupd01[.]eu[.]msi[.]com/ALL_BIOS_Update_Genie_update_20140831\r\nAfter obtaining the original firmware image, we were curious about the similarity between the original\r\nCORE_DXE component and the modified one in MoonBounce. According to our code analysis (binary diffing the\r\nMoonBounce UEFI component with the original firmware image from the vendor), there were no other\r\nmodifications besides hooks for InternalAllocatePool, CoreExitBootServices and CoreCreateEventInternal\r\nservices.\r\nBinDiff analysis with the original CORE_DXE {5AE3F37E-4EAE-41AE-8240-35465B5E81EB} driver from\r\nE7846IMS.M30 firmware\r\nUsing the Binarly Cloud Platform, we found a DXE Core driver which is very similar to the MoonBounce UEFI\r\nfirmware dump component. The similarity was confirmed by matching control flow graphs through further\r\nanalysis with Google BinDiff tool. The code similarity search reveals exactly three modified/hooked routines that\r\nwe discussed earlier.\r\nThere are other interesting questions we need to discuss, such as potential methods of delivering malware to the\r\ntarget system. How could such malware be written into SPI flash storage of the targeted system? It is worth\r\nnoticing that the analyzed MoonBounce UEFI component was built for a target hardware related to a MSI\r\nsystem from 2014. This fact allows us to suggest two possible initial points of compromise:\r\nPhysical access-based implant delivery to the target system - no Intel Boot Guard technology present or\r\nenabled thus there are no physical or hardware restrictions to get access to SPI flash storage of the system.\r\nSoftware-based implant delivery to the target system - keeping in mind the historical ignorance of many\r\nvendors on firmware security threats, we infer that no SPI protections were enabled on the system, hence\r\nhttps://www.binarly.io/posts/A_deeper_UEFI_dive_into_MoonBounce/index.html\r\nPage 5 of 6\n\nSPI write-operations could be issued easily with no exploits required (access only to physical memory is\r\nrequired for working with PCH SPI controller MMIO).\r\nPublic information regarding firmware related implants is more present in the media lately, but it is just scratching\r\nthe surface in terms of threat detection. Many security research papers have been published which provide\r\nexamples of more advanced techniques for threat actors to persist in firmware. The supply chain complexity\r\nsignificantly increases the chances for the attackers to effectively reuse 1/N-day vulnerabilities (“The Firmware\r\nSupply-Chain Security is broken: Can we fix it?”.\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/A_deeper_UEFI_dive_into_MoonBounce/index.html\r\nhttps://www.binarly.io/posts/A_deeper_UEFI_dive_into_MoonBounce/index.html\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.binarly.io/posts/A_deeper_UEFI_dive_into_MoonBounce/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": 1775434650, "ts_updated_at": 1775826774, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/d17d7a58671e1c59d85d396e61f8408fe9615b63.pdf", "text": "https://archive.orkl.eu/d17d7a58671e1c59d85d396e61f8408fe9615b63.txt", "img": "https://archive.orkl.eu/d17d7a58671e1c59d85d396e61f8408fe9615b63.jpg" } }