攻撃者 OneDrive にファイル転送 — フィーチャ社ランサム被害が示す「クラウド外向き」の盲点 #

機械設計受託のフィーチャ社が 2026 年 5 月、約 10 か月前から潜伏していたランサムウェア攻撃の調査結果を公表した。被害そのものは中規模にとどまるが、注目すべきは流出経路だ。攻撃者は侵入後、ファイル転送ツール経由で 自分たちが管理する OneDrive にデータを送信 していた。S3 でも自前 C2 でもなく、最も普及している企業向けクラウドストレージを「持ち出し先」にしたのである。

「正規サービスをエクスフィル先に使う」が標準化している #

最初の侵入痕跡は 2025 年 7 月 9 日。ファイアウォール越しに入られ、原因特定に至るログは攻撃者によって暗号化されていた。最終的に不正アクセスは 32 台、ランサムウェア感染は 13 台、流出した GitHub リポジトリは 144 個に及ぶ。社外秘ソースコードを丸ごと持っていかれた格好だ。

強調したいのは、攻撃者が独自インフラを立てずに Microsoft 365 のサービスを使ったという事実である。これは LotL (Living off the Land) を外向き通信にまで広げた、ここ数年の明確なトレンドだ。理由は単純で、

• 企業プロキシは *.live.com / *.sharepoint.com を遮断しづらい (業務影響が大きすぎる)
• TLS で暗号化されており、ペイロード検査は事実上できない
• 受信側は怪しい IP ではなく Microsoft の正規 IP — レピュテーション・ベースの遮断が効かない

Dropbox・Mega・Google Drive を使う事例も含めれば、近年のランサム前段階のエクスフィルでは正規クラウドが主役になりつつある。「ファイル転送ツール」と曖昧に記載された部分も、十中八九 rclone や同種のオープンソース CLI である可能性が高い。

「外向き」を疑える検知に変えられるか #

10 か月気づかれなかった事実が示すのは、検知が 「入ってくる異常」 には強くても 「正規プロトコルで正規サービスへ出ていく異常」 に弱いという構造的弱点だ。EDR・SOC 強化だけでは本質的に解決しない。

効くのは、外向きトラフィック量を学習し、特定端末から OneDrive への急増 (例: 1 GB/時) を異常として上げる DLP / UEBA の閾値アラート。コードを扱う企業なら、CASB で社外テナントの OneDrive 接続そのものを遮断するのが筋だ。

ソースコード 144 リポジトリ流出は、防御側にとっては「依存関係の脆弱性 + 内部 API キー + 攻撃面の全貌」を相手に渡したに等しい。被害公表でほっとするのではなく、当該コードを使った二次攻撃を前提に、埋め込みクレデンシャルのローテーションを終わらせる ところまでが対応の最低ラインになる。