既に読まれた秘密をロールバックすることはできません

貴重な知的財産が保管された書類金庫を思い浮かべてください。雇われたスパイがそれを開け、中の書類を撮影し、再び閉めて立ち去ります。翌朝、金庫は前夜とまったく同じに見えます。同じ扉、同じ暗証番号、何も動いていません。元に戻すべきものは何もありません。復旧ツールが理解する意味において、何も持ち去られていないからです。損失はすでにコピーという形で建物の外へ出てしまっています。

これが、Active Directoryに対する大規模な攻撃群が取る不都合な形であり、業界お気に入りの防御ストーリーの真ん中に穴が空いている理由です。

この10年間、Active Directoryセキュリティ市場はただ一つの軸で競い合ってきました。悪意ある変更をどれだけ速く元に戻せるか、という軸です。不正な書き込みを検知し、アラートを上げ、既知の正常状態に戻す。改ざん防止の変更追跡と自動ロールバックが、その提案のすべてです。復旧という物語としては優れていますし、復旧は確かに重要です。しかし、それは本当に重要な点を譲り渡してしまっています。変更はすでに起きてしまっており、一部の変更は一度起きてしまうと、なかったことにはできません。

ロールバックする前に完了してしまうActive Directory攻撃

最も速いAD攻撃が実際にどう進行するかを考えてみましょう。ランサムウェア集団は、CVE-2021-42278とCVE-2021-42287の根拠となっているsAMAccountNameスプーフィングのペアであるnoPacのような脆弱性を連鎖させ、通常のアカウントから数分でドメインの完全な制御権まで駆け上がります。攻撃者がその立場を手に入れてしまえば、その後に続く手法は、後から片付けられるような騒々しい破壊行為ではありません。ロールバックが回収すべき何かを持つ前に、作業を完了させてしまう読み取りとなりすましです。

DCSyncは最も分かりやすい例であり、先ほどの金庫の話に直接対応します。ディレクトリ自体の複製プロトコルを悪用し、攻撃者はドメイン コントローラーにアカウントのパスワード ハッシュを要求し、まるで別のコントローラーであるかのようにそれを受け取ります。復旧ツールが気づいて元に戻せるような、変更されたオブジェクトはディレクトリ内に残りません。その変更と呼べるものがあるとすれば、それはすでに流出してしまった認証情報のコピーです。その後にすべてのパスワードをリセットすることはできますし、そうすべきですが、その時点で行っているのは窃盗を止めることではなく、窃盗の後始末です。

DCShadowは逆方向から機能します。不正で正規でないドメイン コントローラーを登録し、複製チャネルを通じて攻撃者が選んだ変更をディレクトリに注入し、監視が見張っている通常の書き込みパスを迂回します。ここでは、有効な制御が不正な複製を試行された瞬間に拒否するため、注入された変更はそもそもディレクトリに入ることがなく、元に戻すべき対象自体が存在しません。

次に、グループ ポリシー オブジェクト(GPO)への悪意ある編集を考えてみましょう。ポリシーを読み込むすべてのマシンにランサムウェアのペイロードを配布するタイプのものや、特権グループへの静かな追加などです。オブジェクトをロールバックすれば、ディレクトリの状態は復元されます。しかし、ポリシーはすでに配布され、それが運んだペイロードもすでに実行されています。オブジェクトを復元しても、すでに生じた被害範囲には何の影響もありません。

これこそが、復旧という物語が行き詰まる場所です。このカテゴリ全体において、検知とロールバックは構造的に手遅れであり、防御は同じ発想の高速版ではなく、まったく異なる規律です。検知は、危険な何かがすでにディレクトリに到達したことを確認するにすぎません。防御は、ディレクトリがそれを受け入れる前に操作を止めます。

検知 対 防御:あるGPO攻撃を両方の視点から考える

攻撃者がサーバーにリンクされたGPOを編集し、次のポリシー更新時にペイロードを展開するとします。まず復旧モデルに従って考えてみましょう。悪意ある設定は検知されロールバックされ、GPOは以前の状態に戻ります。書類上は、インシデントは解決済みです。しかし実際には、編集からロールバックまでの間にポリシーを取得したすべてのマシンが、すでにペイロードを実行してしまっており、オブジェクトをどれだけ復元してもその実行はなかったことにはなりません。

次に、逆の視点から考えてみましょう。そのGPOへの書き込みはインラインで評価され、Active Directoryがそれをコミットする前に拒否されます。ポリシーは決して変更されないため、配布されることもなく、調査すべきペイロードの実行も残りません。同じ攻撃、二つの防御モデル。片付けるものが何も残らないのは、そのうちの一方だけです。

なぜ「防御」であって「高速な検知」ではないのか

この二つ目の結果は、書き込みパス自体に位置する制御によってのみ得られます。これがNetwrix Threat Managerの背後にある仕組みです。重要なオブジェクトやGPOへの変更、特権グループの変更、複製要求といった操作をインラインで評価し、ディレクトリが書き込みをコミットする前に発生源でブロックします。さらに、ネイティブのロギングが無効化または消去された場合でも、これらのイベントを発生源で捕捉するため、攻撃者が先にログを消去して制御を欺くこともできません。これこそが、より強い言葉をまとった高速な検知ではなく、防御という言葉にふさわしい理由です。

これは防御が検知に取って代わるという意味ではありません。一部の攻撃は事後にしか発見・対応できず、そうでないふりをすることは、有能なCISOなら誰もが投げかける最初の率直な問いに耐えられません。過大な主張は、それに見合った反応を招きます。擁護できる立場は、スローガンよりも狭く、より堅実です。確定的にブロックできる変更には防御を最優先し、それ以外のすべてには検知と対応を用いるというものです。

この根底には、一貫した考え方があります。危険な変更が試みられたその瞬間にそれをブロックすることにこだわるのは、アクセス権を持つ者がそれを使用したその瞬間に、それが誰であるかを知ることにこだわることの、レジリエンス側の対となる存在です。どちらも、その後の後片付けではなく、行動が起きたその瞬間に対応することにこだわっています。

これは、無傷に見えたあの金庫の話に私たちを引き戻します。ロールバックは、被害を素早く元に戻せるという約束です。防御は、元に戻すべき被害がそもそも存在しなかったという保証です。Secretをコピーし、コントローラーになりすまし、あるいはロールバックできる前に爆発するActive Directory攻撃について、この二つのうち実際に守れる約束はただ一つであり、それは変更を決してコミットさせなかった制御による約束です。