Detecting them while they are running would be the best approach I guess. Not after the time limit when the damage is already done.
Detecting them while they are running would be the best approach I guess. Not after the time limit when the damage is already done.
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...
These problems are essentially the same, some of the know-how can be easily adapted between them.
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.)
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.
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.
And what if the miner uses it's own crypto lib, and doesn't rely on the OS crypto API?
Most of build actions is not 100% CPU bound
But yeah, abusers are going to abuse
Unless you compile large C/C++ projects on a low core count VM.