インシデントのあらましを簡単に説明しよう。これは、コインチェックが利用する外部のドメイン登録サービスにおいて、コインチェックのネームサーバ（DNS）情報が、何者かに書き換えられたものだ。これにより、同社のドメインのレコードが偽のDNSに登録され、同社にメールで問い合わせた顧客のメールアドレスと本文が第三者に流出する可能性があった。コインチェックはインシデント発生後、対応についてのレポートを公開するとともに、利用するドメイン登録サービスを変更したと発表した。
このインシデントは、一般に「不正アクセス」という言葉から連想する事件とは異なり、一見地味な印象を受けてもおかしくないものだ。しかし、報告書には、セキュリティ担当者ならば誰でも青ざめるような展開が赤裸々につづられていた。
ITmedia エンタープライズ編集部は、実際に同社でインシデント対応に当たった喜屋武 慶大氏（サイバーセキュリティ推進部長）に講演を依頼。2020年9月に開催したオンラインイベント「ITmedia Security Week 秋 - ITmedia エンタープライズ」の特別講演として、当時の様子を当事者の目線で振りかえってもらった。その内容は、セキュリティ担当者だけでなく組織でITに関わる人ならば誰もが非常に参考になるものだった。本稿は喜屋武氏の講演の内容をレポートする（注）。
注：本稿はITmedia エンタープライズ主催「ITmedia Security Week 秋」の講演「ドメインが乗っ取られた！！そのとき我々はどう対応したか」を基に再構成した。
読者の皆さんには「自分がもしもセキュリティ担当者なら、気付くことができただろうか」と問いかけながら、目を通していただきたい。
2020年6月1日正午ごろ：「何かがおかしい」という報告から全てが始まった
その日（インシデント発生当日）、最初に違和感に気付いたのは、社内のSRE（Site Reliability Engineering：サイト信頼性エンジニアリング）チームだった。
「ITmedia Security Week 秋 - ITmedia エンタープライズ」に登壇し、インシデント対応の様子を語ったコインチェックの喜屋武 慶大氏（サイバーセキュリティ推進部長）2020年6月1日正午ごろ、コインチェックで通常の監視業務に当たっていたSREチームは、普段と異なる状況を察知した。前日に比べて自社サービスに対するリクエスト数が異常に少なかったのだ。
「『何かがおかしい。怖い』という報告が、SREチームから社内で使う『Slack』のワークスペースに上がってきた。それが発端だった」（喜屋武氏）
SREチームはまず、リクエスト数の激減以外にも何か異常がないかどうかをチェックした。すると、前日の5月31日を境にサービスのレスポンスタイムが遅延していることが分かった。「この時点では誰もDNSの書き換えという結論は想像していなかった」と喜屋武氏は振り返る。
この違和感をきっかけに、SREチームは本格的な調査に乗り出した。しかし原因はなかなか見つからない。アプリケーションには異常がなく、サーバもロードバランサーも問題がないように見える。ただし、喜屋武氏によれば、ユーザーの感覚としては普段と変わらないように見えても、モニタリングダッシュボードに示されるレスポンスタイムはどんどん遅延していったという。リクエスト数は減っているにもかかわらずだ。
6月1日午後：レスポンス遅延が悪化 「障害ではなく、攻撃だ」と気付いたきっかけ
6月1日の午後になると、レスポンス遅延はさらに進み、体感で分かるレベルになってしまった。また、全ての社員ではなく、特定のメンバーに限ってレスポンス遅延が発生していることも分かってきたという。
原因を突き止めようと、SREチームは、遅延が確認できた環境から経路を確認するtracerouteコマンドを実行した。すると、通常ならば数ホップで同社が利用する国内のAmazon Web Services（AWS）まで到達するはずのリクエストが、なぜかアムステルダム（オランダ）のリージョンにあるAWSのCDN（Content Delivery Network）サービス「Amazon CloudFront」を経由していた。
これこそがレスポンスの遅延の原因と思われたが、そもそもなぜリクエストがオランダを経由するのかが分からない――。不審に思った喜屋武氏は、AWSのサポートに連絡を取った。コインチェックがインシデント対応に奔走する“長い夜”は、この時点で既に始まっていた。
喜屋武氏が「権威DNSに何か問題があるのでは」とAWSのサポートに確認したところ、返ってきた答えは「これはAWSのDNSではない」だった。同氏はその際の反応について「『えっ！』と驚くしかなかった」と話す。このやりとりをきっかけに、AWSのCDN（Content Delivery Network）サービス「ns-1515.awsdns-61.org」に0を足して「ns-1515.awsdns-061.org」にすり替える、一見しただけでは気付かないような手口だった。
この時点からインシデントが一段落するまで、SREチームはAWSのサポートとのやりとりを重ねることになった。
「（違和感に気付いた当初は）ひょっとしたらAWSの障害が原因ではないかと思って問い合わせたことをきっかけに、結果として別の原因が判明した。しかし、その後もAWSのサポートは（インシデント対応に）付き合ってくれた。こういうときに素早く反応してもらえたので、サポート契約していて良かったと感じている」（喜屋武氏）
2020年6月1日夕方：レジストラが乗っ取られていたことが判明
6月1日夕方ごろ、本格的なインシデント対応が始まった。まずは、システム担当の執行役員に対して、これまでのいきさつを報告した。また、状況報告に使うコミュニケーションツールをSlackからWeb会議サービス「Zoom」に切り替えた。「Zoomが詰め所のような形になり、そこに参加する形で執行役員に指揮を執ってもらった」と、喜屋武氏は語る。
状況を報告されたシステム担当の執行役員は、想定しない報告に当初「えっ！」と驚くのみだった。後日、役員は喜屋武氏に「重めのシステム障害を想定していたため（サイバー攻撃を受けたと報告が来た際は）何を言われているのかさっぱり分からなかった」と明かした。
DNSが改ざんされたと分かった以上、初動対応として、コインチェック側はレジストラにログインし、DNSを元に戻そうとした。しかし、IDとパスワードを使ってもログインできない。パスワードをリセットしようとすると、今度はリセットのためのメールがコインチェックに届かない――。つまり、この時点で、レジストラのIDは完全に乗っ取られてしまっていた。
喜屋武氏がドメイン名を検索して状況を確認すると、日本時間で5月31日の深夜にDNSレコードがアップデートされていた。もちろん、コインチェック社内でその時間に当該の操作をした者はいなかった。5月31日深夜を境にレジストラの登録情報が乗っ取られ「coincheck.com」が奪われてしまった。コインチェックがこの事実を把握したのは、6月1日の19時過ぎだった。
タイミングの悪いことに、新型コロナウイルス感染症（COVID-19）の影響でレジストラの電話サポートなどが縮小されていた。コインチェックはレジストラにメールで対応を依頼したが、その時点でレジストラの営業時間外だったため、最悪対応が翌日になってしまうことも考えられた。このタイミングで、コインチェックは社外のセキュリティアドバイザー2人にも状況を報告し、インシデント対応に参加してもらうことになった。
2020年6月1日夜：なぜ、どうやって攻撃された？ 長い捜索が始まる
DNSが不正に書き換えられてしまった場合、それを元に戻せるのはレジストラだけだ。レジストラの対応を待つ間、コインチェックは、今回のインシデントの根本原因を探る調査を開始した。
この時、真っ先に疑われたのはマルウェア感染による不正アクセスだった。しかし、喜屋武氏がログを確認したところ、社内の端末にマルウェア感染は確認できなかった。不審なアクティビティーがないかどうか、未知のマルウェア攻撃がある前提で調査を継続したが、エンドポイントからのアラートも上がっていない。操作ログや通信ログ、プロセスログにも、それらしい痕跡はなかった。喜屋武氏は「マルウェア攻撃が原因である可能性は低い」と判断し、次の調査に移ることにした。
マルウェア以外に、アカウント乗っ取りやパスワードクラック、セッションハイジャックなどが原因になっている可能性もあった。このうち、アカウント乗っ取りが発生していれば、他のサービスを攻撃されている可能性も高い。しかし、シングルサインオン（SSO）ログやSaaSのログイン履歴に不審な点はなかった。セッションハイジャックの可能性も低かった。レジストラに最後にログインした日時がかなり前であり、5月31日時点では有効ではないことが確認できたためだ。
「パスワードに関しては、サービスで設定できる最長の文字数を、パスワードジェネレーターで生成している。それなりの強さであり、総当たりでパスワードクラックを行うことは不可能。使い回しもしていない」（喜屋武氏）
残された可能性は、レジストラの脆弱（ぜいじゃく）性だった。調査に参加したセキュリティアドバイザーからは「海外でもレジストラの脆弱性をきっかけとした攻撃が発生している」というコメントを得ていた。この時点では可能性の一つでしかなかったが「結果的には、レジストラの脆弱性が原因だった」と、喜屋武氏は話す。
「もしレジストラの脆弱性が原因だったなら、（他の事業者も対象にした）攻撃キャンペーンがあるはずだと考えたが、当社以外に攻撃されているという情報がなかった。念のためレジストラにログインした端末は隔離し、他のサービスにもサインオンできないようにした」（喜屋武氏）
調査が進む中、2020年6月1日20時52分ごろ、レジストラから「DNSの情報を元に戻した」という連絡が来た。この時点で、コインチェックではシステム担当執行役員から社長にインシデント発生の報告を上げていた。同社は社内で制定済みの対応フローに従い、緊急事態対策本部を設置した。
2020年6月1日深夜：ドメインがついに回復 判明した衝撃の手口とは
DNSは元に戻ったものの、この時点では、インシデントが社内やユーザーを含めてどの程度の範囲に影響を与えたのか、明確に見えていなかった。影響範囲の確認を兼ねて調査を続けていると、DNSに不審なMXレコードが設定されていることが判明した。攻撃者は、コインチェックのメール情報を盗もうとしていたのだ。
「不正に設定されたIPアドレスを確認すると、coincheck.comを返すメールサーバが動いていた。しかし、SPFレコードの設定が書き換えられていなかったため、coincheck.comを送信元とするメールを送信することが狙いではなさそうだった」（喜屋武氏）
この動きを確認した時点で、時刻は6月2日の深夜1時を過ぎようとしていた。DNSは無事に取り戻せたが、インシデントを引き起こした攻撃の詳細や原因はまだ分かっていなかった。この状況では、攻撃者が再びDNSを改ざんできてしまう可能性もある。喜屋武氏は自分とSREチームの1人を残して他のメンバーを解散させ、2人体制の監視に入った。そして、全社員のメールボックスをくまなくチェックし始めた。
すると、重大な事実が見えてきた。複数の社員のメールボックスの中に「GitHub」をはじめとする複数のサービスからパスワードリセットのメールが大量に届いていたのだ。該当の社員にヒアリングしたところ、彼らは一様に「パスワードをリセットするような操作はしていない」と答えた。実際に、喜屋武氏は社員の操作履歴を精査し、成功したパスワードリセットのリクエストがなかったことを確認した。
ここまでの状況から、初めて攻撃の全体像が見えてくる。
「レジストラの情報を書き換えることで、攻撃者が用意したサーバに問い合わせさせ、偽のレコードを引いてくる。これにより、攻撃者がcoincheck.comに届くメールを不正に取得した」（喜屋武氏）
攻撃者はDNSを直接攻撃せずに、レジストラを攻撃することでDNSを乗っ取ったのだ。
2020年6月2日：プレスリリース第一報を公開、そして……
翌日の6月2日、コインチェックは、朝、昼、夕方の定期Webミーティングを設定した。Web会議には指揮官であるシステム担当の執行役員に常にオンライン状態でいてもらい、進捗（しんちょく）を報告した。Web会議を対策本部にするスタイルはあくまでもCOVID-19対策だったが、これが意外な効果を生んだ。
「リアルな会議室でホワイトボードを前にするようなこれまでの会議スタイルとは異なり、Web会議なら作業をしながらでも報告ができる。そこに入れば誰かがいて、助言をもらえる。振りかえると、この体制はとてもやりやすく、メンバーのから評判も良かった」（喜屋武氏）
ユーザーのサポート窓口となるメールアドレスで利用しているドメインは、すでに攻撃の対象となっていた。ユーザーへの悪影響を防ぐため、コインチェックは新たに「coincheck.jp」のメールアドレスを設定し、動作を確認した上で、インシデントについて記したプレスリリースを公開した。その後の展開は、ITmedia エンタープライズやその他の報道で皆さんもご存じのことだろう。
被害を増やさないために――担当者が語る予防策
喜屋武氏は今回のインシデントを振り返り「本物に酷似したドメイン名をDNSに設定されてしまう攻撃例は、知る限り世界初ではないか」と話す。この攻撃の恐ろしい点は、いったんドメインを乗っ取られ、MXレコードを書き換えられてしまうと、自分が正規のユーザーであることを証明する手段がほとんどなくなってしまうところだ。このような手口は、社内で使うサービスのパスワードがメールを使ってリセットされる設計の弱みを突いたようにも見える。
視聴者に向けたメッセージとして、喜屋武氏は「（今回のインシデントからは）ドメイン乗っ取りの被害が甚大であることを確認できた。DNSはとても大事なサービスだ。このインシデントを参考にし、レジストラに登録したDNSの設定はしっかり監視してほしい。また、権威DNSに使っている関連サービスのアカウント管理情報やレコードは定期的にチェックしてほしい」と話し、講演を締めくくった。