Crypto Miners Part 2

As mentioned in our previous blog post, the trend of online cryptocurrency mining is gaining momentum. The potential to mine cryptocurrency on anyone’s’ browser with ease and anonymity attracts website owners as well as threat actors — joining the fruitful mining pool of leading cryptocurrencies.

Machines all over the world mine cryptocurrencies and get nothing out of it

Over the past month, Check Point Threat Intelligence and Research organization has spotted hundreds of websites that have joined the mining trend, knowingly or not, and take advantage of their e-visitors computational power. Among hundreds of mining websites, we have found some that suggested the mining option as an alternative for online advertisements, some even offering some kind of rewards program.

But, as always, threat actors tend to take every new technology and try to monetize it as much as possible. This time is no different. During our investigation, we spotted a large network of compromised websites and malvertising networks that use their resources in order to make an extra buck and mine coins behind the user’s back.

And what concerns us the most is the fact that although it becomes a more popular funding and monetizing vector, the available code used to mine these coins is poorly implemented and exposes the websites’ users to potential risk without their knowledge or consent. Throughout this article, we will expose you to the poor inner working of one of the prominent online miners available today.

Various implementation methods

Roughly speaking, we can divide the websites that run mining processes into two types. The first type runs hidden mining processes without informing their users. Some of those websites are compromised and the mining is done by a 3^rd party, whereas others knowingly injected a cryptocurrency miner into their site. The second type of websites,keeps the website’s users aware of the mining activity.

Interestingly, we encountered sites that allow individuals to be part of the process, by providing the ability to increase and decrease the amount of mining threads.

The cryptocurrency mining action is a computational operation of which a mathematical output is called ‘hash’. As seen below, the site encourages the user to keep the mining process alive by removing some advertisements from the site, when reaching 600K hashes.

It is important to note that although it is advised not to use more than 3 or 4 threads in order to render the user’s machine operable, no limit is enforced.

In case the users decide to leave the site, at their next visit the hashes counter will continue where it left by saving the values in the cookies mechanism.

This technique is also hitting mainstream sites. Recently WordPress, the largest content management system for websites, released a plugin for the CoinHive API. With an estimated 25% of websites worldwide being powered by WordPress, the popularity of this mining method would likely rise too.

As suspected, other variants of JavaScript crypto miners are starting to appear. On the right above we see a page taking advantage of both CoinHive and JseCoin. Both use your CPU and both run similar risks to your machine.

It’s only a matter of time before this method will become completely mainstream.

Currently observed threat actors who started to use CoinHive

Mining for cryptocurrency may be legal,as seen in the above example, and can be thought of as a preferable alternative to annoying advertisements. However, this profitable playground attracts more and more threat actors, who take advantage of these plug-and-play miners and incorporate CoinHive and other similar tools in their operations.

A major actor in adware and unwanted programs distribution, who uses shady or abused Ad Exchanges as a distribution network, started to incorporate CoinHive in  the landing pages that manipulate users to download the adware. The victim is seduced to download a possibly unwanted program with a malicious potential., His processor is compelled to participate in a computing effort that requires power and resource consumption and gains nothing out of it.

For instance, below is a “Flash Video Player” offer, with an attached CoinHive script running in the background.  This time they also chose not to overwhelm the victim’s PC, and only run 3-4 threads simultaneously.

A quick look into the malvertising campaign which refers to the above “Flash Video Player” offer (using VT Graphs):

A malvertising campaign that chooses to redirect traffic to several types of attacks, including a “technical assistance” scam or the download of a potentially unwanted program bundled with mining activity

Poorly Coded Walkthrough – CoinHive Library

The emergence of web crypto miners, especially tools that are loosely coded and poorly implemented, may pose significant danger to online users worldwide.

In this section we’re going to go over some of the dangers of the CoinHive Monero miner, one of the most popular miners today as of its release in September 14, 2017, and the poor code implementation that could expose viewers to denial-of-service attacks.

Input Validation

Checking for reasonable input is always an important part of code. For instance, if someone is asked for their age and they answer with the number 235, that input should not pass input validation. When setting the number of threads to use on the victim’s CPU, one of the few places the mining tool asks for outside input, it does not verify if a legitimate value was provided. So a website owner using CoinHive can choose to use as many threads as they’d like.

The API documentation for thread implementation

We can see above that there is no upper limit to the number of threads that can be created. In the below instance, the script is calling for 100 threads to simultaneously be created and run, which will tax the CPU heavily. On the right side of the image, we can see that indeed, 100 threads were created; with so many threads trying to run, the CPU usage is at 100%.

Whether by mistake or on purpose, a website owner can ignore the recommended thread count as well as not enforce it. This may create problems for the user down the line.

Error Handling

An essential part of any code is deciding how to react when errors come up. :rerun the referring function, refer to an alternative within the code or just kill the process. The choice is up to the programmers.

Above, we can see that the site key – the cryptocurrency ID of the website – is being checked to see if it returns an error. Should an error be given, the script would try to reconnect. Attempting to reconnect isn’t generally an issue, but because the site key would be hard coded into the website, the reconnection will ultimately be futile.

As the site key is hard coded into the website, and if the check throws an error once, it will throw an error every time it is run. It will keep trying to run the site key until a certain hardcoded time. That time is being set to 6 million milliseconds, or in other words 1 hour and 40 minutes.

The biggest issue with these multiple redundant reconnection attempts lies in the way threads are manipulated. When an error message is thrown by the thread, a new one is created in an attempt to reconnect. This level of thread generation can not only tax the CPU, but it can also tax the memory.

As seen above, going over the recommended thread count was able to eat up 4 gigabytes of memory. When this was allowed to continue (and we see it does for 1 hour and 40 minutes) higher thread counts were able to crash the webpage and even the browser.

Through various efforts, we’ve seen how dangerous these injected scripts can be. If using up one’s CPU wasn’t bad enough, the poor implementation leads to other problems. Lack of input validation can negatively affect the user’s CPU. Poor error handling results in near infinite loops being created. And finally, all these can open up users to DOS attacks.

Is it worth it?

Let’s assume that a single actor runs a large-scale operation, as part of which at every single moment some 1,000 users are viewing its mining pages that includes the CoinHive script.

An average PC can calculate around 45 hashes per second, using 4 browser threads.

Assuming the latest Monero network stats:

Monero Hashrate: 266.122 Mh/s (current worldwide mining power)

A new block is created every 2 minutes in average. (720 blocks per day)

Reward per block is 6.2 XMR.

1 XMR = 88.46$

Every day 4464 XMR worth of blocks are created (720*6.2)

One’s relative contribution to the network’s hashrate is 0.0000000169095 (45/266.12M)

So we will receive 0.000754 XMR daily, per user.

And for 1000 users, for 30 days: (1000*30*0.000754) = 22.62 XMR

In dollars: 2001 USD    (22.62*88.46)

So,our threat actor will get a monthly revenue of $2,398, without much needed effort.

Effect on the Monero network

At first, some have speculated that the addition of a large computation power like CoinHive would make it harder to mine Monero, and as a result the profit from such online mining operations would drive down.

If we take the PirateBay’s use of CoinHive as a pivoting point, which triggered a large scale adaptation of online crypto mining starting mid-September 2017, we can observe in the following graph that the total effect on Monero hash rate is minimal, and that mining difficultly would remain unchanged.

To conclude, as Cryptocurrency mining with CoinHive and other injected scripts becomes more popular, users should be aware of the threats it creates. Aside from damaging their machines, users put themselves at risk for DOS attacks and additional injected code. It will become ever more necessary to ensure that users are protected from such attempts.