フィーチャへのランサムウェア攻撃、ファイル転送ツールでOneDriveにデータ送信
OneDriveへデータ送信。フィーチャのランサムウェア被害が示す「盗まれる被害」の深刻さ
ランサムウェア被害というと、多くの人は「ファイルが暗号化されて使えなくなる攻撃」を思い浮かべるかもしれません。
しかし近年のランサムウェアは、単にデータを暗号化するだけではありません。攻撃者が社内データを外部へ持ち出し、その公開をちらつかせることで、被害企業にさらに強い圧力をかけるケースが増えています。
自動車向け画像認識ソフトウェアなどを手がけるフィーチャ株式会社は、同社サーバに対するランサムウェア被害について最終報を発表しました。
今回の事案では、サーバ内の一部ファイルが暗号化されただけでなく、攻撃者がファイル転送ツールを使い、データを攻撃者管理のクラウドストレージであるOneDriveへ送信していたことも確認されています。
つまり、今回の被害は「使えなくされた」だけでなく、「外部へ持ち出された可能性がある」点が大きな問題です。
32台で不正アクセスを確認、13台がランサムウェアに感染
調査結果によると、不正アクセスが確認されたサーバなどは合計32台にのぼり、そのうち13台がランサムウェアに感染していたとされています。
これは、一部の端末だけで完結する小さなトラブルではありません。複数のサーバに影響が及んでいたことから、社内ネットワーク内で広く調査しなければならない事案だったことが分かります。
ランサムウェア被害では、暗号化されたファイルだけを見ていては全体像をつかめません。
どのサーバに侵入されたのか。どの端末が感染したのか。攻撃者がどこまで移動したのか。どのデータにアクセスしたのか。外部へ送信された可能性はあるのか。
こうした確認を一つずつ進める必要があります。
今回のように複数台のサーバが関係する場合、復旧作業は単にバックアップを戻すだけでは終わりません。再侵入を防ぐためには、侵入経路、被害範囲、認証情報の安全性、ログの状態まで確認する必要があります。
ファイル転送ツールとOneDriveが悪用された意味
今回の事案で特に注目されるのは、攻撃者がファイル転送ツールを用いて、攻撃者管理のOneDriveへデータを送信していた点です。
OneDriveは、多くの企業や個人が日常的に使っている正規のクラウドストレージサービスです。業務で使われることも多く、通信先として見慣れているため、異常に気づきにくい場合があります。
攻撃者がこのような正規サービスを悪用すると、単純に「怪しい通信先を止める」という対策だけでは見逃してしまう可能性があります。
また、ファイル転送ツールも本来は業務に使われる正規の道具です。大容量ファイルの移動、バックアップ、サーバ間のデータ転送など、日常業務で使われることがあります。
しかし、攻撃者が社内に侵入した後、その道具を悪用すれば、社内データを外部へまとめて送信する手段にもなります。
この事例は、攻撃者が必ずしも特殊な道具だけを使うわけではなく、普段の業務で使われるサービスやツールを悪用することがあるという現実を示しています。
GitHubリポジトリ144個の外部コピーも確認
今回の調査では、同社のGitHubサーバから144個のGitHubリポジトリが外部にコピーされたことも確認されています。
GitHubリポジトリには、ソースコードや開発に関する情報が含まれることがあります。企業にとっては、製品やサービスの設計思想、開発履歴、内部の仕組みにつながる重要な資産です。
もちろん、リポジトリの中身によって影響の大きさは異なります。しかし、外部へコピーされた可能性がある場合、単なるファイル流出とは別の観点で確認が必要になります。
ソースコードの中に認証情報や接続情報が含まれていないか。外部サービスのキーや設定情報が残っていないか。非公開の技術情報が含まれていないか。攻撃者がそれを悪用して、別のシステムへ侵入できる可能性はないか。
開発資産の流出は、現在の被害だけでなく、将来の攻撃リスクにもつながる場合があります。
最初の痕跡は2025年7月。発覚までの時間差が示す怖さ
同社の調査では、本件における最初の痕跡は2025年7月9日に確認された、ファイアウォールを介した同社サーバへの不正アクセスだったとされています。
一方で、ランサムウェア被害が判明したのは2026年2月9日です。
この時間差は、サイバー攻撃の怖さをよく表しています。
攻撃者は、侵入してすぐに目立つ行動を取るとは限りません。内部を調べ、重要なサーバやデータを探し、権限を広げ、情報を集めたうえで、最後にランサムウェアを実行することがあります。
そのため、暗号化が始まった時点は「攻撃の始まり」ではなく、「攻撃が表面化したタイミング」にすぎない場合があります。
被害に気づいたときには、すでに長い期間、攻撃者が内部にいた可能性がある。この前提で調査しなければ、本当の被害範囲を見落とすおそれがあります。
ログが消されると、全容の特定は難しくなる
今回、具体的な不正アクセスの原因や手法については、関連ログがランサムウェアで暗号化されていたことなどから、特定には至っていないとされています。
これは、多くの企業にとって重要な教訓です。
サイバー攻撃の調査では、ログが非常に重要になります。誰が、いつ、どこから、どのサーバへアクセスしたのか。どのファイルが操作されたのか。どの通信が発生したのか。これらを確認するためには、ログが残っている必要があります。
しかし、攻撃者がログを消したり、ランサムウェアによってログ自体が暗号化されたりすると、後から全容を調べることが難しくなります。
そのため、ログは単に保存しておくだけでなく、攻撃を受けたサーバとは別の場所にも保管する、改ざんされにくい形で保存する、一定期間さかのぼって確認できるようにする、といった工夫が必要になります。
外部公開とダークウェブ監視が必要になる理由
フィーチャでは現在、通常業務を再開しており、外部公開状況の確認とダークウェブ監視を含む継続的なモニタリングを実施しているとされています。
ランサムウェア被害では、復旧後も警戒が必要です。
持ち出された可能性のある情報が、外部のフォーラムや不正なデータ流通サイトに掲載されることがあります。攻撃者や第三者が、後から別の場所で情報を公開する可能性もあります。
そのため、被害企業は「サーバが復旧したから終わり」とは考えられません。
外部に情報が出ていないか。関係者に影響が出ていないか。第三者がデータを悪用していないか。公開されたリンクやファイルがないか。こうした監視を続ける必要があります。
復旧はゴールではなく、被害拡大を防ぐための継続対応の始まりでもあります。
企業が学ぶべきポイント
今回の事案から、多くの企業が学べることがあります。
まず、ランサムウェア対策では、暗号化への備えだけでなく、情報持ち出しへの備えも必要です。
重要データがどこにあるのか。誰がアクセスできるのか。外部への大容量送信を検知できるのか。正規のクラウドサービスへの不自然な通信を見つけられるのか。
こうした観点が欠かせません。
次に、開発環境やソースコード管理も守るべき重要資産として扱う必要があります。
GitHubなどのリポジトリには、企業の技術情報や内部構造が含まれる場合があります。そこに認証情報が残っていれば、被害がさらに広がる可能性もあります。
最後に、ログの保全です。
攻撃後に原因を調べるには、ログが必要です。ログが消されていたり暗号化されていたりすると、侵入経路や被害範囲の特定が難しくなります。
日ごろから、ログを安全な場所に保存し、異常を早く検知できる体制を整えておくことが重要です。
まとめ
フィーチャへのランサムウェア攻撃では、複数のサーバに不正アクセスが確認され、一部サーバがランサムウェアに感染しました。さらに、ファイル転送ツールを使って攻撃者管理のOneDriveへデータが送信され、GitHubリポジトリ144個が外部にコピーされたことも確認されています。
この事案が示しているのは、ランサムウェア被害が「ファイルを暗号化される攻撃」だけでは済まないということです。
データが持ち出される。開発資産がコピーされる。ログが暗号化され、原因の特定が難しくなる。外部フォーラムやダークウェブ上で情報が公開されていないか、復旧後も監視が必要になる。
こうした被害は、会社の信用、取引先との関係、将来のセキュリティリスクにまで影響します。
ランサムウェア対策では、バックアップだけでなく、外部送信の監視、開発資産の管理、ログ保全、復旧後の継続監視まで含めて考える必要があります。
今回の事例は、正規の業務ツールやクラウドサービスが攻撃に悪用される時代に、企業がどこまで備えられるかを問いかけています。
