Silent Ransom:

TDE Abuse Attack and How It Poisons Your Backups?

Narbulut Backup Now · Threat Research Note

You Have Backups, But You Can’t Open Them: A Next-Generation Ransom Scenario

Traditional ransomware is something most of us are familiar with by now: the attacker encrypts your files, leaves a ransom note on screen, and demands cryptocurrency. If you have a backup solution in place, you often have a chance to recover without paying the ransom. But what if your backups had already been poisoned by the attacker beforehand?

An attack type that has been observed in recent years and is becoming increasingly prevalent sets up exactly this devastating scenario. The attacker does not encrypt the files on your disk — instead, they activate your database server’s own legitimate encryption features using a key under their control. Your backup solution continues to report “backup completed successfully” for months. Until the attacker finally emerges and demands the key.

In this article, we will examine this attack type known as TDE Abuse, how it works across all major SQL engines, why it is more dangerous than traditional ransomware, and the proactive detection approach that Narbulut Backup Now has developed against this threat. We will also share a SQL query that system administrators can use to perform manual checks in their own environments.

What Is TDE, and Why Is It Becoming an Attack Vector?

Transparent Data Encryption (TDE) is a security feature found in many enterprise database engines, primarily Microsoft SQL Server, Oracle Database, MySQL/MariaDB, and IBM Db2. Its purpose is to keep data encrypted “at-rest” on disk, so that even if database files (.mdf, .ndf, .ldf, tablespace files, etc.) are physically stolen, their contents cannot be read.

When TDE is active, it relies on the following chain:

• Service Master Key (at the server level, at the top)
• Database Master Key (at the database level)
• Certificate or Asymmetric Key (protected by the master key)
• Database Encryption Key (DEK) — the symmetric key that actually encrypts the data; protected by the certificate

This structure is a hierarchy that the DBA should be aware of and regularly back up under normal circumstances. When you want to restore a database to another server, if TDE is enabled, the same certificate must be installed on the target server. If the certificate is missing, the restore operation fails with the following error:

The fundamental logic of the attack is built upon this very error.

Anatomy of the Attack: Step-by-Step Silent Destruction

1. Initial Access

The attacker gains sysadmin-level (or equivalent) access to the SQL server. Common vectors include:

• Internet-exposed database ports (1433, 1521, 3306, 5432). Hundreds of thousands of open SQL servers can be found on Shodan.
• Weak or default passwords (sa, root, system/manager).
• Command execution via SQL Injection (xp_cmdshell, COPY FROM PROGRAM, etc.).
• Stolen DBA credentials through phishing or credential dumps.
• Lateral movement via linked servers / dblinks.

2. Reconnaissance

The attacker does not act immediately. First, they map the following:

• Existing backup strategy (msdb.dbo.backupset, RMAN catalog).
• Backup retention period — how many days of historical backups are kept?
• Replication and DR topology.
• Identification of critical databases.

This information determines the “maturation period” of the attack.

3. Encryption Activation

The attacker generates a certificate under their control and encrypts the databases with this certificate. MSSQL example:

-- Attacker's own master key
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'attacker_chosen_password';

-- Attacker's own certificate
CREATE CERTIFICATE AttackerCert WITH SUBJECT = 'Legit Looking Cert';

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

-- Enable TDE
ALTER DATABASE [VictimDB] SET ENCRYPTION ON;

The same logic applies via Wallet and ALTER TABLESPACE … ENCRYPTION ONLINE in Oracle, keyring and ALTER TABLE … ENCRYPTION=’Y’ in MySQL, and keystore in Db2.

4. Key Theft and Destruction

The attacker exports the certificate (.cer) and private key (.pvk) to their own system, then deletes them from the server. They may also change the master key password. From this point on, the databases continue to operate — because SQL Server continues to use the DEK held in memory — but when the server is restarted or a restore from backup is attempted, the key is no longer accessible.

5. “Cold Preparation” — The Most Insidious Part of the Attack

This step makes the attack far more devastating than traditional ransomware. A smart attacker does not demand a ransom immediately. After activating encryption, they wait 30, 60, or even 90 days. During this period:

• All full backups already back up data encrypted with the attacker’s key.
• Differential and transaction log backups are poisoned in the same way.
• Replication targets (Always On AG, Data Guard, etc.) carry poisoned data as DR sites are synchronized.
• Old “clean” backups are deleted as their retention period expires.

Result: By day 90, when the attacker emerges and demands a ransom, the victim has not a single usable backup left.

6. Ransom Demand

The attacker drops the database, restarts the server, or directly leaves a ransom note. When the victim tries to restore from backup, they encounter that infamous error:

The certificate is in the attacker’s hands. If payment is not made, access to the data is mathematically impossible (AES-256 brute-force is not practical).

The Threat Covers All Major SQL Engines

Every SQL engine with encryption capabilities can be vulnerable to this type of attack. We can summarize the attack surface across major database engines as follows:

Within the MITRE ATT&CK framework, this attack is classified under the T1486 – Data Encrypted for Impact tactic.

Why Traditional Backup Solutions Can’t Catch It?

There are concrete reasons why traditional backup and security products fail to detect this attack:

1. Backup integrity ≠ Data readability

SQL Server’s RESTORE VERIFYONLY command or backup products’ verification mechanisms perform checksum checks — answering the question “is this backup corrupted?” They do not check whether the data is actually readable. A backup containing encrypted data can perfectly well be marked as “verified.”

2. Block-level transparency

A SQL backup is essentially a block-level copy of data files. If the data file is encrypted, the backup is taken in its encrypted form. The backup software doesn’t see the difference.

3. EDR/AV invisibility

The commands used during the attack — CREATE CERTIFICATE, ALTER DATABASE SET ENCRYPTION ON — are legitimate SQL DDL commands. They carry no malware signatures. No random write patterns are created on disk, rendering traditional ransomware detection methods ineffective.

4. DLP blindness

The certificate and private key files exfiltrated by the attacker are only kilobytes in size. Most DLP solutions do not raise alerts for transfers this small.

Narbulut Backup Now’s Approach: Check Before Backing Up

Narbulut Backup Now operates on the principle of proactive detection against this class of attack. Before the backup process begins, it queries the encryption status of databases on the target SQL Server and alerts the user if an anomaly is detected.

What this approach means is: If an attacker has infiltrated your environment and placed your databases under TDE with their own certificate, Narbulut Backup Now detects this situation on the first backup attempt. The backup is taken, but the system administrator receives an alert saying “This database is in an encrypted state — is this an expected configuration on your end?”

This simple but critical check breaks the cold preparation phase of the attack. The attacker cannot silently poison backups for 90 days. Because the activated TDE generates an alarm on the first backup cycle.

Manually Querying Encryption Status in SQL Server

Although Narbulut Backup Now performs this check automatically, system administrators can use the following SQL query for instant verification in their own environments. You can run this query via SSMS or sqlcmd with a sysadmin-privileged account:

SELECT
  db.name AS [Database Name],
  db.is_encrypted AS [TDE Marked? (1=Yes)],
  CASE dek.encryption_state
    WHEN 0 THEN 'No Key / No Encryption'
    WHEN 1 THEN 'Unencrypted'
    WHEN 2 THEN 'Encryption In Progress'
    WHEN 3 THEN 'Encrypted (Active)'
    WHEN 4 THEN 'Key Rotation In Progress'
    WHEN 5 THEN 'Decryption In Progress'
    WHEN 6 THEN 'Protection Change In Progress'
    ELSE 'Unknown'
  END AS [Detailed Status],
  dek.percent_complete AS [Operation Completion Percentage]
FROM sys.databases db
LEFT JOIN sys.dm_database_encryption_keys dek
  ON db.database_id = dek.database_id;

How to Interpret the Query Output?

• is_encrypted = 0 and encryption_state = NULL → TDE is not enabled on the database. This is the expected normal state (if you have not planned TDE).
• is_encrypted = 1 and encryption_state = 3 → The database is actively encrypted. Was this a deliberate configuration on your part? If not, investigate immediately.
• encryption_state = 2 → Encryption is currently in progress. If you did not initiate such an operation, the attack is likely happening right now. Isolate the server immediately.
• encryption_state = 4 or 6 → A key or protection change is in progress. Unless this is a planned maintenance operation, this state is suspicious.

What Should You Do If You Detect an Anomaly?

• Isolate the server immediately — disconnect the network, but do not stop the service (to avoid losing the DEK in memory).
• Engage a forensic team for DEK extraction from memory — in some cases, the DEK may still be in memory.
• Back up the certificate along with the master key (if you still have access):

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

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

• Review your oldest backups — if there is a point before TDE was activated, you may have a chance for point-in-time recovery.
• Preserve audit logs — extract the attack timeline through sys.fn_get_audit_file(), Extended Events, and Windows Security Log.
• Report to authorities — a data breach notification may be required under GDPR or applicable data protection regulations.

Recommended Best Practices for Protection

A layered approach is required to protect against this class of attack.

Centralize key management

If you use TDE, store certificates and master keys not on the local server but in HSM (Hardware Security Module) or enterprise Key Management solutions (Thales CipherTrust, Azure Key Vault, AWS KMS). In this case, even if the attacker gains sysadmin access, they cannot generate or export new keys.

Set up audit + alerting for encryption activation

Monitor CREATE CERTIFICATE, CREATE DATABASE ENCRYPTION KEY, and ALTER DATABASE … SET ENCRYPTION ON commands with SQL Server Audit or Extended Events. Under normal circumstances, these commands run only a few times a year; each execution should trigger an alert to your SOC team.

Conduct restore drills

Perform a full restore to an isolated environment quarterly and verify that business-critical tables contain readable data. Relying solely on the “restore successful” message is not enough.

Privileged access management

SQL sysadmin privileges should not be on daily operational accounts. Use just-in-time access (CyberArk, Azure PIM) and MFA-protected bastion hosts.

Leverage your backup solution’s encryption detection capability

Proactive features like Narbulut Backup Now’s TDE status check integrate attack detection with the backup process. This provides an additional line of defense without requiring a separate monitoring layer.

Conclusion

The TDE Abuse attack is one of the rare threats that shatters the security world’s assumption of “I’m safe if I have backups.” The attacker doesn’t encrypt your files, doesn’t delete your backups, and may not even trigger any alert on your system. They simply activate your own legitimate encryption tool with their own key and patiently wait.

The most effective defense against this threat is to continuously monitor encryption status and make it part of the backup process. The TDE check that Narbulut Backup Now performs before taking backups was developed with exactly this principle. Additionally, you can use the SQL query shared above to perform instant verification in your own environment and detect an anomaly at an early stage.

A modern backup strategy does not merely copy data; it also ensures that the copied data is actually usable. This awareness is the key to being prepared today for tomorrow’s ransom scenarios.