Subdomain takeover là tình huống một actor bên ngoài có thể kiểm soát nội dung hoặc dịch vụ được phục vụ dưới một subdomain hợp lệ của tổ chức, thường do DNS vẫn trỏ tới một tài nguyên third-party đã bị xóa hoặc không còn được owner kiểm soát. Đây là bước tiếp theo của một dangling DNS condition khi resource đích thực sự có thể bị người khác claim. Một case thực tế xem Subdomain Takeover từ Dangling DNS.
Microsoft cảnh báo dangling DNS có thể dẫn tới subdomain takeover và các tác động như phishing, cookie exposure hoặc lạm dụng uy tín của hostname hợp lệ. Vì vậy, việc đánh giá takeover phải tách rõ ba trạng thái: record dangling, dependency claimable và takeover đã được xác minh.
Hiểu Subdomain Takeover và điều kiện exploit
Subdomain takeover là gì?
Subdomain takeover là việc một bên không được ủy quyền giành khả năng phục vụ nội dung hoặc dịch vụ dưới một subdomain thuộc namespace của tổ chức. Trường hợp phổ biến là CNAME vẫn trỏ tới SaaS/cloud resource đã deprovision, trong khi provider cho phép account khác đăng ký resource cùng identifier.
Điều kiện nào tạo ra subdomain takeover?
Thường cần đồng thời các yếu tố:
- Subdomain của tổ chức vẫn có DNS record active.
- Record trỏ tới external resource/service.
- Resource intended không còn tồn tại hoặc owner không còn kiểm soát.
- Provider cho phép người khác claim identifier/hostname tương ứng.
- DNS vẫn route traffic tới resource mới được claim.
Nếu thiếu yếu tố claimability, record có thể chỉ là dangling DNS hoặc outage chứ chưa phải takeover vulnerability.
Dangling DNS và subdomain takeover khác nhau thế nào?
| Trạng thái | Evidence chính | Kết luận |
|---|---|---|
| Dangling DNS | Record còn, dependency đích không còn | Lifecycle/misconfiguration finding |
| Claimable | Provider cho phép actor khác đăng ký resource tương ứng | Takeover risk có evidence mạnh |
| Takeover | Actor thực sự kiểm soát content/service dưới subdomain | Confirmed compromise hoặc authorized proof |
Xem nền tảng tại Dangling DNS là gì?.
Những loại DNS dependency nào thường cần kiểm tra?
CNAME tới SaaS hoặc PaaS
Static hosting, app platform, helpdesk, marketing tool, documentation platform và CDN là các use case phổ biến. Risk phụ thuộc cách provider bind custom domain và resource ownership.
Cloud storage hoặc website endpoint
Nếu bucket/site identifier có thể được tạo lại bởi account khác sau khi resource cũ bị xóa, DNS legacy có thể trở thành đường takeover.
Delegated NS
Subdomain được delegate sang authoritative DNS bên ngoài nhưng zone/provider đã bị bỏ. Nếu infrastructure đích có thể bị actor khác kiểm soát, impact có thể rộng hơn một CNAME đơn lẻ.
Released IP hoặc external endpoint
A/AAAA trỏ tới IP được tái cấp phát cũng có thể tạo exposure, nhưng mechanics và khả năng exploit phụ thuộc cloud/network provider. Không nên gọi mọi stale IP là subdomain takeover.
Impact và trust boundary của Subdomain Takeover
Subdomain takeover có thể gây impact gì?
Phishing dưới hostname tin cậy
Attacker có thể phục vụ trang giả trên subdomain nhìn hợp lệ với user và hệ thống lọc.
Cookie và web trust boundary
Nếu cookie scope hoặc application policy cho phép subdomain tương tác với session/data nhạy cảm, takeover có thể làm tăng impact. Cần đánh giá cookie flags, Domain attribute, CORS, OAuth redirect và trust relationship thực tế.
Content injection và brand abuse
Subdomain bị chiếm có thể được dùng để host nội dung trái phép, scam hoặc malware, gây ảnh hưởng uy tín và incident response.
Email hoặc service abuse
Nếu takeover liên quan DNS record khác ngoài web, tác động có thể mở rộng tới mail/service routing. Phải đánh giá từng record thay vì assume mọi takeover chỉ là website defacement.
Phát hiện và xác minh Subdomain Takeover an toàn
Cách phát hiện subdomain takeover
1. Inventory subdomain và DNS record
Ưu tiên CNAME, delegated NS và external A/AAAA. Gắn service owner và dependency để biết hostname nào còn intended. Nếu cần workflow audit rộng hơn cho ownership, TLS, cookie, CORS và OAuth, xem Kiểm tra Subdomain Security.
2. Resolve chain
Ghi CNAME chain, authoritative answer, HTTP/TLS response và error signature nếu có. Một provider-specific error có thể là signal nhưng chưa phải proof.
3. Đối chiếu resource inventory
Kiểm tra project, subscription, account hoặc resource tương ứng có còn tồn tại và còn thuộc owner không.
4. Xác minh claimability bằng evidence phù hợp
Dùng documentation hiện hành của provider, internal test environment hoặc proof được phép. Không nên tự ý claim production resource third-party nếu scope không cho phép.
5. Đánh giá impact
Xem hostname trust, traffic, cookie scope, authentication integration, OAuth redirect, CORS, email và brand exposure để chấm severity.
Có nên claim subdomain để chứng minh vulnerability?
Chỉ khi được authorization rõ trong Rules of Engagement. Việc tạo resource và phục vụ content dưới hostname production có thể chặn traffic hợp lệ, thu nhận request hoặc ảnh hưởng user. Một security audit không nên biến validation thành incident.
Nếu không được phép claim, report có thể dùng evidence chain: DNS record → resource missing → provider claimability/documentation → owner confirmation → impact analysis. Confidence cần được ghi rõ thay vì giả vờ “confirmed takeover”.
False positive thường xuất hiện ở đâu?
Error page nhưng resource vẫn reserved
Một số provider giữ custom domain binding hoặc identifier sau khi app tạm dừng. Error page không có nghĩa người khác claim được.
NXDOMAIN ở target
Target không resolve có thể chỉ là outage hoặc decommission. Phải kiểm tra allocation model của provider.
Fingerprint cũ
Danh sách takeover fingerprints có thể lỗi thời vì provider thay đổi onboarding và domain verification. Luôn xác minh behavior hiện tại.
Custom domain cần ownership verification
Nhiều provider yêu cầu TXT/token verification trước khi bind domain. Điều này có thể làm dangling record không còn claimable dù error signature vẫn giống trước đây.
Remediation và incident response
Remediation subdomain takeover
Nếu subdomain không còn cần
Xóa DNS record hoặc delegation sau khi snapshot và xác minh dependency không còn. Sau đó read-back public DNS và kiểm tra cache/TTL.
Nếu subdomain vẫn cần
Khôi phục hoặc provision resource vào account đúng owner, hoàn tất domain binding/verification, rồi kiểm tra nội dung và TLS certificate.
Nếu takeover đã xảy ra
Xử lý như incident: bảo toàn evidence, contain DNS/resource, review account access, log, certificate, request traffic và các trust relationship liên quan. Không chỉ xóa record rồi đóng incident.
Có cần revoke TLS certificate sau takeover không?
Tùy evidence. Nếu attacker đã kiểm soát subdomain và có khả năng lấy certificate hợp lệ, cần inventory certificate/CT evidence và đánh giá revocation/rotation theo CA/provider workflow. Không nên assume HTTPS ngăn takeover; Microsoft cũng lưu ý actor kiểm soát subdomain có thể có được certificate hợp lệ trong một số tình huống.
Monitoring sau remediation
Sau khi remove/repoint record, theo dõi DNS change và target state cho tới khi public resolver phản ánh intended state. Nếu root cause là decommission workflow, cần sửa process để lần xóa resource sau không tái tạo dangling DNS.
Xem thêm DNS Change Monitoring và Audit DNS Record.
Phòng ngừa, severity và evidence
Cách ngăn subdomain takeover từ lifecycle
- DNS cleanup là bước bắt buộc khi decommission resource.
- Không xóa cloud/SaaS resource trước khi xử lý DNS dependency nếu quy trình provider yêu cầu.
- Gắn owner cho subdomain.
- Inventory external CNAME/NS.
- Review vendor offboarding.
- Monitor target availability và DNS drift.
- Dùng provider domain-verification feature khi có.
- Không giữ test hostname vô thời hạn.
- Audit định kỳ dangling DNS.
- Có incident runbook cho takeover.
Subdomain takeover nên được chấm severity thế nào?
Severity không nên cố định theo tên vulnerability. Cần xem takeover đã confirmed hay chỉ claimable, hostname có traffic không, cookie/auth trust ra sao, subdomain có dùng trong email/OAuth/CORS không, attacker có thể phục vụ arbitrary content không và remediation có dễ không.
Một subdomain test không traffic và một login-related subdomain có trust relationship sâu có thể cùng là takeover nhưng impact hoàn toàn khác.
Evidence tối thiểu cho finding
- Subdomain và DNS record/value.
- Authoritative/public resolution result.
- Target service/provider.
- Resource ownership state.
- Claimability evidence.
- HTTP/TLS response nếu relevant.
- Traffic/business criticality.
- Cookie/auth/CORS/OAuth dependency nếu có.
- Timestamp.
- Remediation và rollback.
Checklist kiểm tra Subdomain Takeover
- Resolve subdomain.
- Ghi CNAME/NS chain.
- Xác định external provider.
- Kiểm tra resource còn thuộc owner.
- Xác minh claimability.
- Không claim nếu chưa authorized.
- Đánh giá cookie/auth/CORS/OAuth trust.
- Đánh giá traffic và business impact.
- Snapshot DNS trước remediation.
- Delete/repoint hoặc restore resource.
- Read-back public DNS.
- Review certificate nếu takeover đã xảy ra.
- Sửa decommission process.
Để rà soát takeover risk cùng các lớp registrar, DNS, subdomain và TLS khác, xem Domain & DNS Security Checklist.
Safe-verification flow và evidence record mẫu
Artifact dưới đây là mẫu workflow an toàn, không phải bằng chứng rằng một subdomain cụ thể đã bị takeover.
- Observe: ghi authoritative/public DNS, CNAME/NS chain và timestamp.
- Correlate: đối chiếu resource inventory và owner; xác nhận resource intended còn tồn tại hay đã deprovision.
- Provider check: dùng tài liệu hiện hành hoặc test environment được phép để đánh giá allocation/claimability; không dựa riêng vào fingerprint.
- Impact review: kiểm tra traffic, cookie scope, OAuth redirect, CORS/allowlist, email/service dependency và brand exposure.
- Authorization gate: chỉ thực hiện proof có khả năng claim/bind resource khi Rules of Engagement cho phép rõ.
- Decision: phân loại
DANGLING_ONLY,CLAIMABLE_RISK,CONFIRMED_TAKEOVERhoặcNEEDS_INVESTIGATION. - Remediate & read-back: snapshot, delete/repoint/restore theo intended state, rồi xác minh public DNS và service state.
| Field | Evidence cần ghi |
|---|---|
| Hostname | Subdomain đang đánh giá |
| DNS chain | Record type/value, CNAME/NS chain, timestamp |
| Resource owner | Account/project/service owner hoặc UNKNOWN |
| Provider evidence | Documentation/test evidence về binding/claimability |
| Authorization | ROE cho phép hay không cho phép active proof |
| Trust/impact | Traffic, cookie, OAuth, CORS, email, brand |
| Classification | DANGLING_ONLY / CLAIMABLE_RISK / CONFIRMED_TAKEOVER / NEEDS_INVESTIGATION |
| Confidence | Low / Medium / High kèm lý do |
| Remediation | Delete, repoint, restore resource hoặc incident response |
| Validation | Read-back DNS/service sau remediation và PASS/FAIL |
Không dùng template này để tự ý claim tài nguyên của bên thứ ba hoặc thu nhận traffic production.
Nguồn kỹ thuật tham khảo
- Microsoft Learn — Prevent dangling DNS entries and avoid subdomain takeover
- NIST SP 800-81 Rev. 3 — Secure Domain Name System Deployment Guide
Kết luận
Subdomain takeover là kết quả của một trust relationship DNS bị bỏ quên và một dependency có thể bị actor khác claim. Không nên nhảy từ “record lỗi” tới “takeover confirmed” nếu chưa có evidence về claimability.
Phòng tránh takeover hiệu quả nhất nằm ở lifecycle: biết subdomain thuộc ai, resource nào đứng sau nó, decommission DNS và resource theo cùng quy trình, rồi monitor state drift. Khi validation cần claim resource, authorization và guardrail phải được khóa trước.