The rise of ‘no malware’ attacks and ransomware

BLUF: Database ransomware, which relies on native database commands rather than traditional malware to wipe data from exposed servers, represents a persistent and automated extortion threat to organisations.

This form of ‘malware-less’ attack operates by exploiting misconfigured, Internet-facing database services. Targets include MongoDB and PostgreSQL. Attackers authenticate using weak or non-existent credentials before remotely connecting to the server. Once inside, they steal data and then use legitimate, destructive database queries (such as DROP DATABASE or bulk DELETE commands) to erase the data. They then insert a ransom note into a new table or document.

This produces the effect of denial of service, but without dropping a detectable binary. Because the attacks use authorised operations within normal protocols, they can bypass conventional host-based security defences.

The result is not only data loss and double extortion attempts but also a significant risk of lateral movement and privilege escalation for Remote Code Execution (RCE) in the wider environment.

Action Points

  • Network segmentation: Isolate database servers by placing them in private network segments, protected by strict firewalls and security groups that only permit access from trusted application servers.
  • Secure remote access: Do not expose database ports directly to the Internet; instead, route remote administrative access through a secure jump server protected by multi-factor authentication (MFA).
  • Enforce strong authentication: Disable password-less access and mandate the use of unique, strong credentials for all database accounts.
  • Backup and recovery: Implement a robust strategy of regular, automated backups for all critical data. Store these backups in a separate, access-controlled location, and routinely test the data recovery process.
  • Continuous attack surface mapping: Proactively scan the environment to map the effective attack surface, continuously identifying and correcting exposed database instances and mis-configurations.
  • Monitor for IOCs: Establish monitoring for Indicators of Compromise (IOCs), such as the creation of new tables or documents named similarly to ransom notes (e.g., README_TO_RECOVER).

Read more here (vendor article).