Series · 5 partsExternal Perimeter IntelligencePart 1 · You are here
- 1Dış Çevre İstihbarat Grafiği: Varlık İlişkilerini HaritalandırmakYou are here
- 2Domain Sahipliği ve Varlık Atıf Kanıtı: Dış Yüzeyde Yanılgılar
- 3Üretici Kapsam Dışıydı. Güven Sınırı Değildi: 3. Taraf Entegrasyonları
- 4Servis Gözlemlendi. Uygulama Hâlâ Bilinmiyordu: Dış Keşif
- 5Giriş Sayfası Kamusaldı. Kimlik Sınırı Başka Bir Yerdeydi
60 saniyede dış çevre istihbaratı
Harici bir penetrasyon testi eskiden bir IP aralığı ve bir port tarayıcı ile başlardı. Bu yaklaşım hâlâ dinleyen servisleri bulur, ancak artık kurumun dış çevresini (perimeter) tarif etmeye yetmez. Aynı organizasyon bölgesel domain’leri, satın alınan markaları, bulut uç noktalarını, kimlik sağlayıcı (identity tenant) yapılarını, mobil backend’leri, destek portallarını, API gateway’leri, unutulmuş migrasyon sunucularını ve üçüncü taraf SaaS entegrasyonlarını aynı anda yönetiyor olabilir. Bunların birkaçı tek bir IP adresini paylaşabilir. Bir hostname tek bir gün içinde servis sağlayıcılar arasında taşınabilir. Bu nedenle operasyonel açıdan asıl anlamlı birim tek başına port değildir; varlıklar arasındaki ilişkidir.
Dolayısıyla modern sızma testi iş akışı her şeyi tara ve yanıt veren ne varsa kurcala şeklinde işlemez:
organizasyonu anlayın, sahipliği ilişkilendirilmiş adaylar oluşturun, bunların güven ilişkilerini modelleyin ve yalnızca ilgili, kapsam dahilinde ve test etmeye değer olanları aktif olarak doğrulayın.
Port taraması ölmedi. Sadece görevi değişti: Kapsamlı bir keşif aracı olmaktan çıkıp, hedefli bir doğrulama aracına dönüştü.
İstihbarat altyapıdan önce gelir
Harici bir testte ilk soru “hangi port açık?” değildir. Asıl soru “şu anda gerçekte hangi organizasyona bakıyorum?” olmalıdır.
Bir şirket ismi nadiren tek bir teknik sınırdan ibarettir. Bir çatı şirket (parent entity), bölgesel tüzel kişilikler, iştirakler, ürün markaları, satın alınmış şirketler, ortak girişimler ve yeniden markalaşma (rebrand) sonrasında elde tutulan eski domain’ler bulunabilir. Kamuya açık yıllık faaliyet raporları, yatırımcı sunumları, yasal bildirimler, şirket satın alma (M&A) duyuruları, basın bültenleri, gizlilik politikaları ve organizasyonun kendi yasal sayfaları, altyapıya tek bir paket dahi gönderilmeden önce bu yapıyı gözler önüne serer.
Bu bir finansal spekülasyon değildir. Düşen bir hisse senedi fiyatı zayıf bir yama yönetimini kanıtlamaz; bir işten çıkarma dalgası da savunmasız bir sunucunun varlığını ispatlamaz. Kurumsal olaylar, test edilebilir varlık hipotezleri ürettikleri için değerlidir. Bir satın alma yeni bir migrasyon sınırı doğurur. Bir şirket elden çıkarma (divestiture) mülkiyet değişikliği yaratır. Yeniden markalaşma arkasında unutulmuş eski domain’ler bırakır. Yeni bir bulut ortaklığı yeni bir güven ilişkisi kurar. Yaşanan kurumsal olay bir tohumdur; teknik kanıtlar ise bu tohumun saldırı yüzeyi haritasına ait olup olmadığına karar verir.
| İstihbarat sorusu | Üretebileceği aday varlık | Hâlâ kanıt gerektiren noktalar |
|---|---|---|
| Ana şirket hangi şirketleri ve markaları kontrol ediyor? | Ek kök domain’ler ve ürün portalları | Mevcut sahiplik, teknik entegrasyon, yazılı kapsam onayı |
| Hangi işletmeler satın alındı veya tasfiye edildi? | Eski kimlik, DNS, e-posta ve uygulama sınırları | Eski ortamın hâlâ ana şirkete bağlı olup olmadığı |
| Hangi bölgeler ve regülasyona tabi servisler mevcut? | Ülke domain’leri, müşteri portalları, ayrılmış veri akışları | Bunların aynı tüzel ve teknik yapı tarafından işletilip işletilmediği |
| Kimlik, ödeme, destek veya telemetriyi hangi sağlayıcılar işliyor? | SaaS ve webhook güven sınırları | Tam entegrasyon biçimi ve sağlayıcının kendisinin test edilebilirliği |
| Hangi açık kaynak depolar, dokümantasyonlar ve mobil uygulamalar var? | API host’ları, paket adları, callback domain’leri, ortam etiketleri | Her gözlemin güncel ve kapsam dahilinde olup olmadığı |
Buradaki disiplin, bireyler hakkında dosya toplamak değil, organizasyon düzeyinde teknik sinyaller yakalamaktır. Rol unvanları, açık ekip sorumlulukları ve resmi e-posta adlandırma kuralları kimlik sınırını anlamlandırmaya yardımcı olabilir. Ancak kişisel telefon numaraları, özel hesaplar, sızdırılmış kimlik bilgisi (credential dump) listeleri ve çalışan hedefleme, yetkilendirilmiş ayrı bir sosyal mühendislik çalışması açıkça talep etmedikçe normal bir altyapı değerlendirmesine ait değildir.
Dış çevrenin birbirine bağlı yedi katmanı
Bu yedi katman birbirinden farklı soruları yanıtlar:
- Kurumsal kimlik: Çatı şirket, iştirak, satın alma, ürün, bölge ve marka.
- Adlandırma (Naming): Kök domain’ler, DNS kayıtları, sertifika isimleri ve geçmiş kayıtlar.
- Yönlendirme (Routing): Tescilli ağlar, anons edilen prefiksler, hosting sağlayıcıları ve CDN edge noktaları.
- Servisler: Gözlemlenen portlar, gerçek protokoller, banner bilgileri, TLS özellikleri ve gözlem zamanı.
- Uygulamalar: Web varlıkları, API’ler, mobil backend’ler, yönetim panelleri ve iş akışları.
- Güven sistemleri: SSO, e-posta, ödeme, destek, analitik, webhook’lar ve veri işleyiciler.
- Tarihsel değişim: Gözlemler arasında neyin ortaya çıktığı, kaybolduğu, taşındığı veya çözümlenmeyi bıraktığı.
Hiçbir kaynak bu yedi katmanın tamamını tek başına kanıtlayamaz. Bir sertifikada yer alan isim mülkiyeti ispatlamaz. Bir IP tescili mevcut yönlendirmenin öyle olduğunu göstermez. Bir CNAME kaydı arkasındaki servis sağlayıcıyı test etme izni vermez. Bir banner doğrulanmış bir ürün sürümü değildir. Çizge (graph), tam da her kenarın (edge) kendisini neyin desteklediğini ve neyin belirsiz kaldığını açıkça kaydetmesi sayesinde işlevsel hale gelir.
Domain yığını değil, bir sahiplik grafiği inşa edin
Doğrulanmış kök domain’lerle başlayın. Her aday kök için var olma kurumsal gerekçesini not edin: resmi marka, bölgesel site, iştirak, satın alınan ürün, yönlendirme (redirect) veya bilinmeyen. Ardından bu ilişkiyi bağımsız sinyallerle test edin.
ICANN’in RDAP servisi, domain ve internet numara kaynakları için yapılandırılmış güncel tescil verileri sağlar. Eski WHOIS sistemine göre makine tarafından okunabilir çok daha iyi bir başlangıç noktasıdır; ancak gizlilik maskelemeleri (privacy redaction) ve kayıt kuruluşu farklılıkları nedeniyle şirket adının bulunamaması hiçbir şeyi kanıtlamaz. Tescil kaydı grafikte sadece bir kenardır, nihai hüküm değildir.
Certificate Transparency (CT) kayıtları, düzenlenen sertifikaların yalnızca ekleme yapılabilen (append-only) kamuya açık defterleridir. Kamusal bir site haritasında (sitemap) hiç yer almamış isimleri, bölgesel sunucuları, ürün ortamlarını ve eski migrasyon sınırlarını ortaya çıkarmada mükemmeldir. Bu loglar, o ismi içeren bir sertifikanın kayıtlara geçtiğini kanıtlar. Ancak host’un hâlâ çözümlendiğini, sertifikanın gerçekten dağıtıldığını veya ana şirketin hâlâ ona sahip olduğunu kanıtlamaz.
Ağ ilişkileri için RIPEstat, IP alanları ve ASN’ler için tescil ve yönlendirme bilgilerini bir araya getirir. Bu, şirketin anons ettiği bir prefiks ile bir bulut veya CDN adresini birbirinden ayırmaya yardımcı olur. Yine bu ayrım kritiktir: Bir CDN tarafından sunulan bir adres, dağıtım altyapısının kanıtıdır; tüm CDN IP aralığının penetrasyon testi kapsamına girdiğinin kanıtı değildir.
Kullanışlı bir sahiplik kaydı şu alanları içerir:
| Alan | Örnek anlamı |
|---|---|
candidate | Gözlemlenen domain, hostname, prefiks, tenant, uygulama veya entegrasyon |
relationship | Ana marka, satın alma, DNS hedefi, paylaşımlı sertifika, kimlik sağlayıcı veya bilinmeyen |
source | Resmi yasal bildirim, RDAP, DNS, CT, yönlendirme verisi, servis gözlemi veya uygulama kanıtı |
observed_at | Kaynağın bu gerçeği gerçekten gözlemlediği an — analistin kopyaladığı an değil |
ownership_confidence | Doğrulanmış (confirmed), muhtemel (probable), olası (possible), çelişkili (contradicted) |
scope_state | Kapsam dahilinde, kapsam dışı, yazılı karar gerekiyor |
current_validation | Test penceresi içinde bağımsız olarak nelerin kontrol edildiği |
next_question | Adayı doğrulamak veya reddetmek için gereken en küçük somut olgu |
Bu model, keşif aşamasındaki en maliyetli hatayı engeller: İki farklı aracın aynı dizeyi döndürmesi yüzünden, akla yatkın görünen bir eşleşmeyi sırf bu yüzden güvenilir bir hedefe dönüştürmek.
Organizasyonun dış güven sağlayıcılarını haritalandırın
Modern şirketler, doğacak sonuçları devretmeksizin çevrelerinin belirli parçalarını dış kaynaklara (third-party) devrederler. DNS ve uygulama kanıtları kimlik sağlayıcıları, müşteri destek platformlarını, ödeme servislerini, e-posta dağıtım altyapılarını, analitik sistemlerini, nesne depolama alanlarını, CDN’leri, izleme araçlarını ve webhook tüketicilerini açığa çıkarabilir.
Buradaki faydalı soru “hangi tedarikçiler mevcut?” değildir. Asıl soru “bu sınırı hangi yetki aşıyor?” olmalıdır.
| Üçüncü taraf rolü | Haritalanacak ilişki | Pentest sorusu |
|---|---|---|
| Kimlik sağlayıcı | Yönlendirmeler, issuer, tenant, claim’ler, oturum devri | Kimlik doğrulama nerede uygulama yetkisine dönüştürülüyor? |
| Ödeme veya olay işleyici | Webhook hedefi, imza, replay durumu | Hangi servis olaya güveniyor ve kaynak nasıl doğrulanıyor? |
| Destek platformu | Özel domain, SSO, hesap verileri | Destek kimliği ana hesap modeline geçiş yapabiliyor mu? |
| Depolama veya CDN | CNAME, origin, yükleme ve dağıtım yolu | İsimlendirme, içerik ve önbellek davranışını hangi taraf yönetiyor? |
| İzleme ve analitik | İstemci SDK’sı, proje tanıtıcısı, gönderilen veri | Uygulamadan hangi veriler çıkıyor ve konfigürasyon davranışı değiştirebilir mi? |
Üçüncü taraf olması, otomatik olarak kapsam dahilinde olduğu anlamına gelmez. Bu ilişkinin mimaride yer aldığı anlamına gelir. Sağlayıcının altyapısı açıkça kapsam dışı kalırken; organizasyonun konfigürasyonu, callback yapılandırması, özel domain’i veya güven kararı test edilebilir olabilir. Bu ayrım test planının sonuna kadar korunmalıdır.
Censys aktif taramanın başladığı yeri değiştirir
Censys, pentester bakış açısından sıklıkla pasif bir tarayıcı olarak adlandırılır. Bu kısaltma önemli bir gerçeği gizler: Censys kamuya açık interneti aktif olarak tarar; analist ise ortaya çıkan haritayı pasif olarak sorgular. Dokümantasyonu sürekli IPv4 keşfini, 65.535 portun tamamında taramayı, otomatik protokol tespitini, çoklu perspektifleri ve bilinen servislerin planlı olarak yenilenmesini tarif eder. Dolayısıyla bir sonuç IP:port ikilisinden çok daha fazlasını sunabilir: gözlemlenen protokol, TLS materyali, HTTP davranışı, yazılım ipuçları, DNS isimleri, yönlendirme bağlamı ve bir gözlem zaman damgası.
Bu durum Censys’i mükemmel bir aday üreticiye dönüştürür:
- Her adresi bizzat taramak zorunda kalmadan standart dışı bir portta SSH veya HTTP tespit etmek;
- Bir sertifika ismini servis gözlemiyle ilişkilendirmek;
- Yanıt veren gerçek protokolü, normalde o porta atanmış protokolden ayırt etmek;
- Mevcut ve geçmişteki açıklığı karşılaştırmak;
- Uzaktan erişim, kimlik, yönetim, veritabanı ve dosya paylaşım yüzeylerini önceliklendirmek;
- Güncel durum doğrulamasına değecek en dar varlık kümesini belirlemek.
Ancak bu mutlak gerçek (ground truth) değildir. Censys; yakın zamanda açık servis göstermeyen host’ların, engelleme listelerindeki host’ların ve kendi tarayıcılarını engelleyen sistemlerin aramada yer almayabileceğini belirtir. Bulut servisleri değişir, anycast ve coğrafi politikalar perspektifi farklılaştırır ve bir banner bir zamanlar tanımladığı canlı ortamdan daha uzun süre kayıtlarda kalabilir. Her kaydın bir observed_at değerine ihtiyacı vardır ve her kritik çıkarım taze bir doğrulamayı zorunlu kılar.
Geniş bir port listesi neden zayıf bir kanıttır?
Güvenlik kontrolleri yalnızca yanlış pozitifler (false positive) üretmez. Çoğu zaman belirsiz ve bakış açısına bağımlı gözlemler üretir.
Nmap projesi; open, closed, filtered, unfiltered, open|filtered ve closed|filtered durumlarını, Nmap’in tek bir tarayıcıya dönen paketlerden çıkarabileceği sonuçlar olarak tanımlar. Aynı port bir ağdan açık, diğerinden filtrelenmiş görünebilir. Sessiz güvenlik duvarı düşürmeleri (silent drops), paket kayıpları, ICMP veya RST hız sınırları, sahte yanıtlar, proxy’ler ve coğrafi politikaların tümü bu tabloyu değiştirir.
İçinde 60.000 filtrelenmiş port bulunan bir raporun neredeyse hiçbir şey anlatmamasının nedeni budur. Yalnızca belirli bir sondanın (probe) kesin bir yanıt üretmediğini kaydeder. Buna karşılık, standart dışı bir portta doğru hostname ve sertifikayla ilişkilendirilmiş protokol düzeyinde tek bir gözlem, test planını kökten değiştirebilir.
Verimli iş sırası şöyledir:
- Aday üretmek için kurumsal, adlandırma, yönlendirme, sertifika ve geçmiş istihbaratını kullanın.
- Paylaşımlı hosting’leri, CDN edge noktalarını, park edilmiş isimleri, wildcard DNS kayıtlarını ve çelişkili sahiplikleri ayıklayın.
- Satın almalar, iştirakler ve üçüncü taraflar için yazılı kapsam kararı alın.
- Onaylanmış test perspektifinden en küçük aday kümesini doğrulayın.
- Zafiyet testine geçmeden önce doğrulanmış servislerin arkasındaki uygulamaları haritalandırın.
Servisten uygulama modeline geçiş
Keşif bize nerede olduğunu söyler. Uygulama haritalama ise yetkinin nasıl hareket ettiğini gösterir.
Aynı IP üzerindeki iki hostname tamamen ilgisiz uygulamalar olabilir. Farklı bulutlardaki iki uygulama aynı kimlik sağlayıcısını paylaşabilir. Bir pazarlama sitesi JavaScript üzerinden bir prodüksiyon API’sini çağırabilir. Bir mobil uygulama, kamuya açık web sitesinde bulunmayan bir backend adını kullanabilir. Bir yönetim arayüzü, müşteri portalı ile aynı edge noktasının arkasında yer alırken tamamen farklı bir rol modeli uygulayabilir.
OWASP Web Security Testing Guide, saldırı yüzeyi tanımlamasını; uygulamaları, domain’leri, sanal host’ları, açık servisleri, DNS’i, standart dışı portları ve sertifika verilerini keşfetmek olarak tanımlar. Bu envanter nihai amaç değil, girdidir.
Doğrulanan her uygulama için sınır sınıflandırması yapın:
APP-0— temel iş uygulaması;APP-1— kimlik doğrulama ve kimlik yönetimi;APP-2— yönetim ve operasyonel yönetim;APP-3— API, BFF, webhook veya backend servisi;APP-X— üçüncü tarafça işletilen uygulama veya entegrasyon.
Ardından giriş noktalarını, kimlik doğrulama mekanizmasını, rolleri, token’ları ve oturumları, API ailelerini, veri akışlarını ve kritik iş akışı durumlarını kaydedin. Bu model olmadan zafiyet keşfi yapmak, çoğunlukla rastgele payload göndermekten ibarettir. Hangi güven kararının test edilmeye değer olduğunu bize bu model söyler.
Kurgusal bir senaryo: Bir şirket, dört sınır
Yetkilendirilmiş başlangıç çekirdeğinin northstar.example olduğunu varsayalım. Henüz hiçbir tarama başlatılmadı.
- Resmi bir şirket birleşme/satın alma duyurusu, Northstar’ın iki yıl önce “Harbor Metrics”i satın aldığını belirtiyor. Bu kurumsal bir aday üretir, henüz bir hedef değil.
- Bir CT kaydı
auth.harbor.exampleadresini içeriyor. Canlı DNS bunu bir SaaS kimlik platformuna çözümlüyor. Bu bir ismi ve mevcut DNS ilişkisini kanıtlar; SaaS sağlayıcısının mülkiyetini kanıtlamaz. - Censys, geçmişte Harbor ile bağlantılı bir adres için
8443portunda en son HTTPS gözlemlemiş. Sertifika aynı zamanda bir Northstar ürün hostname’ini de içeriyor. Bu güven derecesini artırır ve dar bir servis adayı oluşturur. - Yazılı kapsam Harbor uygulamasını onaylıyor ancak altyapı sağlayıcısını hariç tutuyor. Hostname ve SNI kullanılarak yapılan güncel bir TLS ve HTTP kontrolü,
8443üzerinde bir giriş uygulamasını doğrular. - Uygulama haritalaması, Harbor giriş sisteminin Northstar API’si tarafından kabul edilen bir token ürettiğini gösteriyor. Artık bulgu hipotezi “8443 portu açık” değildir. Yeni hipotez şudur: “Sonradan devralınan bir kimlik sınırı, ana uygulamada yetki sağlayabilir.”
Port önemliydi. Ancak sadece kurumsal geçmiş, CT, DNS, servis istihbaratı, sahiplik, kapsam ve uygulama güven ilişkileri onu savunulabilir bir test senaryosuna dönüştürdükten sonra önem kazandı.
Değişim, dış çevrenin bir parçasıdır
Pasif bir kaynağın ilk kez bir hostname döndürmesi, bunun otomatik olarak yeni bir varlık olduğu anlamına gelmez. Bu yeni bir gözlemdir. Kullanışlı bir değişim hattı önce DNS’i doğrular, yalnızca wildcard içeren yanıtları eler, güncel HTTP/TLS/servis kanıtlarını kaydeder ve ardından kalıcı hale getirilmiş iki durumu karşılaştırır.
En azından şunları saklayın:
- İlk ve son gözlem zamanı;
- Önceki ve mevcut DNS durumu;
- Sertifika ve servis gözlem zamanı;
- Kaynak ve veri toplama tanımlayıcısı;
- Sahiplik ve kapsam kararı;
- Analistin bu değişimi kabul veya reddetme gerekçesi.
Varlıkların ortadan kaybolması da önemlidir. Çözümlenmeyi bırakan bir hostname; kasıtlı bir devreden çıkarma, bir migrasyon, askıda kalmış bir bağımlılık (dangling dependency) ya da geçici bir DNS arızasından başka bir şey olmayabilir. Kanıtın eksik olması zafiyetin giderildiğini asla kanıtlamaz ve bir bulguyu hiçbir zaman otomatik olarak kapatmamalıdır.
Kanıt matrisi
| Sinyal | Neyi kanıtlar | Neyi kanıtlamaz | Bağımsız doğrulama |
|---|---|---|---|
| Resmi bildirim veya satın alma duyurusu iki şirketi bağlar | Belirtilen tarihte kurumsal bir ilişkinin var olduğunu | Mevcut teknik entegrasyonu veya test etme yetkisini | Güncel yasal sahipliği teyit edin ve açık bir kapsam kararı alın |
| RDAP kaydı bir domain veya ağ kaynağını bağlar | Yetkili servis tarafından döndürülen güncel yapılandırılmış tescil verisini | Onu kullanan her host veya uygulamanın operasyonel kontrolünü | DNS, yönlendirme, resmi varlıklar ve müşteri teyidini karşılaştırın |
| CT log’u bir hostname içerir | İsmi içeren bir sertifikanın kamuya açık kayıtlara geçtiğini | Güncel DNS’i, aktif dağıtımı, mülkiyeti veya erişilebilirliği | DNS’i çözümleyin; canlı sertifika ve uygulama kimliğiyle kıyaslayın |
| RIPEstat bir prefiks ve ASN’yi ilişkilendirir | Tescil veya yönlendirme verisinin bir ağ ilişkisini desteklediğini | Prefiks içindeki her adresin teste dahil olduğunu | Şirkete ait prefiksleri sağlayıcılardan, peer’lardan ve CDN’den ayırın |
| Censys bir IP ve portta protokol gözlemlemiştir | Servisin kaydedilen perspektif ve zamanda Censys’e yanıt verdiğini | Hâlâ yayında olduğunu, doğru ilişkilendirildiğini veya kapsamda olduğunu | Onaylı test düzleminden dar kapsamlı güncel bir el sıkışma yapın |
| CNAME veya istemci kodu bir SaaS sağlayıcıyı işaret eder | Bir uygulama veya adlandırma bağımlılığının var olduğunu | Sağlayıcıyı test etme iznini | Yalnızca yetkilendirilmiş konfigürasyonu ve güven sınırını test edin |
| Aktif doğrulama servis ve uygulama kimliğini teyit eder | Aday varlığın şu an test perspektifinden mevcut olduğunu | Bir güvenlik zafiyetinin varlığını | Bir uygulama hipotezi ve pozitif/negatif kontroller oluşturun |
Savunma ekiplerine teslim edilecek çıktılar
Savunuculara bir host listesi içeren bir CSV dosyası verip bunu saldırı yüzeyi haritası olarak adlandırmayın. Birbirine bağlı dört çıktı sunun.
Organizasyon haritası. Çatı şirket, markalar, bölgeler, iştirakler, satın almalar ve çözülmemiş mülkiyet soruları. Bu, müşteriye her bir kök domain’in araştırmaya neden dahil edildiğini açıklar.
İlişkilendirilmiş yüzey envanteri. Domain, DNS, IP/prefiks, servis, sertifika, uygulama, hosting sınıfı, ilk/son görülme, kaynak, güven derecesi ve kapsam durumu. Kanıtlar onları güvenli bir şekilde eşleştirene kadar domain tabanlı ve IP tabanlı gözlemleri birbirinden ayrı tutun.
Güven haritası. Kimlik, API, webhook, veri, ödeme, destek ve dağıtım ilişkileri. Üçüncü taraf düğümleri kapsam dışında olsalar bile görünür kalmalıdır; çünkü organizasyon bu sınırlara bağımlıdır.
Doğrulama kuyruğu. Otomatik bir bulgu listesi değil, önceliklendirilmiş sorular dizisi. Her madde, hipotezi doğrulayacak veya reddedecek en küçük yetkilendirilmiş kontrolü ve durmak için gereken kanıtı belirtir.
Harici keşfin faydalı çıktısı “65.535 portu taradık” demek değildir. Asıl çıktı şudur: “Hangi dış ilişkilerin kritik olduğunu, bunların neden bu kuruluşa ait olduğuna inandığımızı, nelerin değiştiğini, neleri doğruladığımızı ve bir sonraki güven kararının nerede çökebileceğini açıklayabiliyoruz.”
Bu, bir pentester’ın test edebileceği — ve bir savunucunun gerçekten ayakta tutabileceği — bir dış çevredir.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.