LockBit 2.0ランサムウェアのバグとデータベース復旧の試み

警察庁のサイバー警察局、サイバー特別捜査隊が暗号化されたデータからマルウェアを解析し、暗号化の復元を行うシステムを開発しました。

ランサム被害のデータ復元成功　警察庁、暗号化を強制解除

これは、NITTANの「当社サーバーへの不正アクセスに関するお知らせ（第３報）」によると、lockbit2.0 と呼ばれるランサムウェアの実行及び暗号化が防ぐことができなかった、及び警察、各システム会社及びサイバーセキュリティ専門会社の協力により、システムネットワーク及び業務の復旧をしたことから、lockbit2.0の暗号化の復元を行なったものと見られます。

なお、lockbit2.0は暗号化したMSSQLが復元できるバグがあり、現在はlockbit3.0（Lockbit Black）へ移行しております。

参考までに、Microsoft の LockBit 2.0 ransomware bugs and database recovery attemptsを抄訳致しました。

Part 2: LockBit 2.0 ransomware bugs and database recovery attempts

^{Disclaimer: The technical information contained in this article is provided for general informational and educational purposes only and is not a substitute for professional advice. Accordingly, before taking any action based upon such information, we encourage you to consult with the appropriate professionals. We do not provide any kind of guarantee of a certain outcome or result based on the information provided. Therefore, the use or reliance of any information contained in this article is solely at your own risk.}

https://techcommunity.microsoft.com/t5/microsoft-security-experts/part-2-lockbit-2-0-ransomware-bugs-and-database-recovery/ba-p/3254421

免責事項：この記事に含まれる技術情報は、一般的な情報提供と教育目的でのみ提供され、専門家のアドバイスに代わるものではありません。従って、このような情報に基づいて何らかの行動を取る前に、適切な専門家に相談されることをお勧めします。また、提供された情報に基づいて、特定の結果や成果を保証するものではありません。従って、この記事に含まれるいかなる情報の使用または依存も、ご自身の責任において実施してください。

暗号化され、破損したデータベースファイルを復元する手順

Procmonの観測によると、最初の4Kバイトしか暗号化しないはずなのに、ランダムに65Kバイトを暗号化していることが判明しました。このため、暗号化されたファイルの最初の0x1000バイトを復号化することには成功しましたが、バグにより、ランダムに散らばる領域を識別して復号化することができませんでした。

また、このファイルは顧客が提供したものであるため、ProcmonやTTDのトレースで破損を迅速に特定することができません。この問題に対処するため、暗号化されたファイルをスキャンして、ランダムに散らばる暗号化の領域を特定できるアルゴリズムを開発します。

Step1: 暗号化されたデータベース・ファイルを特定し、復号システムを自作する

ファイル中の暗号化された領域をすべて特定し、復号化によって破壊しないようにします。

暗号化されたファイルの末尾に付随するデータは、復号処理の一部として利用する復号情報です。各ファイルは、固有の16バイトの初期化ベクトルとAES256キーで暗号化されています。両者は、モディファイした Salsa20/ ChaCha で暗号化されて、各暗号化ファイルの末尾に保存されます。復号システムは、この「復号 blob」を見つけ、一意の 初期化ベクトル と AES256 キーを抽出、この情報を利用してmbedtlsライブラリを通じてAES復号を実行することです。なお、この blob には、元のファイルのサイズや AES ブロックのサイズなど、他のデータも保存されています。

復号化は0x1000 バイトのサイズのバッファに Shannon Entropy チェックを追加することで、これをベースにします。非常に高いレベル（>= 7.8）を持つバッファはすべて復号化され、さらにページヘッダの構成に基づいて復号化されたデータを検証します。

.ndfファイルが構造化されており、すべての0x2000バイトが常に保証された形式に準拠することを利用して、このアルゴリズムを実行し、ファイル内のすべての暗号化領域を特定し、それを正常に復号化することができます。但し、.ndfファイル形式には圧縮データが含まれており、Entropy スキャンでフラグを立てることができるため、復号化後にさらなる検証を行う必要があります。

Step2: Step1の出力を処理し、ページヘッダーのアライメントがずれている場合はその分を考慮する

ファイルの復号に成功したところで、ヘッダーのアライメントがずれていないかどうかを確認する必要があります。先に、ページヘッダー内のPageIndexフィールドを比較することでこの方法を確認しました。これは、この特定のページが.ndfファイル内のどこにあるべきかを識別するためのインデックス値です。

暗号化された領域を見つけた方法と同様に、それぞれのページヘッダーを検証する同じ方法（ Shannon Entropyを除く）で進み、アライメントのずれがある場合は、新しいファイルを作成して挿入します。すでに有効な既存のデータもすべて新しいファイルにコピーします。この新しいファイルは完全に復号化され、正しくアライメントされることが重要です。

Step3: Step2の出力を処理し、ずれたヘッダーから残ったデータを「クリーンアップ」する

アライメントがずれている場所には、まだデータが残っているため「ダミー」のヘッダーを配置し、残っているデータについては、単にそのページ全体をNULLにして、NULL/EMPYページとします。この方法ではデータは失われますが、データベースファイル全体の容量に比べると僅かなため妥協します。

上記の3つのステップを組み合わせることで、MSSQLデータベースファイルを可能な限り復元し機能を正常に戻すことができます。