MongoDB のミスコンフィグを狙うランサムウェア：データの削除と $500 の身代金

Hackers Target MongoDB Instances to Delete Databases and Plant Ransom Notes

2026/02/02 gbhackers — MongoDB データベースを標的とする、大規模なランサムウェア・キャンペーンが継続している。認証制御が設定されていないミスコンフィグ状態で、インターネットに露出した多数のサーバが、世界的に侵害され続けている。最近の調査により、機会主義的な脅威アクターが自動化スクリプトを用いてデータベースを消去し、Bitcoin による身代金を要求していることが明らかになった。コンフィグの不備が、スケーラブルな恐喝オペレーションへと転化している。

長年の沈黙を経て再浮上した攻撃

2017 年から 2021 年にかけて、MongoDB ランサムウェア・キャンペーンは世界中の数多くの組織に影響を与えた。その後の数年間は公的な報告が減少していたが、最近の調査が示すのは、この脅威が消滅していなかったことだ。

2025 年の後半に、セキュリティ研究者たちが複数の地理的拠点に展開したのは、認証なしで公開される MongoDB インスタンスのハニーポット・インフラである。

開始から数日で、すべてのハニーポット・サーバは、約 $500 相当の Bitcoin を要求する身代金メモを受信し、この攻撃パターンが、現在も有効かつ自動化されていることが確認された。

この再拡大は、ペンテストでも裏付けられている。ある中小規模企業においては、侵害された 2つの MongoDB インスタンスが発見され、いずれにおいても身代金メモが発見されている。

この発見を契機に、現在の脅威ランドスケープに対する詳細な調査が実施され、安全でないデプロイ慣行が依然として広範に存在していることが明らかになった。攻撃対象となっているのは、チュートリアル／コンテナ／イメージ／インフラ／テンプレートなどである。

MongoDB ランサムウェア攻撃は、単純だが深刻な脆弱性を悪用している。すなわち、認証なしでデプロイされ、インターネットに露出したデータベースである。

悪意の自動スキャン・ツールは、ポート 27017 で待ち受け、任意の IP アドレスからの接続を受け付ける MongoDB サービスを特定する。攻撃者たちが実行するのは、4 段階の単純なプロセスである。

1. 脅威アクターたちは大規模なインターネット・スキャンにより、脆弱な MongoDB インスタンスを探索する。
2. データベース内容を自身のシステムへエクスポートまたはコピーする。
3. 被害サーバ上の、すべてのコレクションおよびデータベースを完全に消去する。
4. 48 時間以内の Bitcoin 支払いを要求する身代金メモを取り込んだ新たなコレクションを挿入し、応じなければデータが永久に失われると脅迫する。

セキュリティ専門家たちは、身代金の支払いを拒否すべきだと強く主張している。身代金を支払った被害者の多くが、見返りとして何も得られなかったと報告しているからである。多くのケースにおいて、攻撃者は窃取データのコピーを保持しておらず、支払いの有無にかかわらず復旧が不可能であった。

インターネット・スキャンにより明らかになった大規模露出

インターネット接続デバイスを検索する Shodan による分析では、20 万台を超える公開状態の MongoDB サーバが特定された。

このうち、10 万台超のインスタンスが運用情報を開示しており、3,100 台のサーバはアクセス制限や認証要件が存在しない完全な露出状態にある。

Metric	Count	Percentage
Total MongoDB servers discovered	200,000+	–
Servers with operational information	100,000+	–
Fully exposed instances (no authentication)	3,100	100%
Compromised instances (wiped with ransom)	1,416	45.6%
Servers with at least one vulnerability	95,000	46.3%

完全に露出していた 3,100 台のうちの 1,416 台 (45.6%) は、すでに侵害された状態であり、データベースは消去され身代金メモに置き換えられていた。ほぼ、すべての事例で、$ 500 相当の Bitcoin が要求されていた。

すべての攻撃で観測された Bitcoin ウォレットは 5 つのみであり、そのうち 1 つのアドレス “bc1qe2l4ffmsqfdu43d7n76hp2ksmhclt5g9krx3du” が、98% 以上の攻撃で用いられている。それが強く示唆するのは、単一の支配的な脅威アクターの存在である。

露出サーバ数と侵害済みインスタンス数の差異が、残る 1,684台の状態について新たな疑問を引き起こす。それらの一部については、テスト環境またはオフライン化されたシステムという可能性がある。その一方で、身代金を支払った結果として、侵害の痕跡が残っていないケースも考えられる。仮に、一部だけで身代金が支払われたとしても、このキャンペーンによる収益は膨大な金額に達する。

新たな脅威インテリジェンス収集により確認されたのは、MongoDB ランサム攻撃のチュートリアルがダークウェブ・フォーラムおよび Tor サイト上で流通していることである。

2025 年に発見されたチュートリアルの広告は、「この攻撃手法では技術的な専門知識が不要であり、露出したデータベースを標的にすることで、毎日安定した現金収入が得られる。数多くの企業が、MongoDB と管理インターフェイス Mongo Express を、パスワードなしでオンラインに露出させている。コピー／ペースト／クリックができれば十分だ」と主張していた。

Flare のセキュリティ研究者たちは、Docker Hub および GitHub リポジトリも分析し、認証なしでデータベースを全ネットワーク・インターフェイス ( 0.0.0.0 ) にバインドする、安全でない MongoDB コンフィグを含む、763 件のコンテナ・イメージを特定した。

これらのイメージは 30の異なるネームスペースにまたがっており、2つの広く利用されているプロジェクトでは、それぞれが 3 ヶ月間で 15,000回以上もプルされていた。この配布メカニズムにより、安全でないコンフィグが急速に拡散している。

さらに、露出した MongoDB に対する検索により、17,909 件の認証情報が得られたが、その約半数が実際に悪用できるものだった。GitHub や Docker Hub などのコード・リポジトリ／ダークウェブ・フォーラム／ペースト・サイト／侵害済みデータベース全体に、これらの認証情報は散在していた。

MITRE ATT&CK フレームワークへのマッピング

MongoDB ランサム・キャンペーンは技術的に単純なものであるが、MITRE ATT&CK フレームワークに整合する完全な攻撃ライフサイクルを示している。

Tactic	Technique ID	Technique Name	Description
Initial Access	T1190	Exploit Public-Facing Application	Connect to exposed MongoDB without authentication
Discovery	T1046	Network Service Discovery	Scan IP ranges for open MongoDB port 27017
Discovery	T1087	Account Discovery	Enumerate databases and collections
Collection	T1213	Data from Information Repositories	Dump databases to assess value
Impact	T1485	Data Destruction	Drop/wipe collections and databases
Impact	T1489	Service Disruption	Disrupt business operations
Impact	T1657	Extortion	Insert ransom note demanding Bitcoin payment

特筆すべき点として、この攻撃キャンペーンでは、特権昇格／ラテラル・ムーブメント／マルウェア展開を一切必要としない。

この攻撃者は、安全でないデフォルト・コンフィグにより付与された権限の範囲内のみで活動しており、検知が困難であると同時に、予防的対策よりも事後対応に依存せざるを得ない状況を生み出している。

この問題の原因は、データベース構築時の初期設定や配布されているテンプレートにおいて、セキュリティ機能が有効化されていないことにあります。特に、外部からの接続を制限せずに、認証なしで公開してしまうミスコンフィグが、攻撃者にとって絶好の標的となっています。Docker Hub などで共有される便利なイメージの中に、利便性を優先して、誰もがアクセス可能な設定 (0.0.0.0 へのバインド) が残っていることが、被害を広げる大きな要因です。特定の CVE 番号が割り当てられた脆弱性ではなく、不適切なデプロイ慣行 (T1190) が原因です。よろしければ、MongoDB での検索結果も、ご参照ください。