We often see security companies try to make hackers sound very scary and sophisticated in what appears to be an attempt to make it more likely that people will purchase their products and services, but the reality is often quite different. While there do seem to be some sophisticated efforts to exploit vulnerabilities in WordPress plugins, including cases where hackers look to be the ones that have discovered vulnerabilities that exist in plugins (for which we are often the ones that then detect that), a lot of hacking attempts are decidedly not that.

In the past we talked about the correlation between what plugin vulnerabilities get exploited and what vulnerabilities there are YouTube videos on how to exploit, which doesn’t really sound like something you would expect from sophisticated actors. In another instances we spotted a hacker incorrectly trying to exploit a vulnerability in a plugin that only 60+ active installs. We recently came across another example of how poor some of the attempts are.

While reviewing the logs of this website to see how often and when there had been hacker activity related to one plugin with a vulnerability in it, we came across a series of requests probing for usage of quite a few WordPress plugins with known vulnerabilities. What is show below won’t necessarily mean much if you are unfamiliar what is shown in log files, but the important element here is that the number 301 included on each of those lines:

192.169.250.35 - - [17/Jan/2017:22:36:58 -0500] "GET /wp-content/plugins/weever-apps-20-mobile-web-apps/static/js/config/wx.tabtypes.js HTTP/1.0" 301 637 "-" "-"
192.169.250.35 - - [17/Jan/2017:22:36:58 -0500] "GET /wp-content/plugins/dop-slider/libraries/js/jquery.uploadify.min.js HTTP/1.0" 301 607 "-" "-"
192.169.250.35 - - [17/Jan/2017:22:36:59 -0500] "GET /wp-content/plugins/developer-tools/js/developer-tools.js HTTP/1.0" 301 587 "-" "-"
192.169.250.35 - - [17/Jan/2017:22:36:59 -0500] "GET /wp-content/plugins/social-networking-e-commerce-1/js/effects.js HTTP/1.0" 301 601 "-" "-"

The significance of that is that 301 in that location indicates that the requester was told that the requested URL has permanently moved to another location. In this case the cause of that is likely that the URLs were requested without the “www.” portion of our website’s address or they were requested using HTTP instead of HTTPS. What should happen next is that a request should be made to the new URL that was sent back with the previous request. That didn’t happen, so if we were using any of those plugins the hacker would not have found out that we were using it and then moved on to trying to exploit it. We don’t use any of the plugins they were probing for, but someone that did could have been saved from being hacked by this. Handling a 301 redirect is relatively basic task when making requests to web pages, so it shouldn’t be something that doesn’t get properly handled in this type of situation.