Demonstrates Living-off-the-Land (LotL) techniques using native OS tools to simulate realistic threat actor behavior during authorized penetration tests. Use when proving attack feasibility without custom malware, testing detection coverage, and validating what a real adversary could achieve with only built-in system capabilities.
75
62%
Does it follow best practices?
Impact
98%
1.24xAverage score across 3 eval scenarios
Critical
Do not install without reviewing
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/pt-lotl-techniques/SKILL.mdQuality
Discovery
75%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has strong completeness with explicit 'Use when' triggers and good distinctiveness within the security domain. Its main weaknesses are the lack of specific concrete actions (e.g., which LotL techniques or tools) and missing common trigger terms that users might naturally use like 'LOLBins', 'fileless', 'red team', or specific tool names like 'PowerShell' or 'certutil'.
Suggestions
Add specific concrete actions such as 'enumerate accounts via net.exe, transfer files via certutil, execute payloads via mshta/rundll32, perform lateral movement via WMI/PsExec'.
Include additional natural trigger terms users might say, such as 'LOLBins', 'fileless attack', 'red team', 'MITRE ATT&CK', 'PowerShell abuse', 'evasion techniques'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Living-off-the-Land techniques, penetration testing) and describes the general approach (using native OS tools to simulate threat actor behavior), but does not list specific concrete actions like 'enumerate users via net.exe', 'exfiltrate data via certutil', or 'lateral movement via PsExec'. | 2 / 3 |
Completeness | The description clearly answers both 'what' (demonstrates LotL techniques using native OS tools to simulate threat actor behavior) and 'when' (explicitly states 'Use when proving attack feasibility without custom malware, testing detection coverage, and validating what a real adversary could achieve with only built-in system capabilities'). | 3 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'Living-off-the-Land', 'LotL', 'penetration tests', 'native OS tools', 'threat actor', and 'detection coverage'. However, it misses many natural user terms like 'LOLBins', 'fileless attack', 'PowerShell', 'WMI', 'certutil', 'red team', 'MITRE ATT&CK', or 'evasion'. | 2 / 3 |
Distinctiveness Conflict Risk | The description carves out a clear niche focused specifically on Living-off-the-Land techniques using native OS tools during authorized penetration tests. This is distinct from general pentesting skills, malware development skills, or broader security assessment skills, and the 'LotL' and 'native OS tools' qualifiers reduce conflict risk significantly. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a solid structural framework for LotL penetration testing with good safety guardrails, a clear output template, and organized technique categories. Its main weaknesses are the lack of concrete executable examples (no actual commands shown) and missing validation/feedback loops in the workflow for what are inherently risky, system-modifying operations. The content reads more as a high-level methodology guide than an actionable skill with copy-paste-ready instructions.
Suggestions
Add concrete, executable command examples for at least 2-3 key techniques per platform (e.g., show the actual schtasks or certutil command with flags, not just the tool name).
Add explicit validation checkpoints in the execution workflow, such as 'Verify artefact cleanup: re-run discovery commands to confirm no residual files/tasks/keys remain' before proceeding to the next technique.
Move the detailed technique family lists into separate reference files (e.g., WINDOWS_TECHNIQUES.md, UNIX_TECHNIQUES.md) and keep SKILL.md as a concise overview with links.
Remove or condense the Objectives and Approach sections — Claude understands what LotL means and why it's used; focus tokens on the how.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some unnecessary framing (e.g., the 'Objectives' section and 'Approach' paragraph explain concepts Claude already understands). The technique family lists are useful reference material but could be tighter. | 2 / 3 |
Actionability | The skill provides structured guidance and technique categories but lacks concrete, executable commands or code examples. It lists tool names (certutil, schtasks, etc.) without showing specific invocations, making it more of a reference checklist than copy-paste-ready guidance. | 2 / 3 |
Workflow Clarity | The execution workflow has a clear 7-step sequence and the per-technique 4-step checklist is good. However, there are no explicit validation checkpoints or feedback loops — e.g., no 'if cleanup fails, do X' or 'verify artefact removal before proceeding' steps, which matters for operations that modify target systems. | 2 / 3 |
Progressive Disclosure | The content is well-sectioned with clear headers and a logical flow from context to techniques to output template. However, the technique families for both Windows and Unix are listed inline rather than being split into separate reference files, making the skill longer than necessary for an overview document. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
9976e81
Table of Contents
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.