Tin Tặc Đang Dùng Chính Hạ Tầng AWS Để Qua Mặt Mọi Hệ Thống Email Security
Tóm tắt chiến dịch
Từ đầu năm 2026, Kaspersky ghi nhận sự gia tăng rõ rệt của các chiến dịch phishing và Business Email Compromise (BEC) lạm dụng Amazon Simple Email Service (SES) — không phải qua lỗ hổng phần mềm, mà thông qua AWS IAM access key bị rò rỉ. Bằng cách chiếm dụng key của bên thứ ba, kẻ tấn công gửi hàng nghìn email phishing mà không tốn chi phí xây dựng infrastructure riêng.
Điểm khiến chiến dịch này khác biệt: email được gửi từ hạ tầng Amazon — vượt qua SPF, DKIM, DMARC, đến từ IP không bị blocklist, và chứa link redirect qua amazonaws.com. Từ góc độ kỹ thuật, email trông hoàn toàn hợp lệ.
Hai nhánh tấn công chính được xác nhận:
Phishing thông thường — giả mạo thông báo DocuSign, dẫn nạn nhân đến trang đăng nhập giả trên amazonaws.com để đánh cắp credential.
BEC/Invoice Fraud — giả mạo chuỗi email nội bộ về hóa đơn thanh toán, kèm PDF không chứa URL độc hại để qua scanner, nhằm lừa bộ phận tài chính chuyển tiền.
Timeline & Bối cảnh
| Thời điểm | Sự kiện |
|---|---|
| 2024–2025 | Phishing qua legitimate cloud service (Microsoft 365, Google Workspace) trở thành trend phổ biến |
| Đầu Q1/2026 | Kaspersky ghi nhận spike đáng kể các chiến dịch phishing gửi qua Amazon SES |
| 04/05/2026 | Kaspersky công bố báo cáo phân tích chi tiết trên Securelist |
| Hiện tại | Xu hướng chuyển từ sự cố rời rạc → steady, ongoing campaign |
Chiến dịch này không phải hiện tượng đột ngột — nó là bước phát triển tự nhiên của xu hướng kẻ tấn công chuyển dần sang "Living off Trusted Services" (LoTS): thay vì xây dựng domain riêng dễ bị block, chúng thuê hoặc chiếm dụng hạ tầng của các nhà cung cấp lớn có reputation cao.
Chuỗi tấn công
Phase 1 — Reconnaissance & Credential Harvesting (T1552.001)
Kẻ tấn công sử dụng công cụ tự động, phổ biến nhất là TruffleHog (open-source, scan secret trong git history và code), để săn tìm AWS IAM access key bị lộ trên các nguồn công khai:
GitHub repositories — developer commit nhầm file chứa key vào public repo
ENV files — file
.envvớiAWS_ACCESS_KEY_IDvàAWS_SECRET_ACCESS_KEYbị push lên repoDocker images — credential hardcode trong Dockerfile hoặc baked vào image layer
Configuration backups — file config upload nhầm lên S3 bucket public
Exposed S3 buckets — bucket cấu hình sai, cho phép anonymous read
Kẻ tấn công không cần tấn công Amazon trực tiếp — chúng đang khai thác lỗi vận hành của developer và admin.
Phase 2 — Validation & Preparation
Sau khi thu thập được key, attacker thực hiện:
Verify key còn active và có quyền sử dụng SES
Kiểm tra sending limit (SES sandbox vs. production) và sending rate
Verify danh sách mục tiêu (email harvesting từ LinkedIn, data breach, v.v.)
Chuẩn bị HTML email template giả mạo thương hiệu uy tín (DocuSign, Microsoft, v.v.)
Chuẩn bị phishing landing page trên subdomain
amazonaws.comhoặc domain riêng
Phase 3 — Weaponization (T1566.002)
Kẻ tấn công cấu hình chiến dịch email với các yếu tố kỹ thuật nhằm tối đa hóa khả năng delivery và lừa đảo:
SPF/DKIM/DMARC pass: Email gửi qua SES tự động được ký bởi Amazon, đáp ứng mọi tiêu chuẩn xác thực email
Message-ID header chứa
.amazonses.com— trông hoàn toàn legitimate với email security toolRedirect chain: Link trong email trỏ đến
amazonaws.com→ sau đó redirect sang trang phishing thựcCustom HTML template: SES hỗ trợ template HTML đầy đủ, cho phép tạo email trông chuyên nghiệp
Phase 4 — Delivery (T1566.001)
Email được blast số lượng lớn thông qua SES API:
IP nguồn thuộc dải Amazon AWS — không bị blocklist bởi bất kỳ reputation service nào (block sẽ gây false positive hàng loạt cho hàng triệu user Amazon SES hợp lệ)
Email pass tất cả kiểm tra spam filter tiêu chuẩn
Volume không bị giới hạn bởi sending reputation cá nhân vì dùng chung pool IP của Amazon
Phase 5A — Exploitation: Standard Phishing (T1056.003)
Với chiến dịch phishing thông thường, nạn nhân nhận email giả mạo thông báo từ dịch vụ eSign (DocuSign là chủ đề phổ biến nhất trong Q1/2026). Email yêu cầu ký tài liệu. Khi nhấp vào link:
URL ban đầu dẫn đến subdomain
amazonaws.com(nạn nhân thấy domain quen, an tâm)Redirect tự động đến trang sign-in giả — có thể hosted trên
amazonaws.comhoặc domain riêngTrang giả render form đăng nhập Microsoft/Google/Office 365
Mọi credential nhập vào được gửi thẳng về attacker
Không có malware, không có attachment — chỉ là credential harvesting thuần túy qua giao diện web.
Phase 5B — Exploitation: BEC / Invoice Fraud (T1534)
Nhánh BEC tinh vi hơn nhiều. Kẻ tấn công giả mạo email nội bộ, thường là từ nhân viên cấp cao hoặc phòng kế toán/mua hàng, gửi đến bộ phận tài chính. Email mang theo:
Chuỗi email giả mạo: Thread được fabricate thủ công, trình bày như một chuỗi trao đổi hợp lệ giữa nhân viên và nhà cung cấp về hóa đơn đang chờ thanh toán
PDF attachment: Chứa thông tin thanh toán và "tài liệu hỗ trợ" — không có URL độc hại hay QR code trong PDF
Đây là điểm evasion quan trọng: hầu hết email security gateway scan attachment tìm URL/macro độc hại. PDF chỉ chứa thông tin thanh toán → clean. Attachment vượt qua scanner mà không bị flag.
Mục tiêu: thuyết phục bộ phận tài chính chuyển tiền vào tài khoản ngân hàng của attacker, được trình bày như tài khoản nhà cung cấp hợp lệ.
Phase 6 — Collection
Phishing: Credential thu thập realtime, attacker có thể sử dụng ngay (account takeover, lateral phishing)
BEC: Không có phase "collection" kỹ thuật — thành công là khi nạn nhân tự chuyển tiền
Phân tích kỹ thuật chi tiết
Tại sao Amazon SES nguy hiểm hơn phishing thông thường
Phần lớn email security gateway hoạt động theo nguyên tắc reputation-based và signature-based. Amazon SES phá vỡ cả hai lớp phòng thủ này:
| Cơ chế phòng thủ thông thường | Hiệu quả vs. SES abuse |
|---|---|
| SPF check | ❌ Fail — email qua SES pass SPF của Amazon |
| DKIM signature | ❌ Fail — Amazon ký email bằng key của họ, DKIM hợp lệ |
| DMARC alignment | ❌ Fail — alignment pass khi From domain align với Amazon |
| IP reputation blocklist | ❌ Fail — IP Amazon SES không thể blocklist (quá nhiều false positive) |
| Domain reputation | ❌ Fail — amazonaws.com là domain tin cậy nhất trên internet |
| URL scanner | ⚠️ Partial — nếu link trỏ trực tiếp đến domain phishing; nhưng redirect qua amazonaws.com có thể qua |
| Attachment scanner | ❌ Fail (với BEC) — PDF không chứa payload độc hại |
Chỉ có behavioral analysis và AI-based content analysis mới có khả năng phát hiện, nhưng không phải mọi tổ chức đều triển khai lớp này.
Các vector leak phổ biến nhất theo thứ tự mức độ xuất hiện:
GitHub public repo — developer push
.envfile hoặc config chứa credential; ngay cả khi đã xóa, GitHub history vẫn cònDocker Hub — image public với credential baked vào layer;
docker historyhoặc layer extraction có thể recoverPublic S3 bucket — file config hoặc backup upload nhầm vào bucket không có access control
CI/CD log — pipeline log export key ra stdout, log được store public
Paste sites và forum — developer share code debug mà không sanitize credential
TruffleHog tự động scan tất cả các nguồn trên với pattern matching cho AWS key format. Công cụ này hoàn toàn hợp pháp và được dùng rộng rãi trong DevSecOps — nhưng attacker dùng nó theo chiều ngược lại.
Mẫu phishing thực tế — DocuSign Notification
Email headers của một mẫu được Kaspersky phân tích xác nhận nguồn gửi qua SES:
Tất cả authentication check: pass. Không có gì khả nghi trong header.
Nội dung email giả mạo thông báo có tài liệu chờ ký. Link trong email:
Nạn nhân thấy amazonaws.com → click → landing page phishing yêu cầu đăng nhập.
Mẫu BEC thực tế — Invoice Fraud
Email BEC được thiết kế kỹ: thread được fabricate bao gồm chuỗi trao đổi giả giữa "nhân viên" và "nhà cung cấp" từ vài ngày trước, với nội dung về hóa đơn cụ thể, số tiền cụ thể, và lý do thanh toán gấp.
Email cuối trong thread — gửi đến bộ phận tài chính — yêu cầu "xử lý gấp vì nhà cung cấp cần thanh toán trước hạn". PDF đính kèm chứa:
Số hóa đơn
Số tài khoản ngân hàng thay thế (của attacker)
"Chứng từ hỗ trợ" giả
Không có malware. Không có link độc hại. Mọi scanner đều clean. Mồi nhử duy nhất là social engineering — áp lực thời gian, thẩm quyền giả, và định dạng email trông legitimate.
MITRE ATT&CK Mapping
| Tactic | Technique ID | Technique Name | Ghi chú |
|---|---|---|---|
| Resource Development | T1552.001 | Credentials in Files | Scan GitHub/Docker/S3 cho IAM key |
| Resource Development | T1583.006 | Web Services | Lợi dụng SES thay vì tự build mail infrastructure |
| Initial Access | T1566.001 | Spearphishing Attachment | BEC với PDF attachment |
| Initial Access | T1566.002 | Spearphishing Link | Phishing via redirect link |
| Collection | T1056.003 | Web Portal Capture | Thu credential qua fake login form |
| Impersonation | T1534 | Internal Spearphishing | BEC giả mạo nội bộ |
| Defense Evasion | T1036 | Masquerading | Dùng legitimate domain (amazonaws.com) |
| Defense Evasion | T1027 | Obfuscated Files | Redirect chain ẩn destination thực |
| Exfiltration | T1041 | Exfiltration Over C2 Channel | Credential gửi về attacker server |
Nhận định
"Living off Trusted Services" — Vũ khí phòng thủ bị vô hiệu hóa
Xu hướng này không mới — chúng tôi đã thấy attacker lạm dụng Microsoft 365 SMTP relay, Google Workspace, SendGrid từ trước. Amazon SES chỉ là bước tiếp theo trong cùng một playbook: khai thác trust mà tổ chức và vendor đã xây dựng suốt nhiều năm.
Điều đáng lo ngại không phải là kỹ thuật của attacker — mà là giới hạn cơ bản của phòng thủ dựa trên reputation. SPF/DKIM/DMARC được thiết kế để xác thực ai gửi email, không phải email có ý định lừa đảo hay không. Khi attacker sử dụng chính hạ tầng của Amazon để gửi, ba lớp xác thực này mất toàn bộ ý nghĩa phân biệt.
Tại sao BEC qua SES đặc biệt nguy hiểm
BEC không phụ thuộc vào malware hay kỹ thuật khai thác. Nó tấn công vào quy trình nghiệp vụ và con người. PDF không chứa payload độc hại — đây là thiết kế cố ý, không phải thiếu sót. Kẻ tấn công hiểu rằng email scanner hiện tại không thể phân biệt được PDF chứa số tài khoản giả với PDF hợp lệ nếu format trông professional.
Các tổ chức chưa có quy trình xác nhận giao dịch tài chính qua kênh thứ hai (phone call, app riêng) là mục tiêu lý tưởng.
Mức độ rủi ro với tổ chức tại Việt Nam
Có ba yếu tố khiến tổ chức Việt Nam dễ chịu ảnh hưởng hơn mức bình thường:
Thứ nhất, adoption AWS đang tăng mạnh trong cộng đồng developer Việt Nam — cùng với đó là thói quen vận hành chưa trưởng thành: hardcode credential trong code, để long-term IAM key tồn tại vĩnh viễn, không xoay vòng key định kỳ. Theo quan sát của chúng tôi qua các engagement pentest và red team, tỷ lệ tìm thấy AWS credential trong git history của khách hàng doanh nghiệp vẫn còn đáng kể.
Thứ hai, bộ phận tài chính tại các SME Việt Nam thường chưa có quy trình xác nhận chuyển khoản qua kênh thứ hai. Một email "gấp, từ sếp, có tài liệu đính kèm" là đủ để kích hoạt hành động.
Thứ ba, nhiều tổ chức vẫn dùng email security gateway chỉ dừng ở mức anti-spam/anti-virus cơ bản — không có behavioral analysis hay AI content scoring. Với SES abuse, đây là khoảng trống nguy hiểm.
Pattern lớn hơn: Zero-cost Credential Weaponization
Attacker đang thực hiện điều mà trong giới gọi là credential arbitrage — thu thập key bị lộ từ nguồn thứ ba (miễn phí), dùng để blast phishing với chi phí gần bằng 0, scale không giới hạn. Nếu một key bị thu hồi, công cụ scan tự động tìm key tiếp theo. Đây là mô hình tấn công có margin cực cao và rủi ro thấp cho attacker.
Khuyến nghị
Không tin tưởng tuyệt đối vào email “hợp pháp”
Kiểm tra kỹ ngữ cảnh email
Xác minh người gửi thật sự
Không click ngay vào link đăng nhập
Không mở file đính kèm đáng ngờ dù email có vẻ “chính thống”
Luôn xác minh yêu cầu tài chính qua kênh khác
Luôn xác minh qua điện thoại hoặc họp trực tiếp
Không thay đổi tài khoản ngân hàng chỉ dựa trên email
Áp dụng quy trình dual approval cho chuyển khoản
Thiết lập callback verification cho giao dịch lớn
Cảnh giác với trang đăng nhập giả mạo
Kiểm tra domain thật sự trước khi nhập mật khẩu
Không đăng nhập từ link trong email
Truy cập trực tiếp website bằng bookmark
Quan sát kỹ URL redirect bất thường
Bật Multi-Factor Authentication (MFA)
Không lưu AWS Keys trong source code
Giám sát bất thường trên AWS SES
Áp dụng Zero Trust cho email nội bộ
Đào tạo nhận diện phishing thường xuyên, hiện triển khai:
Phishing simulation định kỳ
Red team email exercises
Incident reporting culture
Tham khảo
https://securelist.com/amazon-ses-phishing-and-bec-attacks/119623/
https://cyberpress.org/attackers-abuse-amazon-ses/
https://gbhackers.com/attackers-exploit-amazon-ses/
https://www.bleepingcomputer.com/news/security/researchers-report-amazon-ses-abused-in-phishing-to-evade-detection/
