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: arstechnica.com/information-technology/2017/10/… ? – Tom K. Nov 17 '17 at 12:51
  • 2
    @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
  • 1
    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
  • 1
    @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
  • 1
    @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

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.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.