Tekrarlanabilir bug bounty metodolojisi: recon'dan rapora

Neden metodoloji

Bug bounty’de en pahalı hata, rastgele payload denemektir. Aynı hedefe iki kişi bakar; biri üç gün “deneyip durur”, öteki yarım günde kritik bulur. Fark zekâ değil — süreç. Bu yazı, kendi engagement’larımda oturttuğum, her hedefte aynı sırayla işlettiğim akışı anlatıyor. Amaç: çıktıyı şanstan kurtarıp tekrarlanabilir kılmak.

Akış dört faz: keşif → saldırı yüzeyi haritası → sınıf-öncelikli test → triyaj & rapor. Her faz bir sonrakini besler; atlamak baştan kör başlamak demek.

1. Keşif: pasif önce, aktif sonra

Pasif keşif hedefe tek paket göndermeden yapılır — sertifika şeffaflık logları (crt.sh), pasif DNS, subfinder, arşivlenmiş URL’ler (gau, waybackurls). Burada amaç envanter, sömürü değil.

subfinder -d hedef.com -all -silent > subs.txt
cat subs.txt | httpx -silent -sc -title -tech-detect > live.txt

Kritik disiplin: bu araçlar on binlerce satır üretir. Çıktıyı her zaman diske yönlendir (> dosya), tee ile terminale basma. Büyük dosyaya grep/head ile dokun. Bağlamı şişiren recon, engagement’ı bitiremeden boğar.

Aktif keşif sonra gelir: canlı hostlarda port/servis, teknoloji fingerprint, içerik keşfi (ffuf, katana). Pasifte bulduğun isimli hostlara daralt — tüm wildcard’ı taramak zaman israfı.

2. Saldırı yüzeyi haritası

Host listesi bulgu değil. Haritaya çevir: her canlı uç için giriş noktası (parametre, form, header, JSON alanı), kimlik durumu (anonim / kullanıcı / admin), teknoloji (framework, WAF, auth mekanizması). Bu harita testin önceliğini belirler.

İki şey ararım: (1) güven sınırları — bir bileşen başka bir bileşene nasıl güveniyor (SSO, internal API, webhook); açıklar sınırlarda yaşar. (2) kullanıcı-kontrollü veri akan yerler — URL fetch eden alanlar, dosya yükleme, şablon render, SQL’e giden girdi.

3. Sınıf-öncelikli test

Burada en büyük hatadan kaçınırım: düşük-değer sınıfa zaman harcamak. IDOR, açık CORS, eksik header, self-XSS — çoğu program bunları ya N/A der ya da kuruş öder. Zamanı ödül kazandıran ve gerçek etki taşıyan sınıflara ayırırım:

• ATO (hesap ele geçirme) — auth/oturum/OAuth/JWT zincirleri
• XSS — stored ve DOM, gerçek oturum çalmaya çıkanlar
• SSRF → bulut metadata → kimlik hırsızlığı
• RCE — şablon enjeksiyonu, deserialization, dosya yükleme zinciri
• Veri dökümü — SQLi, yetkisiz toplu veri erişimi

Her hedef için tek bir sınıfta yüzeysel gezinmek yerine, seçtiğim hedefi iliğine kadar sömürürüm. HTB’nin 8-adım web metodolojisini per-target uygularım: keşif → haritalama → her parametreyi test → kimlik/oturum → enjeksiyon → zincirleme → etki kanıtı → checkpoint. Batch halinde 50 hedefe “canary” atıp geçmem; bir hedefte derinleşmek, ona göz atıp bırakmaktan her zaman daha çok bulur.

4. Triyaj: 7 soru kapısı

Bir şey “garip” göründüğünde, rapora geçmeden önce yedi soru sorarım. Hepsine net cevap yoksa, bulgu değildir:

1. Güvenlik sınırını aşıyor mu? (yoksa tasarım, açık değil)
2. Etki ne? Somut zarar — “olabilir” değil, “oluyor”.
3. Tekrarlanıyor mu? Temiz bir oturumda, sıfırdan.
4. Ön koşullar gerçekçi mi? MITM/fiziksel erişim gerektiren çoğu zaman N/A.
5. Kanıt hangi merdiven basamağında? (aşağıda)
6. Zaten biliniyor / scope dışı mı?
7. PoC zararsız mı? Üretim verisini bozmadan kanıtladım mı?

Kanıt merdiveni

Yalnız L3 ve üstünü raporlarım. “Şuna zincirlenebilir” ama zincirlenmemiş = otomatik N/A. Triager senin yerine hayal kurmaz.

5. Rapor: triager-proof

İyi bulgu kötü raporla ölür. Her rapor: tek cümlelik özet → etki → birebir tekrar adımları → tek satır PoC (curl/URL) → önerilen düzeltme. Triager’ın senin kafandakini tahmin etmesi gereken hiçbir boşluk bırakmam. Ekran görüntüsü değil, kopyalanabilir kanıt.

Kapanış

Metodoloji sıkıcı görünür ama tam da bu yüzden işe yarar: heyecanı değil tekrarı ödüllendirir. Şansa güvenen avcı bazen kazanır; sürece güvenen her hedefte taban çizgisini yükseltir. Buradaki akış benim taban çizgim — her engagement’ta aynı sırayla, aynı disiplinle.