<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Windows ve Güvenlik]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:39 +0000 MyBB <![CDATA[Windows Server 2016 Destek Sonu 12 Ocak 2027: Son Güncelleme ve Geçiş Planı]]> https://www.turkteam.org/konu-windows-server-2016-destek-sonu-12-ocak-2027-son-guncelleme-ve-gecis-plani.html Sun, 25 Oct 2026 11:47:42 +0300 BilgeKagan]]> https://www.turkteam.org/konu-windows-server-2016-destek-sonu-12-ocak-2027-son-guncelleme-ve-gecis-plani.html [Resim: attachment.php?aid=434]
Selamlar,

Microsoft, Windows Server 2016'nın 12 Ocak 2027'de destek sonuna (EOL) ulaşacağını duyurdu. BleepingComputer konuyu aktardı. Ocak 2027 güvenlik güncellemesi bu sürüm için son güncelleme olacak; sonrasında aylık güvenlik yaması gelmeyecek. EOL, bir "takvim notu" değil; yamasız kalan sunucular hızla saldırı hedefi olur. Burada takvimi ve güvenli geçiş seçeneklerinizi ele alıyorum.

Konuda anlatılacaklar
  1. EOL ne demek, neden önemli?
  2. Takvim ve etkilenen sürümler
  3. Geçiş seçeneği: Windows Server 2025
  4. ESU: ek süre gerekiyorsa
  5. Geçiş kontrol listesi

1. EOL ne demek?
Destek sonu, ürünün artık güvenlik güncellemesi almayacağı anlamına gelir. Yeni keşfedilen her açık, yamasız kalır; yani sunucu zamanla giderek daha savunmasız hale gelir. Server 2016 Ocak 2022'de ana desteği (mainstream) bitirmişti; genişletilmiş destek de Ocak 2027'de bitiyor.

2. Takvim ve etkilenen sürümler
Kod:
Genel kullanıma çıkış : Ekim 2016 Ana destek sonu : Ocak 2022 Genişletilmiş destek : 12 Ocak 2027 (son güvenlik güncellemesi)
Microsoft'a göre bu durum tüm Server 2016 sürümleri için geçerli: Datacenter, Essentials, MultiPoint Premium ve Standard. Aynı tarihte Server 2016 Essentials özellikleri de desteklenmeyi bırakacak.

3. Geçiş: Windows Server 2025
Microsoft, Windows Server 2025'e geçişi öneriyor. Bu, en güncel Uzun Vadeli Servis Kanalı (LTSC) sürümü; Kasım 2024'te genel kullanıma çıktı. Yaşam döngüsüne göre ana desteği Kasım 2029'da bitecek, genişletilmiş destek Kasım 2034'e kadar sürecek. Dağıtımdan önce test etmek isteyenler için 180 günlük ücretsiz deneme mevcut.

4. ESU
Hemen geçiş yapamayanlar için Azure Arc üzerinden Extended Security Updates (ESU) seçeneği var; ancak bu Standard ve Datacenter için geçerli, Essentials için değil. ESU bir köprü çözümüdür, kalıcı plan değil.

5. Geçiş kontrol listesi
  1. Envanter çıkarın. Hangi sunucular Server 2016 çalıştırıyor, üzerlerinde hangi roller var?
  2. Uygulama uyumluluğunu test edin. Kritik iş uygulamalarını Server 2025'te deneme ortamında doğrulayın.
  3. İnternete dönük sunucuları öne alın. En yüksek risk onlarda.
  4. Geçiş yapılamıyorsa ESU + izolasyon planlayın; yamasız sunucuları ağ segmentasyonuyla sınırlandırın.
  5. Yedekleme ve geri dönüş planı hazırlayın.
Not: Microsoft ayrıca Windows 11 24H2 Home/Pro sürümlerinin güncelleme almayı bırakıp 26H2'ye geçilmesi gerektiğini de duyurdu.

Sonuç
EOL tarihleri sürpriz değildir; planlama süresi verir. Server 2016'yı hâlâ çalıştırıyorsanız, Ocak 2027 öncesi geçiş ya da ESU + izolasyon için şimdi plan yapmak gerekiyor. Ortamınızda kaç Server 2016 sunucusu kaldı, biliyor musunuz?

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   15-t15-windows-server-2016-eol.png (Dosya Boyutu: 126.99 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=434]
Selamlar,

Microsoft, Windows Server 2016'nın 12 Ocak 2027'de destek sonuna (EOL) ulaşacağını duyurdu. BleepingComputer konuyu aktardı. Ocak 2027 güvenlik güncellemesi bu sürüm için son güncelleme olacak; sonrasında aylık güvenlik yaması gelmeyecek. EOL, bir "takvim notu" değil; yamasız kalan sunucular hızla saldırı hedefi olur. Burada takvimi ve güvenli geçiş seçeneklerinizi ele alıyorum.

Konuda anlatılacaklar
  1. EOL ne demek, neden önemli?
  2. Takvim ve etkilenen sürümler
  3. Geçiş seçeneği: Windows Server 2025
  4. ESU: ek süre gerekiyorsa
  5. Geçiş kontrol listesi

1. EOL ne demek?
Destek sonu, ürünün artık güvenlik güncellemesi almayacağı anlamına gelir. Yeni keşfedilen her açık, yamasız kalır; yani sunucu zamanla giderek daha savunmasız hale gelir. Server 2016 Ocak 2022'de ana desteği (mainstream) bitirmişti; genişletilmiş destek de Ocak 2027'de bitiyor.

2. Takvim ve etkilenen sürümler
Kod:
Genel kullanıma çıkış : Ekim 2016 Ana destek sonu : Ocak 2022 Genişletilmiş destek : 12 Ocak 2027 (son güvenlik güncellemesi)
Microsoft'a göre bu durum tüm Server 2016 sürümleri için geçerli: Datacenter, Essentials, MultiPoint Premium ve Standard. Aynı tarihte Server 2016 Essentials özellikleri de desteklenmeyi bırakacak.

3. Geçiş: Windows Server 2025
Microsoft, Windows Server 2025'e geçişi öneriyor. Bu, en güncel Uzun Vadeli Servis Kanalı (LTSC) sürümü; Kasım 2024'te genel kullanıma çıktı. Yaşam döngüsüne göre ana desteği Kasım 2029'da bitecek, genişletilmiş destek Kasım 2034'e kadar sürecek. Dağıtımdan önce test etmek isteyenler için 180 günlük ücretsiz deneme mevcut.

4. ESU
Hemen geçiş yapamayanlar için Azure Arc üzerinden Extended Security Updates (ESU) seçeneği var; ancak bu Standard ve Datacenter için geçerli, Essentials için değil. ESU bir köprü çözümüdür, kalıcı plan değil.

5. Geçiş kontrol listesi
  1. Envanter çıkarın. Hangi sunucular Server 2016 çalıştırıyor, üzerlerinde hangi roller var?
  2. Uygulama uyumluluğunu test edin. Kritik iş uygulamalarını Server 2025'te deneme ortamında doğrulayın.
  3. İnternete dönük sunucuları öne alın. En yüksek risk onlarda.
  4. Geçiş yapılamıyorsa ESU + izolasyon planlayın; yamasız sunucuları ağ segmentasyonuyla sınırlandırın.
  5. Yedekleme ve geri dönüş planı hazırlayın.
Not: Microsoft ayrıca Windows 11 24H2 Home/Pro sürümlerinin güncelleme almayı bırakıp 26H2'ye geçilmesi gerektiğini de duyurdu.

Sonuç
EOL tarihleri sürpriz değildir; planlama süresi verir. Server 2016'yı hâlâ çalıştırıyorsanız, Ocak 2027 öncesi geçiş ya da ESU + izolasyon için şimdi plan yapmak gerekiyor. Ortamınızda kaç Server 2016 sunucusu kaldı, biliyor musunuz?

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   15-t15-windows-server-2016-eol.png (Dosya Boyutu: 126.99 KB / İndirme Sayısı: 1) ]]> <![CDATA[Secure Boot DBX İptali Nasıl Açılır? BlackX Sonrası Windows Yönetici Rehberi]]> https://www.turkteam.org/konu-secure-boot-dbx-iptali-nasil-acilir-blackx-sonrasi-windows-yonetici-rehberi.html Sat, 24 Oct 2026 11:35:26 +0300 KulTigin]]> https://www.turkteam.org/konu-secure-boot-dbx-iptali-nasil-acilir-blackx-sonrasi-windows-yonetici-rehberi.html [Resim: attachment.php?aid=414]
Selamlar,

BlackX kampanyasının gösterdiği gibi, Secure Boot yamasını kurmak tek başına Baton Drop benzeri zincirleri durdurmayabiliyor. Microsoft KB5025885, iptallerin elle etkinleştirilmesi gerektiğini yıllardır yazıyor; Enforcement Phase hâlâ ileri bir tarihe bırakılmış durumda. Bu rehber, kurumsal Windows yöneticisi için sadeleştirilmiş bir yol haritası. Üretimde uygulamadan önce mutlaka pilot yapın; bazı adımlar geri alınamaz.

Konuda anlatılacaklar
  1. Riskleri bilerek başlayın
  2. Adım adım etkinleştirme
  3. Doğrulama
  4. Kurtarma medyası
  5. Bilinen sorunlar

1. Riskleri bilerek başlayın
  • DBX'e PCA 2011 eklendikten sonra eski imzalı boot manager'lar çalışmaz.
  • Eski kurtarma USB / PXE medyası önyüklemeyebilir.
  • Bazı üretici üretici yazılımları DB/DBX güncellemesini bozar; cihaz sınıfı başına test şart.
  • BitLocker kurtarma ekranına düşebilirsiniz; 48 haneli anahtarı önceden alın.
Kod:
manage-bde -protectors -get %systemdrive%

2. Adım adım (özet)
Önce son aylık güvenlik güncellemesini kurun. Ardından (Yönetici PowerShell/CMD):
Kod:
# 1) 2023 UEFI CA'yi DB'ye ekle reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" # Dogrula (True donmeli) [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' # 2) PCA 2011'i DBX'e ekle (iptal) reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x80 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" # Dogrula [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
SVN güncellemesi (0x200) isteğe bağlı dördüncü adımdır; medya yönetimini etkiler.

3. Doğrulama olayları
Olay Kimliği 1036 (DB), 1799 (boot manager), 1037 (DBX), 1042 (SVN). Servicing altındaki UEFICA2023Status değerinin Updated olması beklenir.

4. Kurtarma medyası
İptalden önce, DB güncellemesi uygulanmış bir makinede "Create a Recovery Drive" ile FAT32 USB oluşturun ve bcdboot /bootex adımlarını Microsoft makalesindeki gibi uygulayın. Eski medyayı envanterden çıkarın.

5. Bilinen sorunlar (makaleden)
HP Sure Start, bazı Arm64/Qualcomm, VMware Secure Boot VM'leri, Symantec Endpoint Encryption gibi durumlarda ek üretici adımları gerekebilir. Geniş yayından önce pilot şart.

Kaç makinenizde DBX iptali gerçekten etkin? Ölçümleyen var mı?

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   19-k04-secure-boot-dbx.png (Dosya Boyutu: 123.28 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=414]
Selamlar,

BlackX kampanyasının gösterdiği gibi, Secure Boot yamasını kurmak tek başına Baton Drop benzeri zincirleri durdurmayabiliyor. Microsoft KB5025885, iptallerin elle etkinleştirilmesi gerektiğini yıllardır yazıyor; Enforcement Phase hâlâ ileri bir tarihe bırakılmış durumda. Bu rehber, kurumsal Windows yöneticisi için sadeleştirilmiş bir yol haritası. Üretimde uygulamadan önce mutlaka pilot yapın; bazı adımlar geri alınamaz.

Konuda anlatılacaklar
  1. Riskleri bilerek başlayın
  2. Adım adım etkinleştirme
  3. Doğrulama
  4. Kurtarma medyası
  5. Bilinen sorunlar

1. Riskleri bilerek başlayın
  • DBX'e PCA 2011 eklendikten sonra eski imzalı boot manager'lar çalışmaz.
  • Eski kurtarma USB / PXE medyası önyüklemeyebilir.
  • Bazı üretici üretici yazılımları DB/DBX güncellemesini bozar; cihaz sınıfı başına test şart.
  • BitLocker kurtarma ekranına düşebilirsiniz; 48 haneli anahtarı önceden alın.
Kod:
manage-bde -protectors -get %systemdrive%

2. Adım adım (özet)
Önce son aylık güvenlik güncellemesini kurun. Ardından (Yönetici PowerShell/CMD):
Kod:
# 1) 2023 UEFI CA'yi DB'ye ekle reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" # Dogrula (True donmeli) [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' # 2) PCA 2011'i DBX'e ekle (iptal) reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x80 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" # Dogrula [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
SVN güncellemesi (0x200) isteğe bağlı dördüncü adımdır; medya yönetimini etkiler.

3. Doğrulama olayları
Olay Kimliği 1036 (DB), 1799 (boot manager), 1037 (DBX), 1042 (SVN). Servicing altındaki UEFICA2023Status değerinin Updated olması beklenir.

4. Kurtarma medyası
İptalden önce, DB güncellemesi uygulanmış bir makinede "Create a Recovery Drive" ile FAT32 USB oluşturun ve bcdboot /bootex adımlarını Microsoft makalesindeki gibi uygulayın. Eski medyayı envanterden çıkarın.

5. Bilinen sorunlar (makaleden)
HP Sure Start, bazı Arm64/Qualcomm, VMware Secure Boot VM'leri, Symantec Endpoint Encryption gibi durumlarda ek üretici adımları gerekebilir. Geniş yayından önce pilot şart.

Kaç makinenizde DBX iptali gerçekten etkin? Ölçümleyen var mı?

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   19-k04-secure-boot-dbx.png (Dosya Boyutu: 123.28 KB / İndirme Sayısı: 2) ]]> <![CDATA[PowerShell Logging: Script Block, Module ve Transcription Açmak]]> https://www.turkteam.org/konu-powershell-logging-script-block-module-ve-transcription-acmak.html Mon, 19 Oct 2026 01:53:57 +0300 BilgeKagan]]> https://www.turkteam.org/konu-powershell-logging-script-block-module-ve-transcription-acmak.html [Resim: attachment.php?aid=287]
Selam,

PowerShell modern Windows'ta yönetim dili; saldırganlar da bunu biliyor. Script Block Logging kapalıysa SIEM kör kalır. Bu yazıda Script Block, Module Logging ve Transcription'ı labda nasıl açacağınızı ve nelere dikkat edeceğinizi anlatıyorum.

Üç katman
  • Module Logging: belirli modüllerin pipeline olayları
  • Script Block Logging: derlenen script block metni (Event ID 4104)
  • Transcription: oturumun metin kaydı (dosyaya)

GPO / yerel politika
Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell altında ilgili ayarları Enabled yapın. Labda kayıt defteri ile:
Kod:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" /v EnableModuleLogging /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" /v * /t REG_SZ /d * /f
Transcription:
Kod:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" /v EnableTranscripting /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" /v OutputDirectory /t REG_SZ /d C:\PSTranscripts /f
OutputDirectory ACL'ini sıkı tutun; transcript içinde parola olabilir.

[Resim: attachment.php?aid=288]

Logları okumak
Event Viewer > Applications and Services Logs > Microsoft > Windows > PowerShell > Operational
Kod:
Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' | Where-Object Id -eq 4104 | Select-Object -First 5 TimeCreated, Message
4104 mesajında ScriptBlock metni vardır. EncodedCommand kullanan saldırılarda burada decode edilmiş içerik görünebilir (motor derlediği için).

Gürültü ve gizlilik
  • Yoğun yönetim scriptleri log hacmini şişirir; WEF ile merkezi toplayın
  • Transcription'da secret geçmesin diye SecureString ve gizli kasa kullanın
  • Constrained Language Mode + AppLocker/WDAC ile birlikte düşünün

Saldırgan kaçınması
Logging'i kapatan / log silen davranışları ayrıca izleyin (4104'ün aniden kesilmesi, Event Log servisi oynamaları). Protected Event Logging (dokümante kurulum) ileri adım olabilir.

Kaynaklar
  • Microsoft Docs: about_Logging_Windows_PowerShell
  • FireEye / Mandiant PowerShell logging blogları (tarihsel referans)
  • Sigma rules: powershell script block

Siz Transcription'ı tüm workstation'larda mı açıyorsunuz, yoksa yalnızca sunucu/jump host'ta mı?

4104 boyutları ve WEF
Script Block logları büyük olabilir; WEF'te bandwith planlayın. Gerekirse yalnızca belirli sunucu gruplarında tam logging, workstation'da örnekleme. Yine de jump host / bastion'da tam açın; saldırgan oradan geçer.

PowerShell 7 vs 5.1
Logging ayarları sürüm ve host'a göre değişebilir. pwsh (Core) ve Windows PowerShell için politikaları ayrı doğrulayın. Test: küçük bir script çalıştırıp 4104 düşüyor mu bakın.


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.

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-n19-bbecea.png (Dosya Boyutu: 67.74 KB / İndirme Sayısı: 15)

.png   n19-inner.png (Dosya Boyutu: 20.27 KB / İndirme Sayısı: 14) ]]> [Resim: attachment.php?aid=287]
Selam,

PowerShell modern Windows'ta yönetim dili; saldırganlar da bunu biliyor. Script Block Logging kapalıysa SIEM kör kalır. Bu yazıda Script Block, Module Logging ve Transcription'ı labda nasıl açacağınızı ve nelere dikkat edeceğinizi anlatıyorum.

Üç katman
  • Module Logging: belirli modüllerin pipeline olayları
  • Script Block Logging: derlenen script block metni (Event ID 4104)
  • Transcription: oturumun metin kaydı (dosyaya)

GPO / yerel politika
Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell altında ilgili ayarları Enabled yapın. Labda kayıt defteri ile:
Kod:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" /v EnableModuleLogging /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" /v * /t REG_SZ /d * /f
Transcription:
Kod:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" /v EnableTranscripting /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" /v OutputDirectory /t REG_SZ /d C:\PSTranscripts /f
OutputDirectory ACL'ini sıkı tutun; transcript içinde parola olabilir.

[Resim: attachment.php?aid=288]

Logları okumak
Event Viewer > Applications and Services Logs > Microsoft > Windows > PowerShell > Operational
Kod:
Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' | Where-Object Id -eq 4104 | Select-Object -First 5 TimeCreated, Message
4104 mesajında ScriptBlock metni vardır. EncodedCommand kullanan saldırılarda burada decode edilmiş içerik görünebilir (motor derlediği için).

Gürültü ve gizlilik
  • Yoğun yönetim scriptleri log hacmini şişirir; WEF ile merkezi toplayın
  • Transcription'da secret geçmesin diye SecureString ve gizli kasa kullanın
  • Constrained Language Mode + AppLocker/WDAC ile birlikte düşünün

Saldırgan kaçınması
Logging'i kapatan / log silen davranışları ayrıca izleyin (4104'ün aniden kesilmesi, Event Log servisi oynamaları). Protected Event Logging (dokümante kurulum) ileri adım olabilir.

Kaynaklar
  • Microsoft Docs: about_Logging_Windows_PowerShell
  • FireEye / Mandiant PowerShell logging blogları (tarihsel referans)
  • Sigma rules: powershell script block

Siz Transcription'ı tüm workstation'larda mı açıyorsunuz, yoksa yalnızca sunucu/jump host'ta mı?

4104 boyutları ve WEF
Script Block logları büyük olabilir; WEF'te bandwith planlayın. Gerekirse yalnızca belirli sunucu gruplarında tam logging, workstation'da örnekleme. Yine de jump host / bastion'da tam açın; saldırgan oradan geçer.

PowerShell 7 vs 5.1
Logging ayarları sürüm ve host'a göre değişebilir. pwsh (Core) ve Windows PowerShell için politikaları ayrı doğrulayın. Test: küçük bir script çalıştırıp 4104 düşüyor mu bakın.


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.

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-n19-bbecea.png (Dosya Boyutu: 67.74 KB / İndirme Sayısı: 15)

.png   n19-inner.png (Dosya Boyutu: 20.27 KB / İndirme Sayısı: 14) ]]> <![CDATA[Windows'ta Sysinternals: TCPView, Autoruns ve Process Explorer Pratikleri]]> https://www.turkteam.org/konu-windows-ta-sysinternals-tcpview-autoruns-ve-process-explorer-pratikleri.html Mon, 19 Oct 2026 00:21:55 +0300 KulTigin]]> https://www.turkteam.org/konu-windows-ta-sysinternals-tcpview-autoruns-ve-process-explorer-pratikleri.html [Resim: attachment.php?aid=261]
Merhaba,

Windows olay müdahalesinde ilk açtığım üç araç neredeyse hep aynı: Process Explorer, Autoruns ve TCPView. Hepsi Microsoft Sysinternals ailesinden, ücretsiz ve taşınabilir. Bu yazıda bunları sahada nasıl kullandığımı, nelere baktığımı ve sık gördüğüm tuzakları anlatacağım. Ortam: kendi Windows 11 lab VM'im.

Araçları güvenli edinmek
Resmi kaynak: Microsoft Sysinternals sayfası (learn.microsoft.com altında Sysinternals). ZIP'i indirip doğrulayın; "sysinternals gibi görünen" sahte siteler var. Taşınabilir kullanım için araçları imzalı USB'de tutuyorum; şüpheli makinede internetten indirmiyorum.

Process Explorer: süreç ağacı ve şüpheli çocuklar
Görev Yöneticisi'nden farkı: süreç ağacını, DLL'leri, handle'ları ve doğrulanmış imza bilgisini bir arada gösterir.
  • Options > Verify Image Signatures: imzasız binary'leri hemen görün.
  • View > Lower Pane View > DLLs: sürecin yüklediği DLL'ler (sideloading ipucu).
  • Şüpheli süreçte sağ tık > Properties > Strings / TCP/IP / Image.
Labda bilerek çalıştırdığım bir test process'inde parent'ın explorer.exe değil de bilinen bir LOLBin (ör. rundll32) olması kırmızı bayraktır. Parent-child ilişkisi SOC'ta 4688 ile de takip edilir; Process Explorer bunu canlı gösterir.

[Resim: attachment.php?aid=262]

Autoruns: kalıcılık avcısı
Saldırganın en sevdiği şey yeniden başlatınca geri gelmektir. Autoruns; Run anahtarları, Scheduled Tasks, Services, WMI, Winlogon, AppInit_DLLs ve daha onlarcasını tek ekranda listeler.
Kod:
# Komut satırı sürümü (otomatik rapor için) autorunsc64.exe -a * -c -h -s > C:\Temp\autoruns.csv
Pratik alışkanlıklarım:
  1. Options > Hide Microsoft Entries (dikkat: saldırgan Microsoft gibi görünen isimler kullanabilir; tam tarama da yapın).
  2. Verify Code Signatures açık olsun.
  3. Bilinmeyen publisher + User klasörü altında path = inceleyin.
  4. Scheduled Tasks'ta "powershell -enc" veya temp yolları = yüksek öncelik.
Temiz bir baseline'ı altın imajdan alıp şüpheli makineyle karşılaştırmak çok hızlandırır.

TCPView: kim dışarı bağlanıyor?
netstat güzeldir ama TCPView süreç adıyla birlikte canlı bağlantıyı gösterir. Şüpheli bir EXE'nin bilinmeyen bir IP:port'a ESTABLISHED olması, EDR yokken bile hızlı sinyaldir.
  • Options > Resolve Addresses: bazen kapatın (hız + DNS gürültüsü olmasın).
  • Şüpheli satırda sağ tık > Process Properties / Whois (dikkat: whois dışarı sorgu gönderir; hassas olayda önce IP'yi not alıp izole ortamda soruşturun).
PowerShell ile benzer bilgi:
Kod:
Get-NetTCPConnection -State Established | Select LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess | Format-Table -AutoSize
TCPView'in avantajı hız ve görsellik; betiğin avantajı otomatikleştirme.

USB müdahale çantamda neler var?
  • procexp64, autoruns64, tcpview64, handle64, listdlls64, sigcheck64, strings64
  • Küçük bir hash betiği (Get-FileHash) ve not defteri şablonu
  • Salt okunur çalıştırma alışkanlığı: mümkünse araçları USB'den çalıştır, çıktıyı ayrı kanıta yaz
sigcheck ile tek dosya imza kontrolü:
Kod:
sigcheck64.exe -accepteula -h C:\Users\Public\suspicious.exe

Sık tuzaklar
  • Aynı isimli meşru süreç: svchost.exe yolu C:\Windows\System32 dışında olmamalı.
  • DLL sideloading: meşru EXE + yanındaki şüpheli DLL; Process Explorer lower pane burada kurtarır.
  • Yalnızca GUI'ye güvenmek: çıktıyı CSV/log olarak alın, olay kaydına ekleyin.
  • Canlı sistemde "temizlik" yaparken kanıtı bozmak: önce topla, sonra müdahale et.

Mavi takım ile köprü
Bu üç araç L1/L2 analistin "elle doğrulama" katmanıdır. EDR varsa yine de kullanırım: EDR bazen aggregate gösterir, siz o anki süreci görürsünüz. Tespit kurallarınızı (4688, Sysmon 1/3/11, Prefetch) bu araçlarla çaprazlayın.

Kaynaklar
  • Microsoft Sysinternals resmi belgeleri
  • Windows Internals (süreç/handle modeli için)
  • SANS FOR500/FOR508 notları (canlı yanıt pratiği)

Sizin çantanızda olmazsa olmaz dördüncü araç hangisi? Ben ara sıra Process Monitor'ü de ekliyorum ama gürültüsü yüksek; filtre disiplini şart.

Process Monitor ne zaman devreye girer?
Procmon çok gürültülüdür; filtre olmadan açmayın. Senaryo: "Bu EXE hangi registry anahtarına yazıyor?" Operation is Registry + Process Name filtresi. Çıktıyı PML olarak kaydedip temiz makinede analiz edin. Canlı IR'de önce Process Explorer + Autoruns + TCPView; derinleşme gerekirse Procmon.

Imza ve hash'i ticket'a yazmak
sigcheck -h çıktısındaki SHA256'yı ticket'a ve MISP/IOC listesine ekleyin. "suspicious.exe" adı yetmez; ertesi gün dosya adı değişmiş olur. VirusTotal yüklemesi kurum politikasına bağlıdır; hassas örnekleri herkese açık VT'ye yüklemeyin, private instance veya iç sandbox kullanın.


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.

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-n04-799270.png (Dosya Boyutu: 69.41 KB / İndirme Sayısı: 10)

.png   n04-inner.png (Dosya Boyutu: 26.2 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=261]
Merhaba,

Windows olay müdahalesinde ilk açtığım üç araç neredeyse hep aynı: Process Explorer, Autoruns ve TCPView. Hepsi Microsoft Sysinternals ailesinden, ücretsiz ve taşınabilir. Bu yazıda bunları sahada nasıl kullandığımı, nelere baktığımı ve sık gördüğüm tuzakları anlatacağım. Ortam: kendi Windows 11 lab VM'im.

Araçları güvenli edinmek
Resmi kaynak: Microsoft Sysinternals sayfası (learn.microsoft.com altında Sysinternals). ZIP'i indirip doğrulayın; "sysinternals gibi görünen" sahte siteler var. Taşınabilir kullanım için araçları imzalı USB'de tutuyorum; şüpheli makinede internetten indirmiyorum.

Process Explorer: süreç ağacı ve şüpheli çocuklar
Görev Yöneticisi'nden farkı: süreç ağacını, DLL'leri, handle'ları ve doğrulanmış imza bilgisini bir arada gösterir.
  • Options > Verify Image Signatures: imzasız binary'leri hemen görün.
  • View > Lower Pane View > DLLs: sürecin yüklediği DLL'ler (sideloading ipucu).
  • Şüpheli süreçte sağ tık > Properties > Strings / TCP/IP / Image.
Labda bilerek çalıştırdığım bir test process'inde parent'ın explorer.exe değil de bilinen bir LOLBin (ör. rundll32) olması kırmızı bayraktır. Parent-child ilişkisi SOC'ta 4688 ile de takip edilir; Process Explorer bunu canlı gösterir.

[Resim: attachment.php?aid=262]

Autoruns: kalıcılık avcısı
Saldırganın en sevdiği şey yeniden başlatınca geri gelmektir. Autoruns; Run anahtarları, Scheduled Tasks, Services, WMI, Winlogon, AppInit_DLLs ve daha onlarcasını tek ekranda listeler.
Kod:
# Komut satırı sürümü (otomatik rapor için) autorunsc64.exe -a * -c -h -s > C:\Temp\autoruns.csv
Pratik alışkanlıklarım:
  1. Options > Hide Microsoft Entries (dikkat: saldırgan Microsoft gibi görünen isimler kullanabilir; tam tarama da yapın).
  2. Verify Code Signatures açık olsun.
  3. Bilinmeyen publisher + User klasörü altında path = inceleyin.
  4. Scheduled Tasks'ta "powershell -enc" veya temp yolları = yüksek öncelik.
Temiz bir baseline'ı altın imajdan alıp şüpheli makineyle karşılaştırmak çok hızlandırır.

TCPView: kim dışarı bağlanıyor?
netstat güzeldir ama TCPView süreç adıyla birlikte canlı bağlantıyı gösterir. Şüpheli bir EXE'nin bilinmeyen bir IP:port'a ESTABLISHED olması, EDR yokken bile hızlı sinyaldir.
  • Options > Resolve Addresses: bazen kapatın (hız + DNS gürültüsü olmasın).
  • Şüpheli satırda sağ tık > Process Properties / Whois (dikkat: whois dışarı sorgu gönderir; hassas olayda önce IP'yi not alıp izole ortamda soruşturun).
PowerShell ile benzer bilgi:
Kod:
Get-NetTCPConnection -State Established | Select LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess | Format-Table -AutoSize
TCPView'in avantajı hız ve görsellik; betiğin avantajı otomatikleştirme.

USB müdahale çantamda neler var?
  • procexp64, autoruns64, tcpview64, handle64, listdlls64, sigcheck64, strings64
  • Küçük bir hash betiği (Get-FileHash) ve not defteri şablonu
  • Salt okunur çalıştırma alışkanlığı: mümkünse araçları USB'den çalıştır, çıktıyı ayrı kanıta yaz
sigcheck ile tek dosya imza kontrolü:
Kod:
sigcheck64.exe -accepteula -h C:\Users\Public\suspicious.exe

Sık tuzaklar
  • Aynı isimli meşru süreç: svchost.exe yolu C:\Windows\System32 dışında olmamalı.
  • DLL sideloading: meşru EXE + yanındaki şüpheli DLL; Process Explorer lower pane burada kurtarır.
  • Yalnızca GUI'ye güvenmek: çıktıyı CSV/log olarak alın, olay kaydına ekleyin.
  • Canlı sistemde "temizlik" yaparken kanıtı bozmak: önce topla, sonra müdahale et.

Mavi takım ile köprü
Bu üç araç L1/L2 analistin "elle doğrulama" katmanıdır. EDR varsa yine de kullanırım: EDR bazen aggregate gösterir, siz o anki süreci görürsünüz. Tespit kurallarınızı (4688, Sysmon 1/3/11, Prefetch) bu araçlarla çaprazlayın.

Kaynaklar
  • Microsoft Sysinternals resmi belgeleri
  • Windows Internals (süreç/handle modeli için)
  • SANS FOR500/FOR508 notları (canlı yanıt pratiği)

Sizin çantanızda olmazsa olmaz dördüncü araç hangisi? Ben ara sıra Process Monitor'ü de ekliyorum ama gürültüsü yüksek; filtre disiplini şart.

Process Monitor ne zaman devreye girer?
Procmon çok gürültülüdür; filtre olmadan açmayın. Senaryo: "Bu EXE hangi registry anahtarına yazıyor?" Operation is Registry + Process Name filtresi. Çıktıyı PML olarak kaydedip temiz makinede analiz edin. Canlı IR'de önce Process Explorer + Autoruns + TCPView; derinleşme gerekirse Procmon.

Imza ve hash'i ticket'a yazmak
sigcheck -h çıktısındaki SHA256'yı ticket'a ve MISP/IOC listesine ekleyin. "suspicious.exe" adı yetmez; ertesi gün dosya adı değişmiş olur. VirusTotal yüklemesi kurum politikasına bağlıdır; hassas örnekleri herkese açık VT'ye yüklemeyin, private instance veya iç sandbox kullanın.


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.

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-n04-799270.png (Dosya Boyutu: 69.41 KB / İndirme Sayısı: 10)

.png   n04-inner.png (Dosya Boyutu: 26.2 KB / İndirme Sayısı: 9) ]]> <![CDATA[WDAC mi AppLocker mi? Windows Uygulama Kontrolu 2026 Karsilastirmasi]]> https://www.turkteam.org/konu-wdac-mi-applocker-mi-windows-uygulama-kontrolu-2026-karsilastirmasi.html Sat, 17 Oct 2026 11:24:04 +0300 BilgeKagan]]> https://www.turkteam.org/konu-wdac-mi-applocker-mi-windows-uygulama-kontrolu-2026-karsilastirmasi.html [Resim: attachment.php?aid=90]
Herkese selam,

"Kullanici bilgisayarinda sadece onayli uygulamalar calissin" demek kulaga basit geliyor ama Windows tarafinda iki ayri teknoloji var ve hangisinin ne zaman kullanilacagi kafa karistiriyor: WDAC (Windows Defender Application Control) ve AppLocker. Bu konuda ikisini sade bir dille karsilastiracagim.

Konuda Anlatilacaklar
  1. Uygulama kontrolu neden gerekli?
  2. AppLocker ozellikleri ve sinirlari
  3. WDAC ozellikleri ve guc noktalari
  4. Hangi senaryoda hangisi?
  5. Guvenli baslangic adimlari

1) Neden Uygulama Kontrolu?
Antivirus "kotu bilineni" engeller; uygulama kontrolu ise "iyi bilinmeyen her seyi" engeller. Bu, fidye yazilimi ve bilinmeyen zararlilara karsi cok guclu bir yaklasimdir. Mantik, varsayilan-ret (default deny): listede olmayan calismaz.

2) AppLocker
AppLocker eski ama hala kullanisli. Grup Ilkesi ile yonetilir, kurallari yol, yayinci (imza) veya dosya hash'i uzerinden tanimlarsiniz. Etkili ilkeyi gormek icin:

Kod:
Get-AppLockerPolicy -Effective -Xml

Artilari: kurmasi gorece kolay, denetim (audit) modu var. Eksileri: cekirdek seviyesinde zorlanmaz, bazi atlatma teknikleri bilinir, Microsoft bunu artik birincil cozum olarak onermiyor.

3) WDAC
WDAC (yeni adiyla App Control for Business) cekirdek seviyesinde calisir ve cok daha guclu bir zorlama saglar. Politikayi XML olarak yazar, derleyip (.cip) dagitirsiniz. Surucu ve cekirdek bilesenlerini de kapsar.

[code># Ornek politika olusturma (New-CIPolicy)
New-CIPolicy -Level Publisher -FilePath .\policy.xml -UserPEs
ConvertFrom-CIPolicy .\policy.xml .\policy.cip[/code]

Artilari: cok guclu, imza/yayinci temelli, Intune ile olceklenir. Eksileri: ogrenme egrisi dik, yanlis yapilandirma sistemi kilitleyebilir, bu yuzden once audit modu sart.

4) Hangisi?
  • Yeni bir dagitim yapiyorsaniz ve modern yonetim (Intune) varsa: WDAC.
  • Hizli bir baslangic, GPO tabanli ortam, sinirli kaynak: AppLocker makul.
  • Microsoft'un yonu net: WDAC birincil, AppLocker tamamlayici.

5) Guvenli Baslangic
Hangisini secerseniz secin, altin kural ayni: once denetim modunda calistirin. Haftalarca log toplayip hangi mesru uygulamalarin engellenecegini gorun, listeyi olgunlastirin, sonra zorlamaya gecin. Dogrudan zorlama ile baslamak kullanicilarin isini durdurur.

Kaynaklar
Alıntı:Yasal not: Politikalari yalnizca yonettiginiz cihaz ve etki alanlarinda test edip uygulayin.


.png   bilgekagan-b03.png (Dosya Boyutu: 97.06 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=90]
Herkese selam,

"Kullanici bilgisayarinda sadece onayli uygulamalar calissin" demek kulaga basit geliyor ama Windows tarafinda iki ayri teknoloji var ve hangisinin ne zaman kullanilacagi kafa karistiriyor: WDAC (Windows Defender Application Control) ve AppLocker. Bu konuda ikisini sade bir dille karsilastiracagim.

Konuda Anlatilacaklar
  1. Uygulama kontrolu neden gerekli?
  2. AppLocker ozellikleri ve sinirlari
  3. WDAC ozellikleri ve guc noktalari
  4. Hangi senaryoda hangisi?
  5. Guvenli baslangic adimlari

1) Neden Uygulama Kontrolu?
Antivirus "kotu bilineni" engeller; uygulama kontrolu ise "iyi bilinmeyen her seyi" engeller. Bu, fidye yazilimi ve bilinmeyen zararlilara karsi cok guclu bir yaklasimdir. Mantik, varsayilan-ret (default deny): listede olmayan calismaz.

2) AppLocker
AppLocker eski ama hala kullanisli. Grup Ilkesi ile yonetilir, kurallari yol, yayinci (imza) veya dosya hash'i uzerinden tanimlarsiniz. Etkili ilkeyi gormek icin:

Kod:
Get-AppLockerPolicy -Effective -Xml

Artilari: kurmasi gorece kolay, denetim (audit) modu var. Eksileri: cekirdek seviyesinde zorlanmaz, bazi atlatma teknikleri bilinir, Microsoft bunu artik birincil cozum olarak onermiyor.

3) WDAC
WDAC (yeni adiyla App Control for Business) cekirdek seviyesinde calisir ve cok daha guclu bir zorlama saglar. Politikayi XML olarak yazar, derleyip (.cip) dagitirsiniz. Surucu ve cekirdek bilesenlerini de kapsar.

[code># Ornek politika olusturma (New-CIPolicy)
New-CIPolicy -Level Publisher -FilePath .\policy.xml -UserPEs
ConvertFrom-CIPolicy .\policy.xml .\policy.cip[/code]

Artilari: cok guclu, imza/yayinci temelli, Intune ile olceklenir. Eksileri: ogrenme egrisi dik, yanlis yapilandirma sistemi kilitleyebilir, bu yuzden once audit modu sart.

4) Hangisi?
  • Yeni bir dagitim yapiyorsaniz ve modern yonetim (Intune) varsa: WDAC.
  • Hizli bir baslangic, GPO tabanli ortam, sinirli kaynak: AppLocker makul.
  • Microsoft'un yonu net: WDAC birincil, AppLocker tamamlayici.

5) Guvenli Baslangic
Hangisini secerseniz secin, altin kural ayni: once denetim modunda calistirin. Haftalarca log toplayip hangi mesru uygulamalarin engellenecegini gorun, listeyi olgunlastirin, sonra zorlamaya gecin. Dogrudan zorlama ile baslamak kullanicilarin isini durdurur.

Kaynaklar
Alıntı:Yasal not: Politikalari yalnizca yonettiginiz cihaz ve etki alanlarinda test edip uygulayin.


.png   bilgekagan-b03.png (Dosya Boyutu: 97.06 KB / İndirme Sayısı: 6) ]]> <![CDATA[Windows 10/11 Ev Kullanıcısı Sıkılaştırma: 10 Dakikalık Kontrol Listesi]]> https://www.turkteam.org/konu-windows-10-11-ev-kullanicisi-sikilastirma-10-dakikalik-kontrol-listesi.html Fri, 16 Oct 2026 11:27:45 +0300 KulTigin]]> https://www.turkteam.org/konu-windows-10-11-ev-kullanicisi-sikilastirma-10-dakikalik-kontrol-listesi.html [Resim: attachment.php?aid=41]
Selam millet!

Kurumsal GPO yok, sadece kendi PC'niz var. Yine de yapılabilecekler var. Bu liste "mükemmel güvenlik" değil; ev kullanıcısı için hızlı kazanımlar.

Kontrol Listesi
  1. Windows Update açık ve güncel. Win10 ise ESU durumunuzu kontrol edin (12 Ekim 2027'ye kadar consumer ESU).
  2. BitLocker veya cihaz şifreleme: Settings > Privacy & security > Device encryption (donanım destekliyorsa).
  3. Windows Hello / PIN + güçlü hesap parolası
  4. Smart App Control veya en azından SmartScreen açık (lab değilse)
  5. Yerel admin sayısını azaltın: günlük kullanıcı Standard User olsun
  6. UAC'ı kapatmayın
  7. Gereksiz uzak masaüstü / SMBv1 kapalı
  8. Tarayıcı: güncel, az uzantı, ayrı profil (banka / günlük)
  9. Yedek: 3-2-1 kuralına yaklaşın (en az bir offline/yerel kopya)
  10. Parola yöneticisi + 2FA (bir sonraki konuda detay)

PowerShell ile hızlı bakış (yönetici):
Kod:
Get-LocalUser | Format-Table Name, Enabled, LastLogon Get-BitLockerVolume -ErrorAction SilentlyContinue

Lab VM'lerinde bunları bilerek gevşetirsiniz; günlük PC'de gevşetmeyin.

Kaynaklar
Sizin listede eksik gördüğünüz madde? Yazın.

Kapak: özgün TurkTeam görseli.

.png   kultigin-09.png (Dosya Boyutu: 86.33 KB / İndirme Sayısı: 18) ]]> [Resim: attachment.php?aid=41]
Selam millet!

Kurumsal GPO yok, sadece kendi PC'niz var. Yine de yapılabilecekler var. Bu liste "mükemmel güvenlik" değil; ev kullanıcısı için hızlı kazanımlar.

Kontrol Listesi
  1. Windows Update açık ve güncel. Win10 ise ESU durumunuzu kontrol edin (12 Ekim 2027'ye kadar consumer ESU).
  2. BitLocker veya cihaz şifreleme: Settings > Privacy & security > Device encryption (donanım destekliyorsa).
  3. Windows Hello / PIN + güçlü hesap parolası
  4. Smart App Control veya en azından SmartScreen açık (lab değilse)
  5. Yerel admin sayısını azaltın: günlük kullanıcı Standard User olsun
  6. UAC'ı kapatmayın
  7. Gereksiz uzak masaüstü / SMBv1 kapalı
  8. Tarayıcı: güncel, az uzantı, ayrı profil (banka / günlük)
  9. Yedek: 3-2-1 kuralına yaklaşın (en az bir offline/yerel kopya)
  10. Parola yöneticisi + 2FA (bir sonraki konuda detay)

PowerShell ile hızlı bakış (yönetici):
Kod:
Get-LocalUser | Format-Table Name, Enabled, LastLogon Get-BitLockerVolume -ErrorAction SilentlyContinue

Lab VM'lerinde bunları bilerek gevşetirsiniz; günlük PC'de gevşetmeyin.

Kaynaklar
Sizin listede eksik gördüğünüz madde? Yazın.

Kapak: özgün TurkTeam görseli.

.png   kultigin-09.png (Dosya Boyutu: 86.33 KB / İndirme Sayısı: 18) ]]> <![CDATA[Windows 11 Smart App Control: KB5079391 ile Yeniden Kurulum Olmadan Açma]]> https://www.turkteam.org/konu-windows-11-smart-app-control-kb5079391-ile-yeniden-kurulum-olmadan-acma.html Fri, 16 Oct 2026 11:21:08 +0300 KulTigin]]> https://www.turkteam.org/konu-windows-11-smart-app-control-kb5079391-ile-yeniden-kurulum-olmadan-acma.html [Resim: attachment.php?aid=33]
Selam millet!

Windows 11'de Smart App Control (SAC) ilk günden beri güzel bir fikir: imzasız/şüpheli uygulamaları engelleyen bir katman. Ama bir sorun vardı: bir kez kapattıysanız (veya Evaluation'dan Off'a düştüyse) tekrar açmak için çoğu zaman temiz kurulum gerekiyordu. Mart 2026'da gelen isteğe bağlı güncelleme KB5079391 bunu değiştirdi. Notlarımı paylaşıyorum.

Ne Değişti?
Microsoft'un KB5079391 notlarına göre (24H2 ve 25H2, build 26100.8116 / 26200.8116), Smart App Control artık temiz kurulum olmadan açılıp kapatılabiliyor:

Settings > Windows Security > App & browser control > Smart App Control settings > On

BleepingComputer'ın 27 Mart 2026 haberinde de aynı duyuru özetleniyor. Not: Microsoft, 0x80073712 kurulum hataları nedeniyle KB5079391 dağıtımını bir süre duraklatmıştı; cihazınızda görmüyorsanız Windows Update'ten veya Microsoft Update Catalog'dan tekrar deneyin, güncel kümülatiflere bakın.

Kimler İçin Mantıklı?
  • Günlük kullanım PC'si, sadece imzalı yazılımlar
  • Aile / ebeveyn kontrollü cihazlar
  • "Her .exe'yi çalıştırırım" lab makinesi için DEĞİL - geliştirici veya pentest lab'ında SAC can sıkar

Lab VM'lerimde SAC'ı kapalı tutuyorum; asıl Windows'umda Evaluation veya On tercih ediyorum.

Windows 10 Kullananlar İçin Ara Not
Windows 10 resmi desteği 14 Ekim 2025'te bitti. Consumer ESU programı kritik/önemli güvenlik güncellemelerini 12 Ekim 2027'ye kadar uzatıyor (Microsoft'un ESU sayfası). Ücretsiz (PC Settings sync), 1000 Rewards puanı veya tek seferlik ücretle kayıt mümkün; koşullar ve bölgesel farklar için resmi sayfaya bakın. Uzun vadede Windows 11'e geçmek hâlâ en temiz çözüm.

Kaynaklar
Siz SAC kullanıyor musunuz, lab'da kapalı mı? Yorumlara yazın.

Alıntı:Not: Güvenlik özelliklerini körlemesine açmak yerine kullanım senaryonuza göre seçin. Registry "workarounds" resmi destek kapsamında olmayabilir.

Kapak: özgün TurkTeam görseli.

.png   kultigin-05.png (Dosya Boyutu: 91.76 KB / İndirme Sayısı: 10) ]]> [Resim: attachment.php?aid=33]
Selam millet!

Windows 11'de Smart App Control (SAC) ilk günden beri güzel bir fikir: imzasız/şüpheli uygulamaları engelleyen bir katman. Ama bir sorun vardı: bir kez kapattıysanız (veya Evaluation'dan Off'a düştüyse) tekrar açmak için çoğu zaman temiz kurulum gerekiyordu. Mart 2026'da gelen isteğe bağlı güncelleme KB5079391 bunu değiştirdi. Notlarımı paylaşıyorum.

Ne Değişti?
Microsoft'un KB5079391 notlarına göre (24H2 ve 25H2, build 26100.8116 / 26200.8116), Smart App Control artık temiz kurulum olmadan açılıp kapatılabiliyor:

Settings > Windows Security > App & browser control > Smart App Control settings > On

BleepingComputer'ın 27 Mart 2026 haberinde de aynı duyuru özetleniyor. Not: Microsoft, 0x80073712 kurulum hataları nedeniyle KB5079391 dağıtımını bir süre duraklatmıştı; cihazınızda görmüyorsanız Windows Update'ten veya Microsoft Update Catalog'dan tekrar deneyin, güncel kümülatiflere bakın.

Kimler İçin Mantıklı?
  • Günlük kullanım PC'si, sadece imzalı yazılımlar
  • Aile / ebeveyn kontrollü cihazlar
  • "Her .exe'yi çalıştırırım" lab makinesi için DEĞİL - geliştirici veya pentest lab'ında SAC can sıkar

Lab VM'lerimde SAC'ı kapalı tutuyorum; asıl Windows'umda Evaluation veya On tercih ediyorum.

Windows 10 Kullananlar İçin Ara Not
Windows 10 resmi desteği 14 Ekim 2025'te bitti. Consumer ESU programı kritik/önemli güvenlik güncellemelerini 12 Ekim 2027'ye kadar uzatıyor (Microsoft'un ESU sayfası). Ücretsiz (PC Settings sync), 1000 Rewards puanı veya tek seferlik ücretle kayıt mümkün; koşullar ve bölgesel farklar için resmi sayfaya bakın. Uzun vadede Windows 11'e geçmek hâlâ en temiz çözüm.

Kaynaklar
Siz SAC kullanıyor musunuz, lab'da kapalı mı? Yorumlara yazın.

Alıntı:Not: Güvenlik özelliklerini körlemesine açmak yerine kullanım senaryonuza göre seçin. Registry "workarounds" resmi destek kapsamında olmayabilir.

Kapak: özgün TurkTeam görseli.

.png   kultigin-05.png (Dosya Boyutu: 91.76 KB / İndirme Sayısı: 10) ]]>