Hackers who breached third-party operators running small country-code top-level domain (ccTLD) registries were able to rewrite authoritative DNS records, hijack domains, and obtain fraudulent HTTPS certificates for Google properties, according to a report published by BleepingComputer.
The incident did not involve a breach of Google's own systems. Instead, attackers gained control of the infrastructure behind a handful of ccTLDs and exploited the trust that certificate authorities, registrars, and downstream services place in that infrastructure — a pattern that makes supply-chain compromise, rather than any single victim, the defining feature of the story.
What happened
As reported by BleepingComputer, the attackers compromised third-party operators of the registries for the country-code namespaces of Ghana (.gh), American Samoa (.as), and Sierra Leone (.sl), and modified authoritative DNS records for domains registered under those namespaces.
With control of authoritative DNS in place, the attackers could point domains registered under those namespaces at infrastructure they controlled, for the duration of the intrusion. That redirect opened the door to a more damaging step: because domain control can be demonstrated through DNS-based validation, the attackers obtained unauthorized HTTPS certificates for several Google domains, removing the browser padlock as an early warning signal for users.
The result is a phishing and session-theft scenario that is far more convincing than a lookalike domain alone. A certificate issued by a trusted certificate authority for the actual domain name silences one of the few checks most users are trained to make, which is precisely why certificate issuance is usually treated as a validation control rather than an attack surface. In this case, that validation inherited the weakness of an upstream registry operator.
Why it matters
The broader lesson is one of inherited trust. Domain and DNS integrity is only as strong as the weakest operator in a TLD's chain — registry, registrar, reseller, DNS provider — and TLS certificate issuance inherits whatever weaknesses exist upstream in that chain. Brand-protection programs that monitor a handful of primary domains for typosquatting miss lookalikes registered under lesser-used ccTLDs, where registration friction, registry staffing, and third-party delegation are frequently thinner.
For Hong Kong IT teams, the incident is best read as a mirror rather than a warning about .hk itself. The exposure it illustrates — third-party write access to authoritative DNS, reseller and registry-operating arrangements, and certificate validation that leans on DNS state — applies to any ccTLD ecosystem, including Hong Kong's own, and to any organization that assumes its domain namespace is an inert asset rather than an actively delegated trust boundary.
The practical checklist
Security teams responding to this class of compromise typically converge on the same measures:
- DNSSEC, to prevent forged responses from being accepted downstream even when a registry or resolver is compromised.
- CAA (Certificate Authority Authorization) records, to constrain which certificate authorities are permitted to issue certificates for an organization's domains — the single most direct mitigation against the certificate-abuse stage of this attack.
- Certificate transparency log monitoring, to detect certificate issuance for domains the organization does not control, including under unfamiliar ccTLDs.
- Alerting on unexpected changes to NS, A, and CNAME records, ideally delivered outside the DNS provider's own control plane.
- Registry lock and an audit of third-party write access to authoritative DNS, covering resellers and outsourced operators as well as primary registrars.
BleepingComputer's account underscores a point the open-source and hosting communities have raised repeatedly: the trust graph that underpins the public internet's namespace is far larger than most domain owners realize, and the certificates users rely on are no more trustworthy than the registries that validate them.
據 BleepingComputer 發表的一份報告指出，入侵了多個小型國家及地區頂級域名（ccTLD）註冊局第三方營運商的黑客，得以改寫權威 DNS 記錄、劫持域名，並為 Google 的多個域名取得詐騙的 HTTPS 證書。
今次事件與 Google 自身系統無關。攻擊者取得的是數個 ccTLD 背後的基礎設施控制權，並利用證書簽發機構（CA）、域名註冊商及下游服務對該等基礎設施的信任——亦即說，這是一宗供應鏈入侵事件，而不是針對單一受害者的攻擊。
事件經過
據 BleepingComputer 報道，攻擊者入侵了加納（.gh）、美屬薩摩亞（.as）及塞拉利昂（.sl）三個國家及地區域名註冊局的第三方營運商，並修改了這些域名空間下已註冊域名的權威 DNS 記錄。
在掌握權威 DNS 控制權後，攻擊者即可在入侵期間，將這些域名空間下的域名指向自己控制的基礎設施。這一步重定向為接下來更嚴重的行為打開了門路：由於域名控制權可以透過基於 DNS 的驗證來加以證明，攻擊者遂為多個 Google 域名取得了未經授權的 HTTPS 證書，使瀏覽器掛鎖圖示不再是用戶可依賴的早期預警訊號。
這構成了一個釣魚及竊取用戶會話的場景，其說服力遠超一般的仿冒域名。由受信任的證書簽發機構為真實域名簽發的證書，足以令大多數用戶所熟悉的其中一項檢查失去作用——這正是證書簽發通常被視為一項驗證控制，而非攻擊面的原因。但在本案中，該項驗證沿襲了上游註冊局營運商的弱點。
事件的啟示
事件帶出的教訓，在於信任是會向上游傳遞的。域名及 DNS 的完整性，取決於整個頂級域名信任鏈中最薄弱的一個環節——註冊局、註冊商、代理商、DNS 服務商——而 TLS 證書的簽發，亦會繼承上游任何環節的弱點。品牌保護計劃通常只監察少數幾個主要域名的仿冒情況，因此往往會遺漏那些在較少人使用的 ccTLD 註冊的相似域名；這些域名空間的註冊門檻、註冊局人手安排以及第三方委託安排，通常都更為薄弱。
對香港 IT 團隊而言，這宗事件較適合作為一面鏡子來看，而非一項關於 .hk 域名本身的警告。事件所揭示的風險——第三方對權威 DNS 的寫入權限、代理商及註冊局營運安排，以及依賴 DNS 狀態的證書驗證——適用於任何 ccTLD 生態系統，包括香港自身的域名空間，亦適用於任何誤以為自己的域名空間是一項靜止不變的資產，而非一條處於活躍委託狀態的信任邊界的機構。
實務應對清單
面對這類入侵事件，安全團隊通常會集中採用同一類措施：
- DNSSEC，以確保即使註冊局或解析器遭入侵，被篡改的 DNS 回應也不會被下游系統接受。
- CAA（證書簽發授權）記錄，用以限制哪一間證書簽發機構獲授權為機構的域名簽發證書——這是應對本次攻擊中證書濫用環節最直接的一項緩解措施。
- 證書透明度日誌監察，以偵測機構未有控制的域名（包括在陌生的 ccTLD 下）的證書簽發情況。
- 就 NS、A 及 CNAME 記錄的意外變更設定警示，並盡量採用由 DNS 服務商控制範圍以外的途徑發出。
- 註冊鎖（registry lock），以及對權威 DNS 第三方寫入權限的檢視，涵蓋代理商、外判營運商及主要註冊商。
BleepingComputer 的報道帶出了一點，開源社群及託管服務業界早已多次提及：支撐互聯網公開域名體系的信任鏈，遠比大多數域名持有人所了解的龐大；而用戶所倚賴的證書，其可信程度不會高於負責驗證它們的註冊局。