Active Directoryは最も重要性の高いIT資産の1つであり、ハッカーに狙われることも多いため、そのセキュリティ確保はITチームとセキュリティチームにとって最優先事項です。そして、その役割の一環として、Active Directoryが侵害されていないことを確認する必要があります。
Windows向けActive DirectoryとAzureを合わせると、Microsoftはアイデンティティーおよびアクセス管理（IAM）ツール市場で50%を超えるシェアを占め、Fortune 1000企業の約95%も含まれるため、ハッカーにとってこれほど大きな成果をもたらす標的はほとんどありません。
ここでは、Active Directoryのいくつかの重要なコンポーネントについて、侵害の兆候を確認する方法を見ていきます。Active Directoryのセキュリティーに関するベストプラクティスに加えるべき重要な手順です。
「Active Directoryのセキュリティツールトップ」を参照
ADの侵害検知を改善したいとお考えですか？この記事のスポンサーであるSemperisは、AD、Azure AD/Entra ID、Okta、そしてTier 0の境界における露出の兆候と侵害の兆候を発見するため、Purple KnightとForest Druidを開発しました。これらの無料ツールによって監査全体がどれほど簡単になるかをご確認ください。
攻撃者の兆候を探す
Active Directory環境に到達できるほど巧妙な脅威アクターは、証拠を一切残さずに侵入できるほど巧妙である可能性もあり、その場合、Active Directoryが侵害されたかどうかを判断することは不可能です。
例えば攻撃者は、Domain Adminsグループに参加し、ハッキング活動を行った後、そのグループから離脱する可能性があります。監視を有効にしていれば、特権グループを監視することで、そのメンバー構成を確認できます。特権グループに所属しているものの、指定された管理者の一覧には載っていないメンバーを発見した場合は、その管理者を削除するか、そのユーザーがどのようにして特権グループのメンバーになったのかを調査できます。
多くは攻撃者の速さと能力にかかっています。攻撃者が、イベントログに一切のイベントを記録させない攻撃戦略を用いる可能性もあります。攻撃の兆候を探すために、ドメインに参加しているすべてのコンピューターやドメインコントローラーのイベントログを常に確認することはできません。Active Directoryが侵害されたかどうかを判断するには、重要なActive Directoryコンポーネントの状態確認を戦略の第一歩にすべきです。
攻撃者は、Active Directory管理者が把握・操作することの少ないActive Directoryコンポーネントを攻撃しようとする点に注意してください。これらのコンポーネントがそれぞれデフォルト状態にあることを確認し、その状態から変更されたものがないか判断する必要があります。調査すべきコンポーネントは数多くありますが、この記事では「重要な」ものだけに焦点を当てます。AdminSDHolder、既定のグループポリシーオブジェクト、PrimaryGroupID、ドメインコントローラーについて検証します。この記事の一覧だけでActive Directoryが侵害されたかどうかを判断するには不十分ですが、上記の項目は、攻撃者がActive Directoryへのアクセスに向けて操作を試みる典型的な対象です。
AdminSDHolderオブジェクトと特権アカウント
すべてのActive Directoryドメインには、Systemコンテナー配下にAdminSDHolderという一意のコンテナーがあります。Active Directoryドメインの最初のドメインコントローラーが展開されると、AdminSDHolderコンテナーも作成されます。特権アカウントが使用するアクセス許可を維持するのが、AdminSDHolderコンテナーの役割です。
SDPropプロセスは、コンテナーに適用されたアクセス許可を確認した後、AdminSDHolderコンテナーのアクセス許可をすべての特権アカウントにコピーします。通常のユーザーがAdminSDHolderオブジェクトを操作することはありません。しかし、十分な権限を持つ攻撃者はAdminSDHolderに設定されたアクセス許可を変更し、Active Directoryへのアクセス権を得ることができます。
AdminSDHolderコンテナーが誰かによって変更されたかどうかを確認するには、下のスクリーンショットに示すように、Attribute Editorでその「WhenChanged」属性を確認します。
上のスクリーンショットに示すように、AdminSDHolderコンテナーは3/23/2023（ドメインコントローラーが展開された日）に作成され、5/28/2023に変更されています。誰かが変更した場合、Securityタブにアクセス許可を追加した可能性が高いため、確認して不要であれば削除できます。Active Directoryドメインの展開後に、管理者がAdminSDHolderオブジェクトを操作する必要はありません。
グループポリシーオブジェクト：ハッカーの主要な標的
現在、攻撃者が主にGPO（グループポリシーオブジェクト）を標的にしていることを認識しておく必要があります。GPOは強力なActive Directoryオブジェクトです。GPOには非常に多くの設定があるため、ハッカーがアクセスできれば、設定を変更して標的コンピューターに適用したり、標的コンピューター上のスケジュールされたタスクを介して悪意のあるコードを実行したりできます。標的となるコンピューターには、ユーザーのアカウント、ドメインコントローラー、コンピューターアカウントなどがあります。
Active Directoryには、既定のグループポリシーオブジェクトとしてDefault Domain PolicyとDefault Domain Controllers Policyの2つが実装されている点に注意してください。これら2つのGPOは、Default Domain Policyを除き、展開後に変更されることはありません。会社のパスワードポリシー要件により、Default Domain PolicyのAccount Policiesを変更する必要が生じる場合がありますが、その変更も恒久的に行われます。
通常、環境内のユーザーアカウントやコンピューターアカウントに組織固有の設定やセキュリティ設定を適用したい場合は、新しいGPOを作成します。Attribute Editorを開くか、以下のPowerShellコマンドを使用すれば、既定のドメインポリシーと既定のドメインコントローラーポリシーの変更時刻をいつでも確認できます。このPowerShellコマンドは、ドメイン内のすべてのGPOとその変更時刻を一覧表示します。
$AllGPOs = Get-GPO -All -Server $ThisDomain | Select-Object DisplayName, ModificationTime$AllGPOsActive Directoryの展開日と、既定のドメインポリシーおよび既定のドメインコントローラーポリシーの変更時刻が異なる場合、誰かがActive Directoryへのアクセス権を得るためにこれらのGPOを変更した可能性があります。
PrimaryGroupID：より狙われやすい標的
最近では、攻撃者がActive Directoryを掌握するまでに必要な作業が少ないため、PrimaryGroupID攻撃がますます一般的になっています。
すべてのActive Directoryユーザーアカウントは、最初に既定のセキュリティグループである「Domain Users」に割り当てられ、これがユーザーのPrimaryGroupIDになります。ユーザーアカウントのPrimaryGroupIDは513、コンピューターアカウントのPrimaryGroupIDは515、ドメインコントローラーのPrimaryGroupIDは516です。
攻撃者はユーザーまたはコンピューターのPrimaryGroupIDを変更し、Active Directoryのデフォルトの動作を変えることができます。例えば、ユーザーのPrimaryGroupIDを変更してDomain Adminsグループに所属させれば、攻撃者にActive Directoryへの特権アクセスを与えることになります。
すべてのユーザー、コンピューター、ドメインコントローラーのアカウントを確認するには、PowerShellスクリプトを使用し、PrimaryGroupIDが変更されていないことを確認する必要があります。変更に気付いた場合は、誰かがActive Directoryへのアクセスを目的として、オブジェクトのデフォルトの所属先を変更しようとしたことを意味します。
ドメインコントローラーとそのデフォルトの場所
いったん実装されると、ドメインコントローラーは「OU=Domain Controllers, DC=Domain>, DC=local>」というデフォルトの場所に置かれ続けます。
Active Directory内のデフォルトの場所にあるため、ドメインコントローラーは、ドメインコントローラーの保護を目的としたDefault Domain Controllers Group Policyからグループポリシー設定を確実に受け取ります。
ドメインコントローラーをデフォルトの場所から移動すると、これらの設定を受け取らず、代わりに別のグループポリシーオブジェクトから設定を受け取る可能性があります。例えば、適切な権限を持つ攻撃者であれば、1台以上のドメインコントローラーを、別のGPOが適用された別の組織単位へ移動できます。そのGPOに、悪意のあるコードを実行するスケジュールされたタスクが含まれている可能性もあります。常に簡単なPowerShellスクリプトを実行するか、セキュリティ評価ツールを利用して、各ドメインコントローラーがデフォルトの組織単位に配置されていることを確認してください。
以下は、Active Directoryフォレスト内のすべてのドメインコントローラーの場所を確認するのに役立つ短いPowerShellスクリプトです。このスクリプトは、Active Directoryフォレストからすべてのドメインコントローラーを取得し、Active Directory内でそれぞれのコンピューターアカウントの場所を1つずつ確認します。ドメインコントローラーがデフォルトの組織単位に配置されていない場合は、その結果が画面に表示されます。
$ComputersList = "C:\Temp\DCList.TXT"
Remove-Item $ComputersList -ErrorAction SilentlyContinue
$R = (Get-ADForest).Domains | % { Get-ADDomainController -Discover -DomainName $_ } | % { Get-ADDomainController -server $_.Name -filter * } | Select HostName
foreach ($Item in $R)
{
$ThisDC = $Item.HostName
Add-Content $ComputersList $ThisDC
}
Foreach ($ComputerItem in Get-Content "$ComputersList")
{
$NameOne, $NameTwo = $ComputerItem.Split(".")
$Error.Clear()
$RNow = Get-ADComputer $NameOne -Server $ComputerItem
$DCName = $RNow.DistinguishedName
$CurLocName = $DCName
$RemovedComma = $CurLocName.replace(",", " ")
$DCT1, $DCT2, $DCT3 = $DCName.split(",")
IF ($DCT2 -eq "OU=Domain Controllers")
{
}
else
{
Write-Host "WARNING: Domain Controller is not located in its default OU"
}
}まとめ：ハッカーからActive Directoryを守る
侵害の兆候を探すため、重要なActive Directoryコンポーネントの状態を確認することは、管理者が定期的に実践すべきベストプラクティスです。ドメインコントローラーのコンピューターアカウントのデフォルトの場所、AdminSDHolderコンテナー、既定のグループポリシーオブジェクト、PrimaryGroupID、および侵害を検知する手法について説明しましたが、その他のコンポーネントやActive Directoryのベストプラクティスについては、今後の記事で取り上げます。
関連記事：