ベンダーや請負業者のアカウントを利用してネットワークに侵入する攻撃者が増加中
- Cisco Talos インシデント対応チーム（Talos IR）は最近の緊急インシデント対応業務で、ベンダーと請負業者のアカウント（以下、VCA と表記）が標的にされ、侵害された VCA が攻撃に利用された事例を何度も目にしています。
- ソフトウェア サプライチェーンの侵害という人目を引く事件であれば大いにメディアの注目を集めますが（たとえば先ごろ明らかになった 3CX Desktop Softphone アプリケーションを悪用したサプライチェーン攻撃）、サードパーティの従業員のために作成したアカウントの悪用は見落とされがちです。
- 通常、VCA には必要以上の権限が付与されており、広範囲にアクセスできます。サードパーティには高い信頼が置かれているため、アカウントの監査でそうした VCA を見抜けない場合があります。
- そのため、VCA 関連の問題を防止および検出する機能を強化する必要があります。
ソフトウェア サプライチェーンは、多くの組織にとってセキュリティの重要なテーマになってきましたが、サプライチェーン攻撃に伴うリスクはまだ十分に理解されていません。3CX や MSI
が報告したような大きな事件は度々ニュースの見出しを飾ります。世間の注目を集めたセキュリティ関連の事件の経緯をたどっていくと、サプライチェーンのある特定の側面にぶつかります。それがソフトウェアです。
ソフトウェアに狙いを定めたサプライチェーン攻撃に成功すれば、攻撃者は数十から数百もの被害者にアクセスできます。ただ、こうした攻撃はリソースを大量に消費するうえ、標的の環境やビルドプロセス、ソフトウェアそのものを隅々まで理解していなければ成功しません。また、ソフトウェア サプライチェーン攻撃は本質的に対象範囲が広く、戦略的に標的設定を行うのは困難です。被害者の数が多い攻撃ほど、サイバーセキュリティ コミュニティ内での認知度が高くなります。つまり、最終的に攻撃者が突き止められて阻止される確率が高くなるということです。
サプライチェーンにはエクスプロイトを容易にする側面もあり、被害者の組織内で被害が拡大する可能性があります。業界の注目は、ソフトウェアに狙いを定めたサプライチェーン攻撃を特定して対処することに集まっています。こうした中、Talos IR は侵害した VCA を悪用するインシデントが増えている状況を目の当たりにしてきました。
ベンダーアカウントがサプライチェーンへの格好の侵入口に
VCA は、サードパーティで働く人、つまり組織の環境に物理的あるいは仮想的にアクセスできる外部のパートナー組織の従業員に対して作成されるアカウントです。
VCA は、これから初期アクセスを獲得しようとする攻撃者やすでにアクセスを獲得した攻撃者にとって特に魅力的です。Talos IR は、ある調査をしているときに、攻撃者が権限の低いユーザーアカウントを利用して組織へのアクセスを獲得し、その後さらに 2 つのアカウントを利用して認証に成功した事例を確認しました。1 つは組織全体にソフトウェアを展開するときに使用するサービスアカウントで、もう 1 つはサードパーティベンダーのアカウントです。
どちらのアカウントも、ドメイン管理者の権限かそれに匹敵する権限を持っていました。Talos IR は、攻撃者が最初はサービスアカウントで認証を受けたものの、その後はほぼ例外なくベンダーアカウントを利用していたことを確認しました。それはなぜでしょうか。
攻撃者が同等の権限を持つ他のアカウントよりも VCA の方を好む理由はいくつかあります。
ベンダーは環境にリモートから断続的にアクセスしたり、いつもとは違う時間にアクセスしたりすることがあるため、情報セキュリティチームがそうしたアカウントに対してアクティビティのベースラインを確立するのは容易なことではありません。請負開発チームのメンバーが世界中に散らばっていて各人がそれぞれのシフトで働いている場合、どうすれば時間帯で認証の異常を検出できるでしょうか？請負業者がそれぞれのスケジュールに基づいてリモートから月に数回接続するだけの場合はどうでしょうか？あるいは、臨時のトラブルシューティングのためにログインする場合を考えてみてください。
地理位置情報の異常を検出するのも簡単なことではありません。旅をしながら働くライフスタイルを好むフリーランスのコンサルタントを雇用した場合は、そのアカウントをさまざまな地域から認証できるようにしなければなりません。同様に、大規模な組織の場合、休暇中や出張中の従業員、あるいは別の地域に（一時的または永続的に）異動した従業員をどうすれば簡単に把握できるでしょうか？
権限レベルも攻撃者にとって魅力的な側面です。VCA の権限はベンダーの役割に基づいて設定されるのが一般的ですが、通常はドメイン管理者のように高い権限を持っています。電子カルテ（EHR）や勘定系アプリケーションのような場合では、システムとデータを管理するアクセス権まで持っていることがあります。そうしたアクセス権を、組織の IT 部門と情報セキュリティ部門の従業員が共有することは決してありません。
攻撃者のアクティビティが他の正規ベンダーのアクティビティにカモフラージュされることもあります。テクノロジーベンダーは、コマンドライン実行、構成ファイルの変更、複雑なデバッグとトラブルシューティングに関するタスクを実行するのが一般的です。しっかり監視しているとはいっても、攻撃者がよく実行するアクティビティはこうしたタスクと似たところがあります。前に述べたインシデントからも明らかなように、攻撃者はサービスアカウントよりも VCA を利用するようになっています。システム管理に普段からよく使用されるアカウントを乗っ取ることができれば、監視の目を逃れるのはとても簡単です。
VCA に関するインシデント対応業務で学んだ教訓
Talos IR はこの数年、インシデント対応業務にあたる中で、攻撃者が VCA をさまざまな方法で悪用する事例を何度も目にしてきました。VCA は、初期アクセスに頻繁に利用されるほか、アクセス後は組織のネットワーク内で侵入を拡大するのに使用されます。被害者が多要素認証（MFA）をまだ導入していない場合は特にそうです。通常、VCA には高い権限が付与されているため、VCA のログイン情報が盗まれると、往々にして損害が被害者のアセットへ広がります。それだけでなく、最初の被害者のサプライチェーンをたどって被害が拡大する可能性すらあります。
VCA のログイン情報の盗難といっても、必ずしもユーザー名とパスワードの侵害というわけではありません。Talos IR は、少なくとも 1 件のインシデント対応業務で、攻撃者が盗んだ公開キーを利用して標的の組織を侵害する事例を確認しました。つまり、攻撃者は有効なユーザー名とパスワードを取得しようとする傾向が強いものの、アクセスが容易なら他の認証方式も積極的に使用するということです。VCA を利用している組織にとって、これは重要なポイントといえます。ユーザーアカウントのログイン情報を保護する場合と同じくらいの警戒心を持って、キーをはじめとする認証方式を保護しなければなりません。そのためには、キーローテーションを実施する手順と、侵害を受けた可能性があるキーについてはアクセスを取り消す手順を必ず整備しておく必要があります。
前に述べたように、VCA を悪用すれば権限の昇格とアクセス範囲の拡大が図れます。Talos IR は、複数のインシデント対応業務で、攻撃者が権限の低いアカウントを使用して初期アクセスを獲得したものの、すぐに VCA の使用に切り替えてアクセス範囲を拡大し、最大限の影響を及ぼそうとした事例を確認しました。
アクセスと影響に相関性が見られることがよくあります。その例として、Talos IR が調査した 2 件のランサムウェアインシデントを紹介したいと思います。最初のインシデントでは、攻撃者は Web サーバーサービスアカウントのコンテキストで、一般公開されている Web サーバーへのアクセスを獲得しました。権限の昇格に失敗し、侵入拡大にも失敗したため、ランサムウェアの影響は 1 台のサーバーの Web サーバーディレクトリの一部に限定されました。もう 1 件のインシデントでは、攻撃者は VCA を侵害して Active Directory デフォルトドメインポリシーを変更することで、ドメインに接続されているシステムがドメインの SYSVOL フォルダからランサムウェアバイナリを実行するようにしていました。攻撃者は、この高いアクセス権を利用して、被害者の ESXi ホストでランサムウェアバイナリを実行し、ホストのデータストアにある複数の仮想システムに影響を及ぼしたのです。後者のインシデントの被害は深刻で、VCA に付与したアクセスを厳格に制御する必要性と、VCA が侵害されたらどれだけの影響が出るのかが浮き彫りになった事例でした。
VCA の悪用から保護し、その影響を抑えるための戦略
VCA がもたらすリスクのレベルを理解し認識することが、この脅威を軽減する第一歩です。次に課題となるのが、VCA を適切に保護する方法です。幸い、VCA を保護し、VCA が侵害された場合の影響を軽減するための戦略がいくつかあります。
以下の推奨事項の一部は、防止にとどまらない働きを念頭に置いています。また、こうした推奨事項により、インシデント対応担当者は侵害を受けた VCA の影響を受ける可能性があるシステムの範囲をすぐに把握できるようになります。Active Directory が動作していないときには特に便利です。インシデントでは不要な権限が付与されたままとなっている事例がごく当たり前に見られ、厄介な問題になるため、VCA と一般的なユーザーアカウントを監査することをお勧めします。
不要な VCA を無効にする
IT チームや情報セキュリティチームはさまざまな方法で VCA を保護できますが、中でも特に手軽なのが不要な VCA を無効にすることです。当たり前のことだと思われるかもしれませんが、多くの組織が以前からずっと実施に苦労している課題です。特に、ベンダーの入れ替えが激しい組織が対応に苦慮しています。そこで、信頼できるプロセスを確立して、必要な場合にのみ、ベンダーと請負業者が有効なアカウントにアクセスできるようにすることをお勧めします。このプロセスを確立したら、定期的に監査を行ってプロセスがきちんと守られていることを確認します。
この方法には限界もあります。ベンダーが 1 日か 2 日に 1 回継続的にアクセスする必要がある場合、週に数回アカウントを無効にして再び有効にすることになりますが、その労力に見合うだけの価値はないかもしれません。このような状況では、代わりに他の推奨事項を検討してみてください。
ロギングを検証し、セキュリティのモニタリングを実施する
VCA で何が行われているかをすべて可視化できるように、VCA を中心にロギング構成を評価します。アラートを作成しておけば、VCA の不審なアクティビティや異常なアクティビティを特定できます。VCA がアクセスしてはいけないシステムにアクセスしたら、そのことをすぐに把握できるようにしておくのです。
最小権限アクセスを適用する
効果的なアクセス制御は企業環境の共通の課題であり、VCA も例外ではありません。この概念を物理的なセキュリティの文脈で考えてみましょう。高度なセキュリティが施された施設に空調設備業者が入ってメンテナンスを行う場合、あちこち歩き回って窓から室内を覗いたり、ドアノブをガチャガチャ回したりする行為は禁止されています。決められた部屋に直接入ってメンテナンスすることはできますが、それ以外のことは何もできません。これと同じ制限を VCA にも適用するのです。ネットワーク層やアプリケーション層で VCA がアクセスできる対象を制限します。特定のアプリケーションや製品をサポートしている場合は、ベンダーが利用することが想定されるシステムとポートでのみ、そのアプリケーションや製品にアクセスできるようにします。
この概念をさらに一歩進めて、ネットワークとセキュリティのアーキテクチャを利用して VCA をできる限り分離します。VCA を分離すると、VCA 周りのセキュリティ対策を強化することができ、インシデント対応の際、より積極的な修復措置を効率よく実施することが可能になります。分離は、ネットワーク アクセス コントロール（NAC）、ネットワーク セグメンテーション、Active Directory グループなどで実現できますが、他にもさまざまな手段があります。ペネトレーションテスト（侵入テスト）とレッドチーム演習を使用すると、VCA がどこまでアクセスできるのかと、VCA が侵害されたらどれだけの影響が出るのかを的確に把握できます。
VCA をリモートアクセスのヘルスチェックの対象にする
ホストベースのさまざまな制御機能によってエンドユーザーのワークステーションの堅牢性を維持し、保護するのは非常に手間のかかる作業です。未承認、パッチ未適用、保護対策なしの個人デバイスをベンダーに使用させないようにしてください。解決までに時間とコストがかかるインシデントの原因になります。リモートデバイスについては、ヘルスチェックと信頼できるデバイス構成の両方またはそのいずれかを導入し、構成します。これには、統合オペレーティングシステム機能やサードパーティのツールを利用できます。これは会社で働くすべての人に適用できる優れたプラクティスですが、特に会社所有のアセットを使用するとは限らないベンダーに適しています。自社のセキュリティとコンプライアンスに関するドキュメントをベンダーに共有してもらい、そのベンダーのセキュリティプラクティスとベースラインを理解する際の参考にします。組織の安全性は、組織のリソースにアクセスするシステムの中で最も保護されていないシステムの安全性と同程度にしかなりません。
ジャンプボックスか専用のベンダー アクセス アプリケーションを使用する
さまざまな方法でベンダーセキュリティ要件を達成できますが、中でも特に優れているのがジャンプボックスや専用のベンダー アクセス アプリケーションを利用して単一のエントリポイントを作成することです。この方法では、単一の専門のシステム（またはシステムグループ）から複数のセキュリティ機能を実装できます。たとえばベンダー アクセス アプリケーションは、ベンダーが業務を行うのに必要なシステムへのアクセスを許可し、それ以上のアクセスは許可しないようにすることができます。システムに接続している間にベンダーが行ったアクティビティを適切にロギングし、モニタリングすることも可能です。また、システムヘルスチェック機能を提供できるほか、アプリケーションによっては、VCA を使用して組織の環境との間で送受信するファイルのプロキシ実行やサンドボックス分析をある程度実現することも可能です。
攻撃者は今後も VCA の悪用を続けるでしょう。すでに確立された効果的な方法であり、他の管理者アカウントに紛れ込むことのできるアカウントを使用して特権アクセスを取得することができます。この記事をお読みになって、お客様から VCA を付与されていることに気がついた方は、ぜひこのことをお客様に伝えてください。サプライチェーン攻撃を受ける前にお客様が準備と保護を完了できるようにすることが、お客様に提供できる最大の付加価値かもしれません。
本稿は 2023 年 06 月 06 日に Talos Group
Tags:
