QR コードを利用した侵入経路: ブラウザ分離環境での C2

※この投稿は米国時間 2024 年 12 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

概要

• ブラウザ分離は、ウェブの閲覧アクティビティをユーザーのローカル デバイスから分離し、安全な環境（クラウド サーバーや仮想マシンなど）でブラウザを実行して視覚コンテンツをユーザーのデバイスにストリーミングするセキュリティ技術です。

• ブラウザ分離は、組織がフィッシングの脅威に対抗し、ブラウザを介した攻撃からデバイスを守り、攻撃者によるコマンド＆コントロール（C2 または C&C）戦術を阻止するためによく使用されます。

• このブログ投稿では、現在使用可能な 3 つのタイプのブラウザ分離（リモート、オンプレミス、ローカル）すべてをすり抜けて、悪意あるインプラントを C2 で制御するために使用される最新の技術について、Mandiant が解説します。攻撃者がどのように機械で読み取り可能な QR コードを使用して、攻撃者が制御するサーバーから攻撃対象のデバイスにコマンドを送信するのか、その方法について説明しています。

ブラウザ分離の技術背景

今年、SpecterOps チームがブラウザ分離に関するブログ投稿を掲載し、ペネトレーション テスターやレッドチームのオペレーターがブラウザ分離環境を迂回して内向きのツール転送、外向きのデータ転送を行う方法と、一般的なバイパス手法について説明しました。ブラウザ分離とは、要約すると、ウェブブラウザを安全な環境（ローカルまたはリモート）にサンドボックス化して、視覚コンテンツをユーザーのローカル ブラウザにストリーミングすることで、ユーザーをウェブベースの攻撃から保護する仕組みです。エンドユーザーにとっては（理想的には）完全に透過的なエクスペリエンスとなります。多くの関連ドキュメントによると、ブラウザ分離は通常 3 つのタイプに分けられます。

1. リモート ブラウザ分離（RBI）は、最も安全かつ一般的なタイプで、ブラウザをクラウドベースの環境にサンドボックス化します。

2. オンプレミス ブラウザ分離は、RBI に類似していますが、ブラウザをオンプレミス環境にサンドボックス化する点が異なります。このアプローチの利点は、クラウドからオンプレミスへの複雑な接続を必要とせずにオンプレミスのウェブベース アプリケーションにアクセスできることです。

3. ローカル ブラウザ分離（クライアントサイド ブラウザ分離）は、ローカルのコンテナ環境または仮想マシン環境（Docker または Windows Sandbox）でブラウザをサンドボックス化して実行します。

ブラウザ分離環境では、ウェブページのレンダリングから JavaScript の実行まで、すべてがリモート ブラウザで処理され、ウェブページの視覚的な表示だけがユーザーのローカル ブラウザに（ピクセルのストリーミングとして）送り返されます。ローカル ブラウザでのキー入力やクリックはリモート ブラウザに転送され、ウェブ アプリケーションとのユーザー インタラクションが可能になります。組織は通常、すべてのウェブ トラフィックがブラウザ分離技術を経由するようにプロキシを使用します。これにより、下り（外向き）ネットワーク トラフィックが制限され、攻撃者がブラウザ分離をバイパスしにくくなるようにしています。

SpecterOps は、攻撃型の役割を担うセキュリティ専門家がブラウザ分離環境で攻撃活動を行う際に直面する課題のいくつかを詳しく解説しています。HTTP ヘッダー、Cookie、認証パラメータを使用して分離をバイパスするなど、構成ミスを悪用してブラウザ分離を迂回する方法について記述しています。

ブラウザ分離で典型的なコマンド＆コントロールを阻止

コマンド＆コントロール（C2 または C&C）とは、攻撃者がシステムに不正アクセスし、悪意あるインプラントを利用して遠隔操作することを指します。攻撃対象デバイスとのコマンドの送受信は、HTTP リクエストを使用して、次のように行われるのが最も一般的です。

1. インプラントが（HTTP パラメータ、ヘッダー、リクエスト本文内で）HTTP リクエストを使用して、攻撃者が制御する C2 サーバーからコマンドをリクエストします。

2. C2 サーバーが（ヘッダーまたは本文を介し）HTTP レスポンスを使用して、実行するコマンドを返します。

3. インプラントが HTTP レスポンスをデコードしてコマンドを実行します。

4. インプラントがコマンド出力を別の HTTP リクエストとして C2 サーバーに返送します。

5. インプラントはしばらく「潜伏」状態になった後、このサイクルを繰り返します。

しかし、ブラウザ分離が使用されている環境では、この方法は困難となります。ブラウザ分離システムを介して HTTP リクエストを作成した場合、ローカル ブラウザに返される HTTP レスポンスには、リモート ブラウザの視覚的なページ コンテンツをレンダリングするためのストリーミング エンジンのみが含まれます。ウェブサーバーから送信された元の HTTP レスポンスは、リモート ブラウザでのみ使用可能です。HTTP レスポンスはリモート ブラウザでレンダリングされ、ウェブページを視覚的にレンダリングするためのピクセルのストリーミングのみがローカル ブラウザに送信されます。この仕組みでは、ローカル デバイスが HTTP レスポンスをデコードできないので（上記のステップ 3 が成立しない）、典型的な HTTP ベースの C2 は阻止されます。

このブログ投稿では、ブラウザ分離環境のシステムに不正アクセスして C2 を達成する新しいアプローチを検証します。この手法は、完全にブラウザ分離環境内で行われます。

C2 データをピクセルで送信

この課題に対して、Mandiant のレッドチームは斬新な解決方法を開発しました。C2 データを HTTP リクエスト ヘッダーや本文で返す代わりに、C2 サーバーは QR コードを表示する有効なウェブページを返します。これを受けて、インプラントが Selenium を使用するなどしてローカルのヘッドレス ブラウザでページをレンダリングし、スクリーンショットをキャプチャして QR コードを読み取ります。これによって、QR コードに埋め込まれたデータが取得されます。機械で読み取り可能な QR コードを使用することで、ウェブページのレンダリングがリモート ブラウザで行われる場合でも、攻撃者が制御するサーバーから悪意あるインプラントにデータを送信することが可能となります。

HTTP レスポンスをデコードしてコマンドを実行する代わりに、インプラントは（ブラウザ分離環境のピクセル ストリーミング エンジンからの）ウェブページを視覚的にレンダリングし、ページに表示された QR コードからコマンドをデコードします。この新しい C2 プロセスは次のサイクルをたどります。

1. インプラントが DevTools プロトコルを使用してローカルのヘッドレス ブラウザを制御します。

2. インプラントがヘッドレス ブラウザを使用して C2 サーバーからウェブページをリクエストします。このリクエストはリモートの（分離された）ブラウザに転送され、最終的に C2 サーバーに到着します。

3. C2 サーバーが QR コードにエンコードされたコマンド データを含む有効な HTML ウェブページを返します（QR コードはウェブページに視覚的に表示されます）。

4. リモート ブラウザがピクセル ストリーミング エンジンをローカル ブラウザに返し、視覚的なストリーミングを開始して C2 サーバーから取得したウェブページをレンダリングして表示します。

5. インプラントは、ページが完全にレンダリングされるのを待ってから、ローカル ブラウザのスクリーンショットをキャプチャします。このスクリーンショットに QR コードが含まれます。

6. インプラントが、埋め込まれている QR スキャンニング ライブラリを使用してスクリーンショットから QR コードのデータを読み取り、QR コードに埋め込まれたデータを取得します。

7. インプラントが侵入したデバイスでコマンドを実行します。

8. インプラントが（再度ローカル ブラウザを介して）新しい URL にアクセスします。この URL には、URL パラメータにエンコードされたコマンド出力が含まれています。このパラメータがリモート ブラウザを介して最終的に C2 サーバーに送られます（不正アクセスでない場合でも、正しいウェブページを返すためには URL パラメータが必要となります）。C2 サーバーは、従来の HTTP ベース C2 と同じ方法でコマンド出力をデコードできます。

9. インプラントはしばらく「潜伏」状態になった後、このサイクルを繰り返します。

Mandiant は、Puppeteer とヘッドレス モードの Google Chrome ブラウザを使用して概念実証（PoC）のインプラントを構築しました（最新のブラウザであればどれでも使用できます）。Mandiant はこの検証をさらに一歩進め、インプラントと Cobalt Strike の External C2 機能を統合することにより、HTTP リクエストと QR コード レスポンスの通信において Cobalt Strike の BEACON インプラントを使用できるようにしました。

この手法は、ウェブページの視覚コンテンツを利用するため、3 つのブラウザ分離タイプ（リモート、オンプレミス、ローカル）すべてで機能します。

この手法の実現可能性は PoC で実証されましたが、注意すべき点や問題点もいくつかあります。

• Mandiant のテストおいては、最大データサイズ（2,953 バイト、グリッドサイズ 177 x 177、誤り訂正レベル L）の QR コードの使用が実用的でないことが判明しました。ローカル ブラウザでレンダリングされたウェブページの視覚ストリーミングの質が、QR コードのコンテンツを確実に読み取るには不十分であったためです。最大 2,189 バイトのコンテンツを含む QR コードまでフォールバックする必要がありました。注: QR コードは、誤り訂正レベル（ECL）の設定に応じて、1 つのインスタンスにつき最大 2,953 バイトのデータを格納できます。ECL 設定が高いほど QR コードは読み取りやすくなりますが、最大データサイズは小さくなります。

• Chrome のヘッドレス モード使用によるオーバーヘッド、リモート ブラウザの起動時間、ページ レンダリング要件、視覚コンテンツのリモート ブラウザからローカル ブラウザへのストリーミングにより、各リクエストで QR コードを適切に表示してスキャンするのに約 5 秒かかります。これは、C2 チャネルに大きなレイテンシを生じさせます。たとえば、現時点で BEACON ペイロードは約 323 KiB です。QR コードごとに 2,189 バイト、リクエストごとに 5 秒を要する場合、フル BEACON ペイロードは約 12 分 20 秒で転送されます（約 438 バイト/秒、すべての QR コードがエラーなしでスキャンされ、各ネットワーク リクエストがシームレスに処理されたと仮定）。このスループットは典型的な C2 操作には十分ですが、一部の手法（SOCKS のプロキシなど）では実用的ではありません。

• ブラウザ分離の他のセキュリティ機能（ドメインの評価、URL スキャン、データ損失防止、リクエストにおけるヒューリスティックなど）は、このブログ投稿では考慮されていません。攻撃型のセキュリティ専門チームは、ブラウザ分離環境で操作する際、これらのセキュリティ保護対策をすり抜ける方法も見つける必要があります。

結論と推奨事項

このブログ投稿では、Mandiant がブラウザ分離環境において C2 を確立する新しい手法を示しました。この手法はブラウザ分離技術にも弱点があることを実証していますが、Mandiant は他のタイプの攻撃（クライアントサイドのブラウザの悪用やフィッシングなど）に対する強固な保護対策として、これまでどおりブラウザ分離を推奨しています。ウェブベースの脅威から組織を保護するためには、ブラウザ分離のみに依存するのではなく、「多層防御」戦略を採用して包括的なサイバー防衛体制を確立する必要があります。Mandiant は以下の管理体制の構築を推奨しています。

1. ネットワーク トラフィックのモニタリングによる異常の検知: ブラウザ分離を採用している場合でも、ネットワーク トラフィックを検査し、使用状況に異常がないかモニタリングする必要があります。このブログで取り上げている C2 方式は低帯域幅で行われるので、小さいデータセットを転送する場合でも多くの HTTP リクエストを必要とします。

2. 自動モードのブラウザのモニタリング: ブラウザが自動モードで使用されているかどうかは、プロセス コマンドラインを検査することでモニタリングできます（方法は上の動画を参照）。Chromium ベースのブラウザでは、--enable-automation や --remote-debugging-port などのフラグを使用して、DevTools プロトコルでブラウザを管理する他のプロセスを有効にできます。組織はプロセス作成中にこれらのフラグをモニタリングできます。

多数のサイバー攻撃エミュレーションやレッドチームとパープルチームによる評価分析を通じて、Mandiant は攻撃者が攻撃対象システムに不正アクセスする独特な方法について理解を深めています。詳しくは、Mandiant 技術保証サービスをご覧になり、ご不明な点がありましたらこちらまでお問い合わせください。

-Mandiant、執筆者: Thibault Van Geluwe de Berlaere 氏