An investigation by analysts at Sucuri into malware found on WordPress installations revealed a much larger and ongoing campaign that last month, we’re told, hijacked more than 6,600 websites. The team has seen a spike in complaints this month related to the intrusions, according to analyst Krasimir Konov.
Just when you thought you found a somewhat stable platform, assholes have to come and screw it because they can.
“As new vulnerabilities in WordPress plugins are discovered, we anticipate that they will be caught up in the massive ongoing redirect campaign sending unsuspecting victims to fraudulent websites and tech support scams,” they wrote.
Basically, we are far from over.
Update from AWA.
Yes, it looks like this is a description of what was happening to the site. To me, the more interesting part is how they kept coming back to try different methods.
The first three methods did not match the article given. The last one produced results that are the same as what the article suggests.
They have since moved to encoding strings in the path of code execution. So they have a bunch of small arbitrary strings and then combine them to create an actual program. Consider “a quick brown fox jumped over the lazy dog”. From this one string you can pull ‘h’ from “the”, ‘t’ from “the”, “p” from “jumped” and so on. You can construct any set of words this way. They use this method to hide what their true intentions are.
What makes the newest attack vector so insidious is that the first URL used looks like it should belong. Did Miguel actually want to use the emojii package from legendarytable? If so there is no reason to be suspicious of this URL being called. And because emojii code is pretty complex and dispicable to begin with, having another source of emojii isn’t a concern. It is only when it is discovered that legendarytable is calling drakefollow that things start to get suspicious. Again, the name isn’t completely unreasonable. It is only when drakefollow randomly forwards your browser that you realize that it is malicious.
This meant that we had to track down the legendarytable reference. It didn’t appear anywhere in the code. Our lock down functioned as expected regarding that. The means it must be in the database. We searched every record of the database until we found a reference. That told us where to look. Once we discovered what was in the database and where it was in the database we wrote some custom code to remove it from the database.
This means that the site is safe for the time being. We are using more and different tools to help keep it safe.
Thank you to all of our readers that sent in error reports with screen shots. Thank you for the reader that sent in the link to the article. And thank you to all our readers that sent in suggested WordPress plugins to help protect the site.