鍵マークは本物、サイトは偽物：.gh、.sl、.as レジストリハイジャックの解説

2026 年 10 月 6 日、Google の Chrome セキュリティチームは、素っ気ない題名と驚くべき中身の短い記事を公開しました。攻撃者が 3 つの国別コードドメインレジストリ、ガーナの .gh、シエラレオネの .sl、米領サモアの .as を掌握し、権威 DNS レコードを書き換え、有効な HTTPS 証明書を取得したというのです。対象は Google のドメインと、名指しされなかった「複数の世界的大手ブランド」でした。偽サイトの一つにたどり着いた人が見たのは、どこにも異常のない鍵マークだったはずです。

この事件はきちんと理解する価値があります。多くの人のウェブセキュリティの頭の中の地図が間違っている、まさにその一点の上に位置しているからです。鍵マークは「これは本物のサイトだ」という意味ではありません。それが意味するのはずっと狭いことで、9 月下旬、その 2 つの隔たりが実際に機能する攻撃になりました。

このページ全体を支えるのは 1 つの定義です。ドメイン認証（DV）の証明書が証明するのはただ 1 つ、発行の瞬間に申請者がそのドメインの DNS を支配していたことだけです。DNS の上にあるレジストリが盗まれれば、盗人は、地球上のあらゆる自動チェックにとって、所有者そのものです。

.gh、.sl、.as に何が起きたのか？

国別コードレジストリとは、その 2 文字ドメインの下にあるすべてを束ねるマスターデータベースを運営する組織です。.gh はアクラの Network Computer Systems が、.sl は通信会社 Sierratel が、.as は AS Domain Registry が運営しています。このデータベースを侵害すれば、個々のウェブサイトをハッキングする必要はありません。TLD の下の任意の名前を、自分が支配するサーバーへ委任し直せるからです。

起きたのはまさにそれで、レジストリは 1 つずつ落ちていきました。証明書は公開ログに、.gh の名前については 9 月 22 日、.sl は 9 月 25 日、.as は 9 月 27 日に現れました。リストを上から順に片づけていく一団のような足取りです。Google は、攻撃者が「権威 DNS レコードを改変し、複数の Google ドメインおよび他の組織に属するドメインを対象とする未認可の HTTPS 証明書を取得した」と述べ、自社のシステムには手が及んでいないとしています。

驚くほど多くのことが未公表のままです。レジストリがどう破られたのか、誰の仕業か、いずれかの証明書が実際のユーザーに対して使われたのか、被害者の全リスト。3 つのレジストリ運営者はいずれも、本稿執筆時点で声明を出していません。私たちは、それが実情である箇所には「未公表」と書きます。あなたが読むどの記事もそうあるべきです。

攻撃者はどうやって Google ドメインの有効な証明書を手に入れたのか？

丁寧に頼んだだけです。公開された Certificate Transparency の記録をもとに作業した The Hacker News は、google.com.gh、google.sl、google.as とその変種を含む、Google と YouTube の 7 つのドメインを対象とする少なくとも 12 枚の証明書を数えました。11 枚は Let’s Encrypt、1 枚は ZeroSSL の発行で、すべてドメイン認証です。Let’s Encrypt のスタッフはプロジェクトのフォーラムで発行と失効を確認しました。

ここが居心地の悪いところです。認証局はルールに従ったのです。Google 自身が、「影響を受けた証明書を発行した認証局（CA）が何か誤ったことをしたと考える理由はない」と書いています。ドメイン認証は、申請者にドメインの DNS の支配を証明するよう求めます。通常はレコードを 1 つ公開することで、です。攻撃者は DNS そのものでした。直面したすべての自動チェックを、機械が理解する狭い意味で、正直に通過したのです。

この層での警戒とはどういうものか、1 つの細部が示しています。精査されたログ記録では、少なくとも 9 月 10 日までさかのぼって、google.com.gh、google.sl、google.as の他のすべての証明書は Google 自身の CA である Google Trust Services から発行されていました。無関係な 2 つの認証局からの 12 枚の証明書は、それ自体が異常のしるしであり、公開ログの中に座って、誰かが見るのを待っていました。

誰が見つけ、どう止められたのか？

速い順に 3 つの仕組みです。

第一に、Certificate Transparency がそもそも証明書を可視化しました。2018 年 4 月 30 日以降、Chrome は公開 CT ログに開示されていない証明書をすべて拒否します。世界で最も使われているブラウザで機能する証明書が欲しい攻撃者は、その証明書が存在するという署名つきの自白を世界に手渡さざるを得ないのです。エコシステムの公開カウンターは 25 億枚を超えるログ済み証明書を示し、2025 年 9 月下旬には Let’s Encrypt だけでも 1 日に発行する証明書が 1,000 万枚を超えました。その干し草の山から 12 枚の悪い証明書を見つけ出すことこそ、ログ基盤の存在理由です。

第二に、Chrome は証明書を CRLSets という緊急ブロックリストで遮断しました。これはブラウザのコンポーネントアップデーターを通じて配布され、更新も再起動もなしに効力を持ちます。Chrome のセキュリティチームは何年も前から、オンラインの失効確認は必要なときにこそ失敗すると論じてきました。通信の途中に座る攻撃者は、その確認自体を遮断できるからです。だからブロックリストはブラウザとともに旅をします。Google はその後、CT のデータをさらに掘ってほかの被害者を特定し、それらの証明書も遮断し、可能だった範囲で影響を受けた組織に連絡したとしています。

第三に、それ以外の全員をカバーする遅い経路です。認証局は 12 枚すべてを失効させました。2 枚の .gh 証明書と 1 枚の ZeroSSL 証明書は 9 月 26 日、残りの 9 枚は 10 月 1 日です。証明書がログに現れてから死ぬまでの最短の窓は約 1 日半、最長はほぼ 1 週間でした。Google 自身の正直さを示す一文は引用に値します。「私たちの分析が影響を受けたすべてのドメインを特定したとは保証できず、Chrome の介入が Chrome 以外のユーザーを確実に守るわけでもありません」。

DNSSEC や CAA レコードならこれを防げたのか？

この事件は、この 2 つの頭字語が何を買ってくれて何を買ってくれないかの、ここ数年で最も鮮明な実演です。

まず DNSSEC。公開されているルートゾーンを確認すると、.gh と .sl はそもそも署名されていません。DNSSEC を導入しなかった多くの ccTLD の仲間です。この技術のレジストリでの普及率はヨーロッパで 99 パーセント、アフリカでは 65 パーセントです。そして .as は署名済みで、それでも乗っ取られました。DNSSEC がリゾルバーに検証させるのは、回答がレジストリの公開した内容と一致することです。レジストリ自体が敵の手にあるとき、そこは攻撃者のデータを、鍵もろとも公開します。嘘に付けられた署名も、有効な署名であることに変わりはありません。

ドメイン所有者がどの CA に発行を許すかを宣言する CAA レコードは、もう少し微妙な形をしています。ハイジャックの最中は役に立ちません。CAA レコードは攻撃者が支配するまさにその DNS の中に住んでいるからで、CAA の標準自体が、DNS を編集できる攻撃者はレコードを消せると認めています。ハイジャックの後では大きな意味を持ちます。現行の CA/Browser Forum の規則では、CA は完了済みの認証を最長 200 日再利用でき、この窓は 2027 年 3 月に 100 日、2029 年には 10 日に短縮されます。つまり DNS を失った攻撃者も、キャッシュされたチェックから新しい証明書を鋳造し続けられたのです。10 月 7 日までに、判明している Google の被害ドメイン 7 つはすべて、Google 自身の CA だけを指名する CAA レコードを備えました。それは、まさにこの泥棒の後に取り付ける錠前であり、本物の錠前です。

これは初めてのことなのか？

レジストリと DNS インフラへの攻撃は 1 つのジャンルであって、目新しいものではありません。日付つきの記録です。

ルートゾーンのおよそ 1,400 のドメインのうち、国別コード TLD は 316 あります。それぞれが国や地域に結びつき、それぞれが独自の予算、ガバナンス、セキュリティ体制を持ち、一部は民間の運営者が担っています。ガーナ自身の法定ドメイン当局は、そもそも誰が .gh を運営すべきかをめぐる公開の争いに何年も費やしてきました。ウェブの信頼モデルは、その一部を、これらの組織のうち最も資金のないところが優れたセキュリティチームを持っていることに預けているのです。

あなたには何が見え、実際に何があなたを守るのか？

その期間に偽サイトの一つへ誘導されていたとしても、あなたには何も見えなかったはずです。有効な証明書、いつもどおりの鍵マーク、警告は一切なし。Ars Technica の言葉を借りれば、この種の証明書の保持は「攻撃者が影響を受けたインフラに暗号学的になりすますことを可能にする」のです。実際に誰かがそこへ誘導されたのかどうかは、未公表の事実の一つです。

ユーザーを守ったのは、ユーザーが行った何かではありませんでした。義務化された CT の紙の証跡が証明書を暴き、CRLSets は何の操作も要さずに Chrome 内でそれらを殺し、失効が残りをカバーしました。もう 1 層、言及に値するものがあります。鍵をピン留めするネイティブアプリです。2017 年のトーゴの件では、Chrome のピン留めは不正な google.tg 証明書をどのみち拒否したはずで、Google 自身のアプリや多くの銀行アプリは今もピン留めしています。多層防御はここでは標語ではありません。具体的な積み重ねであり、9 月下旬にはそのすべての層が荷重を支えていました。

VPN はこれを防いでくれるのか？

誠実なセキュリティのページはこの問いに正確に答えます。正確な答えはこうです。この攻撃クラスには防げません。そのもっとありふれた親戚には防げます。そして、どちらがどちらかを知ることがすべてです。

VPN は TLS に関与しません。ブラウザはどのネットワーク上でも同じように、自分のトラストストアに照らして証明書を検証しますし、これらの証明書は有効でした。DNS の下流にあるあらゆるツールにはさらに分が悪いことに、攻撃者はレジストリの権威レコードそのものを汚染したので、地球上のすべての正直なリゾルバーが、VPN プロバイダーのリゾルバーも含めて、攻撃者の回答を配っていました。どの VPN も、私たちのものも含めて、これを遮断できたはずがありません。止めたのは、上で述べた CT、CRLSet、失効のパイプラインです。

VPN が守るのは、接続のあなた側です。敵対的なローカルネットワーク、偽のホットスポット、改ざんを行う ISP では、攻撃者はあなたの端末とインターネットの間に座り、DNS 回答を注入したりトラフィックを曲げたりします。VPN はあなたの DNS 解決とトラフィックの経路を暗号化トンネルの中へ移します。EFF のガイドの言葉では、あなたのトラフィックを「あなたの ISP とローカルネットワークの所有者（カフェやホテルなど）」から隠すのです。それが、ありふれた日常の攻撃面であり、私たちの VPN の暗号化と公共 Wi-Fi のセキュリティのガイドで扱っている面であり、そして、レジストリの攻撃者が一度も触れる必要のなかった層そのものです。2 つの保護は補完関係にあって、交換はできません。だからこそ私たちは、VPN をオンにしてもサイトに見えるものについての誠実なページを別に設けているのです。

ドメイン所有者は今、何をすべきか？

Google が組織に勧めるのは 2 つの手順で、ドメインを 3 つ持つ会社にも 3,000 持つ会社にも同じように当てはまります。保有するすべてのドメインについて、パークされたものや地域ドメインも含めて、Certificate Transparency のログを監視すること。12 枚の不正証明書は何日も公開ログの中にあり、見ようとする誰の目にも見えていました。そして、自社の CA を指名する厳格な CAA レコードを公開すること。理想的には ACME アカウントバインディングつきで、自社の CA でさえ自分のアカウントにしか発行できないようにします。CA の規則集は 3 つ目の手順を加えます。身に覚えのない証明書が現れたら Certificate Problem Report を提出すること。業界の Baseline Requirements は、CA にその調査と最初の所見の報告を 24 時間以内に行うよう義務づけています。

それ以外のみんなにとって、教訓はもっと小さく、しかし現実のものです。ブラウザを最新に保つこと。Chrome ユーザーを救ったブロックリストは、ブラウザとともに旅をするからです。鍵マークはそれが実際に意味するものとして扱うこと。それは転送中の暗号化についての表明であって、向こう側に誰がいるかの表明ではありません。そして、それぞれの道具をそれぞれの層に置くこと。証明書システムはサイトを認証し、VPN はトラフィックの通り道を守ります。9 月の事件に必要だったのは、後者がそもそも出番のないまま、前者が安全側に倒れることでした。