Examining the site’s access logs, I noticed many requests for /?author=123, where the numbers ranged from 1 to several hundred. The goal of this type of malicious scan is to obtain information about registered usernames, which can then be used to brute-force attack the site’s login form. This tutorial explains how “user-ID phishing” works, and how to stop it cold with a slice of .htaccess.

How it works

To understand how user-ID phishing works, let’s say that you scan a WordPress site for the first 10 user IDs. Upon doing so, WordPress will display the Post Archive for any matching (existing) authors. On many WordPress sites, you can see this by requesting the following URL:

https://example.com/?author=1

This typically returns the Post Archive page for the site administrator, which many people leave set at the default “Admin” or something similar. So on the displayed Post Archive page, many themes will include “About the Author” information or similar, something that reveals the name of the author.

Even if the theme does not reveal any sensitive author information, the name of the author may be revealed directly in the URL, for example:

https://example.com/author/admin-username/

This happens when WordPress Permalinks are enabled: the requested ?author=1 query gets redirected automatically to the “pretty permalink” version of the URL, with the full username plainly revealed.

Regardless of how the author username is obtained, once the bad guys get ahold of it, they can use it to brute-force attack your login page and gain access to your site. This is known as user-id phishing and it is trivial to block with a quick snippet of .htaccess.

How to block it

Now that we understand how user-ID phishing works and why it’s bad, let’s take a moment to protect our sites by blocking it. To do so, we add the following snippet of .htaccess to our site’s root .htaccess file:

# Block User ID Phishing Requests
<IfModule mod_rewrite.c>
	RewriteCond %{QUERY_STRING} ^author=([0-9]*) [NC]
	RewriteRule .* http://example.com/? [L,R=302]
</IfModule>

What this code does:

1. Checks if mod_rewrite is available
2. Checks if the query string begins with author=, followed by any number
3. If so, the request is redirected to the location of your choosing (change http://example.com to match your URL)

Alternately, instead of redirecting the phishing request to example.com, it’s possible to simply deny it access by serving a 403 Forbidden error. To do so, replace the RewriteRule line with the following:

RewriteRule .* - [F]

Caveat

This technique should be employed only if your site is not using plain, query-string-based URLs (as specified in WP’s General → Permalink settings).

Note

Depending on your server/setup, the previous code may need to be placed in the .htaccess file that resides in the root of your WordPress install. For example, if WordPress is installed in a subdirectory named /wp/, it may be necessary to place the code in /wp/.htaccess, instead of in the site’s root directory. This has to do with how WordPress uses .htaccess to process permalinks and only affects specific setups.

So try placing the code in root .htaccess and test. If it works, then great you’re done. If not, then try placing it in the WP install directory and test again.

Once located in the proper location, the code will protect your site against all future user-ID phishing attempts. So you can focus on more important tasks, like creating awesome content.

Going further..

Blocking user-enumeration scans is a good first step in protecting your site against username disclosure. The next step is to make sure that your theme template is not revealing any sensitive user information on the front-end. To learn more, check out my tutorial on stopping user-enumeration scans in WordPress.

Bonus Tip: if you’re running BBQ Pro, you can block user-ID phishing with a few clicks.