The Vital Role Of Logs In WordPress Security

This is the third article in a 3 part series on the use of activity logs in WordPress.
Read the first article here.
Read the second article here.

This is the last part of the three article series about how activity logs can help WordPress site administrators. In the first article we have seen how, with a WordPress activity log, you can improve user accountability and tick some compliance check boxes on your WordPress site.

In the second article of this series we looked into the different types of logs WordPress site administrators and developers have at their disposal to help help them ease the troubleshooting of technical problems.

In this third and last article we will see how activity logs can help WordPress site administrators like you to:

• Improve the security of your WordPress site
• Track down the source and damage in a post-hack scenario (forensics)

To highlight how important logs are in WordPress security, I’d like to use a quote from the PCI DSS compliance document:

“Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise.”

Which Logs To Use And When?

The most important logs for detecting and preventing attacks, and to do forensic work on WordPress sites are:

• WordPress audit logs (activity logs)
• Web server access log file
• SFTP logs

Detecting & Preventing WordPress Hack Attacks With Logs

In an ideal world, site administrators have time to review the logs. This is most probably one of the most underrated site admin activities, and unfortunately many, including yours truly, are too busy to do it.

When you analyze the logs you can notice suspicious behaviour which could be a sign of an attack. You can also learn how attackers are trying to break into your WordPress site. Here are some examples of what to look out for in the logs.

The WordPress Audit Trail

Failed login attempts: You should not alarm yourself if you notice a few failed login attempts every day. That is normal. However, if you notice hundreds or thousands of failed login attempts using random usernames, that means that someone launched an automated brute force attack against your site.

If you notice that a particular user has a high number of failed login attempts check with the owner of that username, because it could also be a sign of a targeted hack attack.

Requests to non-existing pages: Similar to failed login attempts, the few daily occurrences of website visitors requesting non-existing pages is nothing to be alarmed about. However if you see a lot of such requests to directories such as /wp-content/plugins/* or the uploads directory then it is something to worry about.

Abnormal user activity: As a website owner you get used to your users’ working patterns. You know roughly when they login, from where they login and what they typically do when logged in to your WordPress site. This knowledge allows you to spot a user login or a content/site setup change during odd hours, or from an unusual IP range. When this happens, double check with the actual user if the activity is legitimate.

Web Server Log Files

In the web server access and error log file you can see what type of scans attackers are launching against your website and what type of vulnerabilities they are trying to exploit.

184.154.139.21 www.wpsecurityauditlog.com - [26/Mar/2019:13:02:52 +0000] "GET /th1s_1s_a_4o4.html HTTP/1.0" 404 60 "-" "SiteLockSpider [en] (WinNT; I ;Nav)"
184.154.139.21 www.wpsecurityauditlog.com - [26/Mar/2019:13:03:25 +0000] "GET /wp-content/cache/min/1/d52574f45f8ba5eb72fa2c5d2d86484e.css/readme.html HTTP/1.0" 404 269 "-" "SiteLockSpider [en] (WinNT; I ;Nav)"
74.208.165.233 www.wpsecurityauditlog.com - [26/Mar/2019:14:27:25 +0000] "GET /wp/wp-login.php HTTP/1.0" 404 35251 "http://www.wpsecurityauditlog.com/wp/wp-login.php" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
178.128.56.15 www.wpsecurityauditlog.com - [26/Mar/2019:18:22:57 +0000] "GET /wordpress/wp-login.php HTTP/1.0" 404 35251 "http://www.wpsecurityauditlog.com/wordpress/wp-login.php" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

The above is just an abstract from our site’s access logs. The first two requests are generated from the SiteLock spider, which means that someone is using Sitelock to scan our website. In the other two lines we can see that someone is trying to find the login page. Actually there are hundreds of requests from each of the above IP addresses in the logs, which means they are automated scans.

In some cases you might spot attackers that are trying to exploit a known vulnerabilities in a WordPress plugin that you might not be even running. Check the example below:

"GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.1" 403 227
"GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.1" 403 229
"GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.1" 403 1058
"GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.1" 403 220
"GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.1" 403 111
"GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.1" 403 125

The above are abstracts from an access log file of a web server. We can see that someone is automatically scanning the web server, trying to exploit the notorious Revolution Slider vulnerability that was discovered years ago. You might notice such patterns in your logs even if you do not have the plugin installed. And that is expected, because most of these attacks are automated mass scans, i.e. non targeted WordPress attacks.

The Need To Setup A WordPress Intrusion System

Most probably you barely have time to generate enough content for your business’ WordPress site, let alone review the logs. The good news is that you can automate part of this process with a WordPress Intrusion Detection System. If you use the WP Security Audit Log plugin you can configure a number of email notifications so that, when there is suspicious activity, you are alerted instantly, enabling you to take the necessary evasive action.

What Can You Do Once You Spot Suspicious Behaviour?

It depends on the nature of the case, but here are a few things you can do:

• Double check with the user if it was legitimate behaviour.
• Block the IP range at website level, or ask the hosting provider to block it at their firewall level.
• If you notice that someone was able to access some files they shouldn’t have accessed, or some section of the website they shouldn’t have access to, update the permissions at quickly as you can.

The above is just a high level idea of what you can do. As such it is very difficult to tell what remedial actions you can take to evade an attack because it always depend on the situation. Nevertheless, it is imperative to always double check things before changing the setup to ensure you do not block legitimate changes.

The Role of Logs in WordPress Forensics

In a post-WordPress-hack scenario you have to trace back the malicious users’ activity to find out what flaw they exploited and what damage they have done on your website. Sounds easy, right? It is not.

The purpose of analyzing the logs in a post-hack attack is primarily to find out how the users gained access to your website and close that security hole. Not doing this could result in your site being hacked again.

So how did it happen? Did they exploit a vulnerability in an outdated plugin, or did they guess a user’s weak password?

In forensics there are no blueprints that tell you what you need to do to trace back activity. Every case is unique. That is why it is a very tricky and difficult job. You should use all of the logs available to try and figure out how the malicious attackers gained access and what they did once they gained access. Use the:

• WordPress activity logs to see what the attackers did once they gained access. Maybe you can also find out how they managed to get in, especially if they guessed a weak password.
• Web server logs, including the error log to try to find out if they exploited a known issue in WordPress, a plugin or a theme. This might be possible if you are running out-dated software.
• SFTP log files to see if they guessed a users’ FTP password.

If you have a dedicated/virtual server and are running other network services it could also be that the attackers gained access through another service, or a known issue in the operating system. In that case you have to dig deeper and analyse the syslog (system logs) and all the other available log files.

You Know Your Website and Setup, so You Know Best

Security professionals can give you a lot of tips on what to keep an eye on and what to lookout for when analyzing the logs. This will help you learn about possible attacks or do post-hack forensic work. However, you are the one who knows your WordPress site, how it’s set up, and the web server hosting setup the best.

It is vital that you learn as much as you can about your users’ behaviour and your setup, so you can easily spot and prevent any possible attacks, ease troubleshooting, and improve user accountability on your WordPress site.

Logs for WordPress Security

WP Mayor trusts in WP Security Audit Log for activity logs on our WordPress sites.

Get started today!

Disclosure: Some of the links used above are affiliate links, meaning that, at no extra cost to you, we may earn a commission if you click through and make a purchase.