What LOTTunnels and LOLBAS taught us about skills

The skills pack is a collection of adversarial SKILL.md files — concise procedures that tell a coding agent how to find and fix security issues in code, CI/CD, cloud config, docs, tests, and frontend UI. We ship the pack through the CLI and a private GitHub repo, and every claim about its size is re-derived from data/skills-catalog.json by a verifier.

A user pointed us at LOTTunnels (living-off-the-tunnel binaries: ngrok, cloudflared, devtunnel, VSCode tunnels, and ~30 more) and LOLBAS (living-off-the-land binaries, scripts, and libraries: 241+ Windows programs abused for execution, download, evasion, credential access, and persistence). The question was whether any of that knowledge should become new adversarial.sh skills.

We treat external registries as input to a fit check, not as content to merge. The pack's mission is find and fix security issues in customer code and CI/CD. A technique can be real and important and still be out of scope if it is pure operator tradecraft rather than something a development agent can audit in a repo.

LOTTunnels catalogs binaries that create inbound tunnels from the public internet to a developer machine: cloudflared, ngrok, devtunnel, localtunnel, expose, tailscale, tmate, and many others. The documented abuse patterns are access, exfiltration, phishing, download, shell access, and install.

We mapped these against the existing skills pack. The overlap was larger than we expected. Several tunnels map directly onto skills we already ship:

• Data exfiltration via outbound tunnels is covered by agent-exfil-channels, ssrf-infrastructure-review, and the broader set of secret-hygiene and network-trust skills.
• Developer tooling as persistence or remote-access vector is adjacent to mcp-server-attack-surface and the CI/CD pipeline-poisoning skills — the common theme is "a trusted dev tool becomes an ungoverned ingress."
• Cloudflared / ngrok in container or VM workloads overlaps with container-build-poisoning and k8s-privileged-pod-escape-surface: if a workload can open a tunnel, its network model is too permissive.

What LOTTunnels added was a signal vocabulary: process names, CLI flags, and config files to hunt for in logs and filesystem snapshots. That is detection content, not a new skill category. We did not port individual tunnel entries, but we now have a shortlist for a future class-level skill: a single skill that teaches an agent to recognize tunnel binaries, inspect their config, and trace whether the containing workload has unnecessary egress.

LOLBAS documents Windows binaries, scripts, and libraries that attackers abuse for execution, download, encoding, persistence, and credential access — certutil downloading executables, reg.exe saving hives, bitsadmin, mshta, wmic, and 200+ others.

Almost all of this is out of scope for the current pack. The pack is designed to run inside coding agents that read code, config, and CI pipelines. LOLBAS entries are primarily endpoint detection and incident response signals: they describe what an analyst should look for on a compromised Windows host, not what a developer should fix in source control.

The exceptions — the parts worth extracting — are where LOLBAS touches the software supply chain:

• Build and installer tooling abused for execution (msbuild, installutil, regsvcs, wscript/cscript). These are relevant to Windows-based build agents and release pipelines, and could feed a future Windows CI hardening skill.
• Downloaders used in install scripts (certutil, bitsadmin, ftp.exe, winget remote installs). These already overlap with supply-chain and package-manager skills, but a Windows-specific "install-script downloader audit" is a plausible future addition.

We added two LOLBAS-derived skills focused on the software supply-chain corner: one for build-tool abuse and one for unpinned downloaders in install scripts. Both are Windows-specific because the underlying binaries are Windows-native, but the audit procedure (find dangerous invocation, verify pinning/signature, replace with hardened equivalent) is the same cross-platform discipline the rest of the pack teaches.

The audit did not add new skills, but it did expose stale copy. The skills catalog already held 136 entries, yet two older blog posts still said 134. The verifier flags mismatches like that, but only on pages registered in data/claims.json — the blog text itself had to be corrected manually.

We updated the stale mentions in keyless-agent-scanning and provable-claims, refreshed the soft-floor basis in the claims registry, and added the API pack/category counts to the provable-claims example output so the next reader sees the full set of derived checks.

Current state, as re-derived by python3 scripts/verify-claims.py: 52 checks pass, 0 fail. The skills pack is 139 SKILL.md files across 15 categories. The attack library remains 56 validated techniques across 10 categories.

The audit produced two candidates for Windows CI and one for cloud/container tunnel detection. We added all three to the skills pack:

1. Developer-tunnel detection

   A class-level skill that scans repo files, container images, CI logs, and devcontainer definitions for tunnel binaries and config artifacts, then maps each finding to the least-privilege network change that would remove the need for the tunnel. It is now skills/cicd-devops/developer-tunnel-detection.

2. Windows CI install-script downloader audit

   Two narrowly scoped skills for Windows-based build agents and release scripts: windows-build-tool-execution-surface flags MSBuild, .NET compilers, InstallUtil, Regasm, and Regsvcs abuse; windows-install-script-downloader-audit flags certutil, bitsadmin, mshta, and similar unpinned downloaders.

These skills are now in the committed catalog, and the count moved from 136 to 139. The postmortem is not that public registries should be merged wholesale — it is that a small, defensible subset can be extracted, rewritten for code-review agents, and validated the same way as every other skill.