インフォスティーラー(情報窃取マルウェア)のログは、アンダーグラウンドの取引商品から実運用上のセキュリティ課題へと変貌を遂げています。防御側にとって、漏えいした認証情報を発見することは、あくまで出発点にすぎません。今日、多くのセキュリティアナリストは、こんなアラートで一日を始めます。従業員の企業メールアドレスが、新たに収集されたインフォスティーラーのログに出現した、というものです。
そのログには、企業向けSaaSアプリケーションのユーザー名とパスワードが含まれています。ブラウザのクッキーもあり、これは悪用可能なライブセッションを意味します。さらに、ファイルに保存されたその他の認証情報も複数見つかります。
会社のオフィスから何百マイルも離れた場所にある従業員個人のパソコンが、Vidarに感染していました。さて、どうすればよいのでしょうか。
漏えいしたパスワードをリセットするのは、当たり前の対応に思えます。しかし、それだけでは問題は解決しないかもしれません。もしスティーラーが認証済みのセッションクッキーを窃取していたなら、攻撃者はパスワードや追加のMFA認証を必要とせず、すでにそのアプリケーションへの侵入経路を確保している可能性があります。また、従業員が個人のパソコンで企業の認証情報を使い回していた場合、漏えいの原因となった端末自体が組織の管理下にすら入っていないケースもあります。
そして、どこかのアンダーグラウンドなTelegramチャンネルでは、同じ情報がすでに初期アクセスブローカーやランサムウェアのアフィリエイト、あるいは機会をうかがう攻撃者の手に渡っている可能性もあります。
これこそが、セキュリティチームがインフォスティーラーのログをめぐって直面する機会がますます増えている、実運用上の課題です。
Flare Researchの「実務者のためのスティーラーログ監視ガイド」によれば、企業の認証情報を含むスティーラーログのおよそ46%は、管理下にない、あるいは個人所有とみられる端末に由来しています。またFlareは、主要な業務効率化SaaSやクラウドサービスに関する認証情報およびセッションの漏えいが、年間およそ29%のペースで増加していると推定しています。
防御側にとって、もはや問われるべきは「インフォスティーラーのログを監視すべきかどうか」という単純な話ではありません。
より難しい問いは、こうです。意味をなさない古いパスワードと、今まさに進行しているかもしれないID侵害とを、どう見分けるのか。
無数の針の山から一本の針を探す
RedLine、Lumma、Vidarなどのインフォスティーラーは、感染したシステムに保存されている情報を収集するために作られたマルウェアです。
マルウェアの種類や設定次第で、その対象にはブラウザに保存されたパスワード、クッキー、自動入力情報、暗号資産ウォレット、システム情報、VPN設定、その他の認証関連情報が含まれます。
これらは「インフォスティーラーログ」としてパッケージ化され販売されますが、たった一件の感染から数百から数千件もの個別レコードが生成されることもあります。これが世界規模のマルウェアエコシステム全体で積み重なれば、防御側はたちまち規模の問題に直面します。
防御側はすべてを処理し検証しなければなりませんが、攻撃者に必要なのは、価値ある有効な認証情報セットがたった一つだけです。Flareがこの問題を表現するように、これは「干し草の山から一本の針を探す」話ではありません。「無数の干し草の山の中から、無数の針の中の特定の一本を探す」話なのです。
スティーラーログはかつてアンダーグラウンドのフォーラムやマーケットプレイスで流通していましたが、Flareの調査によると、現在ではログのおよそ90%がTelegram上に出現しています。公開チャンネルではサンプルが宣伝され、非公開の有料チャンネルではより新鮮なデータセットへのアクセスが提供されています。
盗まれたセッションクッキーが、すでにあなたのMFAを突破していないか?
インフォスティーラーのログは、パスワードもMFA認証も丸ごと飛び越えて、攻撃者にライブの認証済みセッションを渡してしまうことがあります。
Flareはダークウェブとテレグラムにまたがってスティーラーログをリアルタイムで監視しており、漏えいした企業のIDやセッションがアカウント乗っ取りに発展する前に検知できます。
ログの中で最も危険なものは、パスワードとは限らない
複数のチャンネルにまたがる膨大な量のデータを前にすると、リスクの優先順位付けは容易ではありません。数千人の従業員を抱える大企業に勤めていて、一日の始まりに二件のアラートを受け取ったとしたら、どちらがより危険かをどう判断すればよいのでしょうか。
一つ目のアラートは、従業員が使っていた消費者向けウェブサイトの古いパスワードが半年前のスティーラーログに出現したというものかもしれません。一方、二つ目のアラートは昨日収集されたばかりで、従業員の企業ID認証情報と、組織のIDプロバイダーに対する認証済みブラウザセッションが含まれているかもしれません。
どちらも「従業員の認証情報漏えい」というラベルが貼られてはいても、両者はまったく別物です。
だからこそ実務者は、潜在的な影響について何かを示唆する資産、たとえば企業のドメインやサブドメイン、企業向けIDプロバイダー、セッションクッキー、VPNやRDPのエンドポイント、クラウドコンソールなどを中心に、監視の優先順位を組み立てるべきです。
とりわけIDプロバイダーには特別な注意が必要です。SSOのID(Microsoft Entra ID、Okta、Google Cloud Identityなど)が一つ侵害されるだけで、複数の連携アプリケーションへの侵入経路が開かれかねないためです。可能な場所では、自動化された検証と緩和策によって、この防御をさらに強化できます。
セッションクッキーに潜む危険
ユーザーが認証に成功すると、アプリケーションはセッションクッキーを発行します。これにより、リクエストのたびに再認証する必要がなくなります。
マルウェアがその認証済みセッションを窃取すれば、攻撃者はそれをリプレイ(再利用)できてしまう可能性があります。
つまり、攻撃者がセッションクッキーを手に入れ、インフォスティーラーがそれを収集していれば、必ずしもログインする必要すらないのです。盗まれた認証情報だけであれば、依然として認証プロセスを経る必要があり、そこに防御側がログインを検知・阻止できる余地が生まれます。しかし有効なセッションクッキーがあれば、その手順自体がまるごと不要になりかねません。これは実質的にMFAを迂回してしまうことを意味します。
最初の60秒
Flareは、関連する可能性のあるスティーラーデータを発見した直後にまず初期評価を行い、その後リスクスコアリングと検証へ進むことを推奨しています。
目的は、最初の数分間で調査全体を完了させることではありません。組織がどれほど迅速に対応すべきかを見極めることです。
まず立てるべき有用な問いは、「実際に何が盗まれたのか」です。アナリストは、感染がいつ発生したか、どのシステムがそのログを生み出したか、企業の認証情報がいくつ含まれているか、そして認証済みセッションが窃取されたかどうかを特定する必要があります。
そこにビジネス上の文脈を加えます。
testserver.company.comの認証情報と、finance.company.comの認証情報を、必ずしも同じ優先度で扱うべきではありません。
同様に、マーケティング部門のインターンに属する漏えいIDと、IDプロバイダーやクラウドコンソール、本番インフラへのアクセス権を持つ管理者のIDとを、自動的に同じように扱うべきではありません。
そのためFlareのガイドが示す例示的なフレームワークでは、企業ID認証情報とセッションクッキーが組み合わさったケースを重大度「Critical」に位置づけ、1時間以内の対応を目標として提案しています。VPN/RDPアクセスに複数の企業認証情報が組み合わさったケースは、横展開(ラテラルムーブメント)のリスクが高いことから、重大度「High」に分類されます。
漏えいから調査へ
仮に、先ほどの従業員のログにEntra IDの認証情報、企業SaaSのパスワード、ブラウザクッキーが含まれていたとしましょう。次に問うべきは、すでに誰かがそれらを使用したかどうかです。
防御側は、漏えいしたIDを認証テレメトリと突き合わせることができます。ログインの成功・失敗、予期しない地理的位置、見慣れない端末、身に覚えのないIPアドレス、そして従業員の通常の行動範囲から外れたリソースへのアクセスなどです。
また、盗まれた情報が今なお使用可能な状態にあるかどうかも見極める必要があります。感染以降にパスワードは変更されたか。セッションは失効しているか。アカウントは今も有効か。
Flareが推奨する調査ワークフローでは、この分析範囲をさらに広げ、ブラウザのフィンガープリント情報、保存された認証情報の完全な一覧、感染したシステムに関する情報、さらにはVPN設定やSSH鍵といった追加の痕跡も対象に含めます。
その従業員は何者なのか。そのIDで何にアクセスできるのか。感染した端末は企業のものだったのか、それとも個人のものだったのか。これは単発の感染だったのか、それともより広範なキャンペーンの証拠なのか。
そのうえで、そのIDがアクセスできる各システムにわたって認証ログを調べ、最も機微なリソースから優先的に確認していきます。
防御側が特に注視すべきなのは、漏えいがアカウント乗っ取りへと進行していることを示す挙動です。予期しない場所からの認証、ユーザーの役割に見合わないアクセス、不審なダウンロード、パスワードリセットの試み、新規MFAデバイスの登録などが該当します。こうしてスティーラーログは、ID侵害を早期に察知するセンサーとしての役割を果たすようになります。
スティーラーログはIDの問題として扱う
高リスクの漏えいが確認された後は、スピードが物を言います。防御側は、侵害されたセッションを失効させ、影響を受けた認証情報をリセットし、そのIDに対する監視を強化する必要があります。
個別のインシデント対応にとどまらず、組織は繰り返し発生する漏えいの傾向、影響を受けるアプリケーション、そして盗まれた認証情報が実際のアクセス試行につながっているかどうかを追跡すべきです。
結局のところ、インフォスティーラーの監視はID保護における不可欠な一層となりつつあります。これにより組織は、漏えいした認証情報やセッションを特定し、それらが与えるアクセス範囲を把握し、なお悪用可能な状態にあるかどうかを判断し、アカウント乗っ取りがより大規模な侵害へと発展する前に食い止めることができます。
