Cloud Cryptojacking Detection at Scale: Mining-Pool Hunting on AWS

From the hunt desk. Most cryptojacking incidents I have helped clean up over the past three years were discovered not by the SOC, but by the FinOps team. The bill arrives. Someone notices the bill. The DevOps lead opens a ticket. By then the attacker has been mining Monero on a compromised EC2 fleet for somewhere between 11 days and 4 months. The network signal was visible the entire time. Nobody had a detection for it because cryptojacking falls in the gap between “endpoint detection” (no agent on the abused instance) and “data exfiltration” (the bytes look normal). It is a perfect cloud-native attack and remains one of the most under-detected categories in 2026.

This playbook covers the network-side hunt — mining pool protocol fingerprinting, sustained low-volume regular traffic detection, ASN-based pool reputation, and the cross-correlation with EC2 / ECS / EKS / Lambda metadata that lets you go from “this flow looks like Stratum” to “this is instance i-0abc123 in account 111122223333, started by IAM role X, attached to ECS task Y.” All of it from VPC Flow Logs and CloudTrail. No agent required.

This is post #8 in our VPC Flow Log detection series — adjacent to FFT C2 beacon detection, DGA + DNS-tunnel hunting, and TLS fingerprinting.

Why Cryptojacking Survives in Cloud Environments

Three structural reasons keep cryptojacking off most detection roadmaps:

• The volume is small. Mining a coin produces tens of kilobytes per minute of Stratum protocol traffic. Volumetric exfil rules ignore it. The signal lives in the persistence and regularity, not the volume.
• The destinations are diverse. Major mining pools have hundreds of subdomains across multiple ASNs. A blocklist approach catches half on day one and zero by week six. Detection needs to be behavioural, not destination-based.
• The attacker uses your money, not yours. Cryptojacking is theft of compute, not data. CISOs deprioritise it because nobody loses customer records. CFOs care, but they discover it on the bill, not from a SOC alert. The detection programme that catches it has to be operated by a team that cares about cost as much as data — usually a cloud security or platform-engineering team in modern orgs.

The asymmetry matters: a single c5.24xlarge running XMRig for a week consumes roughly $1,200 of compute and produces around $30 of Monero at current rates. The attacker is happy to operate at 2.5% efficiency because the compute is free to them. You are paying 40× the value being stolen — which makes early detection the most cost-effective investment in this whole post.

The Detection Pipeline

1. Ingest. VPC Flow Logs from every account, partitioned by day in S3. CloudTrail in parallel for the metadata join later.
2. Egress filter + ASN enrich. Filter to outbound flows from RFC 1918 to non-RFC 1918. Enrich each destination IP with its ASN using a maintained commercial ASN-enrichment providers lookup table. Mining pools cluster on a handful of well-known ASNs — low-cost hosting neighbourhoods — and a growing long tail of small operators.
3. Stratum / mining-protocol fingerprint. Stratum runs primarily on ports 3333, 4444, 5555, 7777, 8888, 14444, 14433, 14444, plus a few hundred custom ports per pool. Combine with payload size patterns: Stratum keepalive packets are 32–128 bytes; share submissions are 200–600 bytes. The pattern is repetitive and very regular — 60-second intervals are typical.
4. Sustained-traffic ML. An Isolation Forest trained on per-host 24-hour feature vectors flags hosts with the cryptojacking signature: low byte rate (5–50 KB/min), high session persistence (uninterrupted for hours), small packet sizes, repetitive IAT. Critically, the model is trained per-instance-type — a c5.xlarge running a real workload looks different from one running XMRig. Without per-type baselines you swamp the queue with false positives.
5. Metadata join + quarantine. A confirmed candidate gets the EC2 instance metadata pulled from CloudTrail RunInstances events: AMI ID, instance role, launch time, attached security groups, owning account. For containerised workloads, the same join works for ECS tasks and EKS pods via their associated ENIs. Quarantine is one Lambda call away — modify the security group to deny egress, optionally stop the instance, snapshot the EBS volume for forensics.

Stratum Protocol Signature in VPC Flow Logs

Stratum is a JSON-RPC protocol over plain TCP (Stratum v1) or TLS (Stratum v2). VPC Flow Logs do not see payloads, but they see the shape of Stratum traffic clearly:

• Persistent single connection. One TCP session per worker, kept open for hours or days. Compare to a web client that makes many short-lived connections.
• Small bidirectional packets at regular intervals. 60-second keepalives, 30-second share submissions. The byte-per-packet distribution is tight and centred around 50–150.
• Asymmetric byte ratio. Worker → pool traffic exceeds pool → worker traffic in mining mode. The opposite of typical web client behaviour.
• Long-tail destination ports. Pools advertise non-standard ports (3333, 4444, 5555, etc.). Anomalous-port destination from EC2 is a very high-fidelity signal.

Stratum over TLS (newer pools, especially major mining pools) hides the JSON-RPC but preserves all the structural signals above. The TLS fingerprint of the XMRig client is also a strong supplementary signal — see post #7 on JA3/JA4 for the fingerprint hunt.

Athena SQL — The Cryptojacking Hunt Query

WITH egress_24h AS (
    SELECT srcaddr, dstaddr, dstport, bytes, packets, start, end,
           (end - start) AS duration_sec
    FROM central_vpc_flow_logs
    WHERE action = 'ACCEPT'
      AND srcaddr LIKE '10.%'
      AND dstaddr NOT LIKE '10.%' AND dstaddr NOT LIKE '172.%' AND dstaddr NOT LIKE '192.168.%'
      AND protocol = 6
      AND day BETWEEN '2026/05/09' AND '2026/05/15'
),
session_summary AS (
    SELECT srcaddr, dstaddr, dstport,
           COUNT(*)                              AS flow_count,
           SUM(bytes)                            AS total_bytes,
           SUM(packets)                          AS total_packets,
           AVG(CAST(bytes AS DOUBLE)/NULLIF(packets,0)) AS avg_packet_size,
           MAX(end) - MIN(start)                 AS session_lifetime,
           AVG(duration_sec)                     AS avg_flow_duration
    FROM egress_24h
    GROUP BY srcaddr, dstaddr, dstport
    HAVING COUNT(*) > 30
       AND SUM(bytes) BETWEEN 50000 AND 50000000
       AND AVG(CAST(bytes AS DOUBLE)/NULLIF(packets,0)) BETWEEN 40 AND 300
)
SELECT s.srcaddr, s.dstaddr, s.dstport,
       s.flow_count, s.total_bytes, s.avg_packet_size, s.session_lifetime,
       CASE
         WHEN s.dstport IN (3333, 4444, 5555, 7777, 8888, 14444, 14433)
              THEN 'KNOWN_STRATUM_PORT'
         WHEN s.dstport BETWEEN 3000 AND 9000 AND s.avg_packet_size < 200
              THEN 'SUSPECTED_STRATUM_PORT'
         ELSE 'OTHER'
       END AS port_classification
FROM session_summary s
WHERE s.dstport IN (3333, 4444, 5555, 7777, 8888, 14444, 14433)
   OR (s.session_lifetime > 3600 AND s.avg_packet_size < 250 AND s.flow_count > 100)
ORDER BY s.total_bytes DESC;

The result is your cryptojacking candidate list — hosts with persistent, low-volume, small-packet connections to known or suspected Stratum ports. A typical mid-size environment produces 0–5 candidates per day; a compromised one produces dozens to hundreds, all clustered on the same source ENIs.

Connecting the Network Signal to the Cloud Identity

A cryptojacking alert with just a private IP is useless to a responder. The mandatory next step is to join the source IP to the EC2 / ECS / EKS resource and the IAM principal that launched it.

The CloudTrail event you want is RunInstances (for EC2) or RunTask (for ECS) within the last 30 days, joined by instance_id via the VPC Flow Log instance-id field if your log format includes it. For EKS pods, the ENI tag kubernetes.io/cluster/<name> identifies the cluster; from there, kubectl or the EKS Audit API maps the IP to the pod.

Lambda-driven cryptojacking is also rising — attackers using compromised lambda execution roles to spin up mining workloads in regions you do not actively monitor. The detection here is identical at the network layer (Stratum traffic), but the metadata join points to a Lambda function rather than an instance.

Feature Engineering

Cryptojacking Variants Worth Knowing

• XMRig + classic Monero mining. The most common variant — Linux EC2 instances, often via compromised SSH keys or web-app exploits, running XMRig pointed at major mining pools. Distinctive UA and TLS fingerprint.
• Lambda cryptojacking. Less common but increasing — attackers reuse compromised Lambda execution roles to launch workloads via SDK calls. The mining happens in a short-lived Lambda, restarted every 15 minutes. Network signal is identical to EC2 but harder to attribute.
• ECS Fargate cryptojacking. Compromised ECR images or task definitions run mining workloads in Fargate. CloudTrail RunTask is the metadata source for attribution.
• EKS pod cryptojacking. Compromised container images deployed via a Kubernetes operator the cluster admin doesn’t audit. Same network signal; metadata join via EKS Audit logs.
• WebAssembly browser mining (CoinHive-era technique). Out of scope for VPC Flow Logs — happens in user browsers. Mentioned here for completeness.

Limits and False-Positive Sources

• Long-poll APIs. Some legitimate financial-data and IoT APIs use sustained TCP connections with low byte rates. Allow-list by destination ASN.
• WebSocket-heavy SaaS. Slack, Discord, collaboration platforms maintain persistent TCP sessions with intermittent small packets. Allow-list by destination FQDN.
• Database replication. Postgres logical replication, MongoDB oplog tailing, Kafka MirrorMaker all produce sustained low-volume traffic. Tag at source via instance tags.
• Synthetic monitoring agents. commercial synthetic-monitoring agents — all generate periodic small egress traffic. Allow-list by destination ASN.
• Stratum-look-alike protocols. Some pub/sub libraries (NATS, MQTT) produce traffic that resembles Stratum. Run the destination ASN through your reputation feed before alerting.

MITRE ATT&CK Techniques Covered

Adversary emulation. Stand up a lab EC2 instance, install XMRig, point at a mining-pool test endpoint, watch the pipeline fire. public adversary-emulation atomics T1496 includes safe XMRig invocations. For Lambda cryptojacking emulation, a 15-minute Python function that opens a Stratum connection is sufficient.

Adversary groups. Cryptojacking is overwhelmingly opportunistic — no single named group dominates. The closest “groups” are TeamTNT, Watchdog, and KISS (Kinsing) which have been tracked since 2020. Their tooling is open-sourced via various leaks, and the indicators rotate weekly.

Where This Sits in a Mature Threat Hunting Programme

• FFT C2 beacon detection — periodic-signal companion.
• DGA + DNS-tunnel hunting.
• TLS fingerprinting — XMRig has a distinctive JA4.
• Hunting AWS identity attacks — the typical compromise path.
• AWS Bedrock CloudTrail playbook.

Closing Thoughts

Cryptojacking does not exfiltrate customer data. It does not encrypt your databases. It is therefore unfashionable in the threat-hunting community — and that is exactly why it persists for so long, in so many environments, paid for by so many CFOs who eventually realise the cloud bill grew 80% with no business-driver story. Building the detection above is a 1-week task, the cost is negligible, and the operational pattern is straightforward. Do it. Tell your FinOps team. Your CFO will thank you and you will catch the upstream compromise — because the cryptojacking always means there is a broken IAM role or a vulnerable web app upstream that someone else will find and use for worse things next month.

Happy threat hunting.

#threathunting #cryptojacking #xmrig #monero #cloudsecurity #awssecurity #vpcflowlogs #stratum #soc #blueteam #detectionengineering #mitreattack