Siber olay incelemesi: yetkisiz erişim, hesap ele geçirme ve veri ihlali

7545 sayılı Siber Güvenlik Kanunu siber olayı, bilişim sistemlerinin veya verinin gizlilik, bütünlük veya erişilebilirliğinin ihlal edilmesi olarak tanımlar (m.3). Bize gelen sorular daha somuttur: muhasebe hesabına kim girdi; müşteri veri tabanı dışarı çıktı mı, çıktıysa hangi kayıtlar; ayrılan çalışan sisteme erişmeye devam etti mi; web sitesine yapılan saldırı başarılı oldu mu?

Bu sayfadaki iş olayın teknik incelemesi ve raporlanmasıdır. İzole etme, temizleme ve yeniden kurma kararlarını kurumun BT ekibi ya da müdahale firması verir; incelemeyi bu adımların delili bozmayacağı sıraya göre planlarız.

Olayın ilk saatlerinde ne yapılmalı?

İlk saatlerde yapılan her işlem ya delili korur ya da siler:

1. Cihazı kapatmayın, yeniden kurmayın. Yayılmayı durdurmak için ağ bağlantısını kesin, saatini not edin. Çalışan süreçler ve açık bağlantılar bellektedir, kapatınca kaybolur (RFC 3227).
2. Kayıtları dışa aktarın. Bulut, güvenlik duvarı ve sunucu loglarının ömrü kısadır; otomatik silmeyi durdurun.
3. Saldırganın bıraktığını önce kaydedin, sonra kaldırın: posta kutusu yönlendirme kuralı, yeni kullanıcı, zamanlanmış görev.
4. Parolaları değiştirin, açık oturumları sonlandırın, hesaba eklenmiş yeni çok faktörlü doğrulama (MFA) yöntemlerini kontrol edin.
5. Olay günlüğü tutun: kim, ne zaman, ne yaptı.
6. Bildirim sürelerini hukukçunuzla değerlendirin. Kişisel veri söz konusuysa KVKK süresi işlemeye başlamış olabilir.

Ayrıntılı kontrol listesi: dijital delil nasıl korunur?

Hangi olayları, hangi kayıtlarla inceliyoruz?

SIEM, IDS/IPS ve EDR uyarıları ilk ipucunu verir, kararı vermez; her uyarının arkasındaki ham kayda döneriz. Kaynak türleri için: log analizi.

Saldırı denemesi ile başarılı saldırı aynı şey değil

İnternete açık her sunucu her gün taranır; asıl soru denemenin başarılı olup olmadığıdır.

Örnek (Apache erişim logu):

203.0.113.45 - - [12/Mar/2026:02:11:09 +0300] "GET /urun.php?id=12%27%20OR%20%271%27%3D%271 HTTP/1.1" 500 612 "-" "sqlmap/1.8"
203.0.113.45 - - [12/Mar/2026:02:11:14 +0300] "GET /urun.php?id=-1%20UNION%20SELECT%20eposta,parola%20FROM%20uyeler-- HTTP/1.1" 200 48211 "-" "sqlmap/1.8"

Birinci satır bir SQL Injection denemesidir: URL-kodlu tırnak ve OR '1'='1 kalıbı var, sunucu 500 hatası dönmüş. İkinci satırdaki olağandışı büyük yanıt veri döndüğüne işaret edebilir; kanıtı uygulama ve veri tabanı loglarındadır. Dikkat edilecekler:

• Apache'nin varsayılan erişim logu yalnızca istek satırını tutar, POST gövdesini tutmaz. Formdan yapılan enjeksiyon ya da kalıcı (stored) XSS bu logda görünmeyebilir.
• User-Agent istemcinin beyanıdır. "sqlmap" yazması aracı düşündürür, kanıtlamaz.
• Sunucu ters vekil ya da CDN arkasındaysa logdaki IP vekilindir; hangi alanın loglandığını yapılandırmadan doğrularız. Adresin özel, CGNAT ya da genel IP olduğunu IP adresi kontrol aracı gösterir.
• XSS denemesi %3Cscript gibi kalıplarla görünür; betiğin başka bir kullanıcının tarayıcısında çalışıp çalışmadığı çoğu zaman sunucu logundan gösterilemez.

Brute-force'ta da aynı ayrım geçerlidir. Windows'ta 4625 olayının alt durum kodu denemenin türünü söyler: 0xC000006A var olan kullanıcı adına yanlış parola, 0xC0000064 var olmayan kullanıcı adıdır. Tek hesaba yığılmış yüzlerce 0xC000006A parola tahminine (ATT&CK T1110.001), çok sayıda hesaba birkaç denemeyle yayılan girişimler parola püskürtmeye (password spraying, T1110.003) işaret eder. Aralarında çok sayıda 0xC0000064 olması, başka yerden sızmış kullanıcı adı ve parola listelerinin denendiğini (credential stuffing, T1110.004) düşündürür. Belirleyici olan, aynı kaynaktan gelen ilk başarılı 4624 kaydıdır. Linux'ta karşılığı sshd'nin Failed password for invalid user ve Accepted password for satırlarıdır. Açığın koddaki kaynağı ayrı bir incelemedir: web sitesi ve web uygulaması incelemesi.

Hesap ele geçirme ve şüpheli oturumlarda hangi kayıtlar belirleyici?

Hesabı ele geçiren kişi geçerli kimlik bilgileriyle girer (ATT&CK T1078); logda "başarılı giriş" görünür. Ayrımı bağlam yapar: IP ve servis sağlayıcı, ülke, cihaz ve tarayıcı, saat; bu işaretler tek tek değil birlikte okunur. MFA'nın "başarılı" görünmesi de girişi hesap sahibinin yaptığını göstermez: araya giren (adversary-in-the-middle) bir oltalama sayfası oturum çerezini ele geçirirse saldırgan MFA'ya takılmadan girebilir (ATT&CK T1539). Bu yüzden oturum kimliğini izler, o oturumun sonraki işlemlerini birlikte okuruz.

Microsoft 365'te bakılan başlıca yerler:

• Microsoft Entra ID oturum kayıtları: ücretsiz sürümde 7, P1/P2'de 30 gün tutulur. Olay geç fark edilirse ilk yetkisiz giriş bu pencerenin dışında kalır.
• Birleşik denetim günlüğü: 17 Ekim 2023'ten itibaren üretilen Audit (Standard) kayıtları 180 gün tutulur. Posta kutusu kuralı (New-InboxRule, Set-InboxRule, UpdateInboxRules) ve yönlendirme (Set-Mailbox) işlemleri burada görünür. Saldırganlar gelen iletileri RSS gibi göze batmayan klasörlere taşıyıp okundu işaretleyen kurallarla gizleyebilir.
• MailItemsAccessed: hangi iletilere erişildiğini gösterir; E3/E5 lisanslarında varsayılan olarak açıktır. Tek tek açılan iletilerde (bind) her iletinin InternetMessageId değeri kaydedilir. Masaüstü Outlook'la toplu indirmede (sync) kayıt klasör düzeyindedir ve o klasördeki bütün iletiler ele geçmiş kabul edilir; ihlalin kapsamını bu ayrım belirler.

Ele geçirilen hesaptan ödeme talimatı gönderildiyse iletinin kendisi de incelenir: e-posta incelemesi.

Yetki yükseltme ve zararlı yazılım izleri

Yetki yükseltmede aranan, sıradan bir hesabın yönetici yetkisi kazandığı an ve bunu kimin yaptığıdır. Windows'ta 4732 olayı yerel güvenlik grubuna (ör. Administrators) üye eklendiğini, ekleyen hesabı ve oturum kimliğini (Logon ID) kaydeder; bu kimlik aynı oturumun 4624 kaydına bağlanır.

Zararlı yazılım izlerinde iki ayrıntı sık yanılgı doğurur: 4688 olaylarının komut satırı alanı ilgili politika açılmadıysa boştur; Amcache'te bir dosyanın görünmesi ise sistemde bulunduğunu gösterir, çalıştırıldığını değil. Fidye yazılımında (ATT&CK T1486) şifrelenmiş dosyaların değişiklik zamanları, şifrelemenin nerede ve ne zaman başladığını gösterebilir.

Şüpheli dosyayı herkese açık tarama servislerine yüklemeyiz, yalnızca SHA-256 değeriyle sorgularız: VirusTotal, gönderilen dosyaların içeriğinin ücretli müşterileriyle paylaşılabileceğini belirtir. Değeri dosyayı hiçbir yere göndermeden hash hesaplama aracıyla bulabilirsiniz.

Veri ihlalinde teknik inceleme ve KVKK bildirimi

KVKK m.12/5'e göre işlenen kişisel veriler kanuni olmayan yollarla başkalarınca elde edilirse veri sorumlusu bunu en kısa sürede ilgilisine ve Kurul'a bildirir. Kurul'un 2019/10 sayılı kararına göre Kurul'a bildirim öğrenme tarihinden itibaren gecikmeksizin ve en geç 72 saat içinde, ilgili kişilere makul en kısa sürede yapılır; bilgiler aşamalı verilebilir, 72 saat aşılırsa gecikmenin nedeni eklenir. İhlalin bilgileri, etkileri ve tedbirler kayıt altında tutulur.

Bildirimin teknik soruları incelemeyle cevaplanır:

• İhlal ne zaman başladı, ne zaman fark edildi, ne zaman durduruldu?
• Hangi veri kategorileri, yaklaşık kaç kayıt ve kişi etkilendi?
• Giriş yolu neydi, erişim sürüyor mu?
• Hangi teknik tedbirler alındı?

İlk uyarının ne zaman üretildiği ve kime ulaştığı kayıtlardan gösterilebilir; bunun hukuken "öğrenme" anı sayılıp sayılmayacağı veri sorumlusunun ve hukukçusunun kararıdır. 7545 sayılı Kanun da kapsamındakilere, tespit ettikleri zafiyet veya siber olayları gecikmeksizin Siber Güvenlik Başkanlığına bildirme yükümlülüğü getirir (m.7/1-b); kurumunuzun kapsamda olup olmadığı ayrıca değerlendirilir.

Siber olay zaman çizelgesi nasıl kurulur?

Zaman çizelgesi, farklı sistemlerin kayıtlarının tek bir saat eksenine dizilmesidir. Adımlar:

1. Kayıtlar dışa aktarılır; her dosyanın SHA-256 değeri, kimden ve nasıl alındığı yazılır.
2. Her kaynağın saat dilimi ve sapması belirlenir. Windows olay günlükleri UTC, Nginx'in $time_local alanı yerel saat tutar; sapmayı 4616 olayları ve NTP durumu gösterir.
3. Zamanlar UTC'ye çevrilir, yanına Türkiye saati (2016'dan beri UTC+3) yazılır. Ayrıntı: zaman damgaları ve saat dilimi.
4. Olaylar ortak anahtarlarla bağlanır: hesap adı, IP, oturum kimliği, dosya hash'i.
5. Her satır ham kayda bağlanır; kayıt ile yorum ayrı sütunda durur.

Örnek (kurgusal) çizelge kesiti:

Teknikleri MITRE ATT&CK sürümüyle yazarız: v19'da (Nisan 2026) "Defense Evasion" taktiği "Stealth" (TA0005) ve "Defense Impairment" (TA0112) olarak ikiye ayrıldı; eski raporlarla karşılaştırmada bu fark önemlidir.

Olay müdahale kayıtlarının incelenmesi

Olaya daha önce BT ekibi ya da dış firma müdahale ettiyse onların kayıtları da incelenir: olay biletleri, EDR konsolu işlemleri, alınan imajlar, parola sıfırlamaları. İki soru sorarız: müdahalede hangi izler istemeden değişti, müdahale raporundaki sonuçlar ham veriden gerçekten çıkıyor mu? Referansımız, olay müdahalesini CSF 2.0 fonksiyonlarıyla ilişkilendiren NIST SP 800-61 Rev. 3'tür (Nisan 2025); 2012 tarihli Rev. 2'nin yerini almıştır.

Raporda neler yer alır?

• İncelenen kayıt ve imajların listesi, SHA-256 değerleri ve teslim bilgisi
• Kaynak başına saat dilimi ve sapma notu
• Olay zaman çizelgesi (UTC ve Türkiye saati), her satırın dayandığı kayıtla
• Giriş yolu, kullanılan hesaplar, erişilen sistemler ve veriler; sürümüyle ATT&CK eşlemesi
• Gösterge listesi: IP, alan adı, dosya hash'i
• Bulgu dili: "gösterir", "ile uyumludur", "mevcut kayıtlarla belirlenemedi"
• Sınırlar: eksik kayıtlar, doğrulanamayan varsayımlar

Rapor şirket içi karar ve bildirimlerde ya da avukatınız aracılığıyla uzman görüşü olarak kullanılabilir. Suçun oluşup oluşmadığı ya da kusur gibi hukuki değerlendirmeler rapora girmez.

İncelemenin sınırları

En sık sınır, kaydın hiç tutulmamış olmasıdır: süreç oluşturma denetimi kapalıdır, uygulama başarısız girişi yazmaz, loglar birkaç günde döner. Saldırganın sistemlerine erişmeyiz, karşı saldırı yapmayız; yalnızca hukuka uygun elde edilmiş kayıtlarla çalışırız. Bir kaydın yokluğu olayın yaşanmadığını göstermez; raporda bunu açıkça yazarız.