BlackX UEFI Bootkit Abuses Baton Drop to Bypass Secure Boot — Detection, Hunting, and Remediation Guide for 2026

A new UEFI bootkit dubbed BlackX has been observed in an espionage campaign running since early 2026, and it is resurrecting a technique that many defenders assumed was behind us: the Baton Drop vulnerability, used to bypass Secure Boot and load a malicious driver before the operating system — and its security stack — ever comes up. Once resident, BlackX's payload specifically targets and interferes with endpoint security products from Kaspersky and Avast, effectively blinding the very tooling defenders rely on to spot it.

This is not a historical curiosity. An old flaw being re-weaponized in an active espionage campaign is exactly the kind of event that should trigger a posture review: revocation lists, Secure Boot configuration drift, firmware-level visibility, and EDR tamper protection all come into scope. If your organization runs Kaspersky or Avast — common in European, Latin American, and SMB environments — you are in the blast radius of this campaign's anti-detection logic.

Why This Matters Right Now

• Secure Boot is not a panacea. Baton Drop demonstrated years ago that signed-but-vulnerable boot components can be abused to defeat the trust chain. BlackX proves threat actors still find value in that path.
• Pre-OS persistence defeats most IR playbooks. A bootkit survives OS reinstallation and evades in-OS detection. If you reimage an infected machine without addressing the boot path, you've done nothing.
• Targeted EDR interference is a hallmark of espionage tradecraft. Campaigns that bother to neuter specific AV products are resourced, patient, and interested in long dwell time — not smash-and-grab.

Technical Analysis

The Attack Chain (Defender's View)

Based on the reported behavior, BlackX follows a classic bootkit kill chain:

1. Initial access and privilege escalation. The operator gains administrative or SYSTEM-level execution on the target host through conventional means (phishing, exposed services, or prior-stage malware). Bootkit installation requires elevated privileges to write to the EFI System Partition (ESP) or modify boot configuration.
2. Abuse of the Baton Drop weakness. Baton Drop is a flaw class in which a legitimately signed, vulnerable bootloader or boot application can be leveraged to break the Secure Boot chain of trust. By introducing the vulnerable signed component into the boot path, BlackX gains the ability to execute unsigned code at boot — the signature checks pass because the vulnerable shim/bootloader itself is validly signed.
3. Malicious driver load at boot time. With Secure Boot effectively bypassed, BlackX loads a malicious kernel driver before the OS security stack initializes. Boot-time drivers run with the highest privilege and the earliest execution — before most EDR sensor callbacks register.
4. Security product interference. The driver then specifically disrupts Kaspersky and Avast components — blocking driver load, unhooking or corrupting their callbacks, terminating or hollowing their service processes, or preventing their self-protection mechanisms from engaging. The result: the products appear installed and 'running' while providing little or no actual telemetry.

Affected Environment

• Platforms: UEFI-based Windows systems (the ESP-write and Secure Boot bypass components are Windows-boot-chain specific).
• Security products targeted: Kaspersky endpoint products and Avast (consumer and business lines).
• Prerequisites for the attacker: Administrative privileges on the host; ability to write to the EFI System Partition and modify boot entries (e.g., via bcdedit, mountvol, or direct ESP writes).
• Mitigating factor: Systems with up-to-date UEFI dbx revocation lists that blacklist the vulnerable signed boot components used in Baton Drop-style attacks are significantly harder to compromise this way. Microsoft has previously pushed dbx updates via Windows Update to revoke exactly these classes of bootloaders — but revocation deployment is notoriously inconsistent across enterprise fleets.

Exploitation Status

• Confirmed active exploitation: BlackX is deployed in a live espionage campaign as of early 2026.
• Attribution: Espionage-motivated actor; targeting and tradecraft indicate a resourced, persistent adversary.
• The reuse lesson: The vulnerable component being abused is an old, known weakness. Its continued viability in 2026 is a fleet-hygiene failure, not a zero-day failure. That distinction matters for how you respond.

Detection & Response

Bootkits are hard to detect from within a compromised OS — assume on-host telemetry may be lying to you. Layer your detection: (1) catch the installation behaviors (ESP access, boot configuration modification), (2) catch the EDR-tampering behaviors (interference with Kaspersky/Avast), and (3) hunt at scale for boot-path artifacts with out-of-band forensics.

Sigma Rules

---
title: EFI System Partition Mount or Boot Configuration Modification
description: Detects mounting of the EFI System Partition or modification of boot configuration data — prerequisite behaviors for UEFI bootkit installation such as BlackX.
references:
  - https://www.bleepingcomputer.com/news/security/blackx-uefi-bootkit-exploits-baton-drop-flaw-to-bypass-secure-boot/
  - https://attack.mitre.org/techniques/T1542/001/
author: Security Arsenal
date: 2026/04/06
id: 8f2b7c41-3d5e-4a90-b1f6-9c4d2e7a5b31
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_mountvol:
    Image|endswith: '\mountvol.exe'
    CommandLine|contains:
      - ' /s'
      - ': /s'
  selection_bcdedit:
    Image|endswith: '\bcdedit.exe'
    CommandLine|contains:
      - '{bootmgr}'
      - '{fwbootmgr}'
      - '/set'
      - 'path \EFI'
  selection_raw_disk:
    CommandLine|contains:
      - '\\.\PhysicalDrive'
      - '\\.\ESP'
  condition: 1 of selection_*
falsepositives:
  - Legitimate firmware update tooling from OEM vendors (Dell, Lenovo, HP update utilities)
  - IT provisioning and dual-boot configuration
level: high
---
title: Kaspersky or Avast Security Service Tampering
description: Detects process termination, service stop, or service control attempts against Kaspersky and Avast security components — behavior exhibited by the BlackX bootkit driver to blind endpoint defenses.
references:
  - https://www.bleepingcomputer.com/news/security/blackx-uefi-bootkit-exploits-baton-drop-flaw-to-bypass-secure-boot/
  - https://attack.mitre.org/techniques/T1562/001/
author: Security Arsenal
date: 2026/04/06
id: 3e9a1d62-7b4c-4f81-a2e5-6d8c1b4f9027
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_sc:
    Image|endswith:
      - '\sc.exe'
      - '\net.exe'
      - '\net1.exe'
    CommandLine|contains:
      - 'stop'
      - 'delete'
      - 'disable'
  selection_taskkill:
    Image|endswith: '\taskkill.exe'
    CommandLine|contains:
      - '/f'
      - '/im'
  selection_targets:
    CommandLine|contains:
      - 'avp'
      - 'kavfs'
      - 'klnagent'
      - 'AvastSvc'
      - 'aswidsagent'
      - 'afwserv'
      - 'avast'
  condition:
    - selection_sc and selection_targets
    - selection_taskkill and selection_targets
falsepositives:
  - Legitimate AV uninstallation or migration performed by IT
  - Software deployment tools reconfiguring endpoint agents
level: high
---
title: Unsigned or Revoked Boot-Component Driver Load
description: Detects loading of drivers whose signature verification failed or whose signing certificate has been revoked — consistent with Secure Boot bypass payloads such as the BlackX boot-time driver. Requires Sysmon driver load or code integrity logging.
references:
  - https://www.bleepingcomputer.com/news/security/blackx-uefi-bootkit-exploits-baton-drop-flaw-to-bypass-secure-boot/
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
id: 61c4f8a2-9d3b-4e57-b840-2f7a5c1e6d93
status: experimental
logsource:
  category: driver_load
  product: windows
detection:
  selection:
    SignatureStatus:
      - 'Unsigned'
      - 'Revoked'
      - 'Expired'
  filter_known_good:
    Signed: 'true'
  condition: selection and not filter_known_good
falsepositives:
  - Legacy hardware drivers
  - Internally developed unsigned test drivers in lab environments
level: high

A note on fidelity: the ESP-mount and bcdedit rule will fire occasionally in environments with aggressive OEM firmware update tooling. Baseline your fleet's legitimate updater behavior and tune by parent process before enabling at high severity. The AV-tampering rule, by contrast, should be near-zero noise — there is almost no legitimate reason for an interactive process to stop Kaspersky or Avast services outside a sanctioned migration window.

KQL Hunt — Microsoft Sentinel / Defender

The following query hunts across both installation behavior and AV-tampering behavior. It is designed for Defender XDR data (DeviceProcessEvents) but works in Sentinel workspaces ingesting those tables.

// Hunt: BlackX bootkit installation prerequisites + EDR tampering
// Covers ESP access, boot config modification, and Kaspersky/Avast interference
let avTargets = dynamic(["avp.exe", "avpsus.exe", "kavfs.exe", "klnagent.exe", "AvastSvc.exe", "aswidsagent.exe", "afwserv.exe", "avastui.exe"]);
union
(DeviceProcessEvents
 | where TimeGenerated > ago(14d)
 | where FileName in~ ("mountvol.exe", "bcdedit.exe")
 | where ProcessCommandLine has_any ("/s", "{bootmgr}", "{fwbootmgr}", "\\EFI")
 | project TimeGenerated, DeviceName, InitiatingProcessAccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, ReportId
 | extend HuntCategory = "BootPathModification"),
(DeviceProcessEvents
 | where TimeGenerated > ago(14d)
 | where FileName in~ ("sc.exe", "net.exe", "net1.exe", "taskkill.exe", "powershell.exe", "wmic.exe")
 | where ProcessCommandLine has_any ("avp", "kavfs", "klnagent", "AvastSvc", "aswidsagent", "afwserv", "avast")
 | where ProcessCommandLine has_any ("stop", "delete", "disable", "/f", "kill", "terminate")
 | project TimeGenerated, DeviceName, InitiatingProcessAccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, ReportId
 | extend HuntCategory = "AVTampering"),
(DeviceEvents
 | where TimeGenerated > ago(14d)
 | where ActionType == "ServiceStopped" or ActionType == "ServiceInstalled"
 | where AdditionalFields has_any ("avp", "AvastSvc", "avast", "kaspersky")
 | project TimeGenerated, DeviceName, ActionType, FileName, AdditionalFields, ReportId
 | extend HuntCategory = "AVServiceStateChange")
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Events = count() by DeviceName, HuntCategory, InitiatingProcessAccountName
| order by LastSeen desc

Correlate at the device level: a host that shows both boot-path modification and AV-tampering within a short window is a strong bootkit-suspicion candidate and should be escalated to DFIR immediately — do not rely on that host's own EDR console health status to clear it.

Velociraptor VQL Hunt

Bootkit investigation demands offline-capable forensics. This artifact hunts for recently modified files on the EFI System Partition and suspicious boot-path driver references — the artifacts BlackX must leave behind.

-- BlackX UEFI Bootkit Hunt: ESP modifications and suspicious boot drivers
-- Deploy after mounting the EFI System Partition (e.g., mountvol S: /s)
-- Adjust glob path to your mounted ESP letter

LET esp_files = SELECT
    FullPath,
    Size,
    Mtime,
    Btime
FROM glob(globs='S:/EFI/**/*.efi', accessor='file')
WHERE Mtime > ago(30d)
ORDER BY Mtime DESC

LET suspicious_drivers = SELECT
    FullPath,
    Size,
    Mtime,
    Btime
FROM glob(globs='C:/Windows/System32/drivers/*.sys', accessor='ntfs')
WHERE Mtime > ago(14d)
  AND FullPath !~ '(?i)(kav|avp|asw|avast)'
ORDER BY Mtime DESC

SELECT * FROM esp_files
UNION ALL
SELECT * FROM suspicious_drivers

Follow up on hits by collecting the .efi binaries and .sys drivers for offline static analysis and signature verification (Get-AuthenticodeSignature on a clean analysis host, or sbverify / pesign on Linux). Compare ESP contents against a known-good reference from a golden image of the same hardware model — ESP diffs are one of the most reliable bootkit tripwires available.

Remediation & Verification Script

# BlackX Bootkit Posture Check — Secure Boot, dbx revocation, ESP audit
# Run elevated. Produces a per-host posture report.

$report = [ordered]@{}

# 1. Confirm Secure Boot state
$report.SecureBootEnabled = try {
    Confirm-SecureBootUEFI
} catch {
    "Unknown (BIOS mode or error: $($_.Exception.Message))"
}

# 2. Check UEFI revocation (dbx) version — stale dbx = Baton Drop-class bypass viable
$secureBootDB = Get-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -ErrorAction SilentlyContinue
if ($secureBootDB) {
    $report.AvailableUpdates = ($secureBootDB.GetValue('AvailableUpdates'))
    $report.UEFICA2023Status = ($secureBootDB.GetValue('UEFICA2023Status'))
    $report.MicrosoftUpdateManagedOptIn = ($secureBootDB.GetValue('MicrosoftUpdateManagedOptIn'))
} else {
    $report.SecureBootRegKey = 'Missing — investigate'
}

# 3. Flag pending Secure Boot/dbx updates not yet applied
if ($report.AvailableUpdates -ne 0 -and $null -ne $report.AvailableUpdates) {
    Write-Warning 'Secure Boot dbx/KEK updates are available but NOT applied. Apply via Windows Update and reboot.'
}

# 4. Audit currently loaded drivers for unsigned/revoked signatures
$unsigned = Get-CimInstance Win32_SystemDriver | Where-Object { $_.State -eq 'Running' } | ForEach-Object {
    $path = $_.PathName -replace '\\\?\?\', '' -replace '\\SystemRoot', "$env:SystemRoot"
    if (Test-Path $path) {
        $sig = Get-AuthenticodeSignature -FilePath $path
        if ($sig.Status -notin @('Valid', 'NotSigned')) {
            [PSCustomObject]@{ Driver = $_.Name; Path = $path; SigStatus = $sig.Status; Signer = $sig.SignerCertificate.Subject }
        } elseif ($sig.Status -eq 'NotSigned') {
            [PSCustomObject]@{ Driver = $_.Name; Path = $path; SigStatus = 'UNSIGNED'; Signer = 'N/A' }
        }
    }
}
$report.UnsignedOrBadDrivers = $unsigned

# 5. Verify Kaspersky/Avast services are actually running and protected
$avServices = Get-Service -ErrorAction SilentlyContinue | Where-Object {
    $_.Name -match 'avp|kavfs|klnagent|AvastSvc|aswidsagent|afwserv|avast'
}
$report.AVServiceState = $avServices | Select-Object Name, Status, StartType

# 6. Mount ESP read-only style check: list recent .efi modifications
$espMounted = mountvol | Select-String 'EFI System Partition'
$report.ESPNote = 'For ESP file audit, mount with: mountvol S: /s  then compare against golden image'

$report | Format-List
if ($unsigned) { Write-Warning 'Unsigned or invalidly signed RUNNING drivers found — triage immediately.' }
if ($avServices | Where-Object Status -ne 'Running') { Write-Warning 'One or more AV services not running — possible tampering.' }

Remediation & Hardening

1. Apply the latest UEFI dbx revocation updates fleet-wide. Baton Drop-class attacks only work while the vulnerable signed boot components remain trusted. Microsoft distributes dbx updates through Windows Update; verify application with the registry check in the script above (HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot, AvailableUpdates should be 0 after updating and rebooting). Treat revocation deployment as a change-controlled activity — test on representative hardware first, as dbx updates can break dual-boot and some recovery tooling.
2. Migrate to the Windows UEFI CA 2023 certificate chain. Microsoft has been transitioning boot signing to the 2023 CA; devices still trusting only the legacy 2011 CA are exposed to the older, revoked-component abuse patterns. Follow Microsoft's Secure Boot certificate update guidance and validate UEFICA2023Status in the registry post-migration.
3. Enable and verify Secure Boot everywhere — and alert on its absence. Inventory every endpoint's Secure Boot state. A machine where Secure Boot is unexpectedly disabled, or where the state changed without a change ticket, is an incident, not a configuration note.
4. Restrict who can touch the boot path. Limit local admin rights; alert on bcdedit, mountvol /s, and raw disk access outside approved maintenance windows. Enable Windows Defender Credential Guard and VBS/HVCI where hardware supports it — these raise the cost of kernel-driver abuse considerably.
5. Assume on-host AV telemetry is compromised on suspect machines. Kaspersky and Avast users: cross-validate endpoint health from a second telemetry plane (Defender for Endpoint, network detection, DNS analytics). If the AV console says 'green' but the host shows tampering behaviors, trust the tampering signal.
6. Rebuild correctly after confirmed bootkit infection. Reimaging alone is insufficient. For confirmed BlackX infections: update/reflash UEFI firmware from vendor media, reset Secure Boot keys to factory defaults and re-enroll, apply current dbx revocations, then rebuild the OS from trusted media. Rotate all credentials that were ever present on the host.
7. Monitor for the espionage context. Because this campaign targets specific AV vendors, organizations in government, defense, critical infrastructure, and adjacent supply chains should treat any boot-path anomaly as a priority-one DFIR event and preserve ESP and firmware artifacts before remediation destroys them.

The uncomfortable truth BlackX reinforces: Secure Boot's trust chain is only as strong as your revocation hygiene. An attacker in 2026 is still cashing in on a flaw your fleet could have closed years ago. Close it now.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub