Microsoft Teams の Cookie 暗号化を悪用：新たな BOF ツールがレッドチームにもたらすものは？

New BOF Tool Exploits Microsoft Teams’ Cookie Encryption Allowing Attackers to Access User Chats

2025/11/03 CyberSecurityNews — Beacon Object File (BOF) とは、アプリケーションの動作を妨げることなく、Microsoft Teams から認証 Cookie を抽出するために設計されたものである。最近の調査結果により、Teams の機密性の高いアクセス・トークンが保存される方法が明らかにされ、それに基づき BOF が開発された。この Teams における方法では、ユーザーを装う攻撃者が、チャット／メール／ドキュメントなどにアクセスする経路が生じる。

Tier Zero Security がリリースした BOF ツールは、既存のブラウザ攻撃手法を応用して Teams のファイル・ロック・メカニズムを回避するものであり、エンタープライズ環境におけるエンドポイント・セキュリティに関する新たな懸念を露呈させるものだ。

この試みは、Teams の認証プロセスの詳細な分析から生まれた。

RandoriSec による最近の調査結果で概説されているように、Microsoft Teams は msedgewebview2.exe プロセスを使用して、ブラウザ・ウィンドウをエンベッドしている。この Chromium のプロセスは、Microsoft のオンライン・サービスを介してログインを処理する。

このプロセスは、従来の Web ブラウザと同様に、認証中に SQLite データベースに Cookie を書き込む。

これらの Cookie には、Microsoft Graph API へのアクセスを許可するアクセス・トークンが含まれており、それにより、Teams の会話／Skype に加えて、Office 365 の広範な機能が接続される。

その一方で、最新の Chromium ブラウザは防御を強化している。現在では、SYSTEM 権限で実行される COM ベースの IElevator サービスを通じて暗号化キーを保護し、実行ファイルの安全なインストール・パスをチェックすることで、呼び出し元の正当性を検証する設定になっている。

この設定では、Cookie 値を復号化するために、ブラウザ・プロセス内での実行または管理者特権でのアクセスが必要になる。

しかし Teams は、カレント・ユーザーのマスターキーに紐付けられた、よりシンプルな Data Protection API (DPAPI) に依存しているため、暗号化キーの取得により Cookie を標的とする攻撃が容易になってしまう。

プロセス・インジェクションによるファイル・ロックの克服

当初の調査で主要な障害となったのは、Teams の実行時の動作だった。アプリケーションの実行中では、バックグラウンドであっても Cookies データベースファイルがロックされ、直接の読み取りやコピーは防止される。

Tier Zero Security のポストで示唆されるように、MS-Teams.exe プロセスを強制終了すると、ユーザーに警告が表示され、セキュリティ監視が開始される。

この問題に対処するため、研究者たちが参考にしたのが Cookie-Monster-BOF である。この BOF は、ファイル・ハンドルを複製して、IElevator サービスを呼び出すことで、稼働中のブラウザ・プロセスから Cookie を抽出するオープンソース・ツールである。

新しい Teams-Cookies-BOF は、このロジックをメッセージング・アプリ向けに再利用するものだ。つまり、Teams を強制終了するものではなく、MS-Teams.exe プロセス内で直接実行され、DLL／COM ハイジャックを介することで、Cookie ファイルへのオープン・ハンドルを保持している子 WebView プロセスを特定する。

したがって、これらのハンドルを複製し、ファイルの内容をリアルタイムで読み取り、ユーザーの DPAPI マスターキーを使用して値を復号できるようになる。このアプローチにより、ツールは正当なプロセスの動作を模倣し、ファイル・システムを混乱させることなく、ステルス性を確保する。

注目すべきは、BOF の柔軟性が単なる Teams インジェクションを超える点である。具体的に言うと、同じユーザー権限を共有する任意のプロセスで実行され、システム全体の WebView 子プロセスにクエリを発行し、関連する Cookie のダウンロードを可能にする。

それにより調査の適用範囲が広がり、無関係なプロセスに対する異常なハンドル操作といった、検出が可能な指標が新たに得られるようになる。

デモンストレーションとして研究者たちが公開したのは、自然なコンテキスト内で同様の結果を達成する Gist スクリプトである。ただし、このスクリプトには、Teams 以外の二次的な Cookie を取得するリスクがある。

レッドチーム担当者と防御担当者への影響

復号メカニズムに関しては、Cookie-Monster-BOF と全く同じであり、データベース内の “v10” タグ付き値から nonce と暗号化されたペイロードを抽出した後に、AES-256-GCM を使用する。

こうしてトークンを取得すると、会話履歴の取得／メッセージの読み取り、被害者を装うフィッシング・コンテンツの送信などが API 呼び出しにより可能になるため、ラテラル・ムーブメントやソーシャル・エンジニアリング・キャンペーンのリスクが高まる。

Tier Zero Security は、BOF を GitHub で公開している。この BOF は、ビーコン・ペイロードをサポートするあらゆる C2 フレームワークと互換性があり、基本的な使用において引数は必要とされない。

このリリースが浮き彫りにするのは、強化されたブラウザとの比較において、Teams のセキュリティ・モデルに依然として存在するギャップである。ユーザー組織にとって必要なことは、プロセス・インジェクションの挙動監視を優先し、最小権限実行を適用し、DPAPI アクセスや WebView ハンドル操作を標的とするエンドポイント検出ルールを検討することだ。

多種多様なハイブリッド・ワークが、Teams に大きく依存している。したがって、このような脆弱性により明らかにされるのは、生産性向上アプリに組み込まれたブラウザ・コンポーネントに対する継続的な精査の必要性である。

この記事で明らかにされた要点は、Beacon Object File (BOF) という強力なレッドチーム・ツールの登場と、WebView2 経由でトークンを SQLite とカレント・ユーザー DPAPI に保存する、Teams の設計上の弱点です。ファイル・ロックや復号の保護が限定的なため、プロセス内でのハンドル複製やインジェクションによる正規プロセス模倣が可能となり、Cookie を抽出されやすくなっています。さらに、復号はユーザーのマスターキーに依存するため、同一権限で動くプロセスが攻撃対象になりやすいとも、この記事は指摘しています。ご利用のチームは、ご注意ください。よろしければ、Teams で検索を、ご参照ください。