[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEHD34W465QBJD76XZCJ6F":3,"skill-same:01M6AEHD34W465QBJD76XZCJ6F":101},{"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":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6AEHD34W465QBJD76XZCJ6F","detecting-secure-boot-bypass",null,"Detect UEFI Secure Boot bypasses and bootkits such as BlackLotus and Bootkitty by verifying Secure Boot state, checking dbx revocation currency, and hashing EFI boot binaries against known-bad sets using mokutil, efi-readvar\u002Fdbxtool, CHIPSEC, sbverify\u002Fpesign, and Windows Confirm-SecureBootUEFI. Use when auditing fleet dbx rollout after a bootkit advisory or hunting for pre-OS persistence on a suspected-compromised endpoint.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35990,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-secure-boot-bypass\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],"detecting secure boot bypass","secure","boot","firmware","firmware-integrity","blacklotus","dbx-revocation","endpoint","hardware-firmware-security","chipsec","Secure-Boot","security","UEFI","bootkit","persistence","state","windows","cybersecurity","2026-11-10 10:12:30",false,"---\nname: detecting-secure-boot-bypass\ndescription: Detect UEFI Secure Boot bypasses and bootkits such as BlackLotus and\n  Bootkitty by verifying Secure Boot state, checking dbx revocation currency, and\n  hashing EFI boot binaries against known-bad sets using mokutil, efi-readvar\u002Fdbxtool,\n  CHIPSEC, sbverify\u002Fpesign, and Windows Confirm-SecureBootUEFI. Use when auditing\n  fleet dbx rollout after a bootkit advisory or hunting for pre-OS persistence on\n  a suspected-compromised endpoint.\ndomain: cybersecurity\nsubdomain: hardware-firmware-security\ntags:\n- hardware-firmware-security\n- secure-boot\n- uefi\n- bootkit\n- dbx-revocation\n- blacklotus\n- chipsec\n- firmware-integrity\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- DE.CM-01\nmitre_attack:\n- T1542.003\n---\n# Detecting Secure Boot Bypass\n\n> **Legal Notice:** Firmware and Secure Boot assessment must only be performed on systems you own or are explicitly authorized to test. CHIPSEC's write\u002Fmodify modes and EFI variable manipulation can brick hardware. Run destructive checks only in a lab. This skill is for defensive verification and authorized assessment.\n\n## Overview\n\nUEFI Secure Boot is the firmware-enforced trust chain that only permits boot components signed by keys in the platform's allow-list (db) and not present in the revocation list (dbx). Bootkits defeat this layer to gain pre-OS, persistent, kernel-level control that survives OS reinstalls and disk wipes. **BlackLotus** (2023) was the first publicly observed UEFI bootkit to bypass Secure Boot on fully patched Windows 11, abusing **CVE-2022-21894** (\"baton drop\") in a vulnerable, signed Windows boot manager to neutralize Secure Boot and disable BitLocker, HVCI, and Defender. **Bootkitty** (2024) was the first PoC UEFI bootkit targeting Linux. Microsoft's **CVE-2023-24932** addressed a related Secure Boot bypass that required a phased dbx (revocation) rollout because revoking the vulnerable boot managers can render systems unbootable if applied carelessly.\n\nThe core defensive insight is that patching the OS is **not sufficient** — the platform remains exploitable until the vulnerable, signed binaries are revoked in **dbx**. Detection therefore combines: (1) confirming Secure Boot is actually enabled, (2) verifying dbx is current and contains the relevant revocations, (3) checking the integrity and protection of Secure Boot EFI variables with CHIPSEC, (4) hashing on-disk EFI boot binaries and comparing them against the revocation list and known-bad sets, and (5) inspecting firmware\u002FESP for bootkit artifacts. This skill provides a cross-platform (Linux + Windows) workflow using `mokutil`, `efi-readvar`\u002F`dbxtool`, `chipsec`, `sbverify`\u002F`pesign`, and Windows `Confirm-SecureBootUEFI` \u002F `Get-SecureBootUEFI`.\n\n## When to Use\n\n- Verifying that an estate's Secure Boot configuration is enabled, locked, and current after the CVE-2023-24932 \u002F BlackLotus advisories.\n- Hunting for UEFI bootkit indicators on a suspected-compromised endpoint.\n- Validating that dbx revocations (e.g., vulnerable Windows boot managers, Kaspersky\u002Fother vulnerable bootloaders) have actually applied across the fleet.\n- Auditing firmware integrity and Secure Boot variable protections during a hardware security assessment.\n- Building a recurring measured\u002Fbaseline check for boot-chain tampering.\n\n## Prerequisites\n\n- Root\u002Fadministrator on the target (firmware reads require privilege).\n- Linux tooling:\n  ```bash\n  sudo apt install mokutil efitools sbsigntool dbxtool      # Debian\u002FUbuntu\n  sudo dnf install mokutil efitools sbsigntools dbxtool     # Fedora\u002FRHEL\n  ```\n- CHIPSEC (run from a live USB or controlled host; loads a kernel driver):\n  ```bash\n  pip install chipsec        # or build from https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec\n  ```\n- Windows tooling: PowerShell (built-in `Confirm-SecureBootUEFI`, `Get-SecureBootUEFI`), and optionally the UEFI dbx update package from Microsoft.\n- The current `dbxupdate` files from https:\u002F\u002Fuefi.org\u002Frevocationlistfile to compare against.\n\n## Objectives\n\n- Confirm Secure Boot is enabled and in user (not setup) mode.\n- Enumerate db, dbx, KEK, and PK contents and assess freshness of dbx.\n- Verify the relevant CVE revocations are present in dbx.\n- Validate Secure Boot EFI variables are authenticated and protected (CHIPSEC).\n- Hash ESP boot binaries and check them against dbx and known-bad hash sets.\n- Identify bootkit artifacts and report exploitable gaps with remediation.\n\n## MITRE ATT&CK Mapping\n\n| Technique ID | Technique Name | Relevance |\n|--------------|----------------|-----------|\n| T1542.003 | Pre-OS Boot: Bootkit | Core technique — bootkit subverts the boot chain below the OS. |\n| T1542 | Pre-OS Boot | Parent technique covering firmware\u002Fboot-component tampering. |\n| T1542.001 | Pre-OS Boot: System Firmware | Adjacent: firmware modification used to persist or weaken Secure Boot. |\n| T1014 | Rootkit | Bootkits provide rootkit-level concealment and persistence. |\n| T1562.001 | Impair Defenses: Disable or Modify Tools | BlackLotus disables BitLocker\u002FHVCI\u002FDefender after bypassing Secure Boot. |\n\n## Workflow\n\n### 1. Confirm Secure Boot state (Linux)\nA disabled or setup-mode platform offers no protection.\n```bash\nmokutil --sb-state                       # \"SecureBoot enabled\" expected\nbootctl status | grep -i \"secure boot\"   # systemd-boot view\n# 6 = enabled+user mode on the EFI SecureBoot\u002FSetupMode vars:\nod -An -t u1 \u002Fsys\u002Ffirmware\u002Fefi\u002Fefivars\u002FSecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c\n```\n\n### 2. Confirm Secure Boot state (Windows)\n```powershell\nConfirm-SecureBootUEFI        # $true if enabled\n# Inspect the raw dbx variable from Windows:\n[System.BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) | Out-File dbx.hex\n```\n\n### 3. Enumerate the Secure Boot databases\nList db (allowed), dbx (revoked), KEK, and PK.\n```bash\nefi-readvar                      # dumps PK, KEK, db, dbx\nefi-readvar -v dbx -o dbx.esl    # export dbx to a file for offline analysis\nmokutil --list-enrolled          # MOK (shim) enrolled keys\nmokutil --db                     # platform db entries via shim\n```\n\n### 4. Assess dbx freshness and applied revocations\nCompare on-system dbx to the current official UEFI revocation list.\n```bash\ndbxtool --list                                   # current dbx entries + count\n# Download latest dbxupdate from uefi.org\u002Frevocationlistfile, then:\ndbxtool --dbx .\u002FDBXUpdate.bin --apply --dry-run  # show what WOULD be added (no write)\n```\nA low dbx entry count or absence of recent revocations indicates the platform is behind and likely still vulnerable to known bypasses.\n\n### 5. Check Secure Boot variable protection with CHIPSEC\nVerify the SB key variables are authenticated and not freely writable.\n```bash\n# Verify Secure Boot is enabled and the SB variables are properly protected:\nsudo chipsec_main -m common.secureboot.variables\n\n# Check S3 resume boot-script protections (an SMM\u002Ffirmware bypass vector):\nsudo chipsec_main -m common.uefi.s3bootscript\n\n# Dump SPI flash for offline firmware diffing:\nsudo chipsec_util spi dump rom.bin\n```\n\n### 6. Hash ESP boot binaries and check signatures\nVerify bootloaders are signed and not present in dbx.\n```bash\n# Locate and hash EFI boot binaries\nfind \u002Fboot\u002Fefi -iname '*.efi' -exec sha256sum {} \\;\n# Validate a binary's signature against the platform db\nsbverify --list \u002Fboot\u002Fefi\u002FEFI\u002FBOOT\u002Fbootx64.efi\nsbverify --cert \u002Fetc\u002Fsecureboot\u002Fdb.crt \u002Fboot\u002Fefi\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi\n# pesign equivalent on RHEL-family:\npesign -S -i \u002Fboot\u002Fefi\u002FEFI\u002FBOOT\u002Fbootx64.efi\n```\n\n### 7. Cross-check against known-bad bootkit hashes\nCompare collected hashes to revocation\u002Fknown-bad sets (e.g., LoFP \u002F vendor advisories).\n```bash\n# Example: confirm a binary's SHA-256 is NOT one of the revoked CVE-2022-21894 boot managers\nsha256sum \u002Fboot\u002Fefi\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi\n# Compare against the hash list extracted from the latest dbxupdate \u002F advisory.\n```\n\n### 8. Inspect for bootkit artifacts\nLook for unauthorized ESP modifications and self-deployment markers.\n```bash\n# Unexpected files \u002F recently modified binaries on the ESP\nls -laR \u002Fboot\u002Fefi\u002FEFI\u002F\nfind \u002Fboot\u002Fefi -newermt \"-30 days\" -iname '*.efi'\n# On Windows, examine the EFI partition for rogue \\EFI\\Microsoft\\Boot entries.\n```\n\n### 9. Validate measured-boot evidence (optional pivot)\nIf a TPM is present, current PCR[7] reflects Secure Boot policy; deviations corroborate tampering.\n```bash\ntpm2_pcrread sha256:7        # Secure Boot policy PCR\n```\n\n### 10. Run the bundled assessment helper\n`agent.py` collects SB state, dbx counts, ESP binary hashes, and CHIPSEC results into one report.\n```bash\nsudo python scripts\u002Fagent.py --check-chipsec --output secureboot_report.json\n```\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| mokutil | Secure Boot state and enrolled keys (Linux) | https:\u002F\u002Fgithub.com\u002Flcp\u002Fmokutil |\n| efitools (efi-readvar) | Dump PK\u002FKEK\u002Fdb\u002Fdbx | https:\u002F\u002Fgit.kernel.org\u002Fpub\u002Fscm\u002Flinux\u002Fkernel\u002Fgit\u002Fjejb\u002Fefitools.git |\n| dbxtool | Inspect and apply dbx updates | https:\u002F\u002Fgithub.com\u002Frhboot\u002Fdbxtool |\n| CHIPSEC | Firmware \u002F Secure Boot variable assessment | https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec |\n| sbsigntool \u002F pesign | EFI binary signature verification | https:\u002F\u002Fgithub.com\u002Fjejb\u002Fsbsigntools |\n| UEFI Revocation List | Official dbx update files | https:\u002F\u002Fuefi.org\u002Frevocationlistfile |\n| Microsoft KB CVE-2023-24932 | Secure Boot bypass guidance | https:\u002F\u002Fsupport.microsoft.com\u002Ftopic\u002Fkb5025885 |\n| ESET BlackLotus analysis | Bootkit technical writeup | https:\u002F\u002Fwww.welivesecurity.com\u002F2023\u002F03\u002F01\u002Fblacklotus-uefi-bootkit-myth-confirmed\u002F |\n\n## Validation Criteria\n\n- [ ] Secure Boot confirmed enabled and in user mode on the target.\n- [ ] PK\u002FKEK\u002Fdb\u002Fdbx enumerated and exported for analysis.\n- [ ] dbx compared against the current official UEFI revocation list.\n- [ ] CVE-2022-21894 \u002F CVE-2023-24932 revocations confirmed present (or gap flagged).\n- [ ] CHIPSEC `secureboot.variables` and `s3bootscript` modules run.\n- [ ] ESP boot binaries hashed and signature-verified.\n- [ ] Hashes cross-checked against known-bad \u002F revoked sets.\n- [ ] ESP inspected for unauthorized or recently modified binaries.\n- [ ] Findings documented with remediation (dbx update \u002F firmware update) per host.\n","# Detecting Secure Boot Bypass\n\n> **Legal Notice:** Firmware and Secure Boot assessment must only be performed on systems you own or are explicitly authorized to test. CHIPSEC's write\u002Fmodify modes and EFI variable manipulation can brick hardware. Run destructive checks only in a lab. This skill is for defensive verification and authorized assessment.\n\n## Overview\n\nUEFI Secure Boot is the firmware-enforced trust chain that only permits boot components signed by keys in the platform's allow-list (db) and not present in the revocation list (dbx). Bootkits defeat this layer to gain pre-OS, persistent, kernel-level control that survives OS reinstalls and disk wipes. **BlackLotus** (2023) was the first publicly observed UEFI bootkit to bypass Secure Boot on fully patched Windows 11, abusing **CVE-2022-21894** (\"baton drop\") in a vulnerable, signed Windows boot manager to neutralize Secure Boot and disable BitLocker, HVCI, and Defender. **Bootkitty** (2024) was the first PoC UEFI bootkit targeting Linux. Microsoft's **CVE-2023-24932** addressed a related Secure Boot bypass that required a phased dbx (revocation) rollout because revoking the vulnerable boot managers can render systems unbootable if applied carelessly.\n\nThe core defensive insight is that patching the OS is **not sufficient** — the platform remains exploitable until the vulnerable, signed binaries are revoked in **dbx**. Detection therefore combines: (1) confirming Secure Boot is actually enabled, (2) verifying dbx is current and contains the relevant revocations, (3) checking the integrity and protection of Secure Boot EFI variables with CHIPSEC, (4) hashing on-disk EFI boot binaries and comparing them against the revocation list and known-bad sets, and (5) inspecting firmware\u002FESP for bootkit artifacts. This skill provides a cross-platform (Linux + Windows) workflow using `mokutil`, `efi-readvar`\u002F`dbxtool`, `chipsec`, `sbverify`\u002F`pesign`, and Windows `Confirm-SecureBootUEFI` \u002F `Get-SecureBootUEFI`.\n\n## When to Use\n\n- Verifying that an estate's Secure Boot configuration is enabled, locked, and current after the CVE-2023-24932 \u002F BlackLotus advisories.\n- Hunting for UEFI bootkit indicators on a suspected-compromised endpoint.\n- Validating that dbx revocations (e.g., vulnerable Windows boot managers, Kaspersky\u002Fother vulnerable bootloaders) have actually applied across the fleet.\n- Auditing firmware integrity and Secure Boot variable protections during a hardware security assessment.\n- Building a recurring measured\u002Fbaseline check for boot-chain tampering.\n\n## Prerequisites\n\n- Root\u002Fadministrator on the target (firmware reads require privilege).\n- Linux tooling:\n  ```bash\n  sudo apt install mokutil efitools sbsigntool dbxtool      # Debian\u002FUbuntu\n  sudo dnf install mokutil efitools sbsigntools dbxtool     # Fedora\u002FRHEL\n  ```\n- CHIPSEC (run from a live USB or controlled host; loads a kernel driver):\n  ```bash\n  pip install chipsec        # or build from https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec\n  ```\n- Windows tooling: PowerShell (built-in `Confirm-SecureBootUEFI`, `Get-SecureBootUEFI`), and optionally the UEFI dbx update package from Microsoft.\n- The current `dbxupdate` files from https:\u002F\u002Fuefi.org\u002Frevocationlistfile to compare against.\n\n## Objectives\n\n- Confirm Secure Boot is enabled and in user (not setup) mode.\n- Enumerate db, dbx, KEK, and PK contents and assess freshness of dbx.\n- Verify the relevant CVE revocations are present in dbx.\n- Validate Secure Boot EFI variables are authenticated and protected (CHIPSEC).\n- Hash ESP boot binaries and check them against dbx and known-bad hash sets.\n- Identify bootkit artifacts and report exploitable gaps with remediation.\n\n## MITRE ATT&CK Mapping\n\n| Technique ID | Technique Name | Relevance |\n|--------------|----------------|-----------|\n| T1542.003 | Pre-OS Boot: Bootkit | Core technique — bootkit subverts the boot chain below the OS. |\n| T1542 | Pre-OS Boot | Parent technique covering firmware\u002Fboot-component tampering. |\n| T1542.001 | Pre-OS Boot: System Firmware | Adjacent: firmware modification used to persist or weaken Secure Boot. |\n| T1014 | Rootkit | Bootkits provide rootkit-level concealment and persistence. |\n| T1562.001 | Impair Defenses: Disable or Modify Tools | BlackLotus disables BitLocker\u002FHVCI\u002FDefender after bypassing Secure Boot. |\n\n## Workflow\n\n### 1. Confirm Secure Boot state (Linux)\nA disabled or setup-mode platform offers no protection.\n```bash\nmokutil --sb-state                       # \"SecureBoot enabled\" expected\nbootctl status | grep -i \"secure boot\"   # systemd-boot view\n# 6 = enabled+user mode on the EFI SecureBoot\u002FSetupMode vars:\nod -An -t u1 \u002Fsys\u002Ffirmware\u002Fefi\u002Fefivars\u002FSecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c\n```\n\n### 2. Confirm Secure Boot state (Windows)\n```powershell\nConfirm-SecureBootUEFI        # $true if enabled\n# Inspect the raw dbx variable from Windows:\n[System.BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) | Out-File dbx.hex\n```\n\n### 3. Enumerate the Secure Boot databases\nList db (allowed), dbx (revoked), KEK, and PK.\n```bash\nefi-readvar                      # dumps PK, KEK, db, dbx\nefi-readvar -v dbx -o dbx.esl    # export dbx to a file for offline analysis\nmokutil --list-enrolled          # MOK (shim) enrolled keys\nmokutil --db                     # platform db entries via shim\n```\n\n### 4. Assess dbx freshness and applied revocations\nCompare on-system dbx to the current official UEFI revocation list.\n```bash\ndbxtool --list                                   # current dbx entries + count\n# Download latest dbxupdate from uefi.org\u002Frevocationlistfile, then:\ndbxtool --dbx .\u002FDBXUpdate.bin --apply --dry-run  # show what WOULD be added (no write)\n```\nA low dbx entry count or absence of recent revocations indicates the platform is behind and likely still vulnerable to known bypasses.\n\n### 5. Check Secure Boot variable protection with CHIPSEC\nVerify the SB key variables are authenticated and not freely writable.\n```bash\n# Verify Secure Boot is enabled and the SB variables are properly protected:\nsudo chipsec_main -m common.secureboot.variables\n\n# Check S3 resume boot-script protections (an SMM\u002Ffirmware bypass vector):\nsudo chipsec_main -m common.uefi.s3bootscript\n\n# Dump SPI flash for offline firmware diffing:\nsudo chipsec_util spi dump rom.bin\n```\n\n### 6. Hash ESP boot binaries and check signatures\nVerify bootloaders are signed and not present in dbx.\n```bash\n# Locate and hash EFI boot binaries\nfind \u002Fboot\u002Fefi -iname '*.efi' -exec sha256sum {} \\;\n# Validate a binary's signature against the platform db\nsbverify --list \u002Fboot\u002Fefi\u002FEFI\u002FBOOT\u002Fbootx64.efi\nsbverify --cert \u002Fetc\u002Fsecureboot\u002Fdb.crt \u002Fboot\u002Fefi\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi\n# pesign equivalent on RHEL-family:\npesign -S -i \u002Fboot\u002Fefi\u002FEFI\u002FBOOT\u002Fbootx64.efi\n```\n\n### 7. Cross-check against known-bad bootkit hashes\nCompare collected hashes to revocation\u002Fknown-bad sets (e.g., LoFP \u002F vendor advisories).\n```bash\n# Example: confirm a binary's SHA-256 is NOT one of the revoked CVE-2022-21894 boot managers\nsha256sum \u002Fboot\u002Fefi\u002FEFI\u002FMicrosoft\u002FBoot\u002Fbootmgfw.efi\n# Compare against the hash list extracted from the latest dbxupdate \u002F advisory.\n```\n\n### 8. Inspect for bootkit artifacts\nLook for unauthorized ESP modifications and self-deployment markers.\n```bash\n# Unexpected files \u002F recently modified binaries on the ESP\nls -laR \u002Fboot\u002Fefi\u002FEFI\u002F\nfind \u002Fboot\u002Fefi -newermt \"-30 days\" -iname '*.efi'\n# On Windows, examine the EFI partition for rogue \\EFI\\Microsoft\\Boot entries.\n```\n\n### 9. Validate measured-boot evidence (optional pivot)\nIf a TPM is present, current PCR[7] reflects Secure Boot policy; deviations corroborate tampering.\n```bash\ntpm2_pcrread sha256:7        # Secure Boot policy PCR\n```\n\n### 10. Run the bundled assessment helper\n`agent.py` collects SB state, dbx counts, ESP binary hashes, and CHIPSEC results into one report.\n```bash\nsudo python scripts\u002Fagent.py --check-chipsec --output secureboot_report.json\n```\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| mokutil | Secure Boot state and enrolled keys (Linux) | https:\u002F\u002Fgithub.com\u002Flcp\u002Fmokutil |\n| efitools (efi-readvar) | Dump PK\u002FKEK\u002Fdb\u002Fdbx | https:\u002F\u002Fgit.kernel.org\u002Fpub\u002Fscm\u002Flinux\u002Fkernel\u002Fgit\u002Fjejb\u002Fefitools.git |\n| dbxtool | Inspect and apply dbx updates | https:\u002F\u002Fgithub.com\u002Frhboot\u002Fdbxtool |\n| CHIPSEC | Firmware \u002F Secure Boot variable assessment | https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec |\n| sbsigntool \u002F pesign | EFI binary signature verification | https:\u002F\u002Fgithub.com\u002Fjejb\u002Fsbsigntools |\n| UEFI Revocation List | Official dbx update files | https:\u002F\u002Fuefi.org\u002Frevocationlistfile |\n| Microsoft KB CVE-2023-24932 | Secure Boot bypass guidance | https:\u002F\u002Fsupport.microsoft.com\u002Ftopic\u002Fkb5025885 |\n| ESET BlackLotus analysis | Bootkit technical writeup | https:\u002F\u002Fwww.welivesecurity.com\u002F2023\u002F03\u002F01\u002Fblacklotus-uefi-bootkit-myth-confirmed\u002F |\n\n## Validation Criteria\n\n- [ ] Secure Boot confirmed enabled and in user mode on the target.\n- [ ] PK\u002FKEK\u002Fdb\u002Fdbx enumerated and exported for analysis.\n- [ ] dbx compared against the current official UEFI revocation list.\n- [ ] CVE-2022-21894 \u002F CVE-2023-24932 revocations confirmed present (or gap flagged).\n- [ ] CHIPSEC `secureboot.variables` and `s3bootscript` modules run.\n- [ ] ESP boot binaries hashed and signature-verified.\n- [ ] Hashes cross-checked against known-bad \u002F revoked sets.\n- [ ] ESP inspected for unauthorized or recently modified binaries.\n- [ ] Findings documented with remediation (dbx update \u002F firmware update) per host.\n",{"name":5,"tags":47,"author":50,"domain":41,"license":15,"version":51,"nist_csf":52,"subdomain":32,"description":7,"mitre_attack":54},[32,48,49,37,30,29,33,28],"secure-boot","uefi","mahipal","1.0",[53],"DE.CM-01",[55],"T1542.003","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fdetecting-secure-boot-bypass",4395,"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":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-secure-boot-bypass",{"tool":72,"command":73},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-secure-boot-bypass",{"tool":75,"command":76},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-secure-boot-bypass","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-secure-boot-bypass\u002FSKILL.md",true,[80,85,91,95],{"path":81,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-secure-boot-bypass\u002FLICENSE",{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fapi-reference.md","REFERENCE","参考文档",2221,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-secure-boot-bypass\u002Freferences\u002Fapi-reference.md",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fstandards.md",1580,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-secure-boot-bypass\u002Freferences\u002Fstandards.md",{"path":96,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"scripts\u002Fagent.py","SCRIPT","脚本",5269,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-secure-boot-bypass\u002Fscripts\u002Fagent.py",[102,128,150,178,203,230],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":42},"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",[108],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[110,111,112,113,35,41,114,115,116,117,118,119,120,121,122,123,124,125,126,127],"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":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":42},"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",[134],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[26,124,136,137,35,138,41,116,139,140,27,141,142,143,144,145,146,147,148,149],"TPM","validating tpm measured boot attestation","policy","verification","ZeRO","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":160,"publishedAt":42},"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",[156,159],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[144,161,162,163,164,41,165,166,139,167,168,169,170,171,172,173,174,175,176,177],"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":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":185,"publishedAt":42},"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",[184],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[40,186,187,41,188,189,190,191,192,193,194,195,196,197,198,199,141,200,201,202],"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":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":210,"publishedAt":42},"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",[209],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[211,212,213,41,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229],"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":231,"name":232,"nameZh":6,"description":233,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":234,"categories":235,"keywords":237,"publishedAt":42},"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",[236],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[35,238,41,239,240,241,242,243,244,245,246,173,247,174,248,249,250,251,252,253],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]