サイバー犯罪者集団「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の認証情報を取り出していました。

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

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

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

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

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

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

次に、インターネット上に露出した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）」の数が大幅に増加していることを示しています。

図13：外部に露出したポート（10250）が大幅に増加していることを示すShodanのデータ

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

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）

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

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

1009105 – Kubernetes
1008619 - Application – Docker
1010349 - Docker Daemon Remote API Calls

変更監視（Integrity Monitoring）

1008271 – Application - Docker
1009060 - Application - Kubernetes Cluster master
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）

タグ

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

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

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

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

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

■ まとめ

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

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

執筆者

リソース

サポート

会社概要

リソース

サポート

会社概要

The Americas

Asia Pacific

Europe, Middle East & Africa