MCP İle canlı DFIR · saha günlüğü
Claude'a bir AIR konsolu verdim
Binalyze AIR'ı Model Context Protocol ile Claude'a bağladım; sıfır bir Windows 10'da baseline aldım, kalıcılık taktik ve teknikleri uyguladım, karşılaştırdım. Yolda birkaç şey kırıldı en çok onlardan öğrendim.
Bir SOC analistinin günü, çoğu zaman aynı ritüelle geçer: bir makinede "normal" nedir, "sapma" nedir, bunu elle kovalamak. Binalyze AIR bu işi otomatikleştiriyor ama ben bir adım daha ileri gitmek istedim. AIR'ı doğrudan Claude'a bağlarsam, forensic konsolu bir sohbet arayüzünden sürebilir miydim? Model Context Protocol (MCP) tam da bunu vaat ediyordu: bir aracı LLM'e "araç" olarak takmak. Bu yazı, o bağlantıyı kurma ve ilk gerçek drift avımı çıkarma günlüğüm.
Amaç baştan belliydi. Claude'un rolü bir katalizör olacaktı: teknik derinlik, strateji, plan stres-testi gereksiz uyarı üreten bir asistan değil, işi birlikte yürüten bir el. Ve her adımı kanıta bağlayarak ilerleyecektik; "herhalde şöyledir" yok, "bakalım öyle miymiş" var.
01 — BağlantıSessiz hatalar ve iki konsol
MCP server'ı bir iç ağ appliance'ına bağlamak, tek satırlık bir iş değil ama karmaşık da değil: base URL, API token, self-signed sertifika güveni ve org scope. Bunları oturttuğunda bağlantı birkaç dakikada geliyor. Zor olan bağlanmak değildi bağlantıya güvenmekti.
Çünkü hatalar sessizdi. Profiller oluşturdum, Claude "Successfully created" döndürdü; ama listeyi çektiğimde profiller ortada yoktu. Dakikalar önce sorunsuz çözülen bir profil UUID'i birden 404 vermeye başladı. İlk içgüdü "konnektör bozuldu" demekti. Bozulmamıştı. İki şey aynı anda doğruydu: varsayılan list çağrısı, organizationIds=0 açıkça verilmedikçe yalnız System nesnelerini döndürüyordu ve beni asıl yakalayan, oturumun ortasında konnektörün sandığımdan farklı bir AIR instance'ına bakıyor olmasıydı. Ortamda iki konsol vardı, .230 ve .120; "tamir ettim" sandığım an aslında konsol değiştirmiştim.
Ders buydu ve tüm oturuma sindi: her yeşil tikin ardından "hangi konsol, hangi org?" diye sordum, ve bir "success" mesajını asla doğrulama saymadım, nesneyi UUID'iyle geri çekip teyit etmeden ilerlemedim.
02 — KeşifClaude ne yapabiliyor?
Bağlantı gelince ilk yaptığım, yüzeyi haritalamak oldu. Rolüm AIR'da L3/L4 olduğu için araç yüzeyinin neredeyse tamamı açıktı. Ama asıl önemli olan, Claude'un bunları nasıl ele aldığıydı ve burada net bir sınır çizdik: okuma ve sorgu serbest, task atama (baseline, triage, acquisition) rutin, ama canlı endpoint'i etkileyen ve geri-dönüşsüz her şey (isolation, shutdown, uninstall, silme) önce benim onayımı istiyordu. Uygulanan fren AIR'ın izin modeli değil, "yanlışlıkla prod'u kapatma" endişesiydi.
03 — KatalogEvidence sözlüğünü tel üzerinden çıkarmak
Baseline profili tasarlamak için AIR'ın hangi artefaktları hangi kodlarla tanıdığını bilmem gerekiyordu. Ama katalog endpoint'i (/api/public/evidences) 404 döndü. Kod uydurmak DFIR'da en kötü seçenek sessizce boş bir profil üretirsin. O yüzden kodları tahmin etmedik; çalışan bir profilin cevabından okuduk.
full ve evidences isteklerini atıyor; cevabı kopyalayınca ham kod→etiket sözlüğü elimizde.Bu adımda kavramsal bir bomba patladı ve tüm tasarımı değiştirdi: yerleşik Baseline Acquisition for Comparison profili Windows'ta 77 evidence toplar, ama compare motoru bunların hepsini diff'lemez yalnız kanonik kalıcılık/konfig setini. Toplamak ≠ diff'lemek. Bu ayrım, sonraki her kararın zeminiydi.
04 — BaselineProfili doğrulanmış kodlarla kurmak
Elimde geçerli sözlük olunca, Compare-scope disiplinini uygulayan bir profil tasarladık: win_client_core 9 çekirdek kalıcılık kodu (registry run, scheduled task, service, startup, drivers, installed apps, firewall, network adapter, hosts). Windows 7/10/11'de eksiksiz dolu olacak şekilde versiyon-farkındalıklı. Her kodu, çektiğimiz katalogla tek tek eşleştirdik bir varsayımım (crtnh'yi "sertifika deposu" sanmıştım) katalog sayesinde düzeldi; meğer "Cortana History"miş.
list_acquisition_profiles çağrısı yalnız System profillerini döndürüyor; custom profillerin "kayboluyor". Org parametresini açıkça vermezsen "profilim nerede?" paniğini yaşarsın. Bu tek satır, saatlerimi kurtardı.05 — AvCanlı drift: T0 → değişiklik → T1 → compare
Sıra gerçek işe geldi. Sıfır kurulmuş bir Windows 10'a (temiz referans için ideal) baseline aldım, kontrollü kalıcılıklar ektim, tekrar aldım ve karşılaştırdım. Kalıcılıkları ATT&CK'e temiz eşleşecek şekilde seçtim: bir Run key (T1547.001), bir scheduled task (T1053.005), bir servis (T1543.003).
sc = Set-Content. Servisi PowerShell'de sc create … ile kurmaya çalışınca hata aldım çünkü PowerShell'de sc, Set-Content cmdlet'inin alias'ı. Çözüm sc.exe ya da native New-Service. Küçük bir detay ama tespit açısından öğretici: alias'lar komut-satırı telemetrisini saptırır.Ve işte dürüst bir başarısızlık: MCP üzerinden compare_baseline, doğru task ID'leriyle bile response.result.map is not a function parse hatası verdi. Wrapper defekti. Kör "oldu" demek yerine olduğu gibi yazdım envanterime: compare — UI-only, MCP kırık. Karşılaştırmayı AIR arayüzünden çalıştırdım (DRONE differ), ve rapor açıldı.
06 — Sonuç532 deltadan 3 IOC'ye
Rapor açıldığında ilk gördüğüm sayı ürküttü: 445 Added / 52 Changed / 35 Deleted. Sıfır bir makine, bir saatlik pencerede 500'den fazla delta üretmişti. Benim üç kalıcılığım bu yığının içinde, sinyal oranı yaklaşık %0.7. İşte SOC'un asıl dersi burada: ham diff seni boğar; değer, gürültüyü ayıklamakta.
Sinyali gürültüden ayıran şey metadata oldu. Eklenen Run key kaydını açtığımda, detection mantığını doğrudan kuracağım alanlar oradaydı: dosya yok (file_exists:0), imzasız, ve C:\Users\Public altında dünya-yazılabilir bir staging dizini. Meşru bir Run key imzalı ve Program Files altında olur.
UpdaterSvc → beacon.exe: imzasız, dosya yok, kullanıcı-yazılabilir path. Her satır bir kırmızı bayrak.
Ama raporun asıl yıldızı beklemediğim yerden geldi: PowerShell ConsoleHost History. Differ, operatörün tam komut satırlarını yakalamıştı attribution, tradecraft, niyet. Dahası, başarısız sc create denemelerimi bile yakaladı. O başarısız komutlar hiçbir servis, hiçbir başka artefakt bırakmamıştı; ama niyet PSReadLine dosyasında duruyordu. Komut-satırı telemetrisinin neden vazgeçilmez olduğunun canlı kanıtı.
ConsoleHost_history, başarısız sc create dahil tüm komutları yakaladı.Bir de adjudication dersi vardı: rapor, planlamadığım "korkutucu" kayıtlar da gösterdi yeni bir Credential Provider GUID'i, bir shell context-menu handler'ı. İkisi de meşru Windows bileşenleri, ilk-boot'ta kaydolmuş. Analistin görevi tam da bu: her korkutucu satırı IOC ilan etmemek, doğrulamak. "Neyin olmadığı" da bir o kadar önemliydi Users, Hosts, Network Adapters hepsi "No differences", yani yeni hesap yok, C2 redirect yok. Bu, olayın kapsamını daraltıyordu.
07 — DerslerKırılanlardan öğrendiklerim
Bu yolculuğun en değerli kısmı, düzgün çalışan kısımları değil, kırılan kısımlarıydı. Çoğu eğitim ve demo happy-path gösterir; oysa gerçek saha, tuzaklarla dolu. Bende çıkan liste kısaca şöyle: https:// şeması olmadan MCP bağlanmaz; organizationIds=0 verilmeden custom profiller görünmez; PowerShell'de sc bir alias'tır; compare_baseline bu sürümde MCP'den kırık; ve en kavramsal olanı toplamak diff'lemek değildir.
LLM'i DFIR'a bağlamak, sihirli bir "her şeyi çöz" düğmesi değil. Onu değerli kılan şey, hızlı sorgulama-korelasyon-doğrulama döngüsü ve her adımı kanıta bağlama disiplini. Kod uydurmadık, katalogdan okuduk. "Oldu" demedik, listeyle teyit ettik. Compare kırılınca gizlemedik, envantere yazdık. Bir aracı bir modele bağlamak kolay; onu dürüstçe kullanmak asıl iş.
Ve itiraf edeyim: sıfır bir Windows 10'un, bir saatte 500 delta üretip içinde 3 gerçek IOC sakladığını canlı görmek bir SOC eğitiminde saatlerce anlatabileceğim her şeyi tek bir ekrana sığdırdı. Ayakları yere basan lab budur.
Yorumlar
Yorum Gönder