Step 129. Attacking Another VulnHub Vulnerable VM — Apply the Whole Routine to a Target You’ve Never Seen

Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★★★☆ | Estimated time: 4 hours

Prerequisites: Steps 111–128 — you have completed the journey through Kali installation, MS2 reconnaissance (Step 113), getting shells (Steps 117–121), password attacks (Steps 122–124), privilege escalation (Steps 125–126), post-exploitation (Step 127), and reporting (Step 128).

What you need: VirtualBox, a Kali VM, one beginner-friendly vulnerable VM downloaded from VulnHub (vulnhub.com), and a Host-only network. This chapter’s lab screens are marked as screen examples — reproducing them in your own lab is the mission.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.

MS2 (Metasploitable2) was "a workbook you solve knowing the answers" — you already knew where it would break. VulnHub machines are different. They show a difficulty rating but no answer key — a mock exam. Today’s question is a single one: does the sequence you’ve learned (recon → enumeration → intrusion → privilege escalation → documentation) still work on a target you’ve never seen? If it does, the techniques belong to you, not to a specific machine.

1. Learning Objectives

By the end of this chapter, you will be able to:

Pick a beginner-friendly machine on VulnHub and add it to your Host-only lab
Find the IP of an unfamiliar DHCP-booted VM with a ping scan
Apply the recon → enumeration → intrusion → privilege escalation routine to a new target with no guide
Classify the cause when stuck: "a service I don’t know, or one I know but a different version?"
Leave the entire attack process as a reproducible record

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Kali Linux + VirtualBox Host-only network, a VulnHub vulnerable VM
Today’s commands	`sudo nmap -sn <subnet>` (IP discovery), `nmap -p- -sV` (full recon), `searchsploit` (exploit search) — all learned in Steps 113–127
Concepts needed	Generalizing techniques, the routine, flags (user/root), classifying roadblocks
Today’s artifact	An attack record for one new VM (`vm-attack-notes.md`) — reaching root with no guide

2-1. VulnHub — A Workbook Without Answers

VulnHub is a public repository of "virtual machines built vulnerable on purpose." Each machine comes with only a rough difficulty rating and a short hint — no answer key. A frequently recommended beginner pick is an old, simple machine like the Kioptrix Level 1 series — it has fewer services than MS2, making it great for practicing the routine.

Each machine marks its goal as a flag. Usually there are two: user.txt, readable from a regular user shell, and root.txt, readable from root. Today’s completion condition is finding these flags with your own hands.

2-2. Generalizing the Routine — Same Sequence, Different Target

Let’s lay out again the five beats we’ve been repeating since Step 113.

Phase	What you do	Where you learned it	Key commands/tools
Recon	Full survey of open ports and services	Step 113	`nmap -p- -sV`
Enumeration	Investigate the attack surface per service/version	Steps 113–114	Banners, `searchsploit`
Intrusion	First shell through one vulnerability	Steps 117–121	Metasploit or manual exploit
Privilege escalation	From a low shell to root	Steps 125–126	Enumeration scripts, SUID/kernel checks
Documentation	Leave a reproducible record	Steps 127–128	Saving output, checklists

One scary fact — the only thing that changes in this table is the "target IP." The machine changes; the sequence and tools do not. That is what "the technique has generalized" means, and it’s what you’ll prove today.

2-3. A Framework for When You’re Stuck

On a new target, you will get stuck at least once. When that happens, there’s a question to ask instead of panicking.

"Is this a service I don’t know, or one I know but a different version?"

A service you don’t know → study is the answer. Identify it from the port number and banner, and spend 30 minutes researching what that service normally does.
A known service, different version → enumeration is the answer. Even for the same service, known vulnerabilities differ by version, so search again on searchsploit with the exact version string.

Being stuck is not a signal of lacking skill — it’s a signal of lacking information. And the information is almost always already inside the scan results you received.

3. Follow Along

The VM screens below are screen examples showing what a typical run looks like. Your machine, versions, and IP will differ — don’t copy the examples; filling in each step with your own output is today’s exercise.

3-1. Picking a Machine and Adding It to the Lab

Pick one beginner (Easy) machine on VulnHub. Three selection criteria:

Difficulty marked Easy/Beginner
Many downloads, so there are resources (hints) available
A file format compatible with VirtualBox (.ova or .vmdk)

Register the downloaded file in VirtualBox and set the network adapter to Host-only — it must be the same adapter as the Kali VM for them to see each other. This is exactly the setup you used when bringing up MS2 in Step 112.

3-2. Finding the IP — "It’s On, but I Don’t Know Its Address"

Most VulnHub machines get their IP via DHCP. A login screen pops up and never tells you the address. So the first command is not an attack — it’s discovery.

Input (from Kali):

sudo nmap -sn 192.168.56.0/24

Screen example:

Nmap scan report for 192.168.56.1
Host is up (0.00010s latency).
Nmap scan report for 192.168.56.100
Host is up (0.0012s latency).
Nmap scan report for 192.168.56.103
Host is up (0.0035s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 2.87 seconds

How to read it: -sn is a ping scan that finds only "live hosts" without a port scan. 192.168.56.1 is the Host-only adapter (the host), .100 is usually the DHCP server — so the remaining .103 is our target candidate. Confirm your Kali’s own IP with ip addr and exclude it to be sure.

Why: every intrusion begins with knowing the address. This chore of "finding the target first" is the first five minutes of real-world reconnaissance.

3-3. Full Recon — Exactly as in Step 113

Once you have the IP, it’s the routine’s first beat. Skimp here and you’ll pay double later.

Input:

nmap -p- -sV 192.168.56.103 -oN scan_full.txt

Screen example (typical for a beginner machine):

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 4.7p1 (protocol 2.0)
80/tcp open  http    Apache httpd 2.2.8
139/tcp open netbios-ssn Samba smbd 3.X
445/tcp open netbios-ssn Samba smbd 3.X

How to read it: the port is the number, the service is the occupation, and the version is the coordinate of the weakness. A line with a version like "Apache 2.2.8" is your investigation list. Always save it to a file with -oN scan_full.txt — Step 127’s lesson: "a discovery not saved is a discovery that never happened."

3-4. Enumeration — Ask Each Service a Question

Ask every line of the table you received the same question — "does this version have a known hole?"

Input:

searchsploit samba 3
searchsploit openssh 4

Screen example:

------------------------------------------- ---------------------------------
 Exploit Title                             |  Path
------------------------------------------- ---------------------------------
Samba 3.0.20 < 3.0.25rc3 - 'Username' map  | unix/remote/16320.rb
------------------------------------------- ---------------------------------

How to read it: searchsploit is a dictionary of exploit code inside Kali (a local copy of exploit-db). Search by service name + version and candidates appear. If there are no candidates, fold that path for now and move to the next service — the seed of the time management you’ll learn in Step 130 is right here.

Why: on MS2 you knew in advance "where it breaks," but today this search result is your only compass. The deeper the enumeration, the more accurate the compass.

3-5. Intrusion and Flags — The Routine’s Last Beat

Once you’ve picked a candidate exploit, try it the same way as Steps 118–121 — ride Metasploit (msfconsole → search → use → set RHOSTS) or run code manually. As soon as you catch the first shell, move straight into the privilege-escalation enumeration of Steps 125–126.

Screen example (the moment of completion):

$ whoami
www-data
$ sudo -l
User www-data may run the following commands on this host:
    (ALL) NOPASSWD: ALL
$ sudo su
# whoami
root
# cat /root/root.txt
flag{c0ngrats_y0u_d1d_1t_y0urs3lf}

How to read it: a typical escalation path — enter as www-data (web server privileges) and climb to root. Flag files live in different places on each machine — find them with something like find / -name "*.txt" 2>/dev/null, or check home directories and /root first.

3-6. Documentation — Today’s Real Artifact

The moment you get a shell feels like the climax, but today’s artifact is the record. In a scaled-down form of Step 128’s report, fill it in as you attack.

# Attack Record: [machine name]
- Date / time spent / final reach: (user? root?)
- How I found the target IP:
- Recon summary (table of open ports):
- Intrusion path: root cause → attack method (commands) → privileges gained
- Privilege escalation: what the weakness was
- Where I got stuck and how I broke through:
- What I'll do differently next time:

Why: the last two items of this template ("where I got stuck," "what I’ll do differently") are what separate a record from a mere log. Skill grows not when you break in, but when you review.

4. Missions & Exercises

Mission — Root One New VM With No Guide

Add one beginner VulnHub VM to the lab you built in Step 112 (Kali + Host-only network). It must be a different machine from MS2.
Find the target IP yourself with a ping scan.
Apply the routine from start to finish — full scan, service/version enumeration, searchsploit, intrusion, privilege escalation.
Obtain the user flag and the root flag (both, if they exist), and save the evidence output (including whoami).
Complete vm-attack-notes.md using the 3-6 template — in particular, do not leave "where I got stuck and how I broke through" empty.
If you consulted any resources during the attack, note the sources at the end of the record — knowing the limits of your own strength is also a skill.

Exercises

Exercise 1. In nmap -sn 192.168.56.0/24, what does -sn omit, and why is it a good first command of an intrusion?

Exercise 2. The scan result shows "Apache httpd 2.2.8." What is the most important information an attacker gains from this line, and what is the next command to type?

Exercise 3. "A service I don’t know, or one I know but a different version?" — explain why this question is effective when you’re stuck, together with the breakthrough direction for each case.

Exercise 4. Explain the difference between attacking MS2 and attacking a VulnHub machine not with the "workbook vs. mock exam" analogy, but from the perspective of the presence or absence of prior information.

5. Model Answers & Completion Criteria

Mission Model Answer

This mission has no single correct answer — the intrusion path differs per machine. So instead of an answer, here are verification criteria. Your attack succeeds if it satisfies all of the following.

Self-guided discovery: does the record contain the nmap -sn output along with "the basis for confirming this IP as the target" (such as excluding Kali’s own IP)?
Routine completion: are the artifacts of each phase — recon (-p- -sV) → enumeration (searchsploit, etc.) → intrusion → privilege escalation — saved in time order?
Evidence: is the final whoami output root, with the flag contents preserved in the output?
Review: is the "where I got stuck" item concrete — not "it didn’t work," but at the level of "I spent 40 minutes on the Samba path, then switched to a web vulnerability on the Apache side"?

If you’re stuck and make no progress — that’s a result too. Leave a record of how far you got and an analysis of the sticking point (applying the 2-3 framework). Even an unfinished record becomes the starting line of your next attempt once the 2-3 classification is attached.

Exercise Answers

Answer 1. -sn is a scan that skips the port scan and only checks whether hosts are alive (the old -sP). When you don’t even know the target’s IP, you need to narrow down "which addresses are alive" before knocking on 65,535 ports, so a fast, quiet ping scan is the right first command.

Answer 2. The most important information is the exact version string (2.2.8) — vulnerabilities exist per version, not per service. The next command is a search like searchsploit apache 2.2, digging through the dictionary for known exploit code against this version.

Answer 3. Because it splits the cause of the blockage in two and prescribes a different remedy for each. If it’s an unknown service, filling in knowledge (researching docs and hints) is the answer; if it’s a known service at a different version, digging deeper into information (re-searching with the exact version, re-checking the banner) is the answer. Lump it together as "it doesn’t work" and there’s no prescription; classify it and the next action is decided.

Answer 4. MS2 is a target you approach already knowing "which vulnerabilities are planted" — recon was confirmation work. A VulnHub machine comes with no prior information, so recon and enumeration are everything — only the output I receive tells me where it breaks. Even when you type the same commands, the weight of reading the output differs.

Completion Criteria Checklist

[ ] I can add a beginner VulnHub VM to the Host-only lab
[ ] I can find an unfamiliar VM’s IP with a ping scan (-sn)
[ ] I can save and read the results of a -p- -sV full scan to a file
[ ] I can run searchsploit searches per service and version
[ ] When stuck, I can classify the cause as "unknown service / different version"
[ ] I obtained the user/root flags along with evidence output
[ ] I completed vm-attack-notes.md, filling in even "where I got stuck"

6. Common Pitfalls & Fixes

Wall 1. The VM boots but the screen stays black

Symptom: the power is on, but it hangs on a black screen.

Cause: the machine is often distributed for a different virtualization format (VMware-only, etc.), not VirtualBox. A kernel panic message alongside makes it more certain.

Fix: re-read the description on the VulnHub page — the target hypervisor is written there. Picking a VirtualBox repack or a different machine is fastest.

Wall 2. The ping scan doesn’t show the target

Symptom (screen example): Nmap done: 256 IP addresses (2 hosts up) — the machine you expected is missing.

Cause: suspect three things in order — ① the VM’s network adapter isn’t Host-only (NAT, etc.), ② Kali and the target are on different Host-only adapters (vboxnet0 vs vboxnet1), ③ the scanned subnet differs from the actual subnet.

Fix: from Kali, check your own subnet first with ip addr (e.g., 192.168.56.x), align the adapters to the same one in each VM’s VirtualBox settings, then scan again.

Wall 3. It’s supposed to be vulnerable, but the exploit won’t work

Symptom: an attack that exists in a walkthrough fails in my environment.

Cause: mostly a slight version difference or a typo in options. Confusing RHOSTS (the target) and LHOST (your Kali) is especially common.

Fix: re-check the banner/version, and re-read the exploit’s requirements (target architecture, required options) from the beginning. If it still fails, apply the 2-3 framework — look at the scan results again for another service path.

Wall 4. searchsploit returns nothing at all

Symptom (screen example): Exploits: No Results.

Cause: the search term is too long (the entire version) or too short (service name only). Something in between like samba 3.0.20 tends to hit well.

Fix: re-search with just the leading digits of the version (apache 2.2). If there’s still nothing, "no public exploit" is the result for that service — moving on to another port is the correct answer.

Wall 5. I caught a shell but can’t find the flag

Symptom: I have a shell, but root.txt is nowhere to be seen.

Cause: flag locations and filenames differ per machine. Some machines have no flag at all — "reaching root itself is the goal."

Fix: check /root and each user’s home directory first; if nothing turns up, search with something like find / -iname "*flag*" -o -iname "root.txt" 2>/dev/null. Also check whether the machine’s description states the goal.

7. Summary

Today’s Concepts

Concept	One-line explanation
VulnHub	A public repository of deliberately vulnerable VMs — a mock exam with no answers
Generalizing techniques	The state where the same routine works on a target you’ve never seen
Flag	The machine’s goal token — usually user.txt and root.txt
Classifying roadblocks	"Unknown service" vs. "known but different version" — the prescriptions differ
Ping scan	Recon that finds only live hosts, without a port scan

Today’s Commands

Command	What it does
`sudo nmap -sn 192.168.56.0/24`	Find live hosts in a subnet (target IP discovery)
`nmap -p- -sV <IP> -oN scan.txt`	All ports + version recon, saved to a file
`searchsploit <service> <version>`	Search the dictionary of known exploit code
`ip addr`	Check my machine’s IP/subnet
`find / -iname "flag" 2>/dev/null`	Find flag files
`whoami` / `id`	Check current privileges — the first line of every piece of evidence

An Instinct More Important Than Commands

What you proved today is not "I broke into a new machine" but "my routine works anywhere." The target changes; the five beats of recon → enumeration → intrusion → escalation → documentation do not, and neither does the prescription for being stuck (go back to the information).

And one more thing — looking at a walkthrough (someone else’s solution) is nothing to be ashamed of. But afterward, close the guide and break in again from the start, alone. It’s your skill only until your hands remember it.

Once every box is checked, Step 129 is complete. Click the checkbox in the sidebar to save your progress.