Update: WordPress in the Age of Hackers

It’s now the fourth month that the CuriousProg.com website has been up and running and the suspected attacks continue. I wrote in the original post about attempts to compromise the security of the site. There were a number of distinct types of attacks that I had seen:

  • Attempts to log in to the WordPress dashboard via wp-login.php
  • Attempts to get the names of users registered on the site (using “/?author” or another “special” request URL)
  • Looking for backups of the WordPress database that could have been left accessible in the site
  • Attempts to access the xmlrpc.php interface (most likely to run some kind of code on the site)

As of this date I still see a lot of isolated requests to “/wp-login.php” and “/xmlrpc.php”. But there are some additional types of attacks that I’ve monitored that are worthy of discussion.

A “Scavenger” Attack – Thursday, October 16

Apparently from Riga, Latvia, these are all GET or POST requests, mostly to PHP scripts with unusual names, none of which exist on my site. PHP scripts like these wouldn’t normally be requested by themselves; they would be one of multiple requests used to compose the content of the page.

There were a total of 28 requests over 17 days starting on September 30 (a selection of the requests are shown below).

What are these scripts and why is someone looking for them on my website? A quick spot check of a few of the filenames in internet search revealed that these are “command and control” scripts, software that a hacker would install on a website once they were able to compromise security on the site and get the power to upload files to it. It seems like this is a laundry list of a lot of different, unrelated scripts. I’ll call this a “scavenger” attack: someone is searching for malware that someone else has already managed to get installed on the site. If they get a “200 OK” response rather than “404 Not Found”, they know that the script actually exists on the site. The malware could then be used to launch some other kind of attack from this site to other sites (brute force password discovery, a DDOS attack, etc).

. . User-Agent:  Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0
. . Referrer:    -
30/Sep/2017:13:33:44 -0400  404  POST  /cachee.php
30/Sep/2017:19:09:28 -0400  404  POST  /options.php
01/Oct/2017:00:42:30 -0400  404  POST  /sockarp.php?login=cmd
01/Oct/2017:06:28:53 -0400  404  POST  /wp-admin/includes/index.php
01/Oct/2017:12:04:20 -0400  404  POST  /wp-includes/pomo/index.php
01/Oct/2017:17:44:31 -0400  404  POST  /indes.php
01/Oct/2017:23:12:38 -0400  404  POST  /wp-sbb.php
02/Oct/2017:04:50:34 -0400  404  POST  /wp-admin/includes/wp-cods.php
02/Oct/2017:10:29:58 -0400  404  POST  /forum.php
15/Oct/2017:13:18:37 -0400  404  GET  /wp-includes/Text/Tiff.php?x=1
15/Oct/2017:16:01:40 -0400  404  POST  /wp-content/plugins/SocketIontrol.php
15/Oct/2017:18:44:24 -0400  404  POST  /wp-includes/indes.php
15/Oct/2017:21:29:40 -0400  404  POST  /includes.php
16/Oct/2017:00:14:08 -0400  404  GET  /wp-content/themes/sketch/content-post.php
16/Oct/2017:03:13:57 -0400  404  GET  /wp-includes/SimplePie/Decode/HTML/bug.php
16/Oct/2017:06:07:12 -0400  404  GET  /wp-pas.php

As discussed in the first post, these listings (generated from web server log files) show:

  • the date and time (with timezone offset from UTC time) of the request (04/Aug/2017:06:16:38 -0400)”
  • response status (“404”)
  • request method (“GET” or “POST”)
  • and request path (“/cachee.php”)

The request path is the resource (page or part of the page) that was requested; it is listed without the site’s hostname, so the full URL of the example request shown above would be “http://curiousprog.com/cachee.php”. The top of the listing also shows the user agent and the referer for the list of hits. The user agent is the identifying string for the kind of browser that the visitor was using (Firefox in the above example). The referer is the page from which the request was made. If the user clicked a link to get to this page, the page where they clicked will be listed as the referer (example: “www.google.com” for a click on a Google search result).

Since all requests returned a “404” (“Not Found”) response, I think I’m safe for now, but it’s ominous that hackers are scanning to capitalize on others’ work like this!

Looking for Plugin Vulnerabilities – Thursday, October 19

Apparently from Vilnius, Lithuania, there were 30 requests to this site within about 3 seconds, with one more straggler coming in a half an hour later. The requests all involved looking for files under the “wp-content/plugins” folder – files that are part of an installed WordPress plugin.

As discussed in the previous post, WordPress plugins sometimes develop bugs that open security vulnerabilities on the WordPress site. It’s most likely that the hacker is looking for plugins with these known vulnerabilities. Diligent owners of these plugins will quickly issue new releases to fix these problems, but it’s up to the owners of sites where the plugins are installed to log into their WordPress admin dashboard and accept these updates – the updates are not installed automatically when released!

Here’s a sample of the suspicious requests. All of them have the same user agent (looks like a valid web browser, “Chrome”), but no referer:

. . User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.15 (KHTML, like Gecko) Ubuntu/10.10 Chromium/10.0.611.0 Chrome/10.0.61
1.0 Safari/534.15
. . Referrer:    -
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/wpstorecart/lgpl.txt
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/custom-content-type-manager/index.html
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/magic-fields/MF_Constant.php
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/wpmarketplace/readme.txt
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/front-end-upload/destination.php
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/user-avatar/readme.txt
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/font-uploader/font-uploader-free.php
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/ninja-forms/ninja_forms.php
19/Oct/2017:07:03:03 -0400  404  GET  /wp-content/plugins/fcchat/default.png
19/Oct/2017:07:03:04 -0400  404  GET  /wp-content/plugins/resume-submissions-job-postings/installer.php
19/Oct/2017:07:03:04 -0400  404  GET  /wp-content/plugins/nextgen-gallery/changelog.txt
19/Oct/2017:07:03:04 -0400  404  GET  /wp-content/plugins/nmedia-user-file-uploader/readme.txt
19/Oct/2017:07:03:05 -0400  404  GET  /wp-content/plugins/user-meta/readme.txt
19/Oct/2017:07:03:05 -0400  404  GET  /wp-content/plugins/user-photo/admin.css
19/Oct/2017:07:03:05 -0400  404  GET  /wp-content/plugins/mac-dock-gallery/bugslist.txt
19/Oct/2017:07:03:06 -0400  404  GET  /wp-content/plugins/front-end-upload/destination.php
19/Oct/2017:07:33:24 -0400  404  GET  /wp-content/plugins/wp-filemanager/fm.php

Brute Force Attack from Many IP Addresses, Same User Agent – August through October

A general pattern emerged after months of watching the access logs: requests from IP addresses all over the world, each with the exact same user agent. There have been 202 requests from 61 different computer hosts, 83 of the requests from one site in Brazil, others 1-2 requests each from sites in the United States, Canada, Mexico, France, Italy, Germany, Portugal, Estonia, Romania, Argentina, Kenya, and India. These requests came in periodically beginning August and extending into October.

These were mostly requests to “/wp-login.php”, also to home page (“/”) and a few requests to “/xmlrpc.php”. These are not the kinds of requests that would be made by someone reading a post in a browser.

The user agent for all requests was:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1

While a new browser release will certainly get millions of downloads, version 40 of Firefox was released sometime in 2015 – the most recent version of Firefox is at version 56.0.2. Yet this two year old version of Firefox logged a disproportionately large number of requests to the site (there were more requests in October from Firefox/40.1 than from Firefox/56.0).

These were mostly requests to /wp-login.php, also to home page (“/”) and a few requests to “/xmlrpc.php”. These are not the kinds of requests that would be made by someone reading a post in a browser. These are most likely attempts to log in to the WordPress dashboard (“/wp-login.php” requests) to discover usernames and passwords or insert malicious software into the site (“/xmlrpc.php” requests).

This is almost certainly an example of a large, well organized “bot net”: a collection of servers around the world, on which “command and control” software has been installed, all being controlled from one location, instructed to mount one kind of attack. Anti-malware software will block large numbers of frequent requests from the same server; by using multiple servers, the hacker is hoping to evade detection.

Another Search for Plugins – Saturday, November 4

On November 4, I found yet another attack looking for WordPress plugins that don’t exist on my site. Apparently from the Seychelles Islands, this attack made 30 HTTP requests in about 9 seconds, each one looking for some file under the “/wp-content/plugins” folder.

These requests all returned a “404 Not Found” response – except for one, which did find a “license.txt” file for a plugin that I do use on my site! A quick check found that there was a security bug detected in this plugin over a year ago which had already been patched. It could be there’s a new, “zero day” vulnerability that the hackers know about and the developers are not yet aware of, but no apparent damage has been done to my site, things look good.

This attack seemed to be a little more sophisticated than others in one way: it specified a different user agent for almost every request, all coming from the same IP address! Is it possible that 30 different people were all logged in at one IP address, all browsing to a single WordPress site, all requesting obscure paths to plugins on the site, all within 9 seconds? Highly unlikely, looks like an attack, using many different user agents to evade detection by anti-malware software.

Brute Force Username/Password Attack, November 11

A new attack began on November 11, making repeated requests to “/wp-login.php”, most likely trying usernames and passwords. This has been ongoing through November 13, with over 400 attempts being made – a few calls an hour. The vast majority of the requests give the same user agent string, Firefox/34.0. Many of the requests are apparently from Russia, but each request is from large list of over 400 unique server IP addresses – another bot net! A few of the requests, with the same sequence of requests, are apparently from other locations around the world: Poland, Japan, Canada, Kazakhstan.

The full user agent string for most of these requests was:

Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0

The requests follow a pattern: there’s a GET request for the “/wp-login.php” page, which succeeds with a 200 status, followed by a POST request, again to “/wp-login.php”, which fails with a 503 “Service Not Available” error. The latter POST request is most likely trying to send username and password combinations (difficult to tell why it’s failing with the 503 error).

Here’s a sample of one of the pairs of requests:

User-Agent:  Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0
Referrer:    -
11/Nov/2017:16:48:20 -0500  200  GET  /wp-login.php
User-Agent:  Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0
Referrer:    https://curiousprog.com/wp-login.php
11/Nov/2017:16:48:22 -0500  503  POST  /wp-login.php


In my previous post on hack attacks on my WordPress site, I described “brute force” attacks that made many requests, attempting to discover usernames and passwords. This post show that these attacks continue, as well as some other interesting varieties of attempts:

  • Attempts to discover malware previously installed on the site
  • Attempts to discover plugins installed on the site that might have security vulnerabilities

It’s one thing to read about the possibility of hacks on WordPress, but quite another to see first hand the frequency and intensity with which these attacks can occur!

What Can Be Done

These were discussed in the first post, but this more recent experience reinforces some tips to follow for good WordPress security:

  • Pick non-obvious user names (not “admin” or “administrator”, nor “super” or “user”!) for any user login that you create for the dashboard on your WordPress site. Combine this with a long, non-obvious password (more than 8 characters, using a combination of upper and lowercase letters, numbers, punctuation marks, etc). If a hacker can discover a username and password with admin privileges, they can install malware on your site!
  • Keep all WordPress plugins and themes up to date. Two of the attacks demonstrate that hackers are actively searching for a “laundry list” of plugins. Plugin and theme owners update their software to fix security bugs, but WordPress site owners have to take action to install the updates!
  • Uninstall themes and plugins that you don’t use; reduce the number of possible ways that security vulnerabilities can appear on the site.
  • Make regular backups of your WordPress website and the database associated with it. In the event a hacker does get into the site and modify or damage it in some way, the site can be restored from an earlier backup. Arrange to keep these backups offsite if possible, in case a ransomware attack ends up encrypting your website.

The last measure, regular backups, is important for the case of a “zero day” vulnerability, a security bug in WordPress (one of its themes, or any of its plugins) hackers have discovered but of which security experts or WordPress developers are not yet aware. It’s very possible that there will be a window of opportunity where a hacker can break in to a WordPress site despite best efforts to keep themes and plugins up to date. A recent, undamaged backup can restore the site to a good state with little data loss in such a case!

Follow Up: March, 2018

Things have quieted down considerably on my blog site since this was first posted in November. It seems like some of the attackers move on to newer sites after a site has been in existence for a few months. But there’s still a low level of continuing attempts to break in to the site: enumeration of user accounts using the WordPress JSON API, brute force attempts at password discovery, inserting comments to posts with links to overseas sites selling sportswear, etc.

Just this month, there were a number of attempts at password discovery, apparently from a server in Mexico. All attempts used the “admin” user name; the following passwords were tried:

111111, 123123, 123321, 123456, 1234567, 12345678,
1234567890, 123qwe, 654321, 666666, admin, adminadmin123,
administrator, demo123, letmein123, loveyou, pass123, 
password, qwe123, qwerty, root, siteadmin, test123

These all follow well known patterns of “bad” passwords that you should not use for securing your website!

This month, the city of Atlanta, Georgia experienced a major attack to several of their only sites (see the CNN article City of Atlanta still crippled six days after ransomware attack). This was a ransomware attack, where the hacker encrypts all content on a website, making it unreadable until it is “unlocked” with a digital key that only the attacker has – and the hacker is demanding 50 bitcoins in payment (about 400,000 US dollars as of this writing) to unlock the Atlanta sites!

The Washington Post recently published an article saying that “a typical small business website is attacked 44 times a day” and that software “bots” (running on other servers) visit websites around the world 152 million times each week.

If you think that your website is too small or insignificant to be attacked by hackers, think again! Choose long, not so obvious usernames and passwords, use HTTPS for your site, keep your WordPress theme and plugins up to date, and follow other good security practices (as outlined in this post, my previous post on WordPress security as well as other sites) to keep your site safe and secure!


Bringing Up a WordPress Site in the Age of Hackers


WordPress 4.8.3

Add a Comment

Your email address will not be published.