簡潔な回答
レジストラアカウントを乗っ取りから守るには?
他では使わない長いランダムなパスワード、二要素認証、できるだけ少ないユーザー数、サポートへの電話で回避できない復旧手段で、レジストラアカウントを守ります。Wardmint は、表の中に、弱点が DNS レコードではなくレジストラやプラットフォームのログインまたはサポートの流れだったインシデントが2件(2024年7月と2026年2月)あると数えました。
アカウントの対策と、それぞれが対処するインシデント
| 対策 | 防げるもの | 対処する公開事例 |
|---|---|---|
| 移行されたすべてのドメインのアカウントを自分で確保する | 攻撃者が先にアカウントを作成すること | Squarespace の移行、2024年7月9日〜12日(OAuth の弱点) |
| サポートへの電話のルール:音声での依頼では変更しない | サポート担当者へのソーシャルエンジニアリング | Avantis、2026年2月(サポートへの電話後にアカウントが乗っ取られた) |
| アカウントの二要素認証 | 盗まれたパスワードでのログイン | 2026年10月30日〜31日のリダイレクト後の Name.com の助言 |
| 保管庫内の固有で長いパスワード | 認証情報の使い回しと推測 | 一般的な慣行 |
| 名前のある少数のユーザー、退任時に削除 | 内部者と元メンバーのアクセス | DAO と貢献者の入れ替わり |
| ブックマークしたログインアドレス | レジストラログインへのフィッシング | 一般的な慣行 |
なぜレジストラアカウントが標的になるのですか?
ネームサーバー、DS レコード、所有者を変更でき、チェーン上のどんなコードもそれを元に戻せないからです。 あなたとしてサインインしたハイジャッカーは、ドメインを好きな場所に向け、新しい宛先の証明書を要求できます。
公開記録がそのパターンを示しています。Krebs on Security は2024年7月、Google Domains から Squarespace に移行されたドメインが、所有者より先にドメインに紐づくメールでアカウントを作成した攻撃者に対して無防備だったと報じ、Squarespace はこれを OAuth ログインに関連する弱点によるものとしました。Blockaid は2026年2月、Avantis が、サポートへの電話で請求情報が引き出された後に乗っ取られた Squarespace アカウントを通じて侵害されたと書きました。2026年10月30日と31日には、あるレジストラに登録された十数件の DeFi サイトのドメインがリダイレクトされ、レジストラは復旧し、DNS の確認と二要素認証を促しました。
2026年11月12日 の Wardmint の集計によると、表にある7件のインシデントのうち2件(2024年7月の一連の被害と2026年2月の Avantis の事例)は、レジストラまたはプラットフォームでのログインやサポートの流れが要でした。全体はDNS ハイジャックでユーザーを失った暗号資産プロジェクトにあります。
どのようなパスワードとログインの設定を使うべきですか?
パスワードマネージャーで生成して保管する20文字以上のランダムなパスワードを使い、決して使い回さないでください。 チャットで共有したメッセージやスプレッドシートは保管庫ではありません。複数の人がアクセスする場合は、監査証跡のあるチームの保管庫を使い、誰がその秘密情報を見たかを記録してください。
アカウントに二要素認証をオンにしてください。ハードウェアセキュリティキーは、フィッシングページにコードを渡さないため、一般的な第二要素で最も強力です。次は認証アプリで、テキストメッセージで送られるコードは最も弱いものです。復旧コードはオフラインで2か所に保管し、誰がそれにアクセスできるかを書き留めてください。
Wardmint では、アカウント番号とパスワードでサインインし、クライアントエリアで二要素認証をオンにできます。メールでの返信は12時間以内、年中無休。DNSSEC、CAA レコード、不正利用報告のサポートも含みます。登録自体に必要なのはドメインごとの確認済みメール1つだけなので、アカウントのメールは自分で管理するメールボックスにし、そのメールボックスをアカウントと同じ厳しさで保護してください。
誰にアクセスを許可し、サポートへの電話にはどう対処すべきですか?
所有者1人と予備1人を決めて両方を文書化し、電話だけを根拠に変更を行わないというルールを書いてください。 Avantis の事例がその理由を示しています。電話での会話の後にサポートがアカウントを変更できるなら、パスワードの強さはもはや意味を持ちません。
DAO や財団では、誰が認証情報を保有し、トレジャリーがどのように残高をチャージし、貢献者が去るときにアクセスがどう変わるかを事前に決めてください。共同管理の慣行はDAO はドメインをどのように保有し、支払うべきかにあります。チームを離れた人のアクセスは同じ日に削除し、そのとき共有パスワードも変更してください。
最も重要なドメインには、ドメインごとに年 +$29 のドメイン保護を検討してください。ドメインは DomaineGoat LLC の名義で登録され、あなたは受益者のままで、いつでも無料で自分の名義に戻せ、移管ロックがオンで、措置の前にすべての苦情を担当者が読みます。このオプションはドメイン保護とはで説明しています。アカウントが保持するものを減らしますが、強力なログインの代わりにはなりません。
レジストラアカウントを守る7つのステップ
すべてのアカウントとドメインを棚卸しする
各レジストラアカウント、その中のドメイン、サインインできる人を一覧にします。移行で引き継いだアカウントも含めてください。
移行されたアカウントを確保する
レジストラが以前のレジストラを吸収した場合は、サインインして、各ドメインのアカウントを他人ではなくあなたが保有していることを確認します。
パスワードを変更する
保管庫で20文字以上のランダムなパスワードを生成し、このアカウントだけに使います。
二要素認証をオンにする
ハードウェアキーを優先し、次に認証アプリを使います。復旧コードはオフラインで2か所に保管します。
アクセスを絞り、記録する
所有者1人と予備1人を決め、それ以外の全員を削除し、各変更の日付と理由を記録します。
サポートへの電話のルールを書く
電話やチャットだけを根拠に、DNS、所有者、連絡先を誰も変更しないことで合意し、チームに伝えます。
ログインをブックマークし、フィッシングに注意する
レジストラはブックマークからのみ開きます。レジストラへのログインを求めるメールは、フィッシングの可能性があるものとして扱ってください。
レジストラをコピーしたフィッシングページはどう見分けますか?
何かを入力する前にアドレスを確認し、メールのログインリンクは決して辿らないでください。 レジストラのフィッシングは緊急性に頼ります。ドメインがもうすぐ期限切れになる、苦情が来ている、といったメッセージです。ブックマークからレジストラを開き、アカウント内に同じ通知があるか確認してください。
保存された正確なアドレスでのみ認証情報を入力するパスワードマネージャーを使えば、類似のログインページには何も入力されません。ハードウェアキーは、第二要素に同じ保護を加えます。疑わしいページにパスワードを入力してしまった場合は、すぐに変更し、すべてのセッションを終了し、DNS レコードと連絡先メールを確認してください。
もう1つの層は有効期限です。失効したドメインは誰でも取得でき、更新の責任はドメインの失効を防ぐ方法で扱っています。より広い強化計画はDNS ハイジャックからドメインを守る方法にあります。
レジストラアカウントのセキュリティに関する質問
二要素認証だけで十分ですか?
必要ですが、それだけでは足りません。Avantis の事例はサポートへの電話を経由しました。電話での変更を認めないルールと、少数のユーザーを加えてください。
移管ロックはアカウントを守りますか?
いいえ。別のレジストラへの移管を防ぐだけです。ログイン情報を持つ人がネームサーバーやレコードを変更することは防ぎません。
アカウントにチーム共有のメールを使うべきですか?
メンバー1人の個人アドレスではなく、チームが管理し、二要素認証で保護したメールボックスを使ってください。各ドメインにも登録用に確認済みメールが1つ必要です。
アクセス権を持つ貢献者が去ったらどうしますか?
同じ日のうちに、パスワードを変更し、その人のアクセスを削除し、復旧コードをローテーションし、DNS レコードを確認してください。
ドメイン保護は強力なログインの代わりになりますか?
いいえ。ドメインを会社の名義にし、苦情の担当者による確認を加えますが、アカウントには依然として強力なログインが必要です。
まとめ
- レジストラアカウントは、ネームサーバー、DS レコード、所有者を変更できます。
- 2024年と2026年の公になったハイジャックは、ログインの弱点かサポートへの電話を経由しました。
- ランダムな20文字以上のパスワードを保管庫に入れ、他では使わないでください。
- 二要素認証をオンにしてください。できればハードウェアキーで。
- 所有者1人と予備1人を決め、退任者は同じ日に削除してください。
- 電話だけでは変更を行わないというルールを書いてください。
- ドメイン保護は年 +$29 で、強力なログインの代わりにはなりません。
出典 (3)
- 研究者:弱いセキュリティ初期設定が Squarespace ドメインのハイジャックを可能にした — Krebs on Security (確認日 2026-11-12)
- Web3 プロトコルを脅かすフロントエンドのハイジャックと Web2 の攻撃対象領域 — Blockaid (確認日 2026-11-12)
- ハッカーが Name.com に登録された十数件の DeFi ウェブサイトをハイジャック — The Block (確認日 2026-11-12)