I have an application server accessible from the Web, behind a reverse proxy. Its database is secured on a separate VLAN and the database admin password is strong.

Say the application or the operating system has a vulnerability and an attacker performs an exploit and gains application rights.

I assume he can them send SQL requests to delete database data, possibly full tables at once, depending on how the database has been protected [1, 2, 3]. For notes, some detection ideas are presented here.

But can he encrypt / cryptolock the database content?

A first way would be to read data, encrypt it and write it back. But then to encrypt a complete database, it may takes time. Can he encrypt the database content efficiently? How to prevent it?

  • 2
    Attackers don't need to be efficient, they just need to get done before somebody notices. If you want to make things less efficient I guess you could rate limit queries, but that would also impact your legitimate applications. Personally I think a more effective strategy would be to have incremental backups (provided that is financially viable).
    – user
    Commented Aug 26, 2022 at 18:32
  • Why are you specifically worried about cryptolocking, when he could also delete the entire database? Commented Aug 26, 2022 at 22:03
  • Attackers prefer monetize their efforts. Deleting is less likely
    – lalebarde
    Commented Aug 28, 2022 at 7:32

2 Answers 2


But can he encrypt / cryptolock the database content?

Depends on the permission scope your application server has.
If your application can update entries, then the attacker could simply update the entries to contain the encrypted version of the data.
If your application server has administrative privileges over the DB, then it can apply encryption at rest with a specific key that is controlled by the attacker and then remove the DB server access to the key, post storage encryption.

How to prevent it?

My protection strategy would be the following:

  1. Limit your application to necessary operations only:
    1.1. Narrowing down the scope of Update operations:
    1.1.1. Can the application utilize the event-sourcing design pattern?
    in this approach, rewriting of entries is not allowed, so the attacker would only be able to append polluted data, but not to override existing data (unless table size has reached and is being rotated). This pattern introduces other challenges, but they are well described in the above link, including approaches of solutions.
    1.2. Narrowing down the scope of Delete operations:
    Can the application live without delete operations? or perhaps to externalize the delete operations to a "back office-ish" applet with a lesser attack surface that handles data cleanup and erasures.
    1.3. Usage of prepared statements only to limit the blast radius of queries.
  2. Incremental immutable backups:
    As @user mentioned in the comments, incremental backups that are non-rewriteable would save you a lot of time if your database has been compromised. If you can ensure you back up frequently in an immutable manner, then you would be able to revert to your most recent backup.
    For example, append-only backup to a remote storage medium (e.g., private S3 bucket).
  3. Security monitoring of app-specific abnormal activity:
    For instance, a checksum that is calculated with pepper in addition to the entry records can be added for sensitive tables and can be monitored for discrepencies.
    Another example can be to track the standard rate of update calls and monitor for anomalies.
    This will add tailored means of detecting such activities in addition to app-agnostic ones (e.g., Yara rules, anti-virus, EDR, etc)

If an attacker can access the DB then yes they could potentially 'crypto lock' it. As you mentioned, the easiest way to do this is to read the data then update it. This is technically not hard to do or even automate it so it could probably be done pretty fast even on a large DB.

There's no magic way to prevent this but you can use the simple well known methods: Follow the least privilege rule, create regular offline backups and use an AV or IDS to detect unusual activity.

  • 1
    Not AV, but rather IDS/IPS ;) Commented Aug 28, 2022 at 12:45
  • 1
    Fixed with my edit Commented Aug 28, 2022 at 14:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .