Wauna

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

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.

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.

@devin – Did you successfully stop this hack?

Does anyone know how to see what code is filling the mail queues? I have the sendmail service stopped. I can purge the queue, but shortly after turning the service back on, I’ve got 1000’s in there again. They are all created by my apache user. File auditing will only tell me that they were put there by the apache user on _____ date/time. I’d like to come up with a way to determine what code is putting them there. Any advice would be warmly welcomed.

So, changing the file permissions on link-template.php definitely seems to have kept my site up now. It doesn’t remove the infected code, but it does mean that my site visitors aren’t faced with a glaring problem.

Update Day 3: I worked on this late into the night. I had an idea just before I ran out of gas. I removed file permissions to rename that file in hopes of causing the offending code to pop an error and show me who it is. So far today my site is still up, and I am now hunting through the logs to see if I can locate the bad code. As one person said, this is just a bandage not a fix. I also found some interesting POST code in my logs, that I’m evaluating. I’m getting external “POSTS” that are calling wp_cron.php, which is a scheduling or job tool.

It’s hard to tell if this is related or not, but Devin mentioned how this hack seems to be targeting mail. I confirmed that my install was also abusing mail. I was able to catch these emails in my logs and can see that it’s being sent from a file named plugin.php. I searched my install and only found three files with this name. Unfortunately it looks like these are standard wordpress files. I’m going to download a fresh copy and compare to what I’ve got now.

The three files that turned up for me are:
./wp-includes/plugin.php
./wp-admin/includes/plugin.php
./wp-content/plugins/woocommerce-dynamic-pricing-exclusions/plugin.php

Maybe that will provide someone else a lead.

I spent the entire day working on this, and ended up no-where. I tried the eGrep cmds listed in the other thread and no luck. I went back down a few minutes ago. I’ve shut down the sendmail, so no bad emails are going out right now. I removed the files in the root of my app and still nothing. Since the occurrence seems almost timed, I checked my CRON jobs to see if anything was coming up there, and all looked okay. I reviewed my .htaccess and nothing other than standard stuff. I’m at a loss for what to try. We’ve installed a some of the standard security tools such as Wordfence, iThemeSecurity and a few others. Those are all the things that I’ve tried.

My efforts were not successful. After getting Sendmail service running again, the message queues started filling up with more bad emails. I stopped it, but now need to figure out where they are coming from.

Thanks Joe. I agree that it was resolved somewhat premature.
I had intended to post more of what I found. Once I stopped my Sendmail, I looked in the message queue and found 1000’s of message sitting there waiting to spool. /var/spool/ on my machine. I cleared them all out. I cleared the logs, then restarted the service. It seems that it stopped sending. Previously, sendmail was busy working away. I looked through my root a little closer and found a “files” folder. Inside was a bunch of php files. I also found a zip file in the root of my site. I am locking this down now.

The commands in the previous post did yield quite a few files. I ran the following command to locate any other files that were renamed.
find [path to my site] -name '*.supsected'

I’m still waiting to see if it stopped the problem. Since the file renaming seemed to happen at random times.

I’ll keep you posted.

imdevin567 is correct when he says they are appearing to target mail. I ran the top command and noticed that the sendmail service was bumping to the top almost continuously. I shut down the sendmail service in order to see what happens by issuing the service sendmail stop