What is Metasploitable 2, and why every lab has one.

Metasploitable 2 is a deliberately vulnerable Ubuntu-based Linux virtual machine, built and distributed by Rapid7 – the same company behind the Metasploit Framework – specifically as a safe, legal training target. It is not a real production system, and it isn't a CTF box built around a hidden-flag philosophy where the fun is in the puzzle. It's simpler and blunter than that: a box riddled with real, well-documented, publicly known vulnerabilities, placed there on purpose, so you have something to point a scanner and an exploit at without doing anything illegal.

If you've spent any time around pentesting courses, OSCP-adjacent study guides, or home-lab writeups, you've almost certainly seen it mentioned. It shows up constantly for a simple reason: it's free, it's small, it boots reliably in VirtualBox or VMware, and its vulnerabilities are old enough and well-documented enough that virtually every write-up, walkthrough, and course module lines up with what you'll actually see on your own screen. That consistency is underrated – when three different tutorials all describe the same banner, the same port, and the same exploit path, you spend your mental energy learning the technique instead of debugging why your environment doesn't match anyone else's.

It's also deliberately unglamorous. There's no elaborate backstory, no lore, no multi-stage puzzle gating the "real" vulnerability behind a red herring. Every service on the box is broken in a specific, nameable way, and that's the entire point – it's a reference implementation of failure, not a game.

Why a training target like this exists

Practicing enumeration and exploitation techniques against real systems without authorization is illegal and unethical, full stop – it doesn't matter how curious you are or how "harmless" the technique feels. Scanning, exploiting, or even just poking at infrastructure you don't own and don't have explicit written permission to test is a crime in most jurisdictions, and "I was just learning" is not a defense.

Metasploitable 2 solves that problem cleanly. It's something you're explicitly meant to attack, running on your own isolated network, with no victim on the other end and no ambiguity about consent. Rapid7 built and shipped it for exactly this purpose, which means every technique you practice against it – port scanning, service enumeration, exploit development, post-exploitation – has a legitimate, sanctioned target to land on.

This matters more than it might seem at first glance. Authorization is the single line that separates a penetration tester from a criminal running the exact same commands: the tooling and the technique are identical, and the only thing that changes is whether the owner of the system said yes. Building muscle memory on a box you're allowed to break means that, when you eventually do sign a scope-of-work document for a client, the mechanics are already second nature and your attention can go entirely to methodology, reporting, and judgment calls rather than to figuring out which flag does what in a tool you've never run before.

What's actually inside it

This isn't a mystery box – its vulnerabilities are genuinely well-documented public information, catalogued in countless writeups over more than a decade. At a high level, it ships with:

This is intentionally a list, not a walkthrough. The actual step-by-step exploitation of each of these – the exact commands, the Metasploit modules, the manual alternatives – lives in a separate companion article, because that content deserves room to be done properly rather than compressed into a paragraph here.

What's worth noting is how deliberately layered this is. Some of these services get you a shell in one or two commands with almost no thought required: the vsftpd backdoor and the UnrealIRCd backdoor are close to instant wins once you know what to look for. Others, like the Samba and distcc issues, require you to actually understand what the underlying flaw is doing before an exploit will land cleanly. And the credential-based issues on MySQL, PostgreSQL, and Tomcat teach a different skill entirely: recognizing that not every foothold requires an exploit at all – sometimes the front door is just unlocked.

The vulnerability categories it's actually teaching

Individually, that list reads like a museum of old CVEs. Grouped by underlying lesson, it's actually teaching four categories of failure that are still very much alive today:

• Backdoored software. vsftpd 2.3.4 and the compromised UnrealIRCd build are both cases where the software itself was tampered with before it ever reached a user – a supply-chain problem, not a coding bug.
• Default and weak credentials. Tomcat, MySQL, PostgreSQL, and others fail here in the most mundane possible way: nobody changed the password, or there wasn't one required to begin with.
• Outdated, unpatched services. Samba and distcc represent the "we never got around to updating this" failure mode – known fixes existed, they just weren't applied.
• Misconfigured file-sharing and RPC services. NFS exports and Java RMI are both cases where the service works exactly as designed, but the configuration handed out far more trust than it should have.

These four categories still show up in real-world breach reports today – supply-chain compromises, credential stuffing against default logins, unpatched internet-facing services, and overly permissive file shares are recurring headlines, not historical footnotes. That's the actual reason a training box built well over a decade ago is still relevant: the specific CVEs are old, but the failure patterns they represent haven't gone anywhere.

That's also why so many courses and certifications keep it in the curriculum instead of retiring it in favor of something newer. The goal was never to memorize a fixed list of CVE numbers from the mid-2000s – it's to build the instinct to ask "is this software backdoored, is this login still default, is this service overdue for a patch, is this share handing out more than it should" every time you land on a new target, regardless of what year it is or what the target actually runs.

How it fits into a home lab

Metasploitable 2 isn't meant to run in isolation. It's meant to sit on the same isolated, host-only (or NAT-only – never bridged to your real LAN) virtual network as an attacker VM, typically Kali Linux, so you can scan, enumerate, and exploit it entirely inside your own machine with no traffic ever touching your home network or the internet. If you haven't set that network topology up yet, building a home lab on one laptop walks through exactly how to get an isolated attacker-and-target network running on a single machine.

Once your attacker VM and Metasploitable 2 are both up and talking to each other on an isolated network, the natural next step is the actual exploitation walkthrough – Metasploitable 2: step-by-step walkthrough – which goes service by service through enumeration and exploitation in detail.

Frequently asked questions