TryHackMe Recruit Walkthrough: SSRF, LFI, and SQL Injection
TryHackMe Recruit Walkthrough covers an end-to-end attack against a vulnerable recruitment portal where several web vulnerabilities must be chained together to gain administrative access. The room combines SSRF, local file inclusion (LFI), SQL injection, and administrative takeover into a realistic web exploitation challenge.
The primary attack path is:
Enumeration
↓
Information Disclosure
↓
SSRF
↓
Local File Access
↓
HR Credentials
↓
SQL Injection
↓
Admin Credentials
↓
Administrative Access
This is what makes the Recruit room particularly useful from an educational perspective. In a real penetration test, seemingly minor vulnerabilities are rarely evaluated completely in isolation. A vulnerability with limited immediate impact can become significantly more dangerous when it exposes information or functionality that enables another attack.
Lab Note: This walkthrough intentionally omits the room’s flags and discovered passwords. The emphasis is on understanding the methodology and vulnerabilities used to complete the challenge.
Initial Enumeration
The assessment began with an Nmap scan of the target.
nmap -sC -sV TARGET-IP
What the Command Does
The -sC option executes Nmap’s default collection of NSE scripts against discovered services, while -sV enables service and version detection.
The scan identified three accessible services:
| Port | Service | Purpose |
|---|---|---|
| 22 | SSH | Remote administration |
| 53 | DNS | Domain name resolution |
| 80 | HTTP | Web application |
Because this challenge focuses on a recruitment portal, the HTTP service on port 80 became the primary target for further investigation.
Web Directory Enumeration
The next step was identifying content that might not be directly linked from the application’s main pages.
Gobuster was used for directory enumeration:
gobuster dir -u http://TARGET-IP -w /usr/share/wordlists/dirb/common.txt
The command uses Gobuster’s dir mode to request possible directories and files from the target. The -u option specifies the target URL, while -w supplies the wordlist used for discovery.
Several interesting locations were identified:
/mail
/api
/phpmyadmin
/assets
None of these should automatically be considered vulnerable simply because they exist. However, each provides additional attack surface and should be investigated during an authorized web application assessment.
Information Disclosure Through mail.log
Enumeration of the /mail location revealed an accessible log file:
http://TARGET-IP/mail/mail.log
The log exposed internal communication containing information about the application’s authentication and configuration.
Important discoveries included:
- An HR account used the username
hr. - HR credentials were stored inside
config.php. - Administrative credentials were stored in the application’s database.
This is an example of information disclosure. The log itself did not immediately provide administrative access, but it supplied a roadmap for the next stages of the attack.
An attacker now knows exactly what information is valuable and where that information may be located.
[Screenshot – mail.log Contents]
Discovering the SSRF Vulnerability
Investigation of the application’s API revealed a file-handling endpoint accepting a URL through the cv parameter:
/file.php?cv=<URL>
The application apparently retrieves the resource specified by the user.
Functionality like this can be legitimate. For example, a recruitment portal might allow an applicant’s CV to be retrieved from another location. The security problem occurs when the server accepts arbitrary locations without sufficiently validating what resources it is allowed to retrieve.
This creates the conditions for Server-Side Request Forgery (SSRF).
What Is SSRF?
SSRF occurs when an attacker can cause a server to make requests to attacker-controlled destinations.
Instead of the attacker’s computer directly accessing a resource, the vulnerable application performs the request on the attacker’s behalf.
Conceptually:
Attacker
|
| supplies URL
v
Vulnerable Web Application
|
| server performs request
v
Target Resource
This distinction matters because the server may have access to resources that an external user cannot normally reach.
Using SSRF to Access a Local File
The exposed mail log had already revealed that valuable credentials existed inside config.php.
The vulnerable endpoint was therefore tested using PHP’s file:// URI scheme:
http://TARGET-IP/file.php?cv=file:///var/www/html/config.php
Instead of requesting an external website, this instructed the application to retrieve a file from its own filesystem.
The request successfully returned the contents of:
/var/www/html/config.php
This demonstrates why SSRF can become much more serious than simply forcing a server to request another website.
In this challenge, the SSRF primitive effectively provided local file access, exposing a sensitive application configuration file.
Credential Exposure
The retrieved configuration contained the HR password:
$HR_PASSWORD = "(password found in config.php)";
Hardcoding credentials inside application files creates significant risk. Configuration files are commonly targeted because they may contain database passwords, API keys, application secrets, authentication credentials, or other sensitive values.
With the password recovered, the previously discovered username could now be used to authenticate.
Username: hr
Password: [REDACTED]
Authentication succeeded and provided access to the HR portion of the application.
At this point, the first portion of the challenge was complete, but the HR account did not represent the highest privilege available within the application.
Further testing was required.
Discovering SQL Injection
The authenticated application contained a candidate search feature using a parameter similar to:
?search=<input>
A basic single-quote test was submitted:
'
The application returned a database syntax error containing text similar to:
You have an error in your SQL syntax near '%''
Database errors following unexpected characters are a strong indication that user-controlled input may be reaching a SQL query without proper parameterization.
Understanding the Vulnerable Query
Based on the observed behavior, the underlying query was likely structured similarly to:
SELECT * FROM candidates WHERE name LIKE '%input%'
This is an inferred representation based on the error and injection behavior; the exact backend query was not provided directly.
If user input is concatenated directly into this statement, an attacker can potentially modify the structure of the SQL query itself.
That is the fundamental problem behind SQL injection.
Confirming SQL Injection
The following payload was used to determine whether the search parameter could manipulate query logic:
%' OR 1=1-- -
The condition:
1=1
is always true.
The remaining characters terminate or comment out the intended portion of the original SQL statement.
Successful manipulation confirmed that the parameter was vulnerable to SQL injection.
Determining the Number of Columns
Before using a UNION SELECT attack, the number of columns returned by the original query needed to be determined.
The following payload was tested:
%' UNION SELECT 1,2,3,4-- -
The query succeeded with four supplied values, confirming that the original query returned four compatible columns.
This information was necessary because both sides of a SQL UNION operation must return a compatible number of columns.
Enumerating Database Tables
With the column count established, MySQL’s information_schema metadata could be queried.
%' UNION SELECT 1,table_name,3,4
FROM information_schema.tables
WHERE table_schema=database()-- -
The important component is:
information_schema.tables
MySQL’s information_schema database contains metadata describing databases, tables, columns, and other database objects.
The function:
database()
returns the currently selected database.
Together, these allowed the application to reveal table names belonging to its own database.
Extracting Administrative Credentials
Enumeration eventually identified a users table containing authentication information.
The following injection retrieved its username and password fields:
%' UNION SELECT 1,username,password,4 FROM users-- -
Administrative credentials were subsequently exposed through the vulnerable search results.
Username: admin
Password: [REDACTED]
In this challenge, the recovered password appeared within the application’s Position field because of how the injected UNION SELECT columns were rendered by the existing page.
Administrative Access
The recovered credentials were then used to authenticate as the administrative user.
Successful authentication provided access to the administrative dashboard and the final flag required by the room.
The flag itself is intentionally omitted from this walkthrough.
Understanding the Complete Attack Chain
The most important lesson from TryHackMe Recruit is not any individual payload. It is how information obtained during one phase guided the next.
| Stage | Discovery | Why It Mattered |
|---|---|---|
| Enumeration | /mail and /api | Expanded the application’s known attack surface |
| Information Disclosure | mail.log | Revealed the HR username and location of credentials |
| SSRF | file.php?cv= | Allowed the server to retrieve attacker-selected resources |
| Local File Access | file:///var/www/html/config.php | Exposed sensitive configuration data |
| Credential Exposure | HR password | Enabled authenticated application access |
| SQL Injection | Vulnerable search parameter | Allowed manipulation of database queries |
| Database Enumeration | information_schema | Revealed application database structure |
| Credential Extraction | users table | Exposed administrative credentials |
| Admin Authentication | Recovered account | Resulted in administrative application access |
The attack can therefore be summarized as:
mail.log
↓
config.php location discovered
↓
SSRF / local file retrieval
↓
HR credentials
↓
HR dashboard
↓
SQL injection
↓
Database enumeration
↓
Admin credentials
↓
Admin dashboard
No single step tells the entire story. Each vulnerability provides information or access necessary to exploit the next weakness.
Security Issues Identified
Information Disclosure
Internal logs should not be publicly accessible through the web server. Log files can reveal usernames, internal paths, application architecture, errors, credentials, and other operational information.
Sensitive logs should be stored outside the public web root and protected using appropriate filesystem permissions.
Server-Side Request Forgery
Applications that retrieve user-supplied URLs should strictly control what destinations and protocols can be accessed.
Defensive controls can include:
- Allowlisting permitted protocols and destinations.
- Rejecting
file://and other unnecessary URI schemes. - Blocking access to localhost, private address ranges, and sensitive internal services where appropriate.
- Resolving and validating destinations carefully to prevent hostname-based bypasses.
- Applying network-level egress restrictions to application servers.
Sensitive Configuration Files
Secrets should not be exposed through web-accessible functionality.
Where practical, applications should use secure secret-management mechanisms or appropriately protected environment/configuration systems rather than embedding reusable credentials directly into application code.
Filesystem permissions should also follow least-privilege principles.
SQL Injection
The SQL injection vulnerability represents one of the most severe weaknesses in the application because it allows attacker-controlled input to alter database queries.
The primary defense is parameterized queries/prepared statements.
Instead of constructing SQL statements by concatenating user input, applications should separate the SQL structure from supplied values.
Additional protections include:
- Input validation.
- Least-privileged database accounts.
- Generic user-facing error messages.
- Secure application logging.
- Web application firewall rules as an additional layer, not as a replacement for secure code.
Broken Access Control
Once administrative credentials were exposed, the application accepted them without any additional protection.
Sensitive administrative interfaces can benefit from controls such as multi-factor authentication, stronger credential management, monitoring, rate limiting, and appropriate separation of privileges.
Why Vulnerability Chaining Matters
TryHackMe Recruit demonstrates an important principle in penetration testing: the severity of a vulnerability can change dramatically when it is combined with another weakness.
An exposed log file might initially appear to be a relatively minor information leak. However, that log identifies a sensitive configuration file. SSRF then provides a method for retrieving that configuration file. The configuration exposes authentication credentials, which provide access to additional application functionality. That functionality contains SQL injection, which ultimately exposes an administrative account.
The security impact therefore cannot always be determined by evaluating each issue independently.
A penetration tester should continually ask:
What does this vulnerability allow me to access that I couldn’t access before?
That question often identifies the next link in an attack chain.
Tools Used
| Tool | Purpose |
|---|---|
| Nmap | Port and service enumeration |
| Gobuster | Web directory discovery |
| Web Browser | Application testing and authentication |
| SQL Injection | Database enumeration through the vulnerable search parameter |
information_schema | MySQL metadata enumeration |
Lessons Learned
The Recruit room provides a strong demonstration of how web application testing progresses from broad enumeration into increasingly targeted exploitation.
The first important lesson is to investigate information disclosure carefully. A log file might not provide immediate access, but internal filenames, usernames, paths, and architectural details can drastically reduce the amount of guessing required during later stages.
The second lesson is that SSRF should be treated as a potential pivot. Whenever an application retrieves attacker-controlled URLs, the important question is not simply whether it can retrieve an external website. The tester should determine what resources the server itself can reach.
Finally, SQL injection demonstrates why database queries must never be constructed by directly concatenating untrusted user input. Once arbitrary SQL manipulation became possible, application-level authorization provided little protection for information stored inside the database.
Key Takeaways
Main lesson: Vulnerabilities become significantly more dangerous when they can be chained together.
Important commands and payloads:
nmap -sC -sV TARGET-IP
gobuster dir -u http://TARGET-IP -w /usr/share/wordlists/dirb/common.txt
%' OR 1=1-- -
%' UNION SELECT 1,2,3,4-- -
%' UNION SELECT 1,table_name,3,4
FROM information_schema.tables
WHERE table_schema=database()-- -
Skills practiced:
- Network enumeration
- Web content discovery
- Information disclosure analysis
- SSRF testing
- Local file retrieval
- Credential discovery
- SQL injection identification
- UNION-based SQL injection
- Database enumeration
- Vulnerability chaining
Defensive considerations: Protect logs and configuration files, restrict server-side URL retrieval, use prepared SQL statements, implement least privilege, securely manage credentials, and evaluate vulnerabilities in the context of the entire application rather than treating each finding independently.