本文の内容は、2023年3月29にNIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/detect-scarleteel-sysdig-secure）を元に日本語に翻訳・再構成した内容となっております。
最近のSCARLETEEL インシデントは、開発サイクルの早い段階でセキュリティ脅威を検出することの重要性を強調しています。Terraformのステートファイルを使えば、攻撃者は機密情報に簡単にアクセスでき、クラウドインフラストラクチャーに不正にアクセスすることができます。
今回のケースでは、攻撃者はコンテナ化されたワークロードを悪用し、それを使ってAWSアカウントへの特権昇格を行い、ソフトウェアや認証情報を盗み出しました。また、Terraformのステートファイルを使用して、組織内の他の接続されたAWSアカウントにアクセスし、その範囲を広げようとしました。
このブログ記事では、SCARLETEELやその他の類似のセキュリティ脅威を検出するためにSysdig Secureを使用する方法を紹介します。
Sysdig Secure は、クラウドインフラストラクチャー全体の継続的な監視、脅威の検出、コンプライアンスの実施を実現する、包括的なクラウドセキュリティプラットフォームです。Terraform、Kubernetes、Dockerなどの一般的なDevOpsツールとインテグレーションし、フルスタックのセキュリティにおける可視性を提供します。
初期アクセス
この攻撃は、侵害されたKubernetesコンテナから始まり、被害者のAWSアカウントに拡散したため、特に高度なものでした。
攻撃者は、EC2ロール、Lambdaサーバーレス機能、Terraformなど、AWSクラウドの仕組みに関する知識を示していました。彼らの主な動機は、クリプトジャッキングではなく、独自ソフトウェアの窃盗でした。しかし、公衆向けのWebアプリケーションを潜在的な乗っ取りから保護することは重要です。
この目的のために、それらのKubernetesアプリのリアルタイムの侵入検知が必要です。
公衆向けWebアプリケーションを悪用する
SCARLETEEL攻撃の場合、敵はKubernetesクラスターにデプロイされたインターネットに公開されたサービスを悪用しました。コンテナにアクセスすると、攻撃を続行するためにさまざまなアクションを実行し始めます。
侵害を軽減するために、被攻撃者はNetworkPoliciesを実装して、クラスターの内部と外部の特定のingress/egressトラフィックのみを許可することができます。Kubernetes環境を介したラテラルムーブメントとデータ漏洩を防止するためにNetworkPoliciesを使用する事もできます。
幸いなことに、Sysdig Secureでは、予期せぬネットワークトラフィックが再生されないよう、最小権限のNetworkPoliciesを推奨しています。
Kubernetes ネットワーク・ポリシー Sysdig Secure
Sysdig Secureはお客様のKubernetes環境内のネットワークトラフィックを分析するため、ワークロードにより実際に過去に使用したトラフィックを簡単にホワイトリスト化し、予期しないトラフィックはドロップすることができます。
次の画像は、Sysdig Secureのネットワークトポロジーグラフを示したものです。
実行（Execution）
実行は、敵が制御するコードがローカルまたはリモートのシステム、デバイス、その他の資産上で実行されることになるテクニックで構成されています。
SCARLETEELの場合、攻撃者は ‘xmrig’ と呼ばれる既知の悪質なクリプトマイニング・バイナリを実行しました。本ブログでは、この攻撃がどのような手順で行われ、Sysdig Secureでどのように防ぐことができるかについて説明します。
Kubernetesにおけるクリプトマイニング
Falcoのルールには複数のバリエーションがあり、コンテナ、ホスト、Kubernetesにおけるクリプトマイニングの挙動を検出するためによく設計されています。しかし、敵対者は、検出を回避し、可能な限り攻撃のための足場を維持するために最善を尽くします。
まず、Falcoは、以下のFalcoルールで説明しているように、IPアドレス、FQDN、または一致するポート番号のいずれであっても、クリプトマイニングプールに確立された接続を検出することができます。
アウトバウンド接続を検出する SysdigSecure
敵は、これらのIP、ドメイン名、およびポートを直接指すのではなく、Cloudflareのようなコンテンツ配信ネットワーク（CDN）を介して、または単純なHAProxy設定によってトラフィックを中継する場合、この検出を回避することができます。これが、Kubernetes環境のセキュリティを確保するためにネットワークポリシーが非常に重要である理由です。
Sysdig Secureの新しい機械学習ポリシー機能により、使用されたファイル名やネットワーク接続に関係なく、可能な限り早い段階でマイナーを検出することができます。
以下のスクリーンショットに見られるように、機械学習アルゴリズムは、マッチング文字列の条件ではなく、挙動に基づいて検出します。さらに、xmrigはコンテナとして実行され、その挙動から88%の信頼度で検出されました。
ML検出 Sysdig セキュア
探索(Discovery)
前述のように、クリプトマイニングは敵対者にとってのもう一つのステップに過ぎません。
攻撃者は多くの場合、クラウドでの永続性の実現、機密データの漏洩を目的としており、十分な権限があれば、クリプトマイニング用にEC2インスタンスやKubernetes Podなどの新しいリソースを作成し、組織のクラウド請求に影響を与える可能性があります。
攻撃者はクラウドアカウントへの初期アクセスを取得すると、AWSアカウントにデプロイされたリソースに関する情報を収集し始めました。表で報告されているアクティビティは、AWSアカウントで記録されたAPIリクエストの一部に過ぎません。
公開されている脆弱なS3バケットを把握する
悪意のあるアクターは、パブリックなREAD（LIST）アクセスを許可しているS3バケットをスクラップして、その中に含まれるオブジェクトをリストアップすることができます。つまり、バケットのURLを知った悪意のある行為者は、バケット内のすべてのオブジェクト（そこに保存されているかもしれない機密データを含む）に簡単にアクセスし、リスト化することができます。
このようなS3バケットを悪用するには、悪意のある行為者は以下のステップを実行する必要があります：
- S3バケットのURLを見つける
- バケツ内のオブジェクトをリストアップする
- オブジェクトのダウンロード
このプロセスを容易にするツールがいくつかあり、攻撃者はしばしば、公開されたバケットに設定ミスがないか監査するためにそれらを使用します。以下はその例です：
このような悪用を防ぐには、S3バケットのアクセス制御を適切に設定し、許可されたユーザーとアプリケーションのみにアクセスを制限することが重要です。これは、バケットポリシー、IAMロール、およびアクセスコントロールリスト（ACL）を使用して、バケットとそのオブジェクトへのパブリックアクセスを制限することで実現できます。さらに、S3バケットのアクティビティとアクセスログを定期的に監視して、不正なアクセスの試みを検出し、適切な対処を行うことが重要です。
認証情報アクセス（Credential Access）
アクセスキーは、IAMユーザーまたはAWSアカウントルートユーザーの長期的な資格情報です。アクセスキーを使用して、AWS CLIまたはAWS APIへのプログラムリクエストに署名できます（直接またはAWS SDKを使用して）。詳細については、「AWS 全般のリファレンス」の「AWS API リクエストの署名」を参照してください。
SCARLETEELの場合、メタデータエンドポイントから認証情報を取得するために一連のコマンドを実行しました。
AWSメタデータエンドポイントを使った横移動
AWSクラウドメタデータサービスは、IPアドレス169.254.169.254経由でアクセスでき、インスタンスメタデータ、IAMロール認証情報、ユーザーデータなど、Amazon Web Services (AWS) インスタンスに貴重な情報を提供します。
このサービスはAWSインスタンスが正しく機能するために不可欠ですが、SCARLETEELの攻撃に見られたように、コンテナ内からアクセスするとセキュリティリスクをもたらす可能性があります。幸いなことに、Sysdig SecureのFalcoの実装では、以下の例に見られるように、コンテナがクラウドやEC2のメタデータサービスに接触しようとする場合の専用ルールが提供されています：
- rule: Contact cloud metadata service from container
desc: Detect attempts to contact the Cloud Instance Metadata Service from a container
condition: >-
outbound and fd.sip="169.254.169.254" and container and
consider_metadata_access and not user_known_metadata_access
output: >-
Outbound connection to cloud instance metadata service
(proc.cmdline=%proc.cmdline connection=%fd.name %container.info
evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd
priority: NOTICE
tags:
- MITRE_T1552.005_unsecured_credentials_cloud_instance_metadata_api¨C94C - MITRE_T1552_unsecured_credentials¨C95C - MITRE_TA0006_credential_access¨C96C - MITRE_TA0007_discovery¨C97C source: syscall
コンテナがAWSメタデータサービスにアクセスできる場合、システム全体のセキュリティを侵害するために使用できる機密情報を取得する可能性があります。SCARLETEELの場合、攻撃者はAWSインスタンスのIAMロール認証情報にアクセスすることができ、特権昇格させ、AWS環境内の他のリソースにアクセスできる可能性がありました。
このような事象が発生した場合、悪意があるかどうかを本当に確認するためには、アラームを作動させ、その後のすべての事象をキャプチャーすることが必要です。もし、私たちの環境でこのデータを収集したくない、あるいは収集する必要がない場合は、インスタンスメタデータへのアクセスをオフにすることができます。
さらに、攻撃対象領域を減らすために、コンテナがその意図する機能に必要な最小特権の原則とアクセスレベルで構成されていることを確認することが重要です。ネットワークのセグメンテーションが不十分な場合は、Sysdig Secureのポリシーによって、これらのハイジャックされたプロセスを停止させることができます。
S3/Lambda認証情報の窃取
Lambda function やその他のサーバーレス機能は、その下のインフラストラクチャーを気にせずにカスタムコードを実行するために一般的に使用され、エンドユーザーには多くの柔軟性が残されています。影響を受けたAWSアカウントには、主にアカウントの自動化に関連する、さまざまなLambda function がありました。
攻撃者は、適切なAPIコールを使用して、AWSアカウント内の特定の領域にあるすべてのLambda functionを列挙し、取得することを開始しました。例えば、以下のAWSコマンドを使用して、function を一覧表示することができます。裏では単なるREST API呼び出しなので、このタスクを達成するための方法はたくさんあります。
aws lambda list-functions
Lambdaからソフトを盗み出す
function のリストを入手した後、攻撃者はLambdaのコードをダウンロードすることで、より深く掘り下げることを試みました。AWS APIを呼び出してコードの場所を取得し、Lambdaを構成するコードをダウンロードすることができました。
AWS Lambda Sysdig Secure
最終的に、このケースの攻撃者は、Lambda コードの流出に成功しました。このことから、IAMユーザーの悪意のある行動を削除するだけでなく、Sysdigのような管理されたツールを使用して、IAMユーザーに割り当てられたLambdaロールに関連する権限を制限する必要性が求められます。
Terraformによる認証情報アクセス
Terraformのステートファイルには、すべてのデータがプレーンテキストで含まれており、その中にはシークレットが含まれている可能性があります。安全な場所以外にシークレットを保存することは決して良い考えではなく、間違いなくソースコントロールには入れてはいけません！
攻撃者は利用可能なバケットをリストアップし、すべてのデータを取得することができました。インシデント調査中にPacuやTruffleHogなどの異なるツールでデータを調べると、S3バケット内のterraform.tfstateファイルにクリアテキストのIAMユーザーのアクセスキーとシークレットキーの両方を見つけることができました。
Terraformのベストプラクティスについては、Terraformセキュリティガイドを参照してください。
オーガナイゼーションの横移動
横移動(ラテラルムーブメント）は、敵対者がネットワーク上のリモートシステムに侵入して制御するために使用するテクニックで構成されています。これらの技術は、デフォルトの認証情報、既知のアカウント、脆弱なサービスを悪用し、ITとOTの両方のネットワークに存在するデュアルホームのデバイスやシステムも活用することがあります。
過剰なパーミッション
Kubernetes Network PoliciesやAWS Security Groupsと同様に、AWSユーザーにも最小特権の原則を適用し、横への移動を防止する必要があります。AWSのユーザーは、Identity & Access Management（IAM）サービスの下で作成されます。IAMユーザーの権限を制限するのに苦労している人のために、Sysdig Secureは、使用する権限と使用しない権限に基づいて、最小特権のIAMユーザーポリシーを自動的に生成します。これは、以下のスクリーンショットに見られるように、デフォルトでフル管理者権限が与えられているユーザーに対して最も有効です。
以下のビデオで説明されているように、ほとんどのユーザーはクラウド上で過剰な権限を与えられています：
ここでの本当の利点は、Sysdig Secureがユーザーのリスクが高い箇所を特定し、管理者にクラウドユーザーに関連するリスクを改善するための迅速かつ簡単な方法を提供できることです。ある特定のAWSアカウントやリージョンで作業する必要があるユーザーからMulti-Tenancyロールを削除することで、そのアカウントが侵害された場合、敵はあるAWSアカウントから別のアカウントへ横移動する範囲を限定することができるようになりました。
防御回避(Defense Evasion)
防御回避は、敵対者が侵害の全体を通して検出を回避するために使用するテクニックで構成されています。防御回避に使用されるテクニックには、セキュリティソフトウェアのアンインストール/無効化、データおよびスクリプトの難読化/暗号化などがあります。
Cloudtrailを無効にする
SCARLETEEL攻撃の場合、敵対者はAWSのCloudtrail Loggingを無効にしました。これにより、クラウドプロバイダーからの監査アクティビティに依存する脅威検出監視ツールは、クラウド内の横移動に関連するイベントの新しいストリームを受け取ることができなくなりました。攻撃者がCloudtrailロギングを簡単に無効化または変更できるという事実は、クラウドにおける最小特権アクセスの重要性をさらに強調するものです。
- rule: CloudTrail Logging Disabled
desc: >-
The CloudTrail logging has been disabled - this could be potentially
malicious.
condition: aws.eventName="StopLogging" and not aws.errorCode exists
output: >-
The CloudTrail logging has been disabled. (requesting user=%aws.user,
requesting IP=%aws.sourceIP, AWS region=%aws.region,
arn=%jevt.value[/userIdentity/arn], resource
name=%jevt.value[/requestParameters/name])
priority: warning
tags:¨C153C - MITRE_T1562.008_impair_defenses_disable_cloud_logs¨C154C - MITRE_TA0005_defense_evasion¨C155C - MITRE_T1562.001_impair_defenses_disable_or_modify_tools¨C156C - MITRE_T1562_impair_defenses¨C157C source: aws_cloudtrail
Cloudtrailのような特定のサービスを変更できるユーザー数を監視することで、セキュリティチームは敵対者の行動を中断することなく監視し続けることができます。
データ持ち出し(Data Exfiltration)
データ持ち出しとは、権限のない人が、安全なシステムからデータを取り出し、安全でないシステムや権限のないシステムに移し替えることです。したがって、クラウド上のデータ持ち出しとは、クラウドリソースからデータを不正に移動させることを意味します。
独自のソフトウェアを盗む
データ持ち出しの過程で、敵はコマンド＆コントロール（C2）サーバーに接続することがよくあります。匿名でのデータ持ち出しを防ぐには、既知の悪質なC2サーバーへの接続（受信または出力）をリアルタイムで検出できることが重要です。例えばTorの出口ノードがAWSアカウントと通信していた場合、Sysdig Secureは以下のFalcoのルールで説明されているように、このアクションを検出することができます。
- rule: AWS Suspicious IP Inbound Request
desc: >-
Detect inbound requests from known suspicious IP sources, such as TOR exit
nodes, to AWS services.
condition: >-
aws.sourceIP in (ti_anon_ips) and not (aws.eventName="ConsoleLogin" and
jevt.value[/responseElements/ConsoleLogin]="Failure")
output: >-
Suspicious IP Inbound Request (aws.sourceIP=%aws.sourceIP,
aws.region=%aws.region, aws.eventName=%aws.eventName, aws.user=%aws.user,
userAgent=%jevt.value[/userAgent], errorMessage=%jevt.value[/errorMessage])
priority: warning¨C176C source: aws_cloudtrail
]Sysdig Secureには、最新の脅威を検出するためにこれらのマネージドルールを更新する責任を負う脅威インテリジェンスチームがあります。オープンソースのFalcoとは異なり、Sysdig Secureのチームは、マネージドルールに関連するリストを定期的に更新しています。リストは、よく知られている悪質なIP、ドメイン、ポート、ハッシュ値、バイナリ名、さらにファイル/ディレクトリ名について設計されています。これにより、脅威対応者は、データ持ち出し攻撃に使用される既知の不良IPを検出するSysdig Secureを信頼できるため、一定のリスクを回避することが可能となります。
まとめ
Sysdig Secureは、Kubernetes Network Policiesによるゼロトラストネットワーキングや、悪意のあるコンテナの活動を停止させるSigkillアクションなどの堅牢なセキュリティ対策を活用し、SCARLETEEL攻撃をできるだけ早い段階で検出し阻止するのに貢献しました。
脆弱なPodの悪用を迅速に特定し、関連するAWSユーザーのIAMロールを通じて攻撃者が機密情報にアクセスするのを防ぐことで、異常な動作を検出し、ランタイムでドリフトコントロールを行える事もできるSysdig Secureの多層アプローチにより、コンテナエスケープを防止しました。
Sysdig Secureの強力な検出機能により、攻撃者が特権を昇格させて横方向に移ろうとする前に、セキュリティチームはこれらの悪意のある活動に対してアラートを発しました。
脆弱なアプリケーションを保護し、機密性の高いS3バケットへのアクセスをコントロールし、攻撃対象領域を減らすことで、将来的に同様の攻撃を防ぐことができました。Sysdig Secureは、姿勢の観点からは、OPAを活用し、セキュリティに対するPolicy-as-Codeアプローチにより、複数のInfrastructure-as-Code（IaC）ソース（Terraform、Helm、Kustomize）とKubernetesクラスターで一貫したポリシーを適用できます。
最後に、このインシデントは、コンテナ、クラウド、Kubernetesにおける脅威を検知・防止するエンドツーエンドのセキュリティソリューションの必要性を強調するものです。また、適切なセキュリティ対策を実施し、強力な検出とアラートで警戒を怠らず、Terraformのステートファイルへの攻撃を防ぐために明確なIAMコントロールを設定することの重要性を強調しています。
脅威の巧妙さによっては、すべての脅威を確実に検出することはできませんが、攻撃される可能性のあるすべての領域を監視し、Kubernetesとクラウドで影響範囲を制限するために特定のベストプラクティスを実施することに全力を尽くすことができます。