AI-Assisted Security Assessment

Where: the shared Linux box (the Dell in the room) When: Break It rotation — you rotate here while other groups do picoCTF What you leave with: a real vulnerability report your AI assistant drafted from findings you generated

This is the closest thing today to the actual job. You’ll scan a target, find what’s wrong with it, prove it, and write it up — with Claude Code doing the parts a junior analyst would hand to a tool, and you doing the judgment.

Everything here runs on this one box. The target lives on the box itself. Nothing you do touches the venue network, the internet, or anyone else’s machine. That containment is the whole reason this is legal — remember the authorization rules from the start of Break It.

Get in

From your laptop (Windows PowerShell, or Mac/Linux Terminal):

ssh workshop@<box-ip>

Your facilitator writes the box’s IP and the password on the board. Once you’re in, start Claude Code:

claude

Keep two things side by side: the terminal where you run tools, and Claude Code to interpret what they tell you.

Stage 1 — Recon (find the target, see what it runs)

Ask Claude Code to help, then run it yourself:

“I’m on an authorized lab box. There’s a vulnerable web app running locally on port 8080. Give me an nmap command to scan this box and identify what services and versions are running, and explain what the output means.”

Run the scan it suggests (something like nmap -sV localhost). Then paste the output back to Claude:

“Here’s the nmap output: [paste]. What’s running, and which of these is worth a closer look for a security review?”

The lesson: recon is just looking — and it already tells an attacker most of what they need. You didn’t break anything yet. You just read what the machine announces about itself.

Stage 2 — Prove the vulnerability

Open the target in the box’s browser (or ask your facilitator to project it): http://<box-ip>:8080 — it’s DVWA, a web app built to be broken. Log in with admin / password (that it has a default login is lesson number one).

Pick the SQL Injection or Command Injection page. Ask Claude to teach, not to hand you the answer:

“I’m on a DVWA SQL injection training page, authorized lab. Don’t give me the final payload — explain what SQL injection is, why this input box is vulnerable, and what I should try first to confirm it.”

Confirm the vulnerability. The point isn’t to be a wizard — it’s to see that an input box which trusts whatever you type is a door, and to understand why.

Stage 3 — Crack the passwords

Attackers who get in usually find a file of password hashes. Whether those hashes are worth anything depends entirely on whether the passwords were any good. Find out:

cd ~/crack-me
cat README.txt
john --format=raw-md5 hashes.txt

Watch them fall — seconds, most of them. Ask Claude:

“John just cracked these hashes instantly: [paste]. Why were these so fast to crack, and what would have made them resistant?”

Tie it back: the OSINT brief said Marrowfield uses one shared admin login for all their gear. If that one password is on this list — and passwords chosen like this always are — every device falls at once.

Stage 4 — Let AI draft the report (and then fix it)

This is the payoff, and the part that’s genuinely the job. Hand Claude everything you found and have it write the report:

“Write a short vulnerability assessment report for a non-technical nonprofit director. Findings: [paste your nmap results, the injection you confirmed, and the cracked passwords]. Structure it as: summary, findings ranked by severity, and plain-language recommendations. One page.”

Then audit what it wrote. This is the skill that separates someone who uses AI from someone AI uses:

Did it invent a finding you didn’t actually confirm? Cut it. A report with a made-up vulnerability is worse than no report.
Did it get a severity wrong — call something critical that’s minor, or vice versa?
Did it recommend something that doesn’t fit a 14-person nonprofit with no IT staff?

The corrected report is yours. It’s also, almost exactly, a deliverable a real security consultant would bill for.

The bigger question — this is a guardrails moment

You just watched Claude Code run scanning tools, interpret attacks, and write a security report. It behaved like an autonomous network agent — the kind of thing people are racing to build.

So the question the industry is actually wrestling with, and that you’re now qualified to have an opinion on:

What should you let an agent like this do on a network by itself, with no human checking?

Reading and reporting? Probably safe.
Running scans automatically? Against what — and who authorized it?
Fixing things on its own — changing firewall rules, disabling accounts?
What happens when it’s confidently wrong, like your tutor bot was this morning, but this time it has the keys?

There’s no clean answer, and that’s the point. Write down where you’d draw the line. That’s the raw material for the bonus guardrails activity — and it’s a more sophisticated question than most working professionals have thought through.

Facilitator notes

Why DVWA. It’s the standard beginner-legible vulnerable target, runs fully local in Docker (see workshop-box-setup.sh), and every vuln has a difficulty slider set to “low” for a first-timer. No external target, no RF, no legal exposure.

Rotation, not everyone at once. One box can’t take 25 SSH sessions doing heavy work. Run this as a station of 3–5 while other groups do picoCTF, and project Stage 4 (AI drafting the report) for the whole room — that’s the moment worth everyone seeing.

The agent framing is the throughline, not a tangent. Stages 1–4 are impressive on their own, but the guardrails question at the end is what makes this an AI workshop and not just a security one. Give it real time in the Break It debrief. It connects the tutor bot’s wrong answers (morning), this agent’s power (afternoon), and the bonus guardrails activity into one argument: capable AI plus network access needs judgment you have to supply.

Optional projector demo — AI man-in-the-middle (advanced, you drive it). On the box, bettercap can ARP-spoof a facilitator-owned phone on the lab and capture its plaintext traffic; feed the capture to Claude to narrate what’s leaking. It’s a vivid “why unencrypted + unsegmented is dangerous” moment and ties to the Phase 2 DNS lesson. Keep it facilitator-only and lab-scoped — do not have participants ARP-spoof, and never target a device you don’t own. If bettercap is fiddly on the day, skip it; the assessment above carries the phase.