perl.com ドメイン盗難事件：30年の歴史を持つコミュニティの玄関口がひそかに奪われた顛末

ドメインの中には、名前の皮をかぶったインフラが存在する。perl.com はまさにそのひとつだ。マーケティング資産でもなく、誰かが昨年立ち上げたブランドでもない。Webの黎明期からPerlプログラミングコミュニティが寄り集まってきた「インターネットの調度品」であり、ドキュメント・記事・言語の公式顔としての正面玄関だった。

だから、2021年1月27日の朝、その玄関口が突然よそ者のものになっていたとき、それは巧みなブランド戦略でも合意の上での売却でもなかった。盗難だった。ドメインは数ヶ月前に正当な所有者の管理下からひそかに引き剥がされ、複数のレジストラを経由して転々とし、マルウェアの配布履歴を持つIPアドレスに向けられていた。Perlコミュニティのネットワーク運用担当者は率直に述べた：「perl.comドメインが今朝ハイジャックされ、現在はパーキングサイトを指しています。」

これはDomain Maydayシリーズの第19話（EP19）だ。サーバーに一切侵入することなく、30年の歴史を持つコミュニティドメインが盗まれ、そして取り戻されるまでの物語である。

1990年代初頭から保持されていたドメイン

この盗難を理解するには、その体制がいかに「普通」であったか——そしてその普通さこそが脆弱性だったか——を理解しなければならない。

perl.comは堅牢な企業の金庫に保管されていたわけではない。長く続く多くのドメインと同じように、信頼できる一人の人物によって、主流のレジストラで、毎年粛々と更新されていた。サイトの編集者であるbrian d foyは、後に自ら書いた事件の経緯の中でその来歴をこう述べている：「このドメインは1990年代初頭に登録され、まもなくTom Christiansenが管理権を与えられ、基本的には登録料を払い続けていただけです。」

これがインターネット上の重要なドメインの大部分の実態だ。一人の人間、レジストラへのログイン、そして30年間ひっそりと料金を払い続けること。これは完璧に機能する——レジストラのアカウント自体が標的になるまでは。

2021年1月27日：玄関の鍵が変えられた日

最初の公開警報は、Perlコミュニティのインフラを運営する人々から発せられた。Perl NOC（ネットワーク運用センター）のブログは、ドメインが「今朝」ハイジャックされ、あるべきでない場所を指すようになったと投稿した。単なるパーキングページよりも深刻だったのは、運営者が「過去にマルウェアを配布したサイトと関連している可能性を示すシグナルがある」と警告したことだ。

brian d foyは同日、公開の場でこの件を取り上げた。事件を報じた記事は状況を端的に伝えている：「1月27日、PerlプログラミングライターでPerl.comの編集者であるbrian d foyは、perl.comドメインが突然別人名義で登録されているとツイートした。」

コミュニティの対応は迅速かつ実用的だった。奪還作業が始まる間、NOCは読者をバックアップへ誘導した：「コンテンツをお探しの場合は、perldotcom.perl.orgをご覧ください。」 正式なドメイン名は失われたが、コンテンツはアクセス可能なまま維持された。

危機に晒されたもの：マルウェアと紐付くIPアドレス

盗まれたドメインの危険性は、そのドメインが持つ信頼の重みに比例する——そしてperl.comは非常に大きな信頼を担っていた。何百万人もの開発者、チュートリアル、CPANのツール群、そしてウェブ上の無数の古いリンクがそこを指していた。この名前を支配する者が、その信頼の向き先を支配できるのだ。

そして新しい「所有者」は、それを無害な場所に向けなかった。BleepingComputerが記録したように、「ドメイン名perl.comは盗まれ、マルウェアキャンペーンと関連するIPアドレスを指すようになった。」

技術的な痕跡は具体的だった。DNSレコードが書き換えられ、「ドメインに割り当てられたIPアドレスが151.101.2.132からGoogle CloudのIPアドレス35.186.238[.]101に変更された。」 その転送先には過去があった：「2019年、IPアドレス35.186.238[.]101は、現在は活動を停止したLockyランサムウェアのマルウェア実行ファイルを配布するドメインと紐付けられていた。」

この二つの事実を重ね合わせれば、危険性は明らかだ。開発者たちが反射的に信頼する名前が、マルウェアの配布履歴を持つIPアドレスを指すようになるというのは、普段はなかなか騙せないセキュリティ意識の高い技術者を騙すための、ほぼ完璧なセットアップだった。

経緯：サーバーではなく、レジストラのアカウントが狙われた

この事件が注釈ではなく教科書的な事例となっている理由はここにある：perl.comのWebサーバーはハックされていないし、DNSのパスワードも推測されていない。攻撃は一段上のレイヤー——レジストラ、すなわちドメインの所有者記録を保持する企業——で発生した。

brian d foyは事後分析の中で、その推定メカニズムを率直に説明した：「Network Solutionsへのソーシャルエンジニアリング攻撃があったと考えています。偽造書類などを使ったものです。」 報道各社も同様に報じた：この盗難は「レジストラのNetwork Solutionsを騙して、正当な権限なしにドメインの記録を変更させたソーシャルエンジニアリング攻撃」だったと。

最も不穏なのはそのタイムラインだ。コミュニティが気づいたのは1月だったが、実際の侵害ははるか以前だった。ドメイン弁護士のJohn Berryhillによるフォレンジック調査が侵害の実際の日付を数ヶ月前までさかのぼって特定した。perl.comのアカウント記録によれば、「John Berryhillがツイッターでフォレンジック調査を公開し、侵害が実際には9月に発生していたことを示した。」 SecurityWeekも攻撃者の忍耐強さを確認した：「攻撃は2020年9月に行われた」——被害が表面化するおよそ4ヶ月前のことだ。

なぜこれほど長く待ったのか？ドメイン移転のルールが忍耐を報いるからだ。「ICANNは連絡先情報の更新後60日間、ドメインの移転を禁止している。」 9月にレジストラのアカウントをひそかに乗っ取った攻撃者は、すぐにはドメインを移転できない——だから彼らは待ち続け、ロックが解除されてから動いた。

動き出したとき、彼らは奪還を難しくするために、レジストラと国境をまたいでドメインを「洗浄」した。The Registerは最初の移転先を記録した：「ドメインは12月にBizCNレジストラへ移転されたが、ネームサーバーは変更されなかった。」 BleepingComputerは地理的な経路も追跡した：ドメインは「Network Solutionsにあった2020年9月に盗まれ、クリスマスの日に中国のレジストラへ移転された」のち、1月に最後の移転が行われ、「ドメインは再び別のレジストラ、Key Systems GmbHへ移転された。」

そして彼らは現金化を試みた。ドメインを新たな場所に移した後、「不正な登録者はドメイン市場Afternicで19万ドルでドメインを売ろうとした。」 30年の歴史を持つコミュニティ資産が、書類一枚で盗まれ、まるで中古家具のように売りに出されたのだ。

奪還：書類でなされた盗難を、書類で取り返す数週間

盗難を可能にした仕組み——レジストラ、レジストリ、そして所有権記録——が、唯一の帰還経路でもあった。再確保すべきサーバーはなく、適用すべきパッチもない。Tom Christiansenが本物の所有者であり、新たな「所有者」が詐欺師であることを、レジストラとレジストリの連鎖を通じて証明しなければならなかった。

その作業は数日以内に始まった。1月30日までに、Perl NOCは「Network SolutionsがPerl.comドメインの奪還に向けて、正当な登録者であるTom Christiansenと協力している」と報告した。この取り組みは「最終的に、2月初旬にドメインが前の所有者であるTom Christiansenに返還されることとなった。」

しかし「返還」は「解決」を意味しなかった。brian d foyの言葉は、安堵と未解決の課題を同時に捉えている：「Perl.comドメインはTom Christiansenの手に戻り、同じことが再起こらないよう各種セキュリティアップデートに取り組んでいます。」 ドメインがマルウェアと紐付くIPアドレスを指していたため、セキュリティ製品はそれをブラックリストに登録し、一部のDNSリゾルバはシンクホールしていた。レジストリ上の記録が正しくなった後も、ブロックリストやリゾルバのレピュテーションシステムで信頼を取り戻すには数週間を要した——この長い尾が、事件全体をおよそ2ヶ月の苦闘へと引き延ばした。

foyはその経緯をほぼ控えめに言い表した：「私たちは1週間、perl.comドメインの管理を失いました。」 実際の盗難期間は1週間。その前には数ヶ月の潜在的な侵害。そしてその後には数週間の後処理。

レジストラのアカウントセキュリティと長期保有ドメインへの教訓

perl.comの盗難がこれほど示唆に富むのは、まさに何も特殊なことが起きなかったからだ。本質を剥ぎ取ると、その教訓は不快なほど普遍的だ：

1. レジストラのアカウントこそが本当の「王冠の宝石」だ。 誰もがサーバーとDNSホストを堅牢化する。しかし、ドメインの所有権記録はレジストラに存在し、そのアカウントはしばしばパスワードと、変更を説得できるサポートチームによってしか守られていない。perl.comはエッジではなく、そこで盗まれた。

2. ソーシャルエンジニアリングは技術的な制御を上回る。 エクスプロイトもなく、被害者側のマルウェアもなく——ただ「偽造書類など」が実際の記録を動かすのに十分だっただけだ。自分のログインに二要素認証を設定していても、レジストラの人間がそれを上書きするよう説得されてしまえば意味がない。

3. 長期保有ドメインは格好の標的だ。 1990年代初頭に登録され、30年間自動更新で維持されてきたドメインは、連絡先情報が古くなり、人的単一障害点を持ち、所有者がWHOISレコードを毎日監視していない傾向がある。静かな安定性こそが、9月の侵害が1月まで気づかれない理由となった。

4. 移転ルールは両刃の剣だ。 所有者を保護するはずだった更新後60日間の移転ロックが、攻撃者の待合室となった。忍耐とレジストラ・国境をまたいだ「洗浄」が、迅速な解決を多者間・数週間にわたる奪還へと変えた。

5. 奪還は盗難より遅い。 名前を盗むのに必要だったのは偽造書類一枚。取り返すのに必要だったのは、レジストラ、レジストリ、正当な所有者の証拠、そしてブロックリストとリゾルバへの信頼回復の数週間だった。盗難は一つの取引だが、原状回復は多くの手続きを要する。

厳しい結論：perl.comのようなドメインにとって、パスワードの強度はレジストラが騙されるかどうかより重要ではない。

Namefiの視点

perl.comの盗難の各ステップは、ひとつの弱点に依存していた：所有権が他者のアカウント上の記録であり、適切なサポート担当者を説得できた人間が変更できるということ。攻撃者は所有者の鍵を必要としなかった。必要だったのはレジストラの信頼——そして偽造書類一枚で、30年の歴史を持つ資産を地球の反対側に移し、売りに出すのに十分だった。

Namefiは正反対の前提の下に構築されている：ドメインの所有権は暗号学的に検証可能であり、ひそかに書き換えることが困難であるべきだという考えだ。ドメインの管理をDNSとの互換性を保ちながらトークン化されたオンチェーン資産として表現することで、「この名前の所有者は誰か？」という権威ある問いの答えが、説得力のある電話一本で変更できるレジストラのデータベースの可変な一行ではなくなる。移転は署名された監査可能なイベントとなり、不正な「所有権変更」がこっそり通り抜けられる裏口がなくなる。

perl.comが一夜にして盗まれなくなるわけではない——レジストラとレジストリは依然としてチェーンの一部だ。しかし、この事件を定義した特定の障害モード——30年間名前のために料金を払い続けることとそれが自分のものであることを改ざん耐性をもって証明できることの間にある溝——を攻略し、盗まれたドメインが誰も異議を唱えられない前に洗浄される時間窓を縮小する。

perl.comは正面玄関を取り戻した。この事件が残す、より困難な問いは、なぜその錠が最初から、正しい書類を持った見知らぬ人が開けられるようなものだったのか、という点だ。

出典と参考資料

• The Perl NOC — perl.com hijacked
• perl.com (brian d foy) — The Hijacking of Perl.com
• BleepingComputer — Perl.com domain stolen, now using IP address tied to malware
• The Register — Perl.com theft blamed on social engineering attack
• SecurityWeek — Hackers Controlled Perl.com Domain Months Before Hijack
• Security Affairs — Attackers took over the Perl.com domain in September 2020
• The Daily Swig (PortSwigger) — Domain for popular programming website Perl.com stolen in 'hack'
• Slashdot — Perl.com Domain Stolen, Now Using IP Address of Past Malware Campaigns
• INCIBE-CERT — The perl.com domain has been hijacked
• GIGAZINE — Perl.com editors tell the truth about the Perl.com domain hijacking case