<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Sızma Testi (Pentest)]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:39 +0000 MyBB <![CDATA[Pasif ve Aktif Keşif Farkı: Ne Zaman Hangisi, Hangi Araçlar]]> https://www.turkteam.org/konu-pasif-ve-aktif-kesif-farki-ne-zaman-hangisi-hangi-araclar.html Mon, 19 Oct 2026 00:26:17 +0300 KulTigin]]> https://www.turkteam.org/konu-pasif-ve-aktif-kesif-farki-ne-zaman-hangisi-hangi-araclar.html [Resim: attachment.php?aid=265]
Merhaba,

Pentest raporlarının keşif bölümü bazen ya çok zayıf oluyor ya da müşteriye "neden bu kadar gürültü yaptınız?" sorusunu doğuruyor. Sorunun kökü çoğu zaman pasif / aktif keşif ayrımının bulanık olmasından. Bu yazıda ikisini netleştirip hangi aşamada hangi araçlara baktığımı anlatacağım.

Pasif keşif nedir?
Hedefe doğrudan paket göndermeden, kamuya açık kaynaklardan bilgi toplamaktır. DNS kayıtları, sertifika şeffaflık logları, arama motorları, GitHub, iş ilanları, BGP/WHOIS... Hedef sizin trafiğinizi "tarama" olarak görmez (yine de ToS ve yasaları unutmayın).

Örnek pasif akış:
  1. WHOIS / RDAP ile sahip ve netblok
  2. Certificate Transparency (crt.sh) ile alt alan adları
  3. DNS: MX, TXT, SPF, DMARC
  4. Arama motoru dork'ları (kendi varlıklarınız / izinli kapsam)
  5. Şirket kariyer sayfası: teknoloji yığını ipuçları
Kod:
dig +short example.com ANY dig +short _dmarc.example.com TXT curl -s "https://crt.sh/?q=%25.example.com&output=json" | head

Aktif keşif nedir?
Hedefe paket gönderdiğiniz her şey: ping, port tarama, servis parmak izi, web spider, SMB null session denemeleri... IDS bunu görür, log üretir. Kapsam belgesi ve yazılı izin olmadan yapmayın.

Kod:
nmap -sS -sV -T3 -p- 10.10.10.50 whatweb https://hedef.lab

[Resim: attachment.php?aid=266]

Ne zaman hangisi?
  • Sözleşme öncesi / dışarıdan görünürlük: ağırlıkla pasif. Müşteriye "dışarıdan şöyle görünüyorsunuz" demek için yeter.
  • İç ağ pentesti: aktif kaçınılmaz; yine de önce pasifle domain listesini çıkarın.
  • Bug bounty: program kuralları pasifi serbest, aktifi sınırlı tutabilir; her programı okuyun.
  • Kırmızı/mavi tatbikat: mavi takımın tespit edeceği aktif teknikleri bilinçli seçin.

Araç eşlemesi (kısa)
Pasif: dig/drill, whois, crt.sh, SecurityTrails (hesaplı), Wayback, theHarvester (kaynaklarına dikkat), GitHub code search.
Aktif: nmap, masscan (çok agresif; izin ve rate şart), httpx, ffuf, gobuster, netexec, respond/erv (lab).

Gürültü yönetimi
Aktif keşifte kalite = kapsam × hız × gürültü dengesi. Pratik kurallarım:
  • Önce top port, sonra tam port; kör -p- her zaman ilk adım olmasın.
  • --max-rate ve zaman penceresi anlaşması.
  • Aynı IP'ye paralel 10 araç yağdırmayın; sonuçları birleştirin.
  • Bulguyu "nasıl bulundu" diye raporlayın: pasif CT logu mu, aktif nmap mi?

Raporlama dili
Müşteriye "port taradık" demek yetmez. Pasifte bulunan alt alan adının aktif doğrulaması ayrı satır olsun. Yanlış pozitifleri (CDN arkasındaki paylaşılan IP gibi) açıkça yazın.

Etik sınır
Üçüncü taraf servislere (çalışan kişisel GitHub'ı, alt yüklenici) taşmak kapsam dışıdır. OSINT'te bile KVKK ve ilgili gizlilik kuralları geçerlidir; kişisel veri toplamayın, yaymayın.

Kaynaklar
  • OWASP Testing Guide - Information Gathering
  • PTES Technical Guidelines
  • nmap.org dokümantasyonu

Siz pasiften aktife geçişte hangi kontrol listesini kullanıyorsunuz? Varsa şablonunuzu (hassas bilgi olmadan) paylaşın.

Örnek zaman çizelgesi (dış pentest)
Gün 0: sözleşme + kapsam IP/domain listesi. Gün 1: pasif (CT, DNS, iş ilanı, GitHub org). Gün 2: nazik aktif (top ports, httpx). Gün 3+: derinleşme yalnızca açık bulunan servislerde. Bu sıra hem gürültüyü hem de "neden baştan -p-?" sorusunu azaltır.

Bug bounty farkı
Programlar bazen automated scanning'i yasaklar veya rate limit koyar. Pasif keşif çoğu zaman serbesttir; yine de ToS okuyun. Wildscope'ta müşteri olmayan alt alan adlarına kaymak en sık ban nedenidir.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n06-698982.png (Dosya Boyutu: 58.55 KB / İndirme Sayısı: 10)

.png   n06-inner.png (Dosya Boyutu: 24.48 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=265]
Merhaba,

Pentest raporlarının keşif bölümü bazen ya çok zayıf oluyor ya da müşteriye "neden bu kadar gürültü yaptınız?" sorusunu doğuruyor. Sorunun kökü çoğu zaman pasif / aktif keşif ayrımının bulanık olmasından. Bu yazıda ikisini netleştirip hangi aşamada hangi araçlara baktığımı anlatacağım.

Pasif keşif nedir?
Hedefe doğrudan paket göndermeden, kamuya açık kaynaklardan bilgi toplamaktır. DNS kayıtları, sertifika şeffaflık logları, arama motorları, GitHub, iş ilanları, BGP/WHOIS... Hedef sizin trafiğinizi "tarama" olarak görmez (yine de ToS ve yasaları unutmayın).

Örnek pasif akış:
  1. WHOIS / RDAP ile sahip ve netblok
  2. Certificate Transparency (crt.sh) ile alt alan adları
  3. DNS: MX, TXT, SPF, DMARC
  4. Arama motoru dork'ları (kendi varlıklarınız / izinli kapsam)
  5. Şirket kariyer sayfası: teknoloji yığını ipuçları
Kod:
dig +short example.com ANY dig +short _dmarc.example.com TXT curl -s "https://crt.sh/?q=%25.example.com&output=json" | head

Aktif keşif nedir?
Hedefe paket gönderdiğiniz her şey: ping, port tarama, servis parmak izi, web spider, SMB null session denemeleri... IDS bunu görür, log üretir. Kapsam belgesi ve yazılı izin olmadan yapmayın.

Kod:
nmap -sS -sV -T3 -p- 10.10.10.50 whatweb https://hedef.lab

[Resim: attachment.php?aid=266]

Ne zaman hangisi?
  • Sözleşme öncesi / dışarıdan görünürlük: ağırlıkla pasif. Müşteriye "dışarıdan şöyle görünüyorsunuz" demek için yeter.
  • İç ağ pentesti: aktif kaçınılmaz; yine de önce pasifle domain listesini çıkarın.
  • Bug bounty: program kuralları pasifi serbest, aktifi sınırlı tutabilir; her programı okuyun.
  • Kırmızı/mavi tatbikat: mavi takımın tespit edeceği aktif teknikleri bilinçli seçin.

Araç eşlemesi (kısa)
Pasif: dig/drill, whois, crt.sh, SecurityTrails (hesaplı), Wayback, theHarvester (kaynaklarına dikkat), GitHub code search.
Aktif: nmap, masscan (çok agresif; izin ve rate şart), httpx, ffuf, gobuster, netexec, respond/erv (lab).

Gürültü yönetimi
Aktif keşifte kalite = kapsam × hız × gürültü dengesi. Pratik kurallarım:
  • Önce top port, sonra tam port; kör -p- her zaman ilk adım olmasın.
  • --max-rate ve zaman penceresi anlaşması.
  • Aynı IP'ye paralel 10 araç yağdırmayın; sonuçları birleştirin.
  • Bulguyu "nasıl bulundu" diye raporlayın: pasif CT logu mu, aktif nmap mi?

Raporlama dili
Müşteriye "port taradık" demek yetmez. Pasifte bulunan alt alan adının aktif doğrulaması ayrı satır olsun. Yanlış pozitifleri (CDN arkasındaki paylaşılan IP gibi) açıkça yazın.

Etik sınır
Üçüncü taraf servislere (çalışan kişisel GitHub'ı, alt yüklenici) taşmak kapsam dışıdır. OSINT'te bile KVKK ve ilgili gizlilik kuralları geçerlidir; kişisel veri toplamayın, yaymayın.

Kaynaklar
  • OWASP Testing Guide - Information Gathering
  • PTES Technical Guidelines
  • nmap.org dokümantasyonu

Siz pasiften aktife geçişte hangi kontrol listesini kullanıyorsunuz? Varsa şablonunuzu (hassas bilgi olmadan) paylaşın.

Örnek zaman çizelgesi (dış pentest)
Gün 0: sözleşme + kapsam IP/domain listesi. Gün 1: pasif (CT, DNS, iş ilanı, GitHub org). Gün 2: nazik aktif (top ports, httpx). Gün 3+: derinleşme yalnızca açık bulunan servislerde. Bu sıra hem gürültüyü hem de "neden baştan -p-?" sorusunu azaltır.

Bug bounty farkı
Programlar bazen automated scanning'i yasaklar veya rate limit koyar. Pasif keşif çoğu zaman serbesttir; yine de ToS okuyun. Wildscope'ta müşteri olmayan alt alan adlarına kaymak en sık ban nedenidir.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n06-698982.png (Dosya Boyutu: 58.55 KB / İndirme Sayısı: 10)

.png   n06-inner.png (Dosya Boyutu: 24.48 KB / İndirme Sayısı: 9) ]]> <![CDATA[Linux Yetki Yükseltme Temelleri: SUID, sudo, Cron ve Capabilities]]> https://www.turkteam.org/konu-linux-yetki-yukseltme-temelleri-suid-sudo-cron-ve-capabilities.html Sat, 17 Oct 2026 11:25:19 +0300 Tonyukuk]]> https://www.turkteam.org/konu-linux-yetki-yukseltme-temelleri-suid-sudo-cron-ve-capabilities.html [Resim: attachment.php?aid=98]
Bir makineye düşük yetkili bir kabuk (shell) aldınız, sonra ne olacak? Pentest'te asıl iş çoğu zaman o andan sonra başlar. Yetki yükseltme (privilege escalation) yeni başlayanların en çok zorlandığı konu, çünkü ezberlenecek komut değil, geliştirilecek bir bakış açısı. Bu rehberde Linux tarafında en sık karşılaşılan yol yükseltme yollarını kendi lab'ınızda deneyebileceğiniz şekilde topladım.

Konuda anlatılacaklar
  1. Yetki yükseltme nedir, neden önemli?
  2. İlk keşif (enumeration) mantığı
  3. SUID binary'ler
  4. sudo yanlış yapılandırmaları
  5. Cron job'lar
  6. Linux capabilities
  7. Otomasyon araçları
  8. Savunma ve yasal uyarı

Yetki Yükseltme Nedir?

Yetki yükseltme, sistemde sahip olduğunuz sınırlı yetkiyi (ör. www-data veya normal kullanıcı) daha yüksek bir yetkiye (çoğunlukla root) çıkarma işlemidir. Pentest raporunda "düşük yetkili erişim" ile "root erişim" arasındaki fark, müşteri için risk seviyesini tamamen değiştirir.

Temel felsefe: sistem, yanlış yapılandırma veya güncel olmayan bileşen barındırıyorsa, normal kullanıcının yetkisi genişletilebilir.

İlk Keşif (Enumeration)

Yetki yükseltmenin yüzde 80'i doğru keşiftir. Elle bakılacak temel yerler:

Kod:
id # mevcut kullanıcı ve gruplar sudo -l # sudo ile neler çalıştırabiliyoruz uname -a # kernel sürümü cat /etc/os-release ps aux # çalışan süreçler ls -la /etc/cron* # zamanlanmış görevler find / -perm -4000 -type f 2>/dev/null # SUID dosyalar getcap -r / 2>/dev/null # capabilities

SUID Binary'ler

SUID (Set User ID) biti olan bir program, çalıştıran kişinin değil, dosya sahibinin yetkisiyle çalışır. Sahibi root olan ve SUID'li bir binary, kötü tasarlanmışsa root yetkisiyle komut çalıştırmanıza yol açabilir.

Kod:
find / -perm -4000 -type f 2>/dev/null

Çıkan listede standart dışı veya bilinen suistimal edilebilir binary'ler (ör. find, vim, nano, cp bazı sürümlerde) varsa, GTFOBins sitesi hangi binary'nin nasıl suistimal edildiğini gösterir. Örnek fikir (find SUID ise):

Kod:
# find SUID ise root shell find . -exec /bin/sh -p \; -quit

sudo Yanlış Yapılandırmaları

Kod:
sudo -l

Çıktı, parolasız çalıştırabileceğiniz komutları gösterebilir. Örneğin bir kullanıcı (ALL) NOPASSWD ile bir metin editörü ya da betik dili çalıştırabiliyorsa, bu çoğu zaman root'a giden kapıdır (yine GTFOBins referansı). Eski sudo sürümlerindeki bilinen CVE'ler de (ör. Baron Samedit) kontrol edilmelidir.

Cron Job'lar

Zamanlanmış görevler root olarak çalışıyor olabilir. Eğer root'un çalıştırdığı bir script'e yazma yetkiniz varsa veya script güvensiz bir PATH kullanıyorsa, oraya kendi komutunuzu ekleyebilirsiniz.

Kod:
cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.daily/ # root'un çalıştırdığı, herkese yazılabilir bir script var mı? find / -writable -name "*.sh" 2>/dev/null

Linux Capabilities

Capabilities, root yetkisini küçük parçalara böler. Bir binary'ye tehlikeli bir capability (ör. cap_setuid) atanmışsa, SUID olmasa bile yetki yükseltmeye yarayabilir.

Kod:
getcap -r / 2>/dev/null

Örneğin bir Python binary'sinde cap_setuid+ep görürseniz, bu genelde root'a giden bir yoldur.

Otomasyon Araçları

Elle keşfi öğrendikten sonra hız için:
  • LinPEAS - en kapsamlı otomatik keşif script'i
  • linux-smart-enumeration (lse.sh)
  • pspy - root yetkisi olmadan çalışan süreçleri/cron'ları izler

Önerim: önce elle keşfi kavrayın, araçları sonra kullanın. Yoksa LinPEAS çıktısı sizin için anlamsız bir duvar olur.

Savunma Tarafı
  • Gereksiz SUID bitlerini kaldırın, SUID envanteri çıkarın.
  • sudo kurallarını daraltın; NOPASSWD'i kabuk/editör çalıştıran komutlara vermeyin.
  • Cron script'lerini root'a özel, yalnızca root yazabilir yapın; tam yol kullanın.
  • Capabilities'i düzenli denetleyin.
  • Kernel ve paketleri güncel tutun.

Lab Önerisi

Pratik için TryHackMe "Linux PrivEsc", HackTheBox retired makineleri ve bilerek zafiyetli VM'ler birebir. Hepsi kendi hesabınızda, izinli ortamlardır.

Yasal Uyarı

Yetki yükseltme teknikleri yalnızca kendi sistemlerinizde veya yazılı izin/eğitim platformu kapsamında denenmelidir. İzinsiz sistemlerde uygulanması TCK 243-245 kapsamında suçtur.

Görsel: TurkTeam özgün kapak görseli

.jpg   tonyukuk-12-privesc.jpg (Dosya Boyutu: 74.94 KB / İndirme Sayısı: 11) ]]> [Resim: attachment.php?aid=98]
Bir makineye düşük yetkili bir kabuk (shell) aldınız, sonra ne olacak? Pentest'te asıl iş çoğu zaman o andan sonra başlar. Yetki yükseltme (privilege escalation) yeni başlayanların en çok zorlandığı konu, çünkü ezberlenecek komut değil, geliştirilecek bir bakış açısı. Bu rehberde Linux tarafında en sık karşılaşılan yol yükseltme yollarını kendi lab'ınızda deneyebileceğiniz şekilde topladım.

Konuda anlatılacaklar
  1. Yetki yükseltme nedir, neden önemli?
  2. İlk keşif (enumeration) mantığı
  3. SUID binary'ler
  4. sudo yanlış yapılandırmaları
  5. Cron job'lar
  6. Linux capabilities
  7. Otomasyon araçları
  8. Savunma ve yasal uyarı

Yetki Yükseltme Nedir?

Yetki yükseltme, sistemde sahip olduğunuz sınırlı yetkiyi (ör. www-data veya normal kullanıcı) daha yüksek bir yetkiye (çoğunlukla root) çıkarma işlemidir. Pentest raporunda "düşük yetkili erişim" ile "root erişim" arasındaki fark, müşteri için risk seviyesini tamamen değiştirir.

Temel felsefe: sistem, yanlış yapılandırma veya güncel olmayan bileşen barındırıyorsa, normal kullanıcının yetkisi genişletilebilir.

İlk Keşif (Enumeration)

Yetki yükseltmenin yüzde 80'i doğru keşiftir. Elle bakılacak temel yerler:

Kod:
id # mevcut kullanıcı ve gruplar sudo -l # sudo ile neler çalıştırabiliyoruz uname -a # kernel sürümü cat /etc/os-release ps aux # çalışan süreçler ls -la /etc/cron* # zamanlanmış görevler find / -perm -4000 -type f 2>/dev/null # SUID dosyalar getcap -r / 2>/dev/null # capabilities

SUID Binary'ler

SUID (Set User ID) biti olan bir program, çalıştıran kişinin değil, dosya sahibinin yetkisiyle çalışır. Sahibi root olan ve SUID'li bir binary, kötü tasarlanmışsa root yetkisiyle komut çalıştırmanıza yol açabilir.

Kod:
find / -perm -4000 -type f 2>/dev/null

Çıkan listede standart dışı veya bilinen suistimal edilebilir binary'ler (ör. find, vim, nano, cp bazı sürümlerde) varsa, GTFOBins sitesi hangi binary'nin nasıl suistimal edildiğini gösterir. Örnek fikir (find SUID ise):

Kod:
# find SUID ise root shell find . -exec /bin/sh -p \; -quit

sudo Yanlış Yapılandırmaları

Kod:
sudo -l

Çıktı, parolasız çalıştırabileceğiniz komutları gösterebilir. Örneğin bir kullanıcı (ALL) NOPASSWD ile bir metin editörü ya da betik dili çalıştırabiliyorsa, bu çoğu zaman root'a giden kapıdır (yine GTFOBins referansı). Eski sudo sürümlerindeki bilinen CVE'ler de (ör. Baron Samedit) kontrol edilmelidir.

Cron Job'lar

Zamanlanmış görevler root olarak çalışıyor olabilir. Eğer root'un çalıştırdığı bir script'e yazma yetkiniz varsa veya script güvensiz bir PATH kullanıyorsa, oraya kendi komutunuzu ekleyebilirsiniz.

Kod:
cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.daily/ # root'un çalıştırdığı, herkese yazılabilir bir script var mı? find / -writable -name "*.sh" 2>/dev/null

Linux Capabilities

Capabilities, root yetkisini küçük parçalara böler. Bir binary'ye tehlikeli bir capability (ör. cap_setuid) atanmışsa, SUID olmasa bile yetki yükseltmeye yarayabilir.

Kod:
getcap -r / 2>/dev/null

Örneğin bir Python binary'sinde cap_setuid+ep görürseniz, bu genelde root'a giden bir yoldur.

Otomasyon Araçları

Elle keşfi öğrendikten sonra hız için:
  • LinPEAS - en kapsamlı otomatik keşif script'i
  • linux-smart-enumeration (lse.sh)
  • pspy - root yetkisi olmadan çalışan süreçleri/cron'ları izler

Önerim: önce elle keşfi kavrayın, araçları sonra kullanın. Yoksa LinPEAS çıktısı sizin için anlamsız bir duvar olur.

Savunma Tarafı
  • Gereksiz SUID bitlerini kaldırın, SUID envanteri çıkarın.
  • sudo kurallarını daraltın; NOPASSWD'i kabuk/editör çalıştıran komutlara vermeyin.
  • Cron script'lerini root'a özel, yalnızca root yazabilir yapın; tam yol kullanın.
  • Capabilities'i düzenli denetleyin.
  • Kernel ve paketleri güncel tutun.

Lab Önerisi

Pratik için TryHackMe "Linux PrivEsc", HackTheBox retired makineleri ve bilerek zafiyetli VM'ler birebir. Hepsi kendi hesabınızda, izinli ortamlardır.

Yasal Uyarı

Yetki yükseltme teknikleri yalnızca kendi sistemlerinizde veya yazılı izin/eğitim platformu kapsamında denenmelidir. İzinsiz sistemlerde uygulanması TCK 243-245 kapsamında suçtur.

Görsel: TurkTeam özgün kapak görseli

.jpg   tonyukuk-12-privesc.jpg (Dosya Boyutu: 74.94 KB / İndirme Sayısı: 11) ]]> <![CDATA[Pentest Metodolojisi 2026: Keşiften Raporlamaya Adım Adım]]> https://www.turkteam.org/konu-pentest-metodolojisi-2026-kesiften-raporlamaya-adim-adim.html Fri, 16 Oct 2026 11:18:26 +0300 Tonyukuk]]> https://www.turkteam.org/konu-pentest-metodolojisi-2026-kesiften-raporlamaya-adim-adim.html [Resim: attachment.php?aid=23]
Sızma Testi Metodolojisi: Keşiften Raporlamaya

Merhaba,

İyi bir pentest "araç çalıştırmak" değil; kapsamı net, kanıtı güçlü, raporu anlaşılır bir süreçtir. Bu rehber PTES ve NIST SP 800-115 çizgisinde, yetkili bir testin aşamalarını özetler.

Konuda Anlatılacaklar
  1. Sözleşme ve kapsam
  2. Keşif (Reconnaissance)
  3. Tarama ve enumerasyon
  4. Zafiyet analizi ve sömürü (yalnızca izinli lab)
  5. Post-exploitation ve temizlik
  6. Raporlama

1) Sözleşme ve Kapsam
Teste başlamadan yazılı olarak netleştirin:
  • Hedef IP/alan adı / uygulama listesi
  • Yasaklı eylemler (DoS, sosyal mühendislik, üçüncü taraf bulut)
  • Zaman penceresi ve iletişim kanalı
  • Acil durum kontağı
  • Veri işleme ve gizlilik maddeleri

2) Keşif
Kod:
# Pasif: WHOIS, sertifika şeffaflığı, genel DNS whois ornek.com dig ornek.com ANY +noall +answer # Aktif (yalnızca kapsam içi) nmap -sn 10.10.10.0/24

3) Tarama ve Enumerasyon
Kod:
sudo nmap -sS -sV -sC -oA kapsam_tarama 10.10.10.0/24 # Web için (izinli hedef) # whatweb, httpx, nuclei gibi araçlar kapsam ve sözleşme dahilinde

4) Zafiyet ve Sömürü
Bulunan her bulgu için: yeniden üretilebilir adımlar, ekran görüntüsü / paket kaydı, CVSS veya benzeri risk skoru, iş etkisi. Sömürü yalnızca yazılı izin ve lab / kapsam içinde.

5) Raporlama İskeleti
  1. Yönetici özeti (iş dili)
  2. Kapsam ve metodoloji
  3. Bulgular (kritik -> düşük)
  4. Kanıtlar
  5. Düzeltme önerileri
  6. Pozitif bulgular (ne iyi yapılmış)

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Sızma testi yalnızca yazılı yetkiyle ve kapsam dahilinde yapılır. İzinsiz erişim TCK 243-245 kapsamında suçtur.


.jpg   tonyukuk-14.jpg (Dosya Boyutu: 102.28 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=23]
Sızma Testi Metodolojisi: Keşiften Raporlamaya

Merhaba,

İyi bir pentest "araç çalıştırmak" değil; kapsamı net, kanıtı güçlü, raporu anlaşılır bir süreçtir. Bu rehber PTES ve NIST SP 800-115 çizgisinde, yetkili bir testin aşamalarını özetler.

Konuda Anlatılacaklar
  1. Sözleşme ve kapsam
  2. Keşif (Reconnaissance)
  3. Tarama ve enumerasyon
  4. Zafiyet analizi ve sömürü (yalnızca izinli lab)
  5. Post-exploitation ve temizlik
  6. Raporlama

1) Sözleşme ve Kapsam
Teste başlamadan yazılı olarak netleştirin:
  • Hedef IP/alan adı / uygulama listesi
  • Yasaklı eylemler (DoS, sosyal mühendislik, üçüncü taraf bulut)
  • Zaman penceresi ve iletişim kanalı
  • Acil durum kontağı
  • Veri işleme ve gizlilik maddeleri

2) Keşif
Kod:
# Pasif: WHOIS, sertifika şeffaflığı, genel DNS whois ornek.com dig ornek.com ANY +noall +answer # Aktif (yalnızca kapsam içi) nmap -sn 10.10.10.0/24

3) Tarama ve Enumerasyon
Kod:
sudo nmap -sS -sV -sC -oA kapsam_tarama 10.10.10.0/24 # Web için (izinli hedef) # whatweb, httpx, nuclei gibi araçlar kapsam ve sözleşme dahilinde

4) Zafiyet ve Sömürü
Bulunan her bulgu için: yeniden üretilebilir adımlar, ekran görüntüsü / paket kaydı, CVSS veya benzeri risk skoru, iş etkisi. Sömürü yalnızca yazılı izin ve lab / kapsam içinde.

5) Raporlama İskeleti
  1. Yönetici özeti (iş dili)
  2. Kapsam ve metodoloji
  3. Bulgular (kritik -> düşük)
  4. Kanıtlar
  5. Düzeltme önerileri
  6. Pozitif bulgular (ne iyi yapılmış)

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Sızma testi yalnızca yazılı yetkiyle ve kapsam dahilinde yapılır. İzinsiz erişim TCK 243-245 kapsamında suçtur.


.jpg   tonyukuk-14.jpg (Dosya Boyutu: 102.28 KB / İndirme Sayısı: 7) ]]>