AWSDoor によるコンフィグ・ベースの永続化手法：AWS 環境内にマルウェアを隠蔽

AWSDoor – New Persistence Technique Allows Attackers to Hide Malware Within AWS Cloud Environment

2025/09/16 CyberSecurityNews — 攻撃者たちは、クラウド環境への長期的アクセスを維持するために、高度な手法を活用している。そして、新たに登場した AWSDoor という手口が、強大な脅威になり始めている。この悪意のツールは、IAM およびリソース・ベースの永続化手法を自動化し、従来からのマルウェアを配備することなく、AWS アカウント内に潜み続ける。

主なポイント

• AWSDoor は、アクセスキーを注入し、TrustPolicy にバックドアを仕掛けることで IAM を悪用する。
• Lambda レイヤーに不正アクセスすることで、リソース・ベースの永続化を悪用する。
• CloudTrail のログ記録を無効化し、S3 ライフサイクル・ルールを悪用してアカウントをデタッチする。

IAM ベースのバックドアと不正なポリシー

RiskInsight が報告したのは、AWSDoor が AWS Identity and Access Management (IAM) を悪用し、ステルス性の高いバックドアを作成することである。侵害された IAM ユーザーにアクセスキーを注入することで、それらの攻撃者は CLI の永続化を確保できる。

そして簡単な呼び出しにより、悪意の処理が実行される。

AWSDoor は新規の AccessKey ペアを生成し、攻撃者が管理する認証情報を正当なトラフィックに紛れ込ませる。さらに、検知回避のための、既存キーの列挙／未使用キーの無効化／証拠の消去などを可能にする。

前述の AccessKey 生成に加えて、AWSDoor は TrustPolicy ドキュメントを改変して IAM ロールにバックドアを仕掛ける。

続いて攻撃者は、ロールの信頼ポリシーを更新し、自身が管理する主体を取り込ませることで、永続的なクロス・アカウント AssumeRole 機能を確保する。

RiskInsight のレポートには、この新しいポリシーにより注入されるステートメントにより、外部アカウントからの “sts:AssumeRole” が許可され、CloudTrail の認証情報ログを回避する永続的なアクセスを付与すると記されている。

AWSDoor のリソース・ベース永続化モジュールは、AWS のサービス自体を悪用するものだ。たとえば AdminLambda モジュールは、過剰な権限を持つロール・アタッチメントを取り込んだ、悪意の Lambda 関数またはレイヤーを提供する。

上記の “-l” フラグにより AWSDoor は、正当な関数を上書きする不正ライブラリ (例：バックドア化された request.get) を取り込んだ Lambda レイヤーをデプロイし、その関数が実行されるたびに悪意のコードを実行する。

API Gateway／Function URL 経由などで公開される、このような Lambda はリモートシェルになる。この手法では、悪意のコードはメイン関数本体の外側に隠れるため、日常的なコンソール検査やインライン・コード・レビューを回避できる。

緩和策

セキュリティチームに推奨される緩和策は、IAM ポリシーの変更である。具体的には、CreateAccessKey／UpdateAssumeRolePolicy／PutRolePolicy などの CloudTrail イベントを継続的に監視することになる。また、AWS Config のカスタム・ルールを活用して、管理者権限に近い権限を付与する、不正な NotAction ステートメントを検知することも重要である。

さらに、Lambda レイヤーのアタッチメント (UpdateFunctionConfiguration) を監査し、外部からのアクセスが可能な関数 URL を検証する必要がある。それに加えて、CSPM およびクラウド EDR ソリューションを併用すれば、異常な IAM 変更や不審な実行時動作を検出できる。

AWSDoor が示す通り、攻撃者はコンフィグ・ベースの永続化手法へと移行しており、AWS 環境のセキュリティを維持するためには、綿密なポリシー監査とテレメトリの整合性が不可欠である。

AWS 環境に潜伏する、新しい手法 AWSDoor が解明されたようです。この問題の原因は、IAM や Lambda といった正規機能の悪用にあります。具体的には、IAM ユーザーに不正なアクセス・キーを注入したり、TrustPolicy を改変することで、クロス・アカウントの権限を継続的に確保すると、この記事は指摘しています。コンフィグ・ベースの永続化手法は、検出が難しいという問題もあります。よろしければ、2025/08/06 の「ミスコンフィグと脆弱性の決定的な違い：ログに記録されないリスクと対峙する方法とは？」も、ご参照ください。