Your Billing Data as a Security Detector: The New-Region Anomaly

When a cloud account is compromised, the attacker's first move is almost always the same: launch compute as fast as possible across as many regions as possible. They are racing against your detection window. Within 10 minutes of gaining initial access, cryptocurrency miners are operational. Within 2 minutes, they can span 17 regions simultaneously.

Your billing data sees all of it. Not because it tracks suspicious API calls or login anomalies — it doesn't. But because the attacker has to run instances, and running instances costs money, and that spend appears in your billing export the moment it starts. The security and the billing signal are the same event.

The Zero-Threshold Rule

The highest-fidelity signal in cloud billing security is this: any spend in a region your account has never used is anomalous by definition.

No cost floor required. No baseline multiplier. No statistical significance calculation. If your account has operated in us-east-1 and us-west-2 for three years, and a billing row appears this morning for ap-south-1, that row is an incident until proven otherwise.

AWS confirmed this pattern directly in their November 2025 GuardDuty security blog: "Spiking costs for an unused cloud service or region can often be a strong indicator of malicious activity."

The only legitimate false positive is planned geographic expansion — which is a coordinated, multi-week event involving new account configuration, compliance review, and architecture work. It never looks like a simultaneous burst across 3–17 regions in 10 minutes.

The Four Billing-Observable Phases

A credential compromise attack follows a predictable billing signature across four phases:

Phase 4 fires independently and first. Compute reconnaissance (the attacker's DryRun API calls) is billing-invisible — it costs nothing to test what permissions exist. The first billing event is the moment they start running instances, which is also when they appear in a region for the first time.

What Appears in FOCUS Billing Data

The temporal profile is a vertical step-function. Days of $0 billing in a region, then a billing row with real spend — no ramp, no gradual increase. Legitimate workloads always have a setup phase. Attackers' auto-scaling groups do not.

Real-World Incidents

Campaign 1 — AWS GuardDuty, November 2025

Source: AWS Security Blog, "GuardDuty Extended Threat Detection uncovers cryptomining campaign on Amazon EC2 and Amazon ECS"

Key confirmed facts:

• Attacker attempted to run EC2 instances in unused region us-west-1 — the billing signal fired on first dollar of spend there
• Crypto miners operational within 10 minutes of gaining initial access — step-function onset confirmed
• 14 auto-scaling groups, min 20 / max 999 instances per group — $12,000/day scale at full activation
• ModifyInstanceAttribute used to disable API termination — instances persist billing past remediation attempts, extending the damage window
• Instance types spanned GPU, ML, compute, memory, and general-purpose — not GPU-exclusive

Campaign 2 — Datadog Security Labs, 2025

Source: Datadog Security Labs, "Tales from the Cloud Trenches: Amazon ECS is the new EC2 for crypto mining"

• 17 regions targeted in under 2 minutes — billing rows appearing in 17 previously-absent regions within a single billing hour
• Regions included us-west-1, described as "an underutilized region" — consistent with attackers targeting regions outside typical monitoring coverage
• Primary instance type: r6i.metal (bare-metal CPU, $4.69/hr) — not GPU. 20 of these instances generate $2,252/day with no GPU involvement
• "Hundreds of ECS Fargate clusters" per attack, sometimes 50+ in a single incident — Fargate tasks at 16,384 CPU units / 32,768 MB memory each

The GPU-only assumption is outdated. Both GPU, bare-metal CPU, and ECS Fargate are active attack vectors in 2025 campaigns. The billing detection signal — new region with any spend — works regardless of instance type.

What the bill looks like

A typical pre-attack account: $55/month in EC2 (a few t3.medium instances in us-east-1). After compromise: $12,000 in 72 hours, spread across 5 regions, entirely in instance types that were never used before. The billing export tells the full story within one billing day.

Detection Logic: The New-Region Query

The query approach is two steps:

-- Step 1: Find all regions first seen in the last 30 days
SELECT regionid, subaccountid, MIN(billing_day) AS first_seen_date
FROM billing_data
GROUP BY regionid, subaccountid
HAVING first_seen_date >= CURRENT_DATE - 30 days

-- Step 2: Return all spend in those new regions
SELECT resourceid, servicename, regionid, subaccountid,
       SUM(billedcost) AS total_cost
FROM billing_data
WHERE (subaccountid, regionid) IN (new_regions from Step 1)
HAVING total_cost > 0.01  -- any spend above noise floor

No statistical baseline. No magnitude threshold. No day-over-day comparison. The query is zero-threshold: historical absence in a region is the entire signal. A $0.07 billing row in ap-northeast-2 from an account that has only ever operated in us-east-1 is an incident.

False Positive: Planned Geographic Expansion

The one legitimate scenario that triggers this rule: your team has intentionally expanded into a new region. The discriminants are:

• Speed of activation: Planned expansion involves days of setup (VPC configuration, IAM roles, compliance review). An attack is operational within 10 minutes of the first billing row.
• Region cardinality: Planned expansion is one or two new regions over weeks. Attacks span 3–17 regions simultaneously.
• Instance type: Expansion uses the same instance families as your established workloads. Attacks often use high-performance compute (GPU, bare-metal) types never seen in your billing history.
• Tags: Your engineers tag resources. Attackers don't.

If any of those discriminants apply, it is an expansion. If none apply, treat it as a compromise until your security team rules it out.

Fix Checklist

1. Enable AWS Cost Anomaly Detection — free service. Create a monitor scoped to "Linked Account" and set an alert threshold of $0 in any region outside your established set. AWS will email you within hours of the first spend appearing.
2. Add a billing budget with region filter — AWS Budgets can alert on spend in specific regions. Create a budget for each region you don't operate in with a $1 threshold. Alert fires on first dollar.
3. Rotate credentials immediately on alert — the attacker is using stolen credentials. Revoking the access key or invalidating the session is the first remediation step. Do not attempt to terminate instances first — the ModifyInstanceAttribute technique blocks instance termination until you re-enable it via IAM.
4. Audit Service Control Policies (SCPs) — if you operate in AWS Organizations, SCPs can deny ec2:RunInstances in regions your organization does not use. This is a preventive control — an attacker with stolen credentials cannot launch compute in a region the SCP blocks, regardless of the IAM permissions on the key.
5. Check your billing export latency — AWS CUR and FOCUS exports are typically 8–24 hours behind real time. Cost Anomaly Detection uses a near-real-time signal feed that fires faster than the billing export. For security use cases, Cost Anomaly Detection is faster.