XMLRPC or WP-Login: Which do Brute Force Attackers Prefer
At Wordfence we constantly analyze attack patterns to improve the protection our firewall and malware scan provides. We recently took a closer look at brute force attack targets, specifically XMLRPC and wp-login, to gain a deeper understanding of how attackers behave.
In WordPress, there are several ways to authenticate, or sign in to, your website. The two most common ways to authenticate are using the standard login page located at wp-login.php, and by using XMLRPC.
The XMLRPC method is usually used by applications like mobile apps to authenticate before you are able to perform privileged actions on the site.
We analyzed attack data over a 2 week period from January 16th until Janary 29th to determine which target attackers prefer to attack. Here are the results of our analysis.
Which Target Receives More Attacks?
During a two week period we saw almost exactly the same number of attacks on XMLRPC as wp-login. We saw a total of 106 million attacks on wp-login compared to 108 million attacks on XMLRPC.
This result surprised me because I assumed that attackers targeting XMLRPC would be more sophisticated or perhaps creative. But on reflection it takes about the same amount of effort to write an attack script or bot that brute force attacks either target. So this makes sense.
How Many Attackers Hit Both XMLRPC and WP-Login?
The above graph shows the number of unique IP addresses per attack target. Note that this is not the number of attacks, but number of attackers counted as unique IP addresses we saw attacking.
While XMLRPC saw slightly more attacks, wp-login saw slightly more unique attackers, as you can see from the above column chart.
We saw 11,453 attackers only targeting XMLRPC. We saw 38,771 attackers only targeting wp-login. And we saw a whopping 224,461 unique IP addresses targeting both XMLRPC and wp-login.
Clearly most brute force attacks target both XMLRPC and wp-login.
Do Attackers in Different Countries Prefer XMLRPC or WP-Login?
We analyzed attacks from the top attacking countries and saw an interesting trend. As you can see above, most of the attacks come from Russia and the USA is the second most prolific attacker.
What is interesting here is that the attacks originating in Russia have a strong preference for wp-login as a target. And attacks originating in the USA have the opposite preference. They seem to mostly target XMLRPC instead.
Digging Deeper into Brute Force Attacks originating in the USA
As you can see the majority of the total number of attacks originating in the USA come from Amazon.com which provides cloud computing services to developers. We saw a total of over 144 million attacks over two weeks originate from Amazon.
Most of these attacks were targeted at XMLRPC. What is surprising though is that they came from only 36 unique IP addresses hosted at Amazon. All but 3 of these IP addresses appear to be EC2 instances based on their reverse hostnames.
So what is happening here? I’m going to suggest two theories:
One possibility is that 36 servers at Amazon EC2 have been compromised and they have been used to launch a very rapid and wide-spread brute force attack during the past 2 weeks. That attack generated over 144 million failed login attempts across the sites we monitor.
An alternative theory is that a developer may be using EC2 to host an application that is trying to sign into WordPress websites using XMLRPC. The application may not handle bad user credentials correctly and may just keep retrying.
It may be a combination of both bad applications hosted at EC2 and compromised servers engaging in a large scale brute force attack.
Conclusion
The data in this post brings up the old debate about whether or not it’s a good idea to hide your login page. Unless you hide every login method on your site, attackers will still be able to brute force your website.
If you disable or move XMLRPC, you risk breaking various applications, including mobile applications, that rely on XMLRPC to do their job.
If you hide or move your login page, you are going to inconvenience or confuse your users, and XMLRPC is still an attack vector.
Other authentication methods will soon become available in WordPress via, for example, the WP REST API. These will also be exploited by attackers.
So the action we recommend is that you use a security product like Wordfence to intelligently block brute force attacks, no matter what they target. Wordfence counts brute force attacks across all authentication methods and blocks attackers if they violate security policy.
Wordfence can also help you enforce strong passwords and audit your passwords for strength.
We also track attacks across all the sites we protect and take earlier blocking action against known bad IP addresses that have attacked other websites.
As always I welcome your comments below and I’ll be around to join the discussion.
Mark Maunder – Wordfence Founder/CEO
Special thanks to Dan Moen who produced much of the data used in this post and to assistance from our team in analyzing the data.
Comments
9:04 am
"Don't care"...I block both...On my sites they get a big fat 403. There are other methods of doing both these tasks that are easily obfuscated.
9:04 am
Love reading these articles, well done on some more insightful research. I was quite surprised that most of the attacks came through XMLRPC, I always thought it would be easier to trawl and attack through wp-login
I standby that using WordFence is the best thing you can do to protect WordPress sites / multisites because you're not just using the functionality, you're sharing information with the global community about malicious activity and reaping the rewards of it
9:06 am
Great Insights.
It would be helpful if you could share the 36 unique IP addresses hosted at Amazon. I ask so because I would like to block them proactively, before they try to login.
Thank you!
10:33 am
Agreed! I do it manually for the most part, but would really like to be able to add blocks.
9:17 am
We couldn't block access to wp-login.php for obvious reasons. We did however decide that NO ONE should actually be accessing xmlrpc.php directly. In 'Options' we simply added /xmlrpc.php in the field for "Immediately Block IPs that access these URLs"
Most every IP that it catches as accessing xmlrpc, it also lists as having tried wp-login 5 or 6 times. Seems to be working well for us.
7:27 am
Brilliant and simple
9:24 am
I had one my wordpresses on ec2 compromised after fixing it and cleaning things. I checked the code they added and it was sending massive emails. it's very likely that those ec2 servers compromised. it would be nice if host companies always take these things and seriously and work with renters to fix them. we would have much less hacks and spams.
1:17 pm
AWS will work on specific rogue activity if you contact them.
9:28 am
Mark,
For a few users that need the wordpress login. Can't you create an IP address verification to allow access to this login page which can be controlled by a text file above document root and put in folder determined by the webmaster and set in the WF options. It of course would need to update using ftp instead in case it changes.
9:33 am
I am curious as to your statement "If you disable or move XMLRPC, you risk breaking various applications, including mobile applications, that rely on XMLRPC to do their job."
Surely this is only if you need the ability to post to your Wordpress blog from an email, Wordpress app or similar?
If so, I feel that turning it off is the safest option unless that functionality is essential to you. I know of none of my clients use this (I polled them).
I would be interested in how used this technology is.
6:06 am
By default when I setup a WP site, I always disable XMLRPC using htaccess. When and if the client complains, I'll turn it back on. I've only had 2 clients complain since 2005 after hundreds of installs. Blocking XMLRPC from the htaccess file also has the added benefit that WP doesn't use up as many server resources before the request is denied.
9:34 am
Is it possible that hackers are getting free trials on Amazon cloud and then deploying attacks on fresh deployments? Sounds like the best way to hide who and where you really are.
1:25 pm
I read this several years ago when I started using WordPress. I saw tons of Amazon server attacks. In some forum, somewhere, this was suggested. People sign up for free 30 day accounts, using them to attack, then just create another account and so on. Not sure if that's true, but interesting to see it again.
9:34 am
Such a great post! Wordfence is a true crusader in anti-hacker war. Some pieces of information seems unbelievable - as I'm writing this a houndrets of attacks has occurred.
9:36 am
It's interesting to note that Amazon is the US-based host provider with the most attacks, but Comcast has the most attacking IP's. If I were an attacker who had control over various IP addresses, which would be the most effective approach?
1) Many IP addresses, fewer attacks with each?
2) Less IP addresses, more attacks with each?
9:39 am
We look after 11 small websites. 3 are unused and on those we see a different attach pattern. On these unused/inactive sites there there constant WP-Login attacks from Russian origin - all unique IP addresses (maybe 100-200 attempts a day) and each only attempts to log in once. The IP addresses are the same across the 3 websites - so it is a campaign. I guess they are targeting these inactive websites as they believe that security will be weaker?
Why are they only attempting a single log-in each time? Curious.
My experience across all our websites for country of origin of attack mirrors your graph with the exception of USA where the attach rate is below that of Turkey/France.
9:46 am
Great article, but because wordfence is specialized in WordPress, it would be more helpful and practical to add some statistics about WordPress and brute force attacks.
10:01 am
These are WordPress only statistics.
9:48 am
Mark, as always this is a great post. Understanding these attack vectors really help us make determinations about all of our security protocols across our entire client support network since we've built and manage many dozens of client websites, all in WordPress. I might add...all now use Wordfence!
Regarding Amazon's hosting servers. Have you made Amazon's data center executives aware of these IP addresses that seem to be the source of so many brute force attacks? Can you tell if these are true attacks, or are some of these benign app access attempts that have gone off the rail? The XMLRPC approach is one that many of my colleagues haven't really thought much about since we have typically viewed the traditional WordPress /wp-admin login screen attacks as the culprit. Wow...your data really opened our eyes. So, kudos for these insightful posts that are backed by real data...not by speculation.
Jim Martin
Chief Digital Officer
Communication Links
Scottsdale, AZ
10:02 am
Thanks Jim. We don't currently report attacks to the abuse contact on whois information associated with netblocks. It would be quite labor intensive for us although perhaps there's a way to automate that in future.
Regards,
Mark.
11:38 am
Thanks, Mark. I just felt your Amazon-related revelation is so aggregated among a handful of IP addresses at their hosting centers that it might be worthwhile to share the data with them. I can certainly understand that every IP address that is sourced from bad actors can't be shared with every hosting company to get them to investigate and shut those accounts down. The larger publicly-held companies like Amazon and GoDaddy, e.g., have a vested shareholder interest in making sure they are not used as attack vectors.
Appreciate the reply. Keep up the awesome work. It helps me sleep better at night knowing your team is probably getting less sleep than I do :-)
6:12 pm
I host a small set of web sites which on one occasion experienced an attack from a handful of Amazon AWS EC2 instances. I sent a message to AWS support - not expecting a reply :-) - and was pleasantly surprised. They wrote back within a day to report that they'd taken action and terminated the instances. They also told me more about the particular attack that I'd been experiencing (some of our users had downloaded a Firefox add-on which was sending URLs to the EC2 instances for 'shadowing' hack/attack purposes).
I appreciate that it's no doubt the rule that most admin / abuse contacts will do little in response to alerts that they are hosting hackers ... but in my one experience so far with Amazon AWS they were the exception to the rule.
1:42 am
I just tried, for fun, to report one attack to the Amazon abuse contact on whois information, with all the detailed logs and informations. Answer from Amazon was more or less : 'Not informations enough' ! Sure, automated report option is welcome.
10:14 am
I sent some Wordfence blocking reports to Amazon abuse email pointing to the same IP address that was constantly trying to login on one of my sites. They replied that they will investigate the case only if I could send them Apache log extracts. As I didn't want to spend too much time doing this, it didn't go further and it explains also how these attacks can go on for a long time... ;O(
7:14 pm
@Franck You can get your apache logs for that EC2 IP by running: zgrep "ip-address" /var/logs/apache2/*
10:57 am
Thank's a lot.
Would be great have a list of ip range to block, on the base of most largest attacks they do.
From long time i'm thinking to eliminate completely xmlrpc... i no see way i use, is just usefull for those "sirs"...
11:04 am
The way i use is hotlink (php) file extension in htaccess and no one can play with them.
11:34 am
Useful insights as always, we also found over that period France was higher than Russia for attacks, but with WordPress still showing the username of whoever made the post on a site ( a major flaw imo) WordPress is literally giving attackers the user name with which to base attacks from!
5:45 pm
When I set up user accounts, I create a nickname and specify that to be used in the display when posting on WordPress. WordPress gives you nicknames, but they can be similar to your real userid, which is not a good idea.
11:47 pm
I set WP to attribute posts to a name other than the user, for exactly that reason. Is there any reason you cant do that?
12:12 pm
Great reading as always Mark :) I have also blocked all XMLRPC on all our 20+ sites. Also i have noticed quiet a few login attempts also some in the 200+ per day.
Is anyone else seeing a lot of wp-admin views but no actual login attempt???
its very strange seems like they are seeing if the page wp-admin is available first, but then nothing no attempt at all..
We check all live feeds at least 3 times a week and some time manually block those just in case.....Its like a game.
12:14 pm
"Most of these attacks were targeted at XMLRPC. What is surprising though is that they came from only 36 unique IP addresses hosted at Amazon. All but 3 of these IP addresses appear to be EC2 instances based on their reverse hostnames."
Knowing these IPs would be an asset.
12:44 pm
Are these password guessing attacks on wp-login also trying to guess two-factor verification codes?
3:16 am
No. We haven't had any reports of that. A user would receive several SMS's they didn't generate if that was the case.
4:07 pm
Good to know. Thanks. I use an app for verification so I don't get notified when someone tries.
I guess this means that I can forget about brute force attacks and just worry about the complex ones.
1:03 pm
I hope you made Amazon.com aware of what is going on. They have been pretty good at responding to issues like this when you give them proof that they can verify.
3:17 am
I'd love to make ISP's aware of attacks but as I mentioned to another commenter, it would be a very large job considering the volume of attacks we monitor. We may look at automating that in future.
1:10 pm
The way I have seen AWS used is to provide HTML and graphic content to WordPress sights that have been hijacked.
2:55 pm
Is it more effective to block the /xmlrpc.php in WF or is it feasible to delete the .php file? What suffers if the .php file is not present?
3:18 am
I discuss that in the post above. Your mobile apps will stop working. We don't recommend deleting or disabling it. Just use Wordfence and we'll block malicious activity targeting any endpoint in WordPress.
5:31 pm
I use .htaccess rules to limit access to "wp-login.php" and "xmlrpc.php" to known/trusted IP addresses. So other IP addresses get a 403.
I then use "ErrorDocument" in the vhost definition to redirect 403's to a non-existent page, when therefore gives them a standard Wordpress "Not Found" page.
3:20 am
This will break mobile apps or provide an inconsistent experience. It is also not usable for sites that have open registration for example. And it will bite you if your dynamic IP changes. I don't recommend this approach.
12:48 am
I've made the arbitrary decision to not use mobile apps for Wordpress. I'm the only person who requires access, and I don't use open registration. Personal site, personal blog...no need to cater for anyone other than myself in this instance... :)
Agree that for more open sites, this wouldn't cut it - flexible thinking is needed in most cases.
8:20 am
I agree with Michael. I'm the only authorized content creator and admin for my site. I shut down all automation via the block url list and a couple of "disabler" plugins. That includes xmlrpc, ajax, json, rest, as well as probably over 100 attack patterns (with variations for case and with and without asterisks after) I've seen in the log files. No external user has a reason to be hitting any php url (other than me for admin), any .js, any .asp, any .aspx files on my site directly. I realize this won't work everywhere, but for people that don't need all the fancy whizbang features (and associated security holes), this is probably the best approach. I also agree with Mark that allowing access to stuff by IP is potentially unstable. However, once I've confirmed an attack pattern from an IP, I block it permanently, unless it's a simple login attack that is also blocked by country blocking. I may or may not get around to unblocking it a few months later.
Ron
7:13 pm
I agree with the findings of this report, it mirrors my experience watching my dedicated server come under attack last week. The IP would hit XMLRPC and wp-login.php almost simultaneously. I don't think I ever saw them hit one and not the other. The attacks came so intensely that it drove my server load up over 50. I recorded the IP and then firewalled it if they hit those files. Most were Russian IP's but there were others from Greece, Philipines, Indonesia, Spain, etc. However, I did create new login pages for my Wordpress clients with wps-hide-login and the number of attacks dropped dramatically. They seem to give up when they can't access those files.
12:01 am
Mark thanks so much. Startling and very helpful
I wonder does the Wordpress login method suffer from the same vulnerabilities?
I note that jetpack uses XMLRPC in authentication during setup and in my case the server blocks XMLRPC access to my dormant/clone site which is probably a really good idea in light of all this commentary.
So I am unable to complete jetpack setup on a clone site, but I'm OK with that, it makes sense.
Next observation, re Amazon. I'd imagine admitting liability for any compromised servers would be very damaging and contrary to policy.
We can hardly blame them, it must be a nightmare.
10:26 pm
Thanks Mark, it was so informative. I have also received attack alerts in different country's. They used that same login different country's ip's, and it is happening every minute.
I have set login attempt and fail to very least one. And it drops dramatically.
I was looking for why they used such nonsense logins, doesn't make sense. If they have compromised server why they such logins? they know if they launched the attacked everyone gets alarm and can track where it come from. Or are they gathering much useful intel?
4:40 am
Hi Mark,
I absolutely love WordFence because you love to break down complicated techie articles for security newbies like myself.
The first time my Wordpress account got hacked I was in shock. I was the typical user with the admin username lol but I make sure my username is more complex and I use Wordfence to protect my website.
I have been considering changing my login url but it seems like you think it's best for us not to.
Thanks Mark
7:51 pm
Please use the link below to report the abuse to AWS:
https://aws.amazon.com/forms/report-abuse
11:44 pm
Great reading as always Mark :) I have also blocked all XMLRPC on my site, I absolutely love WordFence
8:26 am
I think it would be really cool if our live traffic, blocked ip, and ip history lists would show if a login was actually attempted as opposed to just showing that the page was hit. If a login was attempted, it would be neat to see the login name and password attempted. It might provide some good forensic intel.
Ron
1:49 pm
I used to get a lot of wp-login attacks - often more or less simultaneous from obscure countries like ulan bator. I blocked them permenantly with wordfence and most never try again but some IPs and blocks have tried hundreds of times. I moved login to a another file using one of the 'change login' plugins which was trivial and no-one has discovered the new file name in months so no more logins as requesting wp-login gets you blocked by Wordfence. On one occasion I was getting many attacks and found one US IP that seemed to be associated - an email to the abuse address stopped them all for weeks! I have had positive responses to abuse emails contianing a cut and paste from wordfence. Wordfence is essential - its on my 5 wordpress sites and I monitor the traffic from time to time. Does anyone have a simple method of downloading the daily IPs so I can see who visits regularly using a script or just Excel? At the moment it only gives the last 100. Which file is the number of displayed ips stored? Thanks
5:49 am
Someone is trying to attack my site by accessing both /xmlrpc.php and /wp-login.php.
Every 3 minutes or so they use a new IP. Each time they hit /xmlrpc.php once and /wp-login.php four times.
The User-Agent is always the same and I have block it using 'Advanced Blocking', but obviously this blocks legitimate users and is not really a solution.
I have added /xmlrpc.php to 'Immediately block IPs that access these URLs' (It doesn't seem to have made a difference).
They seem to also get through cloudflare's captcha (I added a captcha requirement for visitors from certain countries).
There are no reports of failed or successful logins (apart from my own).
Nothing seems to work or keep them permanently away. They are wasting my server resources!
This started all of a sudden and does not look like it will stop.
Is there anything I can do?
Many thanks!
11:58 am
Great insights from this read! Nice to see broken down data of the countless attacks and which methods actually use. Though I have to admit this "Russian hacking" situation is really getting out of hand. IMHO, I think it play into this whole Russians-rigged-the-US-election storyline but there's absolutely no proof it's them. I've checked a few of the Ru IPs that've hit my WP instances and have yet to find solid proof that they're being used by actual Russians for the hacking/brute force attempts.
As far as securing my WPs, I go about a bit different than what was posted here. I do run WF on all my sites... it's practically a pre-requisite. I NEVER display the usernames on pages or posts and still block access to most common used usernames (admin, administrator etc) as well as the actual/real administrators usernames... I password protect the wp-admin folder, use 2-factor verification. I also have an advanced .htaccess routine, blocking access to .php and .js files...
Once I had hardened my sites, I saw a near stoppage of attacks. I say near because I don't want to block XMLRPC nor do I think relocation wp-admin/wp-login.php to be solid solution, not to mention the use of plugins to achieve that which is adding another possible entry point.
Fredo.
PS: Team WF keep up the great work! A good chunk of my security rests on you and I appreciate the effort!
4:32 am
I found that russia is the stronger force at the time I had to really pick up my fences in Nov/Dec always hitting the login and the XMLRPC. I had moved the login and disabled the other since I dont really need it plus set up some "rat traps" Since I did that I can sleep better :-)