<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Active Directory & Kurumsal]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:40 +0000 MyBB <![CDATA[Unutulan Test Hesapları: PowerShell ile Active Directory'de Pasif Hesap Denetimi]]> https://www.turkteam.org/konu-unutulan-test-hesaplari-powershell-ile-active-directory-de-pasif-hesap-denetimi.html Fri, 23 Oct 2026 11:34:37 +0300 BilgeKagan]]> https://www.turkteam.org/konu-unutulan-test-hesaplari-powershell-ile-active-directory-de-pasif-hesap-denetimi.html [Resim: attachment.php?aid=380]
Selamlar,

İngiltere Bilgi Komisyonluğu (ICO) 20 Ekim 2026'da iki Galli kuruluşa, Ogi Networks Limited (ONL) ve Data Cymru'ya kınama verdi. Kasım 2024'teki fidye yazılımı saldırısında, 12 yıldan uzun süredir var olan "Test2" adlı bir test hesabı kullanıldı. Hesabın parolası baştan beri "Password1" idi ve bir parola gücü aracına göre bir saniyeden kısa sürede kırılabiliyordu. Saldırıda 182,7 GB veri şifrelendi, 42 GB veri çalındı; çoğu çocuk 3.300 kişinin bilgisi etkilendi. Bu konu, aynı hatayı kendi AD ortamınızda nasıl yakalayacağınızı anlatıyor.

Konuda anlatılacaklar
  1. ICO kararından çıkan somut hatalar
  2. Pasif hesapları bulmak
  3. Parolası hiç değişmemiş hesaplar
  4. Test/servis hesabı adlandırma avı
  5. Güvenli devre dışı bırakma süreci

ICO'nun tespitleri
  • Test hesabı Ocak 2012'de "Password1" ile oluşturulmuş, parola karmaşıklığı kuralı uygulanmamış.
  • Hesaplar düzenli denetlenmemiş; gereksiz hesap 12 yıl yaşamış.
  • Üç sistemde yerel yönetici hesapları 12 yıldan uzun süre aynı parolayı korumuş.
  • Data Cymru'nun hesap incelemeleri planlı ve rutin değilmiş, AD'nin tamamını kapsamıyormuş.
  • Dış kaynak sağlayıcı ile kurum arasında sorumluluk ve veri işleme sözleşmesi net değilmiş.

1. Pasif hesapları bulmak
Kod:
Import-Module ActiveDirectory # 90 gundur giris yapmamis, etkin kullanici hesaplari Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly | Where-Object { $_.Enabled } | Select-Object Name,SamAccountName,LastLogonDate,DistinguishedName | Sort-Object LastLogonDate | Export-Csv inactive90.csv -NoTypeInformation -Encoding UTF8 # Hic giris yapmamis ama etkin hesaplar Get-ADUser -Filter { Enabled -eq $true } -Properties LastLogonDate,whenCreated | Where-Object { -not $_.LastLogonDate } | Select Name,SamAccountName,whenCreated
Not: LastLogonDate, lastLogonTimestamp özniteliğinden gelir ve DC'ler arasında varsayılan olarak 9-14 gün gecikmeyle çoğaltılır. Pasiflik tespiti için yeterli, anlık giriş takibi için değil.

2. Parolası yıllardır değişmeyenler
Kod:
$esik = (Get-Date).AddYears(-1) Get-ADUser -Filter { Enabled -eq $true } -Properties PasswordLastSet,PasswordNeverExpires | Where-Object { $_.PasswordLastSet -lt $esik -or $_.PasswordNeverExpires } | Select Name,SamAccountName,PasswordLastSet,PasswordNeverExpires | Sort PasswordLastSet

3. Test ve geçici hesap avı
Kod:
Get-ADUser -Filter { Enabled -eq $true } -Properties Description,LastLogonDate | Where-Object { $_.SamAccountName -match '(?i)test|demo|temp|tmp|vendor|setup' -or $_.Description -match '(?i)test|gecici|deneme' } | Select Name,SamAccountName,Description,LastLogonDate
Yerel yönetici parolaları için Windows LAPS kullanın; her makinede benzersiz ve döndürülen parola, ICO kararındaki "12 yıl aynı yerel admin parolası" sorununu kökten çözer.

4. Güvenli devre dışı bırakma
Hesabı hemen silmeyin. Önerilen süreç:
  1. Sahibini bulun (yönetici, dış kaynak firması). Sahibi yoksa bu zaten bir bulgu.
  2. Devre dışı bırakın, açıklamaya tarih ve talep numarası yazın, ayrı bir "Disabled" OU'ya taşıyın.
  3. 30-90 gün bekleyin; kimse şikayet etmezse silin.
Kod:
Disable-ADAccount -Identity test2 Set-ADUser test2 -Description "Disabled 2026-10-23 - pasif hesap denetimi" Move-ADObject (Get-ADUser test2).DistinguishedName -TargetPath "OU=Disabled,DC=lab,DC=local"

Kalıcı çözüm
ICO'nun önerileriyle uyumlu olarak: zayıf ve yaygın parolaları engelleyen bir parola filtresi (Entra Password Protection gibi), uzaktan erişimde varsayılan MFA, tüm AD'yi kapsayan çeyreklik hesap incelemesi ve dış kaynak sözleşmelerinde hesap yaşam döngüsünün kimde olduğunun yazılı tanımı. Komutları önce lab ortamında deneyin.

Kendi ortamınızda (veya labınızda) bu komutları çalıştırdığınızda kaç pasif hesap çıktı? Rakam paylaşabilirsiniz, isim değil.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   14-b04-ad-pasif-hesap-denetimi.png (Dosya Boyutu: 119.41 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=380]
Selamlar,

İngiltere Bilgi Komisyonluğu (ICO) 20 Ekim 2026'da iki Galli kuruluşa, Ogi Networks Limited (ONL) ve Data Cymru'ya kınama verdi. Kasım 2024'teki fidye yazılımı saldırısında, 12 yıldan uzun süredir var olan "Test2" adlı bir test hesabı kullanıldı. Hesabın parolası baştan beri "Password1" idi ve bir parola gücü aracına göre bir saniyeden kısa sürede kırılabiliyordu. Saldırıda 182,7 GB veri şifrelendi, 42 GB veri çalındı; çoğu çocuk 3.300 kişinin bilgisi etkilendi. Bu konu, aynı hatayı kendi AD ortamınızda nasıl yakalayacağınızı anlatıyor.

Konuda anlatılacaklar
  1. ICO kararından çıkan somut hatalar
  2. Pasif hesapları bulmak
  3. Parolası hiç değişmemiş hesaplar
  4. Test/servis hesabı adlandırma avı
  5. Güvenli devre dışı bırakma süreci

ICO'nun tespitleri
  • Test hesabı Ocak 2012'de "Password1" ile oluşturulmuş, parola karmaşıklığı kuralı uygulanmamış.
  • Hesaplar düzenli denetlenmemiş; gereksiz hesap 12 yıl yaşamış.
  • Üç sistemde yerel yönetici hesapları 12 yıldan uzun süre aynı parolayı korumuş.
  • Data Cymru'nun hesap incelemeleri planlı ve rutin değilmiş, AD'nin tamamını kapsamıyormuş.
  • Dış kaynak sağlayıcı ile kurum arasında sorumluluk ve veri işleme sözleşmesi net değilmiş.

1. Pasif hesapları bulmak
Kod:
Import-Module ActiveDirectory # 90 gundur giris yapmamis, etkin kullanici hesaplari Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly | Where-Object { $_.Enabled } | Select-Object Name,SamAccountName,LastLogonDate,DistinguishedName | Sort-Object LastLogonDate | Export-Csv inactive90.csv -NoTypeInformation -Encoding UTF8 # Hic giris yapmamis ama etkin hesaplar Get-ADUser -Filter { Enabled -eq $true } -Properties LastLogonDate,whenCreated | Where-Object { -not $_.LastLogonDate } | Select Name,SamAccountName,whenCreated
Not: LastLogonDate, lastLogonTimestamp özniteliğinden gelir ve DC'ler arasında varsayılan olarak 9-14 gün gecikmeyle çoğaltılır. Pasiflik tespiti için yeterli, anlık giriş takibi için değil.

2. Parolası yıllardır değişmeyenler
Kod:
$esik = (Get-Date).AddYears(-1) Get-ADUser -Filter { Enabled -eq $true } -Properties PasswordLastSet,PasswordNeverExpires | Where-Object { $_.PasswordLastSet -lt $esik -or $_.PasswordNeverExpires } | Select Name,SamAccountName,PasswordLastSet,PasswordNeverExpires | Sort PasswordLastSet

3. Test ve geçici hesap avı
Kod:
Get-ADUser -Filter { Enabled -eq $true } -Properties Description,LastLogonDate | Where-Object { $_.SamAccountName -match '(?i)test|demo|temp|tmp|vendor|setup' -or $_.Description -match '(?i)test|gecici|deneme' } | Select Name,SamAccountName,Description,LastLogonDate
Yerel yönetici parolaları için Windows LAPS kullanın; her makinede benzersiz ve döndürülen parola, ICO kararındaki "12 yıl aynı yerel admin parolası" sorununu kökten çözer.

4. Güvenli devre dışı bırakma
Hesabı hemen silmeyin. Önerilen süreç:
  1. Sahibini bulun (yönetici, dış kaynak firması). Sahibi yoksa bu zaten bir bulgu.
  2. Devre dışı bırakın, açıklamaya tarih ve talep numarası yazın, ayrı bir "Disabled" OU'ya taşıyın.
  3. 30-90 gün bekleyin; kimse şikayet etmezse silin.
Kod:
Disable-ADAccount -Identity test2 Set-ADUser test2 -Description "Disabled 2026-10-23 - pasif hesap denetimi" Move-ADObject (Get-ADUser test2).DistinguishedName -TargetPath "OU=Disabled,DC=lab,DC=local"

Kalıcı çözüm
ICO'nun önerileriyle uyumlu olarak: zayıf ve yaygın parolaları engelleyen bir parola filtresi (Entra Password Protection gibi), uzaktan erişimde varsayılan MFA, tüm AD'yi kapsayan çeyreklik hesap incelemesi ve dış kaynak sözleşmelerinde hesap yaşam döngüsünün kimde olduğunun yazılı tanımı. Komutları önce lab ortamında deneyin.

Kendi ortamınızda (veya labınızda) bu komutları çalıştırdığınızda kaç pasif hesap çıktı? Rakam paylaşabilirsiniz, isim değil.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   14-b04-ad-pasif-hesap-denetimi.png (Dosya Boyutu: 119.41 KB / İndirme Sayısı: 6) ]]> <![CDATA[BloodHound CE Lab Kurulumu: Docker ile İlk Attack Path Görselleştirme]]> https://www.turkteam.org/konu-bloodhound-ce-lab-kurulumu-docker-ile-ilk-attack-path-gorsellestirme.html Wed, 21 Oct 2026 11:26:08 +0300 BilgeKagan]]> https://www.turkteam.org/konu-bloodhound-ce-lab-kurulumu-docker-ile-ilk-attack-path-gorsellestirme.html [Resim: attachment.php?aid=329]
Merhaba,

BloodHound Community Edition, Active Directory ve Entra ID saldırı yollarını graf olarak gösterir. SpecterOps'un resmi quickstart'ına göre BH-CLI + Docker Compose ile ayağa kaldırıp örnek veri veya SharpHound çıktısı yutturabilirsiniz. Bu yazı yalnızca kendi lab AD'niz içindir.

Gereksinimler
  • ~8 GB RAM, 4 çekirdek, 10 GB disk (küçük lab)
  • Docker Desktop / Docker Engine
  • EDR'nin BloodHound bileşenlerini engellemesine karşı allowlist (mümkünse ayrı lab makinesi)

Kurulum özeti
Kod:
wget https://github.com/SpecterOps/bloodhound-cli/releases/latest/download/bloodhound-cli-linux-amd64.tar.gz tar -xvzf bloodhound-cli-linux-amd64.tar.gz ./bloodhound-cli install # Çıktıdaki admin parolasını kaydedin # UI: http://localhost:8080/ui/login
İlk girişte parola sıfırlanır. Parolayı kaybederseniz:
Kod:
./bloodhound-cli resetpwd

Veri alma
  • Hızlı keşif: resmi sample AD/Azure ZIP'lerini Quick Upload ile yükleyin
  • Gerçekçi lab: domain-joined Windows'ta SharpHound.exe (yalnızca kendi domain'iniz)
  • Entra: AzureHound; SaaS: OpenHound (GitHub/Okta/Jamf)

Kod:
# SharpHound örneği (lab domain admin oturumu, izinli) SharpHound.exe -c All --zipfilename lab.zip

Explore
Search'te user:bob (sample) gibi nesneler; Pathfinding ile BOB -> Administrators yolu; Cypher sekmesinde hazır sorgular. Amaç: fazla yetki, kerberoastable hesap, ACL kısayollarını görüp düzeltmek.

Yasal uyarı
BloodHound'u sahip olmadığınız / yazılı izniniz olmayan ağlarda çalıştırmayın. TCK 243-245. Kurumsal ağda SOC/CISO bilgilendirmesi şart.

Kaynaklar
Yorumlama disiplini
BloodHound'ta kırmızı yol görmek "yarın Domino" demek değildir; önceliklendirme gerekir. Önce internete açık + high privilege path, sonra kerberoastable, sonra ACL birikimi. Remediation ticket'larına ekran görüntüsü değil, nesne DN ve önerilen ACE değişikliği yazın.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)
  1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
  2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
  3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
  4. Yama veya yapılandırma azaltmasını stagingde deneyin.
  5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
  6. Servis sağlık kontrolü + log doğrulaması yapın.
  7. Gerekliyse IOC avı veya compromise assessment planlayın.
  8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi
  • Üretici / araştırmacı birincil yazısı (kaynakçada)
  • CISA KEV veya CERT duyurusu varsa o
  • Kendi iç runbook'unuzun ilgili maddesi
Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

.png   12-b02-bloodhound.png (Dosya Boyutu: 109.77 KB / İndirme Sayısı: 10) ]]> [Resim: attachment.php?aid=329]
Merhaba,

BloodHound Community Edition, Active Directory ve Entra ID saldırı yollarını graf olarak gösterir. SpecterOps'un resmi quickstart'ına göre BH-CLI + Docker Compose ile ayağa kaldırıp örnek veri veya SharpHound çıktısı yutturabilirsiniz. Bu yazı yalnızca kendi lab AD'niz içindir.

Gereksinimler
  • ~8 GB RAM, 4 çekirdek, 10 GB disk (küçük lab)
  • Docker Desktop / Docker Engine
  • EDR'nin BloodHound bileşenlerini engellemesine karşı allowlist (mümkünse ayrı lab makinesi)

Kurulum özeti
Kod:
wget https://github.com/SpecterOps/bloodhound-cli/releases/latest/download/bloodhound-cli-linux-amd64.tar.gz tar -xvzf bloodhound-cli-linux-amd64.tar.gz ./bloodhound-cli install # Çıktıdaki admin parolasını kaydedin # UI: http://localhost:8080/ui/login
İlk girişte parola sıfırlanır. Parolayı kaybederseniz:
Kod:
./bloodhound-cli resetpwd

Veri alma
  • Hızlı keşif: resmi sample AD/Azure ZIP'lerini Quick Upload ile yükleyin
  • Gerçekçi lab: domain-joined Windows'ta SharpHound.exe (yalnızca kendi domain'iniz)
  • Entra: AzureHound; SaaS: OpenHound (GitHub/Okta/Jamf)

Kod:
# SharpHound örneği (lab domain admin oturumu, izinli) SharpHound.exe -c All --zipfilename lab.zip

Explore
Search'te user:bob (sample) gibi nesneler; Pathfinding ile BOB -> Administrators yolu; Cypher sekmesinde hazır sorgular. Amaç: fazla yetki, kerberoastable hesap, ACL kısayollarını görüp düzeltmek.

Yasal uyarı
BloodHound'u sahip olmadığınız / yazılı izniniz olmayan ağlarda çalıştırmayın. TCK 243-245. Kurumsal ağda SOC/CISO bilgilendirmesi şart.

Kaynaklar
Yorumlama disiplini
BloodHound'ta kırmızı yol görmek "yarın Domino" demek değildir; önceliklendirme gerekir. Önce internete açık + high privilege path, sonra kerberoastable, sonra ACL birikimi. Remediation ticket'larına ekran görüntüsü değil, nesne DN ve önerilen ACE değişikliği yazın.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)
  1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
  2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
  3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
  4. Yama veya yapılandırma azaltmasını stagingde deneyin.
  5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
  6. Servis sağlık kontrolü + log doğrulaması yapın.
  7. Gerekliyse IOC avı veya compromise assessment planlayın.
  8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi
  • Üretici / araştırmacı birincil yazısı (kaynakçada)
  • CISA KEV veya CERT duyurusu varsa o
  • Kendi iç runbook'unuzun ilgili maddesi
Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

.png   12-b02-bloodhound.png (Dosya Boyutu: 109.77 KB / İndirme Sayısı: 10) ]]> <![CDATA[Kerberoasting Nedir? Servis Biletlerinden Hash Avı ve Savunma]]> https://www.turkteam.org/konu-kerberoasting-nedir-servis-biletlerinden-hash-avi-ve-savunma.html Sun, 18 Oct 2026 11:21:49 +0300 Tonyukuk]]> https://www.turkteam.org/konu-kerberoasting-nedir-servis-biletlerinden-hash-avi-ve-savunma.html [Resim: attachment.php?aid=159]
Merhaba,

Kerberoasting, Active Directory'de servis hesaplarının TGS biletlerinden offline parola kırma saldırısıdır. Bu yazıda nasıl çalıştığını, labda nasıl görüldüğünü ve savunma kontrollerini anlatıyorum. Yalnızca kendi AD lab'ınızda deneyin.

Mantık
SPN (Service Principal Name) kayıtlı hesaplar için herhangi bir domain kullanıcısı TGS isteyebilir. Biletin bir kısmı servis hesabı anahtarıyla şifrilidir; zayıf parolada offline Hashcat/John ile kırma denemesi yapılır. Hedefe sürekli online brute force değildir.

Savunmacı bakış: kim risk altında?
  • Uzun ömürlü, insan tarafından seçilmiş parolalı servis hesapları
  • Eski SQL / IIS / monitör hesapları
  • Gereksiz SPN'ler
Kod:
# Labda SPN listesi (PowerView / yerleşik) setspn -Q */*



Tespit sinyalleri
  • Kısa sürede çok sayıda TGS-REQ (anormal)
  • RC4 (0x17) kullanan isteklerin artması (ortama göre)
  • Servis hesabıyla alışılmadık istemcilerden erişim
Windows Security log ve RGEF / Azure Sentinel / Splunk kuralları bu pattern için yazılır. Yanlış pozitif olabilir; baseline alın.

Savunma
  1. Servis hesaplarında uzun rastgele parola (25+ karakter) veya gMSA
  2. Gereksiz SPN temizliği
  3. AES kullanımını teşvik, eski şifreleme türlerini kısıtlama (dikkatli pilot)
  4. Yönetici hesaplarına rastgele SPN eklemeyin
  5. Tier model: krıtık sunuculara yolu daraltın
gMSA (Group Managed Service Account) parolayı Windows'un yönetmesini sağlar; Kerberoasting yüzeyini ciddi azaltır.

Kaynaklar
  • MITRE ATT&CK T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting
  • Microsoft Docs: gMSA
  • ADSecurity.org arşiv yazıları (tarihsel referans)

Siz gMSA'ya geçerken hangi uygulama direnç gösterdi? Deneyimleri duymak isterim.

Honey SPN
Sahte SPN'li tuzak hesap, Kerberoast denemelerini alarm olarak yakalamak için kullanılır. Parolası imkânsız uzunlukta olsun; TGS isteği gelince SIEM alarm. Labda deneyin, production'da legal/etik çerçevede uygulayın.

Raporlama dili
Yönetime "Kerberoasting mümkün" yerine "zayıf parolalı 12 servis hesabı offline kırmaya açık; gMSA ile kapatılabilir" deyin. Sayı ve düzeltme yolu olmadan bulgu yaşamaz.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n28-8818c5.png (Dosya Boyutu: 67.8 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=159]
Merhaba,

Kerberoasting, Active Directory'de servis hesaplarının TGS biletlerinden offline parola kırma saldırısıdır. Bu yazıda nasıl çalıştığını, labda nasıl görüldüğünü ve savunma kontrollerini anlatıyorum. Yalnızca kendi AD lab'ınızda deneyin.

Mantık
SPN (Service Principal Name) kayıtlı hesaplar için herhangi bir domain kullanıcısı TGS isteyebilir. Biletin bir kısmı servis hesabı anahtarıyla şifrilidir; zayıf parolada offline Hashcat/John ile kırma denemesi yapılır. Hedefe sürekli online brute force değildir.

Savunmacı bakış: kim risk altında?
  • Uzun ömürlü, insan tarafından seçilmiş parolalı servis hesapları
  • Eski SQL / IIS / monitör hesapları
  • Gereksiz SPN'ler
Kod:
# Labda SPN listesi (PowerView / yerleşik) setspn -Q */*



Tespit sinyalleri
  • Kısa sürede çok sayıda TGS-REQ (anormal)
  • RC4 (0x17) kullanan isteklerin artması (ortama göre)
  • Servis hesabıyla alışılmadık istemcilerden erişim
Windows Security log ve RGEF / Azure Sentinel / Splunk kuralları bu pattern için yazılır. Yanlış pozitif olabilir; baseline alın.

Savunma
  1. Servis hesaplarında uzun rastgele parola (25+ karakter) veya gMSA
  2. Gereksiz SPN temizliği
  3. AES kullanımını teşvik, eski şifreleme türlerini kısıtlama (dikkatli pilot)
  4. Yönetici hesaplarına rastgele SPN eklemeyin
  5. Tier model: krıtık sunuculara yolu daraltın
gMSA (Group Managed Service Account) parolayı Windows'un yönetmesini sağlar; Kerberoasting yüzeyini ciddi azaltır.

Kaynaklar
  • MITRE ATT&CK T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting
  • Microsoft Docs: gMSA
  • ADSecurity.org arşiv yazıları (tarihsel referans)

Siz gMSA'ya geçerken hangi uygulama direnç gösterdi? Deneyimleri duymak isterim.

Honey SPN
Sahte SPN'li tuzak hesap, Kerberoast denemelerini alarm olarak yakalamak için kullanılır. Parolası imkânsız uzunlukta olsun; TGS isteği gelince SIEM alarm. Labda deneyin, production'da legal/etik çerçevede uygulayın.

Raporlama dili
Yönetime "Kerberoasting mümkün" yerine "zayıf parolalı 12 servis hesabı offline kırmaya açık; gMSA ile kapatılabilir" deyin. Sayı ve düzeltme yolu olmadan bulgu yaşamaz.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n28-8818c5.png (Dosya Boyutu: 67.8 KB / İndirme Sayısı: 6) ]]> <![CDATA[LLMNR ve NBT-NS Zehirlenmesi: Neden Kapatılmalı ve Nasıl Tespit Edilir]]> https://www.turkteam.org/konu-llmnr-ve-nbt-ns-zehirlenmesi-neden-kapatilmali-ve-nasil-tespit-edilir.html Sun, 18 Oct 2026 11:02:18 +0300 Tonyukuk]]> https://www.turkteam.org/konu-llmnr-ve-nbt-ns-zehirlenmesi-neden-kapatilmali-ve-nasil-tespit-edilir.html [Resim: attachment.php?aid=138]
Selam,

LLMNR ve NBT-NS, isim çözümlemesi başarısız olunca Windows'un yerel ağda "bu isim kimde?" diye bağırdığı protokoller. Saldırgan Responder benzeri araçlarla cevap verip kimlik bilgisi yakalayabilir. Bu yazıda neden kapatılacağını ve nasıl tespit edileceğini anlatıyorum. Lab ve kendi ağınız için.

Sorun özeti
Kullanıcı \\dosyaadi yazınca DNS bulamazsa LLMNR/NBT-NS devreye girer. Sahte yanıtla kurban saldırgana bağlanır; NTLMv2 challenge/response yakalanabilir. İç ağda hâlâ en sık lateral movement başlangıçlarından biri.

Kapatma (GPO)
  • LLMNR: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off Multicast Name Resolution = Enabled
  • NBT-NS: arayüz özelliklerinden NetBIOS over TCP/IP disable veya PowerShell/GPO ile
Kod:
# Lab örneği: belirli arayüzde NetBIOS kapatma (indeks ortama göre) Get-CimInstance Win32_NetworkAdapterConfiguration | Where-Object {$_.IPEnabled} | Select Description, TcpipNetbiosOptions



Tespit
  • Ağda LLMNR/NBT-NS sorgularını IDS ile görün (Zeek/Suricata kuralları)
  • Windows'ta şüpheli logon Type 3 + kaynak IP olarak bilinmeyen cihaz
  • Honey- cred / decoy hesap ile Responder avı (kontrollü tatbikat)
Savunma tatbikatında kendi Responder'ınızı lab VLAN'ında çalıştırıp kapatma politikasının işe yaradığını doğrulayın.

Tamamlayıcı kontroller
  • SMB imzalama zorunlu
  • LDAP signing / channel binding
  • Yerel yönetici parolası rastgele (LAPS)
  • Tiering: günlük kullanıcıda local admin yok

Kaynaklar
  • Microsoft Docs: LLMNR
  • MITRE ATT&CK: Adversary-in-the-Middle, LLMNR/NBT-NS poisoning
  • SANS / çeşitli red team blogları (savunma odaklı okuyun)

Siz LLMNR'yi kurum genelinde kapattığınızda kırılan eski uygulamanız oldu mu?

DNS doğru mu?
LLMNR'yi kapatmadan önce iç DNS'in düzgün çalıştığından emin olun. Yanlış DNS + kapalı LLMNR = paylaşım ve yazıcı erişimi kırılır; kullanıcılar politikayı geri açtırır. Önce DNS sağlığı, sonra kapatma.

IPv6 komşuluk
Benzer zehirleme IPv6'da da mümkün (mitm6 senaryoları). IPv6'yı "kullanmıyoruz" diye açık bırakmayın; ya yönetin ya da bilinçli kapatın (kurum politikasına göre).


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n27-7a18d6.png (Dosya Boyutu: 65.3 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=138]
Selam,

LLMNR ve NBT-NS, isim çözümlemesi başarısız olunca Windows'un yerel ağda "bu isim kimde?" diye bağırdığı protokoller. Saldırgan Responder benzeri araçlarla cevap verip kimlik bilgisi yakalayabilir. Bu yazıda neden kapatılacağını ve nasıl tespit edileceğini anlatıyorum. Lab ve kendi ağınız için.

Sorun özeti
Kullanıcı \\dosyaadi yazınca DNS bulamazsa LLMNR/NBT-NS devreye girer. Sahte yanıtla kurban saldırgana bağlanır; NTLMv2 challenge/response yakalanabilir. İç ağda hâlâ en sık lateral movement başlangıçlarından biri.

Kapatma (GPO)
  • LLMNR: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off Multicast Name Resolution = Enabled
  • NBT-NS: arayüz özelliklerinden NetBIOS over TCP/IP disable veya PowerShell/GPO ile
Kod:
# Lab örneği: belirli arayüzde NetBIOS kapatma (indeks ortama göre) Get-CimInstance Win32_NetworkAdapterConfiguration | Where-Object {$_.IPEnabled} | Select Description, TcpipNetbiosOptions



Tespit
  • Ağda LLMNR/NBT-NS sorgularını IDS ile görün (Zeek/Suricata kuralları)
  • Windows'ta şüpheli logon Type 3 + kaynak IP olarak bilinmeyen cihaz
  • Honey- cred / decoy hesap ile Responder avı (kontrollü tatbikat)
Savunma tatbikatında kendi Responder'ınızı lab VLAN'ında çalıştırıp kapatma politikasının işe yaradığını doğrulayın.

Tamamlayıcı kontroller
  • SMB imzalama zorunlu
  • LDAP signing / channel binding
  • Yerel yönetici parolası rastgele (LAPS)
  • Tiering: günlük kullanıcıda local admin yok

Kaynaklar
  • Microsoft Docs: LLMNR
  • MITRE ATT&CK: Adversary-in-the-Middle, LLMNR/NBT-NS poisoning
  • SANS / çeşitli red team blogları (savunma odaklı okuyun)

Siz LLMNR'yi kurum genelinde kapattığınızda kırılan eski uygulamanız oldu mu?

DNS doğru mu?
LLMNR'yi kapatmadan önce iç DNS'in düzgün çalıştığından emin olun. Yanlış DNS + kapalı LLMNR = paylaşım ve yazıcı erişimi kırılır; kullanıcılar politikayı geri açtırır. Önce DNS sağlığı, sonra kapatma.

IPv6 komşuluk
Benzer zehirleme IPv6'da da mümkün (mitm6 senaryoları). IPv6'yı "kullanmıyoruz" diye açık bırakmayın; ya yönetin ya da bilinçli kapatın (kurum politikasına göre).


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n27-7a18d6.png (Dosya Boyutu: 65.3 KB / İndirme Sayısı: 7) ]]> <![CDATA[Active Directory Temelleri: Kerberos Biletleri ve Savunma]]> https://www.turkteam.org/konu-active-directory-temelleri-kerberos-biletleri-ve-savunma.html Fri, 16 Oct 2026 11:19:35 +0300 Tonyukuk]]> https://www.turkteam.org/konu-active-directory-temelleri-kerberos-biletleri-ve-savunma.html [Resim: attachment.php?aid=29]
Active Directory Temelleri: Kerberos ve Savunmacı Bakış

Selamlar,

Kurumsal Windows ağlarının kalbi Active Directory'dir. Bu rehber saldırı tarifleri vermez; Kerberos bilet modelini ve mavi takımın izlemesi gereken noktaları anlatır. Tüm denemeler yalnızca kendi lab AD'nizde yapılmalıdır.

Konuda Anlatılacaklar
  1. AD bileşenleri (kısa)
  2. Kerberos: TGT ve servis bileti
  3. Olay günlükleri (Event ID)
  4. Savunma kontrol listesi
  5. Kaynakça

1) Temel Bileşenler
  • Domain Controller (DC): Kimlik doğrulama ve dizin
  • Domain User / Computer hesapları
  • Group Policy (GPO)
  • Kerberos / NTLM kimlik doğrulama protokolleri

2) Kerberos Biletleri (Kavram)
  • Kullanıcı kimlik doğrular -> TGT (Ticket Granting Ticket) alır
  • Bir servise erişmek için TGT ile servis bileti (TGS) ister
  • Servis bileti ilgili servis hesabının anahtarıyla korunur
Bu model yüzünden servis hesaplarının zayıf parolası veya aşırı yetkili hesaplar tüm ormanı riske atar.

3) İzlenmesi Gereken Olaylar
Kod:
# DC Security loglarında (kavramsal) # 4768: TGT isteği # 4769: Servis bileti isteği # 4624 / 4625: Oturum açma başarı / başarısız # 4720: Kullanıcı hesabı oluşturma # 4732: Güvenlik grubuna üye ekleme
SIEM'inizde "mesai dışı TGT + hassas gruba üye ekleme" gibi zincir kurallar kurun.

4) Savunma Kontrol Listesi
  • Tiering: Admin iş istasyonlarını günlük kullanıcı PC'lerinden ayırın
  • Servis hesaplarında uzun, rastgele parola veya gMSA
  • Krbtgt parolasını düzenli ve güvenli şekilde döndürün
  • Legacy NTLM'i mümkün olduğunca kısıtlayın
  • LDAP imzalama / kanal bağlama
  • Privileged Group değişikliklerini alarmlayın

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: AD testlerini yalnızca kendi lab ortamınızda veya yazılı yetkili pentest kapsamında yapın. TCK 243-245 geçerlidir.


.jpg   tonyukuk-18.jpg (Dosya Boyutu: 98.92 KB / İndirme Sayısı: 16) ]]> [Resim: attachment.php?aid=29]
Active Directory Temelleri: Kerberos ve Savunmacı Bakış

Selamlar,

Kurumsal Windows ağlarının kalbi Active Directory'dir. Bu rehber saldırı tarifleri vermez; Kerberos bilet modelini ve mavi takımın izlemesi gereken noktaları anlatır. Tüm denemeler yalnızca kendi lab AD'nizde yapılmalıdır.

Konuda Anlatılacaklar
  1. AD bileşenleri (kısa)
  2. Kerberos: TGT ve servis bileti
  3. Olay günlükleri (Event ID)
  4. Savunma kontrol listesi
  5. Kaynakça

1) Temel Bileşenler
  • Domain Controller (DC): Kimlik doğrulama ve dizin
  • Domain User / Computer hesapları
  • Group Policy (GPO)
  • Kerberos / NTLM kimlik doğrulama protokolleri

2) Kerberos Biletleri (Kavram)
  • Kullanıcı kimlik doğrular -> TGT (Ticket Granting Ticket) alır
  • Bir servise erişmek için TGT ile servis bileti (TGS) ister
  • Servis bileti ilgili servis hesabının anahtarıyla korunur
Bu model yüzünden servis hesaplarının zayıf parolası veya aşırı yetkili hesaplar tüm ormanı riske atar.

3) İzlenmesi Gereken Olaylar
Kod:
# DC Security loglarında (kavramsal) # 4768: TGT isteği # 4769: Servis bileti isteği # 4624 / 4625: Oturum açma başarı / başarısız # 4720: Kullanıcı hesabı oluşturma # 4732: Güvenlik grubuna üye ekleme
SIEM'inizde "mesai dışı TGT + hassas gruba üye ekleme" gibi zincir kurallar kurun.

4) Savunma Kontrol Listesi
  • Tiering: Admin iş istasyonlarını günlük kullanıcı PC'lerinden ayırın
  • Servis hesaplarında uzun, rastgele parola veya gMSA
  • Krbtgt parolasını düzenli ve güvenli şekilde döndürün
  • Legacy NTLM'i mümkün olduğunca kısıtlayın
  • LDAP imzalama / kanal bağlama
  • Privileged Group değişikliklerini alarmlayın

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: AD testlerini yalnızca kendi lab ortamınızda veya yazılı yetkili pentest kapsamında yapın. TCK 243-245 geçerlidir.


.jpg   tonyukuk-18.jpg (Dosya Boyutu: 98.92 KB / İndirme Sayısı: 16) ]]>