<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Mavi Takım / SOC]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:37 +0000 MyBB <![CDATA[EPSS ile Yama Önceliklendirme: CVSS Yüksek Ama Önce Hangi Açığı Kapatmalı?]]> https://www.turkteam.org/konu-epss-ile-yama-onceliklendirme-cvss-yuksek-ama-once-hangi-acigi-kapatmali.html Sun, 25 Oct 2026 11:53:51 +0300 KulTigin]]> https://www.turkteam.org/konu-epss-ile-yama-onceliklendirme-cvss-yuksek-ama-once-hangi-acigi-kapatmali.html [Resim: attachment.php?aid=440]
Selamlar,

Oracle'ın tek seferde 1.295 yama çıkardığı bir dünyada "önce hangi açığı kapatalım?" sorusu mavi takımların en kritik kararı. Yıllardır tek ölçüt CVSS'ti; ama CVSS ciddiyeti ölçer, sömürülme olasılığını değil. İşte burada EPSS (Exploit Prediction Scoring System) devreye giriyor. Bu rehberde EPSS nedir, CVSS'ten farkı ne ve pratikte nasıl kullanılır, ele alıyorum.

Konuda anlatılacaklar
  1. EPSS nedir?
  2. CVSS ile farkı
  3. API ile sorgulama
  4. KEV ile birleştirme
  5. Pratik önceliklendirme akışı

1. EPSS nedir?
EPSS, FIRST tarafından geliştirilen, bir CVE'nin önümüzdeki 30 gün içinde vahşi doğada sömürülme olasılığını 0-1 arası bir skorla tahmin eden bir modeldir. 0.96 skor, yüksek sömürülme olasılığı; 0.01 ise düşük anlamına gelir. Model günlük güncellenir.

2. CVSS ile farkı
  • CVSS: "Bu açık sömürülürse ne kadar kötü olur?" (ciddiyet, statik)
  • EPSS: "Bu açık yakın zamanda sömürülür mü?" (olasılık, dinamik)
İkisi birbirini tamamlar. Yüksek CVSS + düşük EPSS bir açık, yüksek CVSS + yüksek EPSS bir açıkla aynı aciliyette değildir. Kaynaklar kısıtlıysa, yüksek EPSS'li olanları öne almak sömürülecek açığı kapatma olasılığınızı artırır.

3. API ile sorgulama
EPSS API'si ücretsiz ve kimlik doğrulamasız:
Kod:
# Tek CVE curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-0257" | python3 -m json.tool # Birden fazla CVE curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-0257,CVE-2026-111497" # EPSS'i 0.9 üstü olanları listele curl -s "https://api.first.org/data/v1/epss?epss-gt=0.9&limit=50"
Örnek bir toplu sıralama scripti:
Kod:
import requests cves = ["CVE-2026-0257","CVE-2026-111497","CVE-2025-64446"] r = requests.get("https://api.first.org/data/v1/epss", params={"cve": ",".join(cves)}) data = sorted(r.json()["data"], key=lambda d: float(d["epss"]), reverse=True) for d in data: print(f"{d['cve']} EPSS={float(d['epss']):.4f} pct={d['percentile']}")

4. KEV ile birleştirme
CISA'nın Known Exploited Vulnerabilities (KEV) kataloğu, zaten aktif sömürülen açıkların listesidir. Bir CVE KEV'deyse, EPSS tahminine gerek kalmadan en yüksek önceliktir; çünkü olasılık değil, gerçekleşmiş sömürüdür.
Kod:
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | python3 -c "import sys,json;print(len(json.load(sys.stdin)['vulnerabilities']),'KEV kaydi')"

5. Pratik önceliklendirme akışı
  1. KEV'de mi? Evetse -> hemen yama (en yüksek öncelik).
  2. EPSS yüksek mi (örn. > 0.5)? Evetse -> acil sıraya al.
  3. CVSS kritik + internete dönük mü? Evetse -> yüksek öncelik.
  4. Varlık kritikliği ile ağırlıklandır; kritik sistemleri öne al.
  5. Düşük EPSS + düşük maruziyet -> normal bakım döngüsüne bırak.

Sonuç
CVSS tek başına "neyi önce yamalamalı" sorusunu yanıtlamaz. KEV (gerçekleşen sömürü) + EPSS (sömürü olasılığı) + varlık kritikliği üçlüsü, kısıtlı kaynakları en çok sömürülecek açıklara yöneltir. Siz yama önceliklendirmede EPSS/KEV kullanıyor 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   20-t20-epss-yama-onceliklendirme.png (Dosya Boyutu: 120.54 KB / İndirme Sayısı: 3) ]]> [Resim: attachment.php?aid=440]
Selamlar,

Oracle'ın tek seferde 1.295 yama çıkardığı bir dünyada "önce hangi açığı kapatalım?" sorusu mavi takımların en kritik kararı. Yıllardır tek ölçüt CVSS'ti; ama CVSS ciddiyeti ölçer, sömürülme olasılığını değil. İşte burada EPSS (Exploit Prediction Scoring System) devreye giriyor. Bu rehberde EPSS nedir, CVSS'ten farkı ne ve pratikte nasıl kullanılır, ele alıyorum.

Konuda anlatılacaklar
  1. EPSS nedir?
  2. CVSS ile farkı
  3. API ile sorgulama
  4. KEV ile birleştirme
  5. Pratik önceliklendirme akışı

1. EPSS nedir?
EPSS, FIRST tarafından geliştirilen, bir CVE'nin önümüzdeki 30 gün içinde vahşi doğada sömürülme olasılığını 0-1 arası bir skorla tahmin eden bir modeldir. 0.96 skor, yüksek sömürülme olasılığı; 0.01 ise düşük anlamına gelir. Model günlük güncellenir.

2. CVSS ile farkı
  • CVSS: "Bu açık sömürülürse ne kadar kötü olur?" (ciddiyet, statik)
  • EPSS: "Bu açık yakın zamanda sömürülür mü?" (olasılık, dinamik)
İkisi birbirini tamamlar. Yüksek CVSS + düşük EPSS bir açık, yüksek CVSS + yüksek EPSS bir açıkla aynı aciliyette değildir. Kaynaklar kısıtlıysa, yüksek EPSS'li olanları öne almak sömürülecek açığı kapatma olasılığınızı artırır.

3. API ile sorgulama
EPSS API'si ücretsiz ve kimlik doğrulamasız:
Kod:
# Tek CVE curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-0257" | python3 -m json.tool # Birden fazla CVE curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-0257,CVE-2026-111497" # EPSS'i 0.9 üstü olanları listele curl -s "https://api.first.org/data/v1/epss?epss-gt=0.9&limit=50"
Örnek bir toplu sıralama scripti:
Kod:
import requests cves = ["CVE-2026-0257","CVE-2026-111497","CVE-2025-64446"] r = requests.get("https://api.first.org/data/v1/epss", params={"cve": ",".join(cves)}) data = sorted(r.json()["data"], key=lambda d: float(d["epss"]), reverse=True) for d in data: print(f"{d['cve']} EPSS={float(d['epss']):.4f} pct={d['percentile']}")

4. KEV ile birleştirme
CISA'nın Known Exploited Vulnerabilities (KEV) kataloğu, zaten aktif sömürülen açıkların listesidir. Bir CVE KEV'deyse, EPSS tahminine gerek kalmadan en yüksek önceliktir; çünkü olasılık değil, gerçekleşmiş sömürüdür.
Kod:
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | python3 -c "import sys,json;print(len(json.load(sys.stdin)['vulnerabilities']),'KEV kaydi')"

5. Pratik önceliklendirme akışı
  1. KEV'de mi? Evetse -> hemen yama (en yüksek öncelik).
  2. EPSS yüksek mi (örn. > 0.5)? Evetse -> acil sıraya al.
  3. CVSS kritik + internete dönük mü? Evetse -> yüksek öncelik.
  4. Varlık kritikliği ile ağırlıklandır; kritik sistemleri öne al.
  5. Düşük EPSS + düşük maruziyet -> normal bakım döngüsüne bırak.

Sonuç
CVSS tek başına "neyi önce yamalamalı" sorusunu yanıtlamaz. KEV (gerçekleşen sömürü) + EPSS (sömürü olasılığı) + varlık kritikliği üçlüsü, kısıtlı kaynakları en çok sömürülecek açıklara yöneltir. Siz yama önceliklendirmede EPSS/KEV kullanıyor 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   20-t20-epss-yama-onceliklendirme.png (Dosya Boyutu: 120.54 KB / İndirme Sayısı: 3) ]]> <![CDATA[Microsoft 365 Token Spreying: 79 Kurumda 497 Başarılı Giriş, Parola Yok]]> https://www.turkteam.org/konu-microsoft-365-token-spreying-79-kurumda-497-basarili-giris-parola-yok.html Sat, 24 Oct 2026 11:23:14 +0300 Tonyukuk]]> https://www.turkteam.org/konu-microsoft-365-token-spreying-79-kurumda-497-basarili-giris-parola-yok.html [Resim: attachment.php?aid=397]
Selamlar,

Huntress, 14 Temmuz - 22 Eylül 2026 arasında Microsoft 365 hesaplarına yönelik bir token spreying / replay kampanyası belgelendirdi. 79 kurumda en az 497 başarılı oturum, 200.000'den fazla başarısız deneme. Parola gerekmedi: AiTM (adversary-in-the-middle) ile MFA sonrası alınan oturum jetonları Alman barındırma sağlayıcısı 1337 Services GmbH (AS210558) IP blokundan yeniden oynatıldı. Bu konu SOC için tespit ve müdahale notları.

Konuda anlatılacaklar
  1. Saldırı nasıl işliyor?
  2. Altyapı ve IOC'ler
  3. Ele geçirme sonrası davranış
  4. Conditional Access neden kritik?
  5. Olay müdahalesi kontrol listesi

1. Saldırı nasıl işliyor?
Kurban sahte veya araya giren bir giriş sayfasından MFA'yı tamamlıyor; röle jetonu tutuyor. Dakikalar içinde aynı oturum 1337 Services adresinden görünüyor. Huntress buna "token spraying" diyor: parola spreying'in jeton hali. Kaynaklar: AiTM röleleri, cihaz kodu (device-code) phishing ve sosyal mühendislik.

2. Altyapı ve IOC'ler
Ana yeniden oynatma bloğu: 193.26.115[.]0/24. Öne çıkan adresler: .221, .199, .16, .21, .72, .210. Build A: node kullanıcı aracısı + OAuth2:Token + sahte Entra cihazı (DESKTOP- + 8 hex karakter). Build B: tarayıcı oturumu yeniden oynatma. En az 48 sahte cihaz kaydı görülmüş.

3. Ele geçirme sonrası
  • Mevcut MFA yöntemlerini silip kendi authenticator'larını ekleme (19 kurumda ilk 3 saat içinde).
  • Gizli gelen kutusu kuralları: ".", "sss", "s", "d" gibi kısa isimler; RSS Feeds / Conversation History'ye taşıma.
  • Bir vakada maaş bordrosu temalı dışarı e-posta.
Parola sıfırlamak tek başına yetmez; jeton, cihaz ve MFA yöntemi kalır.

4. Conditional Access
Phase 3'te aynı saldırgan IP'sinden 1.052 engellenmiş giriş yalnızca dört kurumdan gelmiş; 29 kurumda ise hiçbir şey engel olmamış. Huntress önerisi: All Users + All Cloud Apps + All Client Apps için koşulsuz MFA veya engelleme. Cihaz kodu akışını authentication-flow politikalarıyla kısıtlayın.

5. Müdahale kontrol listesi
  1. Oturumları iptal edin (revoke) ve parolayı sıfırlayın.
  2. Entra cihazlarını denetleyin; DESKTOP- + 8 hex kalıbını doğrulayarak silin.
  3. MFA yöntemlerini denetleyin; tanınmayan authenticator'ı kaldırın.
  4. Gelen kutusu kurallarını (özellikle kısa/noktalama isimli) inceleyin.
  5. Hosting IP'lerinden OAuth2:Token / Device Registration Service girişlerini avlayın.
  6. AADSTS53003 (Conditional Access engeli) geçerli kimlik bilgisi işaretidir; "kurtardık" sanmayın.

Tenant'ınızda Conditional Access tüm istemci uygulamalarını kapsıyor mu, yoksa boşluklar 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   08-t08-m365-token-spray.png (Dosya Boyutu: 123.79 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=397]
Selamlar,

Huntress, 14 Temmuz - 22 Eylül 2026 arasında Microsoft 365 hesaplarına yönelik bir token spreying / replay kampanyası belgelendirdi. 79 kurumda en az 497 başarılı oturum, 200.000'den fazla başarısız deneme. Parola gerekmedi: AiTM (adversary-in-the-middle) ile MFA sonrası alınan oturum jetonları Alman barındırma sağlayıcısı 1337 Services GmbH (AS210558) IP blokundan yeniden oynatıldı. Bu konu SOC için tespit ve müdahale notları.

Konuda anlatılacaklar
  1. Saldırı nasıl işliyor?
  2. Altyapı ve IOC'ler
  3. Ele geçirme sonrası davranış
  4. Conditional Access neden kritik?
  5. Olay müdahalesi kontrol listesi

1. Saldırı nasıl işliyor?
Kurban sahte veya araya giren bir giriş sayfasından MFA'yı tamamlıyor; röle jetonu tutuyor. Dakikalar içinde aynı oturum 1337 Services adresinden görünüyor. Huntress buna "token spraying" diyor: parola spreying'in jeton hali. Kaynaklar: AiTM röleleri, cihaz kodu (device-code) phishing ve sosyal mühendislik.

2. Altyapı ve IOC'ler
Ana yeniden oynatma bloğu: 193.26.115[.]0/24. Öne çıkan adresler: .221, .199, .16, .21, .72, .210. Build A: node kullanıcı aracısı + OAuth2:Token + sahte Entra cihazı (DESKTOP- + 8 hex karakter). Build B: tarayıcı oturumu yeniden oynatma. En az 48 sahte cihaz kaydı görülmüş.

3. Ele geçirme sonrası
  • Mevcut MFA yöntemlerini silip kendi authenticator'larını ekleme (19 kurumda ilk 3 saat içinde).
  • Gizli gelen kutusu kuralları: ".", "sss", "s", "d" gibi kısa isimler; RSS Feeds / Conversation History'ye taşıma.
  • Bir vakada maaş bordrosu temalı dışarı e-posta.
Parola sıfırlamak tek başına yetmez; jeton, cihaz ve MFA yöntemi kalır.

4. Conditional Access
Phase 3'te aynı saldırgan IP'sinden 1.052 engellenmiş giriş yalnızca dört kurumdan gelmiş; 29 kurumda ise hiçbir şey engel olmamış. Huntress önerisi: All Users + All Cloud Apps + All Client Apps için koşulsuz MFA veya engelleme. Cihaz kodu akışını authentication-flow politikalarıyla kısıtlayın.

5. Müdahale kontrol listesi
  1. Oturumları iptal edin (revoke) ve parolayı sıfırlayın.
  2. Entra cihazlarını denetleyin; DESKTOP- + 8 hex kalıbını doğrulayarak silin.
  3. MFA yöntemlerini denetleyin; tanınmayan authenticator'ı kaldırın.
  4. Gelen kutusu kurallarını (özellikle kısa/noktalama isimli) inceleyin.
  5. Hosting IP'lerinden OAuth2:Token / Device Registration Service girişlerini avlayın.
  6. AADSTS53003 (Conditional Access engeli) geçerli kimlik bilgisi işaretidir; "kurtardık" sanmayın.

Tenant'ınızda Conditional Access tüm istemci uygulamalarını kapsıyor mu, yoksa boşluklar 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   08-t08-m365-token-spray.png (Dosya Boyutu: 123.79 KB / İndirme Sayısı: 2) ]]> <![CDATA[SIEM'e Log Almadan Önce: NTP Saat Senkronu Neden Kritik]]> https://www.turkteam.org/konu-siem-e-log-almadan-once-ntp-saat-senkronu-neden-kritik.html Mon, 19 Oct 2026 01:33:19 +0300 BilgeKagan]]> https://www.turkteam.org/konu-siem-e-log-almadan-once-ntp-saat-senkronu-neden-kritik.html [Resim: attachment.php?aid=281]
Merhaba,

SIEM'e log akıtmaya başlamadan önce en sık atlanan konu: saat senkronu. Dağınık zaman damgaları korelasyonu öldürür; saldırı zaman çizelgesi güveneceği kalmaz. Bu yazıda neden kritik olduğunu ve Linux'ta chrony ile nasıl düzelteceğinizi anlatıyorum.

Ne bozulur?
  • Aynı oturumun firewall logu 14:01, sunucu auth logu 13:48 görünür
  • Kerberos / sertifika doğrulama hataları (saat kayması)
  • SIEM kuralı "5 dakika içinde 10 fail" eşiğini kaçırır veya yanlış tetikler
  • Adli zaman çizelgesi mahkemede / postmortem'de çöker

chrony kurulumu (Debian/Ubuntu)
Kod:
sudo apt install chrony sudo systemctl enable --now chrony chronyc tracking chronyc sources -v
Reference ID ve System time satırlarına bakın. "Last offset" mikrosaniye-milisaniye bandındaysa iyidir; saniyelerce kayma varsa kaynak veya firewall UDP/123 sorununa bakın.

[Resim: attachment.php?aid=282]

Kaynak seçimi
Kurumsal ortamda iç NTP (domain controller veya dedicated NTP) kullanın. Ev labında pool.ntp.org veya ülkenizdeki pool uygun olabilir. /etc/chrony/chrony.conf örneği:
Kod:
server time.cloudflare.com iburst server 0.tr.pool.ntp.org iburst makestep 1.0 3 rtcsync
Değişince:
Kod:
sudo systemctl restart chrony chronyc tracking

Windows tarafı (kısa)
Domain'e üyeyse genelde DC'den alır. Workgroup labında:
Kod:
w32tm /query /status w32tm /resync
Hyper-V / VMware misafirlerinde host zaman senkronu ile guest NTP çakışabilir; tek kaynak seçin.

SIEM kontrol listesi
  1. Tüm kaynaklarda UTC mi, yoksa local time mı? Belgeleyin.
  2. Normalize ederken timezone alanını koruyun.
  3. Dashboard'a "en çok kayan host" paneli koyun (offset metric).
  4. Yeni kaynak onboarding: önce NTP, sonra agent.

Hızlı teşhis
Kod:
timedatectl timedatectl show-timesync # veya chronyc makestep
Konteynerlerde host saati geçer; VM'lerde RTC + NTP birlikte düşünülmeli.

Kaynaklar
  • chrony resmi dokümantasyon
  • RFC 5905 (NTP)
  • NIST zaman hizmetleri bilgilendirmeleri

Sizin SIEM'inizde saat kaymasından doğan en komik (veya acı) yanlış alarm neydi?

Virtualizasyon tuzakları
VMware Tools / Hyper-V time sync host'u kaynak alırken guest chrony de dış NTP'ye giderse osilasyon görürsünüz. Tek kaynak seçin. Snapshot'a geri dönüş eski saate de döndürebilir; snapshot sonrası chronyc makestep düşünün.

Dağıtık izleme metriği
node_exporter veya osquery ile chrony offset metriğini Prometheus'a alın; 100ms üstü için alarm. SIEM'den önce bu alarm çoğu "garip korelasyon" ticket'ını önler.


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-n16-e0f08e.png (Dosya Boyutu: 62.97 KB / İndirme Sayısı: 13)

.png   n16-inner.png (Dosya Boyutu: 21.26 KB / İndirme Sayısı: 14) ]]> [Resim: attachment.php?aid=281]
Merhaba,

SIEM'e log akıtmaya başlamadan önce en sık atlanan konu: saat senkronu. Dağınık zaman damgaları korelasyonu öldürür; saldırı zaman çizelgesi güveneceği kalmaz. Bu yazıda neden kritik olduğunu ve Linux'ta chrony ile nasıl düzelteceğinizi anlatıyorum.

Ne bozulur?
  • Aynı oturumun firewall logu 14:01, sunucu auth logu 13:48 görünür
  • Kerberos / sertifika doğrulama hataları (saat kayması)
  • SIEM kuralı "5 dakika içinde 10 fail" eşiğini kaçırır veya yanlış tetikler
  • Adli zaman çizelgesi mahkemede / postmortem'de çöker

chrony kurulumu (Debian/Ubuntu)
Kod:
sudo apt install chrony sudo systemctl enable --now chrony chronyc tracking chronyc sources -v
Reference ID ve System time satırlarına bakın. "Last offset" mikrosaniye-milisaniye bandındaysa iyidir; saniyelerce kayma varsa kaynak veya firewall UDP/123 sorununa bakın.

[Resim: attachment.php?aid=282]

Kaynak seçimi
Kurumsal ortamda iç NTP (domain controller veya dedicated NTP) kullanın. Ev labında pool.ntp.org veya ülkenizdeki pool uygun olabilir. /etc/chrony/chrony.conf örneği:
Kod:
server time.cloudflare.com iburst server 0.tr.pool.ntp.org iburst makestep 1.0 3 rtcsync
Değişince:
Kod:
sudo systemctl restart chrony chronyc tracking

Windows tarafı (kısa)
Domain'e üyeyse genelde DC'den alır. Workgroup labında:
Kod:
w32tm /query /status w32tm /resync
Hyper-V / VMware misafirlerinde host zaman senkronu ile guest NTP çakışabilir; tek kaynak seçin.

SIEM kontrol listesi
  1. Tüm kaynaklarda UTC mi, yoksa local time mı? Belgeleyin.
  2. Normalize ederken timezone alanını koruyun.
  3. Dashboard'a "en çok kayan host" paneli koyun (offset metric).
  4. Yeni kaynak onboarding: önce NTP, sonra agent.

Hızlı teşhis
Kod:
timedatectl timedatectl show-timesync # veya chronyc makestep
Konteynerlerde host saati geçer; VM'lerde RTC + NTP birlikte düşünülmeli.

Kaynaklar
  • chrony resmi dokümantasyon
  • RFC 5905 (NTP)
  • NIST zaman hizmetleri bilgilendirmeleri

Sizin SIEM'inizde saat kaymasından doğan en komik (veya acı) yanlış alarm neydi?

Virtualizasyon tuzakları
VMware Tools / Hyper-V time sync host'u kaynak alırken guest chrony de dış NTP'ye giderse osilasyon görürsünüz. Tek kaynak seçin. Snapshot'a geri dönüş eski saate de döndürebilir; snapshot sonrası chronyc makestep düşünün.

Dağıtık izleme metriği
node_exporter veya osquery ile chrony offset metriğini Prometheus'a alın; 100ms üstü için alarm. SIEM'den önce bu alarm çoğu "garip korelasyon" ticket'ını önler.


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-n16-e0f08e.png (Dosya Boyutu: 62.97 KB / İndirme Sayısı: 13)

.png   n16-inner.png (Dosya Boyutu: 21.26 KB / İndirme Sayısı: 14) ]]> <![CDATA[MITRE ATT&CK ile Detection Coverage Haritası: Boşlukları Görmek]]> https://www.turkteam.org/konu-mitre-att-ck-ile-detection-coverage-haritasi-bosluklari-gormek.html Mon, 19 Oct 2026 01:31:56 +0300 BilgeKagan]]> https://www.turkteam.org/konu-mitre-att-ck-ile-detection-coverage-haritasi-bosluklari-gormek.html [Resim: attachment.php?aid=279]
Merhaba,

"SIEM'de 2000 kuralımız var" demek coverage demek değildir. MITRE ATT&CK ile detection coverage haritası, hangi tekniklerde kör olduğunuzu gösterir. Bu yazıda küçük bir SOC'un Excel/Spreadsheet ile bile yapabileceği pratik yöntemi anlatıyorum.

ATT&CK'ı ne kadar derin kullanmalı?
Enterprise matrisinde yüzlerce teknik var. Hepsini yeşile boyamak hedef değil. Önce kurumunuza uygun tehdit modeli: ransomware, BEC, içeriden tehdit, tedarik zinciri... Sonra ilgili tactic/technique alt kümesi.

Basit harita nasıl kurulur?
Satırlar: Technique ID (ör. T1003.001). Sütunlar: Veri kaynağı (process, auth, dns, proxy, endpoint), Kural var mı?, Test edildi mi?, Son test tarihi, Sahip.
Renk:
  • Yeşil: tespit var + son 90 günde test edildi
  • Sarı: kural var ama test yok / yüksek FP
  • Kırmızı: veri var, kural yok
  • Gri: veri yok (önce telemetri)

[Resim: attachment.php?aid=280]

Veri kaynağı gerçekliği
Kural yazmadan önce telemetri var mı bakın. Process Command Line yoksa "suspicious powershell" kuralı hayaldir. Windows'ta en azından:
  • Security 4624/4625/4688
  • Sysmon 1/3/7/11 (mümkünse)
  • DNS / proxy log
  • Kimlik sağlayıcı (AD / Entra) audit

Atomik test ile doğrulama
Red Canary Atomic Red Team gibi kontrollü testler (yalnız kendi lab/izinli ortam) kuralın gerçekten tuttuğunu gösterir. Test sonrası:
Kod:
# Örnek düşünce: T1059.001 PowerShell # 1) Atomik testi labda çalıştır # 2) SIEM'de alarm geldi mi? # 3) Gelmediyse: telemetri mi eksik, kural mı yanlış?
Üretimde rastgele atomik çalıştırmayın; change penceresi ve izin şart.

Önceliklendirme
  1. Kritik varlıkları etkileyen teknikler
  2. Son 12 ayda sektörünüzde görülen teknikler
  3. Kolay kazanım: telemetrisi hazır, kuralı basit olanlar
Raporu yönetime "yüzde 80 coverage" diye sunmak yerine "ransomware kill chain'de 3 kör nokta" diye sunun; aksiyon çıkar.

Yaygın kör noktalar
  • Living-off-the-land (LOLBins) — imza ile zor
  • Bulut yönetim düzlemi (Azure/AWS API) — endpoint odaklı SOC kaçırır
  • Mac/Linux endpoint telemetrisi eksikliği
  • E-posta kimlik doğrulama loglarının SIEM'e gelmemesi

Kaynaklar
  • MITRE ATT&CK resmi site
  • ATT&CK Navigator (katman dosyası paylaşımı)
  • Atomic Red Team
  • SigmaHQ (kural fikirleri)

Siz coverage'ı Navigator ile mi, yoksa servis kataloğuyla mı yönetiyorsunuz? Küçük ekip deneyimleri özellikle değerli.

Navigator katmanı paylaşımı
ATT&CK Navigator JSON katmanını ekipler arası paylaşmak, Excel renginden daha taşınabilirdir. Her major detection eklenince katmanı güncelleyin; çeyreklik gözden geçirmede kırmızı tekniklerden 3 tanesini yeşile çekme hedefi koyun.

Threat-informed defense
Sektörünüze ait tehdit raporlarındaki technique ID'leri haritaya "priority" olarak işaretleyin. Genel matris yüzdesi yerine "bu çeyrek ransomware zinciri coverage" KPI'sı yönetime daha anlamlı gelir.


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.

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-n14-b7a5dc.png (Dosya Boyutu: 68.67 KB / İndirme Sayısı: 8)

.png   n14-inner.png (Dosya Boyutu: 19.9 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=279]
Merhaba,

"SIEM'de 2000 kuralımız var" demek coverage demek değildir. MITRE ATT&CK ile detection coverage haritası, hangi tekniklerde kör olduğunuzu gösterir. Bu yazıda küçük bir SOC'un Excel/Spreadsheet ile bile yapabileceği pratik yöntemi anlatıyorum.

ATT&CK'ı ne kadar derin kullanmalı?
Enterprise matrisinde yüzlerce teknik var. Hepsini yeşile boyamak hedef değil. Önce kurumunuza uygun tehdit modeli: ransomware, BEC, içeriden tehdit, tedarik zinciri... Sonra ilgili tactic/technique alt kümesi.

Basit harita nasıl kurulur?
Satırlar: Technique ID (ör. T1003.001). Sütunlar: Veri kaynağı (process, auth, dns, proxy, endpoint), Kural var mı?, Test edildi mi?, Son test tarihi, Sahip.
Renk:
  • Yeşil: tespit var + son 90 günde test edildi
  • Sarı: kural var ama test yok / yüksek FP
  • Kırmızı: veri var, kural yok
  • Gri: veri yok (önce telemetri)

[Resim: attachment.php?aid=280]

Veri kaynağı gerçekliği
Kural yazmadan önce telemetri var mı bakın. Process Command Line yoksa "suspicious powershell" kuralı hayaldir. Windows'ta en azından:
  • Security 4624/4625/4688
  • Sysmon 1/3/7/11 (mümkünse)
  • DNS / proxy log
  • Kimlik sağlayıcı (AD / Entra) audit

Atomik test ile doğrulama
Red Canary Atomic Red Team gibi kontrollü testler (yalnız kendi lab/izinli ortam) kuralın gerçekten tuttuğunu gösterir. Test sonrası:
Kod:
# Örnek düşünce: T1059.001 PowerShell # 1) Atomik testi labda çalıştır # 2) SIEM'de alarm geldi mi? # 3) Gelmediyse: telemetri mi eksik, kural mı yanlış?
Üretimde rastgele atomik çalıştırmayın; change penceresi ve izin şart.

Önceliklendirme
  1. Kritik varlıkları etkileyen teknikler
  2. Son 12 ayda sektörünüzde görülen teknikler
  3. Kolay kazanım: telemetrisi hazır, kuralı basit olanlar
Raporu yönetime "yüzde 80 coverage" diye sunmak yerine "ransomware kill chain'de 3 kör nokta" diye sunun; aksiyon çıkar.

Yaygın kör noktalar
  • Living-off-the-land (LOLBins) — imza ile zor
  • Bulut yönetim düzlemi (Azure/AWS API) — endpoint odaklı SOC kaçırır
  • Mac/Linux endpoint telemetrisi eksikliği
  • E-posta kimlik doğrulama loglarının SIEM'e gelmemesi

Kaynaklar
  • MITRE ATT&CK resmi site
  • ATT&CK Navigator (katman dosyası paylaşımı)
  • Atomic Red Team
  • SigmaHQ (kural fikirleri)

Siz coverage'ı Navigator ile mi, yoksa servis kataloğuyla mı yönetiyorsunuz? Küçük ekip deneyimleri özellikle değerli.

Navigator katmanı paylaşımı
ATT&CK Navigator JSON katmanını ekipler arası paylaşmak, Excel renginden daha taşınabilirdir. Her major detection eklenince katmanı güncelleyin; çeyreklik gözden geçirmede kırmızı tekniklerden 3 tanesini yeşile çekme hedefi koyun.

Threat-informed defense
Sektörünüze ait tehdit raporlarındaki technique ID'leri haritaya "priority" olarak işaretleyin. Genel matris yüzdesi yerine "bu çeyrek ransomware zinciri coverage" KPI'sı yönetime daha anlamlı gelir.


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.

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-n14-b7a5dc.png (Dosya Boyutu: 68.67 KB / İndirme Sayısı: 8)

.png   n14-inner.png (Dosya Boyutu: 19.9 KB / İndirme Sayısı: 7) ]]> <![CDATA[Olay Müdahalesinde İlk 15 Dakika: Karar Ağacı ve İletişim Disiplini]]> https://www.turkteam.org/konu-olay-mudahalesinde-ilk-15-dakika-karar-agaci-ve-iletisim-disiplini.html Mon, 19 Oct 2026 01:14:45 +0300 BilgeKagan]]> https://www.turkteam.org/konu-olay-mudahalesinde-ilk-15-dakika-karar-agaci-ve-iletisim-disiplini.html [Resim: attachment.php?aid=277]
Selam,

Olay müdahalesinde ilk 15 dakika çoğu zaman sonraki 15 saati belirler. Bu yazıda panik yerine karar ağacı kullanan bir L1/L2 disiplini anlatıyorum. Kurum playbook'unuz varsa o üstündür; bu metin boşluğu doldurmak içindir.

Dakika 0-2: ne olduğunu tek cümlede yaz
"Ne gördük, nerede, ne zaman, kim bildirdi?" Ticket'a düz metin. Spekülasyon yok. Örnek: "Satış ekibinden 3 kullanıcı aynı anda sahte Microsoft girişi bildiriyor; 14:02 TRT."

Dakika 2-5: güvenlik hijyeni ve kanıt
  • Etkilenen hesabı/cihazı izole etmeden önce politika: izolasyon mu, yoksa izleme mi?
  • Ekran görüntüsü + ham log zaman damgası
  • Saat dilimi notu (Europe/Istanbul); SIEM UTC ise dönüşümü yaz

Karar ağacı (özet)
Kod:
Alarm/Bildirim |- Kimlik hırsızlığı şüphesi? -> parola sıfırla, oturumları düşür, MFA kontrol |- Zararlı süreç/EDR? -> ağ izolasyonu, bellek/disk kanıtı kuyruğu |- Veri sızıntısı? -> DLP/egress log, hukuk/iletişim hattını bilgilendir |- Yanlış pozitif? -> kanıtla kapat, kuralı iyileştir

[Resim: attachment.php?aid=278]

Dakika 5-10: iletişim
Tek kanal seçin (IR chat / telefon köprüsü). Herkese ayrı ayrı yazmak kaosu büyütür. Roller:
  • Olay komutanı (karar)
  • Teknik analist
  • İletişim (iş birimleri)
  • Varsa hukuk / KVKK noktası
"Her şeyi herkese mail atma" kuralı: durum özeti 5-10 dakikada bir, net madde işaretleriyle.

Dakika 10-15: kısa çevreleme
  • Etkilenen hesaplarda aktif oturum listesi
  • Firewall / proxy'de bilinen kötü IOC blok (geçici)
  • Yedekleme işlerinin çalıştığını doğrula (silme/encryption senaryosu)
  • Dışa açık yönetim panellerinde anomali
Windows'ta oturum düşürme örneği (lab/politika dahilinde):
Kod:
# Örnek: belirli kullanıcı oturumlarını listele (ortama göre değişir) quser
Entra ID / bulut için Unified Audit Log ve "Revoke sessions" prosedürünüzü hazır tutun.

Yapmayın
  • Kanıt almadan disk silmek / yeniden kurmak
  • Saldırganla "pazarlık" maili
  • Herkese açık Slack'te IOC paylaşmak (sızıntı riski)
  • Saat senkronu bozuk sunucuda zaman çizelgesi kurmak

15. dakikada elde olması gerekenler
  1. Tek cümlelik durum
  2. Etki tahmini (düşük/orta/yüksek) — gerekçeli
  3. Uygulanan çevreleme adımları
  4. Sonraki checkpoint zamanı
  5. Escalate edildi mi?

Kaynaklar
  • NIST SP 800-61 (Computer Security Incident Handling Guide)
  • SANS PICERL modeli
  • Kurumunuzun IR runbook'u

Sizin ilk 15 dakikada en çok atlanan adım hangisi oldu? Bizde uzun süre "tek cümlelik durum" eksikti.

Severity'yi erken sabitlemeyin
İlk 15 dakikada "critical" ilan etmek panik yaratır; "bilinmiyor, çevreleme uygulandı" daha dürüsttür. Severity'yi checkpoint'te güncelleyin. Yönetime giden mesajda teknik jargon yerine iş etkisi: "fatura sistemi yazılamıyor", "e-posta gecikiyor".

Müşteri / regülasyon hattı
Kişisel veri sızıntısı şüphesinde KVKK bildirim süreleri devreye girebilir. IR ekibi hukuk ile erken konuşsun; teknik ekip tek başına "bildirmeyelim" kararını vermesin. İlk 15 dakikanın işi hukuku bilgilendirmek olabilir, resmi bildirimi tamamlamak değil.


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.

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-n13-70a53e.png (Dosya Boyutu: 62.07 KB / İndirme Sayısı: 8)

.png   n13-inner.png (Dosya Boyutu: 19.83 KB / İndirme Sayısı: 8) ]]> [Resim: attachment.php?aid=277]
Selam,

Olay müdahalesinde ilk 15 dakika çoğu zaman sonraki 15 saati belirler. Bu yazıda panik yerine karar ağacı kullanan bir L1/L2 disiplini anlatıyorum. Kurum playbook'unuz varsa o üstündür; bu metin boşluğu doldurmak içindir.

Dakika 0-2: ne olduğunu tek cümlede yaz
"Ne gördük, nerede, ne zaman, kim bildirdi?" Ticket'a düz metin. Spekülasyon yok. Örnek: "Satış ekibinden 3 kullanıcı aynı anda sahte Microsoft girişi bildiriyor; 14:02 TRT."

Dakika 2-5: güvenlik hijyeni ve kanıt
  • Etkilenen hesabı/cihazı izole etmeden önce politika: izolasyon mu, yoksa izleme mi?
  • Ekran görüntüsü + ham log zaman damgası
  • Saat dilimi notu (Europe/Istanbul); SIEM UTC ise dönüşümü yaz

Karar ağacı (özet)
Kod:
Alarm/Bildirim |- Kimlik hırsızlığı şüphesi? -> parola sıfırla, oturumları düşür, MFA kontrol |- Zararlı süreç/EDR? -> ağ izolasyonu, bellek/disk kanıtı kuyruğu |- Veri sızıntısı? -> DLP/egress log, hukuk/iletişim hattını bilgilendir |- Yanlış pozitif? -> kanıtla kapat, kuralı iyileştir

[Resim: attachment.php?aid=278]

Dakika 5-10: iletişim
Tek kanal seçin (IR chat / telefon köprüsü). Herkese ayrı ayrı yazmak kaosu büyütür. Roller:
  • Olay komutanı (karar)
  • Teknik analist
  • İletişim (iş birimleri)
  • Varsa hukuk / KVKK noktası
"Her şeyi herkese mail atma" kuralı: durum özeti 5-10 dakikada bir, net madde işaretleriyle.

Dakika 10-15: kısa çevreleme
  • Etkilenen hesaplarda aktif oturum listesi
  • Firewall / proxy'de bilinen kötü IOC blok (geçici)
  • Yedekleme işlerinin çalıştığını doğrula (silme/encryption senaryosu)
  • Dışa açık yönetim panellerinde anomali
Windows'ta oturum düşürme örneği (lab/politika dahilinde):
Kod:
# Örnek: belirli kullanıcı oturumlarını listele (ortama göre değişir) quser
Entra ID / bulut için Unified Audit Log ve "Revoke sessions" prosedürünüzü hazır tutun.

Yapmayın
  • Kanıt almadan disk silmek / yeniden kurmak
  • Saldırganla "pazarlık" maili
  • Herkese açık Slack'te IOC paylaşmak (sızıntı riski)
  • Saat senkronu bozuk sunucuda zaman çizelgesi kurmak

15. dakikada elde olması gerekenler
  1. Tek cümlelik durum
  2. Etki tahmini (düşük/orta/yüksek) — gerekçeli
  3. Uygulanan çevreleme adımları
  4. Sonraki checkpoint zamanı
  5. Escalate edildi mi?

Kaynaklar
  • NIST SP 800-61 (Computer Security Incident Handling Guide)
  • SANS PICERL modeli
  • Kurumunuzun IR runbook'u

Sizin ilk 15 dakikada en çok atlanan adım hangisi oldu? Bizde uzun süre "tek cümlelik durum" eksikti.

Severity'yi erken sabitlemeyin
İlk 15 dakikada "critical" ilan etmek panik yaratır; "bilinmiyor, çevreleme uygulandı" daha dürüsttür. Severity'yi checkpoint'te güncelleyin. Yönetime giden mesajda teknik jargon yerine iş etkisi: "fatura sistemi yazılamıyor", "e-posta gecikiyor".

Müşteri / regülasyon hattı
Kişisel veri sızıntısı şüphesinde KVKK bildirim süreleri devreye girebilir. IR ekibi hukuk ile erken konuşsun; teknik ekip tek başına "bildirmeyelim" kararını vermesin. İlk 15 dakikanın işi hukuku bilgilendirmek olabilir, resmi bildirimi tamamlamak değil.


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.

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-n13-70a53e.png (Dosya Boyutu: 62.07 KB / İndirme Sayısı: 8)

.png   n13-inner.png (Dosya Boyutu: 19.83 KB / İndirme Sayısı: 8) ]]> <![CDATA[Phishing Mailini SOAR'sız İncelemek: L1 Analist İçin 10 Adımlık Liste]]> https://www.turkteam.org/konu-phishing-mailini-soar-siz-incelemek-l1-analist-icin-10-adimlik-liste.html Mon, 19 Oct 2026 01:12:48 +0300 BilgeKagan]]> https://www.turkteam.org/konu-phishing-mailini-soar-siz-incelemek-l1-analist-icin-10-adimlik-liste.html [Resim: attachment.php?aid=275]
L1 SOC'ta phishing kuyruğu hiç bitmez. SOAR yoksa bile tutarlı bir 10 adımlık liste işleri hızlandırır ve kaçanı azaltır. Bu yazı kendi kullandığım SOAR'sız triage notlarıdır; kurum politikasını ezmez, üzerine giydirin.

0. Güvenlik hijyeni
Analizi izole bir VM'de veya sandbox'ta yapın. Üretim hesabınızda şüpheli eki açmayın. Linklere kendi tarayıcınızdan tıklamak yerine URL'yi kopyalayıp sandbox'ta açın.

10 adım
1) Bildirimi kaydet
Ticket no, bildirenin birimi, zaman (UTC+3 notuyla). Orijinal .eml/.msg dosyasını ekleyin; ekran görüntüsü yetmez.

2) Başlıkları oku (header)
From, Reply-To, Return-Path, Received zinciri. Display name "IT Destek" iken adres rastgele domain ise klasik.
Kod:
# .eml içinden hızlı bakış (Linux lab) grep -E '^(From|Reply-To|Return-Path|Authentication-Results):' mail.eml

3) Kimlik doğrulama sonuçları
SPF / DKIM / DMARC Authentication-Results satırına bakın. fail/softfail tek başına yeterli değil ama skorunuzu etkiler.

4) URL'leri çıkar, çöz
Kısaltıcıları sandbox'ta expand edin. Benzer domain (rnicrosoft.com) avı yapın.
Kod:
# örnek: HTML'den URL (kabaca) grep -oE 'https?://[^"[:space:]]+' mail.eml | sort -u

[Resim: attachment.php?aid=276]

5) Ekleri hash'le, açma
Kod:
sha256sum eklenti.zip
Hash'i VT / kurum sandbox'ına sorun (politikanıza göre). Makro'lu Office ve ISO/IMG taşıyıcılar hâlâ yaygın.

6) İçerik dili ve senaryo
Aciliyet, korku, ödül; fatura, kargo, HR, IT reset. Senaryoyu bir cümlede ticket'a yazın.

7) İç / dış etki
Aynı mail 1 kişiye mi, 500 kişiye mi geldi? Mail gateway logunda subject + message-id arayın.

8) IOC listesi üret
Domain, URL, ek SHA-256, varsa gönderen IP. Paylaşım formatını standardize edin (CSV yeterli).

9) Kontrol önerisi
Gateway'de blok, URL rewrite kategorisi, kullanıcıya "tıklama" duyurusu. L2'ye escalate kriterleri: credential harvest sayfasına giriş yapılmış olması, ek çalıştırılmış olması.

10) Kapanış
Yanlış pozitif ise nedenini yazın (öğrenme). Gerçek phishing ise kısa postmortem: hangi kontrol kaçırdı?

Kullanıcıya dönüş şablonu (kısa)
"Bildirdiğiniz ileti phishing olarak değerlendirildi. Lütfen bağlantıya tıklamayın / ek açmayın. Parola girdiyseniz hemen IT ile parola sıfırlama prosedürünü uygulayın."

Sık L1 hataları
  • Yalnızca spam kutusu gibi davranıp header okumamak
  • IOC'siz "phishing'tir" deyip kapatmak
  • Kullanıcıya suçlayıcı dil
  • Sandbox dışında ek çalıştırmak

Kaynaklar
  • CIS Controls - Email and Browser Protections
  • RFC 7208/6376/7489 (SPF/DKIM/DMARC kavramsal)
  • Kurumunuzun IR playbook'u (asıl kaynak)

Sizin 11. adımınız ne olurdu? SOAR'a geçerken hangi adımı ilk otomatikleştirdiniz?

Header'da Received zinciri
En alttaki Received genelde kullanıcıya en yakın sunucudur; yukarı çıktıkça köken görünür. Sahte "Received" uydurmak mümkündür; SPF/DKIM ile çaprazlayın. Relay gibi görünen üçüncü taraf (pazarlama platformu) meşru olabilir; domain benzerliği tek başına karar değildir.

Kullanıcı tıklamışsa
URL rewrite / proxy logunda 200 mü dönmüş, kimlik bilgisi formu mu açılmış bakın. EDR'da process tree: outlook -> browser -> powershell zinciri var mı? L2'ye "tıklanmış olabilir" diye değil, kanıtla escalate edin.


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.

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-n12-2319b5.png (Dosya Boyutu: 63.28 KB / İndirme Sayısı: 8)

.png   n12-inner.png (Dosya Boyutu: 22.29 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=275]
L1 SOC'ta phishing kuyruğu hiç bitmez. SOAR yoksa bile tutarlı bir 10 adımlık liste işleri hızlandırır ve kaçanı azaltır. Bu yazı kendi kullandığım SOAR'sız triage notlarıdır; kurum politikasını ezmez, üzerine giydirin.

0. Güvenlik hijyeni
Analizi izole bir VM'de veya sandbox'ta yapın. Üretim hesabınızda şüpheli eki açmayın. Linklere kendi tarayıcınızdan tıklamak yerine URL'yi kopyalayıp sandbox'ta açın.

10 adım
1) Bildirimi kaydet
Ticket no, bildirenin birimi, zaman (UTC+3 notuyla). Orijinal .eml/.msg dosyasını ekleyin; ekran görüntüsü yetmez.

2) Başlıkları oku (header)
From, Reply-To, Return-Path, Received zinciri. Display name "IT Destek" iken adres rastgele domain ise klasik.
Kod:
# .eml içinden hızlı bakış (Linux lab) grep -E '^(From|Reply-To|Return-Path|Authentication-Results):' mail.eml

3) Kimlik doğrulama sonuçları
SPF / DKIM / DMARC Authentication-Results satırına bakın. fail/softfail tek başına yeterli değil ama skorunuzu etkiler.

4) URL'leri çıkar, çöz
Kısaltıcıları sandbox'ta expand edin. Benzer domain (rnicrosoft.com) avı yapın.
Kod:
# örnek: HTML'den URL (kabaca) grep -oE 'https?://[^"[:space:]]+' mail.eml | sort -u

[Resim: attachment.php?aid=276]

5) Ekleri hash'le, açma
Kod:
sha256sum eklenti.zip
Hash'i VT / kurum sandbox'ına sorun (politikanıza göre). Makro'lu Office ve ISO/IMG taşıyıcılar hâlâ yaygın.

6) İçerik dili ve senaryo
Aciliyet, korku, ödül; fatura, kargo, HR, IT reset. Senaryoyu bir cümlede ticket'a yazın.

7) İç / dış etki
Aynı mail 1 kişiye mi, 500 kişiye mi geldi? Mail gateway logunda subject + message-id arayın.

8) IOC listesi üret
Domain, URL, ek SHA-256, varsa gönderen IP. Paylaşım formatını standardize edin (CSV yeterli).

9) Kontrol önerisi
Gateway'de blok, URL rewrite kategorisi, kullanıcıya "tıklama" duyurusu. L2'ye escalate kriterleri: credential harvest sayfasına giriş yapılmış olması, ek çalıştırılmış olması.

10) Kapanış
Yanlış pozitif ise nedenini yazın (öğrenme). Gerçek phishing ise kısa postmortem: hangi kontrol kaçırdı?

Kullanıcıya dönüş şablonu (kısa)
"Bildirdiğiniz ileti phishing olarak değerlendirildi. Lütfen bağlantıya tıklamayın / ek açmayın. Parola girdiyseniz hemen IT ile parola sıfırlama prosedürünü uygulayın."

Sık L1 hataları
  • Yalnızca spam kutusu gibi davranıp header okumamak
  • IOC'siz "phishing'tir" deyip kapatmak
  • Kullanıcıya suçlayıcı dil
  • Sandbox dışında ek çalıştırmak

Kaynaklar
  • CIS Controls - Email and Browser Protections
  • RFC 7208/6376/7489 (SPF/DKIM/DMARC kavramsal)
  • Kurumunuzun IR playbook'u (asıl kaynak)

Sizin 11. adımınız ne olurdu? SOAR'a geçerken hangi adımı ilk otomatikleştirdiniz?

Header'da Received zinciri
En alttaki Received genelde kullanıcıya en yakın sunucudur; yukarı çıktıkça köken görünür. Sahte "Received" uydurmak mümkündür; SPF/DKIM ile çaprazlayın. Relay gibi görünen üçüncü taraf (pazarlama platformu) meşru olabilir; domain benzerliği tek başına karar değildir.

Kullanıcı tıklamışsa
URL rewrite / proxy logunda 200 mü dönmüş, kimlik bilgisi formu mu açılmış bakın. EDR'da process tree: outlook -> browser -> powershell zinciri var mı? L2'ye "tıklanmış olabilir" diye değil, kanıtla escalate edin.


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.

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-n12-2319b5.png (Dosya Boyutu: 63.28 KB / İndirme Sayısı: 8)

.png   n12-inner.png (Dosya Boyutu: 22.29 KB / İndirme Sayısı: 9) ]]> <![CDATA[Suricata ile İlk Kural Yazımı: Ev Labında IDS ve eve.json Okuma]]> https://www.turkteam.org/konu-suricata-ile-ilk-kural-yazimi-ev-labinda-ids-ve-eve-json-okuma.html Sun, 18 Oct 2026 11:20:43 +0300 BilgeKagan]]> https://www.turkteam.org/konu-suricata-ile-ilk-kural-yazimi-ev-labinda-ids-ve-eve-json-okuma.html [Resim: attachment.php?aid=158]
Selam arkadaşlar,

Suricata, Snort ailesinden gelen yüksek performanslı IDS/IPS motoru. Bu yazıda ev labımda Suricata'yı IDS modunda ayağa kaldırmayı, basit bir kural yazmayı ve eve.json logunu okumayı anlatıyorum.

Kurulum (Debian/Ubuntu lab)
Kod:
sudo apt update sudo apt install suricata suricata -V
Arayüzü dinlemek için /etc/suricata/suricata.yaml içinde af-packet / pcap bölümünden doğru interface'i seçin (ör. eth0). Labda köprü veya mirror port yoksa, Suricata'yı gateway üzerinde veya trafik üreten VM'in yanında çalıştırın.

Feed güncelleme:
Kod:
sudo suricata-update sudo systemctl restart suricata

İlk kuralınız
Yerel kural dosyası örneği (/etc/suricata/rules/local.rules):
Kod:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TT LAB Suspicious UA"; \ flow:to_server,established; http.user_agent; content:"BadAgent"; \ classtype:policy-violation; sid:1000001; rev:1;)
suricata.yaml içinde local.rules'un yüklendiğinden emin olun. Test trafiği:
Kod:
curl -A "BadAgent" http://example.com/



eve.json okumak
Modern Suricata çıktısı JSON satırlarıdır:
Kod:
sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'
Alanlar: timestamp, src_ip, dest_ip, signature_id, signature, severity... jq ile SIEM'e gitmeden önce filtre öğrenmek çok faydalı.
Kod:
jq -r 'select(.event_type=="alert") | [.timestamp,.src_ip,.dest_ip,.alert.signature] | @tsv' eve.json | head

Kural yazımında dikkat
  • sid 1_000_000+ yerel kurallar için ayırın (çakışmasın)
  • content eşleşmeleri için nocase / depth / offset bilinçli kullanın
  • flow ve http buffer'ları yanlış protokolde çalışmaz
  • IPS (drop) moduna geçmeden önce IDS'te FP ölçün

Performans
Labda varsayılan tamam. Üretimde AF_PACKET cluster, CPU affinity ve bypass politikaları devreye girer. Önce doğru trafik gördüğünüzü doğrulayın:
Kod:
sudo suricatasc -c "iface-stat eth0"

Kaynaklar
  • Suricata Read the Docs (rules / eve)
  • Emerging Threats / Suricata-Update
  • jq el kitabı

Siz eve.json'u doğrudan mi SIEM'e atıyorsunuz, yoksa vector/filebeat ile mi? Küçük lab mimarinizi merak ediyorum.

Home net değişkenleri
suricata.yaml içindeki HOME_NET ve EXTERNAL_NET yanlışsa kurallar ya hiç tutmaz ya da her şeyi tutar. Labda HOME_NET'i [10.10.10.0/24] gibi dar tutun. Multi-homing varsa her iki arayüzü de af-packet'e ekleyin.

IPS moduna geçiş
drop kuralları üretmeden önce bir hafta IDS modunda FP oranı ölçün. Özellikle outbound "policy" imzaları meşru güncellemeleri kesebilir. Önce alert, sonra selective drop.


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.

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-n15-4e5f2d.png (Dosya Boyutu: 65.75 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=158]
Selam arkadaşlar,

Suricata, Snort ailesinden gelen yüksek performanslı IDS/IPS motoru. Bu yazıda ev labımda Suricata'yı IDS modunda ayağa kaldırmayı, basit bir kural yazmayı ve eve.json logunu okumayı anlatıyorum.

Kurulum (Debian/Ubuntu lab)
Kod:
sudo apt update sudo apt install suricata suricata -V
Arayüzü dinlemek için /etc/suricata/suricata.yaml içinde af-packet / pcap bölümünden doğru interface'i seçin (ör. eth0). Labda köprü veya mirror port yoksa, Suricata'yı gateway üzerinde veya trafik üreten VM'in yanında çalıştırın.

Feed güncelleme:
Kod:
sudo suricata-update sudo systemctl restart suricata

İlk kuralınız
Yerel kural dosyası örneği (/etc/suricata/rules/local.rules):
Kod:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TT LAB Suspicious UA"; \ flow:to_server,established; http.user_agent; content:"BadAgent"; \ classtype:policy-violation; sid:1000001; rev:1;)
suricata.yaml içinde local.rules'un yüklendiğinden emin olun. Test trafiği:
Kod:
curl -A "BadAgent" http://example.com/



eve.json okumak
Modern Suricata çıktısı JSON satırlarıdır:
Kod:
sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'
Alanlar: timestamp, src_ip, dest_ip, signature_id, signature, severity... jq ile SIEM'e gitmeden önce filtre öğrenmek çok faydalı.
Kod:
jq -r 'select(.event_type=="alert") | [.timestamp,.src_ip,.dest_ip,.alert.signature] | @tsv' eve.json | head

Kural yazımında dikkat
  • sid 1_000_000+ yerel kurallar için ayırın (çakışmasın)
  • content eşleşmeleri için nocase / depth / offset bilinçli kullanın
  • flow ve http buffer'ları yanlış protokolde çalışmaz
  • IPS (drop) moduna geçmeden önce IDS'te FP ölçün

Performans
Labda varsayılan tamam. Üretimde AF_PACKET cluster, CPU affinity ve bypass politikaları devreye girer. Önce doğru trafik gördüğünüzü doğrulayın:
Kod:
sudo suricatasc -c "iface-stat eth0"

Kaynaklar
  • Suricata Read the Docs (rules / eve)
  • Emerging Threats / Suricata-Update
  • jq el kitabı

Siz eve.json'u doğrudan mi SIEM'e atıyorsunuz, yoksa vector/filebeat ile mi? Küçük lab mimarinizi merak ediyorum.

Home net değişkenleri
suricata.yaml içindeki HOME_NET ve EXTERNAL_NET yanlışsa kurallar ya hiç tutmaz ya da her şeyi tutar. Labda HOME_NET'i [10.10.10.0/24] gibi dar tutun. Multi-homing varsa her iki arayüzü de af-packet'e ekleyin.

IPS moduna geçiş
drop kuralları üretmeden önce bir hafta IDS modunda FP oranı ölçün. Özellikle outbound "policy" imzaları meşru güncellemeleri kesebilir. Önce alert, sonra selective drop.


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.

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-n15-4e5f2d.png (Dosya Boyutu: 65.75 KB / İndirme Sayısı: 6) ]]> <![CDATA[Windows Event Log ile İlk Tehdit Avı: 4624, 4625, 4688 ve 1102]]> https://www.turkteam.org/konu-windows-event-log-ile-ilk-tehdit-avi-4624-4625-4688-ve-1102.html Sun, 18 Oct 2026 11:16:24 +0300 BilgeKagan]]> https://www.turkteam.org/konu-windows-event-log-ile-ilk-tehdit-avi-4624-4625-4688-ve-1102.html [Resim: attachment.php?aid=152]
Merhaba,

SIEM yokken veya EDR alarmı gelmeden önce Windows Event Log hâlâ en yakın dostunuz. Bu yazıda tehdit avında ilk baktığım dört olay kimliğini (4624, 4625, 4688, 1102) ve bunları nasıl sorguladığımı anlatıyorum. Ortam: Windows 11 / Server lab, PowerShell ile.

Önkoşul: audit politikası
4688 (yeni süreç) varsayılanda her yerde dolu olmayabilir. Local Security Policy veya GPO ile "Audit Process Creation" Success açık olmalı; komut satırını da loglamak için:
Kod:
# PowerShell (yönetici) - lab auditpol /set /subcategory:"Process Creation" /success:enable # Komut satırı ekleme (Sysmon yoksa) reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
Üretimde GPO ile yapın; kalıcı ve merkezi olsun. Sysmon varsa 1/3/11 ile bu boşluklar çok daha zengin dolar.

4624 — başarılı oturum
Logon Type değerleri kritik:
  • 2: etkileşimli (konsol)
  • 3: ağ (SMB, vs.)
  • 10: RemoteInteractive (RDP)
  • 5: servis
Gece 03:00'te Type 10 + beklenmeyen hesap = incele. PowerShell:
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-24)} | Select-Object TimeCreated,@{n='Target';e={$_.Properties[5].Value}},@{n='LogonType';e={$_.Properties[8].Value}},@{n='Ip';e={$_.Properties[18].Value}} | Format-Table -AutoSize



4625 — başarısız oturum
Brute force ve parola spray burada görünür. Aynı Source IP'den çok sayıda 4625, ardından bir 4624 = klasik pattern.
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-6)} | Group-Object { $_.Properties[19].Value } | Sort-Object Count -Descending | Select-Object -First 10

4688 — yeni süreç
Parent-child ilişkisi ve CommandLine (açıksa) lateral movement / LOLBin avında altındır. Örnek şüpheli: winword.exe -> powershell.exe, veya userinit -> unknown.exe.
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-4)} | Where-Object { $_.Message -match 'powershell|cmd.exe|rundll32|mshta' } | Select-Object -First 20 TimeCreated, Message

1102 — audit log temizlendi
Security günlüğünün temizlenmesi nadiren meşrudur. Görürseniz kim yaptı, ne zaman, hangi süreç sorularını hemen sorun. Bu olay tek başına yüksek öncelikli alarındır.

Hızlı av senaryoları
  1. RDP brute: 4625 Type 10 yoğunluğu + nadir 4624
  2. Pass-the-hash şüphesi: Type 3 logon pattern'leri + aynı anda süreç anormallikleri (ileri seviye; tek başına 4624 yetmez)
  3. Log silme: 1102
  4. Şüpheli yönetim aracı: 4688 içinde ntdsutil, diskshadow, procdump vb. (ortamınıza göre allowlist)

SIEM'e taşırken
Ham Event Log'u WEF/Winlogbeat ile toplayın. Alanları parse edin (LogonType, IpAddress, CommandLine). Sigma kuralları bu ID'ler üzerine yazılır; yerel PowerShell avı Sigma'ya giden yoldur.

Kaynaklar
  • Microsoft Event ID referansları (learn.microsoft.com)
  • MITRE ATT&CK: Logon / Process Discovery teknikleri
  • SigmaHQ rules (windows)

Sizin ilk baktığınız Event ID hangisi? 4672 (özel yetkiler) ekleyenler de yorumda anlatsın.

wevtutil ve uzak log
Kod:
wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:20 /f:text
WEF (Windows Event Forwarding) ile Collector kurmak, her endpoint'e SSH atmadan av yapmanızı sağlar. Collector şablonlarında 4624/4625/4688/1102'yi önceliklendirin. Disk dolmasın diye retention ve filtreyi ayarlayın.

Sysmon ile zenginleştirme
4688 CommandLine bazen eksik kalır; Sysmon Event ID 1 process create, 3 network connect, 11 file create ile tabloyu tamamlar. SwiftOnSecurity veya Olaf Hartong yapılandırmalarını labda deneyip gürültüyü kendi baselineline göre kırpı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.

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-n11-d9183f.png (Dosya Boyutu: 62.29 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=152]
Merhaba,

SIEM yokken veya EDR alarmı gelmeden önce Windows Event Log hâlâ en yakın dostunuz. Bu yazıda tehdit avında ilk baktığım dört olay kimliğini (4624, 4625, 4688, 1102) ve bunları nasıl sorguladığımı anlatıyorum. Ortam: Windows 11 / Server lab, PowerShell ile.

Önkoşul: audit politikası
4688 (yeni süreç) varsayılanda her yerde dolu olmayabilir. Local Security Policy veya GPO ile "Audit Process Creation" Success açık olmalı; komut satırını da loglamak için:
Kod:
# PowerShell (yönetici) - lab auditpol /set /subcategory:"Process Creation" /success:enable # Komut satırı ekleme (Sysmon yoksa) reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
Üretimde GPO ile yapın; kalıcı ve merkezi olsun. Sysmon varsa 1/3/11 ile bu boşluklar çok daha zengin dolar.

4624 — başarılı oturum
Logon Type değerleri kritik:
  • 2: etkileşimli (konsol)
  • 3: ağ (SMB, vs.)
  • 10: RemoteInteractive (RDP)
  • 5: servis
Gece 03:00'te Type 10 + beklenmeyen hesap = incele. PowerShell:
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-24)} | Select-Object TimeCreated,@{n='Target';e={$_.Properties[5].Value}},@{n='LogonType';e={$_.Properties[8].Value}},@{n='Ip';e={$_.Properties[18].Value}} | Format-Table -AutoSize



4625 — başarısız oturum
Brute force ve parola spray burada görünür. Aynı Source IP'den çok sayıda 4625, ardından bir 4624 = klasik pattern.
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-6)} | Group-Object { $_.Properties[19].Value } | Sort-Object Count -Descending | Select-Object -First 10

4688 — yeni süreç
Parent-child ilişkisi ve CommandLine (açıksa) lateral movement / LOLBin avında altındır. Örnek şüpheli: winword.exe -> powershell.exe, veya userinit -> unknown.exe.
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-4)} | Where-Object { $_.Message -match 'powershell|cmd.exe|rundll32|mshta' } | Select-Object -First 20 TimeCreated, Message

1102 — audit log temizlendi
Security günlüğünün temizlenmesi nadiren meşrudur. Görürseniz kim yaptı, ne zaman, hangi süreç sorularını hemen sorun. Bu olay tek başına yüksek öncelikli alarındır.

Hızlı av senaryoları
  1. RDP brute: 4625 Type 10 yoğunluğu + nadir 4624
  2. Pass-the-hash şüphesi: Type 3 logon pattern'leri + aynı anda süreç anormallikleri (ileri seviye; tek başına 4624 yetmez)
  3. Log silme: 1102
  4. Şüpheli yönetim aracı: 4688 içinde ntdsutil, diskshadow, procdump vb. (ortamınıza göre allowlist)

SIEM'e taşırken
Ham Event Log'u WEF/Winlogbeat ile toplayın. Alanları parse edin (LogonType, IpAddress, CommandLine). Sigma kuralları bu ID'ler üzerine yazılır; yerel PowerShell avı Sigma'ya giden yoldur.

Kaynaklar
  • Microsoft Event ID referansları (learn.microsoft.com)
  • MITRE ATT&CK: Logon / Process Discovery teknikleri
  • SigmaHQ rules (windows)

Sizin ilk baktığınız Event ID hangisi? 4672 (özel yetkiler) ekleyenler de yorumda anlatsın.

wevtutil ve uzak log
Kod:
wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:20 /f:text
WEF (Windows Event Forwarding) ile Collector kurmak, her endpoint'e SSH atmadan av yapmanızı sağlar. Collector şablonlarında 4624/4625/4688/1102'yi önceliklendirin. Disk dolmasın diye retention ve filtreyi ayarlayın.

Sysmon ile zenginleştirme
4688 CommandLine bazen eksik kalır; Sysmon Event ID 1 process create, 3 network connect, 11 file create ile tabloyu tamamlar. SwiftOnSecurity veya Olaf Hartong yapılandırmalarını labda deneyip gürültüyü kendi baselineline göre kırpı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.

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-n11-d9183f.png (Dosya Boyutu: 62.29 KB / İndirme Sayısı: 9) ]]> <![CDATA[Entra ID Servis Sorumlusu Girişlerini İzlemek: KQL ile Tespit Kuralları]]> https://www.turkteam.org/konu-entra-id-servis-sorumlusu-girislerini-izlemek-kql-ile-tespit-kurallari.html Sat, 17 Oct 2026 16:18:55 +0300 BilgeKagan]]> https://www.turkteam.org/konu-entra-id-servis-sorumlusu-girislerini-izlemek-kql-ile-tespit-kurallari.html [Resim: attachment.php?aid=125]
Herkese iyi akşamlar.

Bu hafta yaşanan ConnectWise Cloud Backup olayı, SOC tarafında uzun süredir ihmal edilen bir konuyu yeniden gündeme getirdi: servis sorumlusu (service principal) girişleri. Çoğu ekip kullanıcı girişlerini didik didik izlerken, uygulamaların kendi adına aldığı token'lara pek bakmıyor. Bu yazıda Microsoft Sentinel (ya da Log Analytics) üzerinde bu boşluğu nasıl kapatabileceğinizi, sakin sakin ve adım adım anlatmaya çalışacağım.

Önce kavram: Kullanıcı girişi ile servis sorumlusu girişi farkı
Bir kullanıcı giriş yaptığında arkasında bir insan, bir cihaz ve genelde MFA vardır. Bir uygulama ise "client credentials" akışıyla, yani bir secret ya da sertifikayla doğrudan token alır. Ortada MFA yoktur, koşullu erişim politikaları çoğu zaman uygulanmaz. Bu yüzden bir uygulamanın secret'ı çalındığında saldırgan, uygulamanın sahip olduğu her izni miras alır.

Entra tarafında bu girişler ayrı bir yerde tutulur. Sentinel'de karşılık gelen tablo:
Kod:
AADServicePrincipalSignInLogs
Bu tablo varsayılan olarak gelmez; Entra ID veri bağlayıcısında "ServicePrincipalSignInLogs" seçeneğini işaretlemeniz gerekir. İlk iş, bunun açık olduğunu kontrol etmek:
Kod:
AADServicePrincipalSignInLogs | where TimeGenerated > ago(1d) | summarize count()
Sonuç sıfırsa, veri gelmiyor demektir. Önce bağlayıcıyı düzeltin.

Kural 1: Uygulama başına bilinen IP tabanı
Her uygulamanın normalde nereden bağlandığını öğrenmek, en değerli tespittir. Son 14 günün IP'lerini taban olarak alıp, bugün yeni görülen IP'leri çıkarıyoruz:
Kod:
let taban = AADServicePrincipalSignInLogs | where TimeGenerated between (ago(14d) .. ago(1d)) | summarize by AppId, IPAddress; AADServicePrincipalSignInLogs | where TimeGenerated > ago(1d) | where ResultType == 0 | join kind=leftanti taban on AppId, IPAddress | summarize Ilk=min(TimeGenerated), Son=max(TimeGenerated), Adet=count() by ServicePrincipalName, AppId, IPAddress | order by Adet desc
İlk hafta gürültülü olacaktır. Bulut sağlayıcıların IP havuzları değiştikçe yanlış pozitif görebilirsiniz. Bunu kabul edip birkaç gün boyunca beyaz liste oluşturmak gerekiyor.

Kural 2: Uygulamaya yeni kimlik bilgisi eklenmesi
ConnectWise olayında en kritik adım, saldırganın başka uygulamalara yeni client secret eklemesiydi. Bu, kalıcılık için çok kullanılan bir yöntem. AuditLogs tablosunda şöyle yakalanır:
Kod:
AuditLogs | where TimeGenerated > ago(7d) | where OperationName has_any ("Add service principal credentials", "Update application - Certificates and secrets management") | extend Yapan = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)) | extend Hedef = tostring(TargetResources[0].displayName) | project TimeGenerated, OperationName, Yapan, Hedef, Result
Burada dikkat: Yapan alanı bir uygulama ise (yani InitiatedBy.app doluysa), bu çok daha şüphelidir. İnsanlar secret ekler, uygulamaların başka uygulamaya secret eklemesi nadir bir durumdur.

Kural 3: Dizin rolüne kendini ekleyen uygulamalar
Kod:
AuditLogs | where TimeGenerated > ago(7d) | where OperationName == "Add member to role" | where isnotempty(InitiatedBy.app.displayName) | extend Rol = tostring(TargetResources[0].modifiedProperties[1].newValue) | project TimeGenerated, Uygulama=tostring(InitiatedBy.app.displayName), Rol, TargetResources
modifiedProperties dizisinin sırası kiracıdan kiracıya değişebilir; ilk çalıştırmada ham çıktıya bakıp indeksi doğrulamanızı öneririm.

Operasyonel öneriler
  • Bu üç kuralı önce "sadece raporla" modunda bir hafta çalıştırın, sonra alarma çevirin.
  • Yüksek izinli uygulamaların bir listesini çıkarın (Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All). Alarm önceliğini bu listeye göre belirleyin.
  • Microsoft Graph activity log'larını açın. Graph üzerinden yapılan dizin okumaları başka türlü iz bırakmayabilir.
  • Olay müdahale planınıza "uygulama secret'ı çalındı" senaryosunu ekleyin. Kullanıcı parolasını sıfırlamak burada işe yaramaz; secret'ı döndürmek ve uygulamayı devre dışı bırakmak gerekir.

Benim deneyimim şu: bu tür kurallar ilk günlerde pek alarm üretmez ve ekip "gerek var mıydı" diye sorar. Ama tam olarak o bir gün geldiğinde, elinizde başka hiçbir iz olmayabilir.

Sorularınızı konu altında sorabilirsiniz, kendi ortamınızda karşılaştığınız yanlış pozitifleri paylaşırsanız birlikte iyileştirebiliriz.

Kaynaklar
  • Microsoft Learn - AADServicePrincipalSignInLogs ve AuditLogs tablo referansları
  • Microsoft Learn - Entra ID sign-in log türleri
  • The Hacker News - ConnectWise Cloud Backup olayı (17 Ekim 2026)


.png   004-bilge-entra-sp.png (Dosya Boyutu: 67.91 KB / İndirme Sayısı: 8) ]]> [Resim: attachment.php?aid=125]
Herkese iyi akşamlar.

Bu hafta yaşanan ConnectWise Cloud Backup olayı, SOC tarafında uzun süredir ihmal edilen bir konuyu yeniden gündeme getirdi: servis sorumlusu (service principal) girişleri. Çoğu ekip kullanıcı girişlerini didik didik izlerken, uygulamaların kendi adına aldığı token'lara pek bakmıyor. Bu yazıda Microsoft Sentinel (ya da Log Analytics) üzerinde bu boşluğu nasıl kapatabileceğinizi, sakin sakin ve adım adım anlatmaya çalışacağım.

Önce kavram: Kullanıcı girişi ile servis sorumlusu girişi farkı
Bir kullanıcı giriş yaptığında arkasında bir insan, bir cihaz ve genelde MFA vardır. Bir uygulama ise "client credentials" akışıyla, yani bir secret ya da sertifikayla doğrudan token alır. Ortada MFA yoktur, koşullu erişim politikaları çoğu zaman uygulanmaz. Bu yüzden bir uygulamanın secret'ı çalındığında saldırgan, uygulamanın sahip olduğu her izni miras alır.

Entra tarafında bu girişler ayrı bir yerde tutulur. Sentinel'de karşılık gelen tablo:
Kod:
AADServicePrincipalSignInLogs
Bu tablo varsayılan olarak gelmez; Entra ID veri bağlayıcısında "ServicePrincipalSignInLogs" seçeneğini işaretlemeniz gerekir. İlk iş, bunun açık olduğunu kontrol etmek:
Kod:
AADServicePrincipalSignInLogs | where TimeGenerated > ago(1d) | summarize count()
Sonuç sıfırsa, veri gelmiyor demektir. Önce bağlayıcıyı düzeltin.

Kural 1: Uygulama başına bilinen IP tabanı
Her uygulamanın normalde nereden bağlandığını öğrenmek, en değerli tespittir. Son 14 günün IP'lerini taban olarak alıp, bugün yeni görülen IP'leri çıkarıyoruz:
Kod:
let taban = AADServicePrincipalSignInLogs | where TimeGenerated between (ago(14d) .. ago(1d)) | summarize by AppId, IPAddress; AADServicePrincipalSignInLogs | where TimeGenerated > ago(1d) | where ResultType == 0 | join kind=leftanti taban on AppId, IPAddress | summarize Ilk=min(TimeGenerated), Son=max(TimeGenerated), Adet=count() by ServicePrincipalName, AppId, IPAddress | order by Adet desc
İlk hafta gürültülü olacaktır. Bulut sağlayıcıların IP havuzları değiştikçe yanlış pozitif görebilirsiniz. Bunu kabul edip birkaç gün boyunca beyaz liste oluşturmak gerekiyor.

Kural 2: Uygulamaya yeni kimlik bilgisi eklenmesi
ConnectWise olayında en kritik adım, saldırganın başka uygulamalara yeni client secret eklemesiydi. Bu, kalıcılık için çok kullanılan bir yöntem. AuditLogs tablosunda şöyle yakalanır:
Kod:
AuditLogs | where TimeGenerated > ago(7d) | where OperationName has_any ("Add service principal credentials", "Update application - Certificates and secrets management") | extend Yapan = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)) | extend Hedef = tostring(TargetResources[0].displayName) | project TimeGenerated, OperationName, Yapan, Hedef, Result
Burada dikkat: Yapan alanı bir uygulama ise (yani InitiatedBy.app doluysa), bu çok daha şüphelidir. İnsanlar secret ekler, uygulamaların başka uygulamaya secret eklemesi nadir bir durumdur.

Kural 3: Dizin rolüne kendini ekleyen uygulamalar
Kod:
AuditLogs | where TimeGenerated > ago(7d) | where OperationName == "Add member to role" | where isnotempty(InitiatedBy.app.displayName) | extend Rol = tostring(TargetResources[0].modifiedProperties[1].newValue) | project TimeGenerated, Uygulama=tostring(InitiatedBy.app.displayName), Rol, TargetResources
modifiedProperties dizisinin sırası kiracıdan kiracıya değişebilir; ilk çalıştırmada ham çıktıya bakıp indeksi doğrulamanızı öneririm.

Operasyonel öneriler
  • Bu üç kuralı önce "sadece raporla" modunda bir hafta çalıştırın, sonra alarma çevirin.
  • Yüksek izinli uygulamaların bir listesini çıkarın (Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All). Alarm önceliğini bu listeye göre belirleyin.
  • Microsoft Graph activity log'larını açın. Graph üzerinden yapılan dizin okumaları başka türlü iz bırakmayabilir.
  • Olay müdahale planınıza "uygulama secret'ı çalındı" senaryosunu ekleyin. Kullanıcı parolasını sıfırlamak burada işe yaramaz; secret'ı döndürmek ve uygulamayı devre dışı bırakmak gerekir.

Benim deneyimim şu: bu tür kurallar ilk günlerde pek alarm üretmez ve ekip "gerek var mıydı" diye sorar. Ama tam olarak o bir gün geldiğinde, elinizde başka hiçbir iz olmayabilir.

Sorularınızı konu altında sorabilirsiniz, kendi ortamınızda karşılaştığınız yanlış pozitifleri paylaşırsanız birlikte iyileştirebiliriz.

Kaynaklar
  • Microsoft Learn - AADServicePrincipalSignInLogs ve AuditLogs tablo referansları
  • Microsoft Learn - Entra ID sign-in log türleri
  • The Hacker News - ConnectWise Cloud Backup olayı (17 Ekim 2026)


.png   004-bilge-entra-sp.png (Dosya Boyutu: 67.91 KB / İndirme Sayısı: 8) ]]> <![CDATA[Sigma Kurallari ile Tespit Muhendisligi: SIEM Bagimsiz Kural Yazimi]]> https://www.turkteam.org/konu-sigma-kurallari-ile-tespit-muhendisligi-siem-bagimsiz-kural-yazimi.html Sat, 17 Oct 2026 11:31:20 +0300 Tonyukuk]]> https://www.turkteam.org/konu-sigma-kurallari-ile-tespit-muhendisligi-siem-bagimsiz-kural-yazimi.html [Resim: attachment.php?aid=120]
Mavi takımda bir süre çalışınca şu sorunla karşılaşırsınız: Splunk için yazdığınız tespit kuralı, kurum Elastic'e geçince çöpe gidiyor. Her SIEM'in kendi sorgu dili var ve kurallarınız o dile kilitleniyor. İşte Sigma tam da bu sorunu çözmek için var. Bu rehberde Sigma'yı sıfırdan, pratik bir kural yazarak anlatıyorum.

Konuda anlatılacaklar
  1. Sigma nedir, neden gerekli?
  2. Bir Sigma kuralının anatomisi
  3. İlk kuralı yazmak
  4. sigma-cli ile dönüştürme
  5. İyi kural yazmanın ilkeleri
  6. Kaynaklar ve pratik
  7. Yasal/operasyonel not

Sigma Nedir?

Sigma, log tabanlı tespit kuralları için genel ve SIEM'den bağımsız bir formattır. YAML ile yazılır. Mantık şudur: kuralı bir kez Sigma formatında yazarsınız, sonra bir dönüştürücüyle (converter) Splunk SPL, Elastic KQL, Microsoft Sentinel, QRadar gibi hedeflerin diline çevirirsiniz. Yani "tespit mantığının ortak dili". IOC'ler için nasıl ki STIX varsa, tespit kuralları için de Sigma odur.

Bir Sigma Kuralının Anatomisi

Temel alanlar:
  • title / id / status: Kuralın adı, benzersiz kimliği ve olgunluğu.
  • logsource: Hangi log kaynağı (ör. windows / process_creation).
  • detection: Asıl mantık; selection blokları ve condition.
  • level: Önem derecesi (low/medium/high/critical).
  • falsepositives: Bilinen yanlış alarm senaryoları.

İlk Kuralı Yazmak

Örnek: whoami komutunun bir web sunucusu süreci tarafından çalıştırılması çoğu zaman şüphelidir (web shell sonrası keşif). Basit bir Sigma kuralı:

Kod:
title: Web Sunucusu Tarafindan whoami Calistirilmasi id: 7b2a1f4c-1111-2222-3333-444455556666 status: experimental description: Web sunucusu surecinin alt surec olarak whoami calistirmasi logsource: category: process_creation product: windows detection: selection: ParentImage|endswith: - '\w3wp.exe' - '\httpd.exe' - '\nginx.exe' Image|endswith: '\whoami.exe' condition: selection falsepositives: - Yoneticinin elle yaptigi mesru kontroller level: high tags: - attack.discovery - attack.t1033

Buradaki mantık: ebeveyn süreç bir web sunucusu ve çalışan komut whoami ise alarm üret. MITRE ATT&CK etiketi (T1033) ile de tekniği işaretledik.

sigma-cli ile Dönüştürme

Resmi araç sigma-cli (pySigma tabanlı) kuralı hedef SIEM diline çevirir:

Kod:
pipx install sigma-cli # veya: pip install sigma-cli # Splunk hedefi icin backend kur sigma plugin install splunk # Donusturme sigma convert -t splunk kural.yml

Aynı kuralı -t ile farklı hedeflere (ör. elasticsearch, loki) çevirebilirsiniz. Böylece tek kaynak, çok SIEM.

İyi Kural Yazmanın İlkeleri
  • Davranışa odaklan: Tek bir dosya adına değil, tekniğin değişmez davranışına kural yazın (ör. "hangi ebeveyn hangi çocuğu çalıştırdı").
  • Yanlış alarmı en baştan düşün: falsepositives alanını doldurmak, kuralın üretime alınabilirliğini belirler.
  • ATT&CK ile etiketle: Kapsamınızı (coverage) ölçebilmek için her kuralı tekniğe bağlayın.
  • Önce test: Kuralı üretime almadan önce bilinen bir örnek olayla (ör. Atomic Red Team) tetikleyip doğrulayın.
  • Gürültüyü yönet: Çok geniş kural, analisti alarm yorgunluğuna sürükler; dar ve anlamlı tutun.

Kaynaklar ve Pratik
  • SigmaHQ deposu: binlerce hazır topluluk kuralı; okuyarak kalıpları öğrenin.
  • Atomic Red Team: kurallarınızı güvenle tetikleyip test etmek için.
  • Kendi Windows lab'ınızda Sysmon + bir SIEM (Wazuh/Elastic) kurup uçtan uca deneyin: olay üret, logla, Sigma yaz, dönüştür, alarmı gör.

Sonuç

Sigma, tespit mühendisliğini "bir SIEM'e kilitli uğraş" olmaktan çıkarıp taşınabilir, paylaşılabilir ve ölçülebilir bir disipline dönüştürüyor. Tek bir basit kuralla başlayın, SigmaHQ'daki örnekleri okuyun, kendi lab'ınızda test edin. Siz hangi SIEM backend'ini kullanıyorsunuz ve Sigma dönüşümünde takıldığınız yerler neler, yorumlarda paylaşın.

Yasal/Operasyonel Not

Bu rehberdeki tüm pratikler kendi lab ortamınızda veya yönettiğiniz/izinli sistemlerde yapılmalıdır. Test amaçlı saldırı simülasyonları (Atomic Red Team vb.) yalnızca kendi makinelerinizde çalıştırılmalıdır.

Görsel: TurkTeam özgün kapak görseli

.jpg   tonyukuk-19-sigma.jpg (Dosya Boyutu: 81.62 KB / İndirme Sayısı: 9) ]]> [Resim: attachment.php?aid=120]
Mavi takımda bir süre çalışınca şu sorunla karşılaşırsınız: Splunk için yazdığınız tespit kuralı, kurum Elastic'e geçince çöpe gidiyor. Her SIEM'in kendi sorgu dili var ve kurallarınız o dile kilitleniyor. İşte Sigma tam da bu sorunu çözmek için var. Bu rehberde Sigma'yı sıfırdan, pratik bir kural yazarak anlatıyorum.

Konuda anlatılacaklar
  1. Sigma nedir, neden gerekli?
  2. Bir Sigma kuralının anatomisi
  3. İlk kuralı yazmak
  4. sigma-cli ile dönüştürme
  5. İyi kural yazmanın ilkeleri
  6. Kaynaklar ve pratik
  7. Yasal/operasyonel not

Sigma Nedir?

Sigma, log tabanlı tespit kuralları için genel ve SIEM'den bağımsız bir formattır. YAML ile yazılır. Mantık şudur: kuralı bir kez Sigma formatında yazarsınız, sonra bir dönüştürücüyle (converter) Splunk SPL, Elastic KQL, Microsoft Sentinel, QRadar gibi hedeflerin diline çevirirsiniz. Yani "tespit mantığının ortak dili". IOC'ler için nasıl ki STIX varsa, tespit kuralları için de Sigma odur.

Bir Sigma Kuralının Anatomisi

Temel alanlar:
  • title / id / status: Kuralın adı, benzersiz kimliği ve olgunluğu.
  • logsource: Hangi log kaynağı (ör. windows / process_creation).
  • detection: Asıl mantık; selection blokları ve condition.
  • level: Önem derecesi (low/medium/high/critical).
  • falsepositives: Bilinen yanlış alarm senaryoları.

İlk Kuralı Yazmak

Örnek: whoami komutunun bir web sunucusu süreci tarafından çalıştırılması çoğu zaman şüphelidir (web shell sonrası keşif). Basit bir Sigma kuralı:

Kod:
title: Web Sunucusu Tarafindan whoami Calistirilmasi id: 7b2a1f4c-1111-2222-3333-444455556666 status: experimental description: Web sunucusu surecinin alt surec olarak whoami calistirmasi logsource: category: process_creation product: windows detection: selection: ParentImage|endswith: - '\w3wp.exe' - '\httpd.exe' - '\nginx.exe' Image|endswith: '\whoami.exe' condition: selection falsepositives: - Yoneticinin elle yaptigi mesru kontroller level: high tags: - attack.discovery - attack.t1033

Buradaki mantık: ebeveyn süreç bir web sunucusu ve çalışan komut whoami ise alarm üret. MITRE ATT&CK etiketi (T1033) ile de tekniği işaretledik.

sigma-cli ile Dönüştürme

Resmi araç sigma-cli (pySigma tabanlı) kuralı hedef SIEM diline çevirir:

Kod:
pipx install sigma-cli # veya: pip install sigma-cli # Splunk hedefi icin backend kur sigma plugin install splunk # Donusturme sigma convert -t splunk kural.yml

Aynı kuralı -t ile farklı hedeflere (ör. elasticsearch, loki) çevirebilirsiniz. Böylece tek kaynak, çok SIEM.

İyi Kural Yazmanın İlkeleri
  • Davranışa odaklan: Tek bir dosya adına değil, tekniğin değişmez davranışına kural yazın (ör. "hangi ebeveyn hangi çocuğu çalıştırdı").
  • Yanlış alarmı en baştan düşün: falsepositives alanını doldurmak, kuralın üretime alınabilirliğini belirler.
  • ATT&CK ile etiketle: Kapsamınızı (coverage) ölçebilmek için her kuralı tekniğe bağlayın.
  • Önce test: Kuralı üretime almadan önce bilinen bir örnek olayla (ör. Atomic Red Team) tetikleyip doğrulayın.
  • Gürültüyü yönet: Çok geniş kural, analisti alarm yorgunluğuna sürükler; dar ve anlamlı tutun.

Kaynaklar ve Pratik
  • SigmaHQ deposu: binlerce hazır topluluk kuralı; okuyarak kalıpları öğrenin.
  • Atomic Red Team: kurallarınızı güvenle tetikleyip test etmek için.
  • Kendi Windows lab'ınızda Sysmon + bir SIEM (Wazuh/Elastic) kurup uçtan uca deneyin: olay üret, logla, Sigma yaz, dönüştür, alarmı gör.

Sonuç

Sigma, tespit mühendisliğini "bir SIEM'e kilitli uğraş" olmaktan çıkarıp taşınabilir, paylaşılabilir ve ölçülebilir bir disipline dönüştürüyor. Tek bir basit kuralla başlayın, SigmaHQ'daki örnekleri okuyun, kendi lab'ınızda test edin. Siz hangi SIEM backend'ini kullanıyorsunuz ve Sigma dönüşümünde takıldığınız yerler neler, yorumlarda paylaşın.

Yasal/Operasyonel Not

Bu rehberdeki tüm pratikler kendi lab ortamınızda veya yönettiğiniz/izinli sistemlerde yapılmalıdır. Test amaçlı saldırı simülasyonları (Atomic Red Team vb.) yalnızca kendi makinelerinizde çalıştırılmalıdır.

Görsel: TurkTeam özgün kapak görseli

.jpg   tonyukuk-19-sigma.jpg (Dosya Boyutu: 81.62 KB / İndirme Sayısı: 9) ]]> <![CDATA[Sigma Kurallari ile Tespit: Windows Event Loglarindan SIEM Kuralina]]> https://www.turkteam.org/konu-sigma-kurallari-ile-tespit-windows-event-loglarindan-siem-kuralina.html Sat, 17 Oct 2026 11:22:56 +0300 BilgeKagan]]> https://www.turkteam.org/konu-sigma-kurallari-ile-tespit-windows-event-loglarindan-siem-kuralina.html [Resim: attachment.php?aid=88]
Selamlar,

Mavi takim tarafinda en degerli becerilerden biri, bir saldiri davranisini jenerik bir tespit kuralina cevirebilmek. Sigma tam da bunun icin var: tek bir YAML kuralini yazip Splunk, Elastic, Sentinel gibi farkli SIEM'lere cevirebiliyorsunuz. Bu konuda Sigma mantigini ve basit bir kural yazimini adim adim gosterecegim.

Konuda Anlatilacaklar
  1. Sigma nedir, neden standart haline geldi?
  2. Kural anatomisi (logsource, detection)
  3. Ornek: supheli PowerShell indirmesi
  4. sigma-cli ile hedefe cevirme
  5. False positive yonetimi

1) Sigma Nedir?
Sigma, log tabanli tespit kurallari icin acik bir imza formatidir. YARA dosyalara, Snort ag trafigine ne ise, Sigma da log olaylarina odur. Avantaji tasinabilirlik: bir kez yazilan kural, backend'e gore hedef sorguya cevrilir. 2026 itibariyle topluluk deposu binlerce hazir kural barindiriyor.

2) Kural Anatomisi
Her kuralin iki kilit bolumu vardir: hangi logda arayacagini soyleyen logsource ve neyi arayacagini soyleyen detection.

Kod:
title: Supheli PowerShell Web Indirmesi status: experimental logsource: product: windows category: process_creation detection: selection: Image|endswith: '\powershell.exe' CommandLine|contains: - 'DownloadString' - 'IEX' - 'Invoke-WebRequest' condition: selection level: medium

Burada process olusturma loglarinda (Sysmon Event ID 1 veya Security 4688) powershell.exe'nin indirme/execute kaliplariyla calismasini ariyoruz.

3) Hedefe Cevirme
sigma-cli ile kurali istediginiz backend'e cevirirsiniz:

Kod:
pip install sigma-cli sigma plugin install splunk sigma convert -t splunk -p sysmon powershell_download.yml

Cikan sorguyu dogrudan SIEM'inizde arama olarak kullanabilir veya alarma baglayabilirsiniz.

4) False Positive Yonetimi
Hicbir kural ilk gunden mukemmel degildir. Kurali yazdiktan sonra birkac gun "audit" modunda calistirip gelen eslesmeleri inceleyin. Mesru yonetim scriptleri de Invoke-WebRequest kullanabilir; bu durumda bilinen sunucu adlarini veya imzali scriptleri filter blokuyla elersiniz:

Kod:
filter: CommandLine|contains: 'https://repo.sirketiniz.local' condition: selection and not filter

5) Pratik Tavsiye
Once Sysmon'u iyi bir config ile kurun (telemetri olmadan kural calismaz), sonra MITRE ATT&CK tekniklerinden birini secip ona karsilik gelen Sigma kurallarini inceleyin. Hazir kurallari okumak, kendi kuralinizi yazmanin en hizli yoludur.

Kaynaklar
Alıntı:Yasal not: Tespit kurallarini yalnizca yonettiginiz veya izinli oldugunuz log kaynaklarinda uygulayin.

Siz hangi teknik icin kural yaziyorsunuz, altta paylasin.

.png   bilgekagan-b02.png (Dosya Boyutu: 87.9 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=88]
Selamlar,

Mavi takim tarafinda en degerli becerilerden biri, bir saldiri davranisini jenerik bir tespit kuralina cevirebilmek. Sigma tam da bunun icin var: tek bir YAML kuralini yazip Splunk, Elastic, Sentinel gibi farkli SIEM'lere cevirebiliyorsunuz. Bu konuda Sigma mantigini ve basit bir kural yazimini adim adim gosterecegim.

Konuda Anlatilacaklar
  1. Sigma nedir, neden standart haline geldi?
  2. Kural anatomisi (logsource, detection)
  3. Ornek: supheli PowerShell indirmesi
  4. sigma-cli ile hedefe cevirme
  5. False positive yonetimi

1) Sigma Nedir?
Sigma, log tabanli tespit kurallari icin acik bir imza formatidir. YARA dosyalara, Snort ag trafigine ne ise, Sigma da log olaylarina odur. Avantaji tasinabilirlik: bir kez yazilan kural, backend'e gore hedef sorguya cevrilir. 2026 itibariyle topluluk deposu binlerce hazir kural barindiriyor.

2) Kural Anatomisi
Her kuralin iki kilit bolumu vardir: hangi logda arayacagini soyleyen logsource ve neyi arayacagini soyleyen detection.

Kod:
title: Supheli PowerShell Web Indirmesi status: experimental logsource: product: windows category: process_creation detection: selection: Image|endswith: '\powershell.exe' CommandLine|contains: - 'DownloadString' - 'IEX' - 'Invoke-WebRequest' condition: selection level: medium

Burada process olusturma loglarinda (Sysmon Event ID 1 veya Security 4688) powershell.exe'nin indirme/execute kaliplariyla calismasini ariyoruz.

3) Hedefe Cevirme
sigma-cli ile kurali istediginiz backend'e cevirirsiniz:

Kod:
pip install sigma-cli sigma plugin install splunk sigma convert -t splunk -p sysmon powershell_download.yml

Cikan sorguyu dogrudan SIEM'inizde arama olarak kullanabilir veya alarma baglayabilirsiniz.

4) False Positive Yonetimi
Hicbir kural ilk gunden mukemmel degildir. Kurali yazdiktan sonra birkac gun "audit" modunda calistirip gelen eslesmeleri inceleyin. Mesru yonetim scriptleri de Invoke-WebRequest kullanabilir; bu durumda bilinen sunucu adlarini veya imzali scriptleri filter blokuyla elersiniz:

Kod:
filter: CommandLine|contains: 'https://repo.sirketiniz.local' condition: selection and not filter

5) Pratik Tavsiye
Once Sysmon'u iyi bir config ile kurun (telemetri olmadan kural calismaz), sonra MITRE ATT&CK tekniklerinden birini secip ona karsilik gelen Sigma kurallarini inceleyin. Hazir kurallari okumak, kendi kuralinizi yazmanin en hizli yoludur.

Kaynaklar
Alıntı:Yasal not: Tespit kurallarini yalnizca yonettiginiz veya izinli oldugunuz log kaynaklarinda uygulayin.

Siz hangi teknik icin kural yaziyorsunuz, altta paylasin.

.png   bilgekagan-b02.png (Dosya Boyutu: 87.9 KB / İndirme Sayısı: 7) ]]> <![CDATA[Wazuh 4.14 ile SIEM'e Giriş: Kurulum ve İlk Alarm Kuralları]]> https://www.turkteam.org/konu-wazuh-4-14-ile-siem-e-giris-kurulum-ve-ilk-alarm-kurallari.html Fri, 16 Oct 2026 11:19:28 +0300 Tonyukuk]]> https://www.turkteam.org/konu-wazuh-4-14-ile-siem-e-giris-kurulum-ve-ilk-alarm-kurallari.html [Resim: attachment.php?aid=27]
Wazuh 4.14 ile SIEM'e Giriş

Merhaba,

Wazuh, açık kaynak XDR/SIEM platformudur. 15 Ekim 2026'da v4.14.9 yayımlandı. Bu rehberde tek düğüm lab kurulumu ve ilk alarm mantığını anlatıyoruz.

Konuda Anlatılacaklar
  1. Mimariye kısa bakış
  2. Lab kurulumu (Docker)
  3. Ajan bağlama
  4. İlk kural / uyarısı
  5. Kaynakça

1) Mimari
  • Wazuh indexer: Log depolama / arama
  • Wazuh manager: Analiz, kurallar, ajan yönetimi
  • Wazuh dashboard: Web arayüzü
  • Ajanlar: Uç noktalarda log ve FIM

2) Lab Kurulumu (Docker)
Resmi dokümantasyondaki tek düğüm / Docker Compose senaryosunu kendi lab sunucunuzda izleyin:
Kod:
# Örnek iskelet (sürüm numaralarını resmi dokümana göre güncelleyin) git clone https://github.com/wazuh/wazuh-docker.git cd wazuh-docker/single-node docker compose up -d # Dashboard genelde https://localhost:443
Kurulum bitince varsayılan parolaları hemen değiştirin.

3) Ajan Bağlama
Kod:
# Linux ajan (lab) curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor > /tmp/wazuh.gpg # Resmi paket deposundan ajanı kurun; WAZUH_MANAGER=lab_ip ile kaydedin
Dashboard -> Agents bölümünde ajanın "Active" olduğunu doğrulayın.

4) İlk Alarm Fikri
  • SSH başarısız giriş eşiği
  • Yeni root yetkili kullanıcı oluşturma
  • Web sunucu 4xx/5xx patlaması
  • FIM: /etc/passwd veya /etc/sudoers değişimi
Kod:
# Manager üzerinde kural dosyaları genelde # /var/ossec/etc/rules/local_rules.xml # Değişiklikten sonra: # systemctl restart wazuh-manager

5) İyi Uygulamalar
  • Lab ile production'ı ayırın
  • Ajan iletişimi için TLS zorunlu
  • Disk doluluğunu izleyin (indexer şişer)
  • Her alarm için "ne yapacağız?" runbook'u yazın

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

Alıntı:Yasal Uyarı: SIEM'i yalnızca yönettiğiniz sistemlerde kurun. Başkasının loglarını izinsiz toplamak hukuka aykırıdır.


.jpg   tonyukuk-17.jpg (Dosya Boyutu: 96.92 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=27]
Wazuh 4.14 ile SIEM'e Giriş

Merhaba,

Wazuh, açık kaynak XDR/SIEM platformudur. 15 Ekim 2026'da v4.14.9 yayımlandı. Bu rehberde tek düğüm lab kurulumu ve ilk alarm mantığını anlatıyoruz.

Konuda Anlatılacaklar
  1. Mimariye kısa bakış
  2. Lab kurulumu (Docker)
  3. Ajan bağlama
  4. İlk kural / uyarısı
  5. Kaynakça

1) Mimari
  • Wazuh indexer: Log depolama / arama
  • Wazuh manager: Analiz, kurallar, ajan yönetimi
  • Wazuh dashboard: Web arayüzü
  • Ajanlar: Uç noktalarda log ve FIM

2) Lab Kurulumu (Docker)
Resmi dokümantasyondaki tek düğüm / Docker Compose senaryosunu kendi lab sunucunuzda izleyin:
Kod:
# Örnek iskelet (sürüm numaralarını resmi dokümana göre güncelleyin) git clone https://github.com/wazuh/wazuh-docker.git cd wazuh-docker/single-node docker compose up -d # Dashboard genelde https://localhost:443
Kurulum bitince varsayılan parolaları hemen değiştirin.

3) Ajan Bağlama
Kod:
# Linux ajan (lab) curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor > /tmp/wazuh.gpg # Resmi paket deposundan ajanı kurun; WAZUH_MANAGER=lab_ip ile kaydedin
Dashboard -> Agents bölümünde ajanın "Active" olduğunu doğrulayın.

4) İlk Alarm Fikri
  • SSH başarısız giriş eşiği
  • Yeni root yetkili kullanıcı oluşturma
  • Web sunucu 4xx/5xx patlaması
  • FIM: /etc/passwd veya /etc/sudoers değişimi
Kod:
# Manager üzerinde kural dosyaları genelde # /var/ossec/etc/rules/local_rules.xml # Değişiklikten sonra: # systemctl restart wazuh-manager

5) İyi Uygulamalar
  • Lab ile production'ı ayırın
  • Ajan iletişimi için TLS zorunlu
  • Disk doluluğunu izleyin (indexer şişer)
  • Her alarm için "ne yapacağız?" runbook'u yazın

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

Alıntı:Yasal Uyarı: SIEM'i yalnızca yönettiğiniz sistemlerde kurun. Başkasının loglarını izinsiz toplamak hukuka aykırıdır.


.jpg   tonyukuk-17.jpg (Dosya Boyutu: 96.92 KB / İndirme Sayısı: 7) ]]> <![CDATA[Windows 11 Yerleşik Sysmon: Kurulum, Yapılandırma ve SOC İçin İlk Adımlar]]> https://www.turkteam.org/konu-windows-11-yerlesik-sysmon-kurulum-yapilandirma-ve-soc-icin-ilk-adimlar.html Fri, 16 Oct 2026 11:18:42 +0300 BilgeKagan]]> https://www.turkteam.org/konu-windows-11-yerlesik-sysmon-kurulum-yapilandirma-ve-soc-icin-ilk-adimlar.html [Resim: attachment.php?aid=26]
Selamlar,

Yıllardır Sysinternals Sysmon'u ayrı bir exe ile kuruyorduk. 2026'da Microsoft, Windows 11 ve Windows Server 2025'te Sysmon'u isteğe bağlı yerleşik özellik olarak sundu. Lab makinemde denedim; bu konuda kurulum notlarımı ve SOC açısından ne işe yaradığını paylaşıyorum.

Konuda Anlatılacaklar
  1. Yerleşik Sysmon nedir, ne değildir?
  2. Standalone ile birlikte çalışmaz
  3. Etkinleştirme (PowerShell / DISM)
  4. Yapılandırma dosyası (SwiftOnSecurity vb.)
  5. Olayları nerede görürsünüz, SIEM'e nasıl gider?

1) Ne Yapar, Ne Yapmaz?
Microsoft Learn'e göre yerleşik Sysmon süreç oluşturma, ağ bağlantısı, sürücü/DLL yükleme, ham disk erişimi gibi olayları Windows Event Log'a yazar. Analiz etmez, engellemez, varlığını gizlemez. Yani bir EDR değil; yüksek kaliteli telemetri kaynağıdır. SIEM veya Defender for Endpoint gibi ürünlerle birlikte anlam kazanır.

2) Standalone ile Bir Arada Olmaz
Cihazda eski Sysinternals Sysmon kuruluysa önce kaldırın. İkisi aynı anda desteklenmiyor. Kontrol:

Kod:
Get-Service sysmon*

Çıktı boş olmalı. Varsa standalone'u kaldırıp devam edin.

3) Etkinleştirme
Yönetici PowerShell:

Kod:
Enable-WindowsOptionalFeature -Online -FeatureName Sysmon sysmon -i

DISM alternatifi:
Kod:
Dism /Online /Enable-Feature /FeatureName:Sysmon
sonra yine
Kod:
sysmon -i
.

Varsayılan kurulum az olay üretir; mutlaka bir config uygulayın.

4) Yapılandırma
Popüler topluluk config'leri:
  • SwiftOnSecurity/sysmon-config
  • olafhartong/sysmon-modular (MITRE eşlemeli, modüler)

Kod:
# Örnek: config ile kurulum sysmon -i C:\Sysmon\sysmonconfig.xml # Sonradan güncelleme (restart gerekmez) sysmon -c C:\Sysmon\sysmonconfig.xml

Lab'da önce dar bir config ile başlayıp Event Viewer'da gürültüyü izleyin; production'a körlemesine "her şeyi aç" demeyin, disk ve lisans maliyetiniz şişer.

5) Olaylar Nerede?
Event Viewer: Applications and Services Logs > Microsoft > Windows > Sysmon > Operational.

Yerleşik Sysmon'da görüntülenen mesaj metinleri yerelleştirilmiş olabilir; toplama için XML/alan bazlı parsing kullanın (Microsoft bunu özellikle belirtiyor). WEF veya SIEM agent ile merkezileştirin.

Kaynaklar
Alıntı:Yasal not: Yalnızca yönettiğiniz lab veya kurumsal endpoint'lerde etkinleştirin.

Kapak: özgün TurkTeam görseli.

.png   bilgekagan-05.png (Dosya Boyutu: 97.11 KB / İndirme Sayısı: 8) ]]> [Resim: attachment.php?aid=26]
Selamlar,

Yıllardır Sysinternals Sysmon'u ayrı bir exe ile kuruyorduk. 2026'da Microsoft, Windows 11 ve Windows Server 2025'te Sysmon'u isteğe bağlı yerleşik özellik olarak sundu. Lab makinemde denedim; bu konuda kurulum notlarımı ve SOC açısından ne işe yaradığını paylaşıyorum.

Konuda Anlatılacaklar
  1. Yerleşik Sysmon nedir, ne değildir?
  2. Standalone ile birlikte çalışmaz
  3. Etkinleştirme (PowerShell / DISM)
  4. Yapılandırma dosyası (SwiftOnSecurity vb.)
  5. Olayları nerede görürsünüz, SIEM'e nasıl gider?

1) Ne Yapar, Ne Yapmaz?
Microsoft Learn'e göre yerleşik Sysmon süreç oluşturma, ağ bağlantısı, sürücü/DLL yükleme, ham disk erişimi gibi olayları Windows Event Log'a yazar. Analiz etmez, engellemez, varlığını gizlemez. Yani bir EDR değil; yüksek kaliteli telemetri kaynağıdır. SIEM veya Defender for Endpoint gibi ürünlerle birlikte anlam kazanır.

2) Standalone ile Bir Arada Olmaz
Cihazda eski Sysinternals Sysmon kuruluysa önce kaldırın. İkisi aynı anda desteklenmiyor. Kontrol:

Kod:
Get-Service sysmon*

Çıktı boş olmalı. Varsa standalone'u kaldırıp devam edin.

3) Etkinleştirme
Yönetici PowerShell:

Kod:
Enable-WindowsOptionalFeature -Online -FeatureName Sysmon sysmon -i

DISM alternatifi:
Kod:
Dism /Online /Enable-Feature /FeatureName:Sysmon
sonra yine
Kod:
sysmon -i
.

Varsayılan kurulum az olay üretir; mutlaka bir config uygulayın.

4) Yapılandırma
Popüler topluluk config'leri:
  • SwiftOnSecurity/sysmon-config
  • olafhartong/sysmon-modular (MITRE eşlemeli, modüler)

Kod:
# Örnek: config ile kurulum sysmon -i C:\Sysmon\sysmonconfig.xml # Sonradan güncelleme (restart gerekmez) sysmon -c C:\Sysmon\sysmonconfig.xml

Lab'da önce dar bir config ile başlayıp Event Viewer'da gürültüyü izleyin; production'a körlemesine "her şeyi aç" demeyin, disk ve lisans maliyetiniz şişer.

5) Olaylar Nerede?
Event Viewer: Applications and Services Logs > Microsoft > Windows > Sysmon > Operational.

Yerleşik Sysmon'da görüntülenen mesaj metinleri yerelleştirilmiş olabilir; toplama için XML/alan bazlı parsing kullanın (Microsoft bunu özellikle belirtiyor). WEF veya SIEM agent ile merkezileştirin.

Kaynaklar
Alıntı:Yasal not: Yalnızca yönettiğiniz lab veya kurumsal endpoint'lerde etkinleştirin.

Kapak: özgün TurkTeam görseli.

.png   bilgekagan-05.png (Dosya Boyutu: 97.11 KB / İndirme Sayısı: 8) ]]>