Cuma akşamı tam bilgisayarı kapatmışsın, kafanda hafta sonu planları var. Derken telefonun çalıyor. Arayan SOC (Security Operations Center) ekibinden bir arkadaşın. Sesi biraz titriyor, "Sedat, domain controller üzerinde garip bir trafik var, galiba birileri içeride fink atıyor" diyor. İşte o an damarlarındaki adrenalini hissedersin. Incident Response (Olay Müdahale) dediğimiz şey, aslında o telefonla başlayan ve bazen günlerce süren bir satranç maçı.
İşin aslı, çoğu şirket "bizim başımıza gelmez" kafasında yaşadığı için bu süreçler hep bir kaosla başlıyor. Ama sahada gördüğüm net bir şey var: O kaos anını ne kadar iyi yönetirsen, hasarı o kadar azla atlatırsın. Gel, şu işin kitabına değil de, sahadaki gerçeklerine biraz yakından bakalım.
Panik En Büyük Düşmanın
Genelde bir sızıntı fark edildiğinde yapılan ilk hata, hemen "fişi çekmek". Panikle sunucuyu kapatmak ya da diski formatlamak, aslında saldırganın bıraktığı ekmek kırıntılarını (yani delilleri) yok etmekten başka bir işe yaramıyor. Bir Red Team tarafında çalışan biri olarak söylüyorum; biz saldırganlar en çok sizin panik yapmanızı severiz. Çünkü panik yapınca logları temizlememize gerek kalmaz, siz zaten kendi ellerinizle silersiniz.
Diyelim ki bir Linux sunucunda şüpheli bir süreç gördün. Hemen kill -9 yapıp geçme. Önce o sürecin nereye bağlandığına, hangi dosyaları kurcaladığına bakman lazım.
Mesela basit bir netstat komutu bile sana çok şey anlatır ama ben genelde lsof kullanmayı daha çok severim. Bir keresinde bir sunucuda çok gizli bir backdoor bulmuştuk, adamlar kendilerini standart bir servis gibi göstermişlerdi ama lsof ile baktığımızda hiç alakası olmayan bir dizinden kütüphane çağırdığını yakalamıştık.
# Şüpheli bir sürecin hangi dosyaları açtığını görmek için
lsof -p [PID]
# Ağ bağlantılarını anlık izlemek için pratik bir yol
watch -n 1 "ss -tpue"
Loglar Yalan Söylemez (Eğer Varsa)
Incident Response sürecinde en çok duyduğum cümle ne biliyor musun? "Abi o logları tutmamışız." İşte bu, bir güvenlikçinin duyabileceği en acı verici sözlerden biri. Saldırgan sisteme girmiş, Powershell ile at koşturmuş ama sen Powershell Script Block Logging’i açmamışsın. Geçmiş olsun.
Sıkça karşılaştığım bir durum: Saldırgan Invoke-Expression (IEX) kullanarak bellekte kod çalıştırıyor. Eğer senin EDR'ın ya da loglama sistemin buna bakmıyorsa, diskte dosya arayarak ömrünü tüketirsin ama hiçbir şey bulamazsın.
Bir Python scriptiyle logların içinde hızlıca "anomaly" aramak hayat kurtarabilir. Tabii milyonlarca satır logdan bahsediyoruz, o yüzden elinin altında her zaman hızlı parse yapabileceğin araçlar olmalı. Ben bazen şöyle basit bir şey kullanıyorum hızlıca göz atmak için:
import re
# Basit bir log analiz örneği - Şüpheli IP ve anahtar kelime avcısı
LOG_FILE = "/var/log/auth.log"
SUSPICIOUS_KEYWORDS = ["failed", "invalid user", "accepted password"]
def analyze_logs():
try:
with open(LOG_FILE, 'r') as f:
for line in f:
if any(keyword in line.lower() for keyword in SUSPICIOUS_KEYWORDS):
# Burada IP adresini regex ile çekip bir sete atabilirsin
ip_match = re.search(r'(\d{1,3}\.){3}\d{1,3}', line)
if ip_match:
print(f"[!] Şüpheli Aktivite: {line.strip()}")
except FileNotFoundError:
print("Log dosyası bulunamadı, yolları kontrol et.")
if __name__ == "__main__":
analyze_logs()
"Containment" Yani Yangını Söndürmek Değil, Etrafını Çevirmek
Yangın çıktığında itfaiyenin yaptığı ilk iş nedir? Yangının diğer binalara sıçramasını engellemek. Incident Response'ta da mantık aynı. Bir makine kompromize olduysa, o makineyi network'ten izole etmelisin ama hemen yok etmemelisin.
Bence burada en kritik nokta "Lateral Movement" dediğimiz, saldırganın içeride yana doğru yayılma aşamasını durdurmak. Saldırgan bir kere içeri girdi mi, senin local admin şifrelerinle diğer sunuculara zıplamaya çalışacaktır. Eğer her makinede aynı "Local Admin" şifresini kullanıyorsan (ki hala çok yaygın bir hata), geçmiş olsun; domino taşları gibi hepsi devrilir.
Böyle bir durumda PowerShell ile hızlıca kimlerin hangi sistemlerde oturum açtığını kontrol etmek işe yarayabilir:
# Uzak bir bilgisayardaki aktif oturumları listeleme
qwinsta /server:HEDEF_SUNUCU_ADI
# Belirli bir kullanıcının ağ üzerindeki izlerini arama (Event ID 4624)
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624} | Where-Object {$_.Properties[5].Value -like "*SüpheliKullanıcı*"}
Kendi Deneyimimden Bir Örnek: "Görünmez" Saldırgan
Geçenlerde bir pentest değil de, bu sefer savunma tarafına yardım ettiğim bir olayda başımıza geldi. Müşterinin web sunucusu sürekli bir yerlere istek atıyor ama sistemde ne bir dosya değişikliği var ne de şüpheli bir süreç.
İşin aslı şuydu: Saldırgan, meşru bir Linux servisinin içine "Shared Object" (LDAP kütüphanesi gibi) enjekte etmişti. Servis her çalıştığında saldırganın kodunu da çalıştırıyordu. Bunu klasik araçlarla bulmak çok zor. Ancak sistem çağrılarını (strace) izleyerek kütüphanenin beklenen dışında bir yere gittiğini fark ettik.
Dikkat etmen gereken nokta şu; saldırganlar artık çok akıllı. Sadece "EXE" veya "Script" çalıştırmıyorlar. Sistemdeki mevcut yapıları senin aleyhine kullanıyorlar (Living off the Land).
Olay Bittiğinde Başın Göğe Ermiyor
Saldırganı sistemden attın, açığı kapattın, her şey yolunda mı? Hayır. İşin en sıkıcı ama en öğretici kısmı şimdi başlıyor: Post-Mortem. Yani "Biz nerede patladık?" sorusuna dürüstçe cevap verme vakti.
Genelde kurumsal yerlerde bu aşama "suçlu kim?" oyununa döner ama bence bu en büyük yanlış. Güvenlik bir süreçtir, bir ürün değil. Eğer saldırgan bir Phishing mailiyle içeri girdiyse, suçlu o maili açan çalışan değil, o mailin son kullanıcıya ulaşmasına izin veren sistem ve o mail açıldığında saldırganın tüm network'ü ele geçirmesine izin veren zayıf mimaridir.
Öğrenmeye Açık Ol, Toollara Boğulma
Piyasada çok pahalı IR (Incident Response) araçları var. Hepsi çok güzel, çok renkli ekranlara sahip. Ama işin özünde senin "bir gariplik var" diyebilecek sezgilere ve o garipliğin peşinden gidecek temel teknik bilgiye ihtiyacın var.
Bence her sabah bir önceki günün önemli güvenlik haberlerine göz atmak, yeni çıkan APT gruplarının tekniklerini (TTPs) incelemek seni bir adım öne taşır. MITRE ATT&CK matrisini sadece bakmak için değil, "Saldırgan burada ne yapardı?" diye düşünmek için kullan.
Sonuçta bu bir kedi fare oyunu. Bugün sen kazanırsın, yarın saldırgan yeni bir yöntem bulur. Önemli olan düştüğünde ne kadar hızlı kalktığın ve o düşüşten ne öğrendiğin.
Hadi şimdi git ve o logları bir kontrol et, belki de telefonun çalmasını beklemene gerek yoktur.