The following screenshot shows the code that we received:
As can be observed, the encoded text on line 58 is stored as a string and is passed as a parameter to what appears to be the decoding function defined on line 3. The decoded output is executed with the
eval() call on line 2.
eval() call will evaluate whatever is returned by the function that is defined inside the call. The function returns the decoded string on line 57. This is where we can intercept the execution flow and have a look at what is to be evaluated after the decoding function. We simply replace the return call with
console.log(), save and run the script. Now we will see the decoded code printed out to console. Checking the console, I got the following output:
More obfuscated code! Analyzing we can see that
_$_f4ea array, and then merge them together manually.
The final result looks, like this:
Now we can see a clear picture of what is really going on. Lets quickly review it line by line.
The first two lines define the iframe variable and the
inCode that will later be injected into the URL that was previously identified. Lines 4-10 set iframe parameters and append it to the HTML document. Here we can see that
inCode is injected into the
css parameter in the URL passed to
f.src. Upon further investigation it became evident that this website is suffering from an HTML injection vulnerability that allows malicious actors to inject arbitrary code, and more importantly have HTTP requests appear as if coming from the website itself. This is the core of the exploit. The vulnerable website is hosted in Spain. The attackers were routing all their ad traffic though this vulnerable website, thereby converting all their traffic to Spanish traffic, and finally sending it to the ad tracker that we previously identified.
It appears that the purpose of this exploit was to illegitimately augment Spanish traffic volume and get higher payouts by country. This of course led to the campaign being banned on our partner’s network.