Reconnaissance at Machine Speed: AI-Powered Target Mapping

This is Part 2 of The Operator's Field Manual: Claude Code for Offensive Security.

The Recon Bottleneck

Every engagement starts the same way. You sit down with a target scope, open a terminal, and start the grind. DNS lookups. WHOIS. Subdomain enumeration. Port scanning. Technology fingerprinting. Directory brute forcing. Certificate transparency logs. Each tool runs one at a time because you only have one brain and two hands.

Two hours in, you have a pile of raw output scattered across six terminal tabs. Half of it is noise. You missed a subdomain because you forgot to check one wordlist. You skipped the JavaScript bundle analysis because the port scan was still running and you got distracted by an interesting finding on 8443.

This is not a skill problem. This is a bandwidth problem.

Manual reconnaissance takes 2-4 hours on a moderately complex target. That number doubles for targets with AI components, because you need to probe for LLM endpoints, check for RAG pipeline indicators, analyze response headers for model signatures, and test for chatbot interfaces that might expose tool access.

AI does not get tired at hour three. It does not develop tunnel vision. It does not have an ego that makes it chase the interesting finding instead of the important one. It runs every check, in order, every time. And when you give it parallel execution, it runs multiple checks simultaneously.

The goal is simple: map an entire target's attack surface in under 15 minutes. Here is the exact setup to make that work.

Setting Up kali-mcp

The missing piece between Claude Code and your Kali toolset is kali-mcp. It is an HTTP API bridge that wraps Kali Linux tools and exposes them as MCP-compatible endpoints. Claude Code talks to it over HTTP. The server translates those requests into actual tool executions on your Kali instance and returns structured results.

Three ways to run it:

Option 1: Docker Container (Recommended)

The cleanest setup. Run the kali-mcp server in a Docker container with your Kali tools pre-installed. Map port 5000 inside the container to port 5001 on your host.

docker run -d --name kali-mcp \
  -p 5001:5000 \
  krypteia/kali-mcp:latest

This gives you isolation. The tools run inside the container. Your host stays clean. If something breaks, kill the container and spin a new one.

Option 2: Kali VM

If you already run a Kali VM for your engagements, install the kali-mcp server natively. It is a Python Flask application that starts on port 5000.

cd /opt/kali-mcp
pip install -r requirements.txt
python server.py --host 0.0.0.0 --port 5000

Make sure your VM's network is configured so your host machine can reach port 5000. If you are using NAT, forward the port. If you are on a bridged network, hit the VM's IP directly.

Option 3: Remote SSH Tunnel

For remote Kali instances, tunnel port 5000 to your localhost on 5001:

ssh -L 5001:localhost:5000 user@kali-instance

This works for cloud-hosted Kali boxes, lab environments, or shared team infrastructure.

Verifying the Connection

Once the server is running, verify it:

# Health check
curl -s http://localhost:5001/health
# Expected: {"status": "ok", "tools_available": 13}

# List all available tools
curl -s http://localhost:5001/tools | jq '.tools[].name'

The tool list includes: nmap, nikto, sqlmap, hydra, john, gobuster, dirb, searchsploit, whois, dig, theHarvester, metasploit, aircrack-ng.

Configuring Claude Code

Add the kali-mcp server to your Claude Code MCP configuration. Open your project settings or ~/.claude/settings.json and add:

{
  "mcpServers": {
    "kali-mcp": {
      "type": "url",
      "url": "http://localhost:5001/mcp"
    }
  }
}

Once configured, Claude Code can call any kali-mcp tool directly through the MCP protocol. But the skill we are building will use the HTTP API directly via curl, because that gives us more control over arguments, timeouts, and output parsing.

The tool execution pattern is consistent across every tool:

curl -s -X POST http://localhost:5001/tools/<tool_name> \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "example.com", "flags": "-sV"}}'

Every tool returns JSON with a result field containing the tool's stdout and an exit_code field. This makes it straightforward to parse programmatically, which is exactly what our skill will do.

Building the Recon Skill

This is the core of the article. A complete Claude Code skill that executes phased reconnaissance using kali-mcp tools. Save this as .claude/skills/recon-kali/SKILL.md in your project.

---
name: Kali Recon
description: Phased reconnaissance using kali-mcp tools.
  Executes passive recon, AI component detection, and
  active scanning against authorized targets.
---

# Kali Recon Skill

Perform phased reconnaissance on an authorized target using
kali-mcp tools. Requires kali-mcp server running on localhost:5001.

## Usage

Invoke with: "run kali recon on [target]"

## Pre-Flight

Before starting, verify kali-mcp is reachable:

Run this command:
curl -s http://localhost:5001/health

If the health check fails, stop and report the connection issue.
Do not proceed without a confirmed connection.

## Phase 1: Passive Recon (No Target Interaction)

These queries hit third-party data sources only. No packets
touch the target. Safe to run without active authorization.

### Step 1: WHOIS Lookup

Run this command:
curl -s -X POST http://localhost:5001/tools/whois \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "[TARGET_DOMAIN]"}}'

Extract and record:
- Registrar name
- Registration and expiration dates
- Nameservers
- Registrant organization (if not redacted)
- Associated email addresses

### Step 2: DNS Enumeration

Run these commands sequentially:

curl -s -X POST http://localhost:5001/tools/dig \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "[TARGET_DOMAIN]", "flags": "A"}}'

curl -s -X POST http://localhost:5001/tools/dig \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "[TARGET_DOMAIN]", "flags": "MX"}}'

curl -s -X POST http://localhost:5001/tools/dig \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "[TARGET_DOMAIN]", "flags": "TXT"}}'

curl -s -X POST http://localhost:5001/tools/dig \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "[TARGET_DOMAIN]", "flags": "NS"}}'

Record all results. Pay attention to:
- Multiple A records (load balancing, CDN)
- MX records (email provider identification)
- TXT records (SPF, DKIM, DMARC, domain verification tokens)
- NS records (hosting provider clues)

### Step 3: Email and Subdomain Harvesting

Run this command:
curl -s -X POST http://localhost:5001/tools/theHarvester \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "[TARGET_DOMAIN]", "flags": "-b all -l 200"}}'

This queries multiple OSINT sources: search engines, certificate
transparency, DNS datasets, and public code repositories. Record
all discovered email addresses, subdomains, and associated IPs.

## Phase 2: AI Component Detection

These checks use standard HTTP requests to identify AI integration
points. They touch the target directly but only with normal web
traffic patterns.

### Step 1: Probe Common AI Endpoints

For each of these paths, send a request and analyze the response:

- /api/chat
- /api/completion
- /v1/messages
- /v1/chat/completions
- /api/ask
- /api/ai
- /graphql

Run this pattern for each endpoint:
curl -s -o /dev/null -w "%{http_code}" https://[TARGET_DOMAIN][PATH]

Record which endpoints return anything other than 404. A 200, 401,
403, or 405 indicates the endpoint exists. A 401 or 403 is
particularly interesting because it means the endpoint is real
but protected.

### Step 2: Response Header Analysis

Run this command:
curl -s -I https://[TARGET_DOMAIN] 2>/dev/null

Look for these header patterns:
- x-openai-* (OpenAI API proxy or integration)
- x-anthropic-* (Anthropic API integration)
- x-model-* (generic model serving headers)
- x-request-id patterns consistent with AI gateways
- server headers indicating AI platforms (e.g., vllm, triton)

### Step 3: JavaScript Bundle Analysis

Run this command:
curl -s https://[TARGET_DOMAIN] | grep -oE 'src="[^"]*\.js"' | head -20

For each discovered JS file, fetch and search for AI indicators:
curl -s https://[TARGET_DOMAIN]/[JS_PATH] | \
  grep -iE '(openai|anthropic|langchain|llamaindex|pinecone|weaviate|chromadb|qdrant|embedding|vector|completion|chat\.create)'

Record all matches. These reveal:
- Which AI SDK the application uses
- Vector database integrations (RAG pipeline indicator)
- Model names or API keys accidentally bundled
- AI feature flags or configuration

## Phase 3: Active Scanning (Authorized Only)

STOP. Confirm you have written authorization for active scanning
against this target. Do not proceed without explicit scope approval.

### Step 1: Port Scanning

Run this command:
curl -s -X POST http://localhost:5001/tools/nmap \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "[TARGET_IP]", "flags": "-sS -sV --top-ports 1000 -T4"}}'

Record all open ports, service versions, and OS detection results.

### Step 2: Web Vulnerability Scanning

Run this command:
curl -s -X POST http://localhost:5001/tools/nikto \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "https://[TARGET_DOMAIN]", "flags": "-C all"}}'

Record all findings. Focus on:
- Misconfigurations
- Default credentials
- Information disclosure
- Outdated software versions

### Step 3: Directory Discovery

Run this command:
curl -s -X POST http://localhost:5001/tools/gobuster \
  -H "Content-Type: application/json" \
  -d '{"arguments": {"target": "https://[TARGET_DOMAIN]", "flags": "dir -w /usr/share/wordlists/dirb/common.txt -t 50 -q"}}'

Record all discovered paths. Cross-reference with AI endpoint
findings from Phase 2.

## Output Format

Compile all findings into the structured report format below.
Include only confirmed findings. Mark uncertain items as
"needs verification."

### Target: [DOMAIN]

#### Infrastructure
- IP addresses and hosting provider
- CDN and WAF detection
- DNS configuration summary
- Domain registration details

#### Technology Stack
- Server software and version
- Web framework
- Frontend libraries
- API patterns detected

#### AI Components Detected
- LLM endpoints found (with response codes)
- AI SDK references in JavaScript
- Vector database indicators
- Chatbot or agent interfaces

#### Attack Surface Summary
- Total open ports and services
- AI-specific attack vectors identified
- Priority targets ranked by exploitability

#### Raw Data
- Full DNS records
- Full port scan results
- All discovered paths and subdomains

That is 90% of the work. The skill tells Claude Code exactly what to run, in what order, and what to look for in the results. Claude Code reads it, executes each step through the terminal, parses the output, and compiles the report.

The critical design choice here is phasing. Passive recon runs first because it requires no authorization and generates zero target interaction. AI component detection runs second because it looks like normal web browsing. Active scanning runs last, behind an explicit authorization gate.

This matters for real engagements. You might have authorization for passive recon on Day 1 but active scanning is not approved until Day 3. The skill accommodates that. Tell Claude Code to "run kali recon phase 1 and 2 only" and it stops before touching nmap.

Parallel Recon with Agent Teams

A single Claude Code session running the skill above takes about 12 minutes. That is already a massive improvement over 2-4 hours of manual work. But we can cut it further.

Claude Code supports spawning background agents. Each agent runs independently with its own context and tool access. For recon, this means running phases in parallel instead of sequentially.

The approach: structure your main session as a coordinator that spawns specialist agents.

Main session (coordinator):
  "Run kali recon on target.example.com with parallel agents"

  → Agent 1: Passive OSINT
    - WHOIS, DNS, theHarvester
    - Certificate transparency search
    - Writes results to targets/example.com/passive-recon.md

  → Agent 2: AI Component Detection
    - Endpoint probing
    - Header analysis
    - JavaScript bundle analysis
    - Writes results to targets/example.com/ai-detection.md

  → Agent 3: Active Scanning (if authorized)
    - nmap port scan
    - nikto web scan
    - gobuster directory discovery
    - Writes results to targets/example.com/active-scan.md

  Coordinator waits for all agents, then merges results.

You can structure this in your skill by adding a parallel execution section:

## Parallel Execution Mode

If the operator requests parallel recon, spawn three background
agents using Claude Code's agent system:

Agent 1 instructions: "Execute Phase 1 (Passive Recon) from
the Kali Recon skill against [TARGET]. Write results to
targets/[TARGET]/passive-recon.md"

Agent 2 instructions: "Execute Phase 2 (AI Component Detection)
from the Kali Recon skill against [TARGET]. Write results to
targets/[TARGET]/ai-detection.md"

Agent 3 instructions: "Execute Phase 3 (Active Scanning) from
the Kali Recon skill against [TARGET]. Write results to
targets/[TARGET]/active-scan.md"

After all agents complete, read all three output files and
compile the unified report in the standard output format.

Each agent runs its phase independently. The passive OSINT agent is querying WHOIS and harvesting subdomains at the same time the active scanning agent is running nmap. No waiting. No sequential bottleneck.

The real power comes from chaining. The passive recon agent discovers subdomains. Those subdomains feed into the active scanning agent's target list. You can structure this as a two-wave approach: wave one does passive recon, wave two takes those results and runs active scanning on every discovered asset.

In practice, parallel execution cuts the 12-minute runtime down to about 5 minutes. Three agents working simultaneously, each focused on one thing, each writing structured output that the coordinator merges into the final report.

Sample Output

Here is what the final compiled report looks like after a parallel recon run. This is realistic output from a moderately complex web application with AI features.

### Target: acme-ai.example.com

#### Infrastructure
- Primary IP: 104.26.12.87 (Cloudflare)
- Hosting: AWS us-east-1 (origin behind Cloudflare)
- CDN: Cloudflare (cf-ray headers confirmed)
- WAF: Cloudflare WAF active (403 on common attack patterns)
- DNS: 2 A records, MX → Google Workspace, SPF/DKIM configured
- Registration: GoDaddy, registered 2024-06-15, expires 2026-06-15

#### Technology Stack
- Server: nginx/1.24.0 (behind Cloudflare)
- Framework: Next.js 14.1.0 (x-nextjs-cache header)
- Frontend: React 18.2, Tailwind CSS 3.4
- API: REST at /api/*, WebSocket at /ws
- Auth: NextAuth.js (cookie pattern: next-auth.session-token)
- Database: PostgreSQL indicators in error responses

#### AI Components Detected
- /api/chat: 200 OK (POST, accepts {"message": "...", "thread_id": "..."})
- /api/completion: 405 Method Not Allowed (endpoint exists)
- /v1/messages: 404 (not present)
- OpenAI SDK v4.28.0 referenced in main-[hash].js bundle
- LangChain v0.1.x referenced in server chunk
- Pinecone client detected in API route bundle
- x-request-id header format consistent with LangServe gateway
- /api/chat response includes "model" field: "gpt-4-turbo"

#### Open Ports and Services
- 80/tcp: HTTP (redirect to 443)
- 443/tcp: HTTPS (nginx/1.24.0)
- 8443/tcp: HTTPS (alternative API endpoint, same cert)
- 3000/tcp: filtered (likely internal Next.js dev, not exposed)

#### Attack Surface Summary
- 3 confirmed AI-specific vectors:
  1. /api/chat: Direct LLM interaction, accepts user input,
     returns model output. Priority: HIGH
  2. RAG pipeline via Pinecone: potential context poisoning
     if document ingestion is accessible. Priority: MEDIUM
  3. LangChain agent detected: possible tool access through
     chat interface. Priority: HIGH
- Web application vectors:
  4. WebSocket endpoint at /ws: real-time communication,
     test for injection. Priority: MEDIUM
  5. Alternative API on 8443: may have different auth
     requirements. Priority: MEDIUM
- 14 directories discovered via gobuster
- nikto identified 3 information disclosure issues

#### Priority Targets
1. /api/chat (prompt injection, jailbreak, tool enumeration)
2. LangChain agent tool access (sandbox escape, SSRF via tools)
3. Pinecone RAG pipeline (indirect prompt injection via documents)
4. Port 8443 API (auth bypass, different security controls)
5. WebSocket /ws (injection, privilege escalation)

That is the output of 5 minutes of parallel agent work. Every finding is structured. Every priority is ranked. Every next step is clear. You take this report and feed it directly into your exploitation workflow.

Compare that to the alternative: six terminal tabs, scattered notes, half-remembered findings, and a vague sense that you probably missed something. The structured output alone is worth the setup time.

What's Next

You now have a working reconnaissance pipeline that maps a target's full attack surface, including AI components, in minutes instead of hours. Passive OSINT, AI endpoint detection, active scanning, all orchestrated through Claude Code skills and parallel agents.

But recon is just the first phase. The report above identifies targets. It does not attack them.

Part 3: Building Adversarial Agents takes the recon output and turns it into action. We will build Claude Code agents that take a target profile as input and generate targeted attack payloads. Prompt injection attempts tailored to the specific LLM detected. RAG poisoning payloads designed for the specific vector database in use. Tool abuse sequences based on the agent framework identified during recon.

The recon output becomes the adversarial agent's briefing document. Everything it needs to know about the target, structured in a format it can reason about and act on.

That is where this gets interesting. Reconnaissance tells you what is there. Adversarial agents tell you what breaks.

Follow along at krypteia-sec.com. The field manual continues.