WordPress Security: My take on wp-vcd.php
I understand that millions of people are concerned about WordPress Security. I also understand that people tend to follow others when it comes to things they don’t fully understand – such as WordPress security.
Recently Wordfence provided a very detailed article about the WP-VCD infection campaign. They did an excellent job. I have respect for what they do and their information sharing.
However, it represents a different experience than what I learned from this same infection.
This post will share my point of view and share some of my insights on WordPress security.
I’ll spare you the detailed analysis of the code the hackers uploaded. While I can and definitely have the ability to present complex analysis in terms understandable by all, I know that most of my customers have little care of what it does, they just want it gone.
My experience of WP-VCD
One of the first things I looked for when I worked on a website with wp-vcd.php infection was the root cause – how did the hackers get in.
My systems scan the log files to see when the first occurrence of infected files appear in the logs. This doesn’t mean that’s when the file was uploaded, but it gives my systems a point of reference to start from.
For instance, we (I say we, but it’s my systems), scanned the logs for the first occurrence of wp-vcd.php and then move back to see what led up to that file existing. Frequently, not always, when hackers infect a website, they check to make sure the infection was successful. Such is the case when they upload a backdoor.
In each of my situations, my systems found that the hackers had logged in with an existing WordPress administrator user. Not “admin”, but another named administrator user. This login preceded the installation of malicious plugins or themes.
I was seeing log entries like this:
69.10.33.123 – – [01/Nov/2019:09:11:50 -0700] “POST /wp-admin/network/update.php?action=upload-plugin HTTP/1.1” 200 20005 “https://[redacted].com/wp-admin/network/plugin-install.php” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36”
Prior to this log entry, there was also a single, successful, login from the same IP address. The whois for that IP address point to interserver.net, who provides web hosting, VPS/dedicated servers, cloud servers, and colocation.
I specify it was a single, successful login because that is important. In other words, at this point, hackers already had the username and password. At this point, it wasn’t “brute-forced”. The hackers already knew it. Talking with the website owners, I discovered that they used the same email address and password across many sites – one of them being the infected WordPress site.
Digging further, I used: https://haveibeenpwned.com/ to discover that each of the email addresses associated with the admin-level user for each of these infected WordPress websites, was in the haveibeenpwned.com database.
Further investigation proved each of these users verified that the websites listed as being breached, were used by the individual AND they used the same password.
How large data breaches affect WordPress Security
Let’s recap thus far.
They, the website owners, used the same email address and password across many websites, one of those sites was breached, and the login credentials were compromised and the stolen login credentials were used on WordPress websites.
The hackers found one that works, logged in directly, and then uploaded a bogus/infected WordPress plugin. This was all confirmed by the timeline of events correlated with the log files.
This gets back to STOP using the same password across multiple websites.
That’s one of the easiest fixes ever! Don’t use the same password across multiple websites.
What you think is safe…
I’ve seen this a few times, things you think about WordPress security, things that you believe will make your site safer, can be used against you.
Some of the plugins uploaded by the hackers actually searched the site for the following plugins:
- Wordfence
- Sucuri
- iThemes
- gotmls
and if their search found any of these plugins it injected code into their plugins in an attempt (I didn’t test it) to include their malware as being safe. This obviously, is due to some extreme analysis and investigation and reverse-engineering of each of the plugins.