Some encoding note(s) on modified #CookieBomb attack's obfuscated injection code

We posted the attack related to this injection code in many web pages as per posted here: -->>[previous post], I called this as #CookieBomb attack, it uses the obfuscation JavaScript to burp the hidden redirection via IFRAME and the cookie condition to be used as a ticket for malware infection further maliciousre direction. This post is an additional note of a recent updates of injection code used, as a notice for the adjustment that needed to make for the automation tools on detection related infected sites (if necessary).

Recently I saw a slight modifications for the injected script for infection they use, which I tried to documented in here as per following points.

1. Method of PHP script wrapping

With a simple trick which using PHP script's "echo" command to obfuscate the JavaScript codes wrapped within.

I saw a new infected site with this code like this one, just now, well is is a good gardening shop site, a victim website:

If you see in the infected/hacked site it shows the code" " in the upper left corner of the page, thus in the HTML code you can see the malicious code injected to it. The injected code is having the same pattern of usage of a long long white spaces as a silly attempt o hide it.

The problem is, if you scan as per it is through "known" tools the scanning can not be performed as per it is, i.e.: you'll get the result like this-->>[LINK-1] or this-->>[LINK-2]
which is not showing any malicious detection (except the long white space trails maybe..) Yes this code "currently" can not be scanned in the JavaScript auto decoding tools, and that's what the bad guys wanted it.

So let's take a look closer at the code:

The bad actors is using the JavaScript wrapped in the php command, in this case the echo command, which for the symbol it needs to use the escape character of backslash "\" for the quote sign. This is why the automation can not decode this well, because actually it is in a form of PHP script.

So what are we suppose to overcome this? All we have to do is to remove those characters (I marked those character in the green color) above and you can decode it at will in any JavaScript decoding tools to get the result of the #CookieBomb code as per below:

This scheme will be changed for sure, but don't worry nor afraid of it, because no matter what these bad actors made we shall crack it well. I am sorry for the "light" technicalities I wrote this time, but the impact of this matter is huge and infection is wide, I assume the awareness is necessary. With noted, not only #CookieBomb case, the similar trick can be performed to avoid automation and detection to other malicious obfuscation too.

Samples

I share my decoding note in case you don't want to make risk accessing the infected site I mentioned above in here-->>[SAMPLE].
The password is as usual.

2. Method of mixing hex number

I found the infected sites as per below snapshot:

In the above picture it looks like the usual #CookieBomb obfuscated code, which is not.
My fellow co-workers complaining me that they can not decode this using the automation, which I checked into the Wepawet amd Jsunpack to confirm it as per shown in below:

If you see the code closer you will see the code contains the new trick of obfuscation using the character stated in its hex values as per snipped below:

As you see there are hex of "0x62" and "0xa-02" used in the obfuscation code.

In the first part, you change the hex into its ASCII character and in the second part if you calculate the hex calculation, you can substitute the result directly to the code into:

And you can decode these without problem by your favourite decoder tools, which mine is the "ape" one :-)
The decoded result:

3. Method of string splitting & mixing hex code operation with integer

There is an infected sites which injected by #CookieBomb code as per below:

The code is as per below code and can not be processed in automation tools, the question is why?

If we see it carefully in below marked parts there was a modification:

As per previously explained it used the mixed hex character to replace the real value, but it added string splitting of the hex characters as per seen in line 5. And also noted in the line 32, the condition combined with the hex and integer (0x19==031) and also the subtraction operation of hex with integer stored variable "bv".

Just change the value as per noted with the green color and you can decode into any tools you prefer. PS for spider monkey or rhino simulator this code will run without problem and storing the result instantly.

Below is the decoding result:

4. Method of hiding the "split", a trap & changing hex places

Got another wave of infection coming one of them has this changing, is just like the malware moronz and I are playing a kind of CTF now, OK let's see who will win in the end.. The infected page is up for the research/check purpose:

The code is as per below "format" and the modification spotted I marked as per below in colour. I checked my team's work on these and the common mistakes this time went into the un-necessary changes for the var which is not a hex, here we go:

Well of course after the codes are adjusted you can decode it in anyway you want as per below:
I have a feeling this "note" of changing will be a loong list :-) So be it!

#MalwareMustDie!