Since the beginning of November, I’ve been working on a number of websites (271) that all redirect to various sites, such as:

Automated Malware Remediation

As I started digging through the WordPress with my automated processes looking for WordPress malware, I discovered that on many of the sites, there were no infected files with “known” malware. I had to wait for my Anomaly Detection and Behavior Analysis engines to complete their tasks.

 

Yes!

 

As I suspected, the infections were in the MySQL database. In one case, 8,616 infections in the database.

 

Every post, even the drafts had a line of code added:

 

Usually, it was multiple times, one immediately following the other. As I’m writing this, Google does not flag that site as unsafe:

 

After removing that code from the database and verifying the site did not redirect, it was time to unleash my Root Cause Determiner (RCD).

 

Root Cause Analysis for WordPress Malware

This part of my service analyzes the log files (if available), the date/time stamps of the original files, the database and various other aspects to determine with reasonable certainty, the root cause of the infection. The point of entry (POE). How this site was infected.

 

None of the usual POE’s existed in the logs. RCD looks for things like successful logins from suspicious IP addresses, POSTs to files that shouldn’t exist or from suspicious IP addresses. RCD uses over 1,000 different rules to determine the root cause.

 

When RCD was finished it was determined that on October 14, 2019, the hackers were scanning sites looking for adminer.php – and they found it. This group of sites, with no WordPress malware in the files, but only in the database, were recently moved to a private server. The person moving the sites used adminer.php to migrate the databases over – and then left it there.

 

However, it wasn’t until November 2, 2019, the hackers actually started testing and using it:

 

The script/scanner used by the hackers looked for adminer.php in various folders:

 

• /
• /test
• /dev
• /sql
• /php
• /scripts

 

And it looked for variations of the spelling too:

 

• adminer.php
• oc_adminer.php
• ~adminer.php
• phpadminer.php
• padminer.php
• _adminer.php
• mysql-adminer.php

 

Malware found in WordPress files

In other websites, my systems found the code in both PHP files, like index.php, functions.php, header.php and footer.php for all the themes in the wp-content/themes folders and it was also found in almost all of the .js files throughout the WordPress site. (There are many, many .js files on a WordPress site!)

 

My RCD system would create messages like this:

 

This file was recently edited: “/home/[redacted]/public_html/wp-content/themes/[redacted]/functions.php by user: wp-admin with email of: testing@gmail.com logged in from IP: xxx.xxx.xxx.xxx”

 

The code at that URL was this:

 

It might be recognized by the String.fromCharCode(… as very familiar with other recent redirect code normally found in the database of WordPress malware infected websites.

 

In a few sites, a file named: scripts.trasnaltemyrecords.com-pixel.js was found in the caching system. It had code similar to this:

 

The URL would change from time to time and from site to site, but the structure was the same.

 

In every case I worked on, each one had adminer.php. Every. One. Of. Them. All 271.

 

Please be certain to tell your developer or server manager to remove unnecessary files after a migration, move or other maintenance type work. In my investigation, I found thousands of websites infected with this same malware. Each one had adminer.php publicly available.

 

So, with this type of WordPress malware infection, how did my systems find it?

 

My Behavior Analysis engine looks for a variety of things in a database. Keep in mind that years and years of experience went into my design of the Behavior Analysis engine (BAe). Currently, it focuses on WordPress, Joomla and Magento platforms.

 

In this case, it used a template for what should and shouldn’t be in a WordPress database. The fact there were so many identical links in each post was the first red flag. Then seeing the links were all for a .js file was another indicator. The BAe, grabbed the code from that link and analyzed it. Full analysis involves deobfuscating the javascript.

 

Working with the deobfuscated javascript, BAe looks for any URLs. It checks them against various lists of bad URLs including Google’s Safe Browsing. In this case, as stated earlier, the main URL was not listed in Google’s database of malicious URLs, but my BAe digs further and further until it finds exactly what the code is doing. Here, the code was redirecting and the redirected URL was changing.

 

All indications that the link in the database, (remember in one site, 8,616 times!) was malicious and needed to be removed.

 

Conclusion

Sometimes it’s what you don’t know that will hurt you – or in this case, your website. Please, in your agreement with a developer or server management company, request they move all unnecessary files after a project. If you need help in identifying more POE’s, let me know. I can scan your site. Well, actually, my systems will scan your site.

 

If you found this useful, please share it. If you’re an SEO, web dev, digital marketer, please share it the Facebook groups you’re in. Everyone can benefit from this information.