Linux Privilege Escalation: A Red Teamer's Nightmare and Playground

Banyak orang yang masuk dunia cybersecurity bayangin red team itu cuma serbu server, hackNASA, dan langsung jadi kaya. Realita? Lebih banyak dari itu. Bukan cuma retasan glamor yang lu lihat di film, tapi proses berjam-jam nangkring di depan terminal, baca log, cari celah, dan kadang lu hampir nyerah karena seolah tidak ada jalan keluar. Hari ini gue mau cerita tentang salah satu momen paling intense di dunia red team: privilege escalation di Linux. Bukan cuma teori, tapi pengalaman beneran yang bikin gue kecewa, marah, dan akhirnya lega.

Kenapa Privilege Escalation Itu Berat

Di laboratorium atau lingkungan nyata, setelah lu berhasil dapat shell sebagai user biasa, misalnya www-data atau low, perjuangan baru mulai. Sistem operasi Linux itu dirancang untuk memisahkan hak akses. Root bukan cuma user biasa dengan kuasa super, tapi ada lapisan-lapisan keamanan yang sengaja dibuat untuk bikin lu pusing. Dari sudo policies yang ketat, kernel hardening, sampai container isolation. Bagi red teamer, ini bukan rintangan, ini puzzle yang harus diselesaikan sebelum waktu habis.

Dalam assessment nyata, klien biasanya kasih window waktu 2-4 hari. Lu masuk, dapat shell user biasa, dan harus naik ke root atau setidaknya dapat akses sensitif. Tidak ada tombol "instant root". Setiap sistem punya karakteristik berbeda. Yang penting bukan cuma tool, tapi cara berpikir.

Tahap Pertama: Enumeration yang Gak Boleh Diabaikan

Banyak pemula langsung ke tool tanpa tau apa yang ada di sistem. Gagal total. Langkah pertama harus selalu enumeration. Setiap red teamer punya checklist, tapi jadinya bukan checklist doa, tapi proses investigatif.

Pertama, cek identitas diri. Siapa user lu sekarang? Grup apa aja yang dia miliki? Apakah ada group yang bisa jadi pintu gerbang ke root? Grup seperti sudo, docker, adm, wheel, atau lxd biasanya adalah kunci. Kalau user ada di grup sudo, selamat, tinggal sudo su. Tapi kalau tidak, lanjut ke langkah berikutnya.

Kedua, lihat environment variable. Terkadang ada PATH yang bisa di-inject, atau variabel seperti LD_PRELOAD, LD_LIBRARY_PATH yang bisa dimanipulasi. Juga cek apakah ada password di environment, atau history bash yang meninggalkan jejak. File .bash_history bisa jadi peti harta karun jika admin pernah salah ketik password di command line.

Ketiga, cek proses yang berjalan. Pakai ps aux atau ps -ef. Cari proses yang berjalan sebagai root tapi bisa diakses atau dimanipulasi user biasa. Terkadang ada service yang berjalan dengan hak root tapi file konfigurasinya bisa diedit oleh user biasa, atau binary yang memiliki setuid bit tapi seharusnya tidak.

Keempat, cek cron jobs. Cron itu salah satu favorit red teamer. Kalau ada cron job yang menjalankan script sebagai root, dan script itu bisa diedit atau dipengaruhi user biasa, game over. Gue pernah dapat sistem karena cron job yang menjalankan backup script, dan script itu bisa ditambahkan symlink ke /etc/passwd. Sudah berapa kali lu ngecek cron, tapi lu lupa ngecek direktori tempat cron menaruh file sementara?

Kelima, cek file yang memiliki capability atau setuid bit. Perintah seperti find / -perm -4000 2>/dev/null bisa membuka mata lu. Binary yang memiliki setuid root bisa dieksploitasi jika ada vulnerability di binary tersebut, atau jika binary tersebut membuka file yang bisa kita kontrol.

Saat Tool Bukan Jawaban Segera

Setelah lu ngelakuin enumeration dasar, biasanya tool seperti LinPEAS atau LinEnum muncul. Tool ini bagus, tapi jangan andalkan sepenuhnya. Tool hanya otomatisasi. Kalau lu cumaCopy-paste hasil tool, lu akan ketinggalan celah yang membutuhkan intuisi.

Gue ingat sekali saat assessment di perusahaan fintech. LinPEAS menunjukkan sistem bersih. Tidak ada cron yang mencurigakan, tidak ada setuid binary yang bisa dieksploitasi, tidak ada sudo misconfiguration. Tapi gue curiga. Sistem ini adalah web server dengan aplikasi custom yang dibangun dengan framework PHP tua.

Gue mulai melihat ke arah aplikasi. Di direktori /var/www/html, ada file config.php yang berisi kredensial database. Tapi database hanya bisa diakses dari localhost. Ternyata, di direktori yang sama ada file db_backup.sh yang dijalankan setiap hari jam 2 pagi oleh cron sebagai root. File itu melakukan dump database ke direktori /tmp/backups. Di direktori /tmp/backups, permissionnya 777. Artinya, siapa saja bisa menulis. Gue buat symlink dari /tmp/backups/db.sql ke /root/.ssh/authorized_keys. Ketika cron berjalan, backup script menulis isi file backup ke lokasi yang seharusnya hanya bisa ditulis root. Tapi karena symlink, sebenarnya isinya masuk ke authorized_keys. Gue masukkan public key SSH gue, dan dalam 30 detik, gue sudah login sebagai root.

Itu bukan karena tool menemukannya. Itu karena gue membaca konteks: ada backup script, ada direktori world-writable, dan ada cron yang menjalankannya sebagai root.

Kernel Exploits: Harapan Terakhir

Kalau enumeration manual dan otomatis tidak memberikan jalan, langkah selanjutnya adalah kernel exploits. Ini biasanya teknik terakhir karena berisiko. Kernel exploit bisa membuat sistem crash, dan di lingkungan produksi, itu akan memicu alarm.

Cek versi kernel dengan uname -a. Lalu cari exploit di database seperti Exploit-DB. Tapi hati-hati: kernel exploit tidak universal. Versi kernel yang sama bisa memiliki patch yang berbeda tergantung distro. Ubuntu, Debian, CentOS — meskipun versi kernel sama, patch level bisa beda. Exploit yang bekerja di Ubuntu 20.04 mungkin tidak bekerja di versi yang seharusnya kompatibel.

Gue pernah mencoba kernel exploit di sistem yang katanya vulnerable. Setelah 20 menit, sistem malah reboot. Cron job yang seharusnya diambil alih ikut reboot dan gue kehilangan akses sementara. Untungnya gue sudah punyabackdoor lain. Tapi pengalaman itu mengajarkan: kalau pakai kernel exploit, lakukan di waktu yang tepat, dan punya rencana cadangan.

Container Escape: Jebakan yang Sering Dilupakan

Sekarang banyak sistem berjalan di dalam container. Red teamer sering dapat shell di dalam container dan menganggap itu sudah cukup. Tapi goal biasanya adalah host machine, bukan container.

Pertama, cek apakah container ini memiliki privilege yang tidak seharusnya. Cek apakah mounted volume dari host ada di dalam container. Biasanya direktori seperti /host, /mnt, atau /host-root adalah indikasi. Kalau ada, cek apakah bisa membaca /host/etc/shadow atau /host/root/.ssh/id_rsa.

Kedua, cek capability container. Container yang memiliki CAP_SYS_ADMIN bisa mounting filesystem host. Container dengan CAP_NET_ADMIN bisa memanipulasi jaringan. Kalau container memiliki SYS_ADMIN, gue biasanya mencoba mount root filesystem host ke dalam container, lalu chroot.

Ketiga, cek runtime container. Kalau docker, cek apakah docker socket ada di dalam container (/var/run/docker.sock). Kalau ada, gue bisa membuat container baru dengan mount root host, atau bahkan langsung akses docker API. Gue pernah dapat host melalui docker socket karena container memiliki socket tersebut dan docker group di dalam container tidak dihapus.

Keempat, kalau container berjalan dengan privilege --privileged, itu hampir pasti game over. Container ini bisa mengakses semua device di host, termasuk disk. Cukup mount root host dan chroot.

Sudo Misconfiguration: Jebakan yang Terlalu Sering Dilihat

Banyak admin mengira sudo itu aman. Padahal, konfigurasi sudo yang buruk adalah pintu gerbang paling cepat ke root.

Pertama, cek sudo -l. Output ini menunjukkan perintah apa yang bisa dijalankan user tanpa password. Kalau ada perintah yang bisa dijalankan tanpa password, cek apakah perintah tersebut bisa dijalankan dengan path yang bisa kita kontrol. Misal, sudo /usr/bin/vim. Kalau bisa, gue bisa spawn shell dari vim dengan :!/bin/bash.

Kedua, perhatikan sudo dengan wildcard. Kalau sudo diperbolehkan menjalankan /usr/bin/rsync *, kita bisa menyelipkan opsi seperti -e. Rsync bisa dijadikan backdoor. Atau perintah yang membaca file dari direktori yang bisa kita kontrol. Misal, sudo /usr/bin/less /var/log/*. Kalau bisa, gue bisa bikin file /var/log/test yang sebenarnya adalah symlink ke /etc/shadow, lalu sudo less /var/log/test akan menampilkan shadow file.

Ketiga, cek perintah yang memiliki shebang atau interpreter yang bisa kita override. Kalau sudo /usr/bin/python3 /opt/script.py, dan /opt/script.py bisa diedit, tinggal tambahkan import os; os.system('/bin/bash'). Tapi kalau script tidak bisa diedit, cek apakah python3 bisa dijalankan dengan file yang bisa kita kontrol.

Keempat, cek perintah yang memiliki environment variable injection. Beberapa perintah saat dijalankan via sudo membersihkan environment. Tapi tidak semuanya. Perintah seperti sudo apache2ctl kadang tetap membaca environment variable seperti LD_PRELOAD. Kalau bisa, tinggal buat shared library yang spawn shell, set LD_PRELOAD, dan jalankan perintah sudo yang mengizinkannya.

Password Hunting: Yang Terlalu Sering Dihindari

Banyak orang mengabaikan password hunting karena mengira itu tidak profesional. Padahal, di red team assessment, mencari kredensial adalah bagian dari proses. Kalau lu menemukan password, lu harus melaporkannya sebagai temuan, bukan mengharapkannya untuk login sebagai root.

Tempat-tempat mencari password:

• File konfigurasi yang memiliki password plaintext: /etc/shadow (jika bisa dibaca), wp-config.php, .env, config.php, settings.py, database.yml
• File yang diabaikan: .bash_history, .mysql_history, .viminfo, .python_history
• File backup: *.bak, *.old, *.swp
• Log file: /var/log/auth.log, /var/log/nginx/access.log
• Source code: kadang developer lupa menghapus password hardcoded

Gue pernah menemukan password root di file .bash_history karena admin pernah menjalankan sudo su - dan typo. File history mencatat perintah, dan ternyata ada password yang terlihat jelas. Tentu ini jarang terjadi, tapi ketika terjadi, lu harus sangat beruntung.

Path Hijacking: Celah Tersembunyi di Environment Variable

Path hijacking adalah teknik klasik yang masih bekerja di banyak sistem. Konsepnya sederhana: ketika admin menjalankan perintah tanpa absolute path, shell akan mencari perintah di direktori yang tercantum di PATH secara berurutan. Kalau ada direktori yang bisa ditulis user biasa di awal PATH, kita bisa meletakkan binary dengan nama yang sama di direktori tersebut.

Contoh: cek echo $PATH. Kalau outputnya seperti /home/user/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, dan /home/user/bin ada di paling awal dan bisa ditulis user biasa, tinggal buat binary dengan nama ls atau cat yang sebenarnya adalah shell. Ketika admin menjalankan ls, shell akan menjalankan binary kita terlebih dahulu.

Tapi hati-hati: tidak semua perintah menggunakan PATH. Jika admin menjalankan /bin/ls secara eksplisit, path hijacking tidak bekerja. Juga, beberapa sistem sudah membersihkan PATH sebelum menjalankan sudo.

Scheduler dan Systemd: Modern Attack Surface

Selain cron, sistem modern menggunakan systemd timers dan at jobs. Systemd timer bisa dijadwalkan untuk menjalankan service sebagai root. Cek dengan systemctl list-timers. Kalau ada timer yang menjalankan service, cek apakah unit file bisa dimanipulasi.

Di sistem yang gue temukan, ada systemd timer yang menjalankan service /usr/local/bin/cleanup.sh setiap 15 menit. Service itu dijalankan sebagai root. Tapi file service itu memiliki permission 644, artinya bisa dibaca oleh semua user. Di dalam service file, ada baris ExecStart=/usr/local/bin/cleanup.sh. Cek file tersebut, ternyata cleanup.sh melakukan rm -rf /tmp/*. Kalau bisa membuat file di /tmp dengan nama yang sama, kita bisa menggantinya. Gue buat script cleanup.sh palsu yang spawn reverse shell, taruh di /tmp, dan tunggu 15 menit. Root shell arrived.

Atau systemd service yang memiliki User=root tetapi file unitnya di direktori yang bisa diedit user biasa. Kalau bisa, ubah ExecStart untuk menjalankan shell.

SSH Keys dan Credential Reuse

Terkadang, escalation tidak perlu dari sistem itu sendiri. Cukup dari credentials yang ada di dalam sistem. Setelah dapat shell, cek direktori home semua user. Cek /home/*/.ssh/. Terkadang ada authorized_keys yang bisa dibaca, atau bahkan private key yang bisa diambil. Kalau ada private key, coba login sebagai user tersebut atau root jika key memiliki akses.

Juga cek direktori /root/. Kadang root meninggalkan file backup atau temporary file yang berisi password. Atau file .bash_history root yang mencatat perintah mysql -u root -pPasswordHere. Gue pernah dapat root karena ada file /root/.bash_history yang berisi password database, dan database tersebut memiliki file_priv yang bisa menulis file ke direktori apapun via INTO OUTFILE.

Kerangka Pikir yang Benar

Privilege escalation bukan tentang memor ratusan exploit. Bagi red teamer, ini tentang pola pikir sistematis. Mulai dari yang paling sederhana: file permission, sudo policies, cron jobs, service configuration. Kalau itu tidak ada, baru pindah ke kernel exploits atau container escapes.

Banyak pemula terburu-buru. Mereka dapat shell dan langsung mengejar root dalam 5 menit. Padahal, assessment profesional membutuhkan kesabaran. Lu harus melihat sistem sebagai puzzle. Setiap file, setiap proses, setiap konfigurasi adalah petunjuk. Gabungkan petunjuk itu, dan lu akan menemukan celah yang tidak terlihat oleh tool otomatisasi.

Dan yang terpenting: dokumentasikan setiap langkah. Di red team, laporan adalah produk akhir. Kalau lu naik ke root tapi tidak bisa menjelaskan bagaimana, laporan lu tidak ada nilai. Di dunia nyata, klien ingin tahu bukan cuma bahwa lu bisa masuk, tapi bagaimana cara mencegahnya.

Kesimpulan

Privilege escalation di Linux adalah seni menggabungkan technical skill, kesabaran, dan kreativitas. Setiap sistem adalah berbeda. Setiap klien punya infrastructure yang unik. Yang membuat red teamer hebat bukan tool yang dia pakai, tapi cara dia berpikir. Mulai dari enumeration, analisis konteks, eksploitasi celah kecil, sampai mendapatkan akses penuh.

Di dunia cybersecurity, yang terpenting bukan cuma "bisa hack", tapi "bisa mengamankan". Setiap celah yang lu temukan harus dilaporkan, dan setiap laporan harus memberikan rekomendasi perbaikan. Karena pada akhirnya, red team ada untuk membantu organisasi menjadi lebih aman, bukan cuma untuk menunjukkan seberapa hebatnya skill hacking.

Pertanyaan selanjutnya: setelah lu dapat akses root, apa yang harus dilakukan? Pertahanan, eksfiltrasi data, atau maintaining access? Itu adalah pertanyaan etika yang harus dijawab sebelum assessment dimulai. Di dunia nyata, setiap red teamer memiliki batasan yang harus dihormati. Tanpa batasan, skill yang powerful bisa menjadi bahaya yang tidak terkendali.

Semoga tulisan ini membantu kamu yang sedang belajar atau menjalani karir di dunia red team. Ingat, ini adalah perjalanan panjang. Tidak ada short cut. Yang ada adalah dedikasi, rasa ingin tahu, dan komitmen untuk terus belajar. Kali pertama gue berhasil naik ke root di lingkungan nyata, gue merasa seperti champion. Tahu tidak? Setelah ratusan assessment, excitement itu masih ada. Karena setiap sistem adalah puzzle baru, dan setiap puzzle adalah pelajaran baru.