Phishing Mailini SOAR'sız İncelemek: L1 Analist İçin 10 Adımlık Liste

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.

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.


5) Ekleri hash'le, açma
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.