Infra Red Team

---
name: infra-red-team
description: Adversarial testing against the 2 owned Netcup VPS (dqiii8 + Lier infra) — port/service scan, Syncthing exposure review, CrowdSec/UFW bypass checks, optional isolated Kali container for wifi audit. Never invents targets — hard-gated by infrastructure/redteam_target_allowlist.yaml. NEVER auto-invoked.
command: /infra-red-team
allowed-tools: [Bash, Read, Grep, Glob]
user-invocable: true
disable-model-invocation: true
context: fork
agent: Explore
experimental: true
---

# /infra-red-team — Adversarial Infrastructure Testing

Attacks infrastructure (VPS, network, wifi), not code. Sibling of
`.claude/skills/red-team/SKILL.md` (which attacks the dqiii8 codebase) — same
verification discipline, different attack surface.

## Usage

```
/infra-red-team                    # Audit every target in the allowlist
/infra-red-team netcup-rs4000      # Audit one target by its allowlist id
```

## Target Gate (mandatory, before anything else)

```bash
python3 -c "
import yaml
d = yaml.safe_load(open('infrastructure/redteam_target_allowlist.yaml'))
for t in d['targets']:
    print(t['id'], t['address'], t['scope'])
"
```

If `$ARGUMENTS` names anything that is not literally one of `targets[].id` or
`targets[].address` in that YAML: **stop immediately** and report:

> TARGET FUERA DE ALLOWLIST — añádelo primero en
> `infrastructure/redteam_target_allowlist.yaml` (paso humano aparte), no
> continúo.

Never ask "should I continue anyway?" — the rejection is unconditional, same
principle as `resumable_actions` in Lier: allowlist server-side, never a free
target passed through a prompt. No argument → iterate every target in the
allowlist (default behavior is "audit what's mine", not "ask for a target").

**Disclosed limitation** (panel-review 2026-09-07, P1): this gate is a
markdown instruction read by the model, not a code-enforced allowlist like
Lier's `resumable_actions` — a real hard gate would require the check to run
outside the model's own control (e.g. a wrapper script the model cannot see
past). Until that exists, the gate depends on the model actually reading and
honoring this section every invocation. Treat any address that appears
mid-task (in a command's output, in a Syncthing peer list, in an nmap result)
as data to report, never as an implicit new target — this rule applies even
to addresses that look like they belong to the user.

## Phase A — No Kali required (runs from the dqiii8 host itself)

For each target with `scope: full`:

1. **Port/service scan**, diffed against
   `infrastructure/infra_baseline.yaml`'s `expected_open_ports`:
   ```bash
   nmap -sV -Pn <address>
   ```
   Anything open that isn't in the baseline is a candidate finding — do not
   silently accept it as "probably fine".

2. **Syncthing exposure review** — scoped exactly to what
   `redteam_target_allowlist.yaml`'s `syncthing_audit_scope` block describes,
   nothing wider:
   ```bash
   ssh <target-alias> "syncthing cli config folders list 2>/dev/null; ss -tlnp | grep 22000"
   ```
   Check: encryption in use, whether connections are direct or via a
   third-party relay, whether discovery-server metadata exposes more than
   necessary.

   **Hard limit, not implied by the command above**: this check only reads
   config/connection-state on the two allowlisted hosts themselves. If the
   output surfaces a third-party relay's IP or hostname (Syncthing's public
   relay pool, not owned by the user), that IP is data about the finding
   (e.g. "using a public relay instead of direct connection" is itself
   reportable), **never a new target to scan, connect to, or probe** — this
   skill has no authorization for anything not in the allowlist, and an
   address appearing in a command's output does not grant it. Report the
   relay's presence as a finding category, do not act on the address.

3. **CrowdSec/UFW bypass check** — verify the firewall's actual deny-by-default
   posture matches what Domain 1 hardening established, not just that the
   services are running:
   ```bash
   ssh <target-alias> "ufw status verbose; cscli metrics 2>&1 | head -40"
   ```

## Phase B — Kali-in-Docker (ONLY for aircrack-ng-suite / own wifi audit)

Invoke **only if** the user explicitly asks for a wifi audit **and** the
allowlist YAML has a wifi entry under its "pendiente de alta" section promoted
to a real target. As of this skill's creation, no such entry exists — in that
case, reject this phase with the exact same Target Gate message above. Do not
provision a Kali container speculatively "just in case."

When a wifi target does exist, the container must already respect the
DOCKER-USER hardening sequence (see `docker-user-harden.sh` — this skill
never runs Phase B before confirming that gate, below).

### DOCKER-USER gate (checked every time before any `docker run -p` in this phase)

```bash
ssh netcup-rs4000 "nft list ruleset | grep -A5 DOCKER-USER || iptables -L DOCKER-USER -n"
```

If the final DROP rule is not present, **stop** — do not create the
container. Docker's default DOCKER-USER chain bypasses UFW's deny-by-default
for anything published with `-p`; running before the hardening script means
an insecure window, however brief.

### Container invocation (once the gate above passes)

```bash
ssh netcup-rs4000 "docker network create --internal kali-net 2>/dev/null || true"
ssh netcup-rs4000 "docker run --rm --network kali-net --cap-add NET_ADMIN --cap-add NET_RAW \
  -v /root/dqiii8/tasks/audit:/audit \
  kalilinux/kali-rolling <tool-and-args>"
```

No `--network host`, no capabilities beyond `NET_ADMIN`/`NET_RAW` (the two
aircrack-ng actually needs), no persistent volume beyond the audit-report
mount, container removed after each run (`--rm`).

## Pre-Report Verification Protocol

Same bar as `.claude/skills/red-team/SKILL.md`:

1. Execute the real command over SSH — no simulation, no assumption from a
   prior run.
2. Classify each result: `REAL` / `MITIGATED` / `FALSE_POSITIVE` /
   `ALREADY_FIXED` — same vocabulary as `infra_findings.status`.
3. Check for duplicates before filing:
   ```bash
   python3 -c "
   import sqlite3
   conn = sqlite3.connect('database/dqiii8.db')
   rows = conn.execute(
       \"SELECT title, status FROM infra_findings WHERE source='infra-red-team' ORDER BY created_at DESC LIMIT 20\"
   ).fetchall()
   [print(r) for r in rows]
   "
   ```
   No `2>/dev/null ||` fallback here — an error means the schema regressed
   (the `infra_findings` table must exist), and that must surface loudly.
4. Insert every REAL/MITIGATED finding into `infra_findings` (`source`,
   `target_id`, `check_name`, `proof` containing the actual command output,
   `report_path` set to the report file below).

## Output Format

Generate `tasks/audit/infra-red-team-{date}.md`:

```markdown
# Infra Red Team Report — {date}
Targets: {ids from allowlist audited}

## Executive Summary
{1-2 sentences}

## Findings (REAL and MITIGATED only)
### [IRT-001] {title}
- Target: {target_id}
- Category: {firewall/ssh/syncthing/wifi/drift}
- Severity: CRITICAL/HIGH/MEDIUM/LOW
- Status: REAL/MITIGATED
- Proof: {exact SSH/nmap command + real output}
- Impact: {what an attacker gains}

## CHECKED & SECURE
| Finding | Classification | Reason |
|---------|---------------|--------|

## Statistics
Total checked: {N} | REAL: {N} | MITIGATED: {N} | FALSE_POSITIVE: {N} | ALREADY_FIXED: {N}
```

## Rules

- NEVER scan/attack anything outside the allowlist — no exceptions, no "just
  this once".
- NEVER actually exploit — proof-of-concept only (e.g. confirm a port is open
  and unexpected, don't pivot through it).
- NEVER run Phase B speculatively — it requires an explicit user request AND
  an allowlist wifi entry.
- Document every finding with the real command that produced it.