October 1, 2026

Gaara — From SSH Credential Brute Force to Root

My Walkthrough of an OffSec Proving Grounds Linux Machine

By Anju

7 min read

My Walkthrough of an OffSec Proving Grounds Linux Machine

Today I practiced Gaara on OffSec Proving Grounds.

I finished the machine successfully, but there was one problem: I was focused on solving it and forgot to document my steps and take screenshots along the way.

So instead of leaving the lab undocumented, I reconstructed the attack path from my notes and then cross-checked the important technical details against other publicly available Gaara writeups.

The machine turned out to have a relatively simple attack chain:

Network Enumeration → SSH Credential Brute Force → SSH Access → Local Flag → SUID Enumeration → GDB → GTFOBins → Root

The interesting part for me was the privilege-escalation stage. The machine reinforced something I have been practicing recently:

Privilege escalation is often about finding what a low-privileged user is allowed to execute with higher privileges.

1. Lab Overview

Machine: Gaara Platform: OffSec Proving Grounds Category: Linux / CTF Difficulty: Easy

The objective was to obtain the two flags from the machine:

  • local.txt
  • root.txt

The final attack path was:

Nmap
                  │
          ┌───────┴───────┐
          ▼               ▼
        HTTP             SSH
          │               │
          │          Credential Attack
          │               │
          │               ▼
          │          SSH as gaara
          │               │
          │               ▼
          │           local.txt
          │               │
          │               ▼
          │       Privilege Enumeration
          │               │
          │               ▼
          │        SUID Enumeration
          │               │
          │               ▼
          │           /usr/bin/gdb
          │               │
          │               ▼
          │          GTFOBins Abuse
          │               │
          │               ▼
          └────────────► ROOT
                          │
                          ▼
                       root.txt

2. Initial Enumeration

As always, I started with Nmap.

The goal at this stage was simply to understand the exposed attack surface.

nmap -sC -sV -p- <TARGET-IP>

The scan revealed two open ports:

PortServicePurpose22SSHRemote access80HTTPWeb server

So the initial attack surface looked like:

22/tcp → SSH
80/tcp → HTTP

At this point, I had two possible directions.

I started with the web service.

3. HTTP Enumeration

I opened the website in the browser and started enumerating it.

The web application itself did not immediately reveal anything useful.

I checked the page and performed further enumeration, but I didn't find anything that directly gave me access.

This was one of those situations where it is easy to spend too much time attacking the same service simply because it is open.

Instead, I decided to move to the other exposed service:

SSH.

4. Investigating SSH

SSH was running on port 22.

Normally, SSH requires valid credentials, so the next question was:

Do I have a username that I can test?

The machine itself was named Gaara, so gaara was a reasonable username candidate to investigate.

I tested the SSH credentials using Hydra in the authorized lab environment.

hydra -l gaara -P /usr/share/wordlists/rockyou.txt ssh://<TARGET-IP>

The password was successfully discovered.

This gave me a valid credential pair for the gaara account.

The attack path had now changed:

Open SSH
    ↓
Potential username
    ↓
Password brute force
    ↓
Valid credentials

This was enough to attempt initial access.

5. Initial Access Through SSH

I connected to the target using SSH:

ssh gaara@<TARGET-IP>

The credentials worked and I obtained a shell as the gaara user.

I had successfully achieved initial access.

The first thing I wanted to do was check what was available in the user's home directory.

ls

I found the local flag:

local.txt

I read it with:

cat local.txt

This confirmed the first stage of the machine.

But getting the local flag was only half of the objective.

I was still a low-privileged user.

The next question was:

How can I escalate from gaara to root?

6. Beginning Privilege Escalation

Now the focus changed from gaining access to post-exploitation enumeration.

I first wanted to understand my current privileges.

Useful checks at this stage include:

whoami
id
sudo -l

The important thing is to establish:

  • Which user am I?
  • Which groups am I a member of?
  • Can I execute anything with sudo?
  • What special privileges or permissions are available?

The machine did not provide an obvious sudo-based route, so I moved toward another important Linux privilege-escalation technique:

SUID enumeration.

7. Searching for SUID Binaries

SUID binaries are particularly interesting during Linux privilege escalation because a program with the SUID permission can execute with the privileges of its file owner.

If a binary is owned by root and has the SUID bit enabled, a vulnerable or abuseable binary may allow a low-privileged user to execute actions with root privileges.

I searched the filesystem for SUID binaries:

find / -perm -u=s -type f 2>/dev/null

While reviewing the output, one binary immediately stood out:

/usr/bin/gdb

This was interesting because GDB — the GNU Debugger — can be abused for privilege escalation when it is incorrectly configured with SUID permissions.

At this point, I had a very specific lead.

8. Understanding Why GDB Was Interesting

Instead of immediately running a random command, I searched for the binary on GTFOBins.

GTFOBins is a curated resource documenting legitimate Unix binaries that can be abused in security contexts when they are improperly configured or granted excessive privileges.

Searching for:

gdb

showed a privilege-escalation technique.

The key issue was the combination:

Low-privileged user
        +
SUID gdb
        +
gdb executing with elevated privileges
        =
Potential root shell

This is exactly the type of relationship I want to become faster at recognizing during privilege-escalation enumeration.

9. Exploiting SUID GDB

The GTFOBins technique uses GDB's ability to execute Python code.

The command I used was:

/usr/bin/gdb -nx -ex 'python import os; os.execl("/bin/sh", "sh", "-p")' -ex quit

The important part of the command is the Python expression:

os.execl("/bin/sh", "sh", "-p")

This starts a shell while preserving the elevated privileges available to the SUID process.

After executing the command, I received a shell with elevated privileges.

I verified the result rather than assuming the exploit worked:

whoami
id

The result confirmed that I had obtained root access.

10. Obtaining the Root Flag

Once root access was obtained, I moved to the root user's directory.

cd /root

I listed the directory:

ls

The root flag was present.

I read it with:

cat root.txt

At this point, both flags had been obtained and the machine was successfully completed.

11. Complete Attack Chain

Looking back, the entire attack was surprisingly short:

Nmap
                      │
                      ▼
             22/tcp + 80/tcp
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
        HTTP                     SSH
          │                       │
     No useful path        Username: gaara
                                  │
                                  ▼
                              Hydra
                                  │
                                  ▼
                         Valid SSH password
                                  │
                                  ▼
                           SSH as gaara
                                  │
                                  ▼
                             local.txt
                                  │
                                  ▼
                         Privilege Enumeration
                                  │
                                  ▼
                           SUID Enumeration
                                  │
                                  ▼
                         /usr/bin/gdb
                                  │
                                  ▼
                             GTFOBins
                                  │
                                  ▼
                          SUID GDB abuse
                                  │
                                  ▼
                                ROOT
                                  │
                                  ▼
                              root.txt

12. What Made the Machine Interesting?

At first glance, Gaara looks like a simple machine.

There are only two exposed services:

SSH
HTTP

The web server did not provide an obvious path during my enumeration.

The breakthrough came from changing direction and testing SSH credentials.

Then, after obtaining a shell, the machine shifted into a privilege-escalation exercise.

This made the machine useful for practicing two different parts of a penetration test:

Initial Access

Enumeration
     ↓
Credential Attack
     ↓
SSH

Privilege Escalation

Post-Exploitation Enumeration
     ↓
SUID Search
     ↓
Interesting Binary
     ↓
GTFOBins
     ↓
Root

13. Lessons I Took From Gaara

1. Don't get stuck on one service

HTTP was open, but I didn't find a useful path there.

Instead of continuously attacking the same service, I moved to SSH.

Enumeration is about understanding the whole attack surface, not forcing one particular service to work.

2. Credentials are an attack surface

Once I had a possible username, testing for weak credentials became a valid path in the controlled lab.

The important part was connecting:

Username
   +
SSH
   +
Password Wordlist

to obtain initial access.

3. Post-exploitation enumeration is critical

Getting a shell does not mean the machine is compromised.

After obtaining access as gaara, I had to start the enumeration process again.

This time, I was no longer looking for exposed network services.

I was looking for:

  • Sudo permissions
  • SUID binaries
  • Writable files
  • Capabilities
  • Scheduled tasks
  • Credentials
  • Interesting processes
  • Misconfigured services

The attack surface changes after initial access.

4. Learn to recognize interesting SUID binaries

The discovery of:

/usr/bin/gdb

was the turning point.

I didn't need to memorize every possible SUID exploit.

What I needed was the ability to recognize:

This binary is unusual and has elevated execution privileges. I should investigate it.

Then I could use resources such as GTFOBins to understand whether it could be abused.

5. Enumeration → Research → Validation

The privilege-escalation process was essentially:

Find SUID binary
       ↓
Identify GDB
       ↓
Research GDB
       ↓
Find GTFOBins technique
       ↓
Execute in authorized lab
       ↓
Verify root

This is a much better workflow than blindly copying privilege-escalation commands.

14. What I Would Do Differently Next Time

One thing I learned from this machine wasn't actually a technical vulnerability.

It was documentation discipline.

I solved the machine first and only afterward realized:

"I didn't take the screenshots."

For a cybersecurity portfolio, this matters.

A successful lab is useful for learning, but a well-documented lab is useful for demonstrating that learning to someone else.

So going forward, I want to capture evidence at each major decision point:

Nmap
  ↓
Web Enumeration
  ↓
Credential Discovery
  ↓
SSH Access
  ↓
local.txt
  ↓
SUID Enumeration
  ↓
GDB Discovery
  ↓
GTFOBins
  ↓
Root
  ↓
root.txt

I don't need ten screenshots for every command.

I need screenshots that prove the important transitions.

15. Screenshots I Would Add If I Recreated the Lab

Since I did not capture screenshots during the original attempt, I would rerun the important steps and capture these:

1. Nmap

Show the two open ports:

22/tcp
80/tcp

2. HTTP Enumeration

Show the website and, if applicable, the enumeration result demonstrating that no useful web path was found.

3. Hydra

Show the successful SSH credential discovery.

Important: If publishing publicly, consider hiding the recovered password.

4. SSH Access

Show:

ssh gaara@<TARGET-IP>

and the resulting shell.

5. Local Flag

Show the presence of:

local.txt

You can redact the actual flag value if you don't want to publish it.

6. SUID Enumeration

Show:

find / -perm -u=s -type f 2>/dev/null

with:

/usr/bin/gdb

highlighted.

7. GTFOBins

Show the relevant GDB technique.

8. Root Verification

Show:

whoami
id

demonstrating root access.

9. Root Flag

Show:

cat /root/root.txt

with the flag value redacted if desired.

16. Final Takeaway

Gaara was a relatively straightforward machine, but it reinforced an important penetration-testing workflow for me.

The machine can be summarized in one sentence:

Find the exposed services, identify a valid credential path, obtain an initial shell, enumerate the new environment, identify a privileged SUID binary, research how it can be abused, and verify the privilege escalation.

The complete path was:

Nmap → HTTP Enumeration → SSH Credential Brute Force → SSH → local.txt → SUID Enumeration → GDB → GTFOBins → Root → root.txt

The most important lesson for me was not the GDB command itself.

It was the reasoning behind it:

What do I have?
      ↓
Who am I?
      ↓
What privileges do I have?
      ↓
What can I execute?
      ↓
Which files/binaries have elevated privileges?
      ↓
Is any of them exploitable?
      ↓
Research
      ↓
Test
      ↓
Verify

That is the mindset I am trying to build while practicing OffSec machines.

Don't just memorize the exploit. Learn how you discovered the condition that made the exploit possible.

Conclusion

Gaara gave me practice with a complete Linux penetration-testing chain:

Reconnaissance → Enumeration → Credential Attack → Initial Access → Post-Exploitation Enumeration → SUID Privilege Escalation → Root

It also reminded me of something important about documenting cybersecurity work:

Solving the machine is only half the job when you're building a portfolio.

The other half is being able to clearly explain:

  • What I found
  • Why it mattered
  • What I tested
  • What worked
  • Why it worked
  • How the vulnerabilities connected
  • What I learned

That is the type of documentation I want to continue building throughout my penetration-testing journey.