Privilege Escalation Yetki Yükseltme Teknikleri ve Korunma Yolları

Bir internal pentest’te, lokal admin olmayan bir kullanıcıyla domain admin şifresi görmeden tüm domaine otorite almıştım. Kimse “nasıl yaptın?” diye sormadı; herkes hâlâ parola politikası tartışıyordu. Halbuki işin kritik noktası, tek bir zayıf servis hesabı ve yanlış yapılandırılmış bir izin zinciriydi.

Yetki Yükseltmede Asıl Silah: Yanlış Yapılandırmalar

Privilege escalation deyince çoğunun aklına direkt kernel exploit, 0-day falan geliyor ama pratikte en çok iş yapan şeyler misconfig ve “kimsenin ellemeye üşendiği” ayarlar oluyor. Mesela Linux tarafında klasik sudo -l ile çıkan, parola istemeden çalışan komutlar: (ALL) NOPASSWD: /usr/bin/vim gibi. Bu tek satır, aslında “root ol” demek ama kimse sudoers dosyasını gerçekten okumuyor.

Bir de şu var: Windows ortamlarında service account parolası asla expire edilmeyen, local admin olan, sonra da her yere “log on as service” izni
verilmiş hesaplar. Bunların hash’ini bir kere alıyorsun (mesela yanlış izinli bir yedekleme klasöründen ya da LAPS yanlış kurgulandığı için), sonra pass-the-hash ile domain’in yarısını gezebiliyorsun. Ortada 0-day yok, CVE yok; sadece kötü tasarlanmış yetki matrisi var.

Aklıma gelmişken, Linux’ta da setuid binary’ler hâlâ altın madenidir. find, tar, busybox gibi araçlar yanlış izinlerle ya da özel wrapper’larla setuid olunca, GTFOBins listesini açıp bakmak çoğu zaman yeterli oluyor.





CVE’ler, 0-Day’ler ve Gerçek Hayat

▸ Public Exploit vs Gerçek Kullanılabilirlik

Mesela son yıllarda çıkan birçok Windows LPE zafiyeti (CVE-202x-… serileri) teoride harika; PoC indirip derliyorsun ama gerçek ortamda EDR, sandbox, policy’ler derken direkt pat diye çalışmıyor. Burada deneyim devreye giriyor: exploit’i “loud” şekilde mi kullanacaksın
, yoksa önce living off the land ile lateral hareket edip, en son sessiz bir LPE mi deneyeceksin?

Ha bu arada, 0-day tarafında yetki yükseltme daha çok hedefli operasyonlarda kritik oluyor. Mesela bir sandbox escape ya da container breakout 0-day’i, bulut ortamında sana direkt host seviyesinde kontrol veriyor. Ama aynı etkiyi bazen tamamen bilinen bir CVE ile de alabiliyorsun; tek fark, patch yönetiminin rezalet olması.





▸ Post-Exploitation Zinciri

Privilege escalation’ı tek başına düşünmemek lazım; exploit zincirin ortasında bir adım sadece. Önce düşük yetkili foothold alıyorsun (örneğin zayıf bir web uygulaması RCE’si veya yanlış konfigüre edilmiş bir CI/CD runner), sonra local privesc (kernel/servis/CVE), sonra cred dumping (LSASS, /etc/shadow, config dosyaları), en son da lateral movement. Aradaki her adımın log izi farklı, tespit yüzeyi farklı, dolayısıyla saldırgan için “en sessiz privesc” her zaman en değer
li olan.

Korunma tarafında da bence en kritik pratikler: least privilege (hem kullanıcı hem servis hesapları için), düzenli sudoers ve setuid taramaları, local admin sayısını minimumda tutmak, ve AD tarafında ACL review’ları. Mesela kimse AD’de kimin kime GenericAll, WriteDACL izni olduğunu gerçekten çıkarmıyor; halbuki birçok yetki yükseltme vakası saf ACL suistimaliyle oluyor.

Siz pratikte en çok hangi tür privesc vektörlerine denk geliyorsunuz: yanlış izinler mi, güncellenmemiş CVE’ler mi, yoksa tamamen beklenmedik bir “tasarım hatası” mı?