Subdomain takeover có thể xuất hiện khi một DNS record vẫn trỏ tới dịch vụ cloud/SaaS đã bị xóa. Khi dependency phía sau không còn tồn tại nhưng CNAME hoặc Alias vẫn được public DNS quảng bá, subdomain có thể rơi vào trạng thái dangling DNS và trở thành mục tiêu bị chiếm quyền nếu provider cho phép resource đó được claim lại.
Nguyên nhân thường nằm ở vòng đời vận hành: ứng dụng hoặc cloud resource đã bị deprovision nhưng CNAME/Alias chưa được dọn khỏi DNS zone. Khi target hostname có thể được một bên khác claim lại, traffic dành cho subdomain của doanh nghiệp có thể bị chuyển tới resource do attacker kiểm soát.
Microsoft gọi các record còn trỏ tới resource đã deprovision là dangling DNS entries và cảnh báo chúng có thể dẫn tới mất quyền kiểm soát nội dung, phishing, cookie harvesting và các rủi ro khác. GitHub Pages cũng cảnh báo custom domain còn cấu hình DNS trong khi Pages site đã bị disable hoặc unlink có thể tạo điều kiện cho domain takeover nếu chưa được verify. Nguồn: Microsoft Learn — Prevent dangling DNS entries và GitHub Docs — Verifying your custom domain.
Bối cảnh và dấu hiệu đầu tiên
Giả sử doanh nghiệp từng dùng promo.example.com để trỏ CNAME tới một dịch vụ cloud. Campaign kết thúc, cloud resource bị xóa nhưng DNS record không được dọn khỏi zone. Subdomain vẫn tồn tại công khai dù backend không còn thuộc quyền kiểm soát của doanh nghiệp.
Trong trạng thái này, người dùng nội bộ có thể chỉ thấy lỗi DNS hoặc trang service-not-found. Nhưng với attacker, đây là tín hiệu cần kiểm tra xem target hostname có thể được tạo lại hoặc claim bởi tài khoản khác hay không.
Những tín hiệu đáng chú ý
- CNAME trỏ tới hostname cloud/SaaS nhưng resource không còn tồn tại.
- DNS record không có owner hoặc service catalog tương ứng.
- Subdomain trả lỗi provider-specific như resource not found/unconfigured domain.
- Resource đã bị xóa nhưng decommission checklist không ghi nhận bước remove DNS.
- Domain verification token/TXT record không tồn tại hoặc đã bị xóa.
- Wildcard DNS hoặc nhiều subdomain cũ cùng trỏ tới dịch vụ bên thứ ba.
Investigation: từ dangling DNS đến khả năng takeover
Bước 1: xác minh DNS dependency có còn tồn tại không
Đầu tiên cần read-back authoritative DNS để xác định record hiện tại, target hostname và TTL. Sau đó đối chiếu target với cloud/service inventory để xác nhận resource còn tồn tại và có owner hay không.
Microsoft mô tả một flow điển hình: doanh nghiệp tạo resource cloud, trỏ CNAME từ subdomain tới resource đó, sau này xóa resource nhưng quên xóa CNAME. Record còn lại trở thành dangling DNS và có thể bị khai thác nếu provider cho phép hostname tương ứng được tái tạo hoặc claim. Nguồn: Microsoft Learn.
Bước 2: xác minh claimability, không chỉ nhìn lỗi provider
Một dangling record chưa tự động đồng nghĩa takeover khả thi. Nhiều provider có ownership verification, hostname reservation hoặc tenant-bound protection. Vì vậy cần tách hai câu hỏi: resource có bị deprovision hay không, và một tenant/account khác có thể nhận traffic cho hostname đó hay không.
Azure App Service hiện cung cấp domain verification ID và secure unique default hostnames để giảm rủi ro này. Microsoft khuyến nghị tạo TXT record asuid.{subdomain} khi map custom domain; nếu TXT verification tồn tại, subscription khác không thể validate custom domain nếu không có token phù hợp. Nguồn: Microsoft Learn — Prevent subdomain takeovers in App Service.
Bước 3: kiểm tra service-specific protection
GitHub Pages là một ví dụ khác về protection ở tầng dịch vụ. GitHub khuyến nghị verify custom domain; khi domain đã verify, chỉ repository thuộc owner/organization đó mới được dùng domain tương ứng. Nếu site bị disable nhưng DNS vẫn trỏ tới Pages và domain chưa verify, rủi ro takeover tăng lên. Nguồn: GitHub Docs.
Do đó, investigation phải hiểu cơ chế claim/verification của từng provider thay vì dùng một fingerprint chung cho mọi dangling DNS.
Khi nào có thể xác nhận subdomain takeover risk?
Không nên tuyên bố “takeover confirmed” chỉ vì CNAME trả NXDOMAIN hoặc provider error. Mức độ tin cậy chỉ đủ cao khi nhiều bằng chứng cùng khớp.
- DNS record còn tồn tại và trỏ tới resource/dependency đã deprovision.
- Không có owner/change request hợp lệ giải thích trạng thái hiện tại.
- Provider cho phép một account/tenant khác tạo hoặc claim target/resource tương ứng, hoặc không có ownership verification bảo vệ.
- Subdomain vẫn được public DNS advertise và traffic tiếp tục đi tới dangling target.
- Khi remove/repoint record hoặc restore resource ownership, exposure biến mất.
Remediation: loại bỏ dangling dependency an toàn
Containment trước tiên
- Nếu subdomain không còn cần dùng, remove DNS record sau snapshot/change approval.
- Nếu vẫn cần service, provision lại resource do doanh nghiệp kiểm soát trước rồi mới repoint DNS.
- Giữ hoặc thêm domain verification TXT/token khi provider hỗ trợ.
- Không tạo tạm resource dưới account cá nhân chỉ để “giữ chỗ”.
- Nếu có dấu hiệu attacker đã claim resource, chuyển sang incident response và kiểm tra content, cookie, OAuth/CORS, email hoặc secret exposure liên quan.
Microsoft khuyến nghị remove các CNAME trỏ tới FQDN không còn được provision, đồng thời điều tra xem compromise đã xảy ra hay chưa. Họ cũng khuyến nghị đưa việc remove DNS entry vào decommission checklist để tránh tái diễn. Nguồn: Microsoft Learn.
Giảm rủi ro tái diễn trong lifecycle
- Không xóa cloud/SaaS resource trước khi xử lý DNS dependency.
- Duy trì service catalog gồm FQDN, DNS record, owner và lifecycle state.
- Dùng verification token/domain ownership feature của provider khi có.
- Audit dangling CNAME định kỳ và sau mỗi migration/decommission.
- Hạn chế wildcard DNS nếu không có use case rõ ràng; GitHub cảnh báo wildcard có thể tăng takeover risk.
Kiến thức nền xem Dangling DNS là gì?, Subdomain Takeover là gì? và Kiểm tra Subdomain Security.
Validation sau remediation
| Kiểm tra | Kết quả mong đợi |
|---|---|
| Authoritative DNS | Không còn dangling target |
| Cloud/SaaS resource | Tồn tại và thuộc owner hợp lệ nếu vẫn sử dụng |
| Domain verification | TXT/token/verification vẫn hợp lệ khi provider hỗ trợ |
| HTTP/TLS response | Không còn provider error hoặc content ngoài kiểm soát |
| Service catalog | Owner và lifecycle state được cập nhật |
| Monitoring | Có cảnh báo khi DNS target không còn tồn tại hoặc ownership thay đổi |
Sau khi sửa, cần read-back DNS từ authoritative và public resolvers thay vì chỉ nhìn control panel. Xem Audit DNS Record để kiểm tra zone, dependency và propagation.
Bài học vận hành và bước tiếp theo
- Dangling DNS là lifecycle failure nhiều hơn là DNS syntax error.
- Resource deletion và DNS cleanup phải nằm trong cùng một decommission workflow.
- Provider verification/hostname reservation có thể giảm claimability nhưng không thay thế DNS hygiene.
- Wildcard DNS làm tăng phạm vi cần kiểm soát và có thể tạo takeover risk.
- Service catalog và owner rõ ràng giúp tìm record “mồ côi” nhanh hơn.
- Không kiểm thử takeover bằng cách claim tài nguyên thật ngoài phạm vi được phép; đủ bằng chứng để remediation an toàn quan trọng hơn exploitation.