認証は完璧には守れない。ならば「入られない」ではなく「入られてから、どこまで行かせるか」で守る。KerberLoss/ResetNightmareを入口に、攻撃者の3手（昇格・居座り・指令）を攻撃者の側から読み、それぞれの防御を逆算する。オフェンスを知らなければ、ディフェンスは進化しない。
――「入られない」ではなく「入られてから、どこまで行かせるか」で守る
どんなに守っても、認証はいつか取られます。
巧妙なフィッシングで従業員の1人がだまされる。別のサービスから漏れたパスワードが、たまたま社内でも使い回されていた。委託先の端末が踏み台になる。
入口はいくらでもあります。そのすべてを完璧に塞ぐことは、現実にはできません。
では、認証を取った攻撃者は、その次に何をするのか。
本稿では、そこを攻撃者の側から見てみます。
なぜなら、防御を強くするには、相手の攻め方を知らなければならないからです。ラグビーでも、相手の攻撃パターンを知らなければ、それに対応する守備は組めません。
サイバーセキュリティも同じです。
攻撃者が認証を取った後、何を見て、どこへ進み、どこに居座るのか。その戦術を知ることで、初めて守るべき場所が見えてきます。
きっかけは、2026年夏にSemperisが公表したActive Directory（AD）／Kerberosの脆弱性、KerberLoss（CVE-2026-25177）とResetNightmare（CVE-2026-27912）でした。
いずれも、低い権限のアカウントから始まり、AD上の書き込み権限など一定の条件がそろうと、権限昇格や、最悪の場合はドメイン全体の侵害につながりうる論理的な欠陥です。KerberLossは3月、ResetNightmareは4月に修正されています。
しかし本稿は、この2つのCVEの解説ではありません。
このニュースを入口に、その先を見ます。
一般ユーザーの認証を1つ手に入れた攻撃者は、次に何を見るのか。どうやって管理者へ近づくのか。管理者になったら、どこに居座るのか。そして、どうやって組織の中を動くのか。
攻撃者の動きを逆から読めば、守る側がどこに壁を作ればいいのかも見えてきます。
オフェンスを知らなければ、ディフェンスは進化しません。
これは「攻撃方法を覚えよう」という話ではありません。
取られた1つの認証を、組織全体の侵害に育てさせないための話です。
なお、本稿は特定の組織における被害を指すものではありません。「認証を取られた組織で、その後一般に何が起こりうるか」を考えるものです。
「ドメイン完全乗っ取り」。
脆弱性のニュースは、たいていここで終わります。深刻な脆弱性が見つかった。パッチを当てよう、と。
しかし攻撃者にとっては、その先があります。
ドメイン管理者を握るということは、その組織の「認証の根」を握るということです。パソコンを1台乗っ取ったのとは、意味が違います。
そして、ここからが厄介です。
攻撃者は、派手なマルウェアを持ち込むとは限りません。むしろ、あなたの正規の仕組み――AD、権限管理、配布の仕組み――を、そのまま自分の道具として"相続"します。
正規の権限で、正規の仕組みを使う。
だから、攻撃者の行動が「管理者が、管理者らしいことをしている」ように見えることがあります。
では、攻撃者は何をするのか。
大きく3つに分けて考えてみます。
最初の足がかりは、たいていドメイン管理者ではありません。一般ユーザーなど、もっと低い権限です。
そこから攻撃者が始めるのは、いわば"地図読み"です。
Active Directoryには、「誰がどのグループに属しているか」「誰が誰のパスワードをリセットできるか」「誰がどのオブジェクトを書き換えられるか」といった、膨大な権限関係があります。
攻撃者は、その関係をたどります。
「今の自分から、より強い権限へ行く最短経路はどこか」
という問題として見るわけです。
KerberLossやResetNightmareのような脆弱性も、この権限関係の中で威力を持ちます。書き込み可能な対象など一定の条件がそろったとき、本来の権限を超えたなりすましや権限昇格につながる可能性が生まれます。
つまり怖いのは、脆弱性だけではありません。
あなたのADの権限構造そのものが、攻撃者の地図になる。
ならば、守る側がやることも見えてきます。
「誰が誰のパスワードを変えられるのか」 「誰がどのオブジェクトを書き換えられるのか」
不要な権限を減らす。管理者権限を日常業務のアカウントから分離する。必要以上に強い権限を持つアカウントを減らす。
経路上の線を1本消せば、攻撃者の道は遠くなります。重要な線を消せば、そこで道を途切れさせることもできます。
これは単なるコンプライアンスではありません。
攻撃者が使う近道を、先に消しておく作業です。
強い権限を得た攻撃者が次に考えるのは、「どうすれば追い出されないか」です。
パッチを当てられても、パスワードを変えられても、また入れる状態を作る。これが永続化、つまり"居座り"です。
ここで「ウイルスのファイルをどこかに置く」と考えると、半分しか見えません。
ドメイン規模の居座りでは、ADそのものや、認証に使われる鍵・証明書も重要な対象になります。
たとえば、ADの権限や属性を書き換えて、後から再び強い権限を得られる状態を作る。特権グループにアカウントを追加する。認証に使われる属性に細工する。
さらに深刻なのが、鍵と証明書です。
Kerberosでは、krbtgtという特別なアカウントの鍵素材がチケットの信頼を支えています。これを攻撃者に取得されると、有効に見えるKerberosチケットを偽造されるおそれがあります。
社内の認証局が侵害された場合も厄介です。証明書はユーザーや端末の認証にも使われるため、不正な証明書が新たな身分証として悪用される可能性があります。
つまり、全ユーザーのパスワードを変えれば終わり、とは限りません。
では、どう守るか。
まず、重要な属性や権限を変更できる人を絞る。これは①と同じです。書き込めなければ、そこに裏口を作ることも難しくなります。
もう一つは、「普段は変わらないものが変わった瞬間」を見ることです。
特権グループのメンバーが増えた。 重要な権限が追加された。 認証に関係する属性が書き換えられた。
こうした変更は、それ自体が重要なシグナルになります。
Active Directoryでは、変更監査に加えて重要なオブジェクトや属性へ適切な監査設定をしておけば、こうした変更を記録できます。ログは、侵害された管理者から消されない場所へ送り出しておくことも重要です。
鍵についても同じです。
重要なのは、単に「定期的に全部変える」ことではありません。鍵が侵害された可能性を把握し、必要なときに正しい手順で更新し、盗まれた古い鍵を使い続けられないようにすることです。
変わらないはずのものが変わったら気づく。侵害された鍵は、使い続けられないようにする。
これが②の答えです。
攻撃者は、最初に侵害した端末だけで満足するとは限りません。
そこから別の端末へ、さらに重要なサーバへ、そして重要なデータへ進もうとします。外部と通信し、盗んだデータを持ち出そうとすることもあります。
ここで重要になるのが、「どことどこがつながっているか」です。
特に守るべきものの一つが、ドメインコントローラーです。
ドメインコントローラーとは、ADの情報を保持し、組織の認証を支える中核サーバです。ここに強い権限でアクセスされれば、Active Directory全体の信頼性に影響します。
だから、日常業務の端末から、重要な管理系サーバやデータへ自由に移動できる状態を作らない。
「1人取られても、そこから先には簡単に届かない」
という前提でネットワークと管理経路を設計します。
必要な通信だけを許す。管理系を分離する。重要な資産への到達経路を限定する。外部への通信も必要以上に自由にしない。
何でもつながるネットワークは、攻撃者にとって高速道路です。
守る側が作るべきなのは、その途中にある関所と行き止まりです。
そして、これは早い段階ほど効きます。
攻撃者が十分に強い管理者権限を得てしまえば、組織が普段使っている正規の管理ツールまで攻撃に利用できます。そうなれば、悪意ある操作と通常の管理作業を見分けることは難しくなります。
だから、強い権限へ到達する前に、進める線を減らしておく。
これが③の答えです。
3つを並べると、共通するものが見えてきます。
攻撃者は、あなたのインフラを"相続"する。
ADの権限構造。 認証の仕組み。 ネットワーク。 管理ツール。
組織を動かすために作った正規の仕組みが、侵害後には攻撃者の道具にもなります。
ならば、相続される中身を、あらかじめ薄くしておく。
「認証の脆弱性」というニュースは、この物語の入口にすぎません。
パッチを当てることは大前提です。
そのうえで本当に問われるのは、認証を1つ取られたとき、それがどこまで広がる設計になっているかです。
守りきる、は幻想です。
けれども、「入られてからの距離」は設計できます。
そして、この3つは脆弱性ごとのチェックリストではありません。
攻撃者が何を欲しがり、次にどこへ行くのか。その戦術から逆算した防御です。
オフェンスを知らなければ、ディフェンスは進化しない。
次の脆弱性が現れたときにも残るのは、その考え方です。
本稿は、認証情報が窃取された場合に一般に起こりうる事象と、その被害範囲を狭めるための防御の考え方を述べたものです。特定の攻撃手順や悪用方法には触れていません。また、特定の組織における被害を示すものでもありません。具体的な設定・復旧手順については、各製品の公式ドキュメントや専門家にご確認ください。
安藤 典久
公開日: 2026/8/9
最終更新: 2026/8/9
セキュリティの最新情報をお届けします。