On 18th Sep, Sucuri reported a sudden spike in the number of WordPress, Joomla and other CMS sites infected with the now infamous visitorTracker_isMob malware code. Using a malware signature published by Linux Malware Detect, we were able to secure all servers under our care from 18th onwards, but little was known about the mode of infection. 

Preventive server hardening is an important part of our web server management services. To make sure the web servers under our care was 100% secure, we needed to find out how exactly the VisitorTracker malware spread. This post is about what we found out.

How VisitorTracker malware spreads

On 21st, our technical support team got an alert that a VisitorTracker upload was attempted in a Joomla website. The alert showed the following:

/home/amogahm/public_html/media/system/js/caption.js:
{HEX}js.inject.VisitorTracker.22.UNOFFICIAL FOUND
/home/amogahm/public_html/media/system/js/core.js:
{HEX}js.inject.VisitorTracker.22.UNOFFICIAL FOUND
/home/amogahm/public_html/media/system/js/mootools-core.js:
{HEX}js.inject.VisitorTracker.22.UNOFFICIAL FOUND

Note: Account specific information such as account name and IP address are changed to protect privacy.
Since we did not know the mode of infection, two broad possibilities were considered:

1. Web application vulnerability (in this case, Joomla)
2. Stolen account logins

Before we started the investigation, the attack time stamps were taken for log analysis. A look at the file creation time of caption.js file showed:

# sudo stat /home/amogahm/public_html/media/system/js/caption.js
 File: `/home/amogahm/public_html/media/system/js/caption.js'
 Size: 800 Blocks: 8 IO Block: 4096 regular file
Device: 25h/37d Inode: 119868106 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 550/ amogahm) Gid: ( 545/ amogahm)
Access: 2015-09-21 10:23:09.000000000 -0500
Modify: 2015-09-21 10:23:09.000000000 -0500
Change: 2015-09-21 10:23:09.000000000 -0500

Which means that the file was created at 10:23 hrs server time on 21st Sep. So, our objective now was to find out logs that showed “10:23:09” in it.
First, we took a look at the Control Panel log files and saw that no files were uploaded via the FileManager. Next, we checked the FTP logs and found the following:

Sep 21 10:23:09 mysev pure-ftpd: (amogahm@203.0.113.32) [NOTICE] /home/amogahm/public_html/media/system/js/caption.js uploaded (800 bytes, 52.46KB/sec)
Sep 21 10:23:10 mysev pure-ftpd: (amogahm@203.0.113.32) [NOTICE] /home/amogahm/public_html/media/system/js/core.js uploaded (3616 bytes, 5.39KB/sec)
Sep 21 10:23:25 mysev pure-ftpd: (amogahm@203.0.113.32) [NOTICE] /home/amogahm/public_html/media/system/js/mootools-core.js uploaded (83987 bytes, 5.79KB/sec)

It was an EXACT match with the file creation time stamp. Further, the IP seemed to be webmaster’s IP itself.

So, the mode of infection seemed to be:

1. Modification of .js files stored in webmaster’s PC.
2. Possible compromise of FTP login details, which could be used to upload malware using botnets.

How to block VisitorTracker malware

Account login compromise is a popular way for malware to spread. Since the attackers use authentic login details, the only way to block such uploads is to enable upload stream scanning. To make upload time scanning fool proof, we employ multi-layered defense in which more than one method or signature database is used to detect malware.

1. Upload time scanning – ProFTPd and PureFTPd has features to call upload time scan scripts. In ProFTPd servers we use mod_clamav module, and in PureFTPd, CallUploadScript feature is used to perform ClamAV scanning on uploaded files.
2. File system modification scanning – Most web hosting control panels allow file uploads, and some websites even have features to upload files into their account. To make sure malware uploaded via the HTTP stream is caught, file modification scanning is employed on website document roots. An example of this is the Real-Time Monitoring feature of Linux Malware Detect. It uses the inotify feature of Linux kernel to trigger a malware scan when a file is created, modified or moved in the file system.
3. Multiple signature sources – It is not safe to depend on a single source of malware signature, which is why we integrate signatures from many sources to form a single database. Two reliable open source databases are Maldet and Sane Security.

Since 21st Sep, alerts from various other servers reported an increase in the number of attack attempts and this multi-layered defense system was able to block all of those upload attempts. File inclusion vulnerabilities in web applications are another major method of infection, which can be prevented using a web application firewall such as mod_security.