Step 1: Verifying Connectivity

On the Kioptrix box, I pinged Google’s DNS (8.8.8.8) to confirm internet reachability.

Then, on my Kali machine, I ran:

arp-scan -l

This listed all live devices in my local subnet. I identified Kioptrix’s IP as 10.0.2.4.

Step 2: Full Nmap Scan

To discover open ports and services running on the target, I launched a full TCP scan with the following command:

nmap -T4 -p- -A 10.0.2.4

Command Breakdown:

• nmap: The network scanner tool.
• -T4: Sets the timing template to 4 (Aggressive), which speeds up the scan without overwhelming the network.
• -p-: Tells Nmap to scan all 65,535 TCP ports instead of just the default top 1000.
• -A: Enables aggressive detection, which includes:
• OS detection
• Version detection
• Script scanning
• Traceroute

Results:

Step 3: Service Enumeration

Now that I knew what was running, I began manual service enumeration.

Web Enumeration (HTTP/HTTPS — Ports 80 & 443)

I browsed to http://10.0.2.4 and saw the classic Apache Test Page — a sign that the default Apache web server was up but not customized.

Then, I used DirBuster to find hidden files/directories:

• Target URL: http://10.0.2.4
• Extensions: .php, .csv, .docx
• Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt

SMB Enumeration (Port 139)

From the Nmap scan, I saw the server was running Samba (SMB). I fired up Metasploit for further fingerprinting:

msfconsole then

use auxiliary/scanner/smb/smb_version
set RHOSTS 10.0.2.4
run

Result: Samba version 2.2.1a

SSH Enumeration (Port 22)

Attempted to connect to the SSH service using:

ssh 10.0.2.4

The banner didn’t reveal much — no additional info beyond what Nmap already told me: OpenSSH 2.9p2 (protocol 1.99)

Nikto Web Vulnerability Scan

To round off web enum, I ran:

nikto -h http://10.0.2.4

Key Findings:

• Apache/1.3.20 is vulnerable to:
• Remote DoS and code execution OpenLuck exploit
• Buffer overflow issues in versions below 1.3.27

At this stage, I’ve successfully:

• Identified the target’s IP
• Scanned for open ports and services
• Enumerated Apache, Samba, and SSH services
• Collected known version-specific vulnerabilities (for mapping later)

This project helped me practicalize my scanning and enumeration skills using real-world tools like Nmap, DirBuster, Nikto, and Metasploit’s SMB scanner. It reinforced the importance of thorough recon before any exploitation phase.

I’ll continue with this lab series and dive deeper into vulnerabilities and privilege escalation techniques in the next blog.

Time-based SQL injection is a technique used when the web app doesn’t return visible output or error messages. Instead of looking for data in the response, the attacker injects a SQL payload that deliberately delays the web app’s response. If the delay occurs, it confirms that the payload was executed. This method is useful for extracting data one character at a time by observing the web app’s response time.

In this lab, I was tasked with exploiting a SQL injection vulnerability to cause a 10-second delay on the web app. I referred to a cheatsheet and tried different payloads for various database types — the one for PostgreSQL worked successfully.

The PostgresqlSQL payload i used is: ’ || pg_sleep(10)--

Blind SQLi with Time Delay and Information Retrieval

Moving on, I was tasked with exploiting a blind SQL injection vulnerability that involved both triggering time delays and retrieving information. This technique is useful when a web application doesn’t show visible errors or output changes. Instead, it relies on forcing the server to delay its response using SQL functions like pg_sleep() or SLEEP(). By combining this with conditions, it's possible to confirm whether specific queries are true — for example, if a certain character in a password matches. If the condition is true, the server delays the response, allowing me to extract data like passwords or usernames based on response timing alone.

In this lab, I had to exploit a time delay SQL injection vulnerability to find out the password of the administrator user

1. I first verified that the SQL injection for time delay was working by using the payload ’ || pg_sleep(10)-- and it successfully caused a delay. But since retrieving information through time-based SQLi requires a conditional check to determine true or false responses, I moved on to a new payload:

’%3BSELECT+CASE+WHEN(1=1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--

This allowed me to confirm logical conditions by observing the server's response time.

2.To verify if the administrator user exists, I used the following payload:
'%3BSELECT+CASE+WHEN(username='administrator')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--

3. I determined how many characters are in the administrator’s password using this payload:
'%3BSELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--

I kept increasing the number after > until the server no longer delayed, which helped me conclude that the password is 20 characters long.

4. Testing the Position of the Characters

• First, I forwarded the request to Intruder.
  Then, I injected the payload:
  '%3BSELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,1,1)='a')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
  into the request, placed the payload position marker on ‘a’.
• set up my payload configuration (simple list, a-z and 0–9 wordlist)
• I set up my payload configuration using a Simple List with a custom wordlist containing a–z and 0–9
• In order to validate the position of each character, I needed to monitor the delay time. To make this process easier and more efficient, I used the resource pool to track the delay times for each request. By observing the response time for each injected payload, I could determine whether the condition for a specific character position was met (i.e., if the character was correct).

• After configuring the Intruder tool, I launched the attack while constantly increasing the value of the substring (e.g., from 1,1 to 20,1) to test each position of the administrator's password. This allowed me to systematically test each character in the password, using the delay times to confirm which character was correct at each position. Once I reached 20,1, I had successfully mapped out all 20 characters of the administrator's password.

The above image shows the results of testing the password characters using the Intruder tool. You should notice the “Response Received” column, which is a result of the resource pool setup. The highest number in this column typically indicates the correct character for that position in the password. In most cases, the number will be over 1000, which reflects the time delay and confirms the correct character at that specific position.

After identifying the entire password by testing each character position, I then used the extracted password to log into the administrator account successfully.

What I Learned

• How to trigger a time delay to confirm if a web app is susceptible to blind SQL Injection.
• How to use the time delay to retrieve sensitive information from the web app.
• How to utilize the resource pool in Burp Suite’s Intruder tool for efficient attack management.

Error-Based SQL Injection

Misconfiguration of a database can sometimes lead to verbose error messages being exposed to users. While these errors might seem harmless or just technical details, they can actually leak critical information such as database structure, table names, and even user data especially when SQL injection vulnerabilities are present.

Extracting Sensitive Data Via Verbose SQL Error Messages

In this part, I learned how to trigger errors from a misconfigured web application’s database. If the app returns an error, I can then use those error messages as a medium to extract sensitive data.

My Approach to Solving the Lab

1. I started by testing if the application would respond to malformed SQL input in the cookie header. I injected a single quote (’) into the cookie header and sent the request. The application responded with an error message, which confirmed the app’s vulnerability to error-based SQL injection.
2. Retrieving the Administrator Username:

Next, I attempted to retrieve the administrator username from the database using the following query:

‘ AND 1=CAST((SELECT username FROM users) AS int)--

TrackingId=’ AND 1=CAST((SELECT username FROM users) AS int) —

This also triggered an error, specifically indicating that more than one row was returned. To fix this, I modified my query to ensure it only returned one row by adding LIMIT:

TrackingId=’ AND 1=CAST((SELECT username FROM users LIMIT 1) AS int)--

The image above shows me inputting my query with the LIMIT clause, which restricts the results to just one row. The response from the web app contains an error message confirming that the administrator user exists in the database.

3. Modifying the Query to Leak the Password

By modifying my previous query to:

TrackingId=’ AND 1=CAST((SELECT password FROM users LIMIT 1) AS int) --

I was able to make the web app leak the administrator password in the error message. The error message confirmed that the administrator’s password was exposed through the SQL injection.

Note: The administrator user is the first entry in the users and password table, which is why using LIMIT 1 effectively targets the administrator's data for extraction.

What I Learned

• Trigger error messages by injecting malformed SQL queries into the cookie header.
• Use the information from error messages to infer the existence of database tables, such as the users table.
• Retrieve sensitive data like usernames and passwords by modifying my SQL queries and using techniques such as LIMIT to control query output and avoid errors caused by multiple rows being returned.

Error-Based SQL Injection: In some cases, the web application doesn’t return any useful response that confirms a successful query, but it does leak database error messages when a query fails. These errors can be used to gain information about the database structure or even extract data directly, just by triggering and reading the error output.

In this lab, I was tasked with exploiting the web application using a type of Blind SQL Injection that triggers conditional errors to infer information from the database. My goal was to retrieve the administrator user’s password and log in to the account.

MY APPROACH TO SOLVING THIS LAB

This technique relies on triggering deliberate errors in the web app to confirm SQL injection. So, the first thing I tried was adding a single ’ into the TrackingId cookie value to see if it would cause a visible database error in the response. As expected, it returned an error because the ’ broke the SQL syntax being processed by the backend. That error confirmed the input was being passed directly into a SQL query, meaning the application was indeed vulnerable.

1. Verify if users table exists

From the hint given in the lab, I learned that the web app uses an Oracle database. So, to verify if the users table exists, I used the following SQL payload in the TrackingId cookie: ’ ||(SELECT ‘’ FROM users WHERE ROWNUM = 1)||’

Since the table exists, the query runs without throwing an error. Also ROWNUM=1 is used to prevent the query from returning more than one row.

2. Verify if administrator user exists

’||(SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE ‘’ END FROM users WHERE username=’administrator’)||’

This Payload would help verify if there is a user named administrator and the web app would throw an error which helps infer the user exists.

3. Determine Length of Password using:

’||(SELECT CASE WHEN LENGTH(password)>1 THEN to_char(1/0) ELSE ‘’ END FROM users WHERE username=’administrator’)||’

As shown in the above image, I incremented the value of >1 step-by-step until the web app stopped showing an error response. This helped me determine that the length of the password is 20 characters.

4. Test Password Characters Position using Burp Suite Intruder Tool

If you recall from the last part of this series, I used Burp Suite’s Intruder tool to automate the process of testing password characters. In this lab, my payload for this would be different since I’m working with an Oracle database type.

The payload:

’||(SELECT CASE WHEN SUBSTR(password,1,1)=’a’ THEN TO_CHAR(1/0) ELSE ‘’ END FROM users WHERE username=’administrator’)||’

By setting the payload marker on the ‘a’ character and uploading my wordlist (a–z and 0–9) in the payload configuration, I was able to use Intruder to automate the task of testing character positions.

I then went ahead to login to the administrator account.

What I Learned

Through this lab, I gained a deeper understanding of Blind SQL Injection and how to leverage it for exploiting web application vulnerabilities, even in the absence of direct error messages or query results.

That’s where Blind SQL Injection comes in.

BLIND SQL INJECTION

Blind SQL Injection is a method used when an application is vulnerable to SQL injection, but it doesn’t show the results of the query in the web page. Instead of visible errors or data, the attacker must rely on observing subtle behavioral differences such as changes in the page’s content, redirects, or even how long the server takes to respond to be sure whether the injected query returned true or false.

In this blog, I’ll be sharing what I learned about Blind SQL Injection, starting with how to exploit it by triggering conditional responses a method that helps uncover vulnerabilities even when the application doesn’t visibly display query results.

Blind SQL Injection With Conditional Responses

Unlike other labs I’ve worked on, this lab, as shown in the image above, doesn’t return query results or display error messages. Instead, a simple “welcome back” message is shown to confirm if the query worked. In this lab, my task was to use Blind SQL Injection to retrieve the administrator’s account password.

My Approach to Solving This Lab

1. Since the web app in the lab uses a tracking cookie for analytics and performs an SQL query on the value of the submitted cookie, I modified the tracking cookie ID by adding AND ‘1’=’1 to check if the “welcome back” message was triggered, confirming that the response was working.

One of the first issues I encountered was not getting the “welcome back” message, meaning my query wasn’t working. After researching the issue, I discovered that I didn’t need to URL-encode the AND ‘1’=’1 since I was injecting it directly into the cookie header, which doesn’t require encoding like query parameters do.

After getting a “welcome back” message on the web app navigation bar i then went on to;

2. Verify if the users table exists by injecting AND (SELECT ‘a’ FROM users LIMIT 1)=’a into the cookie header and I confirmed the success by seeing the welcome back message on the web app

NOTE:In this lab, the “Welcome back!” message is the application’s only behavioral cue confirming successful SQL queries because this is a Blind SQL Injection.

3. I verified if the user “administrator” exists by injecting AND (SELECT ‘a’ FROM users WHERE username=‘administrator’)=’a

4. Determine how many characters make up the password of the Administrator user. this was done by injecting AND LENGTH (password)>1)= a

I continually repeated this and increasing the value of >1 till I don't get a “welcome back” message anymore.

How it works: If the condition is true (i.e., the password length is indeed greater than the number I injected), the “Welcome back!” message appears. Once the “Welcome back!” message no longer appears, I know the actual password length is equal to the last number that still triggered the message.

Now I know that the password character is 20 and with the hint given i know that they are lowercase, alphanumeric characters meaning they contain values within a-z and 0–9

5. Test for the Position of Each Password Character

Instead of testing each character manually, I learned about the Intruder tool in Burp Suite and used it to automate this process. I injected the payload:

• AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username=‘administrator’)=’a in the cookie header and placed the payload marker § on the ‘a
• In Burp Suite’s Intruder configuration, I set the payload type to Simple list. Then, I created two custom wordlists:
• One containing lowercase letters (a-z)
• Another containing numbers (0–9)

To detect when the correct character was guessed, I used the Grep Match feature in Burp Suite. I added “Welcome back” as the string to match in the server’s response. This way, Burp would highlight any response that contained that message meaning the injected condition was true.

This helped me quickly spot which payload (character) returned a successful match, making it easier to build the password one character at a time.

After setting up the Grep Match, I launched the attack. Once I successfully identified the first character of the password, I updated the payload in the cookie header to test the next character:

AND (SELECT SUBSTRING(password,2,1) FROM users WHERE username=’administrator’)=’a

I continued modifying the number in the SUBSTRING function by changing it to 3, 4, 5, and so on until I reached 20,1, since I had earlier confirmed that the administrator's password is 20 characters long.

The image above shows the response for my 6th attack, where the payload in the cookie header was set to: AND (SELECT SUBSTRING(password,6,1) FROM users WHERE username=’administrator’)=’a

You’ll notice a 1 under the Grep Match column, which confirms that the 6th character of the administrator's password is t.

After running the attack until I successfully identified all 20 characters of the administrator’s password, I used the password to attempt a login.

With the password I had uncovered, including each character’s position, I logged into the administrator account successfully, confirming the effectiveness of the blind SQL injection method.

What I Learned

From this lab, I gained a deeper understanding of Blind SQL Injection, particularly how to exploit it by triggering conditional responses. Here are the key takeaways:

1. Blind SQL Injection Mechanics: I learned that even when an application doesn’t show direct results or error messages, I can still extract sensitive data like passwords by carefully analyzing subtle behavior changes, such as changes in the page content.
2. Using Conditional Responses: By injecting conditional SQL queries, I was able to infer true or false responses based on the “welcome back” message displayed on the web app, allowing me to deduce information step-by-step without direct feedback.
3. Using Burp Suite’s Intruder Tool: I discovered how to leverage Burp Suite’s Intruder tool to automate payload insertion and quickly test multiple values for each character of the password. This significantly streamlined the process of finding the correct password characters.
4. Grep Match for Response Confirmation: The use of Grep Match in Burp Suite helped me easily identify when the correct password characters were returned, saving time by pinpointing successful attempts.
5. Efficiency in Testing Password Length and Characters: I learned how to test the length of the password and systematically extract each character’s position using SQL queries and Burp Suite’s configuration. This approach turned what could have been a long, manual process into a more efficient and methodical attack.

1. How To Find a Column With a Useful Data Type: After determining the number of columns (as done in Part 1 of this series), it’s important to find a column that accepts a useful data type because only columns with the correct data type (like text or strings) will display information when injected. This allows attackers to extract valuable data.

To do this you’ll need to query the application with

‘ UNION SELECT ‘a’, NULL, NULL--

Note:

• The ‘a’ can be any random string or text.
• The number of NULL values must match the number of columns you found earlier.
• You then move the ‘a’ across different column positions in the query until you get a valid response.

The image above shows the lab where I found a column that contains text.

The lab provided a hint with a specific text string, ‘oXsaSw’, which I used to replace ‘a’ in the query.

By adjusting the query to:

‘ UNION SELECT NULL, ’oXsaSw’ , NULL--

I was able to locate the column containing the useful text.

If you check the image above, you’ll notice the query I inputted into Burp Suite was URL-encoded as: ‘+UNION+SELECT+NULL,‘oXsaSw’,NULL--+ (as explained in Part 1).

The application responded, showing that my query was correctly structured and confirming the useful data column.

2. Using SQL Injection UNION Attack to Retrieve Interesting Data

After determining the number of columns and identifying the column with data, the next step is to retrieve interesting or sensitive information that can be exploited.

In this lab, I was tasked with retrieving data from another table and using it to log into the administrator account.

As shown in the image above I have been provided hint that the database contains table called users, with columns named username and password

Note:
To retrieve data from other tables, you either need to know or guess the table name. In this case, the hint made it easy.

Using Burp Suite to intercept the application traffic, I clicked on the “Gifts” category and modified the request by injecting a SQL query to retrieve username and password from the “users” table.

The query is ‘ UNION SELECT username, password FROM users-- (remember to URL-encode properly when sending through Burp Suite)

The image above shows the application’s response to my SQL injection, where I successfully retrieved credentials.
I then used the administrator’s login details to access the account. Just as an attacker in likely to do in a real-world scenario.

3. Retrieving Multiple values Within a Single Column:

This is similar to retrieving interesting data, but the key difference is: Instead of displaying each value in separate columns, I have to combine multiple values into a single column using functions like CONCAT() and often include a separator (~ or : ) to distinguish the combined values.

This technique is useful when an application only displays data from one column in the response.

Note:

• Syntax for combining values varies depending on the database.
• For example,CONCAT() is common in MySQL, while Oracle databases use | | for string concatenation.
• PortSwigger provides a helpful SQL injection cheat-sheet to guide syntax across different databases.

In this lab, I was tasked with retrieving data from the Users table again. However, this time, I needed to combine the username and password into a single column and then use the retrieved password to log into the administrator account.

Using the PortSwigger SQL injection cheat-sheet, I found the appropriate syntax for the database type and crafted the following query:

‘ UNION SELECT NULL,username || ‘~’ || password FROM users--

I entered this query into Burp Suite, forwarded the modified traffic.

The application responded by displaying the combined data. You’ll notice the separator “~” from my query which helped separate the username and password in the application’s response.

After retrieving the data, I successfully logged into the administrator’s account.

What I Learned:

• I now understand how to find the number of valid columns containing data.
• I learned how to use SQL injection UNION attacks to retrieve sensitive information.
• I practiced retrieving multiple values within a single column, which shows how attackers can improvise when applications restrict data responses.
• I also now have access to the PortSwigger SQL injection cheat-sheet, a valuable tool for executing SQL injection attacks across different database types.

Remediation Recommendations:

• Use Prepared Statements:
  Always use prepared statements to prevent SQL injection. They ensure user inputs are treated as data and not executable code.
• Input Validation and Sanitization:
  Validate and sanitize all user inputs. Whitelist allowed input formats and use parameterized queries to avoid SQL injection risks.
• Apply the Principle of Least Privilege:
  Database accounts used by web applications should have the minimum necessary permissions to limit potential damage if compromised.
• Proper Error Handling:
  Do not expose detailed error messages to users. Show generic error messages instead, to prevent attackers from gaining insights into the database structure.
• Conduct Regular Security Testing:
  Regular penetration testing, especially for injection vulnerabilities, is critical to identify and patch vulnerabilities early.

For Non-Technical Readers

In this phase of my learning, I explored how attackers find and steal sensitive information from websites by exploiting a weakness called SQL Injection.

Normally, when you click around on a website (like searching for products or logging into your account), the website talks to a database behind the scenes to fetch the right information.
If the website is not properly protected, an attacker can insert special tricks (called SQL queries) into the website’s input fields to make the database reveal secrets — like usernames, passwords, and other private data.

In these labs:

• I learned how attackers first figure out how many pieces of information (columns) the database is sending back.
• Then, they find which column actually shows useful or sensitive data.
• After that, they retrieve hidden data like usernames and passwords, even when the website tries to limit what is displayed.
• I also learned that attackers can combine multiple pieces of stolen information into one single response if the website restricts what they can see.

Impact on Daily Life:

• If a website is vulnerable to SQL Injection, your personal accounts (email, banking, shopping, etc.) could be stolen without you realizing.
• This is why it’s important for companies to properly secure their websites and for users to enable extra security measures like two-factor authentication (2FA), so that even if your account credentials are exposed, an attacker would still need a second form of verification to access your account.
• It’s also a reminder to stay cautious about where you enter your personal data and to watch for unusual activities on your accounts.

In the first lab I learnt about Retrieving Hidden Data, this works by by manipulating the SQL query to return more results than the application originally intended.

in the above image I used Burp Suite to intercept the traffic and modified the request by injecting +OR+1=1-- I used +OR+1=1 — because the + signs represent spaces in URL encoding. So instead of typing OR 1=1, which might break the request format.

By modifying the request I was able to view hidden products that weren't meant to be displayed and got the congratulations message shown in the image.

In the next lab, I explored how to Subvert Application Logic using SQL injection.

The goal was to bypass login restrictions by injecting malicious SQL into the login form

In the above image I inputted a random username and password into the respective fields

Then, using Burp Suite, I intercepted the request and modified the username parameter by injecting a malicious SQL query:

administrator’-- this effectively invalidated the password parameter and turned it into a comment, allowing me to bypass the authentication check and log in.

In the next lab I explored how to Retrieve Data From Other Database Table.

My goal was to find and determine the number of column in the database to help me with further exploitation.

I had to first click on a category “gifts” (other categories would work too) and then modified the request on Burpsuite

Then, I intercepted the request in Burp Suite and modified it by injecting the following SQL query into the parameter: ‘+UNION+SELECT+NULL,NULLNULL--+

Through this, I was able to determine that the database had 3 columns by testing different numbers of NULL values to match the database table’s structure.

The page returned with a different structure, indicating that the query successfully executed

Also i used the ‘+ORDER+BY+3--+ to also test

From these labs I got to understand how attackers can easily manipulate SQL queries if user input isn’t properly handled by the application.

Developers should use prepared statements instead of building raw SQL queries with user input.

Also, Input Validation and proper error handling should be enforced.

Now, I’m turning my focus to something deeper.

Web Application Security, there’s something fascinating about how a single line of code, a misplaced trust, or an overlooked logic flaw can open the doors to an entire system.

To explore that, I’ll be learning through PortSwigger Web Security Academy diving into the mechanics behind vulnerabilities like XSS, SQLi, SSRF, and more. Not just to pass labs, but to understand why things break, and how to defend against them.

This blog is where I’ll document that process, the lessons, the roadblocks, the breakthroughs. I’ll share what I learn in simple language, hoping it helps someone else who’s walking this path too.

It’s not just about hacking. It’s about growth, curiosity, and building something meaningful along the way.

Let’s see where this takes us.