Saat sabah 03:12'ydi. Ekrandaki log akışı normalde hipnotize edici bir durağanlığa sahipken, testCompany’nin SOC panelinde alışılmadık bir 'User Enumeration' uyarısı belirdi. Normalde Red Team olarak biz bir şeyler denediğimizde Blue Team'in bunu 15 dakika içinde fark etmesini beklerdik. Ancak bu sefer garip bir durum vardı: Alert gelmişti ama kimse ne yapacağını bilmiyordu. Red Team tarafında biz içeri sızmış, 'Golden Ticket' üretmiş ve Domain Admin haklarıyla içeride geziyorduk. Blue Team ise sadece 'bir şeyler oluyor' diyebiliyordu. İşte o an anladım ki, sadece saldırmak ya da sadece savunmak yetmiyor; aradaki o kopuk köprüyü, yani Purple Team operasyonlarını kurmak zorundayız.
Silolar Arasındaki O Soğuk Savaş
Yıllarca siber güvenlik dünyası iki kutba ayrıldı: 'Biz sızarız, siz tutamazsınız' diyen Red Team ve 'Siz saldırıyorsunuz ama biz de her şeyi görüyoruz' diyen Blue Team. Bu çekişme bazen öyle bir hal alıyor ki, takımlar birbirine bilgi vermekten kaçınıyor, adeta bir ego savaşı başlıyor. Ama gerçek dünya bir CTF yarışması değil dostum. Gerçek bir APT aktörü kapınızı çaldığında, Red Team'in ne kadar zeki olduğu veya Blue Team'in ne kadar hızlı olduğu tek başına bir anlam ifade etmiyor. Eğer bu iki ekip senkronize değilse, organizasyon her zaman bir adım geridedir.
Purple Team, bir takımdan ziyade bir metodolojidir. Saldırı tekniklerini (TTPs) savunma yetenekleriyle eşleştirme sanatıdır. Red Team saldırır, Blue Team izler; sonra bir araya gelip 'Sen burada ne yaptın, ben bunu neden göremedim?' diye sorarlar. Bu süreç, savunma katmanlarını gerçek verilerle güçlendirir.
Teknik Bir Bakış: Kerberoasting ve Tespit Boşluğu
Gelin bu süreci teknik bir senaryo üzerinden inceleyelim. Diyelim ki Red Team olarak testCompany ağında bir 'Kerberoasting' saldırısı simüle ediyoruz. Amacımız, Service Principal Name (SPN) kayıtlı hesapların biletlerini (TGS) çekip çevrimdışı kırmaktır.
Red Team (Saldırı Aşaması - Zararsızlaştırılmış): Bir saldırgan olarak ağa sızdıktan sonra şu komutu koşturduğumu hayal et:
# Defanged/Zararsızlaştırılmış Kerberoasting Payload
# Amaç: Belirli bir SPN için TGS bileti talep etmek
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "HTTP/web-server-01.testcompany.local"
Bu komut çalıştığında, Domain Controller üzerinde bir Event ID 4769 (A Kerberos service ticket was requested) oluşur.
Blue Team (Savunma Aşaması): Eğer Blue Team sadece 'Başarılı Giriş' (Event ID 4624) loglarını izliyorsa, bu saldırıyı kaçıracaktır. Purple Team çalışmasında Red Team bu komutu koşturur ve Blue Team'e der ki: 'Bak, ben şu an bilet istedim, senin ekranına ne düştü?'
Blue Team paneline bakar ve 4769 loglarının çok fazla 'noise' (gürültü) yarattığını, bu yüzden de bu spesifik alarmın gözden kaçtığını fark eder. İşte 'Purple' dokunuşu tam burada başlar.
Tespit Mühendisliği (Detection Engineering)
Purple Team toplantısında şu karar alınır: 'Sadece 4769 loglarını izlemek yerine, şifreleme tipi RC4 (0x17) olan ve zayıf algoritmalar içeren bilet taleplerine odaklanalım.'
Ortaya çıkan Sigma kuralı taslağı (pseudo-code) şöyle olur:
title: Kerberoasting Detection
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketOptions: '0x40810000'
TicketEncryptionType: '0x17' # RC4 encryption - Genelde kırılması kolaydır
condition: selection
Bu kuralı SIEM'e (Örn: Splunk veya ELK) girdiğimizde artık 'görünmez' olan o saldırı, parlak bir kırmızı uyarıya dönüşür. İşte Purple Teaming budur; saldırganın tekniğini alıp onu savunmanın bir parçası haline getirmek.
Sürekli Doğrulama (Continuous Validation)
Bir kere bir kural yazdık ve bitti mi? Tabii ki hayır. Siber dünyada her şey 'drift' eder. Sunucular güncellenir, konfigürasyonlar değişir. Bugün çalışan bir tespit kuralı yarın çalışmayabilir. Bu yüzden 'Atomic Red Team' gibi frameworkler kullanarak bu testleri otomatize etmek gerekir.
Örneğin, her hafta Salı günü saat 23:00'te sistem, otomatik olarak zararsız bir 'LSASS Memory Dump' denemesi yapmalı (Örn: procdump.exe -ma lsass.exe lsass_test.dmp) ve SOC ekibi bu girişimi görüp görmediğini otomatik raporlamalıdır. Eğer rapor 'tespit edilemedi' diyorsa, o gece bir şeyler ters gitmiş demektir ve Purple Team'in devreye girmesi gerekir.
Nereden Başlamalı?
Eğer testCompany gibi büyük bir yapıda çalışıyorsan veya küçük bir butik güvenlik ekibin varsa, Purple Team felsefesine geçmek için şu adımları izleyebilirsin:
- Senaryo Belirle: MITRE ATT&CK matrisinden bir teknik seç (Örn: T1059.001 - PowerShell).
- Saldırıyı Simüle Et: Red Team bu tekniği 'defanged' bir şekilde uygulasın.
- Görünürlüğü Sorgula: Blue Team bu aktiviteyi loglarda, EDR'da veya SIEM'de gördü mü?
- Boşluğu Kapat: Eğer görülmediyse, eksik log kaynağını ekle veya yeni bir korelasyon kuralı yaz.
- Tekrarla: Aynı saldırıyı tekrar yap ve bu sefer alarmın çaldığından emin ol.
Bu döngü, savunmanızı teorik bir 'best practice' listesinden çıkarıp, sahadan gelen gerçek mermilere karşı dayanıklı bir kalkana dönüştürür. Unutma, en iyi defans oyuncusu, forvetin ne düşündüğünü bilendir. Purple Team olmak, sadece teknik bir tercih değil, aynı zamanda o 'gece 3' telefonlarının sayısını azaltan bir huzur stratejisidir.
Bir dahaki sefere Red Team arkadaşın yanına gelip 'Seni hackledim' dediğinde ona kızma; yanına bir sandalye çek ve 'Nasıl yaptın, gel beraber bir kural yazalım' de. Gerçek güvenlik orada başlar.