Massive RFI scans likely a free web app vuln scanner rather than bots

Published: 2014-01-17
Last Updated: 2014-01-17 21:28:34 UTC
by Russ McRee (Version: 1)
3 comment(s)

On 9 JAN, Bojan discussed reports of massive RFI scans. One of the repetitive artifacts consistent with almost all the reports we've received lately is that the attackers are attempting to include I investigated a hunch, and it turns out this incredibly annoying script kiddie behavior is seemingly, rather than bots, thanks to the unfortunate misuse of the beta release of Vega, the free and open source web application scanner from Subgraph.

One of the numerous Vega modules is Remote File Include Checks found in C:\Program Files (x86)\Vega\scripts\scanner\modules\injection\remote-file-include.js.

Of interest in remote-file-include.js:

var module = {
  name: "Remote File Include Checks",
  category: "Injection Modules"
function initialize(ctx) {
  var ps = ctx.getPathState();
  if (ps.isParametric()) {
    var injectables = createInjectables(ctx);
    ctx.submitMultipleAlteredRequests(handler, injectables);
function createInjectables(ctx) {
  var ps = ctx.getPathState();
  var injectables = ["",
    var ret = [];
    for (var i = 0; i < injectables.length; i++)
     return ret;

Great, now the kiddies don't even need to figure out how to make RFI Scanner Bot or the VopCrew Multi Scanner work, it's been dumbed down all the way for them!

What steps can you take to prevent and detect possible successful hits?

  • Remember that the likes of Joomla and WordPress, amongst others, are favorite targets.
    • If you're using add-on components/modules you're still at risk even if keeping these content management systems (CMS) or frameworks (CMF) fully up to date. As always, you're only as strong as your weakest link.
    • Component/module developers are not always as diligent as the platform developers themselves; believe me when I say the Joomla team cares a great deal about the security of their offering.
    • Audit add-on components/modules you have installed, see if there are any open vulnerabilities for them via, and ensure you're utilizing the most current version.
  • Check your web site directories for any files written during or soon after scans.
    • If the remote file inclusion testing proved successful, the attackers will turn right around and drop a file(s) typically.
    • Such files could be a TXT, PHP, or JS file but they also like image file extensions too and will often drop them in the images directory if the vulnerability permits.
  • Yours truly has been dinged by this issue; you have to remember to keep ALL related code current or kiddies will have their way with you.
  • Check your logs for successful 200 (successful) responses where the humans.txt file was attempted, particularly where the GET string includes a path specific to your CMS/CMF.
  • Hopefully you see only 404 (not available) responses, but if you do see a 200 it warrants further investigation.
    • 404 example entry: - - [05/Jan/2014:18:16:13 +0800] "GET /A-Blog/navigation/search.php?navigation_end= HTTP/1.0" 404 927 "-" "-"
    • 200 example entry: - - [05/Jan/2014:18:29:29 +0800] "GET /configuration.php?absolute_path= HTTP/1.0" 200 - "-" "-"

Now that we know it's less likely bot behavior and more likely annoying miscreants, take the opportunity to audit your Internet-facing presence particularly if you use a popular CMS/CMF.

Cheers and feel free to comment or send additional log samples.

3 comment(s)


Maybe it would help if your 200 example wasn't an exact copy of the 404 example??
Doh! Sure would help. Fixed, and thanks.
Sorry, if this is off topic, but on the My ISC page in the section "Current Ports of Interest" I get a php/mysql error message that has much more details than I would wish if this was my site -- especially as a security site.
Also: thanks for the quick fix.

Diary Archives