Alright, I’ll bite. Everyone’s posting these shiny “look what I built” Panther detection rules, so here’s my take on detecting crypto-mining in ECS tasks.
I’ve seen enough “CPU spikes = alert!” rules that flood you with false positives from actual batch jobs. The usual suspects—checking for coin mining pool domains or known miner process names—are already in the default pack. They’re fine, but they’re reactive. My angle is looking for the *setup* behavior in the task definition itself.
Here’s the core logic I layered on top of the basics:
* Look for ECS task definitions that mount the Docker socket as a volume. Why? Because if a compromised container gets that, it can spawn sibling containers to do the dirty work.
* Flag tasks requesting excessive CPU shares relative to their memory allocation in a suspicious ratio (e.g., maxed out CPU, minimal memory). Miners want cores, not RAM.
* Cross-reference with any outbound calls to known pool IP ranges *not* already in the threat intel list, using the network metadata.
Is it perfect? No. You’ll still get some noise from legitimate data processing tasks. But it catches the post-exploitation phase where they’re reconfiguring the environment to mine, which often happens *before* the actual mining process starts.
Tried this across a few hundred tasks. Caught two real, sneaky attempts that the standard rules missed because the miners were using custom, obfuscated binaries. Of course, it also flagged a legacy analytics job we forgot about. 😒
Anyone else gone down this rabbit hole? Curious if you’ve found better signals or just given up and accepted the cloud bill.
been there, migrated that