クラウドを渡る技術: クラウド環境のラテラルムーブ術

This post is also available in: English (英語)

概要

本稿では、クラウド環境の野生の攻撃で見られた複数のラテラルムーブ技術を取り上げつつ、それらをレビューしていきます。ラテラルムーブはクラウド API とコンピュート インスタンスへのアクセスの両者を活用することで実現できます。クラウドレベルのアクセスがあれば、その影響はコンピュート インスタンスへと及ぶことがあります。

今回私たちは、3 つの主要クラウド プロバイダーすべてにおけるクラウド ラテラルムーブ技術を探究します。すなわち、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure という 3 つのサービスについて、オンプレミス環境における同様の技術との違いを明らかにします。

攻撃者はしばしば、多種多様なラテラルムーブ技術を駆使して組織ネットワーク内の機微データにアクセスします。ラテラルムーブ技術がオンプレミス環境に対する攻撃者のアプローチの一角をなしていることは間違いないので、私たちが本稿で議論するシナリオの多くはオンプレミス環境における状況と似たものとなる可能性があります。そこで本稿は、防御側のクラウド セキュリティ態勢改善に向け、とくにクラウド環境での利用が観測されているラテラルムーブ技術を中心に取り上げます。

クラウド環境において攻撃者は、「ホスト/インスタンス」レベルと「クラウド インフラ」レベルという 2 つのレベルで活動しています。このアプローチにより、攻撃者は従来のラテラルムーブ技術とクラウドに特化したそれとをシームレスに組み合わせることができます。

クラウド サービス プロバイダーらは、ラテラルムーブを制限するためのネットワーク セグメンテーションや、きめ細かい IAM 管理といった手段のほか、ラテラルムーブ検出のための集中型ログ機能も提供しています。それでもまだクラウド API には攻撃者が悪用可能なメカニズムが残されていますし、構成ミスがあれば、悪質な行為がさらに行われる可能性があります。

本稿では、エージェント型ソリューションとエージェントレス型ソリューションがどのように連携しあってラテラルムーブからの保護を提供し、それぞれに独自の強みを発揮するのかについて解説します。この解説は、セキュリティ担当者の皆さんが、両ソリューションの組み合わせがクラウドにおける包括的カバレッジを確保してくれる理由を理解するうえで役に立つことでしょう。

Cortex XDR と Prisma Cloud は、本稿で説明するラテラルムーブ技術からの保護を提供します。侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、こちらのフォームからご連絡いただくか、infojapan@paloaltonetworks.com までメールにてお問い合わせください (ご相談は弊社製品のお客様には限定されません)。

はじめに

クラウドやオンプレミスにおけるラテラルムーブを調べてみると、両者の顕著な違いが明らかになります。いずれの環境もそれぞれに防御側にとっての課題をもたらしますが、クラウド環境の場合、過度に寛容なアクセス ポリシーやリソースの構成ミスは、脅威アクターによるクラウド機能悪用の機会を広げるおそれがあります。

こうした機会は多様なラテラルムーブ技術を招きます。そうした技術とクラウド内の強力な API アクセスと組み合わせれば、環境内で実行されているコンピュート インスタンスにすらアクセスを許しかねません。

クラウド サービスにおいてAPI は、コミュニケーション上だけでなくラテラルムーブを容易にする上でも極めて重要な役割を果たしています。攻撃者が適切なクラウド権限 (通常は書き込みアクセス) を備えていれば、API 呼び出しを実行することで、クラウド サービスと直接対話できるようになります。そうした場合、クラウド内でのアクセスとコンピュート インスタンスへのアクセスとを隔てる防壁はいささか頼りないものとなります。攻撃者がそこにつけいれば、クラウド リソースを作成したり、変更したり、ラテラルムーブを効率よく行ったりできるようになります。

オンデマンドでリソースをプロビジョニングさせてくれるクラウド環境のスケーラビリティは、こうしたプロセスを簡素化してくれます。こうした環境では、攻撃者は新しいコンピュート インスタンスを簡単に作成し、オペレーションを拡張し、既存コンピュート インスタンスを制御できるのです。

クラウドにおけるラテラルムーブ技術

技術 1: スナップショットの作成

AWS: Elastic Block Store (EBS)

ある事例では、攻撃者がクラウド環境へのアクセスを取得し、Amazon Elastic Compute Cloud (EC2) インスタンス間をピボットしようとしていました。この攻撃者はまず、従来のラテラルムーブ技術 (デフォルトのオープン ポートの悪用や既存の SSH キーの悪用など) を使って EC2 インスタンスにアクセスしようとしました。

これらの方法でうまくいかないことがわかると、次はクラウド特有のラテラルムーブ技術の利用に移りました。この攻撃者は比較的強力な IAM 認証情報をもっていたので、べつのアプローチでインスタンス内のデータにアクセスできました。

このアプローチでは、ターゲット インスタンス上に存在するランタイム環境 (メモリー内のデータや、当該インスタンスのクラウド メタデータ サービス内で利用可能な IAM 認証情報などのデータを含む) へのアクセスは許可されません。ただし、ターゲット インスタンスのディスクに保存されているデータへのアクセスは許可されます。

攻撃者はまず、自身の SSH キーのセットを使って新しい EC2 インスタンスを作成しました。その後、ターゲットの EC2 インスタンスの EBS スナップショットを CreateSnapshot API を使って作成しました。次にそれを自身の制御下にある EC2 インスタンスにマウントしました (図 1)。

このクラウド環境では、対話的にアクセスできないホストへのアクセスを部分的に代替するために、ホストの仮想ブロック デバイスに保存されているデータに対するアクセスが可能でした。これは、侵害された IAM 認証情報のもつ比較的強力な権限と、クラウド プロバイダーの API とを使って実現されていました。

その後、自身の EC2 インスタンスにマウントした EBS スナップショットを使い、この攻撃者はターゲット EC2 インスタンスのディスクに保存されているデータへのアクセスに成功しました。図 2 は、このイベント チェーンを示したものです。

この技術は AWS に限ったものではなく、ほかのクラウド サービス プロバイダーに対しても有効です。

技術 2: SSH キー

AWS: EC2 Instance Connect

またべつのシナリオでは、侵害された ID およびアクセス管理 (IAM) 認証情報を持つ攻撃者が、AuthorizeSecurityGroupIngress API を使ってセキュリティ グループにインバウンドの SSH ルールを追加していました。その結果、これまでセキュリティ グループによってインターネット アクセスから保護されていたインスタンスが、攻撃者が制御する IP アドレスなどからアクセスできるようになりました。

セキュリティ グループのルールを変更することで、古典的なネットワーク ラテラルムーブが可能になります。これは、オンプレミス環境と比べたクラウドのネットワーク リソース設定の容易さを示すものでした。この後、手に入れた強力な IAM 権限によって、攻撃者は EC2 Instance Connect サービス (これがマシン上の SSH キーを管理している) を使えるようになりました。図 3 に示すように、SendSSHPublicKey API を使って一時的に公開 SSH キーをプッシュすることができたのです。

これにより、攻撃者に対し、EC2 インスタンスへの接続と、当該インスタンス上のデータへのアクセスが許可されました。これは、オペレーティング システムがもともと備えている認証・認可テクノロジーと並び、クラウド サービス プロバイダーも独自にコンピュート インスタンスへのアクセス メカニズムを備えていることを示したよい例です。ただし、通常はこれら 2 つのテクノロジーはつながっています。

クラウドとクラウド内で実行されているコンピュート インスタンスの間には防壁が設けられていますが、こうした防壁はデザイン上透過性があり、異なる認証・認可システム間での行き来を可能にしています。これは、強力な IAM 認証情報があれば、どのようにしてコンピュート インスタンス (コンテナーや RDS データベースなど) へのアクセスを許可しうるのかを示したよい例といえます。クラウドネイティブではないテクノロジーが、クラウドの外側で独立して動く独自の認証方式を備えている場合でも、攻撃者は自身にアクセスを許可させることができます。

当該 EC2 インスタンス内でこの攻撃者は、ディスクに平文で保存されていた認証情報 (なんと秘密 SSH キーと AWS アクセス トークン) を追加で発見しました。これらのアクセス認証情報を使って、攻撃者は追加の EC2 インスタンスへとピボットしました。

ラテラルムーブに SSH とクラウド トークンを使うことは、攻撃者が従来のラテラルムーブ技術とクラウドのラテラルムーブ技術の両方を組み合わせて使っていることを示しています。結局攻撃者はこれらの認証情報を利用してほかの開発環境へとピボットしていました。図 4 はこのイベント チェーンのフローチャートです。

GCP: メタデータベースの SSH キー

構成ミスによる同等のラテラルムーブ技術は GCP にも存在します。Compute Engine インスタンスは、OS Login サービスが使われていない限り、インスタンスのメタデータに SSH キーを保存するように設定できます。

これらの SSH キーはインスタンスのメタデータに保存されていることから、個々のインスタンスへのアクセスが容易になります。ただしインスタンスの SSH キーはプロジェクトのメタデータにも保存できます。つまりこれらのキーはプロジェクト内のすべてのインスタンスへのアクセスを許可することになります。

これは、インスタンスがプロジェクト全体にわたる SSH キーを制限していない限り機能します。以下の図 5 に示すように、公開 SSH キーは Google Cloud CLI を使ってインスタンスのメタデータにアペンドできます。

同様に、特権昇格によって公開 SSH キーをプロジェクト メタデータに追加することもできます。これにより、十分に強力なクラウド認証情報を持つ攻撃者は、図 6 に示すコマンドを使い、その特定プロジェクト内の全インスタンスにアクセスできるようになります。

仮想プライベート クラウド ネットワークのセキュリティ設定により、SSH キーの構成ミスを防げます。

Azure: VMAccess 拡張機能

もうひとつの注目すべきラテラルムーブ技術は、Azure での VMAccess 拡張機能の悪用です。VMAccess 拡張機能は仮想マシン (VM) へのアクセスをリセットするために使われますが、Linux VM の機能にはユーザー用 SSH 公開キーの更新が含まれています。

十分に強力なクラウド認証情報を持つ攻撃者は、この拡張機能を使って、指定された VM 内の特定ユーザー用 SSH キーをリセットすることにより、VM にアクセスできるようになります。これは、図 7 に示すコマンドを使って Azure CLI で実行されます。

この技術をさらに拡張し、図 8 に示すコマンドを使って、同一リソース グループ内の複数の VM にわたって特定ユーザーを侵害することもできます。

技術 3: シリアル コンソール アクセス

AWS: シリアル コンソール アクセス

私たちが観測したもうひとつの技術には、シリアル コンソールのアクセスが使われています。シリアル コンソールは 3 つの主要なクラウド プロバイダーすべてに存在していて、通常はインスタンス上で対話型シェルを提供します。これはネットワーク機能がない場合のトラブルシューティング ツールとして機能します。

EC2 Instance Connect での技術とは対照的に、このアプローチにはより大きな制限をともないます。ユーザー パスワードや SysRq などの追加機能を、対象インスタンスのオペレーティング システムに事前に設定しておく必要があるのです。

ここでの場合、ある攻撃者が SSH の代わりにシリアル コンソールを選択していました。シリアル コンソールなら、インスタンスに設定されたセキュリティ グループ ルールをバイパスできるからです。ある事例では、攻撃者が EC2 Instance Connect サービスを再度利用し、SendSerialConsoleSSHPublicKey API を使って、公開 SSH キーを一時的にプッシュしていました。図 9 に示すコマンドを参照してください。

ただし今回のこの行為は、攻撃者が EC2 インスタンスへのシリアル コンソール接続を確立し、ファイル システムにアクセスし、インスタンス内でシェル コマンドを実行できるようにするものです。

GCP: SSH キー認証

GCP の場合、シリアル コンソールが SSH キー認証に依存しているので、対象のプロジェクトまたはインスタンス メタデータに公開 SSH キーを追加する必要があります。十分なクラウド API 権限を持つ攻撃者であれば、図 10 の次のコマンドにより、Google Cloud CLI で Compute Engine インスタンスへのシリアル コンソール接続を確立することがありえます。

Azure: VMAccess 拡張機能

Azure の場合、この技術にはいくつか制限があります。十分なクラウド API 権限を持つ攻撃者であれば、VMAccess 拡張機能を使って、パスワードを指定した新しいローカル ユーザーを作成するか、既存のローカル ユーザーのパスワードをリセットすることができます。次に、攻撃者は Azure CLI のコマンドを使って、VM へのシリアル コンソール接続を開始します (図 11 参照)。

技術 4: 管理サービス

AWS: Systems Manager

べつのユース ケースでは、Systems Manager サービスに対する IAM 権限を持つ攻撃者が、当該サービスの管理するインスタンスを標的にしていました。この事例で攻撃者は、StartSession API を使って各インスタンス上で対話型シェルのセッションを開始していました。これにあたっては、図 12 に示すコマンドが使われていました。

この方法では、対象 EC2 インスタンスの対応するセキュリティ グループに SSH インバウンド ルールが必要ないので、セキュリティ グループ ルールが事実上バイパスされることに注意してください。

この攻撃者はまた、SendCommand API を使って多数のマネージド インスタンスに対してスクリプトを同時に実行することにより、とくに認証情報ファイルを標的とする大規模な情報収集を可能にしていました。これを行うコマンドを図 13 に示します。

以下の図 14 は、この攻撃イベント チェーンを図解したフローチャートです。

エージェントとエージェントレス: 一緒でよりよく

クラウドの性質を考慮すると、攻撃者の技術は「ホスト」と「クラウド」の 2 層に分類できます。ホスト層にはクラウド インスタンス内で実行されるすべてのアクションが含まれ、クラウド層にはクラウド環境内で行われるすべての API 呼び出しが含まれます。私たちが観測した各技術では、攻撃者はクラウド API とホストレベルでの操作の両方を利用して、クラウド−インスタンス間をシームレスに行き来していました。

マネージド コンピュート インスタンスで通常使われている認証・認可技術がどんなものであれ、防御側は、これらがさほど強力な防壁にはならないことを想定しておく必要があります。攻撃者が強力なクラウド認証情報を持っていれば、クラウド環境内のコンピュート インスタンスにアクセスする術は残されているからです。

本稿に述べたアクティビティを検出するには、エージェント型ソリューションとエージェントレス型ソリューションの両方からデータを得てそれらを相関させ、クラウド環境を包括的に可視化する必要があります。

ホストにアクセスできる攻撃者は、多くの場合、ホスト上で実行されているローカル セキュリティの制御やセキュリティ エージェントの無効化に足る権限を持っています。したがって、ホストからの関連ログ ストリームが停止した場合は、侵害の可能性を示す兆候として注意を払うことが重要です。

攻撃者が EC2 Instance Connect サービスを悪用して EC2 インスタンスにアクセスする、ラテラルムーブ技術 2 を見てみましょう。エージェントレス型ソリューションは、実行されたすべてのクラウドレベルの API 呼び出しを可視化することにより、攻撃者のアクセス方法に関する洞察を提供します。たとえば、セキュリティ グループの変更や、SSH キーのインジェクションなどのアクションが、その一例です。AWS パネルでのこれに関するアラートを以下の図 15 に示します。

図 16 に示した Prisma Cloud Resource Query Language (RQL) クエリーも、悪意のあるアクターが行った疑わしい SSH 操作の特定に使えます。

同時に、ホストレベルの可視性を提供する Cortex XDR エージェントが EC2 インスタンスにインストールされていれば、攻撃者が認証情報や機微ファイルを検索しようとしていることが明らかになります。この可視性は、攻撃者がどのようにラテラルムーブを実行し、ほかの環境にピボットしたかを理解する上で重要であることがわかっています。

エージェント型ソリューションとエージェントレス型ソリューションの両方を使うと、クラウド環境の保護効果が高まります。エージェント型は特定インスタンスの完全な可視化と制御に優れたソリューションですが、攻撃者によって無効にされうる点に注意が必要です。

一方、エージェントレス型ソリューションはクラウドレベルの可視性を提供します。加えて、適切に構成されたクラウド ロギング環境は攻撃者が簡単に変更したり無効化したりできないことから、防御側にとって最重要の最終防衛ラインとなります。クラウド環境保護の観点からは、両ソリューションの組み合わせで両方の長所を得られることになります。

結論

クラウド API レベルの十分な権限を持つ攻撃者は、クラウド API を使用したラテラルムーブにクラウド環境の特性を利用することができます。多くの場合、クラウド API を使えば、一般的なオンプレミス環境での従来のラテラルムーブと比べ、わりあい容易にコンピュート インスタンスをピボットすることができます。ただし、オンプレミス環境にもこの種のリスクはつきまといます。たとえば、仮想化レイヤーへのアクセスと同等の権限を攻撃者が仮想化環境に対して持っているような場合です。

本稿で説明したシナリオのなかには、クラウド サービス プロバイダーなどが提供する検出や修復を利用できるものもあります。防御側は、どんなオプションをクラウド セキュリティ態勢の改善に使えるのかを認識しておく必要があります。 

構成ミスやそれに類する問題により、組織のクラウド セキュリティが弱まることはよくあります。このため、防御側はクラウド サービス プロバイダーが推奨するベスト プラクティスに従うとともに、セキュリティ上の必要性と構成とが一致していることの確認に、とくに注意せねばなりません。

エージェント型ソリューションとエージェントレス型ソリューションの両方を採用する方法は、従来型技術とクラウドベース技術とを組み合わせてラテラルムーブをしかける攻撃者のハイブリッド戦術検出に有効です。本稿で説明したクラウド ラテラルムーブ技術は、クラウド環境特有の課題に効果的に対処する包括的セキュリティ アプローチを持つことの重要性を物語っています。

パロアルトネットワークスのお客様は、以下の製品を通じて、これらの攻撃からさらに強力に保護されています。

Cortex XDR

Cortex XDR はクラウド ホスト、クラウド トラフィック、監査ログからのアクティビティの内容と、エンドポイントやネットワークのデータとを統合します。この統合により SOC チームはデジタル ドメイン全体を俯瞰したインシデントのストーリーを得ることができます。XDR はこれらすべてのデータセットを使って、クラウド コンピュートのクレデンシャル窃取、クリプトジャック、データ漏えいなど、既知の TTP (戦術・技術・手順) と相関する異常なクラウド アクティビティを検出します。

Prisma Cloud

Prisma Cloud は、DevOps チームと SOC チームに対し、組織クラウドまたはハイブリッド クラウドのリソース/インフラ全体を俯瞰し、脆弱性や構成、イベント操作を監視する機能を提供します。Prisma Cloud Defender エージェントは、以下の脆弱性、構成ミス、不審なランタイム イベントからの保護と監視を提供します。

• クラウドの Web アプリ
• VM のランタイム イベント
• サーバーレス関数
• ストレージ コンテナーのリソース

これにより、組織は継続的な状況認識と DevOps 実践の改善によって、安全なクラウド環境を維持できるようになります。

侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、こちらのフォームからご連絡いただくか、infojapan@paloaltonetworks.comまでメールにてご連絡いただくか、下記の電話番号までお問い合わせください(ご相談は弊社製品のお客様には限定されません)。

• 北米フリーダイヤル: 866.486.4842 (866.4.UNIT42)
• EMEA: +31.20.299.3130
• APAC: +65.6983.8730
• 日本: (+81) 50-1790-0200

パロアルトネットワークスは、これらの調査結果を Cyber Threat Alliance (CTA: サイバー脅威アライアンス) のメンバーと共有しました。CTA のメンバーはこのインテリジェンスを使って、お客様に保護を迅速に提供し、悪意のあるサイバー攻撃者を体系的に阻害できます。詳細は Cyber Threat Alliance にてご確認ください｡

Google Cloud は、本稿で解説したラテラルムーブ機会からの保護のため、クラウド システムを適切に構成する方法についてガイダンスを提供しています。