Sessiz Fidye:

TDE Suistimali Saldırısı ve Yedeklerinizi Nasıl Zehirler?

Narbulut Backup Now · Tehdit Araştırma Notu

Yedeğiniz Var, Ama Açamıyorsunuz: Yeni Nesil Bir Fidye Senaryosu

Klasik fidye yazılımları (ransomware) artık çoğumuza tanıdık geliyor: saldırgan dosyalarınızı şifreliyor, ekrana bir fidye notu bırakıyor, kripto para istiyor. Bu senaryoda yedekleme çözümünüz varsa, çoğu zaman fidyeyi ödemeden kurtulma şansınız oluyor. Peki ya yedekleriniz de saldırgan tarafından önceden zehirlenmişse?

Son yıllarda gözlemlenen ve giderek yaygınlaşan bir saldırı tipi, tam olarak bu yıkıcı senaryoyu kuruyor. Saldırgan diskinizdeki dosyaları şifrelemiyor — bunun yerine, veritabanı sunucunuzun kendi meşru şifreleme özelliklerini kendi kontrolündeki bir anahtarla devreye alıyor. Yedekleme çözümünüz aylarca “başarılı yedek alındı” raporu vermeye devam ediyor. Ta ki saldırgan ortaya çıkıp anahtarı talep edene kadar.

Bu makalede, TDE Suistimali (TDE Abuse) olarak bilinen bu saldırı türünü, tüm büyük SQL motorları üzerinde nasıl çalıştığını, neden klasik ransomware’den daha tehlikeli olduğunu ve Narbulut Backup Now’ın bu tehdide karşı geliştirdiği proaktif tespit yaklaşımını inceleyeceğiz. Ayrıca sistem yöneticilerinin kendi ortamlarında manuel kontrol yapabilmeleri için kullanabilecekleri bir SQL sorgusunu da paylaşıyoruz.

TDE Nedir, Neden Bir Saldırı Aracına Dönüşüyor?

Transparent Data Encryption (TDE), başta Microsoft SQL Server, Oracle Database, MySQL/MariaDB ve IBM Db2 olmak üzere birçok kurumsal veritabanı motorunda bulunan bir güvenlik özelliğidir. Amacı veriyi “at-rest” yani disk üzerinde şifreli tutmak; böylece veritabanı dosyaları (.mdf, .ndf, .ldf, tablespace dosyaları, vb.) fiziksel olarak çalınsa bile içeriklerinin okunamamasını sağlamaktır.

TDE çalışırken şu zincire dayanır:

• Service Master Key (sunucu seviyesinde, en üstte)
• Database Master Key (veritabanı seviyesinde)
• Sertifika veya Asimetrik Anahtar (master key tarafından korunur)
• Database Encryption Key (DEK) — gerçek veriyi şifreleyen simetrik anahtar; sertifika tarafından korunur

Bu yapı, normal şartlarda DBA’nin bilmesi ve düzenli olarak yedeklemesi gereken bir hiyerarşidir. Bir veritabanını başka bir sunucuya restore etmek istediğinizde, TDE etkinse hedef sunucuda aynı sertifikanın yüklü olması zorunludur. Sertifika yoksa, restore işlemi şu hatayla başarısız olur:

İşte saldırının temel mantığı bu hatanın üzerine kurulu.

Saldırının Anatomisi: Adım Adım Sessiz İmha

1. İlk Erişim

Saldırgan, SQL sunucusuna sysadmin (veya muadili) yetkide erişim kazanır. Yaygın vektörler:

• İnternete açık veritabanı portları (1433, 1521, 3306, 5432). Shodan üzerinde yüz binlerce açık SQL sunucusu bulunuyor.
• Zayıf veya varsayılan parolalar (sa, root, system/manager).
• SQL Injection üzerinden komut çalıştırma (xp_cmdshell, COPY FROM PROGRAM, vb.).
• Phishing veya credential dump üzerinden çalınan DBA hesapları.
• Linked server / dblink üzerinden yatay hareket.

2. Keşif

Saldırgan hemen harekete geçmez. Önce şunları haritalar:

• Mevcut yedekleme stratejisi (msdb.dbo.backupset, RMAN catalog).
• Yedek retention süresi — kaç günlük geçmiş yedek tutuluyor?
• Replikasyon ve DR topolojisi.
• Kritik veritabanlarının tespiti.

Bu bilgi, saldırının “olgunlaşma süresini” belirler.

3. Şifrelemenin Aktivasyonu

Saldırgan, kendi kontrolündeki bir sertifika üretir ve veritabanlarını bu sertifika ile şifreler. MSSQL örneği:

-- Saldırganın kendi master key'i
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'attacker_chosen_password';

-- Saldırganın kendi sertifikası
CREATE CERTIFICATE AttackerCert WITH SUBJECT = 'Legit Looking Cert';

-- Database Encryption Key oluşturma
USE [VictimDB];
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE AttackerCert;

-- TDE'yi etkinleştir
ALTER DATABASE [VictimDB] SET ENCRYPTION ON;

Aynı mantık Oracle’da Wallet ve ALTER TABLESPACE … ENCRYPTION ONLINE, MySQL’de keyring ve ALTER TABLE … ENCRYPTION=’Y’, Db2’de keystore üzerinden uygulanır.

4. Anahtarın Çalınması ve Yok Edilmesi

Saldırgan sertifikayı (.cer) ve özel anahtarı (.pvk) kendi sistemine export eder, ardından sunucudan siler. Master key parolasını da değiştirebilir. Bu noktadan sonra, veritabanları çalışmaya devam eder — çünkü SQL Server bellekte tuttuğu DEK’i kullanmaya devam eder — ama sunucu yeniden başlatıldığında veya yedekten dönülmek istendiğinde anahtar erişilemez durumdadır.

5. “Soğuk Hazırlık” — Saldırının En Sinsi Kısmı

Bu adım, saldırıyı klasik ransomware’den çok daha yıkıcı hale getirir. Akıllı saldırgan hemen fidye istemez. Şifrelemeyi etkinleştirdikten sonra 30, 60, hatta 90 gün bekler. Bu süre boyunca:

• Tüm full backup’lar zaten saldırganın anahtarıyla şifrelenmiş veriyi yedekler.
• Differential ve transaction log yedekler de aynı şekilde zehirlenir.
• Replikasyon hedefleri (Always On AG, Data Guard, vb.) ile DR site’lar senkronize edilirken zehirli veri taşınır.
• Eski “temiz” yedekler retention süresi dolduğu için silinir.

Sonuç: 90. günde saldırgan ortaya çıkıp fidye istediğinde, kurbanın elinde tek bir kullanılabilir yedek bile kalmamıştır.

6. Fidye Talebi

Saldırgan veritabanını drop eder, sunucuyu yeniden başlatır veya doğrudan fidye notu bırakır. Kurban yedekten dönmeye çalıştığında karşısına o ünlü hata çıkar:

Sertifika saldırganın elindedir. Ödeme yapılmazsa, veriye erişim matematiksel olarak imkânsızdır (AES-256 brute-force pratik değildir).

Tehdit Tüm Büyük SQL Motorlarını Kapsıyor

Şifreleme yeteneğine sahip her SQL motoru bu saldırı türüne karşı savunmasız olabilir. Başlıca veritabanı motorlarındaki saldırı yüzeyini şu şekilde özetleyebiliriz:

MITRE ATT&CK çerçevesinde bu saldırı T1486 – Data Encrypted for Impact taktiği altında değerlendirilmektedir.

Klasik Yedekleme Çözümleri Neden Yakalayamıyor?

Geleneksel yedekleme ve güvenlik ürünlerinin bu saldırıyı tespit edememesinin somut nedenleri var:

1. Backup integrity ≠ Data readability

SQL Server’ın RESTORE VERIFYONLY komutu veya yedekleme ürünlerinin doğrulama mekanizmaları checksum kontrolü yapar — yani “bu yedek bozulmamış mı?” sorusunu cevaplar. Verinin okunabilir olup olmadığını sorgulamaz. Şifreli veriyi içeren bir yedek pekala “verified” olarak işaretlenebilir.

2. Block-level şeffaflık

SQL backup’ı temelde data file’ların block-level kopyasıdır. Data file şifreliyse, backup da şifreli haliyle alınır. Yedekleme yazılımı bu farkı görmez.

3. EDR/AV görünmezliği

Saldırı sırasında kullanılan komutlar — CREATE CERTIFICATE, ALTER DATABASE SET ENCRYPTION ON — meşru SQL DDL komutlarıdır. Hiçbir kötü amaçlı yazılım imzası taşımazlar. Disk üzerinde rastgele write pattern’i oluşmaz; bu da klasik ransomware tespit yöntemlerini etkisiz kılar.

4. DLP körlüğü

Saldırganın dışarı sızdırdığı sertifika ve özel anahtar dosyaları kilobyte boyutundadır. Çoğu DLP çözümü bu kadar küçük transferlere alarm vermez.

Narbulut Backup Now’ın Yaklaşımı: Yedek Almadan Önce Kontrol

Narbulut Backup Now, bu saldırı sınıfına karşı proaktif tespit prensibiyle hareket eder. Yedekleme işlemi başlamadan önce, hedef SQL Server üzerinde veritabanlarının şifreleme durumunu sorgular ve anormal bir durum tespit ederse kullanıcıyı uyarır.

Bu yaklaşımın anlamı şudur: Eğer bir saldırgan ortamınıza sızmış ve veritabanlarınızı kendi sertifikası ile TDE altına almışsa, Narbulut Backup Now bu durumu ilk yedekleme denemesinde fark eder. Yedek alınır ama sistem yöneticisine “Bu veritabanı şifrelenmiş durumda — durum sizin tarafınızdan beklenen bir konfigürasyon mu?” şeklinde bir uyarı gönderilir.

Bu basit ama kritik kontrol, saldırının soğuk hazırlık fazını kırar. Saldırganın 90 gün boyunca sessizce yedekleri zehirlemesi mümkün olmaz. Çünkü etkinleştirilen TDE, ilk yedekleme döngüsünde alarm üretir.

SQL Server’da Şifreleme Durumunu Manuel Sorgulama

Narbulut Backup Now bu kontrolü otomatik yapıyor olsa da, sistem yöneticilerinin kendi ortamlarında anlık doğrulama yapabilmesi için kullanılabilecek SQL sorgusu aşağıdadır. Bu sorguyu SSMS veya sqlcmd üzerinden, sysadmin yetkili bir hesapla çalıştırabilirsiniz:

SELECT
  db.name AS [Veritabanı Adı],
  db.is_encrypted AS [TDE İşaretli mi? (1=Evet)],
  CASE dek.encryption_state
    WHEN 0 THEN 'Anahtar Yok / Şifreleme Yok'
    WHEN 1 THEN 'Şifrelenmemiş'
    WHEN 2 THEN 'Şifreleme Devam Ediyor'
    WHEN 3 THEN 'Şifrelenmiş (Aktif)'
    WHEN 4 THEN 'Anahtar Değişimi Devam Ediyor'
    WHEN 5 THEN 'Şifre Çözme Devam Ediyor'
    WHEN 6 THEN 'Koruma Değişikliği Yapılıyor'
    ELSE 'Bilinmiyor'
  END AS [Detaylı Durum],
  dek.percent_complete AS [İşlem Tamamlanma Yüzdesi]
FROM sys.databases db
LEFT JOIN sys.dm_database_encryption_keys dek
  ON db.database_id = dek.database_id;

Sorgu Çıktısı Nasıl Yorumlanmalı?

• is_encrypted = 0 ve encryption_state = NULL → Veritabanında TDE etkin değil. Beklenen normal durum (eğer TDE planlamadıysanız).
• is_encrypted = 1 ve encryption_state = 3 → Veritabanı aktif olarak şifreli. Bu sizin tarafınızdan kasıtlı yapılmış bir konfigürasyon mu? Cevabınız hayırsa, acil olarak inceleme yapın.
• encryption_state = 2 → Şifreleme şu anda devam ediyor. Eğer böyle bir işlemi siz başlatmadıysanız, saldırı muhtemelen şu anda gerçekleşmektedir. Sunucuyu derhal izole edin.
• encryption_state = 4 veya 6 → Anahtar veya koruma değişikliği yapılıyor. Yine, kasıtlı bir bakım dışında bu durum şüphelidir.

Anormal Bir Durum Tespit Ettiyseniz Ne Yapmalısınız?

• Sunucuyu hemen izole edin — ağ bağlantısını kesin, ama servisi durdurmayın (bellekteki DEK’i kaybetmemek için).
• Bellekten DEK çıkarımı için forensic ekibi devreye alın — bazı durumlarda DEK hâlâ bellekte olabilir.
• Sertifikayı master key’le birlikte yedekleyin (eğer hâlâ erişiminiz varsa):

BACKUP MASTER KEY TO FILE = 'C:\Backup\master_key.snk'
ENCRYPTION BY PASSWORD = 'StrongPassword123!';

BACKUP CERTIFICATE [SertifikaAdı]
TO FILE = 'C:\Backup\cert.cer'
WITH PRIVATE KEY (
  FILE = 'C:\Backup\cert.pvk',
  ENCRYPTION BY PASSWORD = 'StrongPassword123!'
);

• En eski yedeklerinizi inceleyin — TDE’nin etkinleştirilmediği bir nokta varsa, point-in-time recovery şansınız olabilir.
• Audit loglarını koruyun — sys.fn_get_audit_file(), Extended Events ve Windows Security Log üzerinden saldırının zaman çizelgesini çıkarın.
• Resmi makamlara bildirim yapın — KVKK kapsamında veri ihlali bildirimi gerekebilir.

Korunma İçin Önerilen Best Practice’ler

Bu saldırı sınıfından korunmak için katmanlı bir yaklaşım gereklidir.

Anahtar yönetimi merkezi olsun

TDE kullanıyorsanız, sertifika ve master key’leri local sunucuda değil; HSM (Hardware Security Module) veya kurumsal Key Management çözümlerinde (Thales CipherTrust, Azure Key Vault, AWS KMS) tutun. Bu durumda saldırgan sysadmin olsa bile yeni anahtar üretemez veya export edemez.

Şifreleme aktivasyonu için audit + alarm kurun

SQL Server Audit veya Extended Events ile CREATE CERTIFICATE, CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE … SET ENCRYPTION ON komutlarını izleyin. Normal şartlarda bu komutlar yılda birkaç kez çalışır; her çalıştığında SOC ekibinize alarm gitsin.

Restore drill yapın

Quarterly olarak izole bir ortama tam restore yapın ve business-critical tabloların okunabilir veri içerdiğini doğrulayın. Sadece “restore başarılı” mesajına güvenmek yetmez.

Privileged access yönetimi

SQL sysadmin yetkisi günlük operasyonel hesaplarda olmamalı. Just-in-time access (CyberArk, Azure PIM) ve MFA korumalı bastion host kullanın.

Yedekleme çözümünüzün şifreleme tespit yeteneğini kullanın

Narbulut Backup Now’ın TDE durumu kontrolü gibi proaktif özellikler, saldırı tespitini yedekleme süreciyle entegre eder. Bu, ayrı bir izleme katmanına ihtiyaç duymadan ek bir savunma hattı sağlar.

Sonuç

TDE Suistimali saldırısı, güvenlik dünyasının “yedeğim varsa güvendeyim” varsayımını sarsan nadir tehditlerden biridir. Saldırgan dosyalarınızı şifrelemez, yedeklerinizi silmez, hatta sisteminizde herhangi bir alarm üretmeyebilir. Sadece, sizin meşru şifreleme aracınızı kendi anahtarıyla devreye alır ve sabırla bekler.

Bu tehdide karşı en etkili savunma, şifreleme durumunu sürekli izlemek ve yedekleme sürecinin parçası haline getirmektir. Narbulut Backup Now’ın yedek almadan önce yaptığı TDE kontrolü, tam olarak bu prensiple geliştirilmiştir. Ayrıca yukarıda paylaştığımız SQL sorgusunu kullanarak siz de kendi ortamınızda anlık doğrulama yapabilir, anormal bir durumu erken aşamada tespit edebilirsiniz.

Modern bir yedekleme stratejisi yalnızca veriyi kopyalamakla kalmaz; kopyaladığı verinin gerçekten kullanılabilir olduğundan da emin olur. Bu farkındalık, yarının fidye senaryolarına bugünden hazırlıklı olmanın anahtarıdır.