サーバー（非）信頼アカウント

userAccountControl を操作して Active Directory の永続化を行う

最近、グループ Managed Service Accounts（gMSA）について調査を進めていて、情報を得るために MS-SAMR のプロトコル仕様書を読んでいました。すると偶然、 userAccountControl のセクションに興味深い情報があるのを見つけ、思わず手を止めてそれをテストすることにしました:

本質的に、UF_SERVER_TRUST_ACCOUNT ビットがコンピューター オブジェクトの userAccountControl 属性に設定されると、その後 Active Directory は同じオブジェクトの primaryGroupId を Domain Controllers グループの RID に設定する必要があります。したがって、単に userAccountControl を変更するだけで、コンピューター オブジェクトにドメイン コントローラーの特権を付与できます。

動作の調査

当研究室では Domain Admin アカウントを使用してテストを開始し、まずドメイン コントローラーの既定 userAccountControl 値 0x82000（10 進 532480）を試しました。これは、SERVER_TRUST_ACCOUNT（0x2000、10 進 8192）と TRUSTED_FOR_DELEGATION（0x80000、10 進 524288）のビット フラグの合計です。

userAccountControl の値を変更したところ、primaryGroupId は 516（Domain Controllers グループの RID）に更新されており、好調な滑り出しです！次に、SERVER_TRUST_ACCOUNT ビットだけでよいのかを確認したかったため、userAccountControl 属性を 8192 に設定し直して試しました。

これにより、プロトコル仕様の正確性を確認でき、primaryGroupId を変更させるのは SERVER_TRUST_ACCOUNT ビットだけであることがわかりました。

必要な権限を調査

考えられる悪用の経路を検討し始めます。 userAccountControl 属性を変更することができるだけであれば、興味深い 権限昇格 の手法につながる可能性があります。私たちは、 userAccountControl 属性を変更する権限だけを持つ権限のないアカウントでテストを開始しましたが、すぐにアクセス拒否エラーに遭遇しました。

MS-SAMR のドキュメントをもう少し下の行まで読んでいればよかったことがわかりました。userAccountControl 属性の第 5 節では、特定の userAccountControl ビットを設定するために必要な追加の権限が説明されています。 userAccountControl の UF_SERVER_TRUST_ACCOUNT ビットを設定するには、実行者（アクター）が DS-Install-Replica（「ドメイン内でレプリカを追加/削除」）権限をドメイン オブジェクト上で付与されている必要があります。

権限のないユーザーにこの権限を付与し、もう一度テストを試しました。

権限のないユーザーに対して、コンピューター上で userAccountControl を書き込む権限と、ドメイン オブジェクト上で DS-Install-Replica の権限を付与したところ、テストは成功しました。

デフォルトでは、DS-Install-Replica 権限は「Domain Admins」および「Enterprise Admins」グループに付与されます。したがって、設定が不十分な環境を除けば、このアプローチは特権昇格（privilege escalation）のベクトルにはなりません。ただし、必要となる権限が限られていることから、ドメインの持続性（domain persistence）に活用できるアプリケーション（用途）について考え始めました。

ドメインの持続性（domain persistence）のための用途

この方法が持続性（persistence）を実現する上で興味深い手段になり得るかを検討するにあたり、私たちはいくつかの要素を考慮しました。必要となる特権は限られていること、これらの特権は一般的にはあまり見直されないこと、(objectClass=computer) アカウントは作成しやすいこと、コンピューターは頻繁に確認されないこと（多くの組織が、古いコンピューターオブジェクトの問題に悩まされています）、そして仕組みの悪用が容易で、痕跡が短命で済むことです。

この仕組みの設定には、いくつかの小さな手順だけが必要です：

1. 偽のコンピューター（fake computer）または MSA、gMSA アカウントを作成します。既存のアカウントを使用することもできますが、持続性メカニズムの有効性はパスワード変更の頻度によって制限されます。とはいえ、既に存在するものの古くなっている（使用されなくなっている）コンピューターアカウントは、魅力的なターゲットになり得ます。
2. 侵害された通常ユーザー、グループ、または周知のエンティティに「Add/remove replica in domain」権限を付与します。これは、攻撃者が任意の通常ユーザーアカウントを侵害し、ドメインの主導権を再び取り戻せるようにするため、「Authenticated Users」を使用したものです。
3. コンピューターオブジェクトに対して「Write userAccountControl」権限を、上記の手順と同じエンティティに付与します。

既知のパスワードでコンピューターアカウントを作成する

一見すると自明に思えるかもしれませんが、既知のパスワードを使ってコンピューターアカウントを作成できる機能を、必ずしも全員が理解しているわけではないでしょう。たとえば New-ADComputer または New-ADServiceAccount の cmdlet を使用します。例：

New-ADComputer “ComputerName” -AccountPassword (ConvertTo-SecureString -AsPlainText -Force “Password”)

平文パスワードを知っていることは、いくつかの理由で有益です。最も重要なのは、ConvertTo-NTHash と ConvertTo-KerberosKey の cmdlet を、Michael Grafnetter の DSInternals PowerShell モジュールを使って用いることで、NTLM、AES-128、AES-256 のハッシュを計算できる点です。攻撃者がバックドアを悪用することを選択した場合、その権限を使用するためにコンピューター アカウントとして認証する必要があり、overpass-the-hash の手法で実行します。NTLM と AES のハッシュを指定することで、ほとんどの overpass-the-hash 検知を回避できます。

ドメイン支配の奪回

アカウントと権限を仕込んだ後、攻撃者が管理者の認証情報へのアクセスを失ったり、ネットワークから追い出されたりしても、ドメイン支配を取り戻すには、通常ユーザーを1人でも侵害すれば十分です。

どのユーザー アカウントであっても、攻撃者は用意してあるコンピューターの userAccountControl 属性を 0x2000（8192）に変更するだけで済みます。この変更により causes が発生し、即時のレプリケーションが行われます。つまり、攻撃者は特定のドメイン コントローラーを狙う必要がありません。userAccountControl が完了すると、攻撃者はドメイン コントローラーの権限を使ってドメインを侵害できます。

たとえば、攻撃者はコンピューター アカウントを使って DCSync を実行し、krbtgt のパスワード ハッシュを侵害できます。レプリケーションがドメイン コントローラーから来ているように見えるため、ほとんどの DCSync の脅威検知はその活動を検出しません。攻撃者が krbtgt のシークレットを複製できれば、userAccountControl を 0x1000（4096）に戻すだけで、コンピューター アカウントは通常のコンピューター アカウントとして見えるようになります。

手法の自動化

この手法の潜在的な有効性を示すために、私は GitHub で利用可能な2つの新しい PowerShell 関数を作成しました。

最初の関数 Add-ServerUntrustAccount は、3つのセットアップ手順を自動化します。既知のパスワードで偽のコンピューターアカウントを作成し、「Authenticated Users」に「Add/remove replica in domain」および「Write userAccountControl」の特権を付与します。

2つ目の関数 Invoke-ServerUntrustAccount はバックドアの悪用を自動化するもので、非特権ユーザーとして実行することを想定しています。この関数は userAccountControl 属性を 0x2000（8192）に設定し、その後 pass-the-hash を使用して偽のコンピューターアカウントとして認証し、krbtgt のハッシュに対して DCSync を実行し、最後に userAccountControl を 0x1000（4096）に戻します。

メカニズムの発見と悪用の検出

これやその他の類似した仕組みを見つけるには、組織は機密性の高い Active Directory 権限を定期的に監査する必要があります。“Add/remove replica in domain” のような機密性の高い権限の変更をリアルタイムで監視（場合によってはブロック）することも有益です。私たちは人気のある複数のオープンソースの Active Directory 権限監査ツールをテストしましたが、AD ACL Scanner だけが、攻撃者（adversary）の権限を問題があるものとして正しく強調表示しました。

Active Directory のイベントログ（すなわちイベント ID 5136 および 4662 ）は、ACL の変更に対する基本的なリアルタイム監視を提供し、ドメインレベルの「Add/remove replica in domain」権限を検知するのに利用できます。ただし、これらのイベントを分析する手順は簡単ではありません。

さらに、古くなっている（stale）コンピューター アカウント（および MSA と gMSA アカウント）を見つけて削除すること、またネットワーク上の実際のマシンと一致していないアカウントを特定することも重要です。たとえば、PowerShell を使えば古くなっている／未使用のコンピューター アカウントを素早く見つけられます（「-90」をドメインの最大コンピューター アカウント有効期限に置き換えてください）：

$Date = [DateTime]::Today.AddDays(-90); Get-ADComputer -Filter ‘(Enabled -eq $true) -and (PasswordLastSet -le $Date)’ | Select Name

悪用の検知

この手法を攻撃者が使用していることを検出するには、userAccountControl 属性の変更を監視することが中心となります。イベント ID 4742 – Computer Account Management は、userAccountControl の値の変更を監視するために使用できます。userAccountControl でビット 0x2000 が設定された状態への変更が、想定されるドメイン コントローラーの昇格(promotion)以外のタイミングで行われている場合は、心配な兆候です。

まとめ

もちろん、これは致命的な脆弱性ほど深刻ではありませんが、この種の手法は企業環境では見逃されることが多く、インシデント対応者の仕事をさらに難しくしてしまう可能性があります。私たちがテストした Active Directory の監査ツールでは検出率が低かったことから、見落とされやすいあまり知られていない挙動を悪用する、興味深い手法だと考えています。ご意見やご質問を歓迎します。さらに、Attack Catalog にあなたを案内しないのは不本意なので、ぜひご覧ください。ここでは、特定の攻撃がどのように機能するかをさらに学べます。