CtrlK
BlogDocsLog inGet started
Tessl Logo

analyzing-linux-kernel-rootkits

Detect kernel-level rootkits in Linux memory dumps using Volatility3 linux plugins (check_syscall, lsmod, hidden_modules), rkhunter system scanning, and /proc vs /sys discrepancy analysis to identify hooked syscalls, hidden kernel modules, and tampered system structures.

57

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Medium

Suggest reviewing before use

Fix and improve this skill with Tessl

tessl review fix ./skills/analyzing-linux-kernel-rootkits/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

50%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is well-structured and on-topic but stops short across the board: it explains concepts Claude knows, omits executable commands and validation checkpoints, and fails to link its own bundle files. Each dimension lands at 2 because concrete, copy-paste, validated, and well-navigated guidance is missing rather than wrong.

Suggestions

Replace the high-level plugin list in Step 2 with actual executable commands (e.g. `vol -f memory.lime linux.check_syscall.Check_syscall`) or link to references/api-reference.md inline.

Add validation checkpoints to the workflow, e.g. verifying the ISF matches the target kernel and confirming dump integrity before analysis, with a fix-and-retry loop.

Link the bundle files from the body — point to scripts/agent.py for rootkit_analyzer.py and to references/api-reference.md for the full command catalog.

Trim the Overview's explanation of what rootkits/ring 0 are and shorten the example report to the essential findings.

DimensionReasoningScore

Conciseness

The Overview explains concepts Claude already knows ("operate at ring 0, modifying kernel data structures to hide processes...") and the 60+ line ASCII example report is heavy; the body is mostly efficient but could be tightened. It is not a 3 because of this conceptual padding and verbose example, yet not a 1 since actionable structure remains.

2 / 3

Actionability

Steps name specific plugins ("linux.check_syscall, linux.lsmod, linux.hidden_modules, and linux.check_idt") but give no copy-paste `vol -f ...` commands in the body — the executable syntax lives only in the unlinked api-reference.md. This is concrete but incomplete guidance, not fully copy-paste ready.

2 / 3

Workflow Clarity

Four steps are clearly sequenced (acquire → analyze → cross-view → live scan), but there are no validation or verification checkpoints for an evidence-handling forensic workflow, which per the rubric caps workflow clarity at 2. It is above 1 due to the explicit sequence, but lacks the feedback loops needed for 3.

2 / 3

Progressive Disclosure

Section organization is clean, but the bundle files (references/api-reference.md and scripts/agent.py) are never referenced or signaled from the body, and the example invokes rootkit_analyzer.py with no pointer to scripts/agent.py. References exist as files but are not clearly signaled, matching the 2 anchor rather than a 3.

2 / 3

Total

8

/

12

Passed

Description

82%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A specific, well-targeted description with strong natural trigger terms and a clear niche, held back only by the absence of an explicit "Use when..." trigger clause. Adding that clause would raise completeness to a top score.

Suggestions

Append an explicit trigger clause, e.g. "Use when analyzing Linux memory dumps for kernel rootkits, hunting hooked syscalls or hidden modules, or validating rootkit detection coverage."

Consider adding common phrasings users might say ("memory forensics", "hidden process detection") to broaden trigger-term coverage slightly.

DimensionReasoningScore

Specificity

Lists multiple concrete actions ("Detect kernel-level rootkits", "identify hooked syscalls, hidden kernel modules, and tampered system structures") alongside named tools (Volatility3 plugins, rkhunter, /proc vs /sys), matching the multi-action anchor.

3 / 3

Completeness

It clearly answers "what" the skill does but provides no "Use when..." clause or equivalent explicit trigger guidance, so per the rubric guideline completeness is capped at 2.

2 / 3

Trigger Term Quality

Terms a user would naturally say for this need are present and accurate ("rootkits", "Linux memory dumps", "Volatility3", "rkhunter", "hooked syscalls"), giving good coverage rather than generic jargon.

3 / 3

Distinctiveness Conflict Risk

The niche is sharply defined (Linux kernel-level rootkits via Volatility3 memory dumps plus rkhunter), with distinct triggers unlikely to collide with other skills.

3 / 3

Total

11

/

12

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
mukul975/Anthropic-Cybersecurity-Skills
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.