2FA が自分を締め出す鍵に変わった日 – X アカウント乗っ取りからの復旧記録

こんにちは、やまぱん!です。

2026 年 8 月、筆者の仕事用 X アカウントが乗っ取られました。ここで言う「乗っ取り」は、パスワードを忘れて入れなくなった話ではありません。ID とパスワードは合っているのに、身に覚えのない認証アプリの 6 桁コードを要求されて、自分のアカウントに入れなくなったという状態です。

2 要素認証(Two-Factor Authentication、以下 2FA)は本来、パスワードが漏れても攻撃者を止めるための仕組みです。ところが今回は、その 2FA が正規ユーザーである自分だけを締め出す鍵として機能しました。

復旧まで 19 日かかりました。同じ状況に陥る人は多くないと思いますが、陥ったときに参照できる日本語の一次資料が見当たらなかったので、時系列の記録として残しておきます。

2FA が自分を締め出す鍵に変わった日。ID とパスワードは合っているのに、身に覚えのない認証アプリの 6 桁が突破できない状態を表したタイトル画像

スクリーンショットについて: 掲載画像はアカウント名、アイコン、表示名、連絡先メールアドレス、サポートケース番号、パスワード入力欄をマスクしています。赤枠で囲った部分がマスク箇所です。攻撃者側のメールアドレスだけは、パターンを示すために一部を残しています。

TL;DR

  • 身に覚えのない認証アプリによる 2FA を追加され、ID とパスワードが正しくてもログインできなくなった。
  • 同時期に、身に覚えのないメールアドレス変更も発生していた。
  • X Support は本人確認として「一度ログインを試してから、このメールに返信してください」という手順を求めてきた(本文のスクショ参照)。ログイン試行の記録をサポート側でも受け取る仕組みらしい。
  • メールアドレスが最近変更されていたことを理由に、「変更から 7 日以上待ってから再申請してください」と 8/8 に案内され、その間は手詰まりになった。
  • 最終的に X 側で 2FA が強制解除され、通知メールを受け取った直後にログインできた。異常検知から復旧まで 19 日。
  • 教訓は 3 つ。バックアップコードを手元に持つ登録メールアドレス自体を強く守るメール変更通知の「元に戻す」リンクをその場で押す

何が起きたか

症状 1: 身に覚えのないメールアドレス変更

最初に届いたのは、アカウントのメールアドレスが変更されたという通知でした。変更先として表示されていたのは、まったく見覚えのないアドレスです。

MaggieB***@outlook.com

英語圏の人名らしき文字列 + 数字 6 桁 + outlook.com という組み合わせで、心当たりはまったくありません。使い捨てで量産されたアドレスに見えます(伏せ字は筆者によるもの)。

X から届いたメールアドレス変更通知。アカウントに紐づくメールアドレスが見知らぬアドレスへ変更されたことが書かれている
登録メールアドレスが第三者のアドレスへ変更された通知。変更先アドレスは本文と揃えて中間部だけを伏せ字にしている

この時点で「アカウントに誰かが入っている」ことは確定でした。ただ、この通知メール自体は変更前のアドレスに届いています。ここが後で効いてきます(後述)。

症状 2: 設定した覚えのない 2FA

ログインしようとすると、ユーザー名とパスワードの認証までは通ります。その後に出てくるのが、認証コードの入力画面です。

X のログイン画面。パスワード認証の後に verification code の入力を求められている
アイコンと表示名は自分のアカウントのもの。ここまでは正常に進む

そして次の画面で、認証アプリ(Authentication app)の 6 桁コードを要求されました。

認証アプリのコードを入力するよう求める X の画面。Enter your authentication app code と表示されている
「認証アプリで生成されたコードを入力してください」の画面。この認証アプリは自分で設定していない

筆者はこのアカウントで認証アプリによる 2FA を設定していません。つまり、この 6 桁を生成できるのは自分ではない誰かです。

「別の認証方法を選ぶ」に進んでも、選択肢は認証アプリバックアップコードの 2 つだけでした。

別の認証方法を選ぶ画面。Authentication app と Backup code の 2 つしか選択肢がない
本人の手元で使える方法がなく、ここで手詰まりになる

バックアップコードも、自分が生成したものではないので持っていません。SMS もメールも選べない。正しい ID とパスワードを持っている本人だけが、確実に入れない状態が完成しました。

2FA は「誰が 2 段目の鍵を握っているか」で意味が反転する

今回の構図を整理すると、次のようになります。

本来の 2FA と、先に 2FA を奪われた場合の比較図。同じ仕組みが攻撃者を止めるか本人を止めるかが反転することを示している

通常、2FA は「パスワードを知っているだけでは入れない」という壁です。攻撃者がパスワードを入手しても、認証アプリは本人の手元にあるので止まります。

一方、先にアカウントへ侵入されて 2FA を設定されてしまうと、同じ壁が向きを変えます。攻撃者は自分の認証アプリを second factor として登録済みなので通れる。本人は second factor を持っていないので通れない。

さらに登録メールアドレスまで変更されていると、「パスワードを忘れた」の再設定リンクも攻撃者側に飛びます。復旧の争点は「パスワードを思い出せるか」ではなく、プラットフォーム側に 2FA を強制解除してもらえるかに移ります。

なお、どういう経路で最初の侵入が起きたのかは特定できていません。X からもその点についての説明はありませんでした。以下は「本人が設定していない 2FA が有効になっていた」「本人が実行していないメール変更が発生していた」という観測できた事実と、そこからの筆者の解釈を分けて書いています。

X Support とのやり取り

ステップ 1: Help Center のフォームから申請する

ログインできない状態なので、通常の設定画面からは何もできません。X の Help Center にあるフォームから申請します。

X Help Center の申請フォーム。アカウントが乗っ取られた際の状況を選ぶ画面
状況に応じた選択肢を選んで送信する。今回は「2FA が不正に設定された」という趣旨で申請した

伝えたのは次の内容です。

  • ユーザー名とパスワードでログイン処理は進められる
  • その後に認証アプリの 6 桁コードを要求される
  • この認証アプリは自分が設定したものではない
  • したがってコードを生成できない
  • 不正に追加された 2FA を削除またはリセットしてほしい

実際に 6 桁コードを要求されている画面のスクリーンショットも添付しました。送信すると受付完了の表示が出ます。

申請の受付完了画面。Thank you! と表示され、リクエストを受け取ったことが示されている
受付完了の表示。ここからはメールでのやり取りになる

ステップ 2: 「一度ログインを試してから返信して」

ここが今回いちばん興味深かったところです。X Support から返ってきた指示は、PC かスマートフォンの Web ブラウザから x.com にログインを試して、その後にこのメールへ返信してほしいというものでした。

X Access Support からのメール。x.com にユーザー名とパスワードでログインを試し、その後このメールに返信するよう求めている
ケース番号と宛先はマスクしている。返信先は access-support@x.com

メール本文にはこう書かれていました。

Please log in on https://x.com (from a desktop computer or a mobile web browser) with your username and password.
We should receive a notification on our end, which will help us confirm that you're the account owner.
Please reply to this email once you've attempted to log in, and we'll continue to help.

要するに、利用者が実際にログイン操作をすると X 側にもその試行の記録が届き、それをアカウント所有者確認の材料に使うという手順です。「パスワードを知っている人物が、いま、このメールアドレスから返信してきた」という 2 つの事実を突き合わせているのだと思います。

パスワードそのものをメールで送らせずに所有者確認をする方法としては合理的ですが、初見だと「ログインできないと言っているのにログインしろとは」と面食らいました。

ステップ 3: Too many attempts で止まる

指示どおりログインを試したところ、今度はレート制限に引っかかりました。

X のログイン画面に Too many attempts. Try again in a few minutes. と表示されている
パスワード入力欄とアカウント名はマスクしている。短時間に試行を繰り返すとこの状態になる

サポートの指示に従って何度かログインを試すと、この画面に当たります。X のヘルプによると、このロックは約 1 時間で自然に解除されるとのことなので、慌てて試行を重ねるより待つのが正解でした。

After a limited number of failed attempts to sign in to X, you will be temporarily locked out from trying to sign in. When your account is locked, you will not be able to sign in - even with the correct password.
This lock lasts about an hour and will then clear on its own.

出典: Help with temporary account lock out

指示どおり試したこと、そのうえでエラーになったこと、依然としてアカウントへアクセスできないことを返信しました。

ステップ 4: 「メール変更から 7 日以上待ってから再申請して」

8 月 8 日の未明、X Support から追加の回答が届きました。争点になったのは、アカウントのメールアドレスが最近変更されているという事実です。

メールアドレス変更の直後は当該の復旧処理を進められないため、7 日以上待ってから再度申請してほしいという案内でした。

つまり、

  1. 攻撃者がメールアドレスを変更する
  2. その変更によって保護期間のような待機が発生する
  3. 正規ユーザー自身の復旧申請も、その待機に引っかかる

という順序になります。X 側が「これは保護期間である」と明示したわけではないので目的は推測です。ただ少なくとも今回のケースでは、メール変更直後だったことが復旧までの時間を延ばしたように見えました

この時点で打つ手はなくなり、7 日間待つことになりました。

ステップ 5: 7 日経過後に再申請

8 月 15 日、指示どおり再度申請しました。新しいケース番号が発行され、届いたメールの指示は前回と同じ「x.com にログインを試してから返信してください」でした。

2 通目の X Access Support からのメール。1 通目と同じくログインを試してから返信するよう求めている
ケース番号と宛先はマスクしている。手順は 1 通目とまったく同じ

指示どおりログインを試しましたが、状況は変わっていません。相変わらず、自分が設定していない認証アプリの 6 桁コードを要求されます。その画面のスクリーンショットを添えて、英文で以下の趣旨を返信しました。

  • 指示どおりログインを試した
  • ユーザー名とパスワードではログイン処理を進められた
  • しかし認証アプリの 6 桁コードを要求される
  • この認証アプリは自分が設定したものではない
  • したがってコードを取得できない
  • 不正に追加された 2FA を削除またはリセットしてほしい

ステップ 6: 追加のフォームは Duplicate Case で弾かれる

待っている間、別のフォームからも申請しようとしましたが、**Duplicate Case(重複ケース)**として警告が出ました。

申請フォームに Duplicate Case の警告が表示されている画面
連絡先メールアドレスはマスクしている。同じ内容で重ねて申請しても処理は早くならない

同じ内容を何度も投げても順番が繰り上がるわけではありません。むしろケースが分散すると追いにくくなるので、1 本のケースに絞ってやり取りするのが正解です。ここは待つしかありませんでした。

8 月 19 日時点でも、8 月 23 日時点でも、まだ解除されていません。

ステップ 7: 解除、そして復旧

8 月 25 日の未明、件名「X two-factor authentication is now off」のメールが届きました。

X から届いた 2FA 無効化の通知メール。two-factor authentication をオフにしたことが書かれている
アカウント名と宛先はマスクしている。この通知が復旧のシグナルだった

本文には「You've turned off two-factor authentication for(アカウント名)」とあり、続けて「This means you'll no longer have this added protection when you log in to X.」と書かれていました。文面としては「あなたが自分でオフにしました」という通常の通知と同じ形式ですが、実際には X 側で強制解除された結果です。

このメールを見てからログインし直したところ、6 桁コードの要求は消えていて、そのままアカウントに入れました

19 日間のタイムライン

ここまでの流れをまとめると、こうなります。

異常検知から復旧までのタイムライン。8/6 前後の異常検知から 8/25 の復旧までを 7 段階で示している

「フォームを 1 回出したら解除された」ではなく、申請 → 指示 → ログイン試行 → 返信 → 7 日待機 → 再申請 → 再度ログイン試行 → 返信 → 待機という多段のやり取りになりました。

そして重要なのは、この間自力でできることが一つもなかったことです。パスワードは分かっている。アカウントの持ち主であることも証明できる。それでも、2FA の解除権限を持っているのはプラットフォーム側だけでした。

これをやっておけば違った、と思うこと

事後に X のヘルプを読み直して、いくつか「知っていれば違った」ポイントが見つかりました。

1. メール変更通知の「元に戻す」リンクをその場で押す

X の乗っ取られたアカウントに関するヘルプには、次の記載があります。

If you receive an email from verify@x.com regarding an email address change for your X account, you can reverse this action by clicking on the provided link in the email.

つまり、メールアドレス変更の通知メールには「この変更を取り消す」リンクが含まれているということです。通知は変更前のアドレス、すなわち本人が受け取れるアドレスに届きます。

今回、筆者はこの通知を「異常の証拠」としては認識しましたが、その場でリンクを押して巻き戻すことはしていません。もし押していれば、メールアドレスは自分の管理下に戻り、後の「7 日待機」も発生しなかった可能性があります。

この手のセキュリティ通知メールはフィッシングとの区別が難しく、リンクを踏むのを躊躇しがちです。ただ、送信元と本文を確認したうえで自分から能動的に巻き戻す選択肢があることは知っておいて損はありません。

2. バックアップコードを事前に手元に持っておく

X のヘルプでは、2FA を有効にした時点でバックアップコードが生成されると説明されています。

A backup code is automatically generated for you when you turn on two-factor authentication through your iOS or Android X app. You can also generate a backup code on x.com.

このコードがあれば、認証アプリを失っても自力でログインできます。ただし注意点があります。

  • 同時に有効なバックアップコードは 最大 5 個
  • 生成した順に使う必要がある。順番を飛ばして使うと、それ以前に生成したコードがすべて無効になる
  • コードは x.com、mobile.x.com、公式アプリでのみ有効。サードパーティアプリには temporary password が別途必要

もっとも、今回のケースでは事前にバックアップコードを持っていても救われなかった可能性があります。攻撃者が 2FA を設定し直した時点で、既存のコードは無効化されるはずだからです。バックアップコードは「認証アプリを失くした自分」を救う仕組みであって、「乗っ取られた自分」を救う仕組みではないという理解が正しそうです。

3. 登録メールアドレスそのものを強く守る

今回いちばん効いたのはこれだと思っています。X アカウントの復旧導線はすべて登録メールアドレスに依存します。そこを取られると、

  • パスワードリセットのリンクが攻撃者に飛ぶ
  • サポートとのやり取りに使えるアドレスが変わる
  • 変更後の待機期間に引っかかる

という三重苦になります。SNS アカウント側の 2FA を固める前に、紐づくメールアカウント側の 2FA とリカバリ設定を先に固めるのが順序として正しいです。

4. セキュリティキー / パスキーを検討する

X は 2FA の方式として、SMS、認証アプリ、セキュリティキーの 3 つをサポートしています。ヘルプによると、セキュリティキーを登録した場合は他のバックアップ方式を併用しなくてもよい、という扱いになっています。

If you add a security key for additional two-factor authentication protection, we no longer require using another backup method for more protection.

物理キーやパスキーは、フィッシングによる認証情報の窃取に強い方式です。「認証アプリを設定していれば安全」ではなく、そもそも認証情報を渡してしまう経路を減らすという観点では検討する価値があります。

同じ状況になった人向けの実務メモ

上の考察を手順だけに圧縮すると、こうなります。

  1. 初動: まだログインできるならパスワードを変更し、メール変更通知が届いていたらリンクから取り消す。連携しているサードパーティアプリのアクセスも取り消す。
  2. 申請: ログインできないなら Problems with account access から申請する。ユーザー名最後にアクセスできた日付を必ず含める。
  3. 一本化: 申請は 1 ケースに絞る。重ねて出しても Duplicate Case になるだけで、順番は繰り上がらない。
  4. 返信: サポートの指示に忠実に従い、実施した内容とスクリーンショットを添えて返す。「ログインを試してから返信して」は本人確認の一部なので省略しない。
  5. 待機と復旧後: メール変更が絡むと待機期間が発生する。復旧できたらパスワード再設定、2FA 再設定、バックアップコードの保管、連携アプリの棚卸しを一気にやる。

まとめ

今回の件で自分の認識が変わったのは、次の 1 点です。

2FA は「本人だけが通れる仕組み」ではなく、「second factor を握っている側だけが通れる仕組み」

普段は本人が握っているのでセキュリティ機能として働きますが、握る側が入れ替わった瞬間に、同じ仕組みが本人を締め出す装置になります。そしてその状態からの復旧手段は、プラットフォーム側の判断にほぼ全面的に依存します。

だからこそ、second factor を奪われる前段階、つまり登録メールアドレスの防御と、変更通知に対する即時の巻き戻しが重要だと感じました。アカウント本体の 2FA を固めても、その 2FA を差し替えられる経路が空いていたら意味が薄れます。

もし同じ状況になった方は、諦めずにサポートとやり取りを続けてみてください。時間はかかりますが、返ってきます。

参考

  cards

シェアする

  • このエントリーをはてなブックマークに追加

フォローする