AWS Billing & Suspected-Compromise Analysis + 2026 Action Plan

Account 851535961059 · 株式会社 coffee house · Sellers of record: Amazon Korea (KRW) / Amazon.ID (IDR) / AWS Inc (USD)
Prepared 2026-06-22 · Internal/personal · FX is approximate (USD/KRW≈1,380, USD/IDR≈16,300)
Compromise signature does NOT match 100% past due (up to 91d+) Likely legit but over-provisioned
TL;DR
  1. This is most likely NOT a classic crypto-mining compromise. Account-takeover mining shows up as a vertical spike — up to 999 EC2 instances within ~10 minutes. This bill is flat at ~$2.6k/month from Mar through Jun. A flat curve points to legitimate-but-unoptimized always-on resources, not a fresh takeover. (A low-and-slow miner still can't be ruled out without an audit.)
  2. The real immediate risk is payment. The "Current" column is all -the entire balance is past due, accumulating into the 91-day+ bucket. Left alone this leads to account suspension and a service outage.
  3. Root cause = governance / access gap. "Viky has no access to minkabu's AWS" is the crux. Audit, payment, and optimization all start with getting access.

1. Billing Data Analysis

USD invoices (all past due)
$9,550.65
Current $0 · 100% past due
KRW invoices (all past due)
₩14,322,721
≈ $10,378
IDR invoices (all past due)
Rp 1,642,653
≈ $101

Combined past due ≈ $20,030 (≈ ₩27.6M). Three separate invoices because the seller of record differs per currency (KRW = Amazon Korea, IDR = Amazon.ID, USD = AWS Inc).

Past-due aging by currency

Currency1–30d31–60d61–90d91d+Total past due
USD2,717.072,595.992,669.191,568.409,550.65
KRW4,068,3473,887,6573,997,6502,369,06714,322,721
IDR541,284510,234520,21270,9231,642,653

Charges are spread evenly across all four aging buckets = the same magnitude has recurred for months. This is a steady run-rate, not a one-off surge.

Monthly invoices (line items)

PeriodKRW (Amazon Korea)IDR (Amazon.ID)≈ USD
2026-032,369,06770,923~1,720
2026-043,997,650520,212~2,930
2026-053,887,657510,234~2,850
2026-064,068,347541,284~2,980

KRW invoices flatten at ~₩3.9–4.1M from April onward. Add the USD invoices (~$2.6k/mo) and the steady run-rate is ≈ $5k/month (≈ ₩6.9M/month). That is a large gap from the "barely anyone uses it" perception → strong signal of idle / over-provisioned resources.

2. Core Diagnosis — Compromise vs. Legitimate Overspend

Compromise (takeover) hypothesis — WEAK

  • The 2025-late/2026 campaign pattern: post-takeover, attackers spin up up to 999 EC2 / 50+ ECS clusters within ~10 min → a vertical spike.
  • This bill is flat Mar→Jun. No spike present.
  • Can't be fully ruled out: low-and-slow miners, or a takeover kept "quietly" within quotas, exist → must confirm with CloudTrail / GuardDuty.

Legitimate-but-unoptimized — STRONG

  • A flat run-rate = always-on resources left running (idle EC2/RDS, unused NAT GW, unattached EIPs, old snapshots/EBS, large data transfer).
  • "Barely anyone using it" yet $5k/month → textbook over-provisioning for actual usage.
  • Action: once compromise is ruled out, pivot straight to FinOps cleanup.

Conclusion: Run a P0 compromise audit within 24h to rule it out, but the signature strongly suggests the real work is cost optimization + billing/governance.

3. 2026 Action Plan

Workstream A — Rule out compromise P0 · 24h

A1Get access first. Without audit access to minkabu's (customer) account, nothing else can start. Ask the customer to create a read-only cross-account role (SecurityAudit + ViewOnlyAccess managed policies) and delegate it to our account. Never share root credentials.
A2Inventory resources in ALL regions — including regions you never use (miners hide in obscure ones).
aws sts get-caller-identity
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "== $r =="; aws ec2 describe-instances --region $r \
    --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,LaunchTime]' --output text
done
# Repeat the region loop for ECS/Fargate, Lambda, EMR
A3Trace unauthorized activity in CloudTrail. Console → Event history → look up RunInstances, CreateAccessKey, CreateUser, ModifyInstanceAttribute (especially disableApiTermination=true — this campaign's anti-deletion trick), AttachUserPolicy (e.g. AmazonSESFullAccess). Filter by any suspect access-key ID.
A4Credential report + GuardDuty.
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d
# Check for suspect usernames (e.g. user-x1x2x3x4), excess perms, stale unused keys
Enable GuardDuty in all regions and accounts with Runtime Monitoring. Look for findings like CryptoCurrency:EC2/BitcoinTool.
A5If compromise is confirmed, contain it. (1) Immediately deactivate → delete exposed keys; rotate root and all IAM passwords. (2) Terminate unauthorized resources (for instances with deletion disabled, clear disableApiTermination first). (3) Enforce root MFA, remove unneeded access keys. (4) Open an abuse case with AWS Support — there may be room to negotiate credits on the fraudulent charges.

Workstream B — Cost optimization (FinOps) P1 · 1 week

B1Break down the spend. Group Cost Explorer by service, region, usage type to pinpoint what makes up the $5k/month. Use the CUR (Cost & Usage Report) for line-level detail.
B2Remove idle resources (quick win, 5–15% off). Unattached EIPs, unused NAT Gateways, EBS attached to stopped instances, old snapshots/AMIs, unused load balancers, excessive CloudWatch log retention. Apply Trusted Advisor / Compute Optimizer recommendations.
B3Right-size (20–40% off). Use Compute Optimizer to downsize over-provisioned EC2/RDS — and only after that, look at commitments (order matters).
B4Commitment discounts. Once the steady run-rate is confirmed, start conservatively with a 1-year Compute Savings Plan (flexible, ~66% off). Use the "80% rule" (cover only 80% of steady usage) and review 6–12 months of usage first.

Do NOT buy commitments while compromise is unresolved — that would lock fraudulent usage into a contract.

Workstream C — Billing, governance & guardrails P1–P2 · ongoing

C1Clear the past due (urgent). The 91d+ bucket is a pre-suspension signal. Pay outstanding invoices in the Billing console and negotiate dispute/grace with AWS Support. Handle each invoice separately since the seller of record differs (Korea / ID / Inc).
C2Dual alerting. Use Cost Anomaly Detection (free, ML dynamic thresholds, spike detection, ranked root cause) and AWS Budgets (static thresholds, catches slow leaks). CAD for spikes, Budgets for gradual creep — you need both.
C3Org guardrails. AWS Organizations + SCPs to block unauthorized regions and high-cost instance families (e.g. large GPU), and block root usage. Enforce all-region GuardDuty/CloudTrail on member accounts via a delegated admin.
C4Access governance. Root MFA + no day-to-day root use; IAM Identity Center (SSO) for least privilege; short-lived roles instead of access keys; rotate keys and auto-clean unused ones (IAM Access Analyzer unused-access).

4. Immediate Checklist

#ActionOwner / prereqDone when
1Request read-only audit role from customerminkabu cooperationSecurityAudit role assumes successfully
2Inventory EC2/ECS/Lambda in all regionsafter #1Zero unrecognized resources
3CloudTrail 90-day unauthorized-event reviewafter #1No suspect API calls
4Credential report + enable GuardDutyafter #10 findings / key hygiene verified
5Pay past-due invoices, negotiate graceFinance91d+ cleared, suspension avoided
6Cost Explorer breakdown → remove idleafter compromise ruled outMonthly run-rate drops (measured)
7Set up Cost Anomaly Detection + BudgetsongoingTest alert received

5. Sources


This is a first-pass analysis based on two shared invoice screenshots and the Slack discussion; update once actual CloudTrail / Cost Explorer data is available. FX and USD conversions are estimates.