banner
ホームページ / ニュース / 攻撃者は AWS SSM エージェントをリモート アクセス トロイの木馬に変える可能性がある
ニュース

攻撃者は AWS SSM エージェントをリモート アクセス トロイの木馬に変える可能性がある

Feb 16, 2024Feb 16, 2024

Mitiga の研究者は、攻撃者が AWS Elastic Compute Cloud (EC2) インスタンス (仮想サーバー) および非 EC2 マシン (例: オンプレミスのエンタープライズ サーバーや仮想サーバー) への永続的なリモート アクセスを取得するために使用できる、エクスプロイト後の新しい手法を文書化しました。マシン、および他のクラウド環境の VM)。

この「土地を離れて生きる」手法が成功するかどうかは、次の点にかかっています。

「SSM エージェントを制御した後、攻撃者は、データの盗難、(ランサムウェアとしての)ファイルシステムの暗号化、暗号通貨マイニングのためのエンドポイント リソースの悪用、ネットワーク内の他のエンドポイントへの伝播の試みなどの悪意のある活動を実行できます。これらはすべて装いの下で行われます。」正規のソフトウェアである SSM Agent を使用していることを意味します」と Mitiga 研究者の Ariel Szarf 氏と Or Aspir 氏は説明しました。

研究者らは 2 つの異なるシナリオを試しましたが、両方に必要なアクセス レベルは高かったです。 最初のシナリオでは、攻撃者はターゲットの Linux マシンで root アクセス権、またはターゲットの Windows システムで管理者権限を必要としますが、2 番目のシナリオでは、ターゲットの Linux マシンで少なくとも非 root 特権ユーザーとして、またはターゲットの Windows システムで管理者として実行できる必要があります。対象となる Windows システム。

「[最初のシナリオでは]、攻撃は、SSM エージェントを別の AWS アカウントで「ハイブリッド」モードで動作するように登録することで、元の SSM エージェント プロセスを「ハイジャック」し、ID 消費用のメタデータ サーバーを選択しないように強制します。 その後、SSM エージェントが攻撃者の所有する AWS アカウントと通信し、コマンドを実行します」と彼らは説明しました。

2 番目のシナリオでは、攻撃者は Linux 名前空間を使用するか、Windows 上で特定の環境変数を設定することにより、別の SSM エージェント プロセスを実行します。 「悪意のあるエージェントのプロセスは攻撃者の AWS アカウントと通信し、元の SSM エージェントは元の AWS アカウントとの通信を継続します。」

また、脅威攻撃者がエージェントの管理に AWS アカウントを使用したくない場合は、その必要はありません。SSM トラフィックを攻撃者が制御するサーバー (つまり、AWS のサーバーを経由しない) にルーティングするために悪用できる SSM 機能があります。 )。

SSM エージェントをリモート アクセス トロイの木馬に変えると、攻撃者はインストールされているセキュリティ ソリューションに発見されることなくエンドポイントを侵害できるようになります。 C&C 通信は正当であるように見え、別の攻撃インフラストラクチャを開発する必要はなく、SSM エージェントを使用して、サポートされている機能を通じてエンドポイントを操作できます。

SSM エージェントが一部の人気のある Amazon マシン イメージにプレインストールされており、多くの既存の EC2 インスタンスにすでにインストールされて実行されているという事実により、攻撃者の潜在的なターゲットのプールが拡大していると研究者らは指摘しました。

幸いなことに、この手法の使用を検出する方法があり、新しいインスタンス ID、特定のコマンドの使用、AWS アカウントの SSM エージェントへの接続の切断、新しいプロセス、およびセッション マネージャーに関連する不審なアクションに注意を払うことが含まれます。 Amazon CloudTrail ログ内。

研究者らは企業のシステム管理者に次のことをアドバイスしています。

「私たちは、脅威アクターがこれをまだ実行していなければ、現実世界の攻撃でこれを悪用すると強く信じています。 そのため、この進化する脅威からシステムを保護するには、その悪用に関連するリスクを理解し、軽減することが極めて重要です」と彼らは指摘し、AWS セキュリティ チームが元の AWS からのコマンドの受信を制限するソリューションも提供していると指摘しました。 Systems Manager の Virtual Private Cloud (VPC) エンドポイントを使用するアカウント/組織。

「EC2 インスタンスがプライベート サブネット内にあり、パブリック EIP アドレスまたは NAT ゲートウェイ経由でパブリック ネットワークにアクセスできない場合でも、VPC エンドポイントを通じて System Manager サービスを設定できます。 これにより、EC2 インスタンスが元の AWS アカウントまたは組織内のプリンシパルからのコマンドのみに応答するようにすることができます。 この制限を効果的に実装するには、VPC エンドポイント ポリシーのドキュメントを参照してください。