デジタルペンテスト部でペネトレーションテストを担当している小松奈央です。
突然ですが、皆さんの会社ではコンピューターアカウントの棚卸しをしていますか？
従業員の退職時にユーザーアカウントを削除するなど、ユーザーアカウントはしっかり管理している企業が多いと感じます。 一方で、従業員が使用していたクライアント端末に紐づくコンピューターアカウントは削除されず、大量のコンピューターアカウントが残存しているケースをよく見かけます。
これらのコンピューターアカウントに脆弱なパスワードが設定されている場合、ネットワークに侵入した攻撃者によって権限昇格や横展開に悪用される可能性があります。
そこで本記事では、Active Directoryにおいてコンピューターアカウントに脆弱なパスワードが設定される原因とその対策について解説します。
免責事項
当記事の内容は教育・学習およびセキュリティの向上目的で執筆されており、サイバー攻撃行為を推奨するものではありません。 第三者が所有する資産に管理者の許可なく攻撃行為を行うと各種の法律に抵触する可能性があります。 当記事の内容を使用して起こるいかなる損害や損失に対し、当社は一切責任を負いません。
忙しい方向けの要約
- 通常は強固なパスワードが自動的に設定されるはずのコンピューターアカウントに、脆弱なパスワードが設定されることがある
- コンピューターアカウントのリセット
- コンピューターアカウント作成時の互換設定の有効化
- 特定のコンピューターアカウント作成方法
- 脆弱なパスワードが設定されているコンピューターアカウントは、他の脆弱性と組み合わせることで権限昇格や横展開などに悪用可能となる
- コンピューターアカウントもユーザーアカウントと同様に定期的な棚卸しが必要（具体的な対策はこちら）
本記事執筆のきっかけとなるできごと
（本項目は読み飛ばしていただいても大丈夫です。）
以前、ある企業に対してペネトレーションテストを実施していたときのことです。
複数の脆弱性を発見し、それらを組み合わせることで、あと少しで標的となるネットワークに横展開できそうといった状況でした。
そのとき横展開の手段として有効そうだったのが、本ブログでもたびたび取り上げているRBCD（Resource-based Constrained Delegation）攻撃です。 RBCD攻撃による侵入を成立させるための条件のうち、任意のコンピューターアカウントのNTLMハッシュを入手している、という条件を除く、すべての要件を達成していました。
- RBCD攻撃による侵入条件と当時の達成状況
- ✅ドメインコントローラーのOSバージョンがWindows Server 2012以上
- ✅侵入先となるコンピューターオブジェクトのmsDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限を持つユーザーアカウント権限の入手
- ✅侵入先となるコンピューターオブジェクトのDelegate元が未設定
- ✅侵入先となるコンピューターオブジェクトに紐づく実端末が存在する
- ✅侵入先端末で侵入に利用可能なサービス（SMBなど）が動作している
- ❌任意のコンピューターアカウントのNTLMハッシュを入手している
コンピューターアカウントのNTLMハッシュの入手手段としては、「コンピューターアカウントの新規作成」や「侵害済み端末のSAMレジストリからダンプ」などが挙げられます。 しかし、このときは様々な要因によりこれらの手段が使えず、コンピューターアカウントのNTLMハッシュがどうしても入手できずにいました。
そのような状況の中、ふとあることを思い出しました。 それは、ペネトレーションテストの一環でNTDS.ditをダンプ1しユーザーアカウントのパスワードを解析する際に、「コンピューター名と同じパスワードが設定されたコンピューターアカウント」や「空のパスワードが設定されたコンピューターアカウント」が見つかることがある、ということです。
これを思い出した私は、コンピューターアカウントに対しコンピューター名と同じパスワードの組み合わせや空のパスワードでパスワードスプレー攻撃を行うことで、コンピューターアカウントのNTLMハッシュの入手に成功しました。 これによりRBCD攻撃を実現でき、無事にレッドチームの目的である対象ネットワークへの侵入を達成することができました。
ここで一つの疑問点が浮かび上がります。
それは、通常は強固なパスワードが自動的に設定されるはずのコンピューターアカウントに、なぜコンピューター名と同じパスワードや空のパスワードが設定されていたのか、ということです。
コンピューターアカウントの脆弱なパスワード
通常、コンピューターアカウントのパスワードは、ランダムかつ桁数の長いパスワードがOSによって生成・管理されます。 さらに、このパスワードは30日ごとに自動的に変更されます。
では、なぜ通常は強固なパスワードが自動的に設定されるはずのコンピューターアカウントに、コンピューター名と同じパスワードや空のパスワードなどの脆弱なパスワードが設定されることがあるのでしょうか。
この疑問点について調べてみたところ、原因をまとめている素晴らしい記事がすでにありました。
ここでは、この記事を参考に自身で検証した内容をまとめます。
コンピューター名と同じパスワード
「コンピューター名と同じパスワードが設定される」というのは、例えば「TEST01\$」というコンピューターアカウント2であれば、コンピューター（ホスト）名に該当する「TEST01」をすべて小文字にした「test01」がパスワードとして設定されるということです。
以下のいずれかの操作や運用を行っている場合、本事象が発生します。
- 既存のコンピューターアカウントをリセットする
- コンピューターアカウントを手動で作成する際に、「Assign this computer account as a pre-Windows 2000 computer（このコンピューターアカウントをWindows 2000より前のコンピューターとして割り当てる）」にチェックを入れる
それぞれのパターンについて、詳しく説明します。
コンピューターアカウントのリセット
Active Directory上にすでに存在するコンピューターアカウントを、ドメインコントローラーからリセットすることができます。 コンピューターアカウントをリセットした場合、コンピューターアカウントとそれに紐づく実端末との関連付けが解除され、改めてドメインに参加し直さない限りドメインへログインできなくなります。 なお、コンピューターアカウントそのものはドメイン上に残ります。
この操作によって、コンピューターアカウントにコンピューター名と同じパスワードが設定されてしまいます。
実際に、このときのパスワードを確認してみましょう。 以下の図は、ダンプしたNTDS.ditを解析した結果です。 コンピューターアカウント「TEST01\$」のパスワードが、コンピューター名と同じ「test01」であることを確認できます。
次に認証を試してみます。以下の図は、SMB経由によるNTLM認証を試みた際のログです。 1回目は通常のコンピューターアカウントに対して、2回目はリセットしたコンピューターアカウントに対して、それぞれコンピューター名と同じパスワードで認証しています。 いずれも認証には失敗していますが、1回目は「STATUS_LOGON_FAILURE」、2回目は「STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT」と異なるエラーメッセージが表示されており、2回目認証時のコンピューターアカウントとパスワードの組み合わせが正しいことを示しています。
攻撃手法に該当してしまうため具体的な方法は割愛しますが、エラーメッセージが「STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT」の場合は当該コンピューターアカウントのパスワードを変更することが可能であり、他の攻撃に悪用できます。
また、Kerberos認証であればパスワードを変更することなく認証に成功3します。
Windows 2000より前のコンピューターとして割り当て
Active Directoryでは通常、端末をドメインに参加させるタイミングで自動的に対応するコンピューターアカウントが作成されます。 一方で、コンピューターアカウントを事前に作成しておき、端末をドメインに参加させる際に実端末と作成済みのコンピューターアカウントを紐づけることも可能です。
事前にコンピューターアカウントを作成する際に、「Assign this computer account as a pre-Windows 2000 computer（このコンピューターアカウントをWindows 2000より前のコンピューターとして割り当てる）」にチェックを入れている場合、コンピューターアカウントにコンピューター名と同じパスワードが設定されてしまいます。
実際にパスワードを確認してみます。 以下の図は、ダンプしたNTDS.ditを解析した結果です。 コンピューターアカウント「TEST02\$」のパスワードが、コンピューター名と同じ「test02」であることを確認できます。
NTLM認証時の挙動やパスワード変更による悪用が可能であること、Kerberos認証であればパスワード変更なしで認証可能であることは、アカウントリセット時と同様です。
空のパスワード
空のパスワードは、コンピューターアカウントの作成方法に依存して設定される可能性があります。
通常、ユーザーアカウントやコンピューターアカウントには空のパスワードを設定することができません。 しかし、アカウントの「PASSWD_NOTREQD」属性が有効である場合、管理者権限でのみ空のパスワードの設定が可能となります。
特定のコンピューターアカウント作成方法や、一部の資産管理ツールでは、このフラグが有効化された上で、コンピューターアカウントに空のパスワードを設定することがあります。
例として、MicrosoftによるActive Directoryオブジェクト管理ツール「Dsadd」を使用し、コンピューターアカウントを作成してみます。 作成したコンピューターアカウントのプロパティを確認すると、「PASSWD_NOTREQD」属性が有効であることがわかります。
実際にパスワードを確認してみます。 以下の図は、ダンプしたNTDS.ditに含まれるパスワードハッシュです。 コンピューターアカウント「TEST03\$」のパスワードハッシュは「31d6cfe0d16ae931b73c59d7e0c089c0」であり、これは空のパスワードを示す特徴的なハッシュです。 そのため、パスワードハッシュの解析をするまでもなく、コンピューターアカウント「TEST03\$」のパスワードが空のパスワードであることを確認できます。
次にNTLM認証とKerberos認証をそれぞれ試した結果です。 いずれも認証に成功していることを確認できます。
対策
ここまで、コンピューターアカウントに脆弱なパスワードが設定される原因を解説してきました。 では、どのように本問題を対策すればよいのでしょうか。
まず、直接的な対策としては、以下が考えられます。
- 脆弱なパスワードが設定される可能性のある操作・運用を避ける
- （１）コンピューターアカウントのリセット操作を避ける
- （２）コンピューターアカウント作成時に「Assign this computer account as a pre-Windows 2000 computer（このコンピューターアカウントをWindows 2000より前のコンピューターとして割り当てる）」を使用しない
- （３）空のパスワードが設定される可能性のあるコンピューターアカウントの作成方法を避ける
（１）と（２）に関しては、コンピューターアカウントのリセットまたは作成後、コンピューターアカウントを実端末と紐づける（実端末をドメインに参加させる）ことでパスワードが自動的に変更されることを確認しています4。 そのため、コンピューターアカウントを放置せず、コンピューターアカウントを実端末と紐づけるか、使用しない場合はコンピューターアカウントを削除することが重要です。
（３）に関しては、コンピューターアカウントの作成方法に依存するため、画一的な対策を挙げることが困難です。 もし、サードパーティ製のActive Directory管理ツールを使用してドメイン参加を行っている場合は、念のため一度製品仕様を確認してみることをお勧めします。
また、継続的な対策として、定期的にコンピューターアカウントの棚卸しを行い、実端末に紐づかない不要なコンピューターアカウントは削除することも効果的です。
おわりに
昨今はクラウド（Entra IDなど）への移行を進めている企業も多いですが、まだまだActive Directoryに依存している企業がほとんどだと思います。
ユーザーアカウントと比べて対策が見落とされがちなコンピューターアカウントですが、悪用される可能性がある以上、しっかり存在を把握し適切に管理することが重要です。 本記事が、システム点検のきっかけになれば幸いです。
なお、冒頭で登場したRBCD（Resource-based Constrained Delegation）攻撃については、過去に本ブログでも解説しています。 興味のある方は、こちらもぜひご覧ください。
参考文献
- Finding Weak AD Computer Passwords | by Giulio Pierantoni | Medium
- Disable machine account password changes - Windows Server | Microsoft Learn
- UserAccountControl property flags - Windows Server | Microsoft Learn
- Dsadd | Microsoft Learn
- Use Directory Service to manage AD objects - Windows Server | Microsoft Learn
- NTDS.ditとは、Active Directoryにおけるドメインコントローラー上に存在するデータベースファイルであり、ドメインアカウントのパスワードハッシュが格納されています。ペネトレーションテストでは、ドメインアカウントのパスワード強度を調査する目的でNTDS.ditをダンプし、オフラインパスワードクラックによって平文パスワードの特定を試みることがあります。↩
- Active Directoryでは、コンピューター（ホスト）名の末尾にドル記号を付与したものがコンピューターアカウント名として扱われます。↩
- Kerberos認証であればパスワードの変更なく認証に成功することに気がついたとき、これに気づいたのは自分が世界で1人目なんじゃないかと舞い上がりましたが、2022年の時点ですでに気づいている方がいました（Filip Dragovic（@filip_dragovic）氏によるポスト）。↩
- あくまで私の検証環境における検証結果である点はご了承ください。↩
