[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADX1SQ5ZX1MVD47ZPSPGTY":3,"skill-same:01M6ADX1SQ5ZX1MVD47ZPSPGTY":100},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6ADX1SQ5ZX1MVD47ZPSPGTY","auditing-uefi-firmware-with-chipsec",null,"Use Intel CHIPSEC to assess platform firmware configuration, SPI flash write protection, BIOS lock, SMM\u002FSMRR, and Secure Boot variable state, dump SPI flash, and triage UEFI variables for firmware-level threats.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-uefi-firmware-with-chipsec\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],"firmware","auditing uefi firmware with chipsec","chipsec","UEFI","boot","assessment","state","secure","security","Secure-Boot","triage","hardware-firmware-security","spi-flash","bios-write-protection","firmware-assessment","platform-security","cybersecurity","2026-11-10 10:12:30",false,"---\nname: auditing-uefi-firmware-with-chipsec\ndescription: Use Intel CHIPSEC to assess platform firmware configuration, SPI flash write protection, BIOS lock, SMM\u002FSMRR, and Secure Boot variable state, dump SPI flash, and triage UEFI variables for firmware-level threats.\ndomain: cybersecurity\nsubdomain: hardware-firmware-security\ntags:\n- hardware-firmware-security\n- uefi\n- chipsec\n- spi-flash\n- bios-write-protection\n- secure-boot\n- firmware-assessment\n- platform-security\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- ID.AM-02\nmitre_attack:\n- T1542.001\n---\n# Auditing UEFI Firmware with CHIPSEC\n\n> **Authorized Use Only:** CHIPSEC loads a kernel driver and reads\u002Fwrites low-level hardware registers, SPI flash, and SMM. Run it only on systems you own or are explicitly authorized to assess, ideally on dedicated test hardware. Misuse (especially write\u002Fmodify modules) can brick a machine. Never run write-capable modules on production systems.\n\n## Overview\n\nCHIPSEC is the open-source **Platform Security Assessment Framework** created by Intel's Advanced Threat Research team. It inspects the low-level security configuration of x86 platform firmware and hardware — the layer below the operating system where bootkits and firmware implants live. CHIPSEC loads a signed kernel driver (Linux, Windows, or it can run from the UEFI shell) to read and write hardware registers, Model-Specific Registers (MSRs), PCI config space, SPI flash, and UEFI variables, then runs an automated test suite that checks whether the platform's defensive locks are actually engaged.\n\nThe threat CHIPSEC addresses is MITRE ATT&CK **T1542.001 — Pre-OS Boot: System Firmware**: adversaries who modify system firmware (the BIOS\u002FUEFI image on SPI flash) to gain stealthy, persistent, OS-survivable control. Firmware implants persist across OS reinstall and disk replacement and are invisible to most EDR. CHIPSEC's value is verifying the *prerequisites* that prevent such implants: that the SPI flash BIOS region is write-protected (BIOS_CNTL `BLE`\u002F`SMM_BWP`, SPI Protected Ranges), that the flash descriptor locks region access, that SMRAM\u002FSMRR are configured, and that Secure Boot variables are protected. It also dumps the SPI flash for offline forensic comparison.\n\nSources: Intel\u002FCHIPSEC project (https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec), CHIPSEC documentation (https:\u002F\u002Fchipsec.github.io\u002F).\n\n## When to Use\n\n- Baseline firmware-security assessment of a new laptop\u002Fserver platform or fleet image\n- Verifying that BIOS write protection and SPI flash locks are correctly enabled by the OEM\n- Firmware forensics: dumping SPI flash to compare against a known-good image\n- Validating Secure Boot variable protection and S3 boot-script protection\n- Hunting for evidence of a firmware implant or misconfiguration enabling one\n\n## Prerequisites\n\n- Physical or admin\u002Froot access to the target x86 platform (Intel or AMD)\n- Linux (root) or Windows (Administrator), or a UEFI shell environment\n- Ability to load a kernel driver (Secure Boot may need to allow the CHIPSEC driver, or use `--no_driver` for limited checks)\n- Python 3.8+ and a C compiler\u002Fbuild tools for the kernel module on Linux\n- Dedicated test hardware strongly recommended\n\nInstall CHIPSEC:\n\n```bash\n# From PyPI\npip install chipsec\n\n# Or from source (builds the kernel helper\u002Fdriver)\ngit clone https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec\ncd chipsec\npython setup.py install        # builds and installs, including the Linux driver\n\n# Verify\nsudo chipsec_main --help\nsudo chipsec_util --help\n```\n\n## Objectives\n\n- Run the full automated platform-security test suite and interpret PASS\u002FFAIL\u002FWARNING\n- Verify BIOS write protection (BIOS_CNTL) and SPI Protected Ranges\n- Verify the SPI flash descriptor locks region read\u002Fwrite access\n- Verify SMRAM\u002FSMRR and SMI handler protections\n- Verify Secure Boot variable protection and S3 boot-script protection\n- Dump SPI flash and decode it for offline analysis\n- Enumerate UEFI variables and detect anomalous\u002Funexpected entries\n\n## MITRE ATT&CK Mapping\n\n| Technique ID | Name | Tactic |\n|--------------|------|--------|\n| T1542.001 | Pre-OS Boot: System Firmware | Persistence \u002F Defense Evasion |\n\nCHIPSEC defends against T1542.001 by verifying that the controls preventing unauthorized firmware modification are enabled. A FAIL on `common.bios_wp` (BIOS not write-protected) or `chipsec.modules.common.spi_lock` (flash descriptor unlocked) means an attacker with OS privileges could rewrite the SPI flash and implant persistent firmware — exactly the precondition for this technique.\n\n## Workflow\n\n### Step 1: Run the full automated test suite\n`chipsec_main` with no module argument runs every applicable security check for the detected platform and prints a summary of PASS\u002FFAIL\u002FWARNING\u002FINFORMATION results.\n\n```bash\nsudo chipsec_main\n\n# Save machine-readable output for reporting \u002F diffing\nsudo chipsec_main -j results.json -x results.xml -l chipsec.log\n```\n\n### Step 2: Run the core firmware-protection modules individually\nThe `common` module group contains the OEM-independent security checks. Run the group or specific modules:\n\n```bash\n# Run the whole common group\nsudo chipsec_main -m common\n\n# BIOS write protection: checks BIOS_CNTL BLE\u002FSMM_BWP and SPI protected ranges\nsudo chipsec_main -m common.bios_wp\n\n# SPI flash descriptor lock (FLOCKDN) — are flash region accesses locked?\nsudo chipsec_main -m common.spi_lock\n\n# SMRR programming — protects SMRAM from cache-based attacks\nsudo chipsec_main -m common.smrr\n\n# SMM BIOS write protection\nsudo chipsec_main -m common.smm\n\n# S3 resume boot-script protection (against bootscript table attacks)\nsudo chipsec_main -m common.uefi.s3bootscript\n```\n\n### Step 3: Verify Secure Boot variable protection\n```bash\n# Checks that Secure Boot UEFI variables are properly protected\nsudo chipsec_main -m common.secureboot.variables\n\n# To actively test write protection of the variables (test hardware ONLY):\nsudo chipsec_main -m common.secureboot.variables -a modify\n```\n\n### Step 4: Inspect SPI flash region access permissions\n```bash\n# Report SPI flash regions, descriptor, and access permissions\nsudo chipsec_util spi info\n\n# Check the SPI access-control module\nsudo chipsec_main -m common.spi_access\n```\n\n### Step 5: Dump SPI flash for offline forensics\nDumping the flash lets you decode the firmware volumes and compare against a known-good OEM image.\n\n```bash\n# Dump the entire SPI flash to a file\nsudo chipsec_util spi dump rom.bin\n\n# Decode the dumped image: extracts firmware volumes, files, NVRAM variables, etc.\nsudo chipsec_util decode rom.bin\n```\n\n### Step 6: Enumerate and triage UEFI variables\n```bash\n# List all UEFI variables from the runtime interface\nsudo chipsec_util uefi var-list\n\n# List variables directly from the SPI image (offline)\nsudo chipsec_util uefi var-find PK\nsudo chipsec_util uefi var-read db \u003CGUID> db.bin\n\n# Decode the UEFI firmware structure\nsudo chipsec_util uefi decode rom.bin\n```\n\n### Step 7: Limited assessment without a kernel driver\nWhere loading the driver is impossible (locked-down Secure Boot), some checks still run read-only.\n\n```bash\nsudo chipsec_main -n            # --no_driver: skip checks that need the driver\nsudo chipsec_main -p \u003CPLATFORM> # force platform code if auto-detect fails\n```\n\n### Step 8: Triage results and report\n- **FAIL** on `bios_wp` \u002F `spi_lock` → firmware is rewritable from the OS: high risk for T1542.001.\n- **FAIL** on `secureboot.variables` → Secure Boot policy can be tampered.\n- Compare the `spi dump` against the OEM's known-good image (hash firmware volumes) to detect unauthorized modification.\n- Record platform, BIOS version, and every FAIL\u002FWARNING with the relevant register values for the report.\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| chipsec_main | Automated platform-security test suite | https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec |\n| chipsec_util | Manual hardware\u002Ffirmware access (spi, uefi, decode) | https:\u002F\u002Fchipsec.github.io\u002F |\n| UEFITool | GUI\u002FCLI parsing of dumped UEFI images | https:\u002F\u002Fgithub.com\u002FLongSoft\u002FUEFITool |\n| Binarly fwhunt | Firmware vulnerability\u002Fimplant hunting rules | https:\u002F\u002Fgithub.com\u002Fbinarly-io\u002Ffwhunt-scan |\n| NSA UEFI Secure Boot guidance | Hardening reference | https:\u002F\u002Fmedia.defense.gov\u002F |\n\n## Core Module Reference\n\n| Module | Checks |\n|--------|--------|\n| common.bios_wp | BIOS_CNTL BLE \u002F SMM_BWP and SPI Protected Ranges |\n| common.spi_lock | SPI flash descriptor FLOCKDN |\n| common.spi_access | SPI flash region read\u002Fwrite permissions |\n| common.smrr | System Management Range Registers programming |\n| common.smm | SMM BIOS write protection |\n| common.secureboot.variables | Secure Boot variable protection |\n| common.uefi.s3bootscript | S3 resume boot-script protection |\n\n## Validation Criteria\n\n- [ ] CHIPSEC installed and driver loads (or `-n` documented if not)\n- [ ] Full `chipsec_main` suite executed with JSON\u002FXML\u002Flog output saved\n- [ ] `common.bios_wp` result interpreted (write protection state)\n- [ ] `common.spi_lock` \u002F `spi_access` result interpreted (descriptor lock)\n- [ ] SMRR\u002FSMM module results recorded\n- [ ] Secure Boot variable protection checked\n- [ ] SPI flash dumped and decoded for offline analysis\n- [ ] UEFI variables enumerated and triaged\n- [ ] All FAIL\u002FWARNING findings documented with platform\u002FBIOS version\n- [ ] Write\u002Fmodify modules NOT run on production hardware\n","# Auditing UEFI Firmware with CHIPSEC\n\n> **Authorized Use Only:** CHIPSEC loads a kernel driver and reads\u002Fwrites low-level hardware registers, SPI flash, and SMM. Run it only on systems you own or are explicitly authorized to assess, ideally on dedicated test hardware. Misuse (especially write\u002Fmodify modules) can brick a machine. Never run write-capable modules on production systems.\n\n## Overview\n\nCHIPSEC is the open-source **Platform Security Assessment Framework** created by Intel's Advanced Threat Research team. It inspects the low-level security configuration of x86 platform firmware and hardware — the layer below the operating system where bootkits and firmware implants live. CHIPSEC loads a signed kernel driver (Linux, Windows, or it can run from the UEFI shell) to read and write hardware registers, Model-Specific Registers (MSRs), PCI config space, SPI flash, and UEFI variables, then runs an automated test suite that checks whether the platform's defensive locks are actually engaged.\n\nThe threat CHIPSEC addresses is MITRE ATT&CK **T1542.001 — Pre-OS Boot: System Firmware**: adversaries who modify system firmware (the BIOS\u002FUEFI image on SPI flash) to gain stealthy, persistent, OS-survivable control. Firmware implants persist across OS reinstall and disk replacement and are invisible to most EDR. CHIPSEC's value is verifying the *prerequisites* that prevent such implants: that the SPI flash BIOS region is write-protected (BIOS_CNTL `BLE`\u002F`SMM_BWP`, SPI Protected Ranges), that the flash descriptor locks region access, that SMRAM\u002FSMRR are configured, and that Secure Boot variables are protected. It also dumps the SPI flash for offline forensic comparison.\n\nSources: Intel\u002FCHIPSEC project (https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec), CHIPSEC documentation (https:\u002F\u002Fchipsec.github.io\u002F).\n\n## When to Use\n\n- Baseline firmware-security assessment of a new laptop\u002Fserver platform or fleet image\n- Verifying that BIOS write protection and SPI flash locks are correctly enabled by the OEM\n- Firmware forensics: dumping SPI flash to compare against a known-good image\n- Validating Secure Boot variable protection and S3 boot-script protection\n- Hunting for evidence of a firmware implant or misconfiguration enabling one\n\n## Prerequisites\n\n- Physical or admin\u002Froot access to the target x86 platform (Intel or AMD)\n- Linux (root) or Windows (Administrator), or a UEFI shell environment\n- Ability to load a kernel driver (Secure Boot may need to allow the CHIPSEC driver, or use `--no_driver` for limited checks)\n- Python 3.8+ and a C compiler\u002Fbuild tools for the kernel module on Linux\n- Dedicated test hardware strongly recommended\n\nInstall CHIPSEC:\n\n```bash\n# From PyPI\npip install chipsec\n\n# Or from source (builds the kernel helper\u002Fdriver)\ngit clone https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec\ncd chipsec\npython setup.py install        # builds and installs, including the Linux driver\n\n# Verify\nsudo chipsec_main --help\nsudo chipsec_util --help\n```\n\n## Objectives\n\n- Run the full automated platform-security test suite and interpret PASS\u002FFAIL\u002FWARNING\n- Verify BIOS write protection (BIOS_CNTL) and SPI Protected Ranges\n- Verify the SPI flash descriptor locks region read\u002Fwrite access\n- Verify SMRAM\u002FSMRR and SMI handler protections\n- Verify Secure Boot variable protection and S3 boot-script protection\n- Dump SPI flash and decode it for offline analysis\n- Enumerate UEFI variables and detect anomalous\u002Funexpected entries\n\n## MITRE ATT&CK Mapping\n\n| Technique ID | Name | Tactic |\n|--------------|------|--------|\n| T1542.001 | Pre-OS Boot: System Firmware | Persistence \u002F Defense Evasion |\n\nCHIPSEC defends against T1542.001 by verifying that the controls preventing unauthorized firmware modification are enabled. A FAIL on `common.bios_wp` (BIOS not write-protected) or `chipsec.modules.common.spi_lock` (flash descriptor unlocked) means an attacker with OS privileges could rewrite the SPI flash and implant persistent firmware — exactly the precondition for this technique.\n\n## Workflow\n\n### Step 1: Run the full automated test suite\n`chipsec_main` with no module argument runs every applicable security check for the detected platform and prints a summary of PASS\u002FFAIL\u002FWARNING\u002FINFORMATION results.\n\n```bash\nsudo chipsec_main\n\n# Save machine-readable output for reporting \u002F diffing\nsudo chipsec_main -j results.json -x results.xml -l chipsec.log\n```\n\n### Step 2: Run the core firmware-protection modules individually\nThe `common` module group contains the OEM-independent security checks. Run the group or specific modules:\n\n```bash\n# Run the whole common group\nsudo chipsec_main -m common\n\n# BIOS write protection: checks BIOS_CNTL BLE\u002FSMM_BWP and SPI protected ranges\nsudo chipsec_main -m common.bios_wp\n\n# SPI flash descriptor lock (FLOCKDN) — are flash region accesses locked?\nsudo chipsec_main -m common.spi_lock\n\n# SMRR programming — protects SMRAM from cache-based attacks\nsudo chipsec_main -m common.smrr\n\n# SMM BIOS write protection\nsudo chipsec_main -m common.smm\n\n# S3 resume boot-script protection (against bootscript table attacks)\nsudo chipsec_main -m common.uefi.s3bootscript\n```\n\n### Step 3: Verify Secure Boot variable protection\n```bash\n# Checks that Secure Boot UEFI variables are properly protected\nsudo chipsec_main -m common.secureboot.variables\n\n# To actively test write protection of the variables (test hardware ONLY):\nsudo chipsec_main -m common.secureboot.variables -a modify\n```\n\n### Step 4: Inspect SPI flash region access permissions\n```bash\n# Report SPI flash regions, descriptor, and access permissions\nsudo chipsec_util spi info\n\n# Check the SPI access-control module\nsudo chipsec_main -m common.spi_access\n```\n\n### Step 5: Dump SPI flash for offline forensics\nDumping the flash lets you decode the firmware volumes and compare against a known-good OEM image.\n\n```bash\n# Dump the entire SPI flash to a file\nsudo chipsec_util spi dump rom.bin\n\n# Decode the dumped image: extracts firmware volumes, files, NVRAM variables, etc.\nsudo chipsec_util decode rom.bin\n```\n\n### Step 6: Enumerate and triage UEFI variables\n```bash\n# List all UEFI variables from the runtime interface\nsudo chipsec_util uefi var-list\n\n# List variables directly from the SPI image (offline)\nsudo chipsec_util uefi var-find PK\nsudo chipsec_util uefi var-read db \u003CGUID> db.bin\n\n# Decode the UEFI firmware structure\nsudo chipsec_util uefi decode rom.bin\n```\n\n### Step 7: Limited assessment without a kernel driver\nWhere loading the driver is impossible (locked-down Secure Boot), some checks still run read-only.\n\n```bash\nsudo chipsec_main -n            # --no_driver: skip checks that need the driver\nsudo chipsec_main -p \u003CPLATFORM> # force platform code if auto-detect fails\n```\n\n### Step 8: Triage results and report\n- **FAIL** on `bios_wp` \u002F `spi_lock` → firmware is rewritable from the OS: high risk for T1542.001.\n- **FAIL** on `secureboot.variables` → Secure Boot policy can be tampered.\n- Compare the `spi dump` against the OEM's known-good image (hash firmware volumes) to detect unauthorized modification.\n- Record platform, BIOS version, and every FAIL\u002FWARNING with the relevant register values for the report.\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| chipsec_main | Automated platform-security test suite | https:\u002F\u002Fgithub.com\u002Fchipsec\u002Fchipsec |\n| chipsec_util | Manual hardware\u002Ffirmware access (spi, uefi, decode) | https:\u002F\u002Fchipsec.github.io\u002F |\n| UEFITool | GUI\u002FCLI parsing of dumped UEFI images | https:\u002F\u002Fgithub.com\u002FLongSoft\u002FUEFITool |\n| Binarly fwhunt | Firmware vulnerability\u002Fimplant hunting rules | https:\u002F\u002Fgithub.com\u002Fbinarly-io\u002Ffwhunt-scan |\n| NSA UEFI Secure Boot guidance | Hardening reference | https:\u002F\u002Fmedia.defense.gov\u002F |\n\n## Core Module Reference\n\n| Module | Checks |\n|--------|--------|\n| common.bios_wp | BIOS_CNTL BLE \u002F SMM_BWP and SPI Protected Ranges |\n| common.spi_lock | SPI flash descriptor FLOCKDN |\n| common.spi_access | SPI flash region read\u002Fwrite permissions |\n| common.smrr | System Management Range Registers programming |\n| common.smm | SMM BIOS write protection |\n| common.secureboot.variables | Secure Boot variable protection |\n| common.uefi.s3bootscript | S3 resume boot-script protection |\n\n## Validation Criteria\n\n- [ ] CHIPSEC installed and driver loads (or `-n` documented if not)\n- [ ] Full `chipsec_main` suite executed with JSON\u002FXML\u002Flog output saved\n- [ ] `common.bios_wp` result interpreted (write protection state)\n- [ ] `common.spi_lock` \u002F `spi_access` result interpreted (descriptor lock)\n- [ ] SMRR\u002FSMM module results recorded\n- [ ] Secure Boot variable protection checked\n- [ ] SPI flash dumped and decoded for offline analysis\n- [ ] UEFI variables enumerated and triaged\n- [ ] All FAIL\u002FWARNING findings documented with platform\u002FBIOS version\n- [ ] Write\u002Fmodify modules NOT run on production hardware\n",{"name":5,"tags":46,"author":49,"domain":40,"license":15,"version":50,"nist_csf":51,"subdomain":35,"description":7,"mitre_attack":53},[35,47,26,36,37,48,38,39],"uefi","secure-boot","mahipal","1.0",[52],"ID.AM-02",[54],"T1542.001","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fauditing-uefi-firmware-with-chipsec",4414,"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":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill auditing-uefi-firmware-with-chipsec",{"tool":71,"command":72},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill auditing-uefi-firmware-with-chipsec",{"tool":74,"command":75},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill auditing-uefi-firmware-with-chipsec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-uefi-firmware-with-chipsec\u002FSKILL.md",true,[79,84,90,94],{"path":80,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-uefi-firmware-with-chipsec\u002FLICENSE",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fapi-reference.md","REFERENCE","参考文档",2324,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-uefi-firmware-with-chipsec\u002Freferences\u002Fapi-reference.md",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fstandards.md",1394,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-uefi-firmware-with-chipsec\u002Freferences\u002Fstandards.md",{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"scripts\u002Fagent.py","SCRIPT","脚本",4422,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-uefi-firmware-with-chipsec\u002Fscripts\u002Fagent.py",[101,127,149,177,203,230],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":41},"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",[107],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[109,110,111,112,32,40,113,114,115,116,117,118,119,120,121,122,123,124,125,126],"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":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":134,"publishedAt":41},"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",[133],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[28,123,135,136,32,137,40,115,138,139,24,140,141,142,143,144,145,146,147,148],"TPM","validating tpm measured boot attestation","policy","verification","ZeRO","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":159,"publishedAt":41},"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",[155,158],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[143,160,161,162,163,40,164,165,138,166,167,168,169,170,171,172,173,174,175,176],"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":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":184,"publishedAt":41},"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",[183],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[185,186,187,40,188,189,190,191,192,193,194,195,196,197,198,199,140,200,201,202],"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":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":41},"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,40,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":41},"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},[32,238,40,239,240,241,242,243,244,245,246,172,247,173,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"]