ブラウザデータを狙うInfostealerと対策技術について - セキュリティ研究センターブログ

はじめに

　 "Information Stealer (Infostealer)"は、端末から様々な情報を窃取するマルウェアです。多くのInfoStealerは、ブラウザが保存している機微データ（例えば、ユーザによって入力されたログインIDやパスワード、クレジットカード情報、Cookie*など）を窃取します。
*Cookieとは、セッション管理、個人設定の保持、トラッキングなどの目的でブラウザ内に保存されるデータです。Cookieを盗まれると、場合によっては不正アクセス等につながる危険性があります。

　Infostealerの感染経路は多々ありますが、最近では、"ClickFix"と呼ばれる、偽のCAPTCHA画面やアップデート画面などを通じてユーザにPowershellを実行させ、最終的にInfostealerに感染させるというソーシャルエンジニアリング手法が多発しており、注意が必要です。

　本記事では以下の解説を行います。

Infostealerがどのようにしてブラウザデータの窃取を行うのか
Infostealer対策としてブラウザに実装されたApp-Bound Encryption の仕組みについて
App-Bound Encryptionを回避しようとするInfostealerについて
対策例

　なお、本記事は、未公開のブラウザセキュリティの不備を明らかにするものではありません。攻撃者は認知済みですでに広く悪用されているものの、防御側では理解が進んでいないメカニズムの概要や現状のリスクを解説する目的で公開するものですので、あらかじめご了承ください。

注意事項

本記事は、2025年3月26日時点にChromium Code Searchに公開されていたコードをベースにしております
本記事は、「Windows版Chromiumベースブラウザ(Microsoft Edge, Google Chrome等)」を対象とし、単に「ブラウザ」と記載します

ブラウザがデータを保存する仕組み

　ブラウザが取り扱う様々な機微情報は、暗号化された状態でローカルに保存されます。

　この機微情報の暗号化を行うためには秘密鍵が必要ですが、その秘密鍵は、"Data Protection API (DPAPI)"と呼ばれるWindows組み込みのデータ保護APIを使用して暗号化され、ローカルに保存されます。

　ブラウザデータの暗号化と復号の簡易的なイメージは以下の通りです
（実際は複雑な処理が行われていますが、ここでは簡略的に図示しています）。

図1. 暗号化のイメージ図

図2. 復号のイメージ図

Windows Data Protection API(DPAPI)の仕組み

　DPAPIは、Windowsログオンユーザ情報を使用してデータの暗号化及び復号を行うことのできるWindows APIです。

　例えば、あるWindows端末に、ログオンユーザとして「Alice」と「Bob」が設定されているとします。
「Alice」がDPAPIを使ってあるデータを暗号化した場合、「Alice」はDPAPIを使って暗号文を復号することができます。

図3. 同一ユーザ・同一アプリケーションによる復号成功のイメージ図

　一方で、「Alice」がDPAPIを使ってあるデータを暗号化した場合、「Bob」がその暗号化されたデータを入手したとしても、DPAPIを使って復号することはできません。

図4. 別ユーザ、同一アプリケーションによる復号失敗のイメージ図

　まとめると以下のような関係になります。

表1. 秘密鍵の復号成功条件

		同じ	異なる
		暗号化を行ったアプリケーションと復号を試みたアプリケーションが
暗号化を行ったユーザと復号を試みたユーザが	同じ	復号可能	復号可能
暗号化を行ったユーザと復号を試みたユーザが	異なる	復号不可	復号不可

　ここで重要なのは、DPAPIの復号成功条件は、暗号化を行ったユーザと復号を試みたユーザが同一であるかどうかであって、暗号化を行ったアプリケーションと復号を試みたアプリケーションが同一であるかは関係ないということです。

　つまり、「Alice」が「Application1」というアプリケーションでDPAPI暗号化を行った場合、「Alice」であれば「Application2」という暗号化時とは異なるアプリケーションでもDPAPI復号することができます。

図5. 同一ユーザ、別アプリケーションによる復号成功のイメージ図

従来のInfostealerによるブラウザデータ窃取の仕組み

　これまでの内容を整理しながら、「何故Infostealerがブラウザのデータを窃取できるのか」をまとめたいと思います。

ブラウザは、機微データを暗号化してローカルに保存
暗号化のための秘密鍵は、ブラウザ実行ユーザでDPAPIによる暗号化が行われ、その後ローカルに保存　
この暗号化された秘密鍵は、ブラウザ実行ユーザであれば異なるアプリケーション(=Infostealer)でもDPAPIで復号可能（管理者権限不要のため、ユーザに気づかれにくい）

図6. 実際に窃取・復号したデータ例（Windows版Chrome 134.0.6998.178で検証）

　根本的な問題は、DPAPIは、「暗号化時と同じアプリケーションでなければ復号できない」ということを強制する機能をもっていないことです（本来、ブラウザによって暗号化されたデータはブラウザによってのみ復号できるべきかと思いますが、それができない）。

補足：ブラウザの同期機能について

　ある端末のブラウザで入力した入力したログイン情報等を、別の端末のブラウザでも共有する"同期機能"を提供するブラウザがあります（例えばGoogle Chromeの場合、Googleアカウントで同期可能）。

　例えば、AというWindows端末と、BというWindows端末があったとして、それぞれのブラウザは同じアカウントでブラウザ同期されていたとします。BがInfostealerに感染した場合、Aのブラウザデータは窃取されるのでしょうか？

　筆者環境で試したところ、少なくともGoogle Chromeにおいては、同期されたデータの窃取は可能でした（全てのブラウザデータが同期されるわけではありません）。

　この場合、端末BのWindowsログオンユーザ権限でInfostealerが実行されます（このとき、端末Aに関するなにか情報が必要だとか、操作が必要だとか、そういったことは一切なく、端末B上で窃取が完結します）。

図7. 別端末からのログイン情報窃取例（Windows版Chrome 134.0.6998.178で検証）

　時々、私有端末と会社支給の業務用端末で、同じアカウントを使ってブラウザ同期をしている人を見かけます。私有端末がInfostealer感染することで、間接的に業務用端末のブラウザ情報の一部が窃取される可能性があることを考えると、この同期は非常に危険です。

　企業の情報システム部門の方は、従業員へ個人アカウントの同期をしないように教育したり、同期させないようにシステム的に強制したりするなどの対処を行ったほうがよいかと思います。

Infostealer対策： App-Bound Encryption

　このようなInfostealerの攻撃に対して、ブラウザ側も多くの対策を導入をしています。

　本節では、2024年7月に発表された、"App-Bound Encryption"とよばれる対策について紹介します (Google, Improving the security of Chrome cookies on Windows) 。

App-Bound Encryptionは、ここまでお話してきたブラウザデータの秘密鍵の暗号化に関する機能となり、従来通りベースはDPAPIですが、大きく以下の2点にておいて改良がなされています。

秘密鍵の暗号化には、異なるユーザコンテキスト（実行ユーザとSYSTEMユーザ）による二重の暗号化を行う
秘密鍵の復号には、秘密鍵を暗号化したときのアプリケーションと同じであることを検証する

　文章だけだと少し分かりづらいと思いますので、次節で詳細を説明していきたいと思います。

　なお、App-Bound Encryptionはローカル保存されるCookieから保護を始め、今後順次展開予定とのことです。

App-Bound Encryptionの仕組み

　App-Bound Encryptionの最大の特徴は、DPAPIを使って秘密鍵の暗号化や復号を行う機能をブラウザから分離した点にあります（"Elevation Service"と呼ばれるComponent Object ModelでDPAPIの処理がなされます）。

　試しにProcess Monitorで見てみると、確かにブラウザがElevation Serviceの検索を行っている様子が見えます（SYSTEMユーザで起動している点にも注目です）。

図8. Process Monitor例

　このような分離によって、秘密鍵の暗号化及び復号プロセスがどのようになっているか見ていきたいと思います。

　まずは、秘密鍵の暗号化プロセスです（本来はもっと複雑な処理を行っていますが、ここでは概略的に示します）。

ブラウザは、Elevation Serviceに秘密鍵を渡して、秘密鍵の暗号化を要求する
Elevation Serviceは、受け取った秘密鍵に、暗号化要求アプリ(=ブラウザ)の情報を結合する
Elevation Serviceは、暗号化要求アプリの実行ユーザに偽装して(CoImpersonateClient)、「秘密鍵+暗号化要求アプリ情報」をDPAPI暗号化する
Elevation Serviceは、上記で暗号化された「秘密鍵+暗号化要求アプリ情報」を、更にSYSTEMユーザとしてDPAPI暗号化する
二重に暗号化された「秘密鍵+暗号化要求アプリ情報」をブラウザへ返し、ブラウザはローカルに保存する

図9. App-Bound Encryptionによる秘密鍵の二重の暗号化イメージ

　続いて、秘密鍵の復号です（同じく概略的に示します）。

ブラウザは、二重に暗号化された「秘密鍵+暗号化要求アプリ情報」をElevation Serviceに渡して、復号を要求する
Elevation Serviceは、受け取った二重に暗号化された「秘密鍵+暗号化要求アプリ情報」を、SYSTEMユーザとしてDPAPI復号する
Elevation Serviceは、暗号化要求アプリ実行ユーザに偽装して(CoImpersonateClient)、上記で復号した「秘密鍵+暗号化要求アプリ情報」を更にDPAPI復号する
暗号化要求アプリ情報を確認して、今回の復号要求アプリ情報と一致するか確認する
上記が一致していれば秘密鍵をブラウザへ返す

図10. App-Bound Encryptionによる二重に暗号化された秘密鍵の復号イメージ

　このようにして、実行ユーザとSYSTEMユーザの二重に暗号化を行うこと、暗号化要求アプリケーションと復号要求アプリケーションの同一性を検証しています。

　従来の秘密鍵の複号成功条件と比較すると、以下のようになります。

表2. 秘密鍵の復号成功条件　従来とApp-Bound Encryption(Elevation Service経由)での比較

		同じ	異なる
		暗号化を行ったアプリケーションと復号を試みたアプリケーションが
暗号化を行ったユーザと復号を試みたユーザが	同じ	従来: 復号可能 App-Bound Encryption: 復号可能	従来: 復号可能 App-Bound Encryption: 復号不可
暗号化を行ったユーザと復号を試みたユーザが	異なる	従来: 復号不可 App-Bound Encryption: 復号不可	従来: 復号不可 App-Bound Encryption: 復号不可

App-Bound Encryptionリリース後のInfostealer動向

　では、App-Bound Encryptionによって、実際にInfostealerはデータの窃取ができなくなるのでしょうか？

　Infostealerがデータ窃取のために秘密鍵を手に入れるには、大きく以下の2通りがまず考えられると思います。

Elevation Serviceを経由して秘密鍵の復号を要求する場合
- 秘密鍵の暗号化要求アプリ情報(=ブラウザ)と、秘密鍵の復号要求アプリ情報(=Infostealer)が一致しないため、Elevation Serviceは復号された秘密鍵をInfostealerに渡しません。
Elevation Serviceを経由せずに直接DPAPIを呼び出す場合
- SYSTEMユーザでDPAPI暗号化がされているため、InfostealerもSYSTEMユーザとしてDPAPI復号を呼び出す必要があります。
  従来は実行ユーザで復号できていたのに対し、こちらでは昇格する必要があるため、攻撃の難易度が上がります。

　このように、App-Bound Encryptionは従来のInfostealerに対して一定の効果があることが分かります。

　しかし、残念ながら、App-Bound Encryption発表の約2ヶ月後の2024年9月には、いくつかの新しい回避手法が発見され、そして一部の手法はInfostealerに組み込まれました(Infostealer malware bypasses Chrome's new cookie-theft defenses)。

　詳細は割愛しますが、App-Bound Encryptionを無効化する方法、Elevation Serviceによる検証を突破する方法、そもそもElevation Serviceやデータ暗号化の影響を受けない別のパスを利用する方法など複数あり、2025年3月時点でも、筆者環境で検証した限りでこれらの手法は有効でした。

図11. App-Bound Encryptionが有効化されたブラウザから抽出されたCookie例（Windows版Chrome 134.0.6998.178で検証）

　なお、2025年3月に、App-Bound Encryptionの影響を受けることなくCookieを窃取する攻撃手法に対処するため、ブラウザの動作を変更する旨の発表がされています(Chrome for developers, Changes to remote debugging switches to improve security)。

　この変更が実現されると、新しい手法が発見されない限りは、InfostealerによるCookie窃取が困難になると想定されます。

　ブラウザのバージョンを常に最新化しておくことで、このような新しい手法に対する防御手段を得ることができる、一つの良い例ではないでしょうか。