Yedek Altyapısına Yönelik Saldırı Belirtileri ve Alarmlar

Fidye yazılımı operatörü şifreleme komutunu çalıştırmadan önce kurtarma yollarınızı kapatır: yedek işlerini siler, saklama sürelerini kısaltır, gölge kopyaları ve kurtarma ayarlarını yok eder, hipervizörlere erişim açar. Bu hazırlık çoğu zaman şifrelemeden saatler, hatta günler önce yapılır. Doğru olayları izliyorsanız görürsünüz. Bu rehber, bu davranışları tespit edilebilir olaylara, alarm önceliklerine ve yanıt adımlarına çevirir.

Saldırganlar yedekleri neden önce hedef alır

Fidye talebinin pazarlık gücü, kurumun kendi başına geri dönememesine dayanır. Çalışan yedek, saldırganın tek kozunu boşa çıkarır. Bu yüzden yedek altyapısı, saldırı zincirinde kimlik bilgisi ele geçirme ve yanal hareketin hemen arkasından gelen hedeftir. Önce yedek, sonra şifreleme. MITRE ATT&CK bu davranışları T1490 “Inhibit System Recovery” tekniği altında toplar.

Sahada görülen tipik sıra:

1. Etki alanı yönetici yetkisi veya yedek konsolu kimlik bilgisi elde edilir.
2. Yedek konsoluna oturum açılır; depolar, işler ve kopya hedefleri keşfedilir.
3. İşler devre dışı bırakılır veya silinir, saklama süreleri kısaltılır, geri yükleme noktaları silinir.
4. Windows sistemlerinde gölge kopyalar ve kurtarma ortamı devre dışı bırakılır.
5. Hipervizörlere SSH veya yönetim arayüzü üzerinden erişilir; sanal makineler kapatılır ve şifrelenir.

İkinci ile dördüncü adım arasındaki her olay bir tespit fırsatıdır; bu pencere kaçırılırsa ikinci şans genellikle şifrelenmiş ekran olur. Önleyici tasarım (yedek altyapısının kimlik olarak ayrılması) yedek altyapısında kimlik izolasyonu rehberinin konusu. Burada amaç, önleme tuttuğu yerde değil, tutmadığı yerde saldırıyı erken görmek.

İzlenecek yedek konsolu olayları

Yedek yazılımlarının çoğu yönetimsel işlemleri kendi denetim kaydına, Windows olay günlüğüne veya syslog’a yazar. Olay kimlikleri ve alan adları ürüne ve sürüme göre değişir; başka bir ortamdan kopyalanmış olay listesine güvenmeyin. Önce kendi ürününüzün olay kataloğunu çıkarın, sonra aşağıdaki davranışlara karşılık gelen kayıtları eşleyin:

• Oturum olayları: Konsola başarılı ve başarısız girişler, alışılmadık kaynak adresi, mesai dışı oturum.
• İş değişiklikleri: İş silme, devre dışı bırakma, zamanlamanın kaldırılması, kapsamdan sanal makine çıkarılması.
• Saklama değişiklikleri: Geri yükleme noktası sayısının veya gün sayısının azaltılması, GFS ayarlarının kaldırılması.
• Depo değişiklikleri: Depo kaldırma, değiştirilemezlik süresinin kısaltılması, kopya hedefinin silinmesi.
• Geri yükleme noktası silme: Diskten silme komutu, yedek dosyalarının toplu silinmesi.
• Güvenlik ayarları: Şifreleme parolası değişikliği, kullanıcı veya rol ekleme, MFA’nın kapatılması, dört göz onayı ayarının değiştirilmesi.
• Bildirim ayarları: E-posta veya syslog hedefinin değiştirilmesi; saldırgan önce sesi kısmaya çalışabilir.

Bu olaylar ancak konsolun dışına anlık çıkarıldığında işe yarar. Konsolu ele geçiren saldırgan yerel kayıtları da siler. Syslog veya ajan üzerinden SIEM’e aktarımı kurduktan sonra, aktarımın kesilmesini de ayrı bir alarm yapın. Susan kaynak, şüpheli kaynaktır.

Windows tarafında gölge kopya ve VSS göstergeleri

Windows uç noktalarında ve sunucularda kurtarmayı engellemek için kullanılan komutlar iyi bilinir; komut satırı kaydı açıksa kolayca yakalanır. Ön koşul, süreç oluşturma olayında (Güvenlik günlüğü 4688) komut satırını kaydetme ilkesinin etkin olması veya Sysmon olay kimliği 1’in toplanmasıdır. Sahada en sık gördüğümüz eksik tam olarak budur: 4688 toplanıyor, ama komut satırı alanı boş.

Komut / davranış	Amaç	Kaynak
vssadmin delete shadows /all /quiet	Gölge kopyaları silme	4688, Sysmon 1
vssadmin resize shadowstorage (çok küçük değer)	Gölge kopyaların otomatik silinmesini tetikleme	4688, Sysmon 1
wmic shadowcopy delete veya PowerShell ile Win32_ShadowCopy silme	Gölge kopyaları silme	4688, Sysmon 1, PowerShell 4104
wbadmin delete catalog -quiet	Windows Server Backup kataloğunu silme	4688, Sysmon 1
bcdedit /set {default} recoveryenabled no	Windows kurtarma ortamını kapatma	4688, Sysmon 1
VSS hizmetinin durdurulması veya devre dışı bırakılması	Yedek alınmasını engelleme	System 7036 / 7040
Güvenlik veya System günlüğünün temizlenmesi	İz silme	Security 1102, System 104

Aşağıdaki Sigma kuralı, gölge kopya silme girişimini süreç oluşturma olaylarında arar. Sigma, SIEM’den bağımsız bir kural biçimidir ve kullandığınız SIEM’in sorgu diline dönüştürülebilir:

title: Golge Kopya Silme Girisimi
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  sel_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains|all:
      - 'delete'
      - 'shadows'
  sel_wmic:
    Image|endswith: '\wmic.exe'
    CommandLine|contains|all:
      - 'shadowcopy'
      - 'delete'
  sel_resize:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains|all:
      - 'resize'
      - 'shadowstorage'
  condition: 1 of sel_*
level: high
tags:
  - attack.impact
  - attack.t1490

Meşru kullanım nadirdir ama vardır: bazı yedek ürünleri ve disk bakım betikleri gölge kopyaları yönetir. Kuralı canlıya almadan önce birkaç haftalık geçmiş veride çalıştırın, meşru üst süreçleri ve hizmet hesaplarını istisna olarak ekleyin. İstisnayı yalnız dosya adıyla değil, üst süreç yolu ve hesapla birlikte tanımlayın; saldırgan aynı dosya adını taşıyan bir araç getirebilir. Geniş istisna, kör nokta demektir.

Depolama ve hipervizör tarafı belirtiler

Hipervizör

VMware ESXi hedefli fidye yazılımları genellikle ESXi kabuğuna SSH ile girer, sanal makineleri kapatır ve disk dosyalarını şifreler. Tek bir host, onlarca sunucu demektir. İzlenecekler:

• ESXi üzerinde SSH veya ESXi Shell hizmetinin etkinleştirilmesi (vCenter olaylarında ve host günlüklerinde görünür).
• Lockdown modunun kapatılması ve yeni yerel kullanıcı oluşturulması.
• ESXi shell.log ve auth.log içeriğinde, kısa sürede çok sayıda sanal makineyi kapatan veya süreç sonlandıran komutlar.
• vCenter’da toplu güç kapatma, snapshot silme ve datastore dosya işlemleri.

Bu günlükleri ESXi üzerinden uzak bir syslog hedefine gönderin. ESXi’nin yerel günlükleri kalıcı depolamada değilse yeniden başlatmada kaybolur; kurulumda scratch ve log konumu kontrol edilmeden bırakılan host’lara sahada sık rastlanır.

Depolama ve nesne depolama

NAS ve depolama dizilerinde yönetim arayüzüne giriş, snapshot silme, snapshot zamanlamasının kaldırılması ve replikasyonun durdurulması izlenir. S3 uyumlu nesne depolamada yapılandırma değişiklikleri belirgin iz bırakır. AWS’de CloudTrail üzerinden izlenecek örnek olaylar:

• PutBucketLifecycle: Nesnelerin otomatik silinmesini sağlayacak yaşam döngüsü kuralı eklenmesi (API adı PutBucketLifecycleConfiguration olsa da CloudTrail olayı bu adla kaydedilir).
• PutBucketVersioning: Sürüm tutmanın askıya alınması.
• PutObjectLockConfiguration: Kova düzeyindeki varsayılan saklama ayarının değiştirilmesi (yönetim olayı).
• PutObjectRetention: Nesne düzeyinde saklama süresinin değiştirilmesi; Governance modunda s3:BypassGovernanceRetention yetkisiyle kısaltma girişimleri bu olayda görünür. Nesne düzeyinde olduğu için veri olayıdır.
• DeleteObject ve DeleteObjects: Toplu silme. Bu ve yukarıdaki nesne düzeyindeki olaylar CloudTrail’de veri olayıdır; varsayılan olarak kaydedilmez, yedek kovası için ayrıca etkinleştirilmesi gerekir.

Değiştirilemez depo seçeneklerinin hangi saldırgan yetkisine karşı koruduğu değiştirilemez yedek seçenekleri yazısında karşılaştırılıyor. İzleme, bu korumaların atlatılmaya çalışıldığı anı görünür kılar. Koruma ve izleme birlikte çalışır.

Olay–alarm önceliği tablosu

Her olayı aynı öncelikte göndermek, nöbetçiyi alarm yorgunluğuna sokar ve asıl alarm gürültüde kaybolur. Aşağıdaki tablo, olayın tek başına ne kadar güçlü bir saldırı göstergesi olduğuna ve etkisinin geri alınıp alınamayacağına göre başlangıç önceliği önerir:

Olay	Öncelik	Gerekçe
Değiştirilemezlik süresinin kısaltılması, depo kaldırma	Kritik	Korumanın kendisini hedefler
Yedek işi veya geri yükleme noktası silme	Kritik	Geri alınamaz veri kaybı
Şifreleme parolası değişikliği	Kritik	Yeni yedekleri saldırgan anahtarına bağlayabilir
Gölge kopya silme, kurtarma ortamını kapatma	Yüksek	Şifrelemenin hemen öncesinde görülür
ESXi SSH etkinleştirme, lockdown kapatma	Yüksek	Hipervizör şifrelemesinin ön adımı
Saklama süresi kısaltma, iş devre dışı bırakma	Yüksek	Sessiz ama birikimli etki
Konsola yeni kaynak adresten veya mesai dışı giriş	Orta	Tek başına zayıf, korelasyonda güçlü
Bildirim veya syslog hedefi değişikliği, log akışının kesilmesi	Orta–yüksek	İzlemenin körleştirilmesi

Kurumsal siber güvenlik izlemesinde korelasyon, tek tek olaylardan güçlü sinyal üretir. Aynı hesapla konsola mesai dışı giriş ve ardından bir saat içinde saklama değişikliği: iki orta öncelikli olay, tek bir kritik alarm olmalı. Tek başına zayıf, birlikte net.

SIEM’e aktarım ve yanıt eylemleri

Aktarım tasarımında üç kural var. Birincisi, log akışı yedek altyapısının kimlik alanından bağımsız olur; SIEM’e yönetici erişimi yedek yöneticisi hesaplarıyla aynı olmaz. İkincisi, kaynak bazında “son olay zamanı” izlenir ve beklenen süre içinde log göndermeyen kaynak için alarm üretilir. Üçüncüsü, yedek olaylarının SIEM’deki saklama süresi olası bir incelemeyi kapsayacak uzunlukta tutulur; bu konu merkezi log saklama mimarisi yazısında ele alınır.

Kritik ve yüksek öncelikli alarmlar için yanıt adımları önceden yazılır; gece üçte düşünerek karar verilmez:

1. Değişikliği yapan hesabı ve oturum kaynağını belirleyin; değişiklik takvimi ve sorumlusuyla teyit edin.
2. Teyit edilemiyorsa hesabı devre dışı bırakın, yedek konsoluna ve hipervizör yönetimine erişimi yönetim ağından kısıtlayın.
3. Olay kayıtlarını ve ilgili yapılandırmanın mevcut halini delil olarak saklayın; nasıl yapılacağı siber olay sonrası adli delil koruma rehberinde anlatılır.
4. Saklama, değiştirilemezlik ve şifreleme ayarlarını bilinen iyi duruma döndürün ve silinen işleri yeniden oluşturun.
5. Etki alanı genelinde yanal hareket ve yetki yükseltme izlerini aramak için olay müdahale sürecini başlatın.

Kurallar canlıya alındıktan sonra iş bitmez. Test ortamında yetkili bir kişi bu olayları bilerek üretir, alarmın SIEM’e ulaştığı ve nöbetçiye iletildiği düzenli olarak doğrulanır. Test edilmemiş alarm, varsayımdır. Yedek altyapınız için tespit kurallarını ve log akışını birlikte tasarlamak isterseniz SIEM kurulumu ve güvenlik logları ile yedekleme güvenliği ve fidye yazılımına hazırlık hizmetlerimizin kapsamına bakabilirsiniz.

Teknik referans: MITRE ATT&CK T1490: Inhibit System Recovery.

Sık sorulan sorular

Yedek yazılımının kendi e-posta bildirimleri izleme için yeterli mi?

Değil. Bu bildirimler çoğunlukla iş başarısı ve hatası üzerine kuruludur; iş silme, saklama süresi değişikliği veya şifreleme ayarı değişikliği gibi yönetimsel olayları kapsamaz. Konsolu ele geçiren saldırgan bildirim ayarlarını da kapatabilir. Olayları konsol dışındaki bir SIEM’e anlık aktarın.

Gölge kopya silme olayı her zaman saldırı belirtisi midir?

Hayır. Bazı yedek ürünleri ve bakım betikleri gölge kopyaları meşru olarak yönetir. Bu nedenle kuralı, bilinen yedek süreçleri ve hizmet hesapları dışındaki çağrılara odaklayın; kural yazmadan önce birkaç haftalık geçmiş veride meşru kullanımları çıkarıp istisna listesine alın.

Değiştirilemez depo kullanıyorsak bu izlemeye yine de ihtiyaç var mı?

Var. Değiştirilemezlik yalnız mevcut geri yükleme noktalarını korur. Saldırgan yeni işleri durdurabilir, şifreleme parolasını değiştirebilir, kopya işlerini kapatabilir veya değiştirilemezlik süresini sonraki yazımlar için kısaltabilir. Bu olaylar fark edilmezse birkaç hafta içinde güncel ve kullanılabilir yedek kalmayabilir.

Yedek konsolundan gelen kritik alarmda ilk ne yapılmalı?

Nöbetçi önce değişikliği yapan hesabın ve oturum kaynağının meşru olup olmadığını doğrular. Doğrulanamıyorsa hesap devre dışı bırakılır, konsola yönetim ağından erişim kısıtlanır ve değişiklik geri alınmadan önce olay kaydı ile ekran görüntüsü delil olarak saklanır. Ardından olay müdahale süreci başlatılır.