Almost 60K infected sites had installed a WordPress security plugin with a malware scanner.
This report is intended to answer questions and add context to our recently announced discovery of tens of thousands of compromised WordPress websites where popular security plugins were present but unable to detect malware that added itself to the security plugins’ allow lists.
During a 60-day window (May-June 2023), we witnessed 149,252 WordPress websites become infected with malware. Some were infected via the Elementor Essential Addons plugin. Others were infected via stolen admin credentials and two-factor authentication tokens.
WeWatchYourWebsite began offering our services to many server providers in late 2022. Our free service only detects and reports intrusions (no remediation of compromised sites), but we see everything happening on the sites we’re watching. We are a white-label service, so we will not disclose the names of our clients.
Watching Hackers Target the Essential Addons for Elementor Plugin
On February 1, 2023, we began seeing many requests like this in HTTP access logs:
Our service streams log files from websites to our servers for real-time analysis. We’ve been analyzing log files since 2007, so we know that a combination of scans for readme.txt files and the source IP address, if it’s determined to be suspicious, can be a problem. We added a focus to our system for these log entries. This focus allows us to track suspicious requests and their activities based on their IP addresses, user agents, and other factors.
Over February and March 2023, we recorded 17,585 log entries where readme.txt files were being scanned across 312,211 servers. As March progressed, so did the frequency of the scans. However, by April 3, 2023, the scans had slowed, but the number of servers and sites we monitored kept increasing, indicating the scans were slowing.
The number of servers we watched increased while the number of scans for the readme.txt files decreased. The scans became more widespread from multiple IP addresses, however. In contrast, in early February, most scans came from one IP address with the same outdated user agent.
When an exploit was publicly announced for the Essential Addons for Elementor plugin, the suspicious traffic was no longer looking for the readme.txt for this plugin. The hackers no longer cared and were assuming every site had installed it.
By May 12, 2023, we saw large-scale malware infections, and the list of servers we monitor reached 1.5 million. Most of these have more than one website, so the total number of websites we monitor surpassed five million.
Watching Malware on Hacked Sites Make Itself Undetectable to Security Plugins
From the beginning of May through the end of June, we detected 149,252 infected websites. Not all of these were infected by the Essential Addons for Elementor exploit. Since we monitor the databases as well, we started seeing many changes.
Our systems monitor the database for logins, users added, and modifications that happen to over 20 posts on the same website (a possible indication of compromise), and various other changes to WordPress databases.
Of the 149,252 infected sites, 52,848 had the Wordfence security plugin installed. Of these 52,848 sites using Wordfence when they were breached, 7,399 had Wordfence’s exclusion list tampered with. Remember, some of these 52,848 sites were infected via the Elementor Essential Addons vulnerability, and others were infected through compromised login credentials.
Watching Hackers Bypass Wordfence’s 2FA on Over 20,000 WordPress Sites
We know exactly how many sites in our monitoring, with Wordfence installed, had two-factor authentication (2FA) activated: 21,487. That’s almost half the total infected sites with Wordfence.
We don’t know which or how many of these sites were using the free or premium versions of Wordfence. However, Wordfence released an updated firewall rule to block the Elementor exploit for their premium users on May 11, 2023, and their free users had it available on June 20, 2023.
From May to June, we watched backdoors being uploaded to the infected sites, and we also noticed the backdoor files being added to various tables in the WordPress databases.
We saw this in the corresponding access logs:
Inside the priv-wf.php file, we saw this line:
And this is in the database table:
The last line — /wp-content/plugins/goals/languages/File.class — is a Linux binary (ELF). It connected to a command-and-control server and then received and ran remote commands. This file created a process that continually ran in memory when executed. The commands it received and executed were typically lists of other websites to target with brute-force attacks.
Interestingly, the priv-wf.php was not added to the exclusion list.
Watching Hackers Use Compromised Sites to Attack Other Sites
In our system, we saw log entries like:
[May 12 2023 20:20:32] [3885952.833406] [OUTGOING 443] SRC=xxx.xxx.xxx.xxx DST=(webserver IP address) …
So, we know the malware on compromised sites was being used to attack other websites.
I will not list the affected database tables here because I don’t want to make it easy for anyone to add malware files to allow lists. However, these filenames were added to the exclusion lists of security plugins. Hackers were doing this to avoid detection by whatever malware-scanning plugin was installed. Their success at defeating malware scanners showed us how easy bypassing some plugin-based malware scanning is.
When a website is compromised, hackers can upload a variety of files. These files often read the database login credentials of the wp-config.php file. Then they log in, add extra WordPress admin users, change passwords, inject code into the _posts table, etc. In this case, they added some of their backdoor shell files to the exclusion lists of the malware-scanning security plugins.
Why would hackers do this?
Hackers want to maintain control of a website for as long as possible. What better way than to add a new admin user and exclude their malware from being scanned by security plugins trying to detect it?
It doesn’t matter if the malware scanning plugin is the best (read: “industry-leading”) or if it’s local or remote, it won’t see the malware file.
From May to June, we watched attackers’ IP addresses being added to an allowed list in WordPress security plugin firewalls. Some WordPress databases had as many as 20 different IP addresses added to an installed security plugin’s allowed list. We then saw numerous attacks originate from those same IPs as the infected sites with the modified allowlist were used to infect even more sites.
Watching Hackers Steal Session Cookies and Bypass 2FA Challenges
In some situations (14,412 of the 149,252 sites) during this 60-day window, we saw an IP address added to the allowed list. Then seconds later, we saw an admin user logging into the compromised WordPress site from the same IP address. Based on the traffic we observed, 43% (6,197) of these 14,412 sites appeared to be breached with a stolen authentication cookie. Checking these sites programmatically with automated browser requests looking for wp-admin/wp-login.php, we discovered that 89% (5,515) of them had 2FA activated. So these illicit logins with stolen authentication cookies bypassed the 2FA.
Of the 149,252 sites, 5,462 had the MalCare security plugin installed. 24% of these sites (1,202) were tampered with to make Malcare blind to the intrusion. Since MalCare provides exclusion lists of IP addresses, not files (that’s a good thing), only the IP exclusion lists were tampered with. But again, the stolen authentication tokens allowed attackers to bypass Malcare’s 2FA easily.
Nothing was stopping them.
Not IP blocklists.
Solutions for preventing authentication tokens from being stolen are a topic for another day. Still, if you search the web for “info stealing malware,” the first results (out of 4.3 million) will explain how prevalent and damaging data breaches can be.
We originally wrote about this back in January of 2022: https://wewatchyourwebsite.com/one-way-hackers-hack-wordpress-sites
How We Collect Our Data:
Our services are installed on servers. They run as root, so there is no tampering with them. A hacker would need to gain complete control over the server to tamper with our service.
We monitor all file changes and additions for each website on a server. Every time a file is added or modified, it’s automatically analyzed by our three engines. The first engine is signature-based, the second detects anomalies, and the third performs behavior analysis.
Our system also streams access and error logs to our servers for real-time analysis. This lets us respond rapidly to our customers when an intrusion is detected. Finally, we monitor customers’ WordPress databases for suspicious logins and changes.
With our combination of file integrity monitoring, log streaming, and database monitoring, we can identify compromised WordPress sites as quickly as attackers breach them.