これは、実際に自分が godransom というデータベースマルウェア（ランサム系）に感染した体験談です。
同じように「テスト用だから大丈夫」「一時的に公開しているだけ」と思っている人の参考になれば幸いです。
環境構成
まずは当時の環境です。
- データベース：MySQL 5.x
- 用途：アプリケーションのテスト用DB
- 接続形態：外部公開（インターネットから接続可能）
- 認証：ID / パスワード方式
- FW制限：最低限（IP制限なし）
「テスト用だから」「一時的だから」という油断がありました。
異変に気づいたきっかけ
異変に気づいたのは、プログラムの動作テストを行ったときでした。
アプリケーションを起動すると、
テーブルが存在しません
table does not exist
というエラーが発生。
最初は、
- マイグレーション忘れ？
- 接続先DBを間違えた？
- ローカルと環境が違う？
と疑いました。
データベースを確認して絶句
MySQLに直接ログインして確認すると、
- 全テーブルが削除されている
- 見慣れないテーブル名が1つだけ存在
そのテーブルを確認すると、
身代金要求メッセージ（ランサムノート） が格納されていました。
ここで初めて、
「あ、やられたな」
と理解しました。
godransom とは何か
godransom は、
- MySQL / MariaDB などを狙う
- テーブルを全削除
- 代わりにランサムノート用テーブルを作成
- 仮想通貨での支払いを要求
という DB特化型ランサムマルウェア です。
特徴
- 暗号化ではなく 削除
- バックアップがなければ復旧不能
- テストDB・公開DBが特に狙われやすい
感染したのは「テスト用DB」だけだった
幸いだった点として、
- 本番DBは 非公開
- 内部ネットワーク限定
- IP制限あり
だったため、
感染したのは外部公開していたテスト用DBのみ でした。
それでも精神的ダメージは大きかったです。
推定される感染経路
ログや構成を確認した結果、
独自ブログのインジェクション が原因と考えています。
状況
- 自作ブログ
- 入力値チェックが甘い箇所が存在
- SQLインジェクション対策が不十分
- 同じDBサーバーにテスト用DBが存在
👉
Webアプリ → DB侵入 → 全DBスキャン → テストDB破壊
という流れだった可能性が高いです。
なぜ侵入を許したのか（反省点）
完全に自分のミスです。
- テスト用DBを外部公開していた
- IP制限をしていなかった
- 権限の強いユーザーを使っていた
- バックアップがなかった
- 「どうせテスト用」という油断
攻撃者にとってはテストも本番も関係ない ということを痛感しました。
被害状況まとめ
- テーブル：全削除
- データ：完全消失
- 復旧：不可（バックアップなし）
- 身代金：支払っていない
テストデータとはいえ、
検証用に作ったデータ・スキーマが全滅 したのは痛かったです。
取った対策（再発防止）
以降、以下を徹底しました。
DB周り
- 外部公開DBは原則禁止
- 必ずIP制限
- 権限は最小限
- 定期バックアップ（自動）
Webアプリ
- プリペアドステート必須
- 入力値検証の見直し
- ログ監視の強化
意識面
- 「テスト用だから安全」は幻想
- 公開した時点で全世界に晒されている
同じ構成の人へ伝えたいこと
- テスト用DBほど狙われる
- 外部公開 = 攻撃対象
- バックアップは最後の砦
- SQLインジェクションは今でも現役
godransom は他人事ではありません。
まとめ
- MySQLの外部公開DBが godransom に感染
- 気づいたきっかけは「テーブルが無い」というエラー
- 感染経路は自作ブログのインジェクション
- テスト用DBでも被害は現実的
- バックアップと制限は絶対必要
この記事が、
誰かの「同じ失敗」を防げたら幸いです。