Posted on Jul 14 2017 byin Blog Blogs Blogs and Blogging Security
Attackers have been setting their sights on freshly installed WordPress deployments, taking advantage of users who fail to follow through when it comes to configuring their server’s settings.
Researchers at the WordPress security plugin WordFence said Tuesday they observed a significant spike in attacks targeting WordPress accounts from the end of May to mid-June. According to the organization, the biggest increase in scans – roughly 7,500 a day – came on May 30.
According to Mark Maunder, the company’s CEO and founder, attackers mounted thousands of scans each day for /wp-admin/setup-config.php, a URL that new WordPress installations use to setup new sites. These are instances where a user has installed WordPress on their servers, just not configured it.
It wouldn’t be difficult for an attacker to carry out an attack, something Maunder dubs a WPSetup attack. Assuming a user hasn’t finished setting up their WordPress site, an attacker can swoop in and finish the user’s installation for them. With admin access, an attacker can enter their own database name, username, password, and even database server. From there an attacker would have to run an installation and enter some supplementary account information to gain control of the site.
Maunder says it’d be fairly easy for an attacker to execute PHP code, either via a theme or plugin editor, to compromise a victim’s hosting account, in addition to the site. In this case the attacker would have administrative access after all. From there they could also upload their own plugin with PHP code and activate it.
Furthermore an attacker could install a malicious shell in a victim’s directory to access any files or websites on the account or access any databases or application data that vulnerable WordPress installations have access to.
WordPress experts claim the attack method isn’t exactly new, but that it clearly hasn’t limited its effectiveness.
“The attack itself is a well-known tactic. Web scanners have been configured to look for default install files and directories for years,” Weston Henry, lead security analyst at SiteLock, a service that carries out daily scans of websites to identify vulnerabilities, said Thursday. Henry points out that spiga.py, an old web scanner, could be used to sniff out unfinished phpMyFAQ installations. After finding one it’d be easy for an attacker to complete the installation and achieve admin access.
Maunder says users should create a specially coded .htaccess file in the base of their web directory to ensure attackers can’t access their sites in the middle of an installation. .htaccess files are server configuration files, normally located in a site’s root folder, that can be used to enforce SSL, protect sensitive files, and only allow access to selected IP addresses only.
Maunder also says users could install their WordPress files either by unzipping them or doing a one-click install, then access their site immediately and complete the installation. This process is riskier, because an attacker could still pounce on a site if a user is slow, but serviceable, Maunder says.
This entry was posted in WordPress Security on July 11, 2017 by Mark Maunder 51 Replies At Wordfence, we track millions of attacks from a wide variety of sources every day. From this data we create a list of the worst-of-the-worst attackers and add those to our IP blacklist to protect our Premium customers. We also carefully monitor the activity that those known bad IP addresses engage in.
In May and June, we saw our worst-of-the-worst IPs start using a new kind of attack targeting fresh WordPress installations. We also had our first site cleaning customer that was hit by this attack.
Attackers scan for the following URL:
This is the setup URL that new installations of WordPress use. If the attacker finds that URL and it contains a setup page, it indicates that someone has recently installed WordPress on their server but has not yet configured it. At this point, it is very easy for an attacker to take over not just the new WordPress website, but the entire hosting account and all other websites on that hosting account.
How the WPSetup Attack Works
There are several ways you can install WordPress. You can simply unzip the ZIP archive into a directory on your hosting account, or many hosting providers provide a one-click install that does the same thing.
At this stage, even though you have the base WordPress files installed, there is no configuration file yet, so it needs to be created. You used to have to do this manually, but new versions of WordPress guide you through creating this file using a web interface.
If you unzip WordPress or use a one-click installer and don’t immediately complete the installation steps, an attacker who is scanning for fresh installs on your server can use your fresh install to take control of your website.
Let’s walk through the steps to understand how the attacker takes control of your site once they have located your fresh WordPress installation. The first step is to select your language:
Then you see an introductory message:
And finally, you let WordPress know your database name, username, password and which server it lives on.
If an attacker finds your fresh install, they can easily click through the first two steps and then enter their own database server information in this final step. Their database can be on their own server, and it doesn’t have to contain any data – it can simply be an empty database. They just need to get a working WordPress installation running on your site that they have admin access to.
Once this step is complete, WordPress confirms that it can communicate with the database – in this case, the attacker’s database:
Once the attacker clicks “Run the install,” they are prompted to enter information to create the first admin-level account.
They enter their own account information, click the Install button and receive a confirmation that WordPress has been installed and the admin account has been created.
The attacker then retypes the admin credentials they created in the setup process…
… and is signed into a fresh WordPress install on your server using their own database.
How the WPSetup Attack Gets Full Control of Your Hosting Account
Once an attacker has admin access to a WordPress website running on your hosting account, they can execute any PHP code they want in your hosting account. There are several ways they can do this.
Executing PHP Using a Custom Plugin
Once an attacker has admin access to a WordPress site, they can upload any plugin with any PHP code, including their own custom plugin. To execute their code, they spend a few minutes creating a basic WordPress plugin and then upload it to the site and activate it.
What an Attacker Does Once They Can Execute PHP Code
Once an attacker can execute code on your site, they can perform a variety of malicious actions. One of the most common actions they will take is to install a malicious shell in a directory in your hosting account. At that point they can access all files and websites on that account. They can also access any databases that any WordPress installation has access to, and may be able to access other application data.
How to Protect Yourself Against the WPSetup Attack
This attack is gaining popularity. To avoid falling victim, we have provided two procedures you can use below:
Procedure 1: The Safe Way to Install WordPress
Before you install a fresh WordPress installation, create a .htaccess file in the base of your web directory containing the following:
order deny,allow deny from all allow from
Replace the ‘
This rule ensures that only you can access your website while you are installing WordPress. This will prevent anyone else from racing in, completing your installation and taking control of your hosting account by uploading malicious code.
Once complete, you can remove the .htaccess rule and allow the rest of the world to access your website.
Procedure 2: The Risky Way to Install WordPress
This procedure is risky because, if an attacker is fast enough, they can still take control of your site. We don’t recommend this, but include it for completeness.
Instead of creating the .htaccess rule above, you can use the standard WordPress installation method. To reduce the risk of being attacked, you need to shorten the time between installing the WordPress files and completing installation as much as possible.
Recommendations for Server Administrators and Hosting Providers
If you operate a server or a network of servers that provides WordPress hosting to customers, we recommend the following to mitigate this attack:
Scan your hosting accounts for WordPress installations that do not have a wp-config.php. These may be fresh installations that have not yet completed setup. If navigating to the base URL of the site redirects you to /wp-admin/setup-config.php then you have confirmation that setup is incomplete. We suggest you alert your customer they should either complete setup or remove the files.
If you have an IDS (intrusion detection system), you should consider monitoring traffic from your web servers to the open Internet for any MySQL traffic. This may indicate an attacker has configured a WordPress site on your network using their own database on the Internet.
If you have any other mechanisms in place to monitor or prevent connections from your web servers to arbitrary databases on the open Internet, we recommend you use those to mitigate this attack.
Final Advice and Your Thoughts
I recommend that you take the additional step of auditing your own hosting account to make sure you have not accidentally left any unconfigured WordPress installations lying around. If you don’t want to do this yourself, consider our WordPress Site Audit service, which provides a comprehensive site security audit and will include a check for incomplete installations.
As always, I welcome your feedback in the comments below. If you have additional ideas to help mitigate this attack or to help WordPress improve the setup process to avoid this attack, I’d love to hear them.
PS: Please share this with the WordPress community to create awareness of the risks of unconfigured WordPress installations.
Did you enjoy this post? Share it!