~/tutorials/031-the-lab-you-own.md

031: The lab you own

Field Work ended inside this tree. Everything you ran, ran here, where the shell cannot execute anything and the worst outcome is a strange answer.

This tier is different, and it starts by changing machines. The commands from here on are for your own box, aimed at targets you built to be broken. Nothing in the fifteen lessons ahead executes on this site, and nothing here can check your output. That is not a loss. It is the shape of real work, where nobody hands you a checker.

Before a single scan, the target exists. This lesson builds it.

Why own the target

The rule has not moved since lesson zero. Your machines, or somebody's written word. Everything in First Steps and Field Work practiced it inside a jail that cannot leave.

The sentence that matters when you leave: an attack is a question, and a question asked of a machine you do not own is not research. It is trespass with extra steps.

Nothing in this tier needs anybody's permission. That is what owning the target buys.

The shape

A lab is three decisions, and this lesson walks a reader who has never opened a hypervisor through all three. If you already run one, read the ladder anyway. Teaching it later is the other half of knowing it.

A hypervisor. VirtualBox is free and boring, which are its best qualities.
An attacker box. Kali or Parrot, whichever. It is a Linux desktop with tools preinstalled, not a magic credential.
A target box. One deliberately vulnerable machine to start.

The free standard is Metasploitable 2. An old Ubuntu server image carrying a pile of intentionally broken services. If you can destroy that box from your attacker VM, you have a place to practice everything this tier describes.

Metasploitable has a floor, and the floor is real. It is a 2008 era 32 bit Ubuntu image, and on Apple silicon it will not run under VirtualBox without emulation. If your machine cannot stand it up, use OWASP Juice Shop instead. Modern stack, one command to run, and every lesson in this tier still applies, because the techniques are aimed at the class of bug, not the vintage of the image. Run it in the target guest rather than on the host or in Docker, so the lab keeps two machines and rung three still tests what it claims. Do not conclude the tier is too simple when you are actually blocked. Come back to Metasploitable when you want the whole broken server. It stays the spine of the tier either way.

Host-only networking is the setting to prefer. Your two VMs see each other and neither can see your real network. A lab that can accidentally scan the house is not a lab yet.

The line, written down

Before the first boot, one sentence in a file you will not lose:

$ echo "This network exists to be attacked. Nothing on it is real. Nothing off it is a target." > ~/lab-note.txt

It reads like ceremony until the night you are tired and the scope question arrives at 2AM. Then it is the sentence you reread. Write it on your own machine, where it is yours.

The ladder

Three states, each with what success looks like and what failure looks like. A lab you have not seen working is a lab you cannot debug. None of these commands run on this site. They are yours, and your machine's answers are the receipt.

Rung one, the hypervisor is fine

Install VirtualBox, download a current Ubuntu desktop iso, and boot it as a new guest. The first boot of a Linux guest is the moment a hypervisor proves itself, and the moment most people first believe something is broken that is not.

What you should see, and why:

A logo, then a plain text splash that ends at a login prompt or a desktop. Small font, unglamorous, correct.
The guest is slow to reach the desktop. It is sharing your machine, and the first boot installs packages into a virtual disk. Slowness here is the hypervisor doing its job, not failing it.
The display is small, or the wrong resolution, until you install the guest additions. That is cosmetic, and you can fix it after the lab exists.

The state that looks wrong but is fine: a black screen for the first ten or twenty seconds. The virtual disk is being written. Wait it out before you reinstall anything.

The failure state: the machine refuses to start the guest at all, with a message about virtualization being disabled. That is your host firmware, not VirtualBox. The setting is called VT-x on Intel and AMD-V on AMD, it lives in your firmware setup, and enabling it is a five minute fix that only ever happens once.

When the guest reaches a desktop, the hypervisor is fine. Give the VM a second gigabyte of memory if you have it and move on.

Rung two, the attacker box is fine

Kali and Parrot are Linux desktops with the tools preinstalled. Download the one you chose, boot it the same way, and do not trust the word preinstalled. Verify the tools are actually there before you need them at two in the morning:

$ which nmap
$ nmap --version
$ which nikto
$ which msfconsole

What you should see, and why: a path for every which answer, and a version banner for each tool you asked about. The banner is the receipt. A distribution ships, and a mirror corrupts, and an install half finishes, and the tool that answers nothing on the night you need it was missing a week ago when checking was free.

The failure state: command not found. Not a verdict on you or the distribution. The box needs an update, or the tool set you picked a smaller image for does not carry it. Fix it now, with the desktop in front of you, and the fix is the first repair this tier asks for. An attacker box you have not verified is an assumption wearing a distribution name.

Rung three, host-only is genuinely isolating

Two VMs, both booted, adapter set to host-only on both. The positive test first, from the attacker box:

$ ip -br addr
$ ping -c 3 <target-ip>

What you should see, and why: an address in the host-only range for the interface you configured, then three replies with times in the single digit milliseconds. Two machines on the same virtual switch, nothing between them.

Now the negative test, which is the one that matters:

$ ping -c 3 <router-ip>
$ ping -c 3 1.1.1.1

What you should see: nothing. No replies, 100 percent loss, both times. Your router does not know this network exists, and the internet does not know you do. That silence is the lab being a lab.

The failure state is the dangerous one, because it looks like success: the guest reaches the router or the internet, which means the adapter is NAT or bridged, not host-only. Tell them apart before you scan anything. NAT rewrites the guest's traffic so it comes from your machine, and from your router the VM is indistinguishable from you. Bridged takes an address on the house network, as a peer of your real machines, so it can reach anything in the house, and its traffic sits on that network where the household and the gateway can see it. If the negative test answers, stop, open the adapter settings, and read the attached-to field until it says host-only. A lab that can accidentally scan the house is not a lab yet, and the first scan you fire from a mis-set adapter is the accident.

Where this site still helps

The shell at the bottom of this page still answers for its own tree, and the tiers you finished still run:

ls ~/tutorials | wc -l

Every fact on this site stays checkable. The new part is that your machine's facts are yours to check, with real tools, against a box that exists to be broken.

Try it

Build the lab through all three rungs. First boot of the hypervisor, verified tools on the attacker box, then the positive and negative host-only tests, in that order.
Break the network on purpose, then fix it. A lab you have not repaired once is a lab you do not understand.
Write the scope note and keep it.

The next lesson points the first real tool at what you just built.