---

Write-up :

• Platform: Hackthebox

• Challenge Gategory: Forensics

• Challenge Level: Beginner

• Challenge Name: Suspicious Threat

• Challenge Link: [challenge link]

• Challenge Subject:

  Our SSH server is showing strange library linking errors, and critical folders seem to be missing despite their confirmed existence. Investigate the anomalies in the library loading process and filesystem. Look for hidden manipulations that could indicate a userland rootkit. Creds:root:hackthebox

Before start :

scroll down at [Read more] part

At description of challenge : "Look for hidden manipulations that could indicate a userland rootkit".
That means my objective is to investigate a userland rootkit, identify the suspicious library file, and obtain the flag

Let's do a Userland Rootkit Investigation

- Access to machine

• start the machine, upload ovpn file and connect with it && check connection if established then connect via ssh :

    sudo openvpn lab_achnr.ovpn

    ip addr

    ping -c 4 94.237.57.211

    ssh root@94.237.57.211 (password : hackthebox)

- Investigation :

1 - Check for hidden processes

ps aux

ls -l /proc/*/exe | head -n 20

why checking for hidden proccess ?
> some rootkits hide proccesses from ps
> comparing /proc entries with ps can reveal hidden processes
Look for libraries that don’t match normal system ones and pay attention to recently modified or unusual filenames

---

2 - Search for hidden or suspicious libraries

List the system library directory to look for unexpected files :

find /lib /usr/lib /etc -type f -name '*.so*' -ls 2>/dev/null

ldd /bin/ls 

ls -la /usr/lib/x86_64-linux-gnu

scans multiple directories where rootkits might hide (/lib, /usr/lib, /etc)

It is important commands : because a userland rootkit usually hides inside a shared library (.so file)
+ scrolll down at [read more] part to read more about rootkit

How to recognize suspicious files ?

        - Weird names : for example "libc.hook.so.6" instead of the expected "libc.so.6"

        - Recent modification times : that means all libraries are usually installed at the same time

        - Wrong owner or permissions : libraries should be owned by root:root not a user

        - Strange symlinks → check with ls -l; if libc.so.6 points somewhere unusual, that’s suspicious

I found libc.hook.so.6 in "/usr/lib/x86_64-linux-gnu/libc.hook.so.6"
And this rootkit uses ld.so.preload to hide a pr3104d folder

---

3- Collect evidences

mkdir -p /tmp/evidence_rootkit

sudo cp -a /usr/lib/x86_64-linux-gnu/libc.hook.so.6 /tmp/evidence_rootkit/

copy the malicious library

sudo cp -a /etc/ld.so.preload /tmp/evidence_rootkit/ 2>/dev/null || echo "/etc/ld.so.preload not present"

copy the dynamic loader preloader

sudo cp -a /etc/ld.so.preload /tmp/evidence_rootkit/

copy the malicious library

tar -czf /tmp/evidence.tgz /tmp/evidence_rootkit

create compressed archive of this evidence

---

4 -Disable the rootkit library

mv /usr/lib/x86_64-linux-gnu/libc.hook.so.6 /tmp/

Prevents the dynamic loader from preloading the malicious .so on future executions

---

5- Get FLAG

sudo find / -type f -name '*.so*' -exec sh -c 'strings {} | egrep -i "flag|FLAG|HTB|CTF" && echo "== {}"' \; 2>/dev/null

sudo find / -type -f -name "flag.txt"

I found the flag in --------------------------- /var/pr3104d/flag.txt ------------------

---

----- THE CHALLEGNE IS PWNED NOW -----

[+] Read more :

Rootkit

A rootkit is malicious software that hides its presence and gives attackers hidden control of a system

- Goal: stay invisible while keeping access

- Types:

    - Userland rootkit : hooks normal programs/libraries

    - Kernel rootkit   : hides inside the OS kernel

- Tricks: hides processes, files, network ports, logs

- Danger: attacker can steal data, install backdoors, or fully control the machine without detection

    - Rootkits hook system calls by injecting their own .so library

    - They often place this library in unusual locations (/etc, /tmp, /usr/local/lib, etc.)

    - The malicious .so is usually loaded via /etc/ld.so.preload or environment variables

    - This library can:

        - Hide files, processes, or network ports

        - Replace normal functions (open, readdir, stat) with malicious versions

- By searching system folders for strange .so files,you can detect the injected rootkit

How to recognize suspicious files :

- Weird names : fro examle "libc.hook.so.6" instead of the expected "libc.so.6"

- Recent modification times : that means all libraries are usually installed at the same time

- Wrong owner or permissions : libraries should be owned by root:root not a user

- Strange symlinks → check with ls -l; if libc.so.6 points somewhere unusual, that’s suspicious

About dynamic the loader :

- The dynamic loader :
    - is the program that runs when you start a dynamically linked ELF executable

- Its job:
    - locate and load shared libraries (.so files), resolve symbols, and transfer control to the program

- Common loader filenames & locations :

    - ld.so / ld-linux.so.* / ld-<version>.so — the loader binary. Typical locations:

    - /lib/ld-linux.so.2 (32-bit)

    - /lib64/ld-linux-x86-64.so.2 or /lib/x86_64-linux-gnu/ld-<ver>.so

    - symlinks like /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 → use readlink -f to see target

    - Shared object (.so) files

- Extension: .so
- often versioned: libc.so.6, libm.so.6, libcustom.so.1.2.3

- Locations: /lib, /lib64, /usr/lib, /usr/lib/x86_64-linux-gnu, /usr/local/lib, sometimes /etc or /tmp (suspicious)

ldd command

The ldd command in Linux shows the shared library dependencies of an executable
ldd /path/to/executable

```
linux-vdso.so.1 (0x00007ffd5d9fe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7a4d2e7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7a4d4f1000)

```

It shows:

    Each shared library the program needs

    Path where it will be loaded from

    Missing libraries appear as “not found”, which can break the program

It used in forensics:

    Detect tampered or missing libraries caused by rootkits or malware

---

This write-up is written by @achnouri