Having recently concluded a major internal security review, one of the most resource-intensive tasks was retroactively scanning our petabytes of cloud storage data lakes for unauthorized cryptocurrency mining activity. While Wiz's out-of-the-box policies are excellent for real-time cloud environment monitoring, we found the need for a more nuanced, historical analysis rule set tailored specifically for the forensic patterns left in storage services like S3, GCS, and Azure Blob Storage.
Our goal was to identify not just known miner binaries, but also the configuration artifacts, log outputs, and network proxy configurations that often persist long after the actual compute resources have been spun down. The standard "crypto-mining" alerts often focus on live compute instances, leaving a gap in the data lake layer.
We developed a custom ruleset extending Wiz's configuration-as-code framework. The core logic hinges on a multi-factor detection matrix, looking for concurrent evidence across several vectors:
* **File Signature Analysis:** Scanning for known static signatures of common miners (e.g., XMRig, Ethminer) and their associated pool configuration files. This is the most straightforward check.
* **Pattern Matching in Logs:** Targeting common log output strings from miners (e.g., "accepted share", "hashrate", "stratum://") within compressed or plaintext logs dumped to storage.
* **Configuration Artifact Detection:** Searching for orchestration scripts (Shell, Python, Terraform) that contain commands for pulling miner images, setting up mining pools, or altering systemd services for persistence.
* **Anomalous Network Proxy Settings:** Identifying misconfigured or malicious proxy JSON files that could indicate command-and-control (C2) communication attempts for a mining pool.
The rule set is structured as a YAML configuration for Wiz's custom detection engine. A simplified conceptual example of one rule component looks like this:
```yaml
ruleIdentifier: DATA_LAKE_SUSPECT_MINER_LOG
description: "Detects common cryptocurrency miner log output patterns in cloud storage objects."
severity: HIGH
inventoryEntityType: CLOUD_STORAGE_OBJECT
triggerCondition:
and:
- property: objectName
regex: .*.(log|txt|gz)$
- or:
- property: contentMatch
regex: ".*accepted share.*"
- property: contentMatch
regex: ".*hashrate.*[0-9]+\.?[0-9]* (kH|MH|GH|TH)/s.*"
- property: contentMatch
regex: "stratum(+tcp)?://.*"
```
The implementation required careful consideration of scanning costs and performance. We leveraged Wiz's targeted scanning capabilities, focusing first on storage buckets without default encryption, those with publicly readable permissions, and those associated with development or testing environments, before scaling to the entire estate.
Initial results over a 90-day historical scan were revealing. We flagged 42 objects across 3 projects, with only 7 being true positives (actual unauthorized mining residue). The false positives were largely due to legitimate blockchain node logs and developer testing scripts. This false-positive rate informed an iterative refinement process, adding more contextual filters, such as excluding objects associated with known, approved blockchain services.
This exercise underscored the importance of extending cloud security posture beyond runtime. The residual data in storage lakes provides a critical forensic timeline. We are now exploring integrating this ruleset into our CI/CD pipeline to preemptively scan for these patterns in infrastructure-as-code templates before deployment, effectively shifting this particular left. The integration potential with our workflow automation systems is significant.
Data over opinions