サイバー犯罪者集団「TeamTNT」による、侵害したDocker Hubアカウントの悪用方法を解説

本ブログでは2021年11月30日の記事で、侵害されたDocker Hubアカウントが暗号資産（旧仮想通貨）の採掘活動（マイニング）に悪用されていたほか、これらの活動がサイバー犯罪者グループ「TeamTNT」に関連していたことを明らかにしました。それらのアカウントは現在削除されていますが、トレンドマイクロは、これらの侵害されたアカウントに関連するTeamTNTの活動を追跡調査することができました。

トレンドマイクロは、上記の活動に加えて、同グループが異なる環境内で実施したいくつかの不正な活動を確認しました。そのうちの1つは、Weaveworks社の提供する正規ツール「Weave Scope」を悪用して、展開されたコンテナの監視・制御を行っていたことです。

■ 攻撃者が「Weave Scope」を悪用した手口

Weave Scopeは、DockerやKubernetes向けの可視化・監視ツールです。システム管理者はこのツールを使用することで、展開されたコンテナ / ポッド / ワークロードを監視・制御することができます。

実行中のコンテナを管理するには、コンテナの実行、再起動、一時停止、停止、削除が必要ですが、これらはすべてWebコンソール（ローカルまたはクラウド内）から制御できます（図1赤枠内）。

今回の攻撃シナリオでは、基盤となる侵害されたホストが、攻撃者の制御するWeave Scopeインスタンスのノードとなり、そこから攻撃者は様々なコマンドを実行することができました。

管理機能を備えたWeave Scopeは、攻撃者にとって興味深い攻撃対象となります。以下に、Weave Scopeを狙った最近の攻撃手口を紹介します。

1. 攻撃者は、侵害されたアカウントに保存されたイメージに基づいて新たな特権コンテナを起動します。そして、引数内で基盤となるホストのルートファイルシステムをマウントポイント「/host」にマウント（認識させて利用可能な状態に）しようと試みたのち、攻撃者のインフラストラクチャから取得したbashスクリプトを実行します。

2. スクリプト「scope2.sh」がダウンロードされたのち、「bash」に受け渡されて実行されます（図3）。このスクリプトはまず、ホスト名の値が「HaXXoRsMoPPeD」であるかどうかを確認し、trueの場合は実行を停止します。これは、システムがすでに侵害されているかどうかを確認するためのフラグだと考えられます（図6）。

3. 環境変数が設定されます。これによりロケール設定が上書きされ、コマンド履歴が記録されなくなると共に、新たなパスが書き出されます（図6）。

4. 制御されたエンドポイントから変数「SCOPE_TOKEN」が入力されます。この変数にはWeave Scopeのサービストークンが格納されています（図7）。「SCOPESHFILE」には、Base64でエンコードされたWeave Scopeスクリプトが格納されています。

5. 「docker」バイナリへのパスは、「type docker」を使って取り出されます（図8）。TTYイベントを回避するために、それらは「/dev/null」にリダイレクトされます。これに基づいて、実行が進められます。

6. ファイル「/tmp/.ws」が存在するかどうかが確認されます。

a. ファイル「/tmp/.ws」が存在しない場合、以下のコマンドが実行されます。

i. 「mount」ユーティリティを使用して、読み取り/書き込み権限とともに「/tmp/」パスが再マウントされる。

ii. 変数「SCOPESHFILE」に格納されたBase64でエンコードされた文字列がデコードされ、出力が「/tmp/.ws」にリダイレクトされる。これはWeave Scopeスクリプトで、ファイル名が「a」で始まることから、デフォルトでは隠匿される。

iii. 新たに作成されたスクリプトのパーミッションが、「chmod」を用いて実行ファイルに変更される。

b. ファイル「/tmp/.ws」が存在する場合は、以下の手順で実行されます。

i.「mount」ユーティリティを使用して、「/tmp/」パスが読み取り/書き込み権限として再マウントされる

ii.「/tmp/.ws」に存在するWeave Scopeが停止され、上記の手順4で取り出されたサービストークンを使って起動される。

Weaveworks社は2020年9月に、Weave Scopeを保護するためのベストプラクティスを紹介するブログ記事を公開しています。しかし、残念ながらこの正規ツールの悪用事例は依然としてかなりの頻度で発生しています。

■ 侵害されたコンテナからのエスケープ

トレンドマイクロの調査により、攻撃者が侵害されたコンテナからホスト側にエスケープするためによく知られた手法を悪用していたことがわかりました。攻撃者は、バインドマウントの機能を悪用して、以下のパスからDocker Hubの認証情報を取り出していました。

1. /root/.docker/config.json
2. /home/*/.docker/config.json

Docker社の公式ドキュメントによると、

『利用者は、認証情報を持っている場合、任意のパブリックまたはプライベートリポジトリにログインできます。ログインすると、コマンドは、認証情報をLinux上の「$HOME/.docker/config.json」内、あるいは「%USERPROFILE%/.docker/config.json」内に保存します』と記されています。

ある利用者がDockerコマンドラインを使ってDocker Hubアカウントにログインするときに、認証情報ストアが指定されていない場合、ユーザ名、パスワード、レジストリサーバのリンクは、JSONとして以下のように入力されます。

デフォルトでは、使用されるレジストリはDocker社のものです。「auths.auth」フィールドの値は、「ユーザ名＋パスワード」という形式の認証情報を含むBase64でエンコードされた文字列です。これらの認証情報が悪用された場合、被害者の情報にアクセスすることができます。

1. 電子メールアカウントの作成時に使用されたユーザID
2. プライベートイメージ
3. アクセストークン
4. コミュニケーションプラットフォーム「Slack」のWebhooks
5. コンテンツのサブスクリプション（定期購入）
6. アップグレードされた機能

次に、インターネット上に露出したkubeletを列挙した手口を見てみましょう。

■ インターネット上に露出したKubeletを列挙した手口

この攻撃は、Docker REST APIを悪用して、ファイルシステムパス「/root/init.sh」にスクリプトが含まれるイメージからコンテナを作成しました。このスクリプトには、以下が含まれています。

1. 攻撃者は最初にAlpineベースのコンテナを更新し、ソースからアプリケーションレイヤスキャナ「zgrab」をコンパイルしたり、ポートスキャナ「masscan」を使用したりするなど、後の操作で必要なパッケージを追加します。

2. 上記の手順が実行されると、攻撃者のインフラ上に存在する特定のエンドポイントのコンテンツが「RUN」に等しかった場合、kill switchを使用して悪意のある関数の実行を開始します（図11）。

3. kill switchが「RUN」に等しいことが確認されると、悪意のあるPWN機能が実行されます（図12）。

このスクリプトは、悪意のあるエンドポイント（サーバ）からスキャン範囲を取り出します。取り出した結果に「ENDE」が含まれている場合、それは悪意のあるスクリプトを終了する合図です。

エンドポイントから返された結果は、変数「SCAN_RANGE」内に格納され、後で「.0.0.0/8」に付加されます。具体的には、このエンドポイントから返された値が10の場合、「SCAN_RANGE」の値は「10.0.0.0/8」となります。

6文字のランダムなアルファベット文字列である変数「rndstr」は、公開されたkubelet APIが使用するTCPポート番号10250を利用して実行されているポッドのIPアドレスリストを蓄積します。これらのIPアドレスは、masscanやzgrabを悪用して検出されています。このサブネットが完成すると、forループを使ってそれらの結果が攻撃者に送り返され、Webサイトを介して取得した結果を繰り返し実行します。

結果が送信されると、すべてのサブネットが列挙されない限り、kill switchループはインフラからの新たなサブネットを求めてループバックします。

攻撃者は、後で露出したKubeletを狙うために下準備としてこれを行っていると見られています。本ブログでは2021年12月1日の記事で、Docker REST APIからKubernetes APIへと攻撃対象が移行した経緯について詳説しました。図13は、数ヶ月前に公開された約1,200のワークロードからオンライン検索エンジン「Shodan」によってインデックス化された、インターネット上に露出した「Kubernetes APIが使用するポート（10250）」の数が大幅に増加していることを示しています。

■ トレンドマイクロ製品による保護

Cloud One Workload Security

DockerデーモンのREST APIを介して新たなコンテナが作成されると、DPI（Deep Packet Inspection）ルール「1010326 – Identified Docker Daemon Remote API Call」が、イメージから異なる手順で作成されるコンテナに対する様々なノートと共にトリガされます。

イベントは、「containerd」プロセスが作成されたときに生成され、変更監視（Integrity Monitoring）モジュールを使用して記録されます。

DockerデーモンがTCPポート上で待機していることが観測されると、「セキュリティログ監視（Log Inspection）」モジュールがこれを検出します（図15）。

「不正プログラム対策（Anti-Malware）」モジュールは、悪意のあるスクリプト「scope2.sh」をトロイの木馬型マルウェアとして検出します（図16）。

侵入防御（Intrusion Prevention）

1. 1010326 – Identified Docker Daemon Remote API Call
2. 1010561 – Identified Kubernetes Unprotected Primary Channel Information Disclosure
3. 1010762 – Identified Kubernetes API Server LoadBalancer Status Patch Request
4. 1010769 – Identified Kubernetes Namespace API Requests
5. 1009493 – Kubernetes Dashboard Authentication Bypass Information Disclosure Vulnerability (CVE-2018-18264)
6. 1009450 – Kubernetes API Proxy Request Handling Privilege Escalation Vulnerability (CVE-2018-1002105)
7. 1009561 – Kubernetes API Server Denial of Service Vulnerability (CVE-2019-1002100)

セキュリティログ監視（Log Inspection）

1. 1009105 – Kubernetes
2. 1008619 – Application – Docker
3. 1010349 – Docker Daemon Remote API Calls

変更監視（Integrity Monitoring）

1. 1008271 – Application – Docker
2. 1009060 – Application – Kubernetes Cluster master
3. 1009434 – Application – Kubernetes Cluster node

Cloud One Network Security

Network Securityでは、以下のルールにより、本記事で挙げた攻撃を検出します。

• 29993: HTTP: Docker Container With Root Directory Mounted with Write Permission Creation Attempt
• 33719: HTTP: Docker Daemon “create/exec” API with “Cmd” Key Set to Execute Shell Commands
• 33905: HTTP: Kubernetes API Proxy Request Handling Privilege Escalation Vulnerability
• 34487: HTTP: Kubernetes Dashboard Authentication Bypass Vulnerability
• 34488: HTTPS: Kubernetes Dashboard Authentication Bypass Vulnerability
• 34668: HTTP: Docker Build Image API Request with remote and networkmode Parameters Set
• 34796: HTTP: Docker Version API Check Request
• 35799: HTTP: Kubernetes Overlength json-patch Request
• 38836: HTTP: Kubernetes API Namespaces Request
• 38837: HTTP: Kubernetes API Namespaces Status Request
• 38838: HTTP: Kubernetes API Create Namespace Request
• 38839: HTTP: Kubernetes API Delete Namespace Request
• 38840: HTTP: Kubernetes API Update Namespace Request
• 38847: HTTP: Kubernetes API Server loadBalancer Status Patch Request
• 38892: HTTP: Kubernetes API Admission Control Create Mutating Webhook Request
• 38893: HTTP: Kubernetes API Admission Control Create Validating Webhook Request
• 38896: HTTP: Kubernetes API Admission Control Resources Request
• 38898: HTTP: Kubernetes API Admission Control List Mutating Webhook Configurations Request
• 38899: HTTP: Kubernetes API Admission Control List Validating Webhook Configurations Request
• 38901: HTTP: Kubernetes API Admission Control Delete Validating Webhook Request
• 38902: HTTP: Kubernetes API Admission Control Delete Mutating Webhook Request
• 38903: HTTP: Kubernetes API Admission Control Update Validating Webhook Request
• 38904: HTTP: Kubernetes API Admission Control Update Mutating Webhook Request
• 38905: HTTP: Kubernetes API Admission Control Read Mutating Webhook Request
• 38906: HTTP: Kubernetes API Admission Control Read Validating Webhook Request
• 38907: HTTP: Kubernetes API Admission Control Replace Mutating Webhook Request
• 38908: HTTP: Kubernetes API Admission Control Replace Validating Webhook Request
• 38909: HTTP: Kubernetes API CustomResourceDefinition Resources Request
• 38910: HTTP: Kubernetes API Create CustomResourceDefinition Request
• 38916: HTTP: Kubernetes API List CustomResourceDefinition Resources Request
• 38917: HTTP: Kubernetes API Update CustomResourceDefinition Resources Request
• 38918: HTTP: Kubernetes API Update Status CustomResourceDefinition Resources Request
• 38919: HTTP: Kubernetes API Read CustomResourceDefinition Resources Request

Trend Micro Vision One

Weave Scopeはワークロード内で使用される正規ツールであるため、検出モデル（Detection Models）画面から「ステータス（図17赤枠内）」を切り替えることで、検出機能を有効 / 無効にすることができます。環境内でWeave Scopeの使用が想定されていないにも関わらず、XDRの検出モデルによりアラートがトリガされていたり、Observed Attack Techniquesにリストされていたりする場合は、イベントを確認して調査する必要があります。

Workbench

図18に示すダイアグラムは、さまざまなCloud Oneモジュール間の相関関係を1つの画面にまとめたものです。左側のパネルは、Cloud Oneモジュールから生成されたイベントで観測された一連の攻撃手法を表示し、右側のパネルは、攻撃の試みに関与した様々なオブジェクトを表示しています。対応するMITRE ATT&CKタグは、悪用されているフレームワークを特定するのに役立ちます。

図19のWorkbenchでは赤枠の「Impact Scope」より、暗号化されていないDocker REST APIが外部に露出し、Dockerデーモンがリッスン状態にあるワークロードを表示することで、組織内の影響範囲を確認できます。

Root Cause Analysis

Observed Attack Techniquesから生成されたRoot Cause Analysisでは、アウトバウンド接続が観測された正確な時刻や、プロセスのコマンドラインを用いて確認されたプロセスの親子関係など、重要な様々なフィールドを深く掘り下げることができます。これにより、「nsenter」が「scope」から実行され、「bash」シェルの作成に使用されていることや、システムの起動やシャットダウンを担うプロセスID 1あるいは「init」プロセスからコンテキストが取り出されていることが明らかとなりました。

■ まとめ

不十分な対応によるセキュリティ設定の不備や、ソフトウェア固有のバグによって引き起こされる脆弱性は、保護することが困難です。トレンドマイクロは上記の事例において、Weave scopeのような正規プラットフォームを悪用する手口を観測しました。セキュリティを確保するために、定期的に修正プログラム（パッチ）を適用したり、サイバー空間におけるインシデントの最新情報を入手して、周囲に警戒を促すなど、日常業務にセキュリティを浸透させることを再考する必要があります。

■ トレンドマイクロの対策

統合型サーバセキュリティソリューション「Trend Micro Deep Security」（オンプレミス管理型）および「Trend Micro Cloud One Workload Security」（クラウド管理型）は、幅広いセキュリティ機能で攻撃者の侵入を防ぎます。特に、仮想パッチ機能によって脆弱性を狙う攻撃からサーバを防御します。

「Trend Micro Vision One」は、XDR（Extended Detection and Response）ソリューションを超える付加価値と新たなメリットを提供し、企業が「より多くを把握し、迅速に対応する」という目的を実現する脅威防御のプラットフォームです。メール、エンドポイント、サーバ、クラウドワークロード、ネットワークといった複数のセキュリティレイヤーにまたがる情報を収集し、自動的に相関させる深く幅広いXDR機能を提供する「Trend Micro Vision One」は、自動化された防御機能によって攻撃の大半を防ぐことが可能となります。

■ 侵入の痕跡（Indicators of Compromise、IoC）

今回の記事に関する侵入の痕跡は、こちらを参照してください。

参考記事：

• 「Analyzing How TeamTNT Used Compromised Docker Hub Accounts」
  by Trend Micro Research

記事構成：高橋　哲朗（セキュリティマーケティンググループ）

平子　正人（セキュリティマーケティンググループ）

翻訳：益見 和宏（Core Technology Marketing, Trend Micro Research）

The post サイバー犯罪者集団「TeamTNT」による、侵害したDocker Hubアカウントの悪用方法を解説 first appeared on トレンドマイクロ セキュリティブログ.