Post cover image

August 27, 2026

From SQL Injection to PCAP Analysis: My Hands-On Penetration Testing Capstone

A Hands-On Journey Through SQL Injection, Web Enumeration, SMB Shares, and Wireshark Analysis

By Cybersage

10 min read

A Hands-On Journey Through SQL Injection, Web Enumeration, SMB Shares, and Wireshark Analysis

Cybersecurity is much easier to understand when concepts are practiced in a realistic environment.

Reading about SQL injection, directory listing, SMB enumeration, and packet analysis is useful, but performing the complete process from reconnaissance to exploitation and remediation provides a much deeper understanding.

For my Final Capstone Activity, I completed a simulated penetration testing engagement involving multiple vulnerable systems across the following networks:

10.6.6.0/24
172.17.0.0/24

The objective was to identify vulnerabilities, exploit them in an authorized lab environment, locate hidden flag files, and finally recommend remediation methods.

The capstone was divided into four challenges:

  1. SQL Injection
  2. Web Server Directory Listing
  3. Open SMB Shares
  4. Wireshark PCAP Analysis

This article documents my complete hands-on process, including reconnaissance, enumeration, exploitation, results, and defensive recommendations.

Important:_ All activities described in this article were performed in an authorized cybersecurity training environment._

Overview of the Assessment

The exercise simulated a real penetration testing workflow.

Instead of being given the exact vulnerability locations, I had to perform reconnaissance and investigate the available services.

The general workflow looked like this:

Reconnaissance
      ↓
Port and Service Discovery
      ↓
Enumeration
      ↓
Vulnerability Identification
      ↓
Controlled Exploitation
      ↓
Flag/File Discovery
      ↓
Analysis of Findings
      ↓
Remediation Recommendations

One of the biggest lessons from this activity was that penetration testing is not just about running tools.

The tools provide information, but the tester must understand:

  • What the results mean
  • Which service should be investigated next
  • Which vulnerability may exist
  • How different systems are connected
  • How to validate findings
  • How to recommend remediation

Challenge 1: SQL Injection

Objective

The first challenge required me to:

  • Identify a vulnerable SQL input
  • Retrieve user account information
  • Find Gordon Brown's password hash
  • Crack the password
  • Log in to another system as Gordon Brown
  • Locate a flag file

The vulnerable web application was hosted at:

10.6.6.100

Step 1: Accessing the Vulnerable Application

I opened the target in a browser and logged into the DVWA application using:

Username: admin
Password: password

I then changed the DVWA security level to:

Low

This was important because the challenge was designed to demonstrate SQL injection in a deliberately vulnerable configuration.

Step 2: Identifying the SQL Injection Vulnerability

The SQL Injection page contained an input field for a User ID.

By testing SQL syntax in the input field, I was able to manipulate the backend query.

A UNION-based SQL injection payload allowed me to retrieve usernames and password hashes from the users table.

The result included information for multiple users, including Gordon Brown.

The application revealed data such as:

ID: 5
First name: Gordon
Surname: Brown

along with the corresponding password hash.

This demonstrated an important security issue:

None

The application was directly incorporating user-controlled input into an SQL query without properly protecting the query.

Step 3: Cracking Gordon Brown's Password

After obtaining the password hash, I saved it to a file and used John the Ripper with the rockyou.txt wordlist.

Example command:

john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
None

John successfully cracked the password.

Result

Gordon Brown's password: abc123

This also demonstrated why weak passwords remain dangerous.

Even when a password is stored as a hash, a weak and commonly used password may be quickly recovered through dictionary attacks.

Step 4: Accessing the Remote System

Using the recovered credentials, I connected to the target system:

None 
ssh gordonb@172.17.0.2

After logging in, I listed the files in Gordon Brown's home directory.

ls

I found the following file:

hkxisx.txt

I opened it using:

cat hkxisx.txt

Challenge 1 Result

The file displayed:

Congratulations!
You found the flag for Challenge 1!
The code for this challenge is 4E9f12.
None

Challenge 1 Flag

4E9f12

What I Learned From SQL Injection

SQL injection can occur when an application:

  • Trusts user input
  • Directly concatenates input into SQL queries
  • Does not validate input
  • Does not use prepared statements

A successful SQL injection can potentially allow an attacker to:

  • Read sensitive database records
  • Bypass authentication
  • Extract usernames and password hashes
  • Modify or delete data
  • Gain access to additional systems

SQL Injection Remediation

Five important methods for preventing SQL injection are:

1. Use Parameterized Queries

Prepared statements separate SQL code from user input.

Instead of dynamically building a query like:

SELECT * FROM users WHERE id = 'user_input'

The application should use parameterized queries.

This is one of the most effective defenses against SQL injection.

2. Validate Input

Applications should verify that input matches the expected format.

For example, if a field expects a numeric user ID, it should reject letters and SQL syntax.

3. Use Allow-List Validation

Only expected values should be accepted.

This is generally safer than attempting to block every possible malicious character or keyword.

4. Filter Unnecessary User Input

Applications should only accept the data required for the requested operation. Unexpected input should be rejected.

5. Escape Input Where Appropriate

Escaping can provide an additional layer of protection, although it should not replace parameterized queries.

Challenge 2: Web Server Vulnerabilities and Directory Listing

Objective

The second challenge involved discovering directories on a web server that allowed directory listing.

Directory listing occurs when a web server displays the contents of a directory instead of returning a normal web page.

The target was:

http://10.6.6.100

Step 1: Directory Enumeration

I used DIRB to perform directory enumeration.

Command:

dirb http://10.6.6.100 -w /usr/share/wordlists/dirb/common.txt
None

The scan revealed several interesting locations.

The most important findings were:

/config/
/docs/

Both locations were accessible through a browser.

Step 2: Investigating Directory Listings

I manually navigated to the discovered directories using URL manipulation.

For example:

http://10.6.6.100/docs/

The server returned a directory listing instead of blocking access.

Inside the /docs/ directory, I found several files, including:

None 
DVWA_v1.3.pdf
help.html
user_form.html

The interesting file was:

user_form.html

Step 3: Opening the Flag File

I accessed:

http://10.6.6.100/docs/user_form.html

The page displayed:

None 
Great work!
You found the flag file for Challenge 2!
The code for this flag is 18xf9-4z

Challenge 2 Results

Accessible directories:

/config/
/docs/

Flag file:

/docs/user_form.html

Challenge 2 Flag:

18xf9-4z

What I Learned From Directory Listing

Directory listing may appear harmless, but it can expose useful information to an attacker.

For example, an attacker may discover:

  • Backup files
  • Configuration files
  • Documentation
  • Source code
  • User information
  • Old application files
  • Sensitive filenames

Even when a file is not directly linked from a website, a directory listing can reveal its existence.

Directory Listing Remediation

Two important remediation methods are:

1. Disable Directory Listing

Configure the web server so that directory contents cannot be automatically displayed.

For example, the server should return an error page instead of:

Index of /directory

2. Use Default Index Files

Place an appropriate default file, such as:

index.html
index.php

Inside directories where appropriate.

However, sensitive files should not rely solely on an index file for protection. Proper access controls are also required.

Challenge 3: Exploiting Open SMB Shares

Objective

The third challenge focused on identifying an SMB server with anonymously accessible shares.

The process involved:

  • Scanning the network
  • Identifying SMB ports
  • Enumerating available shares
  • Testing anonymous access
  • Downloading a flag file

Step 1: Identifying the SMB Server

I scanned the 10.6.6.0/24 Network to identify hosts running potentially vulnerable services.

One interesting host was:

10.6.6.23

The scan showed that ports associated with SMB were open:

None 
139/tcp
445/tcp

This strongly indicated that the system was running SMB services.

Result

Target: 10.6.6.23

Step 2: SMB Enumeration

I used SMB enumeration techniques to investigate the server and identify available shares.

The shares included:

None None 
homes
workfiles
print$

The enumeration showed that some resources could be accessed without valid user credentials.

The anonymously accessible shares were:

workfiles
print$

This is a serious misconfiguration because anonymous users should not have unnecessary access to shared resources.

Step 3: Accessing the SMB Share

I connected using the SMB client:

None 
smbclient //10.6.6.23/print$

The server allowed anonymous access.

After connecting, I used SMB commands such as:

ls
cd
get

I navigated through the available directories.

None

The relevant path was:

OTHER/taxes.txt

I changed into the directory:

OTHER

Then listed its contents:

ls

I found:

taxes.txt

I downloaded the file:

get taxes.txt

After exiting SMB, I opened the file locally:

cat taxes.txt

The file displayed:

Congratulations!
You found the flag for Challenge 3!
The code for this challenge is A9!15wa2.

Challenge 3 Results

SMB Target:

10.6.6.23

Accessible share containing the flag:

print$

File path:

OTHER/taxes.txt

Challenge 3 Flag:

A9!15wa2

What I Learned From SMB Enumeration

SMB enumeration can reveal:

  • Available shares
  • Anonymous access
  • Usernames
  • Shared directories
  • Files
  • System information

Misconfigured SMB services can expose sensitive information without requiring a sophisticated exploit.

Sometimes, simply checking access permissions is enough to discover a significant security issue.

SMB Remediation

Two or more important remediation methods include:

1. Disable Anonymous Access

Anonymous users should not be able to access sensitive SMB shares.

Authentication should be required.

2. Restrict SMB Access

Use firewalls and network segmentation to limit access to SMB services.

Ports such as:

139
445

It should generally only be accessible from trusted internal systems.

Additional recommendations include:

  • Keep operating systems patched
  • Use strong authentication
  • Apply least privilege
  • Enable SMB signing where appropriate
  • Remove unused shares
  • Monitor SMB access

Challenge 4: Analyzing a Wireshark Capture File

Objective

The final challenge involved analyzing a packet capture file.

The PCAP file was located in the Kali system under the "OTHER" directory.

The goal was to identify:

  • The target IP address
  • Directories accessed on the target
  • The location of a flag file
  • The flag contained within that file

Step 1: Opening the PCAP File

I opened the capture file in Wireshark.

Since I was interested in web traffic, I applied the following display filter:

http

This allowed me to focus on HTTP requests and responses.

The capture revealed communication involving the target:

None 
10.6.6.14

Step 2: Analyzing HTTP Requests

The HTTP traffic revealed several interesting paths.

Examples included:

None 
/data
/styles
/passwords
/icons.txt

The most important directory was:

/data

I used the browser to investigate the discovered path.

Step 3: Finding the XML File

Navigating to the /data/ directory revealed:

None 
accounts.xml

The full URL was:

http://10.6.6.14/data/accounts.xml

Opening the file displayed XML content containing employee information.

None

The file contained:

  • Usernames
  • Accounts
  • Password information
  • Signatures

The Challenge 4 entry revealed the flag.

Challenge 4 Results

Target IP:

10.6.6.14

Flag file URL:

http://10.6.6.14/data/accounts.xml

File content:

Usernames, accounts and passwords

Challenge 4 Flag:

zz90014x

What I Learned From PCAP Analysis

This challenge demonstrated the danger of transmitting sensitive information over unencrypted HTTP.

The packet capture showed that information could be inspected because the traffic was transmitted in clear text.

An attacker with the ability to capture network traffic could potentially view:

  • HTTP requests
  • URLs
  • Usernames
  • Passwords
  • File contents
  • Cookies
  • Other sensitive data

This is why encryption is essential.

Remediation for Clear-Text File Transmission

Two important solutions are:

1. Use HTTPS

HTTPS encrypts communication between the client and server using TLS.

Instead of:

HTTP

Applications should use:

HTTPS

This prevents network observers from simply reading the contents of transmitted traffic.

2. Use a VPN or Other Secure Encryption

A VPN can provide encrypted communication over an untrusted network.

Additional recommendations include:

  • Encrypt sensitive data
  • Avoid transmitting credentials in clear text
  • Do not store sensitive files in publicly accessible directories
  • Use authentication and authorization controls
  • Protect sensitive data at rest and in transit

Final Results Summary

Challenge Vulnerability

Target Flag File Flag

Challenge 1 SQL Injection 10.6.6.100 / 172.17.0.2 hkxisx.txt 4E9f12

Challenge 2 Directory Listing10.6.6.100/docs/user_form.html18xf9-4z

Challenge 3Anonymous SMB Access10.6.6.23OTHER/taxes.txtA9!15wa2

Challenge 4Clear-Text HTTP Traffic10.6.6.14/data/accounts.xmlzz90014x

Key Takeaways

This capstone connected several cybersecurity concepts into one complete workflow.

The most important lessons I learned were:

Reconnaissance matters

A simple port scan can reveal the next direction of an investigation.

Open ports such as:

80  → HTTP
139 → NetBIOS
445 → SMB

Can immediately help prioritize testing.

Enumeration often reveals vulnerabilities

Not every security issue requires a complex exploit.

Examples from this lab included:

  • A directory listing exposing files
  • An SMB share allowing anonymous access
  • HTTP traffic exposing file contents

Weak passwords remain a serious problem

Even when passwords are stored as hashes, weak passwords may be vulnerable to dictionary attacks.

Encryption is essential

Sensitive information transmitted over HTTP can potentially be captured and read.

HTTPS and TLS are essential for protecting data in transit.

Security requires defense in depth

No single security control is enough.

A strong environment should combine:

  • Secure coding
  • Input validation
  • Authentication
  • Authorization
  • Encryption
  • Patch management
  • Network segmentation
  • Firewall rules
  • Monitoring

Skills Practiced

During this capstone, I practiced:

  • Network reconnaissance
  • Nmap scanning
  • SQL injection testing
  • Database enumeration
  • Password hash cracking
  • John the Ripper
  • SSH access
  • Web directory enumeration
  • DIRB
  • URL manipulation
  • SMB enumeration
  • SMBClient
  • Anonymous share testing
  • File extraction
  • Wireshark analysis
  • HTTP traffic analysis
  • Vulnerability assessment
  • Exploitation validation
  • Security remediation

Conclusion

This Final Capstone Activity was a valuable experience because it combined multiple cybersecurity skills into a single penetration testing workflow.

Each challenge demonstrated a different type of security weakness:

  • Improper database input handling led to SQL injection.
  • Web server misconfiguration exposed directory contents.
  • Anonymous SMB access exposed shared files.
  • Unencrypted HTTP traffic exposed sensitive information.

The exercise reinforced an important lesson:

Cybersecurity is not only about finding vulnerabilities. A complete security assessment also requires understanding the impact of those vulnerabilities and recommending practical ways to fix them.

Hands-on labs like this are helping me better understand how different tools, services, vulnerabilities, and defensive controls connect in a real-world security assessment.

Disclaimer

This project was completed in an authorized educational lab environment created for cybersecurity training.

The techniques demonstrated in this article should only be used on systems and networks where you have explicit permission to perform security testing.

Unauthorized access to systems is illegal and unethical.