強力な LDAP 拡張コントロール：AD における反修復（Anti-remediation）と不可視の偵察

2 台の DC の cloud.lab（Windows Server 2022、フォレスト機能レベル 2016）に対して実証しました。実験室／許可された調査研究の文脈に限定します。

発見 1 - FORCE_UPDATE：単一の LDAP 書き込みから複製（レプリケーション）の競合に勝つ

平易な言葉で言うと

AD レプリケーションをすでに完全に理解しているなら、先に進んでください。そうでなければ、たとえ話で説明します。

同じ会社に、別々の2つのオフィスでまったく同じファイリングキャビネットが2台ずつあるとします。これが2つのドメインコントローラー（DC）です。同期を保つために、どちらか一方で行った変更はすべてもう一方にコピーされます。そのコピーがレプリケーションです。

もし2人が別々のオフィスで同じファイルを同じタイミングで編集し、コピーが追いつく前に食い違ってしまったらどうなるでしょう？キャビネットの内容は一致せず、AD は「勝つのは誰か」を決めるルールが必要です。

1. バージョン番号が高いほうが勝ちます。 すべての項目（フィールド）は、変更された回数を覚えており、その回数がその「version（バージョン）」です。
2. バージョンが同じ（同点）の場合に限り、AD は最後に編集したのが誰か（タイムスタンプ）を見ます。
3. それでも同点なら、キャビネットの ID で同点を解消します。

コツ： 通常は、あるフィールドを「編集」するために すでに入っていた正確な値 をそのまま書き戻すと、AD は「何も変わっていない」と言って、バージョンはそのまま据え置かれます。 FORCE_UPDATE は「とにかくこれは本当の変更として数えてください。」 という意味のフラグです。つまりBob がすでに書かれているフィールドにBob を6回書き込むことができ、値が一度も変わっていないのにバージョンだけが6まで上がります。

つまり攻撃者は、編集できるフィールドに悪意のある変更を1回加え、FORCE_UPDATE を数回当ててバージョンを6まで引き上げ、そのまま待ちます。防御側が 別の キャビネット（ほかのDCのいずれか）で修正すると、それは新しい、 後からの 編集になりますが、そのキャビネット上でそのフィールドの 最初の 変更なので、バージョンは 1 です。キャビネット同士が同期し、AD は 6 vs 1 を比較して、6 が勝ちます。攻撃者の値が戻ってきて、防御側の修正は何事もなかったかのように消えます。攻撃者は、より新しく正当な変更よりも勝つように強制的な変更を行ったのです。

正直な注意点は2つあります。 この手法は すでに編集できる フィールドにしか効きません（これは 永続化 であって、権限昇格 ではない）ということと、見えないわけではありません。値は変わらないのに、バージョンだけが跳ねたフィールドが残ります。本当に新しいのは「入場料” ：有名な DCShadow 攻撃も同じ “my version wins” の動きをしますが、ほぼドメインの神レベルの権限が必要です（DCになりすまして be として振る舞う）；一方こちらは、普通の書き込み1回と、1つのフィールドに対する許可（権限）だけで済みます。

背景：AD が勝者を決める仕組み

Active Directory は multi-master であり、つまりすべての書き込み可能な DC が、外部へ複製される変更を受け入れます。複製が整合（reconcile）される前に、2 つの DC に対して 同一オブジェクトの同じ属性 を変更するよう指示できます。 属性ごとの(per-attribute)競合では、タイブレーク（tiebreak）の順序は次のとおりです:

1. バージョン: 属性ごとのカウンターが、各「発信側の書き込み」ごとにインクリメントされます。
2. タイムスタンプ: バージョンが同一の場合にのみ使用されます。
3. サーバー（DSA）GUID: バージョン および タイムスタンプが同値の場合にのみ使用されます。

このメタデータは属性ごとで、 repadmin /showobjmeta または msDS-replAttributeMetaData により確認できます。重要な性質： 低いバージョンは、それがどれほど新しく見えても常に高いバージョンに負けます。 そして MODIFY で、属性の既存の値を書き込むだけの場合は通常 no-op です（AD はバージョンを更新しません）。通常は、同じ値を書き直してバージョンを上げることはできません。

制御（コントロール）：LDAP_SERVER_FORCE_UPDATE（1.2.840.113556.1.4.1974）

FORCE_UPDATE は、文書化されている「文脈（フレーミング）次第で良性になる」タイプの制御です。MS-ADTS によれば、これは DC に 本来であれば no-op（何もしない）になる変更であっても処理させます（「新しいデータが同一でも更新する」）。Java ライブラリ ldaptive には ForceUpdateControl がまさにそれを行う形で同梱されており、攻撃のためのフレーミングはありません。問題になる（重要な）副作用は次のとおりです。強制書き込みは実際の originating write として数えられるため、値を変えずに 属性ごとのバージョンが増分されます。これがブリッジです。バージョンスタンプは慣例的に LDAP クライアントから到達不能だと考えられています（そのため DCShadow は、複製プロトコル上で“不正な DC（rogue DC）”としてこれを操作します）。FORCE_UPDATE は、それを通常の認証済みの LDAP MODIFYから到達可能なものへ移します。

この手法

1. 対象の属性を選択します 主体（principal）がすでに書き込み可能なもの（1 つの WriteProperty ACE）。
2. 悪意のある値を設定します（DC-A 上で）。
3. バージョンを水増しする： 同じ値の追加で N 個の MODIFY を送信し、それぞれに FORCE_UPDATE を付け、可視的な変更なしでバージョンだけを押し上げます。
4. 待って： 防御側が値を修正します。これは（DC-B）として、接続されているどの DC でも自然に行われます。防御側の単発の修正ではバージョンが 1 だけ増えます（current+1 まで）。攻撃者がそれ以上 に水増ししていれば、攻撃者は依然として上位になります。 （実験室では、防御側がバージョン 1 に着地したのは、その属性が以前は未設定だったためです。一般には、攻撃者が修正よりも上のバージョン番号を用意するだけで十分で、それは無料です。）
5. 収束： AD はバージョンを比較します。攻撃者が水増ししたバージョンは、防御側が後から行ったもののバージョンが低い修正よりも上位になります。 攻撃者の値が両方の DC で勝ちます。

防御側は、変更が「定着しない」のを見ます。直すと直ったように見えるのに、数分後には元に戻ります。

特権モデル vs DCShadow：新しいポイント

見過ごされがちな洞察：LDAP はそもそも、属性ごとのバージョン・スタンプに到達できます。 FORCE_UPDATE は、クライアント側の「DC として複製プロトコルを話さなければならない」という前提を静かに打ち崩します。

デモ（2 台の DC のラボ）

攻撃者 = svc-research、単なるドメインユーザーで、委任されたのは only WP;description（複製権限なし）。攻撃者のアクションは自身の NTLM バインドの下で実行されます。管理者コンテキストは、実験室のオーケストレーションのみに使用されます（委任、複製の一時停止/再開、防御側のシミュレーション）。

      Step 1 — low-priv writer bumps the version:
  baseline:                      description  version 1
  attacker no-op FORCE_UPDATE -> description  version 2   (no value change)

Step 2 — stage and win the conflict (replication paused):
  DC01:  description='ATTACKER-OWNED'            version 6  @ 19:58:34  (attacker, FORCE_UPDATE x3)
  DC-02: description='defender-remediation-LATER' version 1 @ 19:58:36  (defender, LATER, lower version)
  => CONVERGED: DC01 = DC-02 = 'ATTACKER-OWNED'   (defender's later fix reverted)
      

攻撃の全体的な要となるのは、1 つの MODIFY にコントロールを付与したものです:

      var m = new ModifyRequest(dn, DirectoryAttributeOperation.Replace, "description", value);
m.Controls.Add(new DirectoryControl("1.2.840.113556.1.4.1974", null, true, true)); // FORCE_UPDATE, critical
connection.SendRequest(m);   // same-value write now bumps the per-attribute version
      

影響範囲と制限

anti-remediation / persistence のプリミティブ（原始的手口）：攻撃者の値を 復旧・クリーンアップ（cleanup）に対してしぶとくする ために、攻撃者がすでに書き込める任意の属性に対して適用する。例：msDS-AllowedToActOnBehalfOfOtherIdentity（RBCD バックドア）、servicePrincipalName（Kerberoast のターゲットを再度主張する）、scriptPath / gPLink（粘着性のある足がかり）。

• スコープ境界（テスト済み）： Linked 属性（member / memberOf）は 影響を受けません。これらは per-value メタデータ付きの Linked-Value Replication により複製されます。既存のメンバーを no-op FORCE_UPDATE で再追加することは成功しますが、リンク値の バージョンは増加しません。したがって、この方法ではグループのメンバーシップを固定（pin）できず、固定できるのは単一値および複数値の、Linked ではない属性のみです。
• 既存の書き込み権限が必要です（権限昇格ではありません）。そして防御側は、別の DC（または収束前）で修正する必要があります。そうしないと競合が成立しません。
• ステルス性は低い： 値の変化がないのに異常なバージョンジャンプが残り、さらに修復（remediation）後にその値が「戻ってきます」（harmj0y, Hunting With AD Replication Metadata, 2017）。

新規性： 複数回の先行研究（prior-art）レビューと、認証済みの GitHub ネイティブなコード検索（約 1,000+ 件の OID ヒット）を行った結果、この特定のプリミティブの公開は見つかりませんでした。ほとんどのヒットは無害（SDK ヘッダー、言語バインディング、ディセクター、CTF supportedControl ダンプ）です。最も近いものは DCShadow（同じ効果で、悪意のある/不正な DC による DA/EA）と、LDAPAngel/RIFM（フォレスト回復ツールで、sends FORCE_UPDATE を送りますが、バージョンの不必要なインフレではなく、運用上の FSMO/GC の目的のために非クリティカルに行うもの）、ldaptive の良性の ForceUpdateControl、および Tenable のオブジェクトレベルの「Conflicting Objects」レースです。これらはいずれもこの技術を使用していません。証拠がないことは証明ではありませんが、「衝突で勝つ / anti-remediation application」の適用は未公開のようです。

Finding 2 - OBJECT_SECURITY DirSync: ログの痕跡なしで Active Directory を列挙

要点を平易な言葉で

一般ユーザーでも Active Directory のほとんどの情報はすでに調べられます。たとえば名前、グループのメンバーシップ、さらに読み取り可能なオブジェクト上の権限リスト（ACL）までです。通常、それらの照会は 記録され、DC のクエリログに残ることがあります。 DirSync は、Entra Connect のようなツールが変更を取り込むための同期機能です。そのオプションの 1 つ OBJECT_SECURITY を使うと、通常ユーザーがそれを実行して、自分の権限で既に読み取ることが許可されている Active Directory 上のすべてを読み取れます。しかし、通常の search ではなく replication の配管（仕組み）を通るため、DC には何も記録されません。これはユーザーがすでに収集できるのと同じデータですが、痕跡は残りません。この方法では、AD で変更された分だけを後から取得し直せる「ブックマーク」（cookie）も提供されます。

仕組み

DirSync (LDAP_SERVER_DIRSYNC_OID, .841) は 2 つのモードがあります：

• flags=0 は完全な複製（replication）のセマンティクスを使用し、 Get-Changes の複製権限が必要です。 これは特権的で DCSync に隣接するパスであり、 Event 4662 経由で記録されます。
• OBJECT_SECURITY (flag 0x1) は、一般の呼び出し元向けに文書化された 非特権 パスです。必要なのは 複製権限も権限変更も不要で、Domain Users だけ。さらに結果のスコープは、呼び出し元がすでに読み取れるデータに制限されます。（これは Simon Décosse、simondotsh が 2022 年に文書化したパスです。私の貢献は、検証された 検出 の帰結です。）

OBJECT_SECURITY は Get-Changes の権限を行使しないため、 Event 4662 が出力されません。また DirSync は 検索パスではなく複製（replication）コードパスを使うため、 Event 1644 も出力されません。この挙動は、2つのホスト・ログ・ソースのちょうど間に完全に位置します。

DirSync が返す cookie により、後から再接続して前回以降の 変更 だけを取得できるため、ノイズの少ない変更モニターとしても使えます。

なぜそれが巧妙な機会なのか

これは recon / enumeration のフェーズにとって、まさに絶好の機会です：

• 特別なアクセス権は不要： 侵害されたドメイン アカウントであれば何でも機能します。要求すべきレプリケーション権はなく、スキーマ/searchFlags の変更もなく、それ自体が不審に見えるものもありません。
• 足跡なし： 追加コストのかからないログ痕跡で、バルクのオブジェクトとメンバーシップを収集でき、さらに継続的な監視のための内蔵デルタ同期も備えています。

これは新たなアクセス権を与えるものではなく、ステルス性（stealth）です。 攻撃者がそれ以外では読み取れないデータを渡すことはありません。これは呼び出し元の effective read access の範囲に限定され、通常の LDAP 検索とまったく同じ内容を返します。重要なのは、これが 機密属性ゲートをバイパスしない ことです（searchFlags 0x80）：機密属性が返されるのは 呼び出し元が本当にそれを読み取る正当な権利を持っている場合のみ（CONTROL_ACCESS 権限を保有している場合）です。このバイパスが当てはまるのは 別の DirSync モード、flags=0 であり、複製（replication）のセマンティクスを使って Get-Changes 権限を持つ誰にでも機密属性を漏えいさせます（同伴する detection blind spots 記事の主題）。また、OBJECT_SECURITY も秘密情報を読み取れません（それは DCSync ではないため、パスワード関連の素材がありません）。違いは純粋に 回避（evasion） です。つまり通常の SD_FLAGS スイープ なら LDAP クエリのログ記録が有効になっている場所ならどこでも Event 1644 のレコードが残ります。一方、OBJECT_SECURITY の DirSync バージョンでは、いずれのログにも残りません。攻撃者にとっての価値は、防御側が依存する LDAP 検索テレメトリを無力化する、低ノイズな収集 にあります。そのため、新たな特権は付与されないとしても、知っておく価値があります。

検知と防御

この2つの結果には共通のテーマがあります。つまり、最も 明白な 検知の発想は機能せず、ホストログは防御側が想定するよりもはるかに見えません。以下はすべて、ラボで技術を実行して検証しました。

FORCE_UPDATE (Finding 1)

• 一次 - レプリケーション・メタデータ（replication-metadata）調査： スナップショット msDS-replAttributeMetaData（または repadmin /showobjmeta）を機密属性について取得し、属性ごとの 値ハッシュが変わらないのにバージョンだけが上昇する 場合にアラートを出します。ラボでは、この方法で攻撃をきれいに特定できました（description バージョン 28 → 29、値は不変）。2つ目の症状：復旧（remediation）後に再び現れる 値。
• イベント 1644 はこれに対して盲目です： FORCE_UPDATE は MODIFY に乗って実行されます。イベント 1644 は 検索（searches） だけを記録するため、この modify では 1644 のイベントが発生しません。そのため、クエリログ内の .1974 の OID をキーにしたルールは決して発火しません。ワイヤ検知には PCAP/ETW が必要で、制御（control）には signed bind（単純/Basic bind は拒否）を要するため、cleartext-389 の可視性が制限されます。
• ハードニング： 機密属性に対する WriteProperty を最小限にします（前提条件全体）。可能であれば同じ DC で復旧（remediate）し、その後バージョンを確認してください。

OBJECT_SECURITY DirSync（検出事項 2）

• ホストのログでは見えません： 4662 がなく（Get-Changes の権限なし）、1644 もありません（レプリケーション経路なし）。そのため記録すべきイベント ルールがありません。ここが死角です。
• 実際に効くのは限られています： 現実的な打ち手は ネットワーク / ETW のキャプチャ で、ワイヤ上の DirSync 制御を観測すること（LDAPS に依存）に加えて DirSync 利用のベースライン化 そして同期元以外のあらゆるソースからそれを検知してアラートすることです。SACL read-canary は 信頼できる 後ろ盾ではありません。テストでは、属性の通常の読み取りに対して ReadProperty の監査 ACE はイベント 4662 を発生させませんでした。AD のホスト側の読み取り監査は信頼性が低く、DirSync のレプリケーション経路の読み取りもそれを変えません。 (SACL canaries は FORCE_UPDATE write およびレプリケーション権限を持つ DirSync/DCSync には有効ですが、このようなステルスな読み取りには有効ではありません。)
• ADWS の観点も見てください： PowerShell の AD コマンドレット（Get-ADUser など）は、LDAP を直接扱いません。代わりに Active Directory Web Services（ADWS、TCP 9389）を経由し、そのクエリをローカルで DC に中継します。したがって、イベント 1644 にはクライアントとして 127.0.0.1（DC 自身）が記録され、操作側の実アドレスは記録されません。
  • 重要な理由： すべての 1644 ルールでは 127.0.0.1 を除外する必要があります。DC 自身の内部検索が常にループバックのノイズを発生させるため、同じ除外条件によって、攻撃者が ADWS 経由でプロキシした活動も見落としてしまいます。真の発信元が分かるのはネットワーク／ETW の可視性だけです。

SACL canaries：それらは何か、そしてどこで役立つのか

上記はいくつかの推奨事項が SACL canaries に依存しているため、ここでそれらについて説明します。すべての AD オブジェクトのセキュリティ記述子には、次の 2 つのアクセス制御リストが含まれています：

• DACL： 誰が 何を実行できるか （権限）
• SACL： 誰の どの操作が監査対象になるかを決めます

SACL の監査 ACE は「このオブジェクトまたは属性にアクセスされたら、Windows Security Event 4662 を発行（emit）する」と述べます。 canary は、高価値のオブジェクトに対して、正当なアクティビティが滅多に触れない領域に意図的に仕込む「honeytoken-style」のトリップワイヤーです。そのため、アクセスが発生すると必ず作動します。これは制御（control）やログ（log）ではなく、オブジェクトアクセス層（object-access layer）で評価されるため、 どの LDAP 制御またはトランスポートが 使用されたとしても作動します。

展開するには：

• 有効化：Audit Directory Service Access（成功）し、重要な資産（crown jewels）で注目しているアクセスに対する監査 ACE を追加します（例：RBCD 属性 msDS-AllowedToActOnBehalfOfOtherIdentity、特権グループ member、AdminSDHolder）。

落とし穴：書き込みには強いが、読み取りには弱い（検証済み）。

この2つの検出結果は異なる防御を回避するため、カナリアは不均等に役立ちます：

• FORCE_UPDATE は write です: 対象属性に対する SACL write-canary は、悪意のある修正で 4662 を確実に発火させ、複製メタデータの探索（replication-metadata hunt）でも関係なく捕捉されます。（control-access right の SACL 監査も、Get-Changes 4662 を通じて複製権限の DirSync/DCSync を同様に確実に検出します。）
• OBJECT_SECURITY DirSync は readです： AD のホスト側の読み取り監査は信頼できません。私のテストでは、ReadProperty の監査 ACE が たとえ通常の 属性の読み取りでも 4662 を発生させませんでした。つまり、SACL のカナリアでは、このようなステルスな読み取りを確実に検知できません。その代わりに ネットワーク/ETW のキャプチャ と DirSync のベースラインに頼る必要があります。

要するに：監査カナリアは 書き込み 側や、複製権限の悪用に対する最良のトリップワイヤですが、ステルスな 読み取り には“回線を見る目”が必要です。

ツール

Red Team と Blue Team のために、LDAP の拡張コントロール（extended controls）を調査し防御することを目的とした 2 つの PoC（proof-of-concept）ツールを作成しました： LDAP Extended Controls Toolkit。

各ツールの役割

red/ — ldapctl（攻撃用）

3つのサブコマンド。各サブコマンドは、検証済みの拡張制御（extended-control）技術を1つずつ具体化して実行します。完全なフラグ、権限、および出力形式は red/README.mdにあります。

blue/ — AdLdapDefense（防御用）

4つの検知/強化（detection/hardening）機能をカバーする、5つのエクスポート済み関数から成る PowerShell モジュールです。パラメーターとサンプル出力は blue/README.md にあります。PowerShell 5.1+ と RSAT（ActiveDirectory）が必要で、DCに到達できる管理者用ワークステーションから実行してください。

参考文献

• MS-ADTS、 LDAP_SERVER_FORCE_UPDATE_OID。 https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3c5e87db-4728-4f29-b164-01dd7d7391ea
• MS-ADTS / MS-DRSR。レプリケーションの競合解決（バージョン → タイムスタンプ → DSA GUID）；DirSync（LDAP_SERVER_DIRSYNC_OID）とレプリケーションのセマンティクス
• DCShadow、Delpy & Le Toux、BlueHat IL 2018。 https://www.dcshadow.com/
• harmj0y、 Active Directory レプリケーション メタデータを使ったハンティング（2017）。 https://blog.harmj0y.net/defense/hunting-with-active-directory-replication-metadata/
• simondotsh、 DirSync を理解し、悪用する（2022）。 https://simondotsh.com/infosec/2022/07/11/dirsync.html
• Tenable、 特権を得るために Active Directory で競合するオブジェクトを使用する（2024年）。 https://medium.com/tenable-techblog/using-conflicting-objects-in-active-directory-to-gain-privileges-243ef6a27928