link-template.php.suspected part II

Hi Mary,

I have been working on a remediation for this hack and am gathering data to figure out the root cause. I am documenting here: [link moderated – keep support on this site Forum Rules. Please contact me via that page and I would be more than happy to help you resolve your issue.

Anybody else that comes across this–please feel free to do the same.

Will do, and thank you @imdevin567

meanwhile, if I find something else that can help I’ll post it here.

Got again my websites down, then when I did the wordpress reinstall got another error, this times pointing something about the Jetpack plugin.

So I changed the plugin folder name via FTP and my website is now available.

This is getting very frustrating, having to do a fresh reinstall every day is just annoying.

I am thinking of migrating to another server, since one of my websites is hosted with another provider and works just fine. But I am afraid that doing so won’t solve anything since maybe the real problem is deep in some content file.

What do you think? migrating only the content and leaving behind plugins and theme would fix it for real?

@mary – If a fresh reinstall is not working, then the malware is residing somewhere outside of the parts you are modifying. Do you have multiple sites running from your account perhaps?

I would check writable folders too; wp-uploads, wp-content/upgrade, etc.

@devin – Did you successfully stop this hack?

I finally got it. In my case the file that was causing the trouble was:
wp-content/plugins/content-aware-sidebars/js/javascript87.php

To catch it, I configured Apache/PHP to include the source code that called the mail function. Then I cleared my spool, and started the sendmail service and then stopped it a few seconds later. I evaluated the messages and it pointed me to this file. I opened up this file and it was all base64 encoded and sending to eval() function. I think that some of those egrep statements should have caught it, but unfortunately they didn’t. I would think any code files in the wp-content folder that had “base64_decode” in it should be carefully evaluated.

I had a night to think on this. I wonder how this file was being executed. Just having a malicious PHP file lying there is not a big deal, but something must have been calling this file in order to execute the code. I’m pulling the HTTP logs to see if there are any requests logged that point to this file. If there are I should be able to locate the IP address of the attacker and block it.

If anyone has interest, I captured a screenshot of this file before I smoked it.

So for those interested… here are the first few lines of the files that I found. I’m pretty confident that I’ve stopped this now.

function ....

[moderated – don’t post hacking code here

Each time the attack happens, the files use different arbitrary variable names, but the basic structure is exactly the same. I was unable to come up with the exact reason that these files were being deposited on my server. I ran through and applied 755 and 644 permissions. Then I walked through a series of steps to lock down WordPress. These steps were posted in an earlier post. If I were better at GREP I might be able to craft some sort of statement to better locate these files. Maybe someone can use the example above to create the right GREP statement.

Hope this helps