Viagra Links In WordPress Posts

Get via App Store Read this post in our app!
Tips for finding SPAM links injected into the_content.
I’m working on a client’s site and I noticed that posts have a hidden <div> filled to SPAM links to dick pills, etc. Hoping to get lucky, I searched for some of the keywords in the database tables, but found no matches. I also searched the code in all the files, and also found no matches.
I know that WordPress hacks can be very tricky to remove, and they go to great lengths to make them hard to find. But perhaps there are some “usual suspects” that I could check, or maybe some tell-tale signs I could look for.
I’m not asking for anyone to solve this specific hack. I’m just looking for advice on where (in general) to look.
In case it’s useful, here’s the unauthorized <div> which is injected right before the close of the first <\p> :
I won’t repeat any of the good advice in Squish’s answer. You should also read this article on WordPress security. I’m just going to cover the specifics of what I learned from my episode.
Basically, the attacker slips a bunch of hidden links into the content so humans can’t see them but google can. So they use unsuspecting sites to drum up back links to shady sites.
It’s hard to say for sure how this was done, but in this site there were two known security vulnerabilities:
admin user was still in use (you should delete/rename the admin user). Outdated plugins and core.
In my case, the infected file was my theme’s functions.php file. At the very top was this:
Notice how it’s cleverly named to look like typical WordPress stuff.
I’m not going to walk through all the code, but basically it’s a bunch of base64_encode ed code as a reversed string. The strrev() makes it hard to find the two biggest red flags here: base64_encode and eval . The un-obfuscated code is included below, but here are my biggest takeaways (in addition to what Squish said):
Be on the look-out for eval and base64_decode , but also look for their reversed equivalents: lave and edoced_46esab Also look for instances of strrev . There are few legitimate uses of all of these in the WP core which will return false positives, but not so many that you can’t scrutinize each one. In my case, the hack doesn’t appear for logged in users (It checks client’s cookies), so don’t let that throw you off. It’s a clever twist to confuse the users who are most likely to be looking for it.
Good night and good luck.
The un-obfuscated code turns out to be this:
In general, the best place to look is in your theme folders, specifically the main theme and in the index.php file. Then the footer and header files.
Also, check your modified dates and start with the most recently modified. Especially if there are several that were all modified around the same date/time.
I’ve seen, and had to fix, this problem several times on people’s servers. The false data is normally loaded via a script inserted into the php files of the template.
Common entry points for gaining the “access” required to pull the injection off are outdated themes and/or plugins. It’s best to run production servers with only the one active theme on the server, as well as removing unused plugins and replacing outdated active plugins.
There are a few scripts out there that you can upload to your server to help you find infected files so you can replace, clean or delete them. (Links listed below)
Again, try looking at file modified dates and check out ones you haven’t modified/installed recently yet have a recent date on the.