SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Analyzes bootkit and rootkit samples by identifying boot-process tampering (MBR/VBR/ UEFI), kernel-mode components, and stealth hooking techniques from static indicators. Activates for requests to analyze a bootkit or rootkit, examine MBR/UEFI tampering, or identify kernel-mode stealth components.
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
Original instructions from the publisher’s SKILL.md
# Dissecting Boot and Kernel Rootkits ## When to Use - You have a sample (MBR/VBR image, UEFI module, or kernel driver) suspected of boot-process or kernel-level tampering and stealth. - You need to identify the persistence vector and stealth technique class statically. **Do not use** this on production firmware/boot media without acquisition — analyze a captured image. The skill reads bytes statically and executes nothing. ## Prerequisites - The boot image / UEFI module / driver (read inertly). ## Safety & Handling - Read bytes statically; never write the sample to boot media or load the driver. ## Workflow ### Step 1: Classify the artifact ```bash python scripts/analyst.py classify sample.bin ``` Detects MBR/VBR (boot signature `0x55AA` at 0x1FE), UEFI modules (PE with `EFI` subsystem / PI GUIDs / `EFI_` strings), and kernel drivers (PE importing `ntoskrnl`/`hal`, `.sys` indicators). ### Step 2: Identify tampering / hooking indicators Flag disk-write primitives (`Int 13h` for MBR bootkits), SSDT/IRP hooking and `Zw*`/`Ke*` kernel APIs, DKOM strings, and driver-callback registration. ### Step 3: Map the persistence vector Determine whether persistence is via MBR/VBR overwrite, UEFI variable/module, or driver service. ### Step 4: Document Record the artifact type, persistence vector, and stealth technique class, mapping to ATT&CK. ## Validation - The artifact type is identified by concrete signatures (boot signature, PE subsystem, imports). - Tampering/hooking indicators reference real primitives, not generic strings. - The persistence vector is stated with its evidence. ## Pitfalls - A legitimate bootloader/driver resembling a bootkit/rootkit — corroborate with behavior. - UEFI modules requiring firmware-volume parsing beyond simple PE checks. - Kernel samples needing signed-driver and callback context to confirm stealth. ## References - See [`references/api-reference.md`](references/api-reference.md) for the classifier. - ATT&CK T1542.003 and T1014 (linked in frontmatter).