Sometimes, while determining root cause of a website infection, we see many new methods. However, recently we’ve been seeing the same old tactics hackers have been using for years.

 

A recent case showed that sometimes, the good old methods still work.

 

Repeat Infections

 

One such case involved  a WordPress website that was hosting with GoDaddy. Single site on a cPanel account. The web dev had installed and run every security plugin available. Some free, some paid.

 

They could find the infection and remove it, but since none of them do root cause analysis, they didn’t know how it was happening. What was interesting is that some of the security plugins identified the other security plugins as being malicious, so it would remove them. One such plugin, identified the rules of another plugin as being malicious and insisted the code be removed from the database of the WordPress site. If that would have been allowed, it would have broken the website and it would be showing 500 errors.

 

Website Malware Root Cause Analysis

 

There seems to be two different strategies when dealing with an infected website.

 

The first strategy seems to focus around, remove all malware, then add every security feature known and hope for the best. While this might work some of the time, it doesn’t work all the time. In this specific case, the web dev had even activated 2fa from a very popular security plugin, but the hackers still got in, over and over again.

 

The other strategy is to find out how it’s happening (root cause) so that hole can be plugged in addition to adding other security measures to prevent other attack tactics.

 

The firewalls from the various security plugins proved ineffective as well.

 

We were contacted, due to our specialty of performing root cause analysis, and asked to dive in. Of course we spotted the infected file immediately. It was code added to the footer.php file of the theme.

 

But that was it! No other malicious code. No backdoors. Nothing.

 

According to the dev, it had been happening for weeks as the various security plugins were installed, configured and run. All but 2 found the infected code in the footer.php file, but could not stop it.

 

The first thing we checked was the cron jobs. Maybe, it was a cPanel infection and the hackers were able to add a cron job in cPanel. Hackers have been doing that since we started removing malware from websites back in 2007. But, checking the .lastlogin file did not reveal any evidence of a breach there and there were no cron jobs either.

 

This is what a typical malicious cron job might show:

 

 

 

 

The Truth is in the Logs

 

We started analyzing the access logs. Luckily, this cPanel account had them activated, many don’t.

 

In this situation, being a cPanel account, we can’t install our Log Collector to get the logs live. So we download what’s available and load them into our home grown log analyzer. We named it, Paul Bunyan. Of course, only internally, not as a brand.

 

Our analyzer looks at many, many different factors. If it finds something suspicious in the logs, it will backtrack, on it’s own, to gather more information. This allows it to either verify, or deny the suspicion.

 

This system ties into our malware scanner so it knows what was found and the date/time stamps of the malicious code. (This is helpful, even though we know that date/time stamps can be tampered with).

 

Being that our malware scanner only found infectious code in the footer.php file for the current theme, our log analyzer scans for that string (footer.php) in the logs first.

 

BAM!!!

 

 

 

 

 

We don’t show the login, but it was with username and password. That first line above shows they went to the /wp-admin/theme-editor.php and included the file they wanted to edit: footer.php in the Kadence theme. We’ve redacted the IP address of the source of this attack, but it was another GoDaddy site in Germany that had been infected and controlled by the hackers.

 

What’s interesting in the above, is that when they’re finished, they logged out!

 

Why is that interesting (I wish all admins would do the same!)?

 

Because the process of logging out removes evidence in the database. As a normal part of our process, we check the database to see who has logged in (but not out) for all admins. When you logout, it kills the session cookie and removes the information from the database.

 

I’ve said it before, hackers know their stuff.

 

Normal WordPress Logins

 

 

 

 

 

 

 

In the above graphic, you see a normal login. The first two lines are obvious, but what follows is our proof that this particular user, logged in with a username and password. There is typically the last line of /wp-includes/css/dashicons… the password strength meter, etc. In the case of a stolen session cookie, you would just see traffic going straight to the wp-admin function. Typically. I know of someone who will read this, lose his mind and have to debate me on this, but we’ll just see what happens. 😉

 

Root Cause Analysis based on FACTS

 

In the particular case, we were able to definitively identify the source of the infection, change all admin passwords, and rest easy as another case closed.

 

We have let the web dev know that someone either had an easy to guess password, although, we did not see evidence of brute force/credential stuffing attacks in the logs that were available. Our gut said some admin user has a info stealer on their local device and it stole the username, password and login URL. We’re still waiting to hear what anti-malware programs the admins are using…

 

Sometimes, the old tactics still work.

 

Until next time! (LOGOUT!!!)