Keşif: sormadan öğrenmek
- Pasif ve aktif keşfi ayırmayı; DNS, whois, RDAP ve sertifika kütükleriyle hedefe dokunmadan bilgi toplamayı ve taramanın izini okumayı öğren.
- Pasif keşifte hedefe tek paket gitmez, aktif keşifte istek yollar ve iz bırakırsın.
- Whois, RDAP, DNS ve sertifika kütüklerini sırayla kullanacak, sonra aktif taramanın izini log satırında göreceksin.
Puan bütün etkinlikleri cevaplayınca hesaba yazılır. Bu dersi tamamlayınca +50 XP alacaksın. Giriş yapmadan ilerlersen puan yalnız bu tarayıcıda durur.
Keşif, saldırının ilk ve en uzun adımıdır. Acele eden kaybeder. Hedefin kaç alan adı var, hangi sunucu hangi işi görür, kim çalışıyor. Bu soruların cevabı çoğu zaman kimseye sorulmadan bulunur.
Keşif ucuzdur. Tek kuruş harcamadan, tek alarm çaldırmadan yüzlerce satır bilgi toplarsın.
İyi bir keşif, sonraki adımları tahminden çıkarıp bilgiye çevirir. MITRE ATT&CK bu aşamayı Keşif taktiği olarak ayrı sayar ve saldırganın ileri operasyonları planlamak için bilgi topladığını söyler. Bu derste sessiz kaynaklardan gürültülü taramaya doğru adım adım ilerleyeceksin.
Pasif ve aktif keşif
Keşif iki türlüdür. Pasif keşifte hedefin sunucusuna tek paket gitmez. Başkalarının topladığı kayıtları okursun. Aktif keşifte hedefe istek yollar ve karşılığını beklersin.
Aradaki sınır nettir. Paket hedefe ulaştıysa aktiftesin. Ulaşmadıysa pasif taraftasın. Pasif keşfin disiplin adı açık kaynak istihbaratıdır (Open Source Intelligence, OSINT).
OSINT yalnız arama motoru değildir. Alan adı kayıtları, sertifika kütükleri, iş ilanları, kod depoları ve eski web arşivleri de açık kaynaktır. Her biri hedefin başka bir yüzünü gösterir.
Etkinlik 1 / 7
Her adımı pasif ya da aktif keşif olarak ayır.
Önce bir seçeneğe, sonra aşağıdaki uygun kutuya bas. İstersen seçeneği kutuya sürükleyip bırak. Yerini değiştirmek için aynı işlemi tekrarla.
0/5 seçenek yerleşti.
Fark, log satırında görünür. Pasif keşif hedefin kaydına düşmez, çünkü ortada istek yoktur.
Aktif tarama düşer. Savunan ekip seni ilk orada görür. Zamanlama da önemlidir. Mesai dışında yapılan tarama daha çok göze batar, çünkü o saatte trafik azdır ve her istek tek başına parlar.
Yoğun saatteki istek ise gürültünün arasında kaybolur. Yetkili bir testte bu bir gizlenme meselesi değildir, kapsam belgesi saat penceresini zaten yazar. Ama savunan tarafın hangi saatte neyi göreceğini bilmek, alarmları doğru okumana yardım eder.
Şema keşfin döngüsünü gösterir. Önce neye ihtiyaç duyduğunu belirlersin, sonra açık kaynaklardan toplarsın. Topladığını ayıklar, doğrular ve bir rapora bağlarsın.
Pasif keşif bu döngünün toplama halkasında kalır. Doğrulama halkasını atlama. Açık kaynak bilgisi eskir ve yanıltır.
Üç yıl önceki bir iş ilanı bugünkü yazılımı göstermez. Her bulguya kaynağını ve tarihini yaz. İki bağımsız kaynaktan gelen bilgi, tek kaynaktan gelene göre daha güvenilirdir. Tek kaynağa dayanan bulguyu raporda varsayım olarak işaretle.
Etkinlik 2 / 7
Doğru mu, yanlış mı?
Pasif keşif hedefin erişim loglarında satır oluşturur.
DNS kayıtları: altyapının haritası
DNS kayıtları altyapıyı ele verir. A kaydı ismin IPv4 adresini, AAAA kaydı IPv6 adresini söyler. MX kaydı postayı hangi sunucunun karşıladığını gösterir.
NS kaydı alan adını hangi ad sunucularının yönettiğini söyler. TXT kaydı serbest metindir ve zamanla bilgi biriktirir. Posta gönderim politikası (SPF) ve bulut hizmetlerinin doğrulama satırları burada durur.
CNAME kaydı bir adı başka bir ada bağlar. Bu kayıtları dig komutuyla sorarsın. Biçim dig TİP alanadı şeklindedir. +short seçeneği yalnız cevabı yazar, ayrıntıyı atar.
$ dig +short NS hedef.example ns1.dnssaglayici.example. ns2.dnssaglayici.example. $ dig +short MX hedef.example 10 mail.hedef.example. 20 yedek.bulutposta.example. $ dig +short TXT hedef.example "v=spf1 include:_spf.bulutposta.example ~all" "bulutdepo-dogrulama=7f3a9c21e4" $ dig +short A vpn.hedef.example 203.0.113.25
Çıktıyı satır satır oku. NS kayıtları, alanın dışarıdaki bir DNS sağlayıcısında yönetildiğini söyler. MX kayıtlarındaki sayı önceliktir; küçük sayı önce denenir.
Birinci posta sunucusu şirketin kendisinde, yedeği bir bulut posta hizmetinde duruyor. TXT kaydındaki SPF satırı, şirket adına posta gönderebilecek sunucuları sayar ve aynı bulut hizmetini tekrar gösterir.
İkinci TXT satırı bir bulut depolama hizmetinin alan doğrulamasıdır. Son komut VPN kapısının adresini verir. Dört komutla şirketin posta yığınını, bulut sağlayıcısını ve uzaktan erişim kapısını öğrendin.
Burada sık bir karışıklık var: dig sorgusu hedefe gidiyor mu? Sorgun önce kendi çözücüne gider. Yanıt çözücünün önbelleğindeyse hedefe hiçbir paket ulaşmaz.
Önbellekte yoksa çözücü, alanın yetkili ad sunucusuna sorar. O sunucu çoğu zaman bir DNS sağlayıcısındadır ve senin adresini değil, çözücünün adresini görür. Bu yüzden sıradan DNS sorgusu pasif sayılır.
Yetkili sunucuya doğrudan binlerce aday ad sormak ise aktiftir. Bölge aktarımı (AXFR) istemek de öyledir. Bu iki iş, yetkili sunucunun loglarına senin adresinle düşer.
Etkinlik 3 / 7
hedef.example alan adının posta sunucusu kayıtlarını dig ile sor.
Whois ve RDAP: alan adının kimliği
Whois kaydı alan adının tescil bilgisini yazar: kayıt şirketi, kayıt tarihi, bitiş tarihi ve ad sunucuları. RFC 3912 bu protokolü 43 numaralı TCP portunda tanımlar. Protokol çok basittir: bir satır sorgu gider, düz metin cevap döner. Kayıt sahibinin adı ve telefonu eskiden açıktaydı.
Bugün kişisel veri koruma kuralları yüzünden çoğu kayıtta gizlenir. Yine de tarihler açıkta kalır ve tarih tek başına güçlü bir ipucudur. Dün alınmış bir alan adı çoğu zaman oltalama kokar.
$ whois hedef.example Domain Name: HEDEF.EXAMPLE Registrar: Ornek Kayit Hizmetleri Creation Date: 2011-04-12T09:14:03Z Registry Expiry Date: 2027-04-12T09:14:03Z Name Server: NS1.DNSSAGLAYICI.EXAMPLE Registrant Organization: REDACTED FOR PRIVACY
Whois'in yerini artık RDAP alıyor (Registration Data Access Protocol). ICANN'a göre 28 Ocak 2025'ten beri genel üst düzey alanların çoğunda kayıt işletmecileri ve kayıt şirketleri whois sunmak zorunda değil. RDAP ise bütün genel üst düzey alanlarda zorunludur. RDAP HTTPS üzerinden çalışır ve cevabı JSON biçiminde verir.
Sorgu biçimini RFC 9082, cevap biçimini RFC 9083 tanımlar. Hangi alanın hangi RDAP sunucusunda durduğunu IANA'nın yayımladığı önyükleme (bootstrap) dosyası söyler. Ülke kodlu alanlar ise kendi kayıt kurallarına bağlıdır.
$ curl -s https://rdap.kayit.example/domain/hedef.example | jq '.events'
[
{ "eventAction": "registration", "eventDate": "2011-04-12T09:14:03Z" },
{ "eventAction": "expiration", "eventDate": "2027-04-12T09:14:03Z" },
{ "eventAction": "last changed", "eventDate": "2026-03-02T11:40:55Z" }
]jq '.events' komutu JSON cevabından yalnız olaylar dizisini süzer. registration ilk kayıt tarihidir, expiration bitiş tarihi, last changed ise son değişikliktir. On beş yıllık bir alan adı yerleşik bir şirketi gösterir. Dün alınmış ve hedefin adına benzeyen bir alan adı ise şüphe uyandırır.
Savunan ekip bu yüzden kendi markasına benzeyen yeni kayıtları izler. Son değişiklik tarihi de işe yarar. Ad sunucuları yakın zamanda değiştiyse şirket altyapısını taşıyor olabilir. Taşıma dönemleri, unutulmuş kayıtların en çok biriktiği dönemlerdir.
Derinleş:Whois'ten RDAP'a kısa tarihçe
Whois bugünkü internetten bile eskidir. İlk tanımı 1982 tarihli RFC 812'de NICNAME/WHOIS adıyla geçer. O gün amaç, ARPANET kullanıcılarına bir rehber hizmeti sunmaktı. 2004'te yayımlanan RFC 3912 protokolü güncelledi ama özünü değiştirmedi.
Whois'in üç büyük sorunu vardı. Cevabın ortak bir biçimi yoktu, her kayıt şirketi kendi düz metnini yazıyordu. Kimlik doğrulama yoktu, herkes her şeyi aynı ölçüde görüyordu. ç, ğ, ş gibi ASCII dışı karakterleri de düzgün taşımıyordu.
IETF bu sorunlar için RDAP'ı geliştirdi. İlk RDAP belgeleri 2015'te yayımlandı. Bugünkü sorgu ve cevap biçimleri 2021'de RFC 9082 ve RFC 9083 ile yenilendi.
RDAP'ta cevap yapısaldır ve erişim katmanlı olabilir: yetkili bir kullanıcı gizli alanları görürken herkese açık sorgu yalnız temel bilgiyi alır. Otomatik keşif araçları bu yüzden RDAP'a geçiyor. Yapısal cevabı jq gibi bir araçla tek satırda süzebilirsin.
Etkinlik 4 / 7
Alan adının sahibini ve kayıt tarihini veren açık kayıt: ____
Etkinlik 5 / 7
Şirketinin adına benzeyen bir alan adının RDAP çıktısı aşağıda. Bugün 28 Eylül 2026. En makul yorum hangisi?
Önce kodu oku, sonra çıktıyı seç.
{
"ldhName": "hedef-destek.example",
"events": [
{ "eventAction": "registration", "eventDate": "2026-09-26T22:41:07Z" },
{ "eventAction": "expiration", "eventDate": "2027-09-26T22:41:07Z" }
]
}Sertifika kütükleri ve alt alanlar
Alt alan adı keşfi ayrı bir iştir. Ana site sıkı olabilir. Ama unutulmuş bir test ortamı eski sürümle açık durur. Burada en verimli pasif kaynak sertifika şeffaflık kütükleridir.
RFC 6962 her TLS sertifikasının herkese açık ve yalnız ekleme yapılabilen bir kütüğe yazılmasını tanımlar. Chrome, herkese açık güvenilen TLS sertifikalarının bu kütüklerde kayıtlı olmasını ister ve kayıtsız sertifikayı kabul etmez. Bu yüzden bir şirketin aldığı neredeyse her sertifika, içindeki adlarla birlikte açıkta durur.
Önceki derste crt.sh ile alt alan listesi çıkarmıştın. O sorgu hedefe dokunmaz, çünkü istek crt.sh'a gider. Sık yapılan hata, bu işi aktif tarama sanmaktır.
Ölçü yine aynıdır: paket hedefe ulaşmıyorsa iş pasiftir. Kütüğün iki sınırı var. Joker sertifika, yani *.hedef.example gibi bir kayıt, altındaki adları gizler.
İç ağda yalnız kurumun kendi sertifika otoritesiyle imzalanan adlar da kütüğe hiç düşmez. Listeyi bu yüzden eksiksiz sanma. Kütükten çıkan adı DNS ile doğrula, çözülmeyen adı ayrı bir sütunda tut.
$ dig +short CAA hedef.example 0 issue "ornekca.example" 0 iodef "mailto:[email protected]"
Savunan taraf aynı kütükleri ters yönde kullanır. Kendi alan adın için kesilen her yeni sertifikayı izlersen, tanımadığın bir sertifikayı gün içinde fark edersin. Bu bazen gölge BT'dir, bazen de senin adına sertifika almaya çalışan biridir.
İkinci savunma CAA kaydıdır. RFC 8659'da tanımlı bu DNS kaydı, alanın için hangi sertifika otoritesinin sertifika kesebileceğini söyler.
Yukarıdaki örnekte issue satırı yalnız tek bir otoriteyi yetkili sayar. iodef satırı ise kurala aykırı bir istek gelirse bildirimin nereye gideceğini yazar. Üçüncü savunma, sahipsiz kalan DNS kayıtlarını düzenli taramaktır.
Derinleş:Sertifika şeffaflığı neden doğdu
Sertifika şeffaflığı bir krizden doğdu. 2011'de Avrupa'daki bir sertifika otoritesi ele geçirildi. Saldırganlar, çok kullanılan alan adları için sahte ama tarayıcıların güvendiği sertifikalar üretti. Bu sertifikalar bir süre fark edilmeden kullanıldı.
Sorun şuydu: bir otoritenin kimin adına sertifika kestiğini kimse dışarıdan göremiyordu. Google mühendislerinin önerdiği çözüm basitti. Her sertifika herkese açık bir kütüğe yazılacak, kütük de geriye dönük değiştirilemeyecekti. Kütük, Merkle ağacı adlı bir yapı kullanır.
Ağacın kökündeki özet, bütün kayıtların özetlerinden hesaplanır. Kütük büyüdükçe eski ağacın yenisinin içinde aynen durduğunu kanıtlayabilir. Bir kaydı sonradan silmek ya da değiştirmek bu yüzden fark edilir. Kütük, sertifikayı aldığında imzalı bir zaman damgası (Signed Certificate Timestamp, SCT) verir.
Tarayıcı bu damgayı görmek ister. RFC 6962 bu düzeni 2013'te tanımladı. 2021'de yayımlanan RFC 9162 ise protokolün 2.0 sürümünü getirdi.
Etkinlik 6 / 7
Bir güvenlik ekibi, şirketin kendi unutulmuş alt alan adlarını saldırgandan önce bulmak istiyor. Hangi pasif kaynak en verimlisidir?
Aktif keşfe geçiş ve bıraktığın iz
Pasif kaynaklar tükenince aktif keşfe geçilir. MITRE bu aşamayı T1595 (Active Scanning) olarak listeler ve üç alt teknik sayar. IP bloklarını taramak hangi adreslerin canlı olduğunu bulur.
Zafiyet taramak açık servislerin sürümünü ve bilinen açıklarını yoklar. Kelime listesiyle taramak ise yaygın dizin ve dosya adlarını tek tek dener. Üçünde de hedefe paket gider.
Aktif taramayı yalnız kendi lab ortamında ya da yazılı iznin olan hedefte yap. Aktif keşifte ölçü hızdır. Saniyede yüzlerce istek atarsan güvenlik duvarı seni hemen görür. Yavaş tarama izini küçültür ama silmez.
203.0.113.14 - - [28/Sep/2026:03:11:58 +0300] "GET /urunler HTTP/1.1" 200 8812 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" 198.51.100.77 - - [28/Sep/2026:03:12:04 +0300] "GET /.env HTTP/1.1" 404 153 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)" 198.51.100.77 - - [28/Sep/2026:03:12:04 +0300] "GET /admin/ HTTP/1.1" 404 153 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)" 198.51.100.77 - - [28/Sep/2026:03:12:05 +0300] "GET /.git/HEAD HTTP/1.1" 404 153 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)" 198.51.100.77 - - [28/Sep/2026:03:12:05 +0300] "GET /yedek.zip HTTP/1.1" 404 153 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)"
Kaydı satır satır oku. İlk satır sıradan bir ziyaretçidir: var olan bir sayfa ve 200 cevabı. Sonraki dört satır aynı adresten, iki saniye içinde gelir.
Hepsi var olmayan yolları sorar ve 404 alır. /.env ortam dosyasını, /.git/HEAD unutulmuş kod deposunu, yedek.zip ise açıkta kalmış bir yedeği arar. İstemci kimliği (User-Agent) alanında Nmap Scripting Engine yazar.
Nmap'in betik motoru varsayılan olarak kendini böyle tanıtır. Saat 03.12, trafiğin en sakin olduğu andır. Bu satırlar bir tarama aracının bıraktığı klasik parmak izidir.
Savunan taraf bu deseni kurala çevirir. Aynı adresten kısa sürede gelen çok sayıda 404 yanıtı bir uyarıdır.
Bilinen tarama araçlarının istemci kimlikleri ikinci bir işarettir, ama saldırgan bu alanı kolayca değiştirir. Bu yüzden desene bakmak, kimliğe bakmaktan daha güvenilirdir. Keşif yapan taraf için ders ise sıralamadır.
Önce pasif kaynakları tüket, sonra aktife geç. Böylece hedefe dokunduğunda ne aradığını bilirsin. Körlemesine tarama hem yavaştır hem yüksek sesle bağırır. Bulduğun her adı, adresi ve sürümü tek dosyada topla; rapor yazarken bu dosya işini yarı yarıya kısaltır.
Etkinlik 7 / 7
Yoğun bir saatte alınmış web sunucusu kaydında aktif taramaya ait satırları işaretle.
Şüpheli satırlara tıkla. Birden fazla olabilir.
Okumayı istediğin sırayla sürdürebilirsin. Ders, bütün etkinlikleri cevapladığında tamamlanır.