Cookie Consent Script Used to Distribute Malware

Cookie Consent Script Used to Distribute Malware

Most websites today use cookies. Since May 25th, 2018, all websites that do business in the European Union (EU) had to make some changes to be compliant with the EU General Data Protection Regulation (GDPR). Even though cookie usage is mentioned only once in GDPR, any organization utilizing them to track users’ browsing activity have had to add a warning about how they are using them and ask for the user consent.

GDPR and Cookie Consent

Here is Recital 30 of GDPR:

Natural persons may be associated with online identifiers […] such as internet protocol addresses, cookie identifiers or other identifiers […]. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

Cookie consent laws are not new with GDPR. They have actually been around since 2014 when the EU implemented them. Canada’s Anti-Spam Law (CASL) also requires websites to use cookie consents.

Nevertheless, cookie consents became more popular after the widespread GDPR laws in the EU took effect. This has caused many website owners to look for an easy way to implement cookie consents.

We have recently found a website using JavaScript from cookiescript[.]info to display a cookie consent request. When visiting the website for the first time via Chrome, you would get a JavaScript alert like this:

“Your computer is infected. You have to check it with antivirus.”

If you click Cancel or OK, you are redirected to a website that tries to convince you to buy an antivirus software which could actually be malware.

Malware Distribution to Unsuspecting Users

It looks like the website cookiescript.info is the one distributing malware to unsuspecting users.

The malware we caught attempted to load JavaScript from here:

cdn.front[.]to/libs/cookieconsent.min.4.js

That link just redirects to this URL:

hxxp://cdn[.]cookiescript[.]info/libs/cookiescript.min.js

Here’s some of the code inside this JavaScript:

As you can see, the code is loading some additional JavaScript:

“hxxp://cdn[.]cookiescript[.]info/libs/detect_ga.js”

This JavaScript is responsible for detecting the user agent and for attaching the cookie to a browser.

Here is some of the code:

Finally, when the code gets loaded, it shows the alert message we mentioned above. It also comes with the code responsible for the redirect to the malicious website which tries to sell an antivirus software:

hxxp://jsserver[.]info/alert.php

You can see the code here:

How the Website Hides its IP

The website cookiescript.info appears to be using Cloudflare to hide its IP addresses. It is valid to note, some companies that register and maintain domain names have had issues in finalizing their models for compliance with GDPR.

It is not easy to find out who owns this website. However, after some more digging, more details were found:

cookiescript[.]info. 86399 IN NS fred.ns.cloudflare.com.
cookiescript[.]info. 86399 IN NS mia.ns.cloudflare.com.

It appears that cookie-consent.org and front.to are also part of the same network. Some evidence suggests that the malware has been operating for a few months already.

Why do Hackers Hide Malware in a Cookie Consent Script?

After GDPR was enacted, many website owners were looking for an easy way to implement the changes to be GDPR compliant. Some webmasters turned to services that offered to display a cookie consent notice on their website through a simple JavaScript add-on.

Unfortunately, many website owners do not check the code they are adding to the website. This is a prime opportunity for hackers to trick website owners to add the malicious code onto their own website. It’s possible that initially, the code was benign and that the hackers were just waiting for a large number of websites to add it so they could modify the code and infect all of the websites at once.

Conclusion

We highly recommend inspecting any code before adding it to your website. It’s always best for you to host the entire code on your own server instead of hosting it in an external website which can be compromised or simply owned by malicious users.

If you want to make sure your website is protected, we suggest that you put it behind a Website Application Firewall (WAF) and that you follow website security good practices.

You May Also Like