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
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]
So let's take a look closer at the code:
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.
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!