We, a medium-sized hosting provider, just do it using the process name. Works much better than you'd expect, since most miners are using very similar software. No interesting engineering challenge here, sadly.

Ssssh.... If you tell everyone that's what you do, people will just rename the binary...

The trick to protections like this is to not tell anyone how they work, and to run them only occasionally. Ie. once a week, ban half of users who are running xmrig.exe. Also include users who signed up with the same email address, phone number or IP address as the detected users and who have a consistently high CPU use - these are probably successful bypasses of your simple process name based filter.

That way bad actors have a very hard time figuring out exactly what your protections are or how they work. If they were to get an immediate ban as soon as they fired up xmrig.exe, then they'd quickly think to rename it or recompile it or run it under wine or a host of other ideas. Yet having a random selection of their accounts banned seemingly at random means they learn nothing.

Obviously you need a process for users accidentally caught in the net to get their accounts reactivated, and if you're a service like githuib you should probably let the user have a grace period to do that before killing their entire business...

So if you only ban half of illegitimate accounts once a week, does this mean I just need to launch my mining code registration scripts also once a week, ideally just after I see some of my accounts have been banned?

And doing this will get me a full week's of free mining on half my miners (if I'm the only one in the world pursuing this strategy) or most of my miners if the banning campaign is capped and also hits other abusers? It sounds like a great deal, honestly.

For most places you can get free compute power, a week's mining revenue might only be a few cents.

As long as the account sign-up process requires a captcha or phone number for the most spam-like signups, you'll keep their profits low enough to deter most people.

Good luck finding that post and linking it to the provider. That set aside, except for DDoS defense, we've run into no problems at all when talking very openly about how we operate. Seems naive at first glance, but we've had a good 10+ year run (so far!). Works for us, might not for others.

Delayed banning seems to work well for multiplayer game anti cheat systems (like VAC).

These problems are essentially the same, some of the know-how can be easily adapted between them.

> Good luck finding that post and linking it to the provider.

No need to link it to the provider. If one provider does things that way, you want to block their method. (And, of course, the odds are overwhelming that the other providers are doing the same thing.)

It seems like a Whois search about the domain that's in your Hacker News profile yields lots of interesting information. Your previous comments seem to indicate that's a provider you work for. Maybe it's not related though. Or maybe it's just a way of doing PR. I know nothing.

Wonder if you could check the repeated use of cryptographic functions in a process as a sign.

As a bonus, you'll also see ransomwares, disk encryption software, http servers, browsers...

And what if the miner uses it's own crypto lib, and doesn't rely on the OS crypto API?

Do miners heavily rely on crush instructions? Then it could perhaps be possible to reduce the performance of these instructions 100-fold, making mining useless but other code still run.

You could also just address it through your rate table by appropriately pricing for intense workloads, couldn't you?

We're offering shared hosting for web apps and other hacker/toy projects. Intense compute workloads are just not what our product is built for, so we let other providers handle that part of the market.

That's what I mean. So make it very expensive to run them on your service and the coin miners will go elsewhere.

We're aiming to make our service accessible to everyone, which involves customers choosing their own price. So there isn't a fixed price we could raise. Additionally, there is a free trial month, which adversaries typically make use of, instead of paying for the service. Hiking he price without deep additional changes is not in our interest and wouldn't change anything in our case.

Google Colab supposedly has great miner detection for example. I Googled out of curiosity recently and couldn't find any clearnet mentions of anyone bypassing it in the recent past and the old ways don't work. Though it must be possible it at minimum doesn't seem to be easy.

Google Cloud is similar (perhaps the same). I run sites there that involve arbitrary code execution by our users, and periodically Google support contacts us to report cryptomining violations. I don't know exactly what Google's heuristics are for triggering this, but their reports to us typically include the ip address of a mining pool that was contacted by one of our virtual machines. My impression is that mining typically involves a network connection.

Aren't you afraid of running such service on Google infrastructure and getting the ban hammer from Google?

No I am definitely not afraid of that, based on several factors: knowing what really happens in practice having used GCP since 2014; my company being in the highest tier of Google’s startup program; I know many people who work at Google (eg numerous of my past PhD students). Of course my risk analysis parameters may be completely different than yours. On a purely technical level, GCP is a good quality product.

Does it even matter to GCloud (a paid service) if I use 100% of the GPU for Deep Learning or for mining? They operate on profit either way.

They also care because in practice such use is often done by attackers unbeknownst to the person paying for the resources. That would much rather make the person paying aware ASAP of such usage, rather than have them be on the hook for a large bill at the end of the month. Google does have a complicated process to allow cryptomining on their infrastructure. They also flag all kinds of other suspicious activity, eg once somebody was launching DOS attack from cocalc on “the country of Turkey” and that got some of cocalc shutoff immediately.

It does, I think, for the same reason GPU manufactories segment GPUs for gaming and for Deep Learning.

RandomX is quite easily detectable due to the unusual use of floating point operations. Proof of concept detectors have already been created, for example https://github.com/tevador/randomx-sniffer

CPU throttling is probably your best bet I'd say. Watch for things pegging the CPU

Most of build actions is not 100% CPU bound

But yeah, abusers are going to abuse

> Most of build actions is not 100% CPU bound

Unless you compile large C/C++ projects on a low core count VM.

AFAIK, I don't think OOM-killer would help too much. Calculating hashes is not very memory intensive job