How to Detect Malware in a MySQL Database

How to Detect Malware in a MySQL Database | Zmanda

A malicious user can find vulnerabilities that will exploit an organization’s MySQL database. Thus, monitoring database activity should be a core practice of every business. Hackers unleash attacks designed to steal confidential data, and their primary targets are an organization’s MySQL database servers. Databases are known to be one of the most compromised assets.

Why is the database targeted so often? Simple—Database is the heart of any organization that stores customer records and other confidential business data. Organizations give the least priority when it comes to protecting these crucial assets.

Once hackers and malicious insiders gain access to sensitive data, their next step is to quickly extract value, impose damage, or impact business operations. Apart from financial loss or reputation damage, breaches also result in regulatory violations, fines, and legal fees, etc.

Let’s have a look at the case study below, where a customer lost millions of dollars due to  malicious activity on their database:

Case Study

Company name: Capital One



Capital One bank incurs one of the most significant losses of 150 million, owing to a vulnerability attack.


A software engineer and a previous employee from Capital One bank hacked into the company server, holding customer data and poached personal data of over 100 million people. Amazon Web Services hosts the customer database, and incidentally, the engineer was also previously employed with Amazon.

According to court and Capital One, the hacker stole 140,000 Social Security numbers and 80,000 bank account numbers. In addition to the tens of millions of credit card applications were also breached. The theft compromised one million Canadian social insurance numbers, which are equivalent to Social Security numbers for the Americans. The data stolen range was as early as the year 2005 and the latest being in the year 2019.

The bank provided the statement that it expected that the breach would cost it up to $150 million, including paying for credit monitoring for affected customers. The infringement was possible as there was vulnerability open in their firewall, and the hacker could easily access the hosted database in AWS.

Being a former employee at AWS, the vulnerability was exploited well to hack into the database and manipulate the customer data. Possible knowhow on how the vulnerability may have been used.

As we are aware, databases are used to store all customer and transactional data. The hacker did manipulate the DB either by adding/removing or even extracting data from the Bank Database.

If they had proper security to monitor this database, which can be done using Zmanda ZRM product, such a threat could have been detected and proactively stopped from happening. The bank has fixed the vulnerability and has now more stringent methods in place to control such frauds.

Detecting Malicious MySQL Database Activity Using Zmanda

The organizations should adopt a multi-layered database security defense strategy. With the adoption of best practices could sensibly reduce the risk for data exposure caused by various attack vectors. For instance, Zmanda can detect  malicious activities from database backups

ZRM for MySQL stores MySQL binary logs as part of the database backups. The binary logs provide a proper audit trail of all database activity. ZRM for MySQL binary uses log parsing capability for a particular point in time recovery, detecting malicious database activity using SQL inspection.

ZRM for MySQL plugin interface allows DBAs (Database Administrator) to write log parser plugin scripts to track and monitor specific/all database activity. For example, the following code can detect the deletion of data from the PRODUCTS table in the database. This script prints all instances of deleted line items from the PRODUCTS table.

@fields = split ( / \| /, $ARGV[0] );



if (($fields[3] == “Query”) && \

( $fields[4] =~ /$SQL_VERB *FROM.*`$TABLE_NAME`/ )) {

print “$fields[2] $fields[4]\n”;


The mysql-zrm command runs the customized plugin script for all backups or a specific backup image. The following command looks for deletion from PRODUCTS table on a backup image dated Dec 9, 2019.

# mysql-zrm –action parse-binlogs \

–source-directory /var/lib/mysql-zrm/pricebook/20061205142103 \

–parse-binlogs-plugin /usr/share/mysql-zrm/plugins/


The output of the command will contain valid deletions as well as malicious database deletions.

Similarly, customers can set up their own script and get it executed and verified before and after the backup as per the need and is a standout feature for ZRM for MySQL.

Below given screenshot refers to the Backup|How page in ZRM, where you can configure the plugin name, path, and execution.


The Pre and Post backup-plugin parameter should include the name and the full path to the plugin. The recommended location for plugins in “/usr/share/mysql-is database/plugins” directory.


Despite the high level of consciousness on various vulnerability threats, the number of incidents has increased over recent years. As a result of the cost incurred by the victims of these incidents has increased the operating cost to a very significant level due to increases in data breaches. To reduce the impact of these events, an organization needs to adopt proper procedures to minimize the total cost incurred due to data breach and not having an efficient monitoring and detecting tool.

Be sure to also check out the Points to Include in Your Disaster Recovery Plan

Explore More Topics