Saturday, September 21, 2013

MMD-0006-2013 - Rogue 302-Redirector "Cushion Attack", an attempt to evade IDS/IPS

This is a quick post, of current on going web-driven malicious web traffic redirection threat with high possibility to malware infection. I was supervising some surveillance operations for one and a half month straight so I probably don't know recent progress whether any researchers already cover this, but since there many links for this threat raising up now, I dare myself peeling & exposing this threat for the awareness purpose. For the IDS/IPS industry this reading is a must read, for I am sure there is no coincidence regarding to this new phenomena in web threat.

It's all started from an "Angel" (thank you so much!) who hinted me with the bunch of interesting URLs:

Since there is a possibility the hash will change, so practically it can be described with the regex below:

For confirming the regex above and the result, you can check it out in the URLQuery (w/thanks friends, can't research this well without your site!) in-->HERE

Seeing the url status, some of them are cleaned up stuffs (which is VERY GOOD), so I went to the "difficult to cure" sites to check the origin and native of the threat, and found the "alive" redirection base by the fake HTTP 302 redirection as per I captured below:

If we go all the way along with the list, (if the sites are alive) all we will see is the same fake 302 pages with redirection via their each link, deeper investigation confirming me these are URL redirectors with what looks like a given exact condition.
The challenge came by when you trace them one by one... here we go:

Threat Explanation

If you see in the picture about the one with the end page of kee.php is a CookieBomb threat, which can be set to go anywhere, you can see our previous post of the CookieBomb-->HERE, kindly bear me not to explain it further here.

One of the URL made be bump straight ahead to the RedKit URL:

One link I trace activating the "like" script in facebook account implanted in a RBN domain, a highly suspicious domain:

With the script linked to PNG facebook icon downloaded below:

One request I followed redirect me into a TDS scheme that forwarding and forwarding me until ending up in Ukraine "hosting service" site (to make it short. I cut some http conversation)

And so on..

What are these? What's the purpose?

Is not easy to explain this threat, I checked around 60-70 urls just now, come into a conclusion that these are a cushion that is used for evade web filtration/URL of IDS/IPS alerts for the following web driven attacks designed by the bad actors behind it. By the suspension of the redirection using the URL written in the rogue 302 page, the response from victim; to click the link mentioned to continue the flow of redirection/infection to next hop of the threat's site/URL; is needed.

This new layer made by these rogue 302 redirection will add the link of threat chain, that's why I called it as a new "cushion for the further threat that come along behind it, I made simple graph for better understanding below:

Proof of Concept

I collected/posted myself some urls for investigation of this case, also with other researchers posts also in there, that (again) can be seen in the URLQuery page mentioned above. The screenshot is as follows:

If you see the Alert in IDS/IPS column, it shows the very low detection of these rogue 302 pages, the evading was working as per expected by the scums who's planning these. I call this threat as Rogue "302-Redirectors" (as per it is..*smile*) to be use for the future reference.

If you see the end-point of the redirection and infection that can be caused by this threat, I do not surprise if the CookieBomb, RedKit and Kelihos people is behind this.

The Multiple Redirection Possibility

Speaking of the devil, the CookieBomb & TDS spread to infect Reveton that @kafeine (with thank's so much for the post) mentioned in his blog in-->HERE, contains a video demonstration of the malicious tool used to do mass-hack of exploited sites, code injection and monitoring the implemented TDS spread.

Since we know for sure that the Rogue 302-Redirectors (in short: 302redir) was created by the same actors behind the CookieBomb (and also RedKit EK and Kelihos), and in that video; as per proven in many CookieBomb hacked sites; we will know there is exist the conditional switch to be used to make multiple URL redirection happens.

You can also see in the below snapshot taken during the video running, that two URLs for forward/redirection was burped out via Jabber-base bot used in one thread of an injection scheme, it presents multiple redirection logic exists behind the tools mentioned, pic (click to enlarge):

To PoC the theory of multiple redirection is not so hard once we know how the usual threat of these types works. Our member of the development/coder department is making a very good PoC for the multiple forwarder to be used in Rogue 302 Redirector threat s per below capture:

We are terribly sorry, we can not release the whole PoC code for security reason yet, we promise to relese the code to known researchers only after threat alert level become lower.


These are the samples that I received and analysed, you can view the urls safely here-->HERE

Please be save friends, I hope this short story of awareness helps.



  1. Replies
    1. Yes. no signatures to stop these at the time I posted the blog.

    2. My approach concerning IDS/IPS is to ensure that I pick the cookiebomb js script, since he is always the initiator of the redirection. This means somewhat flexible IDS/IPS rules to pick the long script, whitespaces, loops,splits,etc. This is serious threat and people managing IDS/IPS should thrive to keep their EK sigs tuned.

    3. We will contact other filter sites for the 92bytes redirection blocking

  2. I've been seeing something similar but for index.php followed by a single char var with a 92 byte base64 string. Already some at urlquery with the following search: \/index\.php\?[a-z]\=.{92}$. The response is always 302 to about:blank... Do you have any idea if this is related?

    1. I saw what you meant as per below list, see the similar pattern in each URL?

      2013-09-25 10:54:28 [Germany]
      2013-09-24 15:51:58 [Italy]
      2013-09-23 11:52:25 [United Kingdom]
      2013-09-18 14:25:45 [Germany]
      2013-09-17 14:21:29 [Germany]
      2013-09-16 21:09:43 [Germany]
      2013-09-16 21:07:23 [United Kingdom]
      2013-09-16 19:54:26 [Germany]
      2013-09-15 21:15:32 [Germany]
      2013-09-15 02:31:36 [Germany]

  3. Hola Ricardo.
    This is the "other" Evil PHP infection receipt scheme, yes, the concept is like we have in CookieBomb & 302-redir.
    Checking further, to find that above GET url strings contains similar pattern of "dGltZT0xMzA5M" < this could be a string needed for that Evil PHP to match or a KEY to XOR the next following string (not tested)
    If the condition met then you'll be redirected to somewhere malicious destination, if not the about:blank URL will be burp.
    I saw some pattern of these URL went straight to the FakeAV updates/installer.
    We will check deeper!

    1. Ricardo, various redirection to Blackhole, FakeAV and Zip malware download URL was detected via the URL you mentioned. The IP addresses used is same as CookieBomb ones (hacked sites), so this could be a "shared infrastructure result" between those malware moronz to another.
      Nice finding. A redirector indeed.

    2. I leave here the URLQuery monitoring url for this threat:

  4. Thanks for the follow up! I've been testing two level 1 websites with the cookie bomb js and both are redirecting to the same site ( The argument passed can be decoded from base64 to clear text:
    this is true for all 92 byte argument I've tested so far. Other lengths seem base64 but don't decode to clear text so may be xor'd.

    1. Hello Ricardo,
      Yes, we confirmed it in our side too.
      1) the regex for 92 bit strings are coming via CookieBomb among another redirection
      2) the redirection went to the same destination as targeted by CookieBomb, 302-redirect or, to EK sites (black hole, etc) or other malicious site like FakeAV.

  5. Thank you for this info...

    I think i have this problem since last month a go. And i have to refresh the index of my site every day... but How can stop this?... I´m tired now ...
    If u could check the report
    I will be a very grateful if gime ve a few suggestions for repair this situation, because are out of my control ... thnks so much.

    1. The bad guys are attacking via common PHP / webapp vulnerability and ssh/ftp account, upgrading the webapp and change the username/ passwords of your ssh/ftp might stop it. I you use CMS lik WordPess/Joomla, etc make sure you use the latest one and please avoid using too many plugins.