Introduction

This post covers Part 1 of my first penetration testing lecture at university.
We’ll walk through how to set up your own isolated pentesting lab using Kali Linux, Metasploitable 2, and DVWA (Damn Vulnerable Web App), all safely contained within a virtual environment.

This isn’t just a technical write-up; it’s the actual process I went through, including what worked, what didn't, and what to double-check before you start poking around with exploits.

Lab Setup

To build our lab environment, we used:

• Kali Linux – for scanning, scripting, and exploitation
• Metasploitable 2 – intentionally vulnerable target machine
• VMware Workstation Player or VirtualBox – for virtualization

I already had Kali set up as a VM, and downloaded Metasploitable from VulnHub.

The .vmdk file (virtual disk) isn’t directly bootable, you’ll need to create or import a VM that uses it via a .vmx file.

Network Configuration - What you MUST get right for every VM ever

Rule 1: Don't expose ANYTHING to the Internet light-heartedly

Especially not Metasploitable!

Metasploitable is intentionally riddled with vulnerabilities. If it's visible to your home network or the open internet, it's an active security risk. There are even automated tools scanning for it online.

Instead, isolate it inside a host-only or private NAT network.

VMware Networking Modes Explained:

1. Host-only: The Isolated Lab

This is the safest mode as it completely isolates the VM from the outside world.

• Internet Access: No.
• Communication: VMs can communicate with the host and other VMs in the same private network (e.g., your Kali setup).
• LAN Exposure: No.
• Use Case: The best option for safe labs where you need a controlled, zero-exposure testing environment.

2. NAT: The Internet Gateway

Network Address Translation (NAT) allows the VM to share the host's IP address to access the internet.

• Internet Access: Yes.
• Communication: VMs can talk to each other if they are on the same NAT network.
• LAN Exposure: No.
• Use Case: Primarily used when Kali needs internet access (for updates or downloads) while remaining hidden from the local network.

3. Bridged: Full Network Member

The Bridged mode connects the VM directly to your physical network adapter, giving it its own unique IP address from your router.

• Internet Access: Yes.
• Communication: Full visibility and communication with all devices on your local LAN.
• LAN Exposure: Yes (Your LAN is exposed to the VM).
• Use Case: This is dangerous for testing. Avoid using it for offensive security work as any mistakes or unintended traffic can directly affect your home or corporate network.

Recommended Setup

Kali VM:

• NIC 1: Host-only (isolated lab)
• NIC 2: NAT (for internet access, updates)

Metasploitable VM:

• NIC 1: Host-only (lab only, no internet)
• NIC 2: Host-only (lab only, no internet)

(Only one NIC is really needed here, unless you're experimenting with routing later.)

But what is NIC really and why are there two to begin with?

Having two NICs (Network Interface Cards) in Kali allows it to act as a bridge between the isolated lab environment and the internet; one interface handles safe internal traffic (Host-only), while the other provides external access (NAT) for updates, tools, or exploit downloads.

This way, Kali can scan and interact with Metasploitable, but Metasploitable stays locked inside your lab, with zero exposure to the outside.

Starting Metasploitable

Once your VM is imported and your network config is correct:

1. Boot Metasploitable
2. Login with default credentials:

username: msfadmin 
password: msfadmin

3. Check it's IP with:

ifconfig
# or (on newer distros):
ip a

You should see something like 192.168.56.x (if you're using host-only).

Mini Excursus – ipconfig vs ifconfig vs ip

I confused ipconfig with ifconfig, easy beginner mistake:

ipconfig is for Windows.
ifconfig is the classic Linux command, but it's now considered outdated.

Modern Linux systems use ip, like ip a for listing interfaces. Worth remembering early.

Accessing DVWA from Kali

Now, go to your Kali browser and enter Metasploitable’s IP, like this:
http://192.168.56.101/
If everything’s working, you should land on the starting screen where you can now select DVWA.

Wait… Why Do All These Lab IPs Look Like 192.168.x.x?

If you've ever set up a local network or looked at your home router, you've probably seen IP addresses like:

192.168.0.1
192.168.56.101

These aren't random: they’re part of the private IP address ranges reserved by standards of the Internet Engineering Task Force (IETF). The three most common ones are:

192.168.0.0/16
172.16.0.0/12
10.0.0.0/8

Devices in these ranges can’t be reached directly from the internet, they’re designed for internal use only.

That’s why Kali and Metasploitable show IPs like 192.168.56.101; they live inside a virtual local network your hypervisor (VMware, VirtualBox) creates.

Bottom Line

If you see an IP starting with 192.168, you’re in your own little hacker playground.
The world can’t see in and (for now), you can’t break out. 😈

I'm going to trust you in finding out the login credentials for DVWA :D very basic combination.

Once logged in, go to the DVWA Security settings and set it to Low to begin experimenting.

What is XSS, Actually?

Cross-Site Scripting (XSS) is when untrusted user input gets “unsafely interpolated” into a web page - without proper escaping or validation - and then executed by the victim’s browser.

This allows an attacker to inject HTML, JavaScript, or other browser-parsed content.

Classic Examples in Code

<meta http-equiv="refresh" content="3; url=http://example.com">
<script>alert("XSS")</script>

Check out some more here if you're interested in the broader payload picture.

XSS Types: Where the Payload Lands

The impact of a Cross-Site Scripting (XSS) attack depends entirely on how and where the malicious payload is processed and delivered to the user.

1. Reflected XSS

This type is a one-time, per-request attack.

• How it Works: The malicious input is delivered via a single request (like a URL parameter), and the server immediately reflects the input back into the page's response.
• Impact: The exploit is transient; it only executes for the user who clicks the specially crafted link. It is not saved on the server.

2. Stored XSS (Persistent XSS)

This is the most dangerous form, as the payload achieves infinite persistence.

• How it Works: The malicious script is saved on the server (often in a database field like a comment, profile bio, or forum post).
• Impact: The exploit is executed for every single user who views the compromised page. The attack continues indefinitely until the malicious code is manually removed from the server.

Testing Reflected XSS in DVWA

We used the Damn Vulnerable Web App (DVWA) and Burp Suite to explore this vulnerability.

Start with the “Low” security level (in the site options) and try the following on the dedicated XSS site you find in the navigation:

<script>alert("hi")</script>

Success: the payload is reflected and executed instantly.

How do you know it's reflected and not stored?

If you refresh the page or make a second request and the payload is gone, it's reflected.
Stored XSS would persist across requests or reloads.

Mini Excursus: Crypto Stealers & Copy-Paste Traps

You might think XSS is mostly alert boxes and harmless popups, but it’s far from a joke in the real world.

One clever - and sadly common - use case is stealing cryptocurrency through copy-paste manipulation.

How it works

Many users copy their wallet address (from an exchange or wallet app), then paste it into a form, payment screen, or transfer box.

A malicious website or browser extension, using injected JavaScript, can detect this action and silently replace the clipboard content with the attacker’s own wallet address.

An example for this could be:

<input type="text" onpaste="setTimeout(() => this.value = 'attacker_wallet_address', 1)">

Or even more subtle:

document.addEventListener("paste", function(e) {
  e.preventDefault();
  const clipboard = e.clipboardData || window.clipboardData;
  const original = clipboard.getData('text');
  
  if (original.startsWith('bc1') || original.length > 30) {
    e.target.value = 'attacker_wallet_address';
  }
});

This replaces the address as soon as it's pasted, often without the user noticing, especially if it’s visually similar.

The JS Clipboard API

The modern Clipboard API even allows direct access to read or write clipboard content:

navigator.clipboard.readText().then(text => {
  if (text.includes("eth") || text.startsWith("1") || text.length > 25) {
    navigator.clipboard.writeText("attacker_wallet_address");
  }
});

This means malicious scripts can replace the clipboard value in the background, outside of input fields.

Why does this even matter (to me)?

This is a real-world example of client-side JavaScript being used for financial theft.

Crypto transactions are irreversible! if a wallet address is changed without detection, the funds are gone. No chargebacks, no refunds.

This kind of attack is often part of:

• XSS payloads on crypto dashboards
• Fake DApp phishing portals
• Malicious browser extensions

Takeaways

If you're testing crypto-related apps, don’t stop at just finding an XSS point, instead ask:

• Can this XSS be used to access or modify clipboard data?
• Can I inject something into input fields or manipulate auto-fill?
• Is there any user interaction (like paste, drag-drop, or type) I can hook into?

Even the smallest reflected XSS, when combined with a clipboard trap, could have consequences as severe as those of wallet hijacking.

Bonus: Try for Yourself!

Want to test clipboard behavior?

Create a basic HTML page like this:

<button onclick="navigator.clipboard.writeText('LOL_HACKED')">Click Me</button>
<input placeholder="Try pasting here">

Now copy something else, click the button, and paste.
This is how simple it can be if the API is not secured properly.

From Low to Medium: Bypassing Filters

In “Medium” security mode, DVWA introduces some basic filters, usually blocking <script> tags.. or does it?