Alt alan adı keşfi

www.hedef.example sıkı korunur. api-test.hedef.example genelde kimsenin listesinde değildir. Kurumlar ana siteyi düzenli test eder, yan sistemleri unutur.

Pazarlama ekibinin açtığı bir kampanya alanı, kapanmayı bekleyen bir test ortamı, eski bir sağlayıcıda duran bir kopya. Hepsi ana envanterde görünmez ama dışarıdan erişilir. İşte bu yüzden alt alan keşfi testin en verimli erken adımıdır: en zayıf halkayı genelde en görünmez yerde bulursun.

Alt alan keşfinde üç bağımsız kanal kullanırsın ve her biri farklı bir geçmişe bakar. Sertifika şeffaflık günlüğü, kuruma verilen her sertifikanın taşıdığı adları tutar; bu, TLS kullanan her yeni servisi yakalar. Pasif DNS toplayıcıları ise dünyanın dört bir yanındaki çözücülerin daha önce gördüğü ad-adres eşleşmelerini saklar; bir ad artık çözülmese bile geçmişte çözüldüyse burada durur. Üçüncü kanal, kelime listesiyle kaba kuvvettir: sözlükteki her adı hedef alanın altında dener ve ilk iki kanalın hiç görmediği, hiçbir sertifikası olmayan iç adları bulur.

Kanalları birleştirmek şart, çünkü her biri diğerinin kör noktasını kapatır. Sertifika günlüğü yalnız TLS'li servisleri görür; TLS kullanmayan bir yönetim paneli orada yoktur. Pasif DNS yalnız daha önce sorgulanmış adları bilir; hiç yayımlanmamış bir iç ad kaydı orada olmaz.

Kelime listesi yalnız tahmin ettiğin adları bulur; aklına gelmeyen bir adı kaçırır. Tek araçla çalışan kişi listenin yarısını görür. Farklı kaynakların birleşimi her zaman daha geniş ve daha güvenilir çıkar.

Kanalların bir ekseni de zamandır. Sertifika günlüğü ve pasif DNS geçmişe bakar: aylar önce açılıp kapanmış bir adı bile tutabilir.

Kaba kuvvet ise şimdiye bakar; yalnız bugün çözülen adları bulur. Bu ayrım işine yarar, çünkü geçmişte var olup bugün kaybolan bir ad genelde yarım kalmış bir taşımanın ya da unutulmuş bir projenin izidir. Eski bir adın hâlâ bir yere işaret edip etmediğini kontrol etmek, sonraki dersteki devralma senaryosunun ilk ipucunu verir.

Pratikte bu üç kanalı küçük bir keşif hattına dizersin. subfinder pek çok pasif kaynağı tek komutta tarar. amass ikinci bir bağımsız toplayıcıdır; sürüm 5 ile pasif toplama artık varsayılan davranıştır. Bu yüzden eski '-passive' bayrağı kullanımdan kalktı; düz 'amass enum -d hedef.example' pasif kaynaklardan toplar.

İki aracın çıktısını 'sort -u' ile birleştirip tekrarları atarsın. Son adımda httpx listedeki her adın ayakta olup olmadığını durum kodu ve sayfa başlığıyla gösterir.

$ subfinder -d hedef.example -all -silent -o subfinder.txt
$ amass enum -d hedef.example -o amass.txt
$ cat subfinder.txt amass.txt | sort -u > hepsi.txt
$ httpx -l hepsi.txt -silent -sc -title > canli.txt

Bu hattın çıktısı birbirini tamamlayan iki dosyadır. 'hepsi.txt' ham ve tekilleştirilmiş ad listesidir; içinde ölü kayıtlar da durur. 'canli.txt' ise httpx süzgecinden geçmiş, gerçekten yanıt veren adları taşır.

subfinder ve amass aynı adı sık sık birlikte bulur, bu yüzden 'sort -u' adımı listeyi belirgin biçimde kısaltır. Aynı hattı başka bir hedef alanında da değişmeden çalıştırabilirsin; değişen yalnız hedef alan adı ve sözlük dosyasıdır. Aşağıda canli.txt dosyasının ilk satırları duruyor.

$ head -4 canli.txt
https://www.hedef.example [200] [Hedef Kargo]
https://api.hedef.example [200] [Hedef API]
https://panel.hedef.example [301] [Moved Permanently]
https://test.hedef.example [403] [403 Forbidden]

Çıktıyı satır satır oku. İlk iki satır 200 döner; ikisi de canlı ve doğrudan erişilebilir servistir. 'panel' satırındaki 301 bir yönlendirmedir. Nereye gittiğini ayrıca izlersin, çünkü varış noktası çoğu zaman bir giriş ekranıdır.

'test' satırındaki 403 ise kapının var olduğunu ama kilitli olduğunu söyler; test ortamı olduğu için önceliği yüksektir. Listede hiç görünmeyen bir ad yanıt vermemiştir ve büyük olasılıkla ölü kayıttır. Aynı sayfa başlığıyla dönen yüzlerce ad varsa, karşında çoğu zaman ayrı uygulamalar değil, tek bir ortak karşılama sunucusu durur.

Kaba kuvvet turunun en sinsi tuzağı joker DNS kaydıdır. Kimi alan adı, sorulan ad ne olursa olsun aynı adresi döner. Böyle bir alanda kelime listesiyle üretilen her ad sözde çözülür ve elinde yüzlerce sahte sonuç birikir.

Tuzağı tanımak basittir: var olması imkânsız rastgele bir ad dene. 'asdf-yok-12.hedef.example' bir adrese çözülüyorsa o alanda joker kayıt var demektir ve kaba kuvvet sonuçlarının hepsi anlamsızdır. Bu durumda yalnız sertifika ve pasif DNS kanallarına güvenirsin.

Joker kaydı doğrulamak için birkaç rastgele adı arka arkaya çözersin. Hepsi aynı adrese düşüyorsa joker vardır. Modern toplayıcılar bu filtreyi kendiliğinden uygular, yine de sonucu kendi gözünle denetlemek sahte adların rapora sızmasını önler.

Joker olan bir alanda gerçek adları ayırmanın yolu, dönen içeriği karşılaştırmaktır: joker yanıtı hep aynı sayfayı verir, gerçek bir alt alan farklı bir yanıt üretir. Joker kaydı rapora ayrıca yazarsın. Savunan ekip için de değeri vardır, çünkü joker kayıt yanlış yazılmış her adı canlı bir sunucuya taşır.

Listeyi okurken adlandırma desenine dikkat et. api, api-v2, api-test gibi adlar bir kalıp gösterir.

Kalıbı bulunca kendi kelime listeni türetirsin; dev, staging, uat, eski ve yedek sözcükleri hemen her kurumda karşılığını bulur. Bulduğun adları da sınıflandırmak işi hızlandırır: yönetim, test, eski sürüm ve üçüncü taraf paneli gibi gruplar oluşturursun. Test ortamları genelde daha gevşek yapılandırılır ve ilk bakılacak grup olur.

Liste eline geçince ilk iş kapsam süzgecidir. Toplayıcılar ortak altyapı yüzünden başka kuruma ait adları da getirir. Aynı bulut sağlayıcısının paylaşımlı IP aralığı, hedefle ilgisiz onlarca adı listeye sızdırabilir.

Kapsam dışı bir adrese istek atmak, iyi niyetli olsa bile yetkisiz erişim tartışması doğurur. Bu yüzden her adı kapsam belgesiyle karşılaştırır, emin olmadığın adı müşteriye sorar, tahminle ilerlemezsin. Pratik bir yol, her adın çözüldüğü adresi kapsam belgesindeki IP aralıklarıyla karşılaştırmaktır. Aralığın dışında kalan ad ayrı bir listeye gider ve müşteri onaylamadan ona dokunulmaz.

Listeyi süzdükten sonra özel bir durum aranır: ölü CNAME kaydı. Bir ekip bulut kovasını ya da barındırma hesabını siler, ama DNS'teki CNAME kaydını bırakır.

Kayıt hâlâ o dış adrese işaret eder, dış adres ise artık sahipsizdir. O kaynağı yeniden kaydeden kişi, alt alanda kendi içeriğini yayımlar. MITRE bu tekniği T1584.001 altında ele alır: kuruma ait DNS kaydı var olmayan ya da geri verilmiş bir kaynağa işaret ettiğinde alt alan devralma doğar.

Etkisi küçümsenmez. Devralınan alt alan kurumun adıyla çalışır. Oltalama sayfası oradan yayımlanır ve kurbanlar gerçek bir alt alanda olduklarına inanır. Çerez kapsamı üst alanla paylaşılıyorsa oturum verisi de risk altına girer.

Çözüm basittir: ölü kaydı bölge dosyasından sil. Kaynak silinirken DNS kaydının da silinmesini süreç kuralına bağlamak, bu sınıfı kökten kapatır. Silme sırası da önemlidir: önce DNS kaydı kaldırılır, sonra kaynak silinir. Ters sıra, arada boşta bir kayıt bırakır.

Bu sınıf gerçek programlarda sık ödül kazandırır, çünkü kurumlar bulut kaynaklarını sürekli açıp kapatır ve DNS temizliğini unuturlar. Bir kampanya biter, kova ya da barındırma hesabı silinir, ama DNS kaydı kalır. Saldırgan o kaydı görüp kaynağı yeniden oluşturduğunda kurumun adıyla içerik yayımlar. Bu yüzden varlık envanterini güncel tutmak ve DNS bölgesini boşta kayıtlara karşı düzenli taramak, kırmızı takımın bulacağı açığı önce mavi takıma buldurur.

Devralma şüphesini doğrulamak dikkat ister ve yetkili testte adı kaydetmeye asla varmaz. Önce CNAME hedefinin çözülüp çözülmediğine bakarsın.

Sonra hedef servisin o adı tanıyıp tanımadığını kontrol edersin; sahipsiz bir kova genelde 'NoSuchBucket' benzeri net bir hata sayfası döner. Bu hata metni servise ve duruma göre değişir; can-i-take-over-xyz gibi topluluk listeleri hangi servisin hangi imzayı döndürdüğünü belgeler. Kanıt olarak DNS kaydını ve hata sayfasını ekran görüntüsüyle alırsın; alanı gerçekten kapmak kapsam dışı bir varlık edinmek olur.

Savunan taraf aynı yöntemleri kendi envanteri için kullanır. Kendi sertifika günlüğünü izleyen kurum izinsiz açılmış alt alanı erken görür. DNS bölgesini düzenli tarayıp boşta kalan (dangling) kayıtları ayıklamak, kaynak silme sürecine DNS temizliğini eklemek ve alt alan envanterini güncel tutmak devralma riskini kapatır.

Kimi barındırma servisleri bir adı hesaba bağlamadan önce TXT kaydıyla sahiplik kanıtı ister; bu doğrulamayı açık tutmak devralmayı zorlaştırır. Dışarıdan nasıl göründüğünü bilen kurum, saldırganın bulacağı listeyi ondan önce bulur.

Alt alan sayısı çoğu kurumda beklenenden yüksek çıkar. Orta ölçekli bir şirkette yüzlerce ad görmek olağandır ve bu adların büyük kısmı ölü kayıttır. Ölçek büyüyünce otomasyon şart olur: toplama, süzme ve canlılık kontrolünü tek betikte birleştirir, her koşumun çıktısını tarihli klasöre yazarsın. Böylece iki tarama arasındaki farkı, yani yeni açılan ya da kapanan adları görürsün.

Savunan ekip için en değerli çıktı bu fark listesidir. Envanteri tek kaynaktan beslemek ise saldırgandaki kör noktanın aynısını savunana taşır.