[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AET3Z5YNY8ASN3PDP18QHV":3,"skill-same:01M6AET3Z5YNY8ASN3PDP18QHV":107},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":63,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M6AET3Z5YNY8ASN3PDP18QHV","hunting-bootkits-in-efi-system-partition",null,"Baseline the EFI System Partition and hunt malicious EFI binaries such as ESPecter, BlackLotus, Bootkitty, and Glupteba by mounting the ESP, hashing and verifying boot loaders, scanning with YARA, and flagging anomalous non-EFI files or out-of-band bootloader changes. Use during proactive threat hunts for firmware\u002Fbootkit persistence (MITRE ATT&CK T1542.003) or when investigating suspected UEFI-level compromise that survives OS reinstall.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36146,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fhunting-bootkits-in-efi-system-partition\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"hunting bootkits in efi system partition","firmware","measured-boot","firmware-forensics","efi-system-partition","blacklotus","ATT&CK","hardware-firmware-security","ESP","Secure-Boot","malicious","yara","UEFI","bootkit","threat-hunting","forensics","boot","secure","cybersecurity","security","2026-11-10 10:12:30",false,"---\nname: hunting-bootkits-in-efi-system-partition\ndescription: Baseline the EFI System Partition and hunt malicious EFI binaries such as ESPecter, BlackLotus, Bootkitty, and Glupteba by mounting the ESP, hashing and verifying boot loaders, scanning with YARA, and flagging anomalous non-EFI files or out-of-band bootloader changes. Use during proactive threat hunts for firmware\u002Fbootkit persistence (MITRE ATT&CK T1542.003) or when investigating suspected UEFI-level compromise that survives OS reinstall.\ndomain: cybersecurity\nsubdomain: hardware-firmware-security\ntags:\n- bootkit\n- uefi\n- efi-system-partition\n- secure-boot\n- firmware-forensics\n- threat-hunting\n- yara\n- measured-boot\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- DE.CM-01\nmitre_attack:\n- T1542.003\n---\n# Hunting Bootkits in the EFI System Partition\n\n## Overview\n\nThe EFI System Partition (ESP) is a small FAT32-formatted partition that the platform firmware reads at power-on to locate and execute the operating system's boot loader. Because it executes *before* the operating system, kernel, and any EDR agent, the ESP is one of the most coveted persistence locations for advanced adversaries. UEFI bootkits that live on the ESP survive OS reinstallation, disk reformatting of the OS partition, and most endpoint defenses.\n\nThis skill follows the detection research published by **Eclypsium** (\"Enhanced Threat Detection: Bootloaders, Bootkits, and Secure Boot\", and the *Bootkitty* and *Glupteba* analyses) and aligns with the ESP-hunting methodology Rapid7 documented for Velociraptor (`Windows.Forensics.UEFI`, `Windows.Detection.Yara.UEFI`). The threat context is concrete and current:\n\n- **ESPecter** (ESET, 2021) — a UEFI bootkit that persists on the ESP as a patched Windows Boot Manager (`bootmgfw.efi`) plus malicious kernel-mode drivers. It marked the move of UEFI threats *from SPI flash to the ESP*, where they are far easier to deploy.\n- **BlackLotus** (2023) — the first in-the-wild UEFI bootkit able to bypass Secure Boot on fully patched Windows 11 by exploiting CVE-2022-21894 (\"baton drop\") and staging a vulnerable signed `bootmgfw.efi` on the ESP.\n- **Bootkitty** (2024) — the first UEFI bootkit targeting Linux, dropped onto the ESP.\n- **Glupteba** — commodity malware whose UEFI variant replaces software on the EFI partition.\n\nThe core detection insight from Eclypsium and Rapid7 is that the bootloader normally changes **only** during a vendor or OS update; an out-of-band change to ESP binaries, an unsigned or untrusted-signed boot loader, or any file in the ESP root that is *not* under the `EFI\u002F` directory is a high-fidelity indicator of compromise. This skill builds that baseline and hunts deviations from it.\n\n## When to Use\n\n- During proactive threat hunts for firmware\u002Fbootkit persistence (MITRE ATT&CK T1542.003 — Pre-OS Boot: Bootkit)\n- After an incident where an adversary achieved SYSTEM\u002Froot and may have established below-OS persistence\n- When validating Secure Boot posture across a fleet and confirming boot-chain integrity\n- As a periodic integrity check, comparing the current ESP contents against a trusted golden baseline\n- When triaging hosts that show measured-boot (TPM PCR) mismatches\n\n## Prerequisites\n\n- Administrative\u002Froot access to the target host (mounting and reading the ESP requires elevation)\n- Linux analysis tooling — install on Debian\u002FUbuntu:\n  ```bash\n  sudo apt-get update\n  sudo apt-get install -y sbsigntool pesign efitools efibootmgr binwalk yara\n  pip install pefile\n  ```\n- `UEFITool` for inspecting firmware\u002Fbinaries (download from https:\u002F\u002Fgithub.com\u002FLongSoft\u002FUEFITool\u002Freleases)\n- A trusted **golden baseline** of EFI binary hashes for the OS\u002Fvendor versions in scope (build it once on a known-clean, freshly imaged host)\n- For Windows targets: WinPE or a forensic boot environment, or Velociraptor with the `Windows.Forensics.UEFI` artifact\n\n## Objectives\n\n- Mount and enumerate the ESP read-only without altering evidence\n- Inventory every EFI binary and compute cryptographic hashes\n- Verify Secure Boot signatures on each boot loader against trusted keys\n- Compare contents against a golden baseline to surface out-of-band changes\n- YARA-scan ESP binaries for known bootkit signatures\n- Flag anomalies: files outside `EFI\u002F`, unsigned loaders, modified `bootmgfw.efi`\u002F`grubx64.efi`, and tampered boot entries\n- Confirm measured-boot (TPM PCR 0\u002F2\u002F4) integrity where TPM is present\n\n## MITRE ATT&CK Mapping\n\n| ID | Name | Relevance |\n|----|------|-----------|\n| T1542.003 | Pre-OS Boot: Bootkit | Adversaries place malicious boot loaders on the ESP to execute before the OS and EDR, achieving stealthy, resilient persistence. This skill hunts exactly that artifact. |\n\n## Workflow\n\n### Step 1: Identify and mount the ESP read-only\nThe ESP is a FAT32 partition, usually flagged `EF00` (GPT) or `esp,boot`. Locate it and mount read-only to preserve evidence.\n```bash\n# Identify the ESP (type code EF00 \u002F \"EFI System\")\nsudo lsblk -o NAME,FSTYPE,PARTTYPENAME,MOUNTPOINT\nsudo fdisk -l | grep -i \"EFI System\"\n\n# Mount the ESP read-only (replace \u002Fdev\u002Fsda1 with the identified partition)\nsudo mkdir -p \u002Fmnt\u002Fesp\nsudo mount -o ro,umask=077 \u002Fdev\u002Fsda1 \u002Fmnt\u002Fesp\n\n# Confirm the canonical layout: EFI\u002F should be the only top-level dir\nls -la \u002Fmnt\u002Fesp\n```\n\n### Step 2: Detect anomalous top-level entries (high-fidelity hunt)\nPer Rapid7\u002FVelociraptor guidance, the ESP root should contain **only** the `EFI\u002F` directory (and possibly a vendor `System Volume Information`). Anything else is suspicious.\n```bash\n# Any path in the ESP root NOT under EFI\u002F is a red flag\nfind \u002Fmnt\u002Fesp -maxdepth 1 -mindepth 1 ! -name 'EFI' ! -iname 'System Volume Information'\n\n# Hunt for boot binaries dropped outside expected vendor folders\nfind \u002Fmnt\u002Fesp -type f \\( -iname '*.efi' -o -iname '*.sys' -o -iname '*.dll' \\) -printf '%p\\t%s bytes\\t%TY-%Tm-%Td\\n'\n```\n\n### Step 3: Inventory and hash every EFI binary\nCompute SHA-256 of all boot binaries for baseline comparison and threat-intel lookup.\n```bash\n# Recursively hash all EFI\u002FPE binaries on the ESP\nfind \u002Fmnt\u002Fesp -type f \\( -iname '*.efi' -o -iname '*.sys' \\) -print0 \\\n  | xargs -0 sha256sum | tee \u002Ftmp\u002Fesp_hashes.txt\n\n# Quick triage on the primary loaders\nsha256sum \u002Fmnt\u002Fesp\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi 2>\u002Fdev\u002Fnull\nsha256sum \u002Fmnt\u002Fesp\u002FEFI\u002FBoot\u002Fbootx64.efi 2>\u002Fdev\u002Fnull\nsha256sum \u002Fmnt\u002Fesp\u002FEFI\u002F*\u002Fgrubx64.efi \u002Fmnt\u002Fesp\u002FEFI\u002F*\u002Fshimx64.efi 2>\u002Fdev\u002Fnull\n```\nSubmit unknown hashes to VirusTotal \u002F the LOLDrivers and Binarly catalogs to identify known-vulnerable or malicious loaders (e.g., the BlackLotus-abused `bootmgfw.efi` builds).\n\n### Step 4: Verify Secure Boot signatures on each loader\nA legitimate loader is signed by Microsoft UEFI CA (Windows\u002Fshim) or the distro vendor. Use `sbverify` to list\u002Fverify signatures and `pesign` for the certificate chain.\n```bash\n# List embedded signatures on a loader\nsbverify --list \u002Fmnt\u002Fesp\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi\n\n# Verify against the platform's db certificate (export it first)\nsudo efi-readvar -v db -o \u002Ftmp\u002Fdb.esl   # dump Secure Boot db\nsbverify --cert \u002Fpath\u002Fto\u002FMicrosoftUEFICA.pem \u002Fmnt\u002Fesp\u002FEFI\u002FBoot\u002Fbootx64.efi\n\n# Inspect the PE certificate chain\npesign -S -i \u002Fmnt\u002Fesp\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi\n```\nAn **unsigned** loader, a loader signed by an unexpected\u002Fself-signed certificate, or a known-vulnerable signed binary staged by an attacker (BlackLotus technique) is a confirmed finding.\n\n### Step 5: Compare against the golden baseline\nDiff the live ESP hash inventory against a trusted baseline captured from a clean image of the same OS\u002Fvendor build.\n```bash\n# Sort both inventories on the hash column and diff\nawk '{print $1}' \u002Ftmp\u002Fesp_hashes.txt | sort > \u002Ftmp\u002Flive.sha256\nsort baseline_esp_hashes.sha256 > \u002Ftmp\u002Fbase.sha256\n\n# Hashes present live but absent from the baseline = unexpected\u002Fnew binaries\ncomm -23 \u002Ftmp\u002Flive.sha256 \u002Ftmp\u002Fbase.sha256\n```\nBecause the bootloader changes only during legitimate updates, any new hash that does not correspond to a known patch is an actionable lead.\n\n### Step 6: YARA-scan ESP binaries for bootkit signatures\nRun YARA rules for known bootkits (ESPecter, BlackLotus, Bootkitty, CosmicStrand) across the ESP — the same approach as Velociraptor's `Windows.Detection.Yara.UEFI`.\n```bash\n# Scan all ESP files recursively with a bootkit ruleset\nyara -r -w bootkit_rules.yar \u002Fmnt\u002Fesp\u002F\n\n# Example: scan only the binaries collected in Step 3\nyara -r bootkit_rules.yar \u002Fmnt\u002Fesp\u002FEFI\u002F\n```\nSource rules from the YARA-Rules project, Eclypsium\u002FBinarly publications, and ESET's bootkit reports.\n\n### Step 7: Inspect and validate UEFI boot entries\nESPecter-class bootkits manipulate the boot order\u002Fentries. Enumerate NVRAM boot variables and confirm each points to an expected, signed loader.\n```bash\n# List boot entries and the current order (Bootkitty\u002FESPecter tamper here)\nsudo efibootmgr -v\n\n# Confirm Secure Boot is enabled and look for revoked hashes in dbx\nmokutil --sb-state\nsudo efi-readvar -v dbx -o \u002Ftmp\u002Fdbx.esl\n```\nA boot entry referencing a file outside `\\EFI\\` or a loader whose hash appears in `dbx` (revoked) but is still present indicates tampering.\n\n### Step 8: Validate measured boot against TPM PCRs (where available)\nMeasured boot records the boot-chain components into TPM PCRs (notably PCR 0, 2, 4). A bootkit that alters loaders changes these measurements.\n```bash\n# Read PCRs that cover firmware and the boot loader\nsudo tpm2_pcrread sha256:0,2,4,7\n\n# Parse the TCG event log to see what was measured into each PCR\nsudo tpm2_eventlog \u002Fsys\u002Fkernel\u002Fsecurity\u002Ftpm0\u002Fbinary_bios_measurements\n```\nCompare measured values against the host's known-good attestation baseline; an unexplained PCR 4 change correlates with a modified boot loader.\n\n### Step 9: Document findings and preserve evidence\n```bash\n# Make a forensic image of the ESP for offline analysis before remediation\nsudo dd if=\u002Fdev\u002Fsda1 of=\u002Fevidence\u002Fesp_$(hostname)_$(date +%F).img bs=4M conv=noerror,sync\nsha256sum \u002Fevidence\u002Fesp_*.img > \u002Fevidence\u002Fesp_image.sha256\nsudo umount \u002Fmnt\u002Fesp\n```\nRecord every anomalous binary (path, hash, signature status, baseline diff result, YARA match) in the case file before any cleanup.\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| sbsigntool (`sbverify`) | List\u002Fverify Secure Boot signatures on EFI binaries | https:\u002F\u002Fgit.kernel.org\u002Fpub\u002Fscm\u002Flinux\u002Fkernel\u002Fgit\u002Fjejb\u002Fsbsigntools.git |\n| pesign | Inspect PE\u002FCOFF signatures and certificate chains | https:\u002F\u002Fgithub.com\u002Frhboot\u002Fpesign |\n| efitools (`efi-readvar`) | Dump Secure Boot variables (db\u002Fdbx\u002FKEK\u002FPK) | https:\u002F\u002Fgit.kernel.org\u002Fpub\u002Fscm\u002Flinux\u002Fkernel\u002Fgit\u002Fjejb\u002Fefitools.git |\n| efibootmgr \u002F mokutil | Enumerate boot entries and Secure Boot state | https:\u002F\u002Fgithub.com\u002Frhboot\u002Fefibootmgr |\n| UEFITool | Parse and inspect UEFI binaries\u002Ffirmware | https:\u002F\u002Fgithub.com\u002FLongSoft\u002FUEFITool |\n| YARA | Signature-scan ESP binaries for bootkits | https:\u002F\u002Fgithub.com\u002FVirusTotal\u002Fyara |\n| tpm2-tools | Read PCRs and TCG event log for measured boot | https:\u002F\u002Fgithub.com\u002Ftpm2-software\u002Ftpm2-tools |\n| Velociraptor `Windows.Forensics.UEFI` | Scale ESP hunting across a fleet | https:\u002F\u002Fdocs.velociraptor.app\u002F |\n| Eclypsium bootkit research | Threat context and detection methodology | https:\u002F\u002Feclypsium.com\u002Fblog\u002Fthreat-detection-bootloaders-bootkits-secureboot\u002F |\n| Rapid7 UEFI hunting blog | ESP hunting with Velociraptor artifacts | https:\u002F\u002Fwww.rapid7.com\u002Fblog\u002Fpost\u002F2024\u002F02\u002F29\u002Fhow-to-hunt-for-uefi-malware-using-velociraptor\u002F |\n\n## Known Bootkit Indicators\n\n| Bootkit | ESP Artifact \u002F Behavior | Reference |\n|---------|-------------------------|-----------|\n| ESPecter | Patched `bootmgfw.efi` + kernel drivers on ESP | ESET WeLiveSecurity 2021 |\n| BlackLotus | Vulnerable signed `bootmgfw.efi` staged to bypass Secure Boot (CVE-2022-21894) | ESET 2023 |\n| Bootkitty | Malicious EFI loader on ESP targeting Linux | ESET \u002F Eclypsium 2024 |\n| Glupteba (UEFI) | Replaces software on the EFI partition | Eclypsium |\n| CosmicStrand | UEFI firmware implant hooking the boot chain | Eclypsium \u002F Kaspersky |\n\n## Validation Criteria\n\n- [ ] ESP located and mounted read-only without modifying evidence\n- [ ] Top-level ESP contents enumerated; any non-`EFI\u002F` entries flagged\n- [ ] All EFI binaries inventoried with SHA-256 hashes\n- [ ] Secure Boot signatures verified on every boot loader\n- [ ] Live inventory diffed against a trusted golden baseline\n- [ ] YARA bootkit ruleset run across the ESP with no unexplained matches\n- [ ] Boot entries (`efibootmgr`) validated; no references outside `\\EFI\\`\n- [ ] Secure Boot confirmed enabled; no present binary matches a `dbx`-revoked hash\n- [ ] TPM PCR 0\u002F2\u002F4 measurements compared to baseline (where TPM present)\n- [ ] Forensic ESP image preserved and all findings documented\n","# Hunting Bootkits in the EFI System Partition\n\n## Overview\n\nThe EFI System Partition (ESP) is a small FAT32-formatted partition that the platform firmware reads at power-on to locate and execute the operating system's boot loader. Because it executes *before* the operating system, kernel, and any EDR agent, the ESP is one of the most coveted persistence locations for advanced adversaries. UEFI bootkits that live on the ESP survive OS reinstallation, disk reformatting of the OS partition, and most endpoint defenses.\n\nThis skill follows the detection research published by **Eclypsium** (\"Enhanced Threat Detection: Bootloaders, Bootkits, and Secure Boot\", and the *Bootkitty* and *Glupteba* analyses) and aligns with the ESP-hunting methodology Rapid7 documented for Velociraptor (`Windows.Forensics.UEFI`, `Windows.Detection.Yara.UEFI`). The threat context is concrete and current:\n\n- **ESPecter** (ESET, 2021) — a UEFI bootkit that persists on the ESP as a patched Windows Boot Manager (`bootmgfw.efi`) plus malicious kernel-mode drivers. It marked the move of UEFI threats *from SPI flash to the ESP*, where they are far easier to deploy.\n- **BlackLotus** (2023) — the first in-the-wild UEFI bootkit able to bypass Secure Boot on fully patched Windows 11 by exploiting CVE-2022-21894 (\"baton drop\") and staging a vulnerable signed `bootmgfw.efi` on the ESP.\n- **Bootkitty** (2024) — the first UEFI bootkit targeting Linux, dropped onto the ESP.\n- **Glupteba** — commodity malware whose UEFI variant replaces software on the EFI partition.\n\nThe core detection insight from Eclypsium and Rapid7 is that the bootloader normally changes **only** during a vendor or OS update; an out-of-band change to ESP binaries, an unsigned or untrusted-signed boot loader, or any file in the ESP root that is *not* under the `EFI\u002F` directory is a high-fidelity indicator of compromise. This skill builds that baseline and hunts deviations from it.\n\n## When to Use\n\n- During proactive threat hunts for firmware\u002Fbootkit persistence (MITRE ATT&CK T1542.003 — Pre-OS Boot: Bootkit)\n- After an incident where an adversary achieved SYSTEM\u002Froot and may have established below-OS persistence\n- When validating Secure Boot posture across a fleet and confirming boot-chain integrity\n- As a periodic integrity check, comparing the current ESP contents against a trusted golden baseline\n- When triaging hosts that show measured-boot (TPM PCR) mismatches\n\n## Prerequisites\n\n- Administrative\u002Froot access to the target host (mounting and reading the ESP requires elevation)\n- Linux analysis tooling — install on Debian\u002FUbuntu:\n  ```bash\n  sudo apt-get update\n  sudo apt-get install -y sbsigntool pesign efitools efibootmgr binwalk yara\n  pip install pefile\n  ```\n- `UEFITool` for inspecting firmware\u002Fbinaries (download from https:\u002F\u002Fgithub.com\u002FLongSoft\u002FUEFITool\u002Freleases)\n- A trusted **golden baseline** of EFI binary hashes for the OS\u002Fvendor versions in scope (build it once on a known-clean, freshly imaged host)\n- For Windows targets: WinPE or a forensic boot environment, or Velociraptor with the `Windows.Forensics.UEFI` artifact\n\n## Objectives\n\n- Mount and enumerate the ESP read-only without altering evidence\n- Inventory every EFI binary and compute cryptographic hashes\n- Verify Secure Boot signatures on each boot loader against trusted keys\n- Compare contents against a golden baseline to surface out-of-band changes\n- YARA-scan ESP binaries for known bootkit signatures\n- Flag anomalies: files outside `EFI\u002F`, unsigned loaders, modified `bootmgfw.efi`\u002F`grubx64.efi`, and tampered boot entries\n- Confirm measured-boot (TPM PCR 0\u002F2\u002F4) integrity where TPM is present\n\n## MITRE ATT&CK Mapping\n\n| ID | Name | Relevance |\n|----|------|-----------|\n| T1542.003 | Pre-OS Boot: Bootkit | Adversaries place malicious boot loaders on the ESP to execute before the OS and EDR, achieving stealthy, resilient persistence. This skill hunts exactly that artifact. |\n\n## Workflow\n\n### Step 1: Identify and mount the ESP read-only\nThe ESP is a FAT32 partition, usually flagged `EF00` (GPT) or `esp,boot`. Locate it and mount read-only to preserve evidence.\n```bash\n# Identify the ESP (type code EF00 \u002F \"EFI System\")\nsudo lsblk -o NAME,FSTYPE,PARTTYPENAME,MOUNTPOINT\nsudo fdisk -l | grep -i \"EFI System\"\n\n# Mount the ESP read-only (replace \u002Fdev\u002Fsda1 with the identified partition)\nsudo mkdir -p \u002Fmnt\u002Fesp\nsudo mount -o ro,umask=077 \u002Fdev\u002Fsda1 \u002Fmnt\u002Fesp\n\n# Confirm the canonical layout: EFI\u002F should be the only top-level dir\nls -la \u002Fmnt\u002Fesp\n```\n\n### Step 2: Detect anomalous top-level entries (high-fidelity hunt)\nPer Rapid7\u002FVelociraptor guidance, the ESP root should contain **only** the `EFI\u002F` directory (and possibly a vendor `System Volume Information`). Anything else is suspicious.\n```bash\n# Any path in the ESP root NOT under EFI\u002F is a red flag\nfind \u002Fmnt\u002Fesp -maxdepth 1 -mindepth 1 ! -name 'EFI' ! -iname 'System Volume Information'\n\n# Hunt for boot binaries dropped outside expected vendor folders\nfind \u002Fmnt\u002Fesp -type f \\( -iname '*.efi' -o -iname '*.sys' -o -iname '*.dll' \\) -printf '%p\\t%s bytes\\t%TY-%Tm-%Td\\n'\n```\n\n### Step 3: Inventory and hash every EFI binary\nCompute SHA-256 of all boot binaries for baseline comparison and threat-intel lookup.\n```bash\n# Recursively hash all EFI\u002FPE binaries on the ESP\nfind \u002Fmnt\u002Fesp -type f \\( -iname '*.efi' -o -iname '*.sys' \\) -print0 \\\n  | xargs -0 sha256sum | tee \u002Ftmp\u002Fesp_hashes.txt\n\n# Quick triage on the primary loaders\nsha256sum \u002Fmnt\u002Fesp\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi 2>\u002Fdev\u002Fnull\nsha256sum \u002Fmnt\u002Fesp\u002FEFI\u002FBoot\u002Fbootx64.efi 2>\u002Fdev\u002Fnull\nsha256sum \u002Fmnt\u002Fesp\u002FEFI\u002F*\u002Fgrubx64.efi \u002Fmnt\u002Fesp\u002FEFI\u002F*\u002Fshimx64.efi 2>\u002Fdev\u002Fnull\n```\nSubmit unknown hashes to VirusTotal \u002F the LOLDrivers and Binarly catalogs to identify known-vulnerable or malicious loaders (e.g., the BlackLotus-abused `bootmgfw.efi` builds).\n\n### Step 4: Verify Secure Boot signatures on each loader\nA legitimate loader is signed by Microsoft UEFI CA (Windows\u002Fshim) or the distro vendor. Use `sbverify` to list\u002Fverify signatures and `pesign` for the certificate chain.\n```bash\n# List embedded signatures on a loader\nsbverify --list \u002Fmnt\u002Fesp\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi\n\n# Verify against the platform's db certificate (export it first)\nsudo efi-readvar -v db -o \u002Ftmp\u002Fdb.esl   # dump Secure Boot db\nsbverify --cert \u002Fpath\u002Fto\u002FMicrosoftUEFICA.pem \u002Fmnt\u002Fesp\u002FEFI\u002FBoot\u002Fbootx64.efi\n\n# Inspect the PE certificate chain\npesign -S -i \u002Fmnt\u002Fesp\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi\n```\nAn **unsigned** loader, a loader signed by an unexpected\u002Fself-signed certificate, or a known-vulnerable signed binary staged by an attacker (BlackLotus technique) is a confirmed finding.\n\n### Step 5: Compare against the golden baseline\nDiff the live ESP hash inventory against a trusted baseline captured from a clean image of the same OS\u002Fvendor build.\n```bash\n# Sort both inventories on the hash column and diff\nawk '{print $1}' \u002Ftmp\u002Fesp_hashes.txt | sort > \u002Ftmp\u002Flive.sha256\nsort baseline_esp_hashes.sha256 > \u002Ftmp\u002Fbase.sha256\n\n# Hashes present live but absent from the baseline = unexpected\u002Fnew binaries\ncomm -23 \u002Ftmp\u002Flive.sha256 \u002Ftmp\u002Fbase.sha256\n```\nBecause the bootloader changes only during legitimate updates, any new hash that does not correspond to a known patch is an actionable lead.\n\n### Step 6: YARA-scan ESP binaries for bootkit signatures\nRun YARA rules for known bootkits (ESPecter, BlackLotus, Bootkitty, CosmicStrand) across the ESP — the same approach as Velociraptor's `Windows.Detection.Yara.UEFI`.\n```bash\n# Scan all ESP files recursively with a bootkit ruleset\nyara -r -w bootkit_rules.yar \u002Fmnt\u002Fesp\u002F\n\n# Example: scan only the binaries collected in Step 3\nyara -r bootkit_rules.yar \u002Fmnt\u002Fesp\u002FEFI\u002F\n```\nSource rules from the YARA-Rules project, Eclypsium\u002FBinarly publications, and ESET's bootkit reports.\n\n### Step 7: Inspect and validate UEFI boot entries\nESPecter-class bootkits manipulate the boot order\u002Fentries. Enumerate NVRAM boot variables and confirm each points to an expected, signed loader.\n```bash\n# List boot entries and the current order (Bootkitty\u002FESPecter tamper here)\nsudo efibootmgr -v\n\n# Confirm Secure Boot is enabled and look for revoked hashes in dbx\nmokutil --sb-state\nsudo efi-readvar -v dbx -o \u002Ftmp\u002Fdbx.esl\n```\nA boot entry referencing a file outside `\\EFI\\` or a loader whose hash appears in `dbx` (revoked) but is still present indicates tampering.\n\n### Step 8: Validate measured boot against TPM PCRs (where available)\nMeasured boot records the boot-chain components into TPM PCRs (notably PCR 0, 2, 4). A bootkit that alters loaders changes these measurements.\n```bash\n# Read PCRs that cover firmware and the boot loader\nsudo tpm2_pcrread sha256:0,2,4,7\n\n# Parse the TCG event log to see what was measured into each PCR\nsudo tpm2_eventlog \u002Fsys\u002Fkernel\u002Fsecurity\u002Ftpm0\u002Fbinary_bios_measurements\n```\nCompare measured values against the host's known-good attestation baseline; an unexplained PCR 4 change correlates with a modified boot loader.\n\n### Step 9: Document findings and preserve evidence\n```bash\n# Make a forensic image of the ESP for offline analysis before remediation\nsudo dd if=\u002Fdev\u002Fsda1 of=\u002Fevidence\u002Fesp_$(hostname)_$(date +%F).img bs=4M conv=noerror,sync\nsha256sum \u002Fevidence\u002Fesp_*.img > \u002Fevidence\u002Fesp_image.sha256\nsudo umount \u002Fmnt\u002Fesp\n```\nRecord every anomalous binary (path, hash, signature status, baseline diff result, YARA match) in the case file before any cleanup.\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| sbsigntool (`sbverify`) | List\u002Fverify Secure Boot signatures on EFI binaries | https:\u002F\u002Fgit.kernel.org\u002Fpub\u002Fscm\u002Flinux\u002Fkernel\u002Fgit\u002Fjejb\u002Fsbsigntools.git |\n| pesign | Inspect PE\u002FCOFF signatures and certificate chains | https:\u002F\u002Fgithub.com\u002Frhboot\u002Fpesign |\n| efitools (`efi-readvar`) | Dump Secure Boot variables (db\u002Fdbx\u002FKEK\u002FPK) | https:\u002F\u002Fgit.kernel.org\u002Fpub\u002Fscm\u002Flinux\u002Fkernel\u002Fgit\u002Fjejb\u002Fefitools.git |\n| efibootmgr \u002F mokutil | Enumerate boot entries and Secure Boot state | https:\u002F\u002Fgithub.com\u002Frhboot\u002Fefibootmgr |\n| UEFITool | Parse and inspect UEFI binaries\u002Ffirmware | https:\u002F\u002Fgithub.com\u002FLongSoft\u002FUEFITool |\n| YARA | Signature-scan ESP binaries for bootkits | https:\u002F\u002Fgithub.com\u002FVirusTotal\u002Fyara |\n| tpm2-tools | Read PCRs and TCG event log for measured boot | https:\u002F\u002Fgithub.com\u002Ftpm2-software\u002Ftpm2-tools |\n| Velociraptor `Windows.Forensics.UEFI` | Scale ESP hunting across a fleet | https:\u002F\u002Fdocs.velociraptor.app\u002F |\n| Eclypsium bootkit research | Threat context and detection methodology | https:\u002F\u002Feclypsium.com\u002Fblog\u002Fthreat-detection-bootloaders-bootkits-secureboot\u002F |\n| Rapid7 UEFI hunting blog | ESP hunting with Velociraptor artifacts | https:\u002F\u002Fwww.rapid7.com\u002Fblog\u002Fpost\u002F2024\u002F02\u002F29\u002Fhow-to-hunt-for-uefi-malware-using-velociraptor\u002F |\n\n## Known Bootkit Indicators\n\n| Bootkit | ESP Artifact \u002F Behavior | Reference |\n|---------|-------------------------|-----------|\n| ESPecter | Patched `bootmgfw.efi` + kernel drivers on ESP | ESET WeLiveSecurity 2021 |\n| BlackLotus | Vulnerable signed `bootmgfw.efi` staged to bypass Secure Boot (CVE-2022-21894) | ESET 2023 |\n| Bootkitty | Malicious EFI loader on ESP targeting Linux | ESET \u002F Eclypsium 2024 |\n| Glupteba (UEFI) | Replaces software on the EFI partition | Eclypsium |\n| CosmicStrand | UEFI firmware implant hooking the boot chain | Eclypsium \u002F Kaspersky |\n\n## Validation Criteria\n\n- [ ] ESP located and mounted read-only without modifying evidence\n- [ ] Top-level ESP contents enumerated; any non-`EFI\u002F` entries flagged\n- [ ] All EFI binaries inventoried with SHA-256 hashes\n- [ ] Secure Boot signatures verified on every boot loader\n- [ ] Live inventory diffed against a trusted golden baseline\n- [ ] YARA bootkit ruleset run across the ESP with no unexplained matches\n- [ ] Boot entries (`efibootmgr`) validated; no references outside `\\EFI\\`\n- [ ] Secure Boot confirmed enabled; no present binary matches a `dbx`-revoked hash\n- [ ] TPM PCR 0\u002F2\u002F4 measurements compared to baseline (where TPM present)\n- [ ] Forensic ESP image preserved and all findings documented\n",{"name":5,"tags":49,"author":52,"domain":42,"license":15,"version":53,"nist_csf":54,"subdomain":31,"description":7,"mitre_attack":56},[37,50,28,51,27,38,35,26],"uefi","secure-boot","mahipal","1.0",[55],"DE.CM-01",[57],"T1542.003","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fhunting-bootkits-in-efi-system-partition",4425,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill hunting-bootkits-in-efi-system-partition",{"tool":74,"command":75},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill hunting-bootkits-in-efi-system-partition",{"tool":77,"command":78},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill hunting-bootkits-in-efi-system-partition","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fhunting-bootkits-in-efi-system-partition\u002FSKILL.md",true,[82,87,93,97,101],{"path":83,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fhunting-bootkits-in-efi-system-partition\u002FLICENSE",{"path":88,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":92},"reference\u002Frbac-idor.md","REFERENCE","参考文档",3918,"https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdjango-security\u002Freference\u002Frbac-idor.md",{"path":94,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fapi-reference.md",2769,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fhunting-bootkits-in-efi-system-partition\u002Freferences\u002Fapi-reference.md",{"path":98,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fstandards.md",1445,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fhunting-bootkits-in-efi-system-partition\u002Freferences\u002Fstandards.md",{"path":102,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"scripts\u002Fagent.py","SCRIPT","脚本",6112,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fhunting-bootkits-in-efi-system-partition\u002Fscripts\u002Fagent.py",[108,134,155,183,209,236],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":115,"publishedAt":44},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[114],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[116,117,118,119,43,42,120,121,122,123,124,125,126,127,128,129,130,131,132,133],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","identity","pr","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":44},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[140],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[40,130,142,143,43,144,42,122,145,146,25,147,26,148,149,150,151,152,153,154],"TPM","validating tpm measured boot attestation","policy","verification","ZeRO","Tools","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":165,"publishedAt":44},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[161,164],{"categoryNo":162,"categoryName":163,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[149,166,167,168,169,42,170,171,145,172,173,174,175,176,177,178,179,180,181,182],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":190,"publishedAt":44},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[189],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[191,192,193,42,194,195,196,197,198,199,200,201,202,203,204,205,147,206,207,208],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":216,"publishedAt":44},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[215],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[217,218,219,42,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":237,"name":238,"nameZh":6,"description":239,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":240,"categories":241,"keywords":243,"publishedAt":44},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[242],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[43,244,42,245,246,247,248,249,250,251,252,178,253,179,254,255,256,257,258,259],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]