CoinHive Bitcoin Mining

Question

2 clients (call them Client R and Client B) reported users of their websites complaining about their anti-viruses detecting a trojan called: CoinHive.js. This seem to be a bitcoin mining malware, that starts threads when a user accesses the website to use processing power and generate bit coin.

After a lot of analysis, and after MalwareBytes (and other anti-malware software) scan returned no virus/trojan hits, we ended up downloading the published websites locally and scanning them with Autopsy.

Client R's website returned various hits. Some were false positives, others were straight and plain, the injected coin mining script. What fixed the issue was manually removing the scripts from the files, and deleting the server cache: C:\Windows\Temp

Client B's website returned no hits. But when entering the website and inspecting element, the bit coin mining script still seems to appear at the bottom of the html markup and our Mcaffee still detects it (for some reason it detects it in Internet explorer but not Chrome???).

We also scanned all other websites on the same server and no other website seems to contain the script: we thought perhaps the fact that Client B's website is infected was due to another website injecting the script into it.

I found 2 tools: Anti Web Miner and No Coin but they both seem to have to do with the client users accessing the website and nothing to do with the hosting server.

Where could the script be injected from? What can we try? Is there some kind of executable or anything else we can look for manually?

Is this what you are looking for: https://arstechnica.com/information-technology/2017/10/a-surge-of-sites-and-apps-are-exhausting-your-cpu-to-mine-cryptocurrency/ ? — Tom K., Nov 17 '17 at 12:51
@Jurgen - There are a huge number of ways attackers can inject a script to your site. You need to find the initial infection vector with some urgency - mining is a lesser concern. If they can control the server they can steal and modify user data. Is all of the server software up to date? — Hector, Nov 17 '17 at 12:57
@Hector do you mean the anti virus software on the server? The malwarebytes, which some articles online said would be able to find and ger rid of the malware, was definitely up to date, but it did not seem to find anything. I can check about the Mcaffee running on the server. Anything else to look for? — Jurgen Cuschieri, Nov 17 '17 at 13:51
Internet-facing devices are definitely scary when it comes to security. If you have McAfee, I'd look into Change Control. That will let you protect your directories where the web pages are and manage changes. That should help protect against the changes to your web pages. Also, especially for web servers, application whitelisting is a good idea. It won't protect against your page being changed, but will protect against unwanted software and scripts being run. — baldPrussian, Nov 17 '17 at 13:56
@JurgenCuschieri - No, I mean you need to find out how the infection got there in the first place. It doesn't matter if software can detect this infection. There is an open hole somewhere which allows anybody to modify the underlying workings of these users websites. Next time they could do something substantially worse than waste a little of the websites users CPU. — Hector, Nov 17 '17 at 14:11
@JurgenCuschieri - Lets put it this way. You have a safe. Somebody broke in and left you a note mocking you. You need to focus on how they broke in, not what the note says before somebody else breaks in and steals all your valuables! You can worry about how they knew your school nickname later once you've fixed the safe. — Hector, Nov 17 '17 at 14:16
I get your point and it makes a lot of sense. However, these particular 2 websites could have easily been infected while still hosted on a different web server. While it makes a lot of sense to protect entry into the server (and I will work on that) what about this particular issue? How can I find what's injecting the script into the Website B at run time, since no "coinhive" scripts seem to actually be present in the published pages? — Jurgen Cuschieri, Nov 17 '17 at 14:21
@JurgenCuschieri - when did they move to the server? The first CoinHive commit was September 15th - meaning unless they moved extremely recently the odds are there is a problem with their current config. As for this infection you've given nowhere near enough detail. What is the full server stack for the application (apache/nginx/IIS/other + version?, PHP/Framework?). And if you load the website what is the full URI that the coinhive script is pulled from? — Hector, Nov 17 '17 at 14:37
@JurgenCusheri - you clearly do not get the point. If you are responsible for removing these scripts then (unless you were specifically contracted to do that only) you have a responsibility to properly investigate how the sites were compromised not conjecture as to what may have happened. You also have a responsibility to mitigate future compromises of the sites. — symcbean, Nov 17 '17 at 14:44
@symcbean Actually, I think you guys cannot get the point. I asked this question specifically about the CoinHive issue. Yes, the entry point is more important than just figuring out anything about CoinHive, but me asking a question about it does not mean that nothing is being done to mitigate possible future compromises of the sites — Jurgen Cuschieri, Nov 17 '17 at 15:08
@Hector I will be updating the question with more information as you requested — Jurgen Cuschieri, Nov 17 '17 at 15:08
@JurgenCuschieri - Unfortunately your question has been put on hold. Try asking another without the wall of text. "How is this malicious script being served" - simply explaining the server architecture, found script locations and called URI. Although you might find it gets moved to another StackExchange. — Hector, Nov 17 '17 at 15:16
No idea what you're talking about: without the wall of text? You say my question is too broad, when the answer you gave me was totally unrelated to the CoinHive issue. I wanted to ask a question about CoinHive: you ranted about how the entry point is more important when you could have simply asked me for more info, waited till I update the question and then provide me with an answer related to my question. Then you put my question on hold while I am getting the requested information in place to update my question to be more detailed :) Very helpful bunch you are! — Jurgen Cuschieri, Nov 17 '17 at 15:21
I agree with the request to break up this question to individual topics, because each served its own purpose. E.g. 1. Risk concern, which you should rebuild your site vs clean up 2. Future mitigation. 3. Coinhive is the least issue here, i.e. when attacker can inject a coinhive script, they can actually inject any other script. — mootmoot, Nov 17 '17 at 16:16
@JurgenCuschieri - I didn't put it on hold. I was one of several users (most having notably more reputation here than I do) that voted for it . The reason being the vast majority of the text is entirely unrelated to what you asked. We volunteer to post here - if you want to order people on what to tell you pay someone. Your post suggests little security knowledge which is why I pushed you towards the underlying issue that allowed this to happen. If you don't fix it it doesn't matter if you stop this infection - you just get reinfected tomorrow by the same script. — Hector, Nov 17 '17 at 16:29
The major talking points within this thread was how important it is to close any entry point and ensure that the same thing does not re-occur. That was something that was tackled immediately once we got to know about the problem. Had I wanted to ask about it, I would have asked another question. My question was related to the Coinhive malware and how we can get rid of it *and just that*. Why is it so difficult to put this across? I understand that there are other more important things, *but I did not ask about them here*. — Jurgen Cuschieri, Nov 17 '17 at 17:28
And no, I am not security savvy, and I am not even the server administrator here. I accept that my question was not as informative as it should have been, and I would have offered more details had I been given the chance. Thanks! — Jurgen Cuschieri, Nov 17 '17 at 17:29

score 2 · Accepted Answer · answered Nov 17 '17 at 14:40

Where could the script be injected from? Pretty much anywhere. It's a web server, so by definition is exposed to the internet. There may be a compromised device on your network (although that possibility is low). You could have a malicious administrator. First step is to start closing down possible vectors for this.

What can we try? I'd start by looking at permissions and reducing them. Which accounts have rights to that directory? Who has access to those acocunts? Are all accounts tied to a specific person? Also, this doesn't appear to be a virus - someone or something is altering the web page code. If it were me, on any internet-facing server I'd put application whitelisting as part of the build process before I allowed that to touch the intenet. There are also products out that that can protect the directories in question from unauthorized changes and if one is attempted revert them. That would as a rule of thumb be a good decision to make as well.

If the website administrators don't have 2 accounts (one for normal use and one for administrative tasks on the servers), they should do that. I worked at one job where the server admins used their normal accounts for server admin tasks. One of them got a worm on his computer, and it quickly found its way onto our servers. They spent an entire weekend remediating that mess. Have a user account that they log into their workstation with and an administrator account that they ONLY use to log in to the web server with. Then block all other accounts from logging into that server.

Is there some kind of executable or anything else we can look for manually? Sure there is, but what would it be called? Where would you look for it? That's a needle in a haystack. It could reside in pretty much any location on your network. Also, if an account with access to that server has been compromised, the parties responsible for this could put content on it from anywhere in the world. Changing administrator passwords might not be a bad idea there. I'd think that the server itself is compromised and an entity is doing this and not some executable.

This all depends on how strongly you want to react to this. It sounds like there's not a lot of cybersecurity experience there and you want to do forensics as well. I'd suggest engaging with a reputable consulting company to do those and then some penetration testers to find out where the holes are. sure, it'll cost money; these folks don't come cheap. But they can help resolve this for you and bring a lot of experience and expertise to the table.

CoinHive Bitcoin Mining

1 Answers1