Major malicious redirections affecting WordPress sites were detected during Jan/Feb 2016 (Ongoing). Potech Consulting discovered a new variation of this infection, this article describes its new characteristics.
If you’re not a techie, you need to know that visiting some of your favorite blogs and sites might infect your system with a "Ransomware", in other words, a malware that locks your files/system and asks for money. You need to be safe click here.
It is believed these redirections landed users on ad sites, then forced their traffic to servers hosting the Nuclear Exploit Kit, to infect victim’s devices with ransomware. The Nuclear Exploit Kit targets then vulnerabilities in Adobe Flash Player, Adobe Reader / Acrobat, Internet Explorer, Silverlight. After being exploited, the victim’s system is infected with the TeslaCrypt ransomware.
Wordpress Ransomware LightSpeed Metamorphosis
Furthermore, the js infections enlarged their attack surface by not only targeting outdated [Flash, IE] clichés, but included old-school Trojans (asking to be installed) to infect updated browsers too.
A New JS Pattern:
One of the new injected code in WordPress sites comes with:
- An “eval” js function (figure 2)
- A couple of encrypted and encoded HTML divs (figure 3 and 5).
Its shape and content has changed since the last wave of articles uncovered its first form.
In the above figure, the scattered variables are filled with Hex content, and are evaluated at the end of the script. The Hex decoding of these leads to the following code.
This snippet decodes (again) the contents of the following HTML element included in the page.
This code checks the User Agent (specifically IE – figure 4) and decrypts the content of the following HTML element: (again)
Finally, the payload will include our long awaited iframe, and a cookie that expires in a week, instead of a day (previous versions of the infection).
The malicious iframe URLs are in constant change, a bit similar to Sucuri’s and Heimdalsecurity posts, but now it is changing its GET variables, paths, domains, and sub-domains more frequently. Here’s a few patterns:
- http://pistonggeaesten.autoinsuranceprice.us/forums/viewtopic.php?t=9z4f &f=6p9478318j02y151wr2 (outdated)
- http://sageniti-rogamusque.brothersrunning.com/boards/viewforum.php?f=33.o &sid=0702988ti2064z7bz97d5 (outdated)
- http://batchdelaysostenedor.<legitwebsite>.com/boards/index.php?PHPSESSID=42125 &action=8p54671ag2l00ko30773
- http://ploertinnen.orlandoirrigationsystem.com/forums/index.php?PHPSESSID=764&action=6q.z65hta4u1050 (outdated)
What is critical now is that the malicious sites are using less suspicious domains, they are relying more on third level domains infecting legitimate second level domains as mentioned by Sucuri, to be immune to blocking.
As mentioned at the beginning the scripts are now adding classic Trojans, and not only relying on Flash, Adobe, IE vulnerabilities.
In less than an hour the same site redirected our requests to 5 different URLs on sandboxed machines. One of them infected a machine with TeslaCrypt “.micro”, while the second infected it with the TeslaCrypt “.mp3” variant. One crashed our Java JRE, and the other crashed our Internet Explorer.
One particular site attempted to infect our machine with a known Trojan, redirecting our requests to http://www.download.windowsupdate.com trying to download from the site the following files:
Hence the infection is trying to widen its attack surface beyond obsolete technologies, now that the update culture is being spread intensely.
Detection and Remedial
Then a classic grep/sed on your server, depending on the signature, will get you infected scripts.
As for backdoors, due to their variety, it will be time consuming to search for infected php files.
You can go old school grepping base64 decoder, or scanning using third party tools, but we would recommend to ban access to all unneeded php files in the first place stopping the bleeding:
- Configure your htaccess to whitelist access to only needed pages, css, js and media. All internal php files must not be accessed through web (web-config.php etc).
- Disable all php system access functions exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source (as much as you can)
- Disable write permissions even for owners (your cache and temporary files can wait)
For Administrators and Webmasters
After the first step (if included), you will have more time to choose your favorite WordPress recovery procedure.
Other than that you can apply remaining hardening procedures published on the WordPress official website.
For end users
Update / disable flash, update Adobe Reader, update your Browsers, don’t use IE.
By Jean S, Elie Z
Elie is the Head of Application and Database security at Potech Consulting, he is passionate about secure coding and guitars.
Jean is the Head of System and Network security at Potech Consulting, he is passionate about root access and cars.