re-ransomware

ランサムウェア分析（暗号化の識別／身代金要求メッセージ／復号・復旧）

使用する場合／使用しない場合

• 使用する：被害者のファイルが暗号化されている（拡張子の変化、ファイルヘッダーの破損、エントロピーの上昇）、または身代金要求メッセージ（README/DECRYPT）が見つかったサンプル
• 使用する：「復旧できるか」を判断し、復号・復旧の手順（鍵の抽出 → 復号スクリプト／コミュニティの復号ツール）を提示する必要がある場合
• 使用する：ランサムウェアサンプルの暗号化アルゴリズム、鍵管理、C2 とのやり取りを再現する場合
• 使用しない：サンプルがランサムウェアだとまだ確認できていない場合（まず [[re-triage]] で初期調査し、[[re-behavior]] で挙動を確認してください）
• 使用しない：暗号化アルゴリズムそのものだけを分析する場合（直接 [[re-crypto-id]] / [[re-crypto-keys]] を使用してください）
• 注意：サンプルを実行すると、実際にファイルが暗号化されます。必ずサンドボックスのスナップショット内で実行してください（[[re-sandbox]] が必須の前提条件、[[re-analyze/platform-tips]] の最優先原則）。静的分析ではサンドボックスは不要です

ツールの準備

すべてのツールは使用前に動作を確認してください。暗号化分析の三点セットとサンドボックスの完全なインストール方法は各スキルを参照してください。このスキルではそれらを再利用します。このスキル固有のツールはファイルシステムのスナップショットツールです（サンプルによる暗号化で分析環境が破壊されるのを防ぎます。落とし穴 1）。

暗号化分析の三点セット（crypto ドメインを再利用）

• [[re-crypto-id]]：アルゴリズムの識別（定数テーブルのフィンガープリント、独自の暗号化）
• [[re-crypto-keys]]：鍵の抽出（ハードコード／メモリ／リソース）
• [[re-crypto-decrypt]]：復号スクリプト（pycryptodome のインストール方法は該当スキルを参照）
• 確認：python3 -c "from Crypto.Cipher import AES; print('ok')"（[[re-crypto-decrypt]] を参照）

サンドボックス環境（実行前の必須条件）

• [[re-sandbox]]：VM スナップショット + ネットワーク分離（INetSim / fake DNS）。ランサムウェアサンプルの動的分析では、既定で VM スナップショットを使用します（暗号化の挙動は破壊的です）
• 確認：スナップショットは VBoxManage snapshot <vm> list に clean があること、ネットワークは ping 8.8.8.8 が通らないこと

ファイルシステムのスナップショットツール（暗号化前の状態を保存）

• Linux：btrfs スナップショットの snapper——Debian/Ubuntu では apt install snapper、Fedora では dnf install snapper、Arch では pacman -S snapper。確認：snapper --version。btrfs 以外では tar/rsync（標準搭載）で監視対象のディレクトリをバックアップします
• Windows：ボリュームシャドウコピーの vssadmin（システム標準搭載）——vssadmin list shadows で確認します。スナップショットは復号・復旧手段のひとつでもあります（手順 5）
• macOS：Time Machine の tmutil（標準搭載）——tmutil listbackups で確認します
• ハッシュ／列挙：sha256sum / find（coreutils 標準搭載）

ファミリーの識別と復号ツールの調査（オンライン、インストール不要）

• ID Ransomware（id-ransomware.malwarehunterteam.com）：身代金要求メッセージ／暗号化されたファイルのヘッダーをアップロードしてファミリーを識別します
• No More Ransom（nomoreransom.org）：公式復号ツールの一覧（落とし穴 4 の時効性に注意）
• [[re-ti]]：サンプルのハッシュを VT / コミュニティレポートで調べ、ファミリーと既存の分析結果を確認します

操作手順

順番に実行し、各手順の証拠（パス + sha256）を記録してください（[[re-triage]] を参照）。静的分析を優先します（[[re-analyze/platform-tips]] の静的分析優先原則）。まずホストマシンで 1～2 を行い、実行が必要な場合にのみサンドボックスに移します。

1. 初期判断（拡張子の変化／暗号化ヘッダーの特徴／身代金要求メッセージ）：

   sha256sum sample.exe 被加密文件            # 存证（[[re-triage]]）
   file 被加密文件                            # 文件头是否被改写/替换
   xxd -l 64 被加密文件                       # 头部特征：固定前缀=感染 ID/密钥块，尾部特征同理
   find / -xdev -iname "*README*" -o -iname "*DECRYPT*" -o -iname "*RECOVER*" 2>/dev/null
   find . -type f -mmin -60 -size +1k | head  # 加密时间窗内被改动的文件
   

   • 判定の手掛かり：拡張子が一括で変化する（.crypt/.locker/.encrypted）、元ファイルが削除／上書きされている、ディレクトリに身代金要求メッセージがある、デスクトップの壁紙が変更されている
   • まず被害者のファイル全体のハッシュ／ディレクトリ一覧を保存します（スナップショットと相互にバックアップとして機能します）

2. 暗号化アルゴリズムの識別（crypto ドメインを使用）：

   • サンプルの静的分析：[[re-crypto-id]]——定数テーブルのフィンガープリント（AES S-box / RSA 公開鍵 DER / CRC テーブル）、XOR/ROL/ROR 変換、ハイブリッド暗号化の有無（AES key を RSA でラップする方式が最も一般的）
   • 暗号文の観察：固定されたヘッダー／末尾ブロック（感染 ID、鍵ブロック）、暗号文の長さのアラインメント（AES ブロック長 16）、エントロピー（>7.0 → 暗号化／圧縮／高ランダム性の候補。ファイルヘッダーとコンテキストも併せて根拠を確認してください。高エントロピーだけでは暗号化と判定できません）
   • 次の 3 つから判定します：対称暗号（ファイル全体を AES で暗号化）→ 対称鍵を探す、非対称暗号（RSA で直接暗号化）→ ほぼ復旧不可能、ハイブリッド暗号（AES key を RSA で暗号化）→ 鍵ブロックがファイルとともに保存されている場合は手順 3 を確認
   • 結論（アルゴリズムの仮説 + 証拠）を手順 3/5 に引き継ぎます

3. 鍵管理の再現（ローカル／ネットワーク／C2 による配布）：

   • ローカル：[[re-crypto-keys]] で静的分析を優先（strings/ハードコードされた値／リソース／インポートテーブル）→ 見つからなければメモリを調べます（[[re-memdump]] は既定で gcore によるダンプ。ダンプのタイミングは暗号化ループの実行中、鍵が派生済みで破棄される前です）
   • ネットワーク／C2 による配布：サンドボックス内で [[re-sandbox]]（INetSim/fake DNS）+ [[re-netcap]] でパケットをキャプチャし、[[re-protocol]] で再構築します——鍵は実行時にのみ C2 から配布される場合があり、静的分析では取得できません
   • ハイブリッド方式：サンプル内に RSA 公開鍵が含まれ、AES key が暗号化されてファイルヘッダーに書き込まれている場合 → 秘密鍵がなければ復旧できません（正直に伝えてください。[[re-crypto-keys]] の落とし穴を参照）
   • 候補となる各鍵について、その出所の証拠（オフセット／関数名／ダンプのパス）を記録し、[[re-crypto-decrypt]] で使用します

4. 身代金要求メッセージと C2 とのやり取り（[[re-protocol]] を使用）：

   • 身代金要求メッセージを確認：メールアドレス / URL（Tor/ダークウェブ）/ BTC アドレス / 感染 ID を抽出し、IOC に記録します（[[re-ioc]]）
   • C2 とのやり取り：[[re-protocol]] で一連の分析を行います——[[re-netcap]] でパケットをキャプチャ → [[re-crypto-id]] で暗号文を判定 → [[re-crypto-keys]] で鍵を取得 → [[re-crypto-decrypt]] で通信を復号 → [[re-proto-rev]] でやり取りを再構築（鍵のアップロード／状態報告／感染 ID の登録）
   • 特に確認する点：暗号化前にデータがアップロードされていないか（二重恐喝、落とし穴 2）、鍵が C2 に送信されているか

5. 復旧方法（鍵の抽出 → 復号スクリプト、鍵がない場合 → コミュニティツール）：

   • 鍵がある場合：[[re-crypto-decrypt]] で一括復号スクリプトを作成します（アルゴリズム／モード／IV は [[re-crypto-id]] の結論に従って再現）→ まず小さなサンプルで平文を確認 → 全体を処理
   • 部分暗号化／ヘッダー暗号化：数 KB のヘッダー、または一部ブロックのみ暗号化されている場合 → ヘッダーを削除／ファイルヘッダーを再構築するだけで、大半のファイルを復旧できる可能性があります（まず暗号文の長さが元の長さと同じか確認してください。最も手軽な方法です）
   • 鍵がない場合：ID Ransomware でファミリーを識別 → No More Ransom / ベンダーの復号ツール（必ず対象の亜種と一致させてください。落とし穴 4）→ 利用できるツールがなければ「現時点では復旧不可能」と正直に報告します
   • スナップショット／バックアップからの復旧を優先：vssadmin / snapper / Time Machine でロールバックします（サンプルが先にボリュームシャドウコピーを削除している場合があるため、削除されていないか確認してください）
   • 成果物：復旧可能性の結論 + 復号スクリプト + 証拠チェーン（[[re-ioc]] のレポート構成）

分野横断の連携

• [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]]：それぞれ手順 2/3/5 で参照し、暗号化の識別→鍵→復号の主な流れを構成します
• [[re-sandbox]] / [[re-behavior]]：動的分析の必須前提条件（[[re-analyze/platform-tips]] の最優先原則）と、暗号化／外部送信の挙動の観察
• [[re-protocol]]：身代金要求メッセージの背後にある C2 とのやり取り（netcap / crypto-* / proto-rev）、手順 4
• [[re-ti]]：サンプルのハッシュ／ファミリーの識別（VT、ID Ransomware）
• [[re-ioc]]：身代金要求メッセージのメールアドレス／URL／ウォレットアドレス、鍵と暗号文のフィンガープリントを IOC として出力します
• [[re-malware]]：このスキルは re-malware ゲートウェイから参照されます（ランサムウェアサンプルの分岐）。挙動分析／レポートはゲートウェイの全手順に従います
• [[re-analyze/platform-tips]] の関連分岐：既定ではサンドボックスを使用（暗号化の挙動は破壊的）、静的分析を優先、プラットフォーム別の分岐（Linux では snapper、Windows では vssadmin を使用）

常见坑与陷阱

• 样本在沙箱内加密所有文件：现象——样本一跑，沙箱里全盘文件被加密，包括样本自身与行为日志，取证产物被毁；原因——未做文件系统快照/蜜罐隔离就运行，或分析完没恢复快照；对策——[[re-sandbox]] 快照 + 蜜罐文件夹（放假文档/假密钥，观察加密目标选择）+ 只读传入样本，分析完立即恢复快照（坑清单见 [[re-sandbox]]）；原始样本与密文副本在宿主机独立备份
• 双重勒索（数据泄露 + 加密）：现象——勒索信同时威胁"加密文件 + 公开泄露数据"，只盯加密会漏掉外传阶段；原因——双重勒索模式：先窃取数据（C2 上传）再加密，赎金诉求双份；对策——[[re-behavior]] / [[re-netcap]] 优先观察网络外传（泄露影响面大于加密），分两阶段记录行为与 IOC，报告分开陈述
• RaaS 变体差异：现象——同家族不同样本加密扩展名/算法/密钥方案都不一样，套用家族通用结论出错；原因——RaaS（勒索软件即服务）向攻击者出租可定制变体，每租户可配置；对策——以手头样本实测为准（[[re-crypto-id]] 重新确认），记录样本级特征（样本哈希/密钥块指纹）而非家族级结论
• 解密工具时效性：现象——No More Ransom 解密器报"不是此变体"或解出乱码；原因——解密器只覆盖特定变体/旧版本，新变体算法或密钥方案已变；对策——先用 ID Ransomware + 样本哈希精确匹配变体再选工具；失效就走密钥提取路线（步骤 3/5）或诚实报告不可恢复；工具随 C2 密钥泄漏更新，可定期复查