An Introduction to Maldet and ClamAV Malware Scanning

6 min read

If you have a developer account with GridPane, then you can get access to our integrated malware scanning solution: Maldet + ClamAV.


Maldet is short for Linux Malware Detect. This is a software package that scans for malware on Linux systems and has been designed with hosting environments in mind. It’s been created to address threats in a shared hosting environment which, for our purposes, is vastly superior to regular anti-virus solutions that typically have a poor track record of detecting malware on the user account level.
For more information see:


ClamAV® is an open source (GPL) anti-virus engine used in a variety of situations including email scanning, web scanning, and end point security. It provides a number of utilities including a flexible and scalable multi-threaded daemon, a command line scanner and an advanced tool for automatic database updates.

Maldet and ClamAV work by scanning your servers looking for signatures of thousands of instances of known malware, and then logging the results. It’s important to note that these are not malware cleaners and you will need to take care of any malware found. If malware is found on your server, please check out this guide and take action ASAP – ideally immediately:

Moving a Website that’s had a Malware Infection

We’ve configured Maldet and ClamAV to work together to do thorough scans of your WordPress websites and deliver the results directly in your GridPane dashboard.


If you have a developer account and would like to use this tool suite, contact support, and information will be provided on how to install and use the suite.

Malware Scanning Server Logs

As well as giving notifications inside your account, all scan results are logged, and you can view these directly inside your server.

If Maldet finds an infection on the server, there will be a record in Maldet log files. This record will have both the website and location of the infection.

The Maldet scan report file is found here:


While the more detailed log file is found here:​


You can also view general scan data with the following:

cat /usr/local/maldetect/logs/event_log

Viewing Your Logs

If you’ve received a notification that malware has been scanned, you can view your logs directly inside your server as detailed below.

Step 1. SSH into your server

Please see the following guides to get started:

Step 2. Open the report log

There’s a couple of ways you can view your scan data. One is to view an overview of the scan reports as follows:

cat /opt/gridpane/maldet-all-sites-report.ids

Here you will a list of all report data that looks like this:

Dec 01 04:18:13 server-name-here maldet(8501): {scan} scan report saved, to view run: maldet --report 201201-0402.8501
Dec 02 04:18:01 server-name-here maldet(23409): {scan} scan report saved, to view run: maldet --report 201202-0402.23409
Dec 03 04:17:11 server-name-here maldet(20418): {scan} scan report saved, to view run: maldet --report 201203-0402.20418
Dec 04 04:17:16 server-name-here maldet(22121): {scan} scan report saved, to view run: maldet --report 201204-0402.22121
Dec 05 04:16:57 server-name-here maldet(30020): {scan} scan report saved, to view run: maldet --report 201205-0402.30020

At the end of each line the log gives you the command to run view that scans data. In the example above, this would be as follows:

maldet --report 201205-0402.30020

Alternatively, you can view ALL scan data with he following command (Side note – PuTTY doesn’t handle displaying large amounts of data like this very well):

cat /opt/gridpane/maldet-all-sites-scan.log

Step 3. Assess the Report

If malware has been detected, your report will look something like this:

HOST: server-name-here
SCAN ID: 201204-0324.8335
STARTED: Dec 5 2020 04:06:59 +0000
COMPLETED: Dec 5 2020 04:17:54 +0000
ELAPSED: 5155s [find: 16s]

RANGE: 1 days

WARNING: Automatic quarantine is currently disabled, detected threats are still accessible to users!
To enable, set quarantine_hits=1 and/or to quarantine hits from this scan run:
/usr/local/sbin/maldet -q 201204-0324.8335

{HEX}php.gzbase64.inject.452 : /var/www/
{HEX}php.gzbase64.inject.452 : /home/system-user-name/sites/$
Linux Malware Detect v1.6.4 < >

Here we can see that it’s flagged two specific files.

How you proceed from this point onwards will depend on the type of infection, but typically it’s always best to consult a professional who specializes in malware cleanup (Thomas Raef from is an excellent choice, and he regularly contributes in the Facebook group and has written for us here in the KB) so that you can assess where the breach came from and prevent it from happening again in the future.

As noted in the introduction, please also check out the following guide:

Moving a Website that’s had a Malware Infection

6G and 7G WAF Logs False Positives

Maldet may sometimes incorrectly flag the 6g.log or 7g.log as malware. For example:

{YARA}eval_post : /home/sytem-user-name/sites/
{YARA}eval_post : /var/www/

Log Exclusions

Maldet does have some ability to ignore certain file types or directories, and if you’re getting false positives from your logs you can take measures to exclude them.

Unfortunately, these are not granular enough for us to be comfortable excluding them by default.

There are two options, one is to set them to ignore all .log files, and the other is to have it ignore the /logs directory in the site directory.

Since the log directory is in the userspace we are not comfortable defaulting to having the malware scanning avoid this directory as the PHP user has access to it and if a vulnerable plugin was compromised then this would be a directory where compromised files could reside.

However, if you would like to exclude the log directory locations, you can do so by following the 2 steps below.

Step 1. SSH into your Server

Please see the guides listed above to get started.

Step 2. Add the exclusion

Run the following command to open up the file we need to edit:

nano /usr/local/maldetect/ignore_paths

Next, add the following two lines to the file:


Finally, save the file with CTRL+O and then Enter, and then exit nano with CTRL+X.

Your exclusion is now in place.

Troubleshooting: Cron customizations are being overwritten

We’ve had a report of custom cronjobs being overwritten.

This is rare, but sometimes cron customizations can be wiped out. If we update cron, or if cron is empty, we have healer workers that will rebuild all of our configurations, but these won’t add back customizations.

Here you could add a check to the script to check crontab, and also build in a check to it as well.

The way this works is will send you a notification if it hasn’t heard from the script in a certain amount of time. When you get notified, you can connect to your server and run the script manually, and it will add itself back to cron.