Tấn công chiếm đoạt subdomain (subdomain takeover) là một kỹ thuật mà kẻ xấu khai thác các bản ghi DNS bị bỏ quên để chuyển hướng lưu lượng truy cập đến tài nguyên do chúng kiểm soát. Lỗi cấu hình này có thể gây ra những rủi ro nghiêm trọng về uy tín thương hiệu, lừa đảo phishing và tổn thất tài chính cho doanh nghiệp. AWS đã chia sẻ các phương pháp và công cụ giúp doanh nghiệp chủ động phát hiện, ngăn chặn và ứng phó hiệu quả với mối đe dọa này.
Theo Đội ngũ Ứng phó Sự cố Khách hàng của AWS (AWS CIRT), các tác nhân đe dọa đang tích cực quét các bản ghi CNAME công khai trỏ đến những tài nguyên không còn tồn tại để tìm kiếm cơ hội thực hiện tấn công chiếm đoạt subdomain.
Lưu ý: Kỹ thuật chiếm đoạt subdomain không khai thác lỗ hổng của các dịch vụ AWS. Nó lợi dụng một bản ghi DNS “lơ lửng” (dangling record) để chuyển hướng lưu lượng truy cập đến một tài nguyên do kẻ tấn công kiểm soát.
Subdomain takeover là gì và tại sao nguy hiểm?
Một cuộc tấn công chiếm đoạt subdomain xảy ra khi doanh nghiệp xóa một tài nguyên đám mây (như S3 bucket) nhưng quên không xóa bản ghi DNS (cụ thể là CNAME) đang trỏ đến nó. Bản ghi DNS này trở thành “lơ lửng”, trỏ đến một đích không còn tồn tại. Kẻ tấn công có thể lợi dụng điều này bằng cách tạo ra một tài nguyên mới với cùng tên chính xác đó trong tài khoản của chúng, qua đó chiếm quyền kiểm soát subdomain và phân phát nội dung độc hại.
Kỹ thuật này khả thi khi một bản ghi CNAME trỏ đến tài nguyên AWS sử dụng không gian tên DNS chia sẻ toàn cầu, nơi tên tài nguyên có thể được chọn bởi bất kỳ khách hàng AWS nào. Các tài nguyên AWS sau đây thuộc diện này:
- Amazon S3 (không gian tên toàn cầu): Tên bucket như
mybucket.s3.amazonaws.comlà duy nhất trên toàn cầu và có thể bị chiếm bởi tài khoản khác nếu bucket bị xóa. - Amazon CloudFront: Mặc dù tên miền phân phối như
d111111abcdef8.cloudfront.netdo AWS gán, nếu bạn xóa một distribution và khách hàng khác tình cờ nhận được cùng tên miền đó, bản ghi CNAME lơ lửng có thể trỏ đến nội dung của họ. - AWS Elastic Beanstalk: Tên môi trường như
myapp.elasticbeanstalk.comlà duy nhất toàn cầu và có thể bị chiếm nếu môi trường bị chấm dứt.
Các tác động tiềm tàng đối với doanh nghiệp bao gồm:
- Rủi ro danh tiếng: Doanh nghiệp mất kiểm soát nội dung được phân phát từ subdomain của mình, có thể là nội dung xấu độc, gây ảnh hưởng tiêu cực đến hình ảnh thương hiệu.
- Nguy cơ lừa đảo (phishing): Kẻ tấn công có thể dựng các trang web giả mạo để đánh cắp thông tin đăng nhập hoặc phát tán phần mềm độc hại cho người dùng tin tưởng vào tên miền của bạn.
- Bị chặn truy cập: Nếu subdomain bị các nhà cung cấp dịch vụ bảo mật gắn cờ vì hoạt động độc hại, nó có thể ảnh hưởng đến hoạt động kinh doanh của bạn.
- Tổn thất tài chính: Sự cố có thể gây gián đoạn dịch vụ và tốn kém chi phí để khắc phục.
Phân tích một kịch bản tấn công
Hãy xem xét một ví dụ phổ biến với Amazon S3. Ban đầu, bạn có một S3 bucket tên là subdomain.example được cấu hình để lưu trữ một trang web tĩnh, với endpoint là subdomain.example.s3-website-us-east-1.amazonaws.com.

Để người dùng dễ nhớ, bạn tạo một bản ghi CNAME trong Amazon Route 53, trỏ subdomain.example.com đến endpoint của S3 bucket.

Sau một thời gian, quản trị viên quyết định ngừng sử dụng trang web này và xóa S3 bucket đi, nhưng lại quên xóa bản ghi CNAME trong Route 53.

Lúc này, bản ghi DNS đã trở nên “lơ lửng”. Kẻ tấn công phát hiện ra tình trạng này, chúng liền tạo một S3 bucket mới với cùng tên subdomain.example trong tài khoản AWS của chúng. Giờ đây, mọi truy cập đến subdomain.example.com sẽ bị chuyển hướng đến nội dung độc hại do kẻ tấn công kiểm soát, trong khi người dùng cuối không hề hay biết.

Chủ động phát hiện lỗ hổng với AWS Config
Để phát hiện sớm các rủi ro, AWS khuyến nghị sử dụng AWS Config để liên tục giám sát các bản ghi CNAME trong Route 53 và xác minh rằng tài nguyên đích có thực sự tồn tại trong tài khoản của bạn hay không. Cách tiếp cận này ưu việt hơn việc chỉ kiểm tra phân giải DNS, vì nếu kẻ tấn công đã chiếm quyền, việc phân giải vẫn thành công nhưng lại trỏ đến tài nguyên của chúng.
Bằng cách truy vấn kho cấu hình của AWS Config, giải pháp này kiểm tra xem tài nguyên có tồn tại trong danh mục của chính doanh nghiệp bạn hay không, giúp xác định chính xác các bản ghi CNAME lơ lửng ngay cả khi cuộc tấn công đã xảy ra.
AWS đã công bố một giải pháp tham khảo mã nguồn mở để tự động hóa quy trình này. Giải pháp này triển khai một hàm Lambda để quét các bản ghi CNAME, đối chiếu với kho AWS Config, và tạo ra các phát hiện (finding) mức độ HIGH trong AWS Security Hub khi phát hiện bản ghi lơ lửng. Nó cũng có thể gửi thông báo qua SNS để cảnh báo đội ngũ bảo mật.

Các biện pháp ngăn chặn và ứng phó
Phòng chống tấn công chiếm đoạt subdomain đòi hỏi cả quy trình phòng ngừa và khả năng phản ứng nhanh.
Phòng ngừa: Quy trình vận hành chuẩn (SOP)
Biện pháp hiệu quả nhất là xây dựng một quy trình vận hành chuẩn cho việc gỡ bỏ tài nguyên, đảm bảo bản ghi DNS được xóa trước khi xóa tài nguyên gốc:
- Xóa bản ghi CNAME trỏ đến tài nguyên bạn dự định gỡ bỏ.
- Chờ cho DNS TTL hết hạn. Điều này đảm bảo các DNS resolver trên internet cập nhật thay đổi. Nếu bạn xóa tài nguyên trước khi TTL hết hạn, kẻ tấn công có thể chiếm tên tài nguyên trong khi các bản ghi CNAME được cache vẫn đang trỏ về đó.
- Gỡ bỏ tài nguyên (S3 bucket, môi trường Elastic Beanstalk, v.v.).
- Kiểm tra lại DNS để xác nhận bản ghi đã được xóa hoàn toàn.
Nguyên tắc vàng: Luôn xóa DNS trước, đợi TTL, sau đó mới xóa tài nguyên.
Phòng ngừa: S3 Account Regional Namespaces
Vào tháng 3 năm 2026, AWS đã ra mắt account regional namespaces cho S3 bucket, giúp giảm thiểu nguy cơ này. Tuy nhiên, doanh nghiệp cần lưu ý các giới hạn quan trọng:
- Không ảnh hưởng đến bucket hiện có: Các bucket đã tạo trong không gian tên toàn cầu không thể di chuyển và vẫn có nguy cơ bị chiếm đoạt.
- Không gian tên toàn cầu vẫn là mặc định: Khi tạo bucket mới, người dùng cần chủ động chọn tùy chọn mới này.
- Cần cập nhật mẫu IaC: Các mẫu Infrastructure-as-Code (CloudFormation, Terraform) hiện có cần được cập nhật để sử dụng không gian tên mới.
Do đó, giải pháp phát hiện bằng AWS Config vẫn rất quan trọng, đặc biệt với các hạ tầng S3 cũ và các dịch vụ khác như CloudFront và Elastic Beanstalk.
Ứng phó: Thông báo và khắc phục
Khi phát hiện một bản ghi lơ lửng, giải pháp tham khảo của AWS sẽ tự động tạo cảnh báo trong Security Hub và gửi thông báo qua SNS. AWS khuyến nghị nên bắt đầu với quy trình phát hiện và thông báo, trong đó một thành viên của đội ngũ sẽ xem xét và phê duyệt việc xóa bản ghi DNS. Việc tự động xóa hoàn toàn có thể mang rủi ro nếu có trường hợp dương tính giả.
Kết luận
Chiếm đoạt subdomain là một lỗi cấu hình có thể phòng tránh nhưng lại gây ra hậu quả đáng kể. Cách tiếp cận phòng thủ theo lớp là hiệu quả nhất: xây dựng quy trình vận hành chặt chẽ, sử dụng các công cụ tự động như AWS Config để phát hiện sai sót, và thiết lập quy trình ứng phó nhanh chóng. Đảm bảo “vệ sinh” DNS tốt là tuyến phòng thủ đầu tiên và quan trọng nhất để bảo vệ tài sản số của doanh nghiệp trên môi trường cloud.


