Loading story…
Splunk published new endpoint detections for suspicious changes to Linux EFI boot components that could indicate bootkit installation, firmware-level persistence, or tampering with the system boot chain. One analytic flags deletion of .efi files in /boot/efi/EFI/BOOT/, while another monitors processes that modify files in the EFI boot volume using EDR telemetry such as process GUIDs, parent-child relationships, and full command-line logging. Splunk said both behaviors are unusual in normal operations, though legitimate administrator activity, package updates, OS reinstalls, and tools such as grub or shim may generate false positives.
The detections map to MITRE ATT&CK Pre-OS Boot techniques T1542.001 and T1542.003, which cover malicious changes to system firmware and bootkits that execute before the operating system loads. MITRE notes that attackers can persist by overwriting legacy BIOS boot records such as the MBR or VBR, or by creating or modifying files in the EFI System Partition (ESP) on UEFI systems so attacker-controlled code runs during boot. Splunk also linked the bootloader-modification analytic to CVE-2024-7344, underscoring concern that EFI boot artifacts remain a high-value target for stealthy persistence and difficult-to-remediate compromise.
See real exploitation activity before you spend the cycle.
3 events from the most recent confirmed update back to the earliest known activity.
Splunk updated and published the "Linux Possible Bootloader Modification" analytic for Linux, which monitors processes modifying files in the EFI boot volume. The analytic is intended to surface unusual EFI boot file changes that may indicate bootkit activity or firmware persistence.
Splunk published the "Linux EFI Bootloader File Deletion" analytic to detect deleted .efi files under /boot/efi/EFI/BOOT/ on Linux. The detection is framed as a way to identify possible bootkit installation, firmware-level persistence, or tampering with the boot process.
MITRE ATT&CK published the T1542.001 System Firmware sub-technique entry covering firmware-level persistence behavior. This reference provides the ATT&CK technique context later used by related detections.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See real exploitation activity behind this advisory so you can triage it against everything else in the queue.
4 references tracked. Mallory keeps watching after this page renders.
research.splunk.com
Open sourceresearch.splunk.com
Open sourceattack.mitre.org
Open sourceattack.mitre.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers previously disclosed **LogoFAIL**, a broad set of UEFI image-parsing flaws that can let attackers execute code during the DXE boot phase by abusing OEM logo customization paths. The vulnerabilities affect parsers for formats including BMP, GIF, PNG, JPEG, PCX, and TGA, and can be triggered from attacker-controlled sources such as the EFI System Partition, firmware update volumes, or NVRAM. Binarly reported 29 root causes, including 15 likely exploitable issues, and demonstrated arbitrary code execution on a Lenovo ThinkCentre M70s Gen 2 via an AMI PNG parser flaw. The weaknesses can bypass protections such as **Secure Boot**, Intel Boot Guard, AMD hardware-validated boot, and ARM TrustZone-based verification, with impact spanning firmware from major BIOS and device vendors. Subsequent reporting said the **BootKitty** malware family exploited LogoFAIL to infect **Linux** systems, marking a notable evolution from a theoretical firmware weakness into active bootkit tradecraft. Coverage described the attack path as exceptionally difficult to detect or remove because it operates in UEFI before the operating system loads, allowing persistence below traditional endpoint defenses. The case also undercut assumptions that Linux systems are insulated from modern UEFI bootkits, showing that firmware-level compromise can survive OS reinstallations and evade both software- and hardware-based security controls.
Jun 29, 2026
ESET disclosed that **11 outdated Microsoft-signed Linux `shim` bootloaders** could be abused to bypass **UEFI Secure Boot** on systems that trust the **Microsoft Corporation UEFI CA 2011** certificate. The issue affects UEFI-based machines regardless of installed operating system because an attacker can introduce an old but still-trusted signed binary even if the device never originally shipped with it. Researchers said the vulnerable shims can trust insecure second-stage loaders such as **GRUB 2**, lack later protections including **MOK denylist enforcement** and **SBAT** support, and could let an attacker with administrative access or boot-process control run arbitrary code during early boot and install persistent UEFI bootkits such as **BlackLotus**, **Bootkitty**, or **HybridPetya**.
Aug 11, 2026
**BlackLotus** was identified as the first publicly known UEFI bootkit seen in the wild that can bypass **UEFI Secure Boot** on fully patched Windows 11 systems by exploiting `CVE-2022-21894` and abusing legitimate Microsoft-signed boot binaries that were not added to the UEFI revocation database (`dbx`). ESET reported that the malware disables protections including **HVCI** and **BitLocker**, installs components to the EFI System Partition, enrolls an attacker-controlled Machine Owner Key, and persists through the boot process before loading a malicious kernel driver and an HTTP downloader into `winlogon.exe`. The malware also protects its files from removal and supports command-and-control tasking for payload delivery, updates, and uninstall. Microsoft said devices that have not yet received the **Secure Boot 2023 certificates** will continue to boot and receive normal updates while the certificates are rolled out over the coming months. The certificate transition is required because older **2011 Secure Boot certificates**, including the **Microsoft Corporation KEK CA 2011**, have expired, and the newer certificates are needed to keep delivering `dbx` revocation updates that block vulnerable bootloaders and bootkits such as BlackLotus. Microsoft said some systems remain delayed because of firmware incompatibilities, OEM support limits, disabled Secure Boot, Legacy BIOS mode, or unsupported Windows 11 installs, but most users do not need urgent action unless Windows reports a firmware-related Secure Boot warning.
Aug 14, 2026