VMDK Data Recovery After an Akira Ransomware Attack

12台すべてのドライブは、到着から24時間以内にイメージ化され、その後のすべての作業は、それらのイメージに対して実施されました。元のメディアは、分析が進む間も一貫して受領時の状態のまま保たれ、証拠としての状態が保全されました。

約120TBものデータを、イメージ1件ずつスキャンしていく方法は現実的ではありませんでした。エンジニアたちは、作業をテラバイト単位の範囲に分割し、10件のスキャンを同時に実行することで、ハードウェア自体の限界までスループットを引き上げました。その後、2台目のシステム上で2セット目のイメージが構築され、両方のマシンで抽出作業を同時並行して進められるようになりました。

データが削除されていく過程で、BTRFSは、保存されたデータをその物理的な場所に対応づける層を消去し始めていました。このマップのうち約7TB分が影響を受け、本来なら読み取り可能なはずのストレージから使用不可能な出力が生じていました。エンジニアたちは、影響を受けた領域が削除前は連続して割り当てられていたことを突き止め、これにより手動での再構築が可能になりました。マップを手作業で再構築することで、ファイルシステムがすでに解放していた約5TB分のバックアップデータへのアクセスが復旧しました。

破損したVMDKファイルは、単純に読み取れる、読み取れないという二択であることは滅多にありません。エンジニアは、暗号化された領域、破損した領域、部分的に上書きされた領域、構造的に損傷した領域を、無傷の領域から切り分けました。最優先度の3台の仮想マシンには、それぞれ5個または6個の復元ポイントがあり、最新のものは攻撃直前に取得されていたもので、合計35個のVMDKファイルが対象となりました。損傷は、それらの各ファイルの3~5%に影響を及ぼしていました。3台のうち1台については、暗号化プログラムが仮想ディスクファイルにまったく到達していませんでした。

バックアップデータだけではデータセットを網羅できない箇所については、エンジニアは本番環境の仮想ディスクの未暗号化領域を統合しました。このアプローチは有効でしたが、慎重を要するものでした。優先度の高い3台のマシンのうち2台には、スナップショットファイルも存在していました。スナップショットファイルは、それが表すデータとの間に一対一の関係を持ちません。スナップショットファイルとそれが表すデータとを対応づける構造は、暗号化された領域内に存在していました。そのため、本番環境の仮想ディスクを使ってギャップを埋めると、古いデータが混入し、後から追跡が困難な破損を引き起こす可能性がありました。エンジニアは、デフォルトで統合を行うのではなく、データセットごとにリスクを評価しました。

DriveSaversは、インシデント対応企業および顧客と連携し、ディスクをどの環境にインポートするかを事前に取り決めました。抽出されたファイルレベルのデータは、まずネットワーク経由で返送され、これにより顧客は残りの作業が進行している間も特定のファイルにアクセスできるようになりました。その後、再インポートに適した完全なVMDKファイルが提供されました。