Qilin（別名義としてAgendaとも関連づけて語られることがあります）は、ランサムウェアを中核にした恐喝ビジネスを回す「運用主体」として知られています。ニュースで名前を見かけても、実際にどんな手口で侵入し、どこで被害が大きくなり、企業側は何から手を付ければいいのかは見えにくいものです。ここでは、一般的に知られている脅威情報の範囲で、Qilinの概要と攻撃の流れ、現場で効く対策を整理します。
Qilinの位置づけ（単独犯というより“プラットフォーム”）
Qilinは、RaaS（Ransomware as a Service）型の運用として説明されることが多い存在です。RaaSは、攻撃ツールや運用ノウハウを提供する側と、侵入・展開を担う参加者（アフィリエイト）が分業するモデルを指します。被害組織から見れば「相手が誰か」より、「同じ型の流れで被害が拡大する」点が厄介になります。
攻撃者の呼称として「Qilin」という名が前面に出ますが、実務では「侵入経路」「権限の奪取」「横展開」「暗号化」「情報公開の脅し」が一続きの作業として進みます。どこか一箇所を守る発想より、連鎖を断つ発想が必要になります。
名前の変遷と活動時期の見え方
調査記事などでは、2022年ごろに「Agenda」として言及され、同年のうちにQilinへリブランドした趣旨の整理が見られます。早期からアンダーグラウンドのフォーラム上で宣伝が行われ、のちにRaaSとして稼働した流れが報告されています。
活動の活発化については、他の大規模ランサムウェア運用の混乱・摘発・分裂など、犯罪生態系の変化と結びつけて語られることがあります。固定メンバーだけの増減というより、参加者が「より稼げる場」へ移る動きが影響する、そんな構図が見えます。
何が怖いのか：暗号化だけで終わらない「二重の恐喝」
Qilinは、ファイルを暗号化して業務を止めるだけでなく、事前にデータを持ち出し、支払いが無い場合に公開すると脅す「二重恐喝」の文脈で語られています。暗号化の復旧可否だけで判断すると、後段の「情報漏えいリスク」が残ります。被害対応が長期化しやすい理由がここにあります。
社内的にも判断が難しくなります。復旧作業、顧客対応、法務判断、広報、取引先への説明が同時に走り、意思決定が消耗しがちです。攻撃側はその混乱を前提に交渉を進めてきます。
Qilinの攻撃の流れ（典型パターン）
公開されている情報を総合すると、よく語られる流れは次のような段取りです。個々の事件で差は出ますが、順番の感覚を持っておくと初動が速くなります。
初期侵入：認証情報の悪用や脆弱性起点
入り口は一つに限られません。盗まれたID・パスワードの再利用、公開サービスへの侵入、既知の弱点の悪用が組み合わさりやすい領域です。侵入口の時点では「静か」に進むことが多く、ログの見落としが命取りになります。
内部偵察と権限拡大：Active Directoryが焦点になりやすい
企業ネットワークでは、ディレクトリサービス（代表例がActive Directory）が「鍵束」になっています。ここを押さえられると、横展開や一斉実行の難易度が一気に下がります。攻撃者は、どのサーバが重要か、バックアップがどこにあるか、誰が管理者かを短時間で把握しようとします。
横展開：複数端末へ一気に広げて「止める」
暗号化を一台で実行しても被害は限定的です。現実に怖いのは、サーバ群や端末群へ同時多発的に広がり、業務が面で止まるケースです。運用上の「便利な仕組み」が、攻撃側にとっても便利に働く場面が出ます。
データ持ち出し：復旧できても終われない状態を作る
バックアップから復旧できても、情報が外に出ていれば別問題になります。個人情報、契約情報、設計情報、財務、メール、ソースコードなど、公開された時の損害が大きいものが狙われます。持ち出しの有無を早期に見極められるかが勝負になります。
暗号化と恐喝：復旧コストと“公開リスク”の二点で揺さぶる
最後に暗号化が実行され、身代金要求が提示されます。交渉は金額の話に見えますが、実際には「いつまでに支払うか」「公開を止める条件」「データ削除の主張の扱い」など、複数の不確実性が絡みます。支払いの是非は一律に言えず、法務・規制・保険・事業継続の事情が強く影響します。
技術面で語られる特徴（“手口のトレンド”として押さえる）
脅威レポートでは、Qilin（Agenda）について実装言語の変化やクロスプラットフォーム志向が取り上げられています。例として、当初はGolangで書かれ、のちにRustへ置き換えたという指摘が見られます。狙いは、対応環境を広げたり、解析や対策を難しくしたりする方向性と読み取れます。
実務的に気を付けたいのは、OSの境界を前提にした防御が崩れやすい点です。報告の中には、Linux向けの暗号化プログラムをWindows環境へ持ち込むような発想が述べられています。運用ツールや転送ツールの悪用と絡むと、EDRの設定次第で検知が難しくなる可能性が示唆されています。
「Windows端末だけ見ていれば安心」「実行ファイルの種類で弾ける」といった期待は置きにくくなっています。防御側は「挙動」と「権限」を軸に見直す必要があります。
企業が受ける被害の内訳（見落としやすいポイント）
暗号化の被害は目に見えます。見えにくい損害が後から効いてきます。
- 停止損害：業務停止、受注停止、医療・教育・製造などでは影響が連鎖しやすい
- 復旧費用：端末再展開、サーバ再構築、ログ調査、外部支援
- 信用損失：取引先の監査、顧客離れ、採用影響
- 法務・規制対応：漏えい時の通知、契約上の義務、行政対応
- 再侵入リスク：侵入口が塞がれていないと、復旧後に再被害が起きる
攻撃者の狙いは「支払うしかない状況」を作ることです。復旧作業が進んだ瞬間に安心せず、侵入経路の封鎖と証跡保全に優先度を置く判断が大切になります。
守りを固める実践ポイント（“効くところから”整える）
予算や人手が限られていても、効果が出やすい順番があります。Qilinに限らずRaaS型全般に効く考え方です。
認証を強くする（侵入口を細くする）
- MFA（多要素認証）を、メール、VPN、リモート管理、重要SaaSに適用する
- 特権IDの棚卸し：管理者権限を持つアカウントを減らし、用途別に分離する
- パスワード再利用の抑止：漏えいパスワードの検知、SSO導入の検討
IDが破られると、脆弱性対策だけでは追いつきません。入口の細さが被害規模を左右します。
バックアップを“復旧できる形”にする
- 3-2-1の考え方（媒体を分け、オフラインや隔離を含める）を意識する
- バックアップに書き込み権限が広すぎないか確認する
- 復旧訓練を行い、復旧所要時間（RTO）と復旧時点（RPO）を把握する
バックアップがあっても、暗号化や削除の対象になれば意味が薄れます。「隔離」と「訓練」がセットで効きます。
横展開を止める（ネットワークの切り分け）
- サーバ間通信を必要最小限にし、管理系ネットワークを分離する
- 端末からサーバへの管理プロトコルを見直し、誰がどこへ管理できるかを絞る
- 重要データ保管領域は、アクセス経路と権限を整理する
「ひとつ破られたら全滅」の構造を外す発想です。
監視は「イベント」より「筋の悪い動き」を拾う
製品名の話より、見たいポイントの話が役に立ちます。
- 深夜帯の管理者ログイン、普段使わない国やIP帯からのアクセス
- 短時間での大量認証失敗、複数端末への連続ログイン
- 端末やサーバでの異常なファイル改変の増加
- 大量データ送信の兆候（送信先の不審、時間帯、量の急増）
ログを集めても、見ないままだと効果が出ません。見るべき「型」を決め、アラート疲れを避ける運用が現実的です。
侵害を前提にした準備（当日の混乱を減らす）
- 連絡網、意思決定者、外部支援先、保険窓口を一枚にまとめておく
- ランサム対応の机上訓練を年に一度は回す
- 端末隔離の手順、ネットワーク遮断の権限を明文化する
「誰が止めるか」が曖昧だと、止めるまでに時間が流れます。時間は身代金交渉の材料にもなります。
被害に気づいた直後の動き（初動チェックリスト）
状況次第で最適解は変わります。一般論として、混乱を抑えやすい順に並べます。
- 拡大防止：感染が疑われる端末・サーバの隔離、不要な遠隔接続の停止
- 証跡保全：ログ、メモリ、ディスク、アラート履歴を可能な範囲で確保
- 侵入経路の仮説：最初に侵入された端点を特定し、同じ穴を塞ぐ
- 重要資産の確認：バックアップの健全性、ドメイン管理系の侵害有無
- 対外対応の準備：顧客・取引先・監督当局への連絡要否、法務確認
「暗号化された端末を直す」作業に全力投入しがちです。実際には、侵入経路が残ったまま復旧すると再被害の確率が上がります。
よくある疑問（現場で出やすいポイント）
身代金を払えば安全に終わるのか
支払っても、データが完全に削除された保証を検証するのは難しいとされています。攻撃者の主張と事実の間にギャップが起き得ます。判断には法務・規制・保険・事業継続の要件が絡み、技術チームだけで背負える話ではありません。
“うちは中小だから狙われない”は通るのか
RaaS型は「参加者が獲物を探す」構造なので、規模だけで外れるとは言いにくい面があります。取引先の踏み台にされるリスクもあり、サプライチェーン全体で見られることが増えています。
EDRを入れているのに突破される理由は
ツールの有無より、設定・監視・運用が効きます。OSや実行形式の想定をずらす手口が報告されている以上、例外設定、管理ツールの許可範囲、隔離運用の訓練まで含めて「防御の形」を作る必要があります。
Qilin対策は「入口」「横展開」「復旧」の3点で差が出る
Qilinは、RaaSとしての運用、二重恐喝、クロスプラットフォーム志向といった文脈で語られています。攻撃の派手さは暗号化に見えます。実害を左右するのは、それ以前の侵入と横展開、起きた後の復旧設計です。入口を細くし、横に広がらない構造に寄せ、復旧を訓練しておく。地味な積み上げが最終的に効きます。
最後に、社内の状況に合わせて対策の優先順位を整理したい場合は、次を教えてください。現実的な順番に落として提案できます。
- 従業員規模、拠点数、社内サーバの有無（オンプレ／クラウド）
- リモートアクセスの手段（VPN、VDI、ゼロトラスト等）
- バックアップ方式（世代数、保管先、オフラインの有無）
コメント