wow, really great engineering blog, learned a lot, and here are few snippets which i liked and caught more attention
https://modal.com/blog/catching-cryptominers
It’s important that our detection system is based on runtime program analysis. Twenty years ago Paul Graham observed that with email spam it is message itself, the data, that is an abuser’s Achilles heel. Spammers can steal email addresses, miners can steal credit cards. Both can change their metadata. But they cannot change their data. The message must scam, the program must mine.
syscall is the way
If a cryptominer’s Achilles heel is their program, their data, we should analyze their program.
Unfortunately for us, a miner’s program is vastly more complicated than a scammer’s email message. Modal’s SDK is currently Python-only, but the Modal container runtime supports arbitrary x86 Linux code execution. Any detection system based on source code or binary analysis was thus ruled out as intractable.
We can also rule out container image scanning, because Modal Functions are not blocked from downloading and executing arbitrary programs at runtime. In some container environments it’s valid to mount filesystems with noexec
or go whole-hog and make the entire container filesystem read-only, but this would be cripplingly restrictive to our users.
What we need is a runtime monitoring mechanism which is involves a relatively narrow domain, is common across all x86 programs, and can be observed with little to no runtime overhead.
How it works is that on container creation Modal’s runtime creates a dedicated socket to receive all runtime syscall trace data from gVisor. A thread is spawned and runs for the lifetime of the container, receiving and analyzing syscall events (a.k.a “tracepoints”) against all implemented analysis “rules”.