空での検出:ビッグスリーのクラウドセキュリティを強化するためのシグマルール
編集者注:以下の記事は、レポート全文の抜粋です。 分析の全文を読むには、 ここをクリックして レポートをPDFとしてダウンロードしてください。
このレポートでは、Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform(GCP)の3つの主要なクラウドプロバイダーを攻撃するために使用されたツールの概要を示します。 これらの攻撃ツールの機能の詳細が含まれており、これらのクラウドプロバイダーに対する疑わしい動作や悪意のある動作の検出を提供します。 このレポートは、検出エンジニアリングに重点を置くセキュリティ運用の読者を対象としています。 出典には、Recorded Future® Platformとオープンソースの研究が含まれます。
Executive Summary
多くの組織は、データ、リソース、サービスをクラウドに移行しています。 クラウドは、組織にサービスを拡張し、組織のオンプレミス リソースでは実現できない機能を提供する機能を提供します。 クラウドサービスの利用が増加するにつれて、組織がクラウド環境を適切に保護および監視する必要性がますます重要になります。 クラウドインフラストラクチャに対する攻撃は、オンプレミスのインフラストラクチャと比較して、検出に独自のアプローチを必要とします。 その結果、クラウドインフラストラクチャのセキュリティのベストプラクティスは、従来のインフラストラクチャに適用できる他のベストプラクティスとは異なります。
Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform(GCP)のビッグスリープラットフォームはすべて、セキュリティ制御が組み込まれており、ロギング機能を提供していますが、クラウド環境の脅威の検出と対応にはまだ曖昧さがあります。 私たちの研究では、アーティファクトの削除、コマンドの実行、クラウド環境の列挙など、ビッグスリープラットフォームに対して実行できるさまざまなタイプの攻撃と、研究の一環としてエミュレートした攻撃のサブセットを検出するためのシグマルールについて詳しく説明します。
主な判断
- ビッグスリープラットフォームは、ログを収集、集約、および関連付けるためのインフラストラクチャと組み合わせると、ほとんどの悪意のあるアクティビティを検出するロギング機能を提供します。
- AWSやAzureを攻撃するために開発されたツールは、GCPを標的としたツールに比べて洗練されています。
- クラウドインフラストラクチャに対する攻撃の検出エンジニアリングは、クラウドの分散型で一時的な性質、クラウドインフラストラクチャから実行できる多くの異なるワークロード、およびクラウドプロバイダー間の違いにより複雑です。
- クラウド サービス プロバイダーを標的とした攻撃を検出する機会は、クラウド プロバイダーと、Azure と GCP の両方のホスト型仮想マシンの両方に存在します。
背景
クラウドワークロード
組織がクラウドリソースを使用する方法は、クラウドワークロードと呼ばれます。 Dellは、クラウド ワークロードを「クラウド リソースで実行できる特定のアプリケーション、サービス、機能、または特定の量の作業」 と定義 しています。 これらのワークロードは、クラウド関連の侵入による潜在的なターゲットであるか、またはリスクにさらされています。
Gartner は 、クラウドに移行すべき上位 7 つのワークロードを次のように述べています。
- モバイルデバイスとアプリケーションのサポート
- コラボレーションとコンテンツ管理
- ビデオ会議
- 仮想デスクトップとリモートワークステーション管理
- スケールアウト アプリケーション
- ディザスタリカバリ
- ビジネス継続性ソリューション
ビッグスリー
この調査の焦点として、クラウドのIaaS(Infrastructure-as-a-Service)の上位3 つのプロバイダー 、Amazon Web Services(AWS)、Azure、Google Cloud Platform(GCP)を選択しました。 これらのプラットフォームを合わせると、2022年第1四半期の世界のクラウドIaaS市場の62%以上 を占め ており、AWSは市場シェアの33%、Azureは21%、GCPは8%となっています。
3つのプラットフォームはすべて同様のサービスを提供しています。ただし、 BMCによる最近のブログでは、AWSとAzureはどちらも約200 +サービスを提供し、GCPは100 +を提供しています。 BMCは、各プラットフォームが提供する一般的なサービスについても概説しています。以下は彼らの研究の要約です。
- コンピューティング サービス (VM、サービスとしてのプラットフォーム、コンテナー、サーバーレス機能)
- データベースおよびストレージサービス(リレーショナルデータベース管理、NoSQL、オブジェクトストレージ、ファイルストレージ、アーカイブストレージ、データウェアハウス/データレイク)
- ネットワーク (仮想ネットワーク、負荷分散、ファイアウォール、DNS、コンテンツ配信)
BMCはまた、ロボティクス、エンドユーザーコンピューティング、ゲーム開発、仮想現実、IoTなどのより専門的なサービスの一部について、AzureとAWSの両方がGCPと比較してより多くのサービスを提供すると述べています。
結局のところ、どのビッグスリープラットフォームを使用するかの選択は、組織が解決しようとしている特定のユースケースにより大きく依存します。
ビッグスリーの脅威分析
クラウドインフラストラクチャの保護は、本質的に、第3回Annual National Cybersecurity Summit(2020年)でSounil Yu氏によって最初に紹介されたセキュリティモデルに従っており、 DIEトライアドとして知られています。 DIEトライアドは、よく知られているCIAトライアド(機密性、完全性、可用性)の適応バージョンですが、組織のリソースまたはデータが存在するインフラストラクチャに重点を置いています。 Copadoは、DIEトライアドについて 次の 定義も提供しています。
- 分散型:システムは、1つのゾーンへの依存を防ぎながらスケーラビリティを確保できるように分散されていますか?
- 不変:インフラストラクチャは、問題が発生した場合に廃棄して交換できますか(infrastructure-as-code)。
- エフェメラル:システムの再プロビジョニングの期間はどのくらいですか、また、侵害が発生した場合に資産は使い捨てですか?
クラウド インフラストラクチャに対する脅威モデリング攻撃は、クラウドの分散型で一時的な性質と、クラウド インフラストラクチャから実行できるワークロードの多様性により、ますます複雑になっています。 そのため、クラウドインフラストラクチャは組織によって異なり、ある組織のクラウドインフラストラクチャに直接影響を与える可能性のある脅威が、別の組織のクラウドインフラストラクチャに直接影響しない場合もあります。 これらの違いは、クラウド環境の多様な性質を示し、クラウド環境の統一されたセキュリティ モデルの作成に関連する課題を説明するのに役立ちます。
Recorded Future Platform と OSINT の調査を使用して、これらの各プラットフォームに影響を与えるサイバー脅威を特定したところ、Amazon AWS インスタンスに最も大きなリスクをもたらすのは設定ミスであり、次いで認証情報の盗難が脅威アクターの初期アクセスを可能にすることがわかりました。 侵害につながる最も一般的な設定ミスは、環境をパブリックにアクセスできるようにするクラウドサービスの設定に起因します。 しかし、Microsoft Azureは、さまざまなサイバーセキュリティの脅威の影響を受けており、設定ミスは大きな部分を占めていませんでした。 最後に、Google Cloud プロダクトが標的にされたサイバー インシデントは 1 件のみで、設定ミスの問題に関連して言及されることはほとんどありませんでした。
クラウドインフラストラクチャセキュリティのベストプラクティスの実装において組織を導くために、組織が利用できる多くのリソースがあります。 このようなリソースは、個々の組織の状況への適用性について検討する必要がありますが、一般的なものには、 Cloud Security Alliance、米国 国立標準技術研究所、および米国 サイバーセキュリティおよびインフラストラクチャセキュリティ庁のリソースが含まれます。
この調査では、ビッグスリープラットフォームを攻撃するために使用される一般的なツールとフレームワークを特定し、それらのツールをテスト環境に対して使用しました。 以下の図1は、クラウド検出の手法を示しています。 大まかに言うと、私たちの方法論は、作成したクラウドプロバイダーのテスト環境に対してこれらの悪意のあるツールを実行することで構成されていました。クラウドプロバイダーのログを分析して、これらのツールの使用を示すアーティファクトを探し、可能な場合はそれらに基づいてSigmaルールを作成しました。
図 1: Insikt Groupのクラウド検出エンジニアリング手法(出典:Recorded Future)
AWS 脅威分析
攻撃対象領域
AWS環境は、非常に異なる動機と攻撃手法を持つあらゆる種類の脅威アクターによって一般的に標的にされています。 AWS環境に影響を与える一般的な攻撃をエミュレートしたり、脅威アクターによって実装される可能性のある攻撃戦略を実証したりするために使用できるツールは無数にあります。 これらのツールの中から、潜在的な攻撃の種類の最新性と幅広さに焦点を当てて選択し、AWSのロギングサービスであるCloudTrailのログデータを生成するために使用しました。 このデータを使用して、表示された動作の Sigma 検出を作成し、防御者や脅威研究者が AWS 環境での悪意のある可能性のあるアクティビティとこれらのツールの使用をより適切に特定できるようにしました。
CloudTrail ログデータの生成に使用したツールについて、以下で説明します。
ストラタスレッドチーム
Stratus Red-Teamは、クラウドベースのロギング、モニタリング、セキュリティプラットフォームの生みの親であるDataDogが作成したペネトレーションテスト ツールです 。 Stratusは、Red Canaryの Atomic Red Team ペネトレーションテストスイートをベースにしています。ただし、Stratusはクラウド環境に焦点を当てていますが、Atomic Red TeamはWindows、Linux、MacOSのオペレーティングシステムとネットワークをターゲットにするために使用されます。
Stratusには、図2に示すように、30以上の事前に記述された攻撃手法が含まれています。これらの手法のうち 7 つを除くすべての手法は、AWS 環境に対してさまざまな攻撃を実行するために使用されます。 これらの攻撃は、クレデンシャルアクセス、防御回避、ディスカバリー、実行、権限昇格、流出、初期アクセス、永続化のATT&CK戦術など、多岐にわたります。
パク
Pacu は、事前に作成されたモジュールを使用して AWS クラウド プラットフォームに対する攻撃手法を実行することに焦点を当てた、オープンソースのエクスプロイト フレームワークです。 このツールは、AWS環境内の脆弱性や設定ミスを特定するためのレッドチーム化に使用することを目的としています。 現在、偵察、ディスカバリー(列挙)、特権昇格、ラテラルムーブメント、パーシステンス、エクスクルート、防御回避などの戦術を実行する42のモジュールがあります。 Pacu には、ユーザーが次のようなアクションを実行できるようにするエクスプロイト固有のモジュールのリストも含まれています。
- ターゲット環境での ID およびアクセス管理 (IAM) キーの自動作成
- Lightsail SSH キーの検出、SSH キーの生成、一時的なアクセス許可
- EC2 インスタンスでの SYSTEM/root としてのリモートコード実行
シグマ ルール検出
AWS Sigma ルール: Stratus アクティビティ検出
このルールは、Stratus がモジュールを実行するたびに user-agent に含まれる文字列 stratus-red-team を検出します。 Stratusは主にレッドチーム化の目的で悪意のある活動を示すために使用されますが、脅威アクターがStratusのモジュールを変更してツールを武器化する可能性があります。 ストラタスが攻撃の実行とターゲット環境の初期化をTerraform Infrastructure-as-Code(IaC)ツールに依存しているため、脅威アクターはユーザーエージェントを変更せずに放置し、ユーザーエージェントに は引き続きstratus-red-teamが含まれる可能性があります。
AWS Sigma ルール: ポート 22 イングレス
Stratusモジュール aws.exfiltration.ec2-security-group-open-port-22-ingress ユーザーは、ポート 22 経由での環境へのインバウンド アクセスを許可するセキュリティ グループを作成できます。 このセキュリティグループを作成することで、脅威アクターは被害者の環境内でツールをドロップしたり、C2コマンドを提供したりするルートを持つことになります。 ポート 22 のイングレスを許可する一般的なアクティビティは、イベント名 AuthorizeSecurityGroupIngress のイベントと、要求パラメーター toPort に文字列 22 が含まれているイベントを識別することで検出できます。
AWS Sigma ルール: CloudTrail 証跡の削除
Stratusモジュール aws.defense-evasion.cloudtrail-delete ユーザーは CloudTrail 証跡を作成して、AWS 環境からログ記録データを削除できます。 この手法は、 DeleteTrail というイベント名でイベントを識別するだけで検出できますが、これらのイベントを精査して、削除が正当に実行されていないことを確認する必要があります。
編集者注:この記事はレポート全文の抜粋です。 分析の全文を読むには、 ここをクリックして レポートをPDFとしてダウンロードしてください。
関連