HackDig : Dig high-quality web security articles for hackers

Rotating Iframe URLs – One a Minute

2014-08-15 20:40

Earlier this week, Sucuri wrote about auto generated iframes in hacked WordPress blogs. The malicious PHP code fetched the iframe URLs from a remote server (hxxp://82 .200 .204 .151/config.inc.php) on-the-fly every time someone loaded infected web pages. This trick helped regularly update the malicious URLs without having to change the code on each hacked site individually. All the URLs had the same format http://<domain-of-a-hacked -site.com>/news/faults-ending.php. For example, hxxp://brewerstire .com/news/faults-ending.php .

This reminded me of another ongoing attack that also rotates iframe URLs in a similar way. However it has some distinguishing features that make it worth it to describe it separately.

Disclaimer: I still haven’t had access to websites affected by this hack and didn’t see the actual malicious code, but I have enough details that I managed to get as an external observer to speculate about what’s going on.


1. This hack affects all sorts of PHP sites. Most of the sites I checked were Joomla and WordPress sites.

2. There is a malicious iframe code at the very top of the HTML code of infected web pages.

<i f r a m e src="hxxp://<malicious URL>" width=1 height=1 style="visibility: hidden"></i f r a m e>

3. The iframe URL changes much more often then in the case described by Sucuri. It changes every minute! Actually this attack rotates a long list of URLs and roughly in two hours you begin to notice repetitions.

4. The iframe URLs conform to patterns that your can easily spot if you see a few URLs. Every few days the pattern changes. The current pattern is: http://<domain-of-a-hacked-site>/templates/system/index.php. For example:

hxxp://www .exileskimboards .com/templates/system/index.php
hxxp://www .granvillesoccer .com .au/templates/system/index.php
hxxp://www .bonabejadid .ir/templates/system/index.php
hxxp://www .dijonpoker .fr/templates/system/index.php
hxxp://rcouncil.rmutr .ac .th/templates/system/index.php
hxxp://www .tvstein .ch/templates/system/index.php

my list of 119 URLs can be found on pastebin.

Before that I saw: http://<domain-of-a-hacked-site>/<7-random-characters>.php.

hxxp://reneks .com .tr/yrdoter.php
hxxp://yatginkumlama .com/dlagphi.php
hxxp://vardarlarmutfak .com/qygkmfd.php
hxxp://genckoltukdoseme .com/whdkrmv.php
hxxp://oppoportal .com/ywdvbnk.php
hxxp://profiaudio .com .pl/xbiwspk.php
hxxp://targetedasia .com/rgrmvmh.php
hxxp://web429 .webclient2 .de/uqevulx.php

my incomplete list of 41 URLs can be found on pastebin.

Update (May 23rd, 2013): New list of 105 iframe URLs.

and http://<domain-of-a-hacked-site>/<path>/<subdir>/<subdir>.php.

hxxp://bugs4u .info/forum/downloads/monthly_06_2012/monthly_06_2012.php
hxxp://www .funfiles .cc/deliveryairport/deliveryairport.php
hxxp://www .svendborgfrivilligraad .dk/themes/Phos/forum/green/green.php
hxxp://www .lt90 .org/upload_files/now/nata/nata.php
hxxp://graf-pokrishkin .ru/temp/4183![barum]/4183![barum].php
hxxp://jivdom .info/forum/admin/applications_addon/ips/blog/setup/versions/upg_10003/upg_10003.php
hxxp://www .goduk1apt .com/elephantcablegrahamcooper/elephantcablegrahamcooper .php

my short list of 18 URLs can be found on pastebin.

5. The iframe is being injected only if visitors come from search engines and don’t use known IPs of search engine crawlers.

6. The iframe is being injected for all types of requests that contain eligible referrer headers. I.e. not only into web pages (content type text/html) but into any other requested resource: *.js, *.css, *.jpg, *.png, etc. and even “404 Not found” error pages. All the infected responses have the text/html content type, regardless of the type of the resource being requested, their status code is 200 (even for non-existen pages whose content say “404 not found”), and they have the X-Powered-By: PHP headers even for static files.

7. The malicious code seems to be buggy and on some sites it generates the “500 Internal Server Error“.

What’s going on?

Now let me speculate about what’s going on.

1. When the iframes are injected into static resources, such as images, we see the extra X-Powered-By: PHP HTTP header. This means that some PHP script is responsible for this iframe injection.

2. Since the iframe HTML code is being injected even into static resources that should not be processed by PHP (e.g. images, CSS, JS ), which is clearly a bug, this means that the malicious PHP code starts working before web server touches any legitimate files. But if requests lacks a search engine referrer, then the same static files are being processed directly (no X-Powered-By: PHP header and correct Content-Type) Therefore, we can suggest that it’s either something that’s working on the server level or something that has changed the site configuration.

3. This is not a server-wide infection. I checked other sites that share the same servers with the infected sites. They didn’t exhibit the same malicious behavior.

4. So it must be some site configuration modification. Since the malicious behavior relies on the Referrer header, I guess it is done using a set of ModRewrite rules in .htaccess file that redirect all incoming requests with eligible referrers (search engines and, maybe, social networks) to some PHP script hidden somewhere on the server, providing it with the originally requested URL as a parameter.

Malicious script

Here’s how such a script can work:

1. Get the URL requested by a visitor (passed as a parameter by the ModRewrite rule) and either fetch it directly, or make a roundtrip to a remote server that will fetch it and return the content (like in the scenario I described in my previous post).

2. Then check the visitors IP. If it is not in a known range of IPs belonging to search engines and security companies, then inject the iframe code at the very top of the fetched “page” content and return it back to user. Otherwise return the unmodified content. If the original URLs are being fetched by a remote server then the iframe code could be injected by that remote server too (and in this case skip the following points about the iframe generation)

Iframe generation

So how does the script change the iframe URLs (in case the iframe code is being generated by that script)? I’ve seen other attacks that use the following two tricks that can help accomplish this task:

  1. There is a list of iframe URL saved somewhere on the server: either hard-coded in that script or in some standalone file. For example, I’ve seen an attack that used the log1.txt file in the /.logs/ subdirectory to store a list of malicious URLs that it used for script injections. In this case, hackers need to upload a new list to all the infected sites when they want to use a new list of URLs (and we know they changed their lists at least three times.)
  2. As in the Sucuri’s example, the malicious script can simply request an iframe URL from a remote server on every load. In this case hackers don’t even need to update anything on the infected sites since they can manage URL lists centrally on their own server. Something tells me this variant is more plausible.

Iframe URLs

I normally focus on infected websites and don’t analyze malicious URLs. However in this case the malicious URLs clearly belong to other infected sites and can add some interesting details to this story.

The “/templates/system/index.php” pattern in the malicious iframe URLs suggests that all those sites are powered by Joomla. So they currently use a batch of about 120 URLs that all point to an index.php file in the system template of Joomla. I guess, those sites all had been hacked using a brute force attack on the Joomla login form, followed by malicious code injection into template files using the access to Joomla admin interface. (Many people have been talking about distributed WordPress brute force attacks lately, but you should not forget that similarly massive attacks are being targeted at Joomla too. I constantly come across their traces in logs of Joomla site I work with.)

But wait, if we take a look at other lists of iframe URLs with the “7-random-characters.php” and “subdir/subdir.php” patterns, we’ll see a different picture. You won’t see many Joomla sites there. Sites in those two lists are very heterogeneous: pure html, forums, Drupal, and even ASP.NET sites on IIS servers (although PHP was installed on those IIS servers). In my experience, such lists of hacked sites could be compiled as a result of attacks that steal FTP credentials from computers of their webmasters.

It looks like the gang that injects the iframes simply sells the traffic to another gang that provides them with the lists of URLs, or they manage several different attacks at the same time.

302 redirects

What does those iframes URLs point at? They actually do a 302 redirect to malicious resources that try to attack visitors’ computers using known vulnerabilities in browser plugins. At this point the malware looks for the following exploitable plugins: Adobe Reader, Java, Flash, Quick Time, Real Player, Shockwave, Silverlight, VLC and Windows Media Player. The page with the exploit tracks visitors’ IPs and will return the “404 not found” errors to returning visitors.

The redirect URLs synchronously change for every iframe URL (even for those with older URL patterns that are no longer in use) every minute. This proves that the redirect rules are not something static (like typical .htaccess redirects). They have a dynamic nature and should be handled by the PHP scripts themselves. Most likely they request the redirect URLs on-the-fly from a remote server (maybe the same that provided the iframe URLs).

The redirect URLs have a peculiar format:

hxxp://425roads .info/lilkohlbmxuh?fbeesiwtyf=518675
hxxp://425roads .net/lkqlgchu?flufewmrivlx=5186751
hxxp://425roads .org/lxqccnycjhsk?fctpmn=5186751
hxxp://averbolados .info:8000/lpdqh?fphxrvpdkck=9840870
hxxp://bigger-joy .org/lshsxkmci?fbeyn=5186751
hxxp://boxingplaces .org/lvfhilo?fmirinlsugbe=5186751
hxxp://cycling-infos .com:8000/lcrchcvcup?fpepbmtgcmb=5186751
hxxp://fiveandsixandseven .net:8000/lyyykbjynbnffo?ftegbdf=5186751
hxxp://germaindusant .net/llsjbcf?fqreotff=9840870
hxxp://jab-servers .com:8000/lesxcc?fidkdgljbty=5186751
hxxp://kinder-world .net/lkhlsxdqht?fjnuvip=9840870
hxxp://muscle-guys .info/lxwhcuxtwd?fqwscf=9840870
hxxp://mutauga .com/lhpejsgylf?fccgtqqorxt=5186751
hxxp://niria-coperta .org/ltjqv?fowcqxxui=5186751
hxxp://paris-online-guide .net:8000/lwjmlup?fmckhkdjyi=5186751
hxxp://pizza-recipes .de/lflpwvtkctoogi?foseyilcyx=5186751
hxxp://rotatethespin .org:8000/lduxhuqilciol?frvwbkq=9840870
hxxp://runthepig .info/lecqvmgugipdfd?fkrhcrk=5186751
hxxp://shinebaby .info:8000/lqfgmgbdxpboo?fjbdmdikp=5186751
hxxp://sortebmul .com/lqlchhsovktcld?fsosbn=9840870
hxxp://threehundredfortyone .net/liuecopx?fupctdcfmmg=9840870
hxxp://ufoarea51 .net/lfgeiytb?fesbqkwc=9840870
hxxp://underwater-house .com/lehcgcoswufitb?fkbdbqmemm=5186751
hxxp://urgentmathcourses .org/llgsigdse?flvqjtsgb=9840870

While the domain names change several times a day, the query part of the URLs changes every minute. Its numeric part remains the same though. At this point I noticed only two variants: 9840870 and 5186750. Not sure what they mean. Probably some IDs. You can use them to find even more malicious redirect URLs using the urlquery.net‘s search tool: 5186751 and 9840870.

Malicious domains

When I got a first few redirect URLs, I thought they also belonged to hacked sites. There was no pattern in domain names, they all were quite meaningful (e.g. underwater-house .com or pizza-recipes .de), they belonged to multiple TDLs (.com, .net, .org, .info, .de) and pointed to multiple different IPs all over the world. However the root levels of those sites were empty, so I decided to take a look at their WHOIS records.

It turns out that all those domains (a couple of hundred) are less than a month old and each of them were registered using the united-domains.de service by a half-dozen “persons” (most likely fake) just hours before the attackers began to use them. Now it’s clear that they were specifically registered for this attack (probably using fake identities and stolen credit card details). I won’t be surprised if they also used the United Domains’ reselling program’s API to automate the process (I’ve blogged about this approach last year).

Pwnd servers

Then I checked the servers. It appeared they all were dedicated or virtual private servers with a few legitimate sites (usually from one to ten sites). One more detail. The HTTP headers of the malicious content show that it’s being served by Nginx web server. You might also have noticed that many redirect URLs point to port 8000. I checked several servers and figured out that this happens when server owners have Apache working on port 80. In this case hackers install Nginx on port 8000 and serve the malicious content off of it. Thus, the need to specify the port for URLs on such servers. But if Nginx was initially installed and working on port 80, then hackers only needed to configure new virtual hosts for their own domains and didn’t have to add port to their URLs.

The only plausible explanation is that all these servers are hacked at a root level.

Here’s the list of compromised servers (one of them is on the network of Linode, but I’m sure it’s not related to their recent security incident):

Missing links

At this point I don’t have definite answers to a few questions to complete this investigation. I hope that fellow researchers and webmasters of the hacked site will be able to help me.

  1. How exactly do hackers break into websites to place the iframe code there?
  2. How exactly does that code work? You can post the malicious code on pastebin or contact me and send the files.
  3. How exactly were the sites hosting the iframe URLs hacked?
  4. What is the malicious nginx setup on the compromised servers and how did the attackers gain root access there?

To webmasters

Meanwhile, some general advice to webmasters of compromised sites.

  1. Check the .htaccess file for unwanted rules. Note, the malicious code can be hidden below a few screens of empty lines. There can also be a .htaccess file above the site root level that you should also check.
  2. Scan your server for any new or modified files. It’s always good to use some integrity or version control system which greatly facilitate this task.
  3. It’s always a good idea to change all passwords when your site is compromised. In this particular case I see some signs (not proved yet) of attacks that either brute-force or steal passwords, so changing passwords is a must.
    • Your FTP credentials could be stolen from your PC. Many trojans can easily extract your passwords if you save them in FTP clients. Specialized password manager programs or services (e.g. KeePass, LastPass) are much more suitable solution if you don’t want to memorize your passwords.
    • If you use web applications with admin interface, such as WordPress or Joomla, then you should never use default names of administrator users (e.g. admin, administrator, root). Create a new user with admin permissions and delete the default admin. And don’t forget about strong passwords.

Questions and comments are welcome.

Related posts:

Source: /etunim-a-eno-slru-emarfi-gnitator/11/50/3102/moc.setisarapksamnu.golb

Read:18803 | Comments:0 | Tags:Website exploits htaccess iframe Joomla nginx redirects Unit

“Rotating Iframe URLs – One a Minute”0 Comments

Submit A Comment



Blog :

Verification Code:


Tag Cloud