Pasif keşif: hedefe dokunmadan

Yetkili bir sızma testi taramayla değil, dinlemeyle başlar. Pasif keşif, hedefe tek paket yollamadan onun dışarıya nasıl göründüğünü çıkarır. Veriyi hedeften değil, üçüncü kaynaklardan alırsın: alan adı kayıtları, sertifika günlükleri, arama motorları ve arşiv siteleri.

Elindeki kapsam belgesi genelde birkaç alan adı ve bir IP aralığından ibarettir. İlk işin, o dar listenin gerçekte ne kadar geniş bir yüzeye açıldığını anlamaktır. Bu bölümde bu kaynakları tek tek açar, her birinin hangi soruya yanıt verdiğini ve nerede kişisel veri sınırına dokunduğunu görürsün.

Keşif tek bir eylem değildir, bir ton skalasıdır. Pasif uçta hedefin sunucusuna hiç dokunmazsın; veriyi bir başkasının topladığı arşivden okursun. Yarı pasif uçta hedefe ait olmayan ama onu tarayan servisleri sorgularsın; istek senden değil, o servisten hedefe gider. Aktif uçta ise paketi doğrudan hedefe yollarsın ve onun günlüğüne satır düşer.

Bir işlemin hangi tona düştüğünü belirleyen tek soru şudur: bu eylem hedefin kayıtlarında iz bırakır mı? Bu soruyu her adımda kendine sorman, kapsamın dışına erken çıkmanı önler.

MITRE ATT&CK bu aşamayı Reconnaissance taktiği (TA0043) altında toplar ve on iki tekniğe böler. Pasif çalışmada üç öbek işine yarar. T1596 Search Open Technical Databases açık teknik veri tabanlarını kapsar: T1596.001 pasif DNS, T1596.002 WHOIS, T1596.003 sayısal sertifikalar. T1590 Gather Victim Network Information ağ verisini toplar: alan adı özellikleri (.001) ve DNS (.002).

T1593 Search Open Websites/Domains ise arama motorlarını (.002) ve kod depolarını (.003) içine alır. İnsan tarafını iki teknik daha okur: T1589 çalışan adları ve e-posta adresleri gibi kimlik bilgisini, T1591 kurumun yapısını ve iş ilişkilerini toplar. Kişisel veriye en çok bu ikisi dokunur. Her teknik farklı bir üçüncü kaynağı okur; hepsi hedefe paket yollamadan çalışır.

Bir alan adının arkasındaki kayıt verisi ilk duraktır. Klasik whois protokolü 43. portta düz metin döner: kayıt sahibi, kayıt ve bitiş tarihleri, ad sunucuları.

Ad sunucusu satırı çoğu zaman en değerli ipucudur, çünkü alan adının hangi barındırma ya da bulut sağlayıcısında durduğunu söyler. Kayıt tarihleri ise altyapının yaşını verir; yeni kaydedilmiş bir alan adı genelde bir kampanya ya da geçici bir proje işaretidir.

Kayıt verisine erişim biçimi son yıllarda değişti. ICANN, yapılandırılmış ve yetkilendirilebilir bir protokol olan RDAP'ı zorunlu kıldı. 28 Ocak 2025 tarihinden sonra genel üst düzey alan adı kayıt kuruluşları artık whois hizmeti vermek zorunda değil; istisna olarak yalnız .com, .name ve .post kaldı.

Pratikte ne değişir? whois çıktısının biçimi sağlayıcıdan sağlayıcıya oynayabilir, RDAP ise JSON döner. İki kaynağı da denersen, birinin kısıtladığı alanı çoğu zaman öbüründen tamamlarsın.

$ whois hedef.example | grep -i 'Registrant\|Name Server'
$ dig +short NS hedef.example
# $RDAP: alan adının üst düzey uzantısına düşen RDAP uç noktası
$ curl -s "$RDAP/domain/hedef.example" | jq '.nameservers[].ldhName, .events[].eventDate'

Bu satırlar aynı kayıt verisini farklı kanaldan çeker. whois çıktısını grep ile daraltırsın, ilk dig satırı ad sunucularını kısa biçimde verir.

RDAP tarafında ise önce doğru sunucuyu bulman gerekir: IANA'nın yayımladığı önyükleme kaydı, hangi üst düzey uzantının hangi RDAP sunucusuna düştüğünü söyler. O adresi bir değişkene alır, alan adını sorar ve yapılandırılmış JSON yanıt alırsın; ad sunucuları ve olay tarihleri ayrı alanlarda durur. Hiçbir komut hedefin web sunucusuna istek atmaz; sorgu kayıt kuruluşuna ya da RDAP sunucusuna gider.

$ whois hedef.example | grep -i 'Registrant\|Name Server'

Kayıt verisini okurken kaynakların birbirini doğrulaması önemlidir. Tek bir sitede gördüğün bilgi eski olabilir. İki ayrı kaynak aynı ad sunucusunu söylüyorsa o satıra güvenirsin.

Bir IP ortak barındırmada başka kuruma da ait olabilir; kayıt sahibi, sertifika adı ve ters DNS birlikte okunduğunda varlığın gerçekten hedefe ait olup olmadığı netleşir. Bu çapraz okumanın hepsi pasif kalır, çünkü kayıt kuruluşu, sertifika günlüğü ve arşiv hedefle senin yerine çoktan konuşmuştur. Hedefin giriş sayfasını açtığın an ise aktif tarafa geçersin.

DNS kayıtları bir kurumun teknoloji haritasını sessizce açar. MX kaydı posta altyapısını gösterir; posta bir bulut servisinde duruyorsa oltalama senaryosu o servisin kurallarına göre kurulur. TXT kayıtları özellikle bereketlidir.

SPF satırı, adına posta gönderebilen sunucuları listeler ve şirketin hangi posta sağlayıcısını kullandığını ele verir. Doğrulama satırları ise hangi bulut ürünlerine kayıt olunduğunu söyler. Tek bir TXT sorgusundan bir bağımlılık listesi çıkar.

SPF'nin biçimi RFC 7208'de tanımlıdır. 'v=spf1' ile başlar, 'include:' ifadeleriyle yetkili sağlayıcıları sıralar ve genelde 'all' mekanizmasıyla biter. E-posta kimlik doğrulamasının ikinci ayağı DMARC'tır; '_dmarc' alt alanındaki TXT kaydında durur ve 'p=' etiketiyle politikayı bildirir.

Bir kurumun DMARC politikası 'p=none' ise sahte gönderim engellenmez, yalnız raporlanır. Bu satır hem savunmanın olgunluğunu hem de bir oltalama testinin ne kadar kolay geçeceğini önceden söyler.

$ dig +short MX hedef.example
$ dig +short TXT hedef.example
$ dig +short TXT _dmarc.hedef.example

İkinci komutun örnek çıktısı 'v=spf1 include:_spf.saglayici.example -all' biçiminde döner. Bunu satır satır oku. 'v=spf1' kayıt türünü belirtir.

'include:_spf.saglayici.example' hangi sağlayıcının posta göndermeye yetkili olduğunu söyler ve doğrudan bir bağımlılık ifşasıdır. Sondaki '-all' ise listedeki dışında her kaynağı sert biçimde reddet demektir; '~all' görseydin bu yumuşak bir uyarı olurdu. Tek satırdan hem posta sağlayıcısını hem de kurumun ne kadar sıkı yapılandırdığını çıkardın.

Bu izleri okumanın karşılığı savunma tarafında da vardır. TXT ve SPF kayıtlarını temiz tutmak, artık kullanılmayan sağlayıcıları listeden çıkarmak dışarıya sızan bağımlılık sayısını düşürür. WHOIS gizliliği kayıt sahibi bilgisini maskeler.

DMARC politikasını 'p=reject' seviyesine çekmek, adına gönderilen sahte postayı doğrudan engeller. Saldırganın okuduğu her satır, savunanın kapatabileceği bir açıklıktır; bu yüzden aynı sorguları kurumun kendisi de düzenli çalıştırır. Geçişi aceleye getirmez: önce 'p=none' ile gelen raporları okur, meşru gönderenleri SPF'ye ekler, sonra politikayı sıkılaştırır.

Bir kuruma verilen her TLS sertifikası, herkese açık ve yalnız eklenebilir günlüklere yazılır. Buna sertifika şeffaflığı (Certificate Transparency) denir. Amaç sahte sertifikayı yakalamaktır, ama yan etkisi keşif için altın değerindedir: bir kurum yönetim panelini gizlese bile, o panele verdiği sertifikanın adı günlükte kalır. crt.sh gibi arayüzler bu günlükleri sorgular ve tek bir joker sertifikadan onlarca iç alt alan adı düşer.

$ curl -s 'https://crt.sh/?q=%25.hedef.example&output=json' | jq -r '.[].name_value' | sort -u

Komutu parça parça çöz. '%25' işareti URL kodlamasında yüzde imidir ve crt.sh için 'her şey' anlamına gelen joker görevi görür; yani '*.hedef.example' altındaki tüm adları ister. jq süzgeci JSON yanıtından yalnız 'name_value' alanını çeker.

Çıktıda 'www.hedef.example', 'posta.hedef.example' gibi düz adların yanında '*.hedef.example' biçiminde joker satırlar da görünür. Joker satırlar tek bir sertifikanın tüm alt alanları kapsadığını gösterir ama tekil bir hedef vermez; genelde 'grep -v "^\*"' ile elenir. sort -u ise tekrar eden adları tek satıra indirir.

Bir örnek üstünden gidelim. Bir kurum panelini 'panel-internal.hedef.example' adında yayımlamış ve bu adı hiçbir yere bağlamamış olsun. Ama panele HTTPS verdiği an, sunucu bu adı taşıyan bir sertifika alır ve sertifika günlüğe yazılır. Sen crt.sh sorgusunda bu adı görürsün, oysa arama motorunda ya da sitenin menüsünde izi yoktur.

Gizlemek işe yaramaz; sertifika günlüğü tek satırda paneli açığa çıkarır. Bu kaynak savunan taraf için de erken uyarı sistemidir. Kendi adına verilen sertifikaların günlüğünü izleyen kurum, izinsiz açılmış bir alt alanı saatler içinde fark eder. Dışarıdan nasıl göründüğünü bilmeyen kurum ise o listeyi saldırgana kendi eliyle hazırlatmış olur.

Arama motoru operatörleri keşif tablosunu tamamlar. 'site:hedef.example' sorgusu yalnız hedefe ait dizinli sayfaları getirir. 'filetype:pdf' ya da 'filetype:xlsx' belge türünü daraltır ve çoğu zaman yanlışlıkla yayımlanmış iç belgeleri açar.

'inurl:admin' adres içindeki bir sözcüğü, 'intitle:index of' ise dizin listeleme açık bir klasörü arar. Bu sorgular hedefe istek atmaz; arama motorunun daha önce topladığı dizini okur, bu yüzden pasiftir ve hedefin kaydına satır düşürmez.

Arşiv siteleri sabırlı olana ödül verir. web.archive.org silinmiş sayfaların eski kopyalarını tutar. Bir kurum yönetim bağlantısını sitesinden kaldırmış olabilir, ama iki yıl önceki kopya hâlâ arşivde durur.

Eski bir sayfanın kaynağında kaldırılmış bir uç adresi, bir belge üstverisinde kalmış iç kullanıcı adı bulmak olağandır. Bunlar canlı sistemde görünmez ama yapı hakkında doğrudan ipucu verir ve otomatik taramaya nereden başlayacağını söyler.

Topladığın veriyi düzenli tutmak işin ayrılmaz parçasıdır. Her kaynağın çıktısını ayrı dosyaya yaz, tarih at ve çalıştırdığın komutu kaydet. Rapor aşamasında bir bulgunun nereden geldiğini göstermek zorundasın; hafızadan yazılan keşif bölümü denetlenemez. Çalışan adları ve e-postaları toplarken de kişisel veri kurallarına uyar, yalnız testin gerektirdiği kadarını alır ve raporda maskelersin.

Belge üstverisi için de aynı özen gerekir. Bir PDF'in yazar alanında çıkan kullanıcı adı bulgudur, ama kişinin kendisi hedef değildir. Savunma tarafı bu yüzden belgeleri yayımlamadan önce üstveriden arındırır.

Gerçek işte bu aşamanın en somut karşılığı ödül avı (bug bounty) kapsam belgesidir. Bir program hangi alan adlarının test edilebilir olduğunu, hangilerinin dışarıda kaldığını satır satır yazar. Pasif keşif tam da burada değer üretir: topladığın adları kapsamla eşleştirir, dışarıda kalan varlıklara hiç dokunmadan yalnız izinli yüzeye odaklanırsın.

Kapsamı okumadan taramaya başlamak, hem boşa emek hem de yetki sınırını aşma riskidir. İyi keşif, ne yapmayacağını da bilmektir.