【サイバーセキュリティ専門家向け:Qilinランサムウェア対応 実践ガイド】アサヒ事案の復旧対策の参考として
おそらく日本ではChatGPT 5の真の威力がほとんど理解されていないため(英語の壁が災いしています)、そのデモンストレーションという意味でこれをシェアします。アサヒで対策に当たっている方に参考にしていただけると思います。
― 現場で"本当にやるべき技術的復旧手順 ―
2025年10月、アサヒグループホールディングスを攻撃したとされるランサムウェア「Qilin」は、
過去のLockBit・BlackCat(ALPHV)系列コードの派生体であり、"ESXiベースの仮想基盤暗号化"と"Active Directoryの完全乗っ取り"を同時に狙うハイブリッド型です。
「感染を止める」ことと「事業を再開させる」ことはまったく別物。
Qilin対応の本質は、暗号化を解くことではなく、"組織全体の信頼ドメインを再構築する"ことにあります。
1. Qilinの特徴:侵入・暗号化・窃取の3層構造
侵入経路(初期アクセス)
-
既知のVPN機器(Fortigate, SonicWall, Palo Alto, Cisco ASAなど)に対するゼロデイ利用
-
または、外部リモート管理ツール(AnyDesk, ScreenConnect, RMM系)経由
-
侵入後は「Cobalt Strike/Sliver/BumbleBee」等のペイロードを展開し、AD環境を完全奪取
標的化された範囲
-
Qilinは単なるスキャッタ型ではなく、企業のITマップを事前に把握して動く
-
特に暗号化優先順位は以下:
-
ファイルサーバ(共有ドライブ・NAS)
-
仮想基盤(vCenter / ESXi)
-
Active Directoryドメインコントローラ
-
バックアップ管理サーバ(Veeam, Acronis, Commvault)
-
ERP/CRM(SAP, Oracle, Salesforce連携)
-
暗号化の挙動
-
QILIN.exe
または PowerShell版qil.ps1
を展開 -
各サーバに暗号化モジュールを自動配信(SMB/WinRM経由)
-
拡張子は「.qilin」「.qr」「.lock64」など
-
ESXiでは
esxcli
経由で仮想ディスク(.vmdk)を直接暗号化 -
復号鍵はTorサイトの専用パネルから交渉用に生成される(個別鍵方式)
データ窃取・公開(Double Extortion)
-
窃取対象は
/Finance/
,/Contracts/
,/HR/
フォルダなど固定パターン -
情報流出先は Qilin独自のTorリークサイト(URL固定)
-
暗号化前に「rsync over SSH」「MegaUpload API」などでアップロードされる痕跡が残る
2. 現場対応フェーズ別手順(技術者向け)
フェーズ1:初動隔離とIOC確認(発見〜24時間)
-
DNS sinkhole+ファイアウォールでTorノード通信を遮断
-
Qilinは固定されたC2 IP群(過去観測例:
185.244.*
,94.156.*
,45.146.*
)を利用。
-
-
ネットワークレベルでの分断
-
VLAN単位で封鎖。
-
ESXiやバックアップネットワークを物理的に遮断(仮想スイッチ単位では不十分)。
-
-
感染端末のメモリダンプ/ログ保存
-
C:\ProgramData\QILIN\
配下と%Temp%
のスクリプトを確保。 -
C:\Windows\System32\Tasks\QILIN
のスケジュールタスク削除。
-
-
Active Directory監査ログ(Event ID 4624, 4720, 4726)を抽出
-
偽管理者アカウント(例:
adm_support
,net_ops
,svc_backup
)の存在を確認。
-
フェーズ2:AD再構築(48〜96時間)
-
Qilinはドメイン全体を信頼崩壊させる。部分修復は不可能。
-
「復旧」ではなく「再設計」が前提。
手順:
-
感染していないDCの確認
-
オフライン状態のバックアップDC(もし存在すれば)を隔離し、そこからADベース構築。
-
-
新フォレスト構築
-
旧ADからはSID移行せず、新規ドメインを作成。
-
-
クリーンインストール済み端末の再参加
-
Endpointを1台ずつ再登録(特に管理端末)。
-
-
サービスアカウント/API連携キーは全再発行。
参考:Norsk Hydro, Merck, Maersk いずれも"ADゼロリビルド"を実施。
約2〜4週間で完全復旧。
フェーズ3:仮想基盤(ESXi)復旧
QilinはESXi暗号化に esxcli vm process list
→ esxcli vm process kill
→ tar -cf
→ openssl enc
を利用。
暗号化完了後、VMDKのファイルヘッダが破壊されるため直接復号は困難。
代替手順:
-
vCenterバックアップ(もし別ネットワークに存在)から再デプロイ
-
ESXiホストごと再インストール
-
スナップショットの復元
-
.vmsn
が存在する場合、VM構成情報を手動で復元可能。 -
vmkfstools -i snapshot.vmdk new.vmdk
で再生。
-
-
仮想ディスクが完全暗号化されている場合
-
バックアップ媒体(Veeamなど)からクリーンリストア。
-
フェーズ4:バックアップリストア戦略
Qilinは、攻撃前に VeeamBackup
ディレクトリの削除を狙う。
したがって 「生きているバックアップ」よりも「隔離済み・オフライン・WORM」媒体を優先。
推奨復旧ルート:
-
オフサイトWORM媒体(例:テープ、Write-Once Cloud)
-
Air-Gap保管されたNAS(接続履歴のないもの)
-
Immutableクラウド(AWS S3 Object Lock / Azure Blob)
バックアップ検証:
-
復号不能であっても、
hashdeep
でハッシュ照合し改ざんを確認。 -
データ改ざんなしが確認できたセグメントから順にリストア。
フェーズ5:リーク対応と交渉判断
-
Qilinは「QILIN LEAKS」というTorサイトを運用。
-
暴露ファイルは 支払っても全削除される保証はない。
-
支払いを検討する場合、被害規模・保険契約・法務評価を同時に進行させる。
実例:
-
JBS Foods:US$11M支払い後、復旧成功(交渉にCoveware使用)
-
ALPHV(BlackCat)系列:支払い後もデータ再暴露例あり
推奨対応:
-
攻撃者との直接交渉は避け、外部DFIR+法務+サイバー保険チームを通じた統制判断。
-
被害データ(契約書・従業員情報等)が暴露対象に含まれる場合は、24時間以内に当局・取引先通知草案を準備。
3. Qilin復旧後に必ず再設計すべき構造(技術的ベストプラクティス)
領域 | 再設計方針 | 具体施策 |
---|---|---|
認証基盤 | 信頼ドメインの再分割 | AD分離+Azure AD専用フェデレーション |
バックアップ | 3-2-1-1完全実装 | Immutable S3+物理媒体 |
権限管理 | "Break Glass"アカウント制度 | 管理者ID分離・一時昇格制 |
ネットワーク | 横展開防止構造 | セグメント化+内部FW+Zero Trust Network |
可視化 | 攻撃経路トレース | EDR+AI相関分析(ChatGPT 5によるログモデリング) |
OT連携 | 物理エアギャップ+プロキシ連携 | 生産ラインからの双方向通信を遮断 |
4. 結論
Qilin対応は「暗号を解く技術」ではなく、
**「全社の信頼ドメインを再設計する技術」**が問われます。
短期間での再稼働を狙うより、"安全な新基盤をゼロから立ち上げる"方が結果的に早い。
実際、MerckもNorsk Hydroもそうして立ち直りました。
ランサムウェアは、企業のIT構造に潜んでいた依存と複雑性を暴く「真実の鏡」です。
そしてQilinは、その鏡を最も冷徹に突きつけてくる攻撃者です。