.dlock / .Darkness Ransomware Decryption Guide

.dlock / .Darkness Ransomware Decryption Guide

Early September, a freight company in Kwai Chung found their SQL Server unreachable in the morning — every database file (.mdf, .ldf) renamed with a .dlock extension, backup files (.bak) included. Their entire shipping system ground to a halt, dozens of trucks waiting at the warehouse gate, drivers shouting. The boss called us: "That database is our lifeline!"

The culprit was .dlock, whose twin .Darkness specialises in database and server attacks. Here's what makes these twins tick.

.dlock vs .Darkness: telling them apart

• .dlock: The "d" likely stands for database. It specifically hunts SQL Server and MySQL files (.mdf, .ldf, .bak, .sql) — and stops the SQL service first so files aren't locked. Thoroughly nasty.
• .Darkness: Lives up to the name — turns the Windows desktop pitch black with a single line of white ransom text. Broader targeting; doesn't spare ordinary files either.
• Common ground: Both enter via RDP or unpatched VPN, both use AES-256, both leave ransom notes called HOW_TO_RECOVER.txt (a name many families share — check the contact email inside to distinguish).

Some victims see .dlock, others .Darkness, some both (different machines, different variants). Don't agonise — handling is identical.

Why target databases?

These twins have a clever (evil) strategy: databases are where SMEs hurt most.

Think: lost Office documents can be recreated; but databases — client records, order history, inventory, finances — losing them is corporate amnesia. The Kwai Chung freight company had tens of thousands of delivery addresses and open orders in SQL. Without it, drivers didn't know where to go.

Their attack playbook:

1. Enter via RDP/VPN, lurk 1–2 days mapping the network's servers
2. Find SQL Server, then run net stop MSSQLSERVER to unlock the .mdf files
3. Rapidly encrypt all database + backup files (.bak included)
4. Spread to other machines, encrypt ordinary files
5. Drop the ransom note, typically demanding 0.3–1 BTC

The whole thing can take under an hour. By morning, it's too late.

Database encrypted: special rescue routes

Databases differ from ordinary files — with unique rescue options:

• Transaction logs: SQL Server .ldf files record every transaction. If the .ldf isn't fully encrypted, or there's off-site log shipping, partial reconstruction is possible. In Kwai Chung we found an old log backup on another machine and recovered some transactions.
• Application-level exports: Many ERP/logistics apps auto-export (e.g. daily CSV exports). If these live elsewhere, they may have escaped. The freight company's logistics software exported Excel to the manager's PC daily — that PC was clean, saving the previous day's complete data.
• Identify first: Run ID Ransomware and No More Ransom before anything else.
• Cloud databases: Azure SQL or RDS offer point-in-time restore — one click to roll back. That's the cloud's biggest advantage.

Real case: Kwai Chung freight's "rustic Excel" workaround

SQL database wiped out, .bak files all .dlock. Dozens of trucks waiting — extremely urgent.

We did several things:

1. Found yesterday's Excel export: The manager's PC had the logistics software's daily auto-export with all open orders. One day behind, but complete.
2. Built an instant temp system: In half a day we set up a shared Google Sheet; warehouse staff updated shipment status manually. Rustic, but it worked.
3. Rebuilt SQL: Three days re-entering Excel data into a new SQL Server (upgraded to the latest version while at it). Driver addresses matched against paper waybills.
4. Hardened: RDP closed, VPN + 2FA instead; SQL backups set to daily Azure Blob (immutable); sa account disabled, least-privilege accounts created.

Four days total, HK$18,000. The boss said: "Four days without a system cost more in lost business than that. Lucky we recovered." Now every Friday we automatically receive their backup-success notification — a monitoring mechanism we set up for them.

Prevention: databases are lifelines — protect them like it

1. 3-2-1 backup — .bak must leave the machine: Daily .bak to off-site (cloud or another box). The classic mistake is keeping backups on the same server — one encryption takes all.
2. Least-privilege SQL accounts: Don't run daily operations as sa. Create dedicated accounts with only needed permissions.
3. Harden RDP/VPN: Never expose SQL port (1433) to the internet. VPN in, with 2FA.
4. Test restores regularly: Monthly, restore a .bak to a test machine and verify it works. One client backed up for three years without ever restoring — the .bak turned out corrupt.
5. Consider cloud databases: Azure SQL Database and AWS RDS offer automatic point-in-time restore — one click rolls back minutes. Long-term it's often cheaper than maintaining your own server.

FAQ

1. Q: Are .dlock and .Darkness the same?

A: Similar core, different focus. .dlock specifically loves database files and stops SQL services first; .Darkness is broader. Handled the same way.

2. Q: My encrypted .mdf won't attach. Now what?

A: Don't try attaching — it wastes time. Look for backups (.bak off-site), transaction logs, or application-level exports. If none exist, plan a rebuild.

3. Q: Why not just pay for the decryptor?

A: Extra database risk — even with a decryptor, the decrypted database may be corrupt (especially large .mdf files). We've seen clients pay, decrypt, and still end up relying on backups. Payment isn't a magic fix.

4. Q: Are cloud databases really safer?

A: Not "can't be hit" but "easier to recover from". Point-in-time restore rolls back minutes — hard for on-premises SQL to match. Of course, cloud permissions must be configured properly too.

Summary

.dlock/.Darkness target databases because they know it's where SMEs hurt most. Golden rules for database protection: off-site backups, least privilege, never expose to the internet. If hit, don't panic — check for application exports, cloud versions and transaction logs first.

Database emergency? WhatsApp +852 6558 6806 immediately — we have SQL recovery experience. For prevention, see our ransomware protection guide.