Cloud Security Hardening for a Southeast Asian E-Commerce Platform

Background

A Singapore-registered e-commerce platform operating across Southeast Asia (Philippines, Indonesia, Thailand, Vietnam) contacted CyberneticsPlus after their AWS billing alert fired — the monthly spend had reached $8,400 in 9 days (normal monthly spend: ~$2,200).

Initial investigation by their DevOps team identified dozens of EC2 instances running in regions the company had never used (eu-west-1, us-west-2, sa-east-1) — all running CPU-intensive workloads consistent with cryptocurrency mining.

Company profile: 12-person team, 4 developers with AWS access, operating a marketplace platform serving 40,000+ active buyers and sellers. AWS environment: EKS cluster (production), RDS PostgreSQL, ElastiCache Redis, S3 for product images and seller documents.

Incident Response

Hour 0–4: Immediate Containment

CyberneticsPlus was engaged via emergency contact. Initial triage:

1. Identified the compromised credential: CloudTrail audit showed all unauthorised EC2 operations originated from IAM access key AKIAX...7K9F belonging to a developer account
2. Key immediately deactivated: Developer’s access key disabled within 30 minutes of engagement start
3. Unauthorised instances terminated: All EC2 instances in foreign regions terminated
4. Spend control: AWS Support engaged to apply Service Quota limits preventing future large-scale EC2 launches
5. Scope check: Reviewed CloudTrail for 30 days — confirmed attacker actions were limited to EC2 launch (no access to RDS, S3, or customer data)

Hour 4–24: Forensics

Root cause investigation:

CloudTrail showed the first unauthorised API call at 14:23 UTC on Day 1. The developer’s access key AKIAX...7K9F was used from an IP address in Eastern Europe — not consistent with the Singapore-based team.

Repository scan of the company’s GitHub organisation revealed the access key had been committed to a private repository 6 months earlier in a .env file. The repository was private, but GitHub’s secret scanning (not enabled) would have flagged it. The git history had never been cleaned.

Attack timeline reconstruction:

• 6 months prior: Access key committed to private repository
• Unknown date: Repository forked or scanned by credential-harvesting tool (common automated attack — monitors GitHub for newly committed secrets)
• Day 0: Attacker activated the key and began launching EC2 instances across 8 regions
• Day 9: Billing alert triggered at $8,400

Customer data exposure assessment:

• CloudTrail confirmed: no S3 GetObject or ListObject calls using the compromised key
• RDS: no database connections from the compromised key’s sessions
• Seller documents, customer PII, payment data: no access confirmed
• Conclusion: incident was purely financial (unauthorised compute spend) with no customer data breach

Hour 24–48: Full Remediation

All access keys for all 4 developers rotated. EC2 instances confirmed terminated. AWS account-level security controls applied (block all new EC2 outside ap-southeast-1 via SCP).

AWS Security Overhaul

Post-incident, CyberneticsPlus conducted a comprehensive AWS security assessment and implemented 41 security controls across the environment.

Identity and Access Management

• All IAM users converted to IAM Identity Center (SSO) — eliminated long-lived access keys for console access
• Application access moved to IAM roles with least-privilege policies
• GitHub Actions OIDC federation configured — CI/CD pipeline uses short-lived role credentials (no access keys)
• SCPs deployed:
  • Block all regions except ap-southeast-1 and ap-southeast-2 (backup region)
  • Block EC2 instance types above t3.xlarge (prevents cryptomining on large instances)
  • Block disabling GuardDuty or CloudTrail

Secrets Management

• All developer machine .env files audited — 3 additional historical commits with credentials found and revoked
• GitHub Advanced Security secret scanning enabled on all repositories
• Pre-commit hooks deployed to development team: git-secrets to prevent future credential commits
• Application secrets migrated to AWS Secrets Manager

Detection and Monitoring

• GuardDuty enabled in all regions (not just ap-southeast-1)
• Billing alerts configured at 50%, 75%, 100%, and 150% of expected monthly spend
• GuardDuty → EventBridge → SNS → PagerDuty alert configured for all High and Critical findings
• CloudTrail: enabled in all regions with S3 delivery to a separate, locked security account

Container Security (EKS)

• Kubernetes RBAC audit: 3 service accounts with cluster-admin removed, scoped permissions implemented
• Pod Security Admission: restricted profile enforced on production namespace
• Network Policies: default-deny implemented, explicit rules for required service communication
• Container image scanning: Trivy integrated into CI/CD pipeline (ECR images scanned on push)

Financial Impact and Recovery

Direct costs of the incident:

• Unauthorised EC2 spend: $8,400 (partially recovered — AWS provided a $6,200 goodwill credit after incident report submission)
• Net financial loss: ~$2,200

AWS credit eligibility: AWS’s policy on account compromise credits varies. CyberneticsPlus assisted with the credit request, documenting that the account was compromised due to an inadvertent credential leak rather than insecure root access — which resulted in a partial credit being approved.

Post-incident investment:

• CyberneticsPlus engagement (incident response + security overhaul): $18,500
• Ongoing: GuardDuty and Security Hub costs: ~$180/month

ROI calculation: The security overhaul cost was paid for within the first year through:

• Reduced risk of future incidents (no further compromises in 12 months post-deployment)
• Cyber insurance premium reduction (15% at next renewal)
• Enterprise seller onboarding: 3 enterprise sellers cited the security posture improvement as a vendor requirement for joining the marketplace

Lessons

1. Secret scanning in CI/CD is non-negotiable. A free GitHub Advanced Security feature (for private repos) would have caught the committed key before it was ever accessible.
2. GuardDuty doesn’t protect regions you don’t enable it in. The attacker launched instances in regions where GuardDuty was not enabled — no detection until billing alerts fired.
3. Access keys should not exist. OIDC federation for CI/CD and IAM Identity Center for human access eliminates the class of credential-based attacks entirely.
4. Billing alerts are a last resort, not a security control. $8,400 in 9 days is a minimal cryptomining impact. A data exfiltration incident wouldn’t trigger billing alerts at all.