Suspicious Activity: “An admin user with the username backup was created outside of WordPress”

On 14 February 2018, WordFence alerted me to highly suspicious behavior. This is the format of the email I received from WordFence version 4.9.3:

This email was sent from your website “[REDACTED BLOG NAME]” by the Wordfence plugin.

Wordfence found the following new issues on “[REDACTED BLOG NAME]”.

Alert generated at Wednesday 14th of February 2018 at 12:07:50 PM

Critical Problems:

* An admin user with the username backup was created outside of WordPress.

NOTE: You are using the free version of Wordfence. Upgrade today:

Receive real-time Firewall and Scan engine rule updates for protection as threats emerge
Other advanced features like IP reputation monitoring, country blocking, an advanced comment spam filter and cell phone sign-in give you the best protection available
Remote, frequent and scheduled scans
Access to Premium Support
Discounts of up to 90% for multiyear and multi-license purchases
Click here to upgrade to Wordfence Premium:
https://www.wordfence.com/zz2/wordfence-signup/

This is suspicious on its own, but I wondered if it might be benign. Or at worst, maybe was a plugin gone bonkers. Or maybe my web host was doing something wonky. But strangely, when looking at the accounts in the database I noticed there was no nickname or email address associated with the account. WordPress requires both to create an account if you go through the normal way.

This email was sent from your website “[REDACTED BLOG NAME]” by the Wordfence plugin at Wednesday 14th of February 2018 at 08:28:38 AM

The Wordfence administrative URL for this site is: http://example.org/wp-admin/admin.php?page=Wordfence

A user with username “backup” who has administrator access signed in to your WordPress site.

User IP: 35.183.24.90
User hostname: ec2-35-183-24-90.ca-central-1.compute.amazonaws.com
User location: Montreal, Canada

…then WordFence alerted me this user logged in from an EC2 instance.

Then I got 5 more log-ins in the space of about 10 minutes to other sites I maintain. From the same computer. In my mind, this elevated “suspicious” to “probably malicious.” In that moment I was very glad for my MySQL backup processes that would allow me to go back a few days in time before this nonsense.

The behavior was so swift I wonder about whether it was automated, but logging in with saved credentials is not a terrible slow operation even for a person.

The lack of email address on the accounts implies, to me a concrete plan. No email address means they would have no way to reset their password but also no way for me to track them by email.

I knew I wanted to remove access for this user. So for each I needed to

1. 1. Change their password
   2. Log them out
   3. Add an email address I control for each account
   4. Change the SALT for the password encryption for each site.

So I did 1, 2, and 3. I used the standard WordPress user administration panel to change each password and log each out. I also added an email address using the gmail “+whatever” format:

Append a plus (“+”) sign and any combination of words or numbers after your email address. For example, if your name was hikingfan@gmail.com, you could send mail to hikingfan+friends@gmail.com or hikingfan+mailinglists@gmail.com.

I kept a list of the sites I was modifying as I went. I also inspected some of the other applications I have hosted to see if there was anything unusual there. Code injections or user creation, for example. I didn’t see anything.

Then I did step 4 for each of the sites. Wordress provides a “SALT CODE GENERATOR” at https://api.wordpress.org/secret-key/1.1/salt/ which gives you a code block suitable for adding to wp-config.php easily. What is the Salt? I let the WordPress documentation tell you:

In Version 2.6, three (3) security keys, AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY, were added to ensure better encryption of information stored in the user’s cookies. These collectively replaced a single key introduced in Version 2.5.
In Version 2.7 a fourth key, NONCE_KEY, was added to this group. When each key was added, corresponding salts were added: AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, and NONCE_SALT.

You don’t have to remember the keys, just make them long, random and complicated — or better yet, use the online generator. You can change these at any point in time to invalidate all existing cookies. This does mean that all users will have to login again.

…

A secret key makes your site harder to hack by adding random elements to the password.

In simple terms, a secret key is a password with elements that make it harder to generate enough options to break through your security barriers. A password like “password” or “test” is simple and easily broken. A random, long password which uses no dictionary words, such as “88a7da62429ba6ad3cb3c76a09641fc” would take a brute force attacker millions of hours to crack. A ‘salt‘ is used to further enhance the security of the generated result.

I’ve not seen any recurrence of the suspicious behavior and have not seen any attempted entry by any of the “backup” accounts created.

There’s no common themes or plugins (other than WordFence and WordPress and my own host) to link the intrusions but I’ll remain vigilant. When I wrote “WordFence is vital for self-hosted WordPress instances” the other day this is the kind of thing I was thinking of.

I reported the behavior to my web host, which they appreciated. I had blocked the IP address for all my sites from that host which they verified I did correctly. They also showed the logs of the logins and other than dates and times not much was useful other than a User-Agent of Mozilla/5.0 (Windows NT 6.1;
WOW64; rv:37.0) Gecko/20100101 Firefox/37.0.

Because it was an EC2 instance that was at the originating IP address, I also collected my notes on the behavior and reported it to Amazon Web Services: AWS: Report Abuse.

On 21 February 2018 I received replies from Amazon. Not particularly satisfying but it’s my hope they’ll continue to take security seriously.

Hello,

Thank you for submitting your abuse report. We have begun our investigation into the source of the activity or content you reported.

We’ve determined that an Amazon EC2 instance was running at the IP address you provided in your abuse report. We have reached out to our customer to determine the nature and cause of this activity or content in your report.

We will investigate your complaint to determine what additional actions, if any, need to be taken in this case. Due to our privacy and security policies, we cannot provide details regarding the resolution of this case, or the identity of our customer. We may notify you during our investigation if our customer requires more information from you to complete their troubleshooting of the issue. Our customer may reply stating that the activity or content is expected and instructions on how to prevent the activity or manually remove the content, as well. If you wish to provide additional information to us or our customer regarding this case, please reply to this email.

Please note that if we determine the activity or content to not be abusive, we will notify you and resolve the case; we may refrain from communicating further, in that case.

We will notify you once this case has been marked resolved. Thank you for alerting us to this issue.

Regards,
AWS Abuse Team

And also this, which resolves the closes the case out:

Hello,

This is a follow up regarding the abusive content or activity report that you submitted to AWS. We have investigated this report, and have taken steps to mitigate the reported abusive content or activity. Due to our privacy and security policies we are unable to provide details regarding the resolution of this case or the identity of our customer.

We are committed to mediating reports of abusive content or activity to the satisfaction of both the reporters and our customers. If you believe the reported content or activity persists, or are not satisfied with the resolution of this case, please reply directly to this message with more information. Your response should include the most recent activity logs or web location of the content that you have available that indicates that the activity or content persists, as well as a clear, succinct explanation of what you expect of us and our customer.

Thank you for bringing this matter to our attention.

Regards,
AWS Abuse Team

I hope this proves useful to folks. If you’re running self-hosted WordPress, do take a serious look at WordFence.