古いサービス、新しい手口: UNC2903 によるクラウド メタデータの悪用

UNC2903 Attack Leveraged CVE-2021-21311 and IMDSv1 Abuse news

2021 年 7 月以降、Mandiant は、UNC2903 による公開 Web アプリケーションのエクスプロイトを特定し、Amazon のインスタンス メタデータ サービス (IMDS) を使用して認証情報を収集および悪用しました。 Mandiant は、UNC2903 による S3 バケットと追加のクラウド リソースへのアクセス試行を、盗んだ資格情報を使用して追跡しました。このブログ投稿では、UNC2903 がエクスプロイトと IMDS の悪用をどのように実行したか、およびクラウド強化技術に関する関連するベスト プラクティスについて説明します。

UNC2903 はアマゾン ウェブ サービス (AWS) 環境を標的にしていましたが、他の多くのクラウド プラットフォームは、同様の攻撃のリスクにさらされる可能性のある同様のメタデータ サービスを提供しています。企業がクラウド ホスティング サービスへの移行を続けるにつれて、同様の脅威アクターの動機と操作が顕著になっています。この記事では、ホステッド サービスを使用するセキュリティおよび情報技術チームの潜在的なリスクと考慮事項についても説明します。

タイムライン

Mandiant のインシデント レスポンス、インテリジェンス、およびトランスフォーメーション サービス チームは、このブログ投稿で説明されている情報を収集して、同様の日和見的侵入をより適切に検出、防止、および対応できるようにしました。次のタイムラインは、最初に観測されたキャンペーン中に実行された UNC2903 アクティビティを示しています。

  • 2021 年 2 月、Adminer と呼ばれる脆弱なデータベース管理ソフトウェアを説明するCVE-2021-21311公開されました
  • 2021 年 2 月、概念実証コード (PoC) が公開され、脆弱なバージョンをホストする AWS アプリケーションでエクスプロイトを活用して認証情報を取得する方法が示されました
  • 2021 年 6 月、UNC2903 はサーバー側のリクエスト フォージェリの脆弱性を悪用し、被害者のアマゾン ウェブ サービスの秘密鍵にアクセスしてデータを盗みました。

このブログ投稿では、パッチが適用されたバージョンの Adminer ソフトウェアについて説明していますが、要求の偽造やリモート コード実行に対して脆弱な Web アプリケーションも、同様のメタデータ サービス攻撃への道を開く可能性があります。

野生での使用と搾取の証拠

クラウド メタデータの脅威の状況

Mandiant のアナリストは、AWS や同様のクラウド プラットフォームでホストされているサービスの悪用と悪用が最近増加していることを確認しました。 UNC2903 によって実行されたキャンペーンで特定された脅威は、インフラストラクチャのスキャン、偵察、およびクラウド ホスト プラットフォームによって提供される基盤となる抽象化レイヤーのさらなる悪用を含む多段階攻撃でした。基盤となるシステムの悪用と悪用が発生すると、盗まれた認証情報は、侵害されたテナントの他の AWS サービスでのデータ流出に利用されます。

具体的には、UNC2903 によるデータ窃盗につながるイベントについて、Mandiant のインシデント対応チームは次のことを特定しました。

  1. 管理者ソフトウェアをホストする外部に面した AWS Web インフラストラクチャでのネットワーク スキャンの試み
  2. インフラストラクチャが特定されると、追加の Web ナビゲーションと偵察が実行されます
  3. ホストされた Web サーバーに存在する可能性がある複数の Web アプリケーションの悪用の試み
  4. 識別されたエクスプロイトを使用した手動のエクスプロイトおよびテストを示すさらなる試み

インフラストラクチャがアマゾン ウェブ サービス クラウド内でホストされていることを考えると、IMDS は UNC2903 のような攻撃者にとって魅力的な標的です。 UNC2903 のケースでは、脅威アクターが、IMDSv1 も実行している悪用可能な Web アプリケーションを標的にしていることが確認されました。 Amazon の IMDSv1 では、リンク ローカル IP アドレス (169.254.169.254) に対する特殊な URL への Web リクエストが許可されます。これは、ホスティング プラットフォーム全体で内部サービス通信とトラブルシューティングを強化するように設計されています。取得可能なメタデータには、構成、トポロジを理解するための情報、さらにはユーザーの役割と資格情報を取得するための情報が含まれています。

Amazon は IMDSv2 をリリースし、 GuardDutyなどの AWS セキュリティ機能を通じて保護とアラートのレイヤーを追加しました。 IMDSv2 がこのタイプの攻撃を修正する方法は、ユーザーが http://169.254.169[.]254/latest/api/token から PUT を介してトークンを取得することです。その後、そのトークンが使用され、IMDS へのすべてのリクエストで繰り返されます。特別なヘッダー ( x-aws-ec2-metadata-token ) 経由。

Amazon は GuardDuty 拡張機能を備えた IMDSv2 を実装することを推奨していますが、代わりに IMDSv1 を使用する Amazon の顧客によって作成された EC2 インスタンスは、パッチが適用されていない脆弱なサードパーティ ソフトウェアを実行している場合、危険にさらされる可能性があります。クラウド テクノロジーの採用が拡大するにつれて、脅威が表面化し、セキュリティ機能が制限された古いメタデータ サービスまたは非推奨のメタデータ サービスを基盤とする脆弱な Web インフラストラクチャが標的にされます。 Web アプリケーションの脆弱性に関連するリスクのレベルを評価し、クラウド環境の基盤となるメタデータ サービスが高度または継続的な脅威の可能性を高める可能性があるという理解と組み合わせる必要があります。

巧妙なテクニック、いくつかの SSRF、および簡単なアクセス

Mandiant はキャンペーンで、UNC2903 が専用の運用中継ボックスを利用して Web スキャンを実行し、エクスプロイトおよび関連する IMDSv1 の悪用を実行したことを観察しました。脅威アクターは、攻撃前に特定されたアプリケーションの手動偵察と一致する一連の Web スキャンとアクティビティを実行します。 UNC2903 によって観測された攻撃は、サーバー側のリクエスト フォージェリ (「SSRF」) の脆弱性を利用して、AWS S3 バケット ストレージ アクセスに使用される一時的なアクセス キーを返しました。

図 1は、 CVE-2021-21311を使用して UNC2903 で特定された重大な攻撃経路を示しています。

UNC2903 Attack Leveraged CVE-2021-21311 and IMDSv1 Abuse
図 1: CVE-2021-21311 と IMDSv1 の悪用を利用した UNC2903 攻撃

観測されたキャンペーンでは、UNC2903 が CVE-2021-21311 を利用して次の攻撃を実行しました。

  • 攻撃者は、http://169.254.169[.]254/latest/meta-data/iam/security-credentials/ に 301 リダイレクトするように構成されたスクリプトを使用して、運用中のリレー ボックスで Web サーバーをホストしています。
Mandiant テスト環境
図 2: Mandiant のテスト環境
  • 次に、攻撃者は4.0.0 から 4.7.9 より前のバージョンの管理者ページに移動し、そこから SSRF の脆弱性を実行しようとしています。
管理者
図 3: 管理者
  • 悪意のあるリダイレクト スクリプトをホストしている運用中のリレー ボックスの IP アドレスとポートが、被害者の管理者のサーバー ダイアログ ボックスに入力され、ログイン ボタンが押されます。
管理者の悪用
図 4: 管理者の悪用
  • Adminer を持つ被害者のサーバーはだまされて、動作中のリレー ボックスに Web リクエストを送信し、被害者のサーバーは 301 リダイレクトを要求して、それに従い、SSRF を完了します。
ウェブログ
図 5: Web ログ
  • 被害者のサーバーは攻撃者にエラーを返しますが、IMDS はサービスから結果を返すため、メタデータ資格情報はエラー メッセージの応答に直接表示されます。
資格情報の盗難
図 6: 資格情報の盗難

これらの手順は、攻撃を実行するために使用された脅威アクターのコマンドを正確に反映していませんが、UNC2903 が使用する方法を強調していることに注意してください。攻撃には CVE-2021-21311 による悪用と SSRF の悪用が含まれるため、デフォルトのクラウドベースのシステムとテナントの構成に基づいて、限られたアーティファクトを利用できます。

アーティファクトと注目すべき観察事項

Mandiant Incident Response は、UNC2903 によって実行された関連するエクスプロイトおよび IMDS 悪用のアーティファクトを特定して収集しました。最初のスキャンとエクスプロイトから記録されたアクティビティ、および AWS メタデータ サービスと資格情報の悪用は、テナントで利用可能なホストされたインフラストラクチャとクラウド ログの構成の対象となる場合があります。セキュリティ オペレータがイベント ログに注意を払わなければ、ロギングのレベルを上げたとしても、UNC2903 や他の攻撃者による同様の攻撃が検出されない可能性があります。

この攻撃は Adminer PHP アプリケーション ページのエクスプロイトを利用しているため、調査者は悪意のあるナビゲーションと対話を簡単に見逃す可能性があります。特定されたアクティビティは、標準的な成功した Web 応答を画面または記録されたイベント ログ内に返す一部のエクスプロイトと比較して、特徴的に独特です。

搾取と虐待を証明するいくつかの情報源には、次のものがあります。

  • Web アクセスとエラー ログ
  • GuardDuty イベント
  • VPC フロー ログ
  • S3 データとアクセス イベント

図 7 は、管理者 Web ページで特定された初期アクセスと Web アプリケーション スキャン アクティビティの例を示しています。エクスプロイトは成功しましたが、利用可能なログの Web 応答として 302 リダイレクトまたはその他の 403 エラーが Web 応答に表示されることに注意してください。

シミュレートされた攻撃者がサーバー情報を入力し、CVE-2021-21311 を実行した後に生成される Web アクセス ログ
図 7: シミュレートされた攻撃者がサーバー情報を入力し、CVE-2021-21311 を実行した後に生成された Web アクセス ログ

図 8 は、SSRF が完了したときの Web サーバーを表す VPC フローの例を示しています。アウトバウンド要求を行った被害者サーバーは、外部 IP アドレスに対して疑わしいことに注意してください。ただし、ポートは、攻撃用に選択された任意の目的のポート、またはより個別のポートに構成できます。

シミュレートされた被害者サーバーが悪意のあるポート 1337 経由で Web リクエストを送信したことを示す AWS VPC フロー ログ
図 8: シミュレートされた被害者サーバーが悪意のあるポート 1337 経由で Web リクエストを送信したことを示す AWS VPC フロー ログ

図 9 は、認証情報が盗まれて悪用された後の GuardDuty イベントの例を示しています。テストの GuardDuty は、S3 バケットからのデータ盗難が完了した後にアラートを出したことに注意してください。

盗まれたメタデータ認証情報を使用した S3 からのデータ盗難を示す AWS GuardDuty イベント
図 9: 盗まれたメタデータ認証情報を使用した S3 からのデータ盗難を示す AWS GuardDuty イベント

ミッションの完了と将来への影響

UNC2903 および同様の攻撃者によって実行された攻撃の最終段階には、データの流出または AWS テナントとのやり取りが含まれています。アプリケーションの悪用やメタデータ サービスの悪用によって盗まれた情報により、攻撃者が組織のクラウド環境からデータを操作したり盗んだりする可能性があります。同様のクラウド指向のメタデータ サービスの悪用は、攻撃者が元のアプリケーション ターゲットを超えて環境をさらに悪用できることを示しています。クラウド サービスとソリューションを設計するときは、防止と対応のための構成を評価し、テクノロジ チームが検討する必要があります。後で、不正なメタデータ サービスの使用の検出を軽減、制限、および支援するための潜在的な戦略について説明します。

Mandiant インテリジェンスの調査結果

帰属

UNC2903 は、動機が不明であり、2021 年 7 月から Mandiant によって追跡されているグループです。恐喝や販売などの盗難データ。 Web ログの分析によると、攻撃者は特に adminer.php をスキャンし、GitHub から直接 WSO Webshell をインストールするための Apache Root Privilege Escalation である CVE-2019-0211 をテストしていたことがわかりました。

CVE-2021-21311 の脆弱な adminer.php が攻撃者によって自動スキャンによって発見されてから 18 分後、Mandiant は Telegram ボットによる adminer.php のインデックス作成を観察しました。これは、adminer.php へのリンクが Telegram チャットで共有されたことを示しています。グループ。数分後、無料の VPN サービスからの自動セッションも adminer.php をスキャンしました。数時間後に別の IP から同じ自動化されたプロセスが実行され、最初のアクセスから 3 時間 15 分後にインタラクティブなアクティビティと IMDS サービスへのアクセスが成功しました。

スキャン活動

Mandiant は、2021 年 6 月下旬に UNC2903 インフラストラクチャを使用して 2,100 を超える IP アドレスをスキャンしたことを示す兆候を観察しました。スキャンはポート 80 や 443 などの Web サービスに焦点を当てており、攻撃者がリストから操作していた可能性があることを示唆する特定のサービス プロバイダーには焦点を当てていませんでした。特定のサービス プロバイダーを対象としていない、事前の調査からのオープンな HTTP ポートを持つターゲットの数。

ユーザー エージェント文字列

Mandiant によって観測された UNC2903 によって使用されるユーザー エージェント文字列:

  • Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (Gecko のような KHTML) Chrome/91.0.4472.101 Safari/537.36 Edge/91.0.864.48
  • Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (Gecko のような KHTML) Chrome/91.0.4472.106 Safari/537.36
  • Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

セキュリティを変革し、同様の脅威を軽減

Mandiant は、組織が EC2 インスタンスで IMDSv1 が有効になっていることを検出、修復、防止することを推奨しています。 EC2 インスタンスを修復して IMDSv2 を使用するように変換する前に、組織はすべてのインスタンス/アプリケーションをテストして、そのような修復手段によって運用が影響を受けないことを確認する必要があります。

脆弱な管理者 Web アプリケーションを使用すると、アプリケーションを実行している EC2 インスタンスで IMDSv2 が有効になると、攻撃者はシークレット/資格情報を取得できなくなります (図 10 を参照)。

IMDSv2 が適用された EC2 インスタンスから資格情報を取得しようとすると、エラー メッセージが表示される
図 10: IMDSv2 が適用された EC2 インスタンスから認証情報を取得しようとしたときに受信したエラー メッセージ

次に、組織が環境から IMDSv1 を検出、修復、および防止できる複数の方法を提供します。

検出、修復、および防止

IMDSv1 を使用した EC2 インスタンスの検出

現在デプロイされている EC2 インスタンスを監査して、環境で IMDSv1 または IMDSv2 が使用されているかどうかを確認します。

  • ネイティブ AWS サービス:
    • AWS Security Hub – チェック[EC2.8] EC2 instances should use IMDS v2
    • CloudWatch MetadataNoToken (インスタンス メタデータ サービスがトークン (つまり、IMDSv1) なしで正常にアクセスされた回数をカウントします)
    • AWS Config – 組織の EC2 インスタンスが HTTPTokens を要求するように設定されているかどうかを確認する Config ルール (以下を参照)。

AWSTemplateFormatVersion: "2010-09-09"

Description: ""

Resources:

ConfigRule:

Type: "AWS::Config::ConfigRule"

Properties:

ConfigRuleName: "ec2-imdsv2-check"

Scope:

ComplianceResourceTypes:

- "AWS::EC2::Instance"

Description: "A Config rule that checks whether your Amazon Elastic Compute Cloud (Amazon EC2) instance metadata version is configured with Instance Metadata Service Version 2 (IMDSv2). The rule is COMPLIANT if the HttpTokens is set to required and is NON_COMPLIANT ..."

Source:

Owner: "AWS"

SourceIdentifier: "EC2_IMDSV2_CHECK"

Parameters: {}

Metadata: {}

Conditions: {}

  • オープンソース ツール:
  • AWS CLI:
aws ec2 describe-instances --filters Name=metadata-options.http-tokens,Values=optional --query "Reservations[*].Instances[*].{Instance:InstanceId}"  --region [EnterRegionHere]

現在のアカウントの外部からの EC2 インスタンス資格情報の使用に関する GuardDuty アラート。

  • InstanceCredentialExfiltration.InsideAWS – High : EC2 インスタンス認証情報が別の AWS アカウントで使用されている場合 (図 9 を参照)。
  • InstanceCredentialExfiltration.OutsideAWS – High : EC2 インスタンス資格情報が外部 IP アドレスによって使用されている場合。
  • IMDS へのアクセスを限られたユーザーまたは EC2 ロールに制限する
    • 次のコマンドを実行して、IMDS サービスを bobuser に制限します。
ip-lockdown 169.254.169.254 bobuser

IDMSv1 の修正

: 組織の EC2 インスタンスから IMDSv1 を無効にする前に、修復アクションの前に広範なテストを実行する必要があります。

  • メタデータ サービスを必要としないインフラストラクチャでは、IMDS を完全に無効にします。
aws ec2 modify-instance-metadata-options –instance-id <instance-id> –http-endpoint disabled
  • IMDS が必要な場合、組織は EC2 インスタンスで IMDSv2 のみを実行するように強制できます。
aws ec2 modify-instance-metadata-options –instance-id <INSTANCE-ID> –http-endpoint enabled –http-token required
  • Remediate AWS-IMDSv1などのオープンソース ツールを利用して、IMDSv1 が有効になっているすべての EC2 インスタンスを検出して修復します。
python remediate-imdsv1.py --profile <AWS_PROFILE> --remediate –debug
  • メタデータ サービスへのアクセスを拒否するように iptables ルールを設定する
iptables -A OUTPUT –proto tcp -m owner --uid-owner root -d 169.254.169.254 -j REJECT

環境からの IMDSv1 の防止

  • 組織は、EC2 のロール資格情報がある場合、IMDSv2 を使用するために API 呼び出しを要求するサービス コントロール ポリシー (SCP) を作成できます。次のサンプル SCP を参照してください。

{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "RequireAllEc2RolesToUseV2",

"Effect": "Deny",

"Action": "*",

"Resource": "*",

"Condition": {

"NumericLessThan": {

"ec2:RoleDelivery": "2.0"

}

}

}

]

}

  • 組織は Infrastructure-as-Code (IaC) を利用して、IMDSv1 の使用を禁止または無効にする必要があります。 IMDSv2 を適用するにはいくつかの方法があります。ここでは CloudFormation を介していくつかの方法を示します。
  • ユーザーが IMDSv2 用に構成されていない EC2 インスタンスを起動できないようにするカスタムの CloudFormation または Terraform テンプレートを作成する
    • クラウドフォーメーション

      AWSTemplateFormatVersion: "2010-09-09"

      Description: ""

      Resources:

        IamPolicy:

          Type: "AWS::IAM::ManagedPolicy"

          Properties:

            PolicyDocument:

              Version: "2012-10-17"

              Statement:

                - Action:

                    - "ec2:RunInstances"

                  Resource:

                    - "arn:aws:ec2:*:*:instance/*"

                  Effect: "Deny"

                  Condition:

                    StringNotEquals:

                      ec2:MetadataHttpTokens: "required"

            Description: "An IAM policy that prevents users from launching new EC2 Instances if they are not configured to use the new Instance Metadata Service (IMDSv2)"

      Parameters: {}

      Metadata: {}

      Conditions: {}

    • テラフォーム

      provider "aws" {

      }

       

      resource "aws_iam_policy" "IamPolicy" {

        name = "Require_IMDSv2"

        description = "IAM Policy that requires IMDSv2"

        policy = <<POLICY

      {

        "Version": "2012-10-17",

        "Statement": [

          {

            "Action": [

              "ec2:RunInstances"

            ],

            "Resource": [

              "arn:aws:ec2:*:*:instance/*"

            ],

            "Effect": "Deny",

            "Condition": {

              "StringNotEquals": {

                "ec2:MetadataHttpTokens": "required"

              }

            }

          }

        ]

      }

      POLICY

       

      }

  • EC2 インスタンスが IMDSv2 を使用するように構成されていない場合に、ユーザーが EC2 インスタンスを起動できないようにする IAM ポリシーを作成します。

{

"Version": "2012-10-17",

"Statement": [

{

"Action": [

"ec2:RunInstances"

],

"Resource": [

"arn:aws:ec2:*:*:instance/*"

],

"Effect": "Deny",

"Condition": {

"StringNotEquals": {

"ec2:MetadataHttpTokens": "required"

}

}

}

]

}

  • 新しく作成されたすべての EC2 インスタンスが IMDSv2 を使用するように構成されていることを強制する IAM ポリシーを作成します (注: 既存の EC2 インスタンスは、この IAM ポリシーの影響を受けません)。

{

"Version": "2012-10-17",

"Statement": {

"Sid": "RequireImdsV2",

"Effect": " Deny ",

"Action": "ec2:RunInstances",

"Resource": "arn:aws:ec2:*:*:instance/*",

"Condition": {

" StringNotEquals ": {

"ec2:MetadataHttpTokens": " required "

}

}

}

}

追加の防止策と強化

  • すべての EC2 インスタンスを確認し、EC2 のユーザー データ スクリプトに平文のシークレットや機密データが含まれていないことを確認します。
    • ユーザー データ スクリプトは、EC2 の起動中に提供する一連のコマンドです。ユーザー データ スクリプトはルート権限を使用して実行され、IMDS を介して表示できます。攻撃者は、簡単な curl コマンドで実行中のスクリプトを読み取ることができます。

curl http://169.254.169.254/latest/user-data

  • HTTP Put 応答ホップの数を制限します (最小値はデフォルトで 1 に設定され、最大値は 64 です)。
    • 次の例では、発生するホップの最大数を 1 に制限しています。

{

"Version": "2012-10-17",

"Statement": {

"Sid": "MaxImdsHopLimit",

"Effect": "Deny",

"Action": "ec2:RunInstances",

"Resource": "arn:aws:ec2:*:*:instance/*",

"Condition": {

"NumericLessThanEquals":
{"ec2:MetadataHttpPutResponseHopLimit": "1"}

}

}

}

  • API 呼び出しを制限して IMDSv2 を使用し、IAM ポリシーを介して Amazon EC2 ロール認証情報を配信します

{

"Version": "2012-10-17",

"Statement": {

"Sid": "RequireAllEc2RolesToUseV2",

"Effect": "Deny",

"Action": "*",

"Resource": "*",

"Condition": {

"NumericLessThan":
{"ec2:RoleDelivery": "2.0"}

}

}

}

  • EC2 インスタンス メタデータ サービスを変更できるようにアクセスを制限する

{

"Version": "2012-10-17",

"Statement": {

"Sid": "LimitModifyInstanceMetadataService",

"Effect": "Deny",

"Action": "ec2:ModifyInstanceMetadataOptions",

"Resource": "*",

"Condition": {

"StringNotLike":
{"aws:PrincipalARN”: “arn:aws:iam:*:role/ec2-imds-admin"}

}

}

}

  • S3 バケットへの IAM ロール / 認証情報アクセスの範囲を制限する
  • パブリック インターネットからの IAM ロール / クレデンシャルの使用能力をブロックまたは削減する
  • サーバーのインターネット出口を制限して、送信サーバー トラフィックを防止します
  • S3 バケット ポリシーを実装して、S3 バケットへのアクセスをさらに制限する
  • VPC フローと S3 バケット/オブジェクト レベルのアクセス データ イベントを有効にする
  • 悪用の可能性がないか Web リクエストをプロキシまたは監視する
  • サーバーへの受信または送信を許可するサービス ポートを制限する
  • Web サーバーへの不要な HTTP ヘッダーをサニタイズまたは制限する
  • すべてをログに記録し、クレデンシャルの悪用の可能性を警告する優先順位を付ける
  • ソリューションに関するアマゾン ウェブ サービスのベスト プラクティスに従い、定期的にセキュリティ コントロールをテストする

重要ポイント

組織がさらにクラウド環境に移行するにつれて、デフォルト設定の複雑さが増し、攻撃者が 1 つのシステムからのアクセスを利用して、同様の他の多くのシステムにピボットする機会を提供する可能性があります。クラウド システムに保存されたデータは、他の環境と同様に、盗まれたり、改ざんされたり、削除されたりする可能性があります。侵入への対応における Mandiant の専門知識は、スパイ活動と金銭目的のグループの両方によって引き続き標的にされているクラウド環境にまで及びます。

謝辞

テクニカル レビューの Nick Richard と MITRE D3FEND マッピングの Justin Moore に感謝します

指標

  • 141.94.43.37
  • 37.59.152.171
  • 191.96.108.227
  • 191.96.108.8
  • hxxps://raw.githubusercontent[.]com/wso3/wso3/master/wso.php
  • 35b03c6bc21d140201670005923333de

MITRE マッピング

マイター ATT&CK UNC2903

戦術

説明

発見

T1580: クラウド インフラストラクチャの検出

初期アクセス

T1190: 公開アプリケーションの悪用

持続性

T1505.003: Web シェル

資格情報へのアクセス

T1552.004: 秘密鍵
T1552.005: クラウド インスタンス メタデータ API

コレクション

T1530: Cloud Storage オブジェクトからのデータ

マイター D3FEND UNC2903

戦術

説明

硬化

アプリケーションの強化

  • D3-PSEP: プロセス セグメントの実行防止
  • D3-SAOR: セグメント アドレス オフセットのランダム化

探知

ファイル分析

  • D3-DA: 動的解析
  • D3-EFA: エミュレートされたファイル分析
  • D3-FCR: ファイル コンテンツ ルール
  • D3-FH: ファイルハッシュ

ネットワーク トラフィック分析

  • D3-CSPP: クライアント サーバー ペイロード プロファイリング
  • D3-NTCD: ネットワーク トラフィック コミュニティ偏差
  • D3-PHDURA: ホストごとのダウンロード/アップロード比率分析
  • D3-PMAD: プロトコル メタデータの異常検出
  • D3-RTSD: リモート端末セッション検出
  • D3-UGLPA: ユーザー地理位置情報ログオン パターン分析
  • D3-ISVA: インバウンド セッション ボリューム分析

プロセス分析

  • D3-DQSA: データベース クエリ文字列分析
  • D3-PSMD: プロセス自己変更検出
  • D3-PSA: プロセススポーン分析
  • D3-PLA: プロセス系統分析

隔離する

ネットワークの分離

  • D3-ITF: インバウンド トラフィックのフィルタリング
  • D3-OTF: アウトバウンド トラフィックのフィルタリング

実行の分離

  • D3-HBPI: ハードウェアベースのプロセス分離
  • D3-MAC: 強制アクセス制御
  • D3-EDL: 実行可能ファイルの拒否リスト

欺く

おとりオブジェクト

  • D3-DF: おとりファイル
  • D3-DNR: おとりネットワーク リソース
  • D3-DUC: デコイ ユーザー資格情報

追い出す

資格情報の無効化

  • D3-ACI: 認証キャッシュの無効化

プロセスのエビクション

  • D3-PT: プロセスの終了

参照: https://www.mandiant.com/resources/blog/cloud-metadata-abuse-unc2903

Comments

タイトルとURLをコピーしました