AI Skills

Pre-built skills for AI assistants working with Weaponized VS Code.

Pentest with Weaponized

A comprehensive skill that teaches AI assistants (Claude Code, Cursor, etc.) how to use the Weaponized MCP tools and workspace features for penetration testing.

Covers:

• All 13 MCP tools: targets, credentials, findings, terminals, graph
• 6 MCP resources for read-only state access
• 4 workflow patterns: reconnaissance, credential exploitation, listener setup, iterative attack
• Workspace note structure (host YAML, credentials YAML, finding frontmatter)
• Best practices for documenting findings and building commands

Download

Download pentest-with-weaponized.zip

Installation

Claude Code

# Extract to your project's .claude/skills/ directory
unzip pentest-with-weaponized.zip -d .claude/skills/

# Or install globally
unzip pentest-with-weaponized.zip -d ~/.claude/skills/

Other MCP Clients

Copy the SKILL.md content into your AI client's system prompt or knowledge base configuration.

Preview

View SKILL.md content

---
name: pentest-with-weaponized
description: >
  Guide for AI assistants to perform penetration testing using the Weaponized VS Code
  extension's MCP tools and workspace features. Use this skill whenever the user asks
  you to help with a penetration test, red team engagement, CTF challenge, or offensive
  security task while connected to a Weaponized MCP server. Also use it when you see
  MCP tools like get_targets, get_credentials, list_terminals, create_finding, or
  workspace notes with ```yaml host / ```yaml credentials blocks.
---

# Penetration Testing with Weaponized VS Code

You are connected to a **Weaponized VS Code** workspace — a penetration testing
environment that stores targets, credentials, findings, and tool output as structured
Markdown notes. The workspace exposes MCP tools and resources that let you read,
create, and act on engagement data without touching raw files.

## Core Concepts

**Markdown-as-Database**: every piece of engagement state lives in `.md` files with
fenced YAML blocks. Host notes contain ````yaml host```` blocks; credential notes
contain ````yaml credentials```` blocks. The extension watches these files and syncs
them into an in-memory state you can query via MCP.

**Foam knowledge graph**: notes link to each other with `[[wiki-links]]`. The graph
tracks relationships between hosts, users, services, and findings. You can query it
via `get_graph`.

**Terminal bridge**: VS Code terminals are exposed as MCP resources. You can list
them, read their output, send commands, and even create pre-configured terminals
(msfconsole, netcat listener, meterpreter handler, web delivery server).

---

## Available MCP Tools

### Reconnaissance & State

| Tool | Purpose | When to use |
|------|---------|-------------|
| `get_targets` | Get all hosts as JSON | Starting an engagement, checking what's discovered |
| `get_credentials` | Get all credentials as JSON | Before lateral movement, checking captured creds |
| `get_hosts_formatted` | Hosts in env/hosts/yaml/table format | Generating `/etc/hosts` entries, shell exports |
| `get_credentials_formatted` | Creds in env/impacket/nxc/yaml/table format | Building command lines for impacket, NetExec |
| `get_graph` | Full relationship graph + Mermaid diagram | Understanding attack paths, reporting |

### Findings Management

| Tool | Purpose | When to use |
|------|---------|-------------|
| `list_findings` | Search findings by severity/tags/query | Reviewing what's been found, filtering by priority |
| `get_finding` | Get one finding by ID | Deep-diving into a specific vulnerability |
| `create_finding` | Create a new finding note | After discovering a vulnerability or misconfiguration |
| `update_finding_frontmatter` | Update severity/tags/description | Upgrading severity after confirming exploitability |

### Terminal Interaction

| Tool | Purpose | When to use |
|------|---------|-------------|
| `list_terminals` | List open VS Code terminals | Checking what's running |
| `read_terminal` | Read recent output (last N lines) | Analyzing scan results, checking shell output |
| `send_to_terminal` | Send a command to a terminal | Running commands, interacting with shells |
| `create_terminal` | Create a new terminal (with optional profile) | Starting tools — profiles: `netcat`, `msfconsole`, `meterpreter`, `web-delivery`, `shell` |

### Available Resources (read-only)

| URI | Content |
|-----|---------|
| `hosts://list` | All hosts JSON |
| `hosts://current` | Currently active host |
| `users://list` | All credentials JSON |
| `users://current` | Currently active credential |
| `graph://relationships` | Relationship graph |
| `findings://list` | All findings |

---

## Workflow Patterns

### Pattern 1: Reconnaissance Cycle

```
1. get_targets → see what hosts exist
2. list_terminals → find terminal running nmap/scan
3. read_terminal(id, lines=100) → read scan output
4. create_finding(title, severity, tags, description) → document discoveries
5. get_graph → visualize relationships
```

### Pattern 2: Credential Exploitation

```
1. get_credentials → check available creds
2. get_credentials_formatted(format="impacket") → get domain/user:pass strings
3. create_terminal(profile="shell") → open a working terminal
4. send_to_terminal(id, command) → run impacket/NetExec/etc.
5. read_terminal(id) → check results
6. create_finding → document successful exploitation
```

### Pattern 3: Listener Setup

```
1. create_terminal(profile="netcat") → start nc listener
   OR create_terminal(profile="meterpreter") → start meterpreter handler
2. list_terminals → confirm listener is running
3. read_terminal(id) → monitor for incoming connections
4. create_finding → document shell access
```

### Pattern 4: Iterative Attack

```
1. get_targets → pick target
2. get_hosts_formatted(format="env") → get $TARGET, $DC_HOST vars
3. send_to_terminal(id, "nmap -sV $TARGET") → scan
4. read_terminal(id, lines=200) → analyze results
5. list_findings(severity="critical") → check existing findings
6. create_finding / update_finding_frontmatter → update engagement state
7. get_graph → check if new attack paths opened
```

---

## Best Practices

### Always check state first
Before running any tool, call `get_targets` and `get_credentials` to understand the
current engagement context. The workspace may already have targets and creds from
previous work.

### Use formatted output for commands
When building shell commands, prefer `get_hosts_formatted` and
`get_credentials_formatted` with the appropriate format. For example:
- `impacket` format gives `DOMAIN/user:password` — ready for secretsdump, psexec, etc.
- `nxc` format gives `-u user -p pass -d domain` flags — ready for NetExec
- `env` format gives `export TARGET=...` — ready for shell scripts

### Document as you go
Create findings immediately when you discover something. Use appropriate severity:
- **critical**: RCE, domain admin, unauth access to sensitive data
- **high**: privileged credential, significant misconfig
- **medium**: information disclosure, weak config
- **low**: minor issues, best-practice violations
- **info**: interesting observations, recon notes

Use tags for categorization: `web`, `ad`, `privesc`, `creds`, `misconfig`, `network`.

### Read terminals before sending commands
Always `read_terminal` to check current state before `send_to_terminal`. The terminal
might be in the middle of something, or waiting for input.

### Use terminal profiles wisely
- `msfconsole` — Metasploit Framework console, auto-starts msfconsole
- `meterpreter` — Meterpreter multi/handler, pre-configured listener
- `netcat` — Netcat reverse shell listener
- `web-delivery` — HTTP file server for payload delivery
- `shell` (or omit) — plain shell terminal

### Leverage the graph
`get_graph` returns a full relationship graph including a Mermaid diagram. Use this
to identify attack paths: compromised host → lateral movement → domain controller.
The graph includes `longestPath` which highlights the deepest chain of compromise.

---

## Workspace Note Structure

The workspace uses a specific directory layout:

```
workspace/
├── hosts/           # One folder per host
│   └── target.htb/
│       └── target.htb.md    # Contains ```yaml host block
├── findings/        # One folder per finding
│   └── sqli-login/
│       └── sqli-login.md    # Contains frontmatter with severity/tags
├── services/        # Service notes
├── .vscode/
│   ├── settings.json    # Extension config (LHOST, LPORT, scanners)
│   └── mcp.json         # MCP server config for AI clients
└── *.md                 # General notes, linked with [[wiki-links]]
```

### Host YAML Block Format
```yaml
- hostname: target.htb
  ip: 10.10.10.100
  is_dc: false
  alias: ["target.htb", "web.target.htb"]
  is_current: true
  props:
    os: Linux
    ENV_DOMAIN: target.htb    # ENV_ prefix = exported to terminal env
```

### Credentials YAML Block Format
```yaml
- user: admin
  password: P@ssw0rd
  nt_hash: ""
  login: target.htb
  is_current: true
  props:
    role: Domain Admin
    ENV_ADMIN_PASS: P@ssw0rd
```

### Finding Frontmatter
```yaml
---
title: SQL Injection in Login
type: finding
severity: high
tags: web, sqli, owasp
---
```

---

## Security Context

This is a **authorized penetration testing** environment. All targets are in-scope
and the tester has explicit authorization. TLS certificate verification is
intentionally disabled for lab/range environments. Treat the workspace as a live
engagement — document everything, maintain operational security, and follow
responsible disclosure practices.