Friday, January 22, 2016

Gotcha of the Day: Finding the source of SPAM from a WordPress install

One of my clients who runs WordPress reached out to me earlier: they had received notification that they're system was sending out SPAM. D'oh. I helped them do the usual fixes: update WordPress and plugins, change passwords, and double check the security scanner they had in place to see if there were any other know issues.

While poking around for a possible lead to the cause of their issue I came across this post: Tracing Spam from PHP Scripts. The very short version of the post is this:

If you set mail.log in php.ini to a webserver writeable path, all calls to mail(...) will be logged for you.

I set this up and as the author Eric promised, a few hours later I saw entries like these:

mail() on [/var/www/vhosts/somehost.com/wp-content/uploads/2012/07/alias.php:2]: \
  To: xxx@yahoo.com -- Headers: From: "XXX XXX"  ... \
  Content-Type: text/html; charset="iso-8859-1"  Content-Transfer-Encoding: 8bit

And just like that, I knew where to find the malicious script in question. A quick search under uploads yielded 3 .php files, all filled with malicious code.

This Whack-a-Mole approach, of course, isn't sustainable long term. I've already suggested that this organization sign up with sucuri, as I've had great success in having them finding and fixing WordPress issues (one memorable occasion happened on Christmas Day, no less). But to actually witness this attack in action is pretty sweet; and all through a simple config file tweak no less.

mail.log is definitely my new SPAM stopping best friend.

2 comments:

  1. How did those malicious scripts end up in the upload directory?

    ReplyDelete
  2. > How did those malicious scripts end up in the upload directory?

    I don't have a specific answer. I suppose the generic answer is that it's a security glitch in either WordPress or one of the plugins the site was using.

    Scary, right?!

    ReplyDelete