Active Directory セキュリティ監視における4つの課題

攻撃者が資格情報やデータを侵害するための新たな戦術を絶えず開発しているため、Active Directory（AD）のような重要なシステムで悪意のある活動の兆候を監視することが、これまで以上に重要になっています。

多くの組織は セキュリティ情報およびイベント管理（SIEM）製品に助けを求めます。しかし、これらのソリューションが非常に強力である一方で、最終的には Windows のイベントログに依存しています。Windows のイベントログは扱いが複雑であり、いくつかの重要な AD 攻撃ベクターを監視するのに必要な情報を提供しません。

このブログでは、Active Directory のセキュリティ確保における主要な課題 4 つを取り上げ、それらに対処するためにイベントログを使用することの限界について説明します。

課題 1：グループのメンバーシップ変更の監視

Active Directory のセキュリティグループ は、ユーザーにデータ、マシン、アプリケーションなどの IT リソースへのアクセス権を付与するための主要な手段です。攻撃者が環境内で横方向に移動するにつれて、乗っ取ったアカウントを新しいセキュリティグループに追加して追加の特権を得ることがよくあります。そのため、セキュリティグループのメンバーシップの変更を追跡することが不可欠です。

特権アクセスを提供するグループの変更を追跡することは、特に重要です。これには、Domain Admins、Enterprise Admins、Schema Admins などの組み込みグループに加え、組織が作成して昇格されたアクセス権を提供しているあらゆるセキュリティグループが含まれます。

イベント ログが取得する内容—およびその制限

Active Directory は、イベント ログでセキュリティ グループへの変更を追跡します。たとえば、ユーザーが Domain Admins グループに追加されると、AD は以下に示すようなイベントを生成し、次の主要な詳細が含まれます：

• 変更を実行したユーザーの ID
• 変更されたオブジェクトの DN とクラス
• 変更の種類（この場合はメンバーが追加されたこと）

図1. セキュリティ グループが変更されたことを示すサンプル イベント

ただし、イベント ログにはいくつかの重要な制限があります：

• · 変更がどこから発生したのかの記録がない — イベント ログは、グループのメンバーシップに対する変更の発信元（ソース）を記録しません。ジャンプ サーバーまたはドメイン コントローラー（DC）から Domain Admins グループが変更されることは正常である場合がありますが、管理者ではないワークステーションや、その他のインターネットに公開されたマシンからの変更は攻撃の手掛かりになり得ます。変更のソースに関する詳細がなければ、異常な場所からの変更を通知することは不可能です。
• · 有効なグループ メンバーシップを監視できない — Active Directory は、グループの直接メンバーシップに対する変更のみを記録します。 しかし、グループには他のグループをメンバーとして含めることができます。したがって、グループのメンバーシップ変更を本当に監視するには、グループ自体と、その中にネストされているすべてのグループを監視する必要があります。
• · イベント間の不整合 — ログに記録されるイベントは、グループがどのように変更されたかによって異なります。たとえば、Active Directory Service Interfaces（ADSI）を使ってユーザーをグループに追加した場合、イベント ログには「既存の各グループ メンバーごとに1つの削除イベント」が表示され、その後「各グループ メンバーを追加し直すイベント」が続き、最後に「新しいユーザーを追加するイベント」が表示されます。そのため、メンバーが50人のグループにユーザーを追加すると、101件のイベント ログ エントリが生成されます。さらに、変更が LDAP を使って行われた場合、識別名（distinguished name）の代わりにオブジェクトの GUID が記載されることがあります。こうした不整合は、SIEM 製品に混乱や誤った情報をもたらし、収集したデータに対して効果的に動作するルールを作成することを非常に難しくします。

課題 2. グループ ポリシー（Group Policy）の変更を監視する

グループ ポリシー（Group Policy）設定は Active Directory ドメイン 全体のユーザーやコンピューターに影響します。たとえば、システムへの管理アクセス権を持つのが誰か、といった点も含まれます。グループ ポリシー オブジェクト（Group Policy object）（GPO）の単一の変更だけでも、深刻なセキュリティへの影響や本番環境の停止につながり得るため、これらの変更を監視することが重要です。

イベント ログが記録するもの—およびその限界

グループ ポリシー（Group Policy）が変更されると、図 2 に示すようなイベントがログに記録されます。このイベントには、変更を行ったのが誰かや、GPO の識別子などの有用な情報が含まれます。

図 2. グループ ポリシー（Group Policy）の変更に対してログに記録されるイベント

ただし、これらのイベントには次の重要な情報が含まれていません。

• · どの設定が変更されたのか、その変更前後の値の詳細 — GPO は、数百におよぶ既製およびカスタム設定をサポートします。変更によって、ユーザーの既定のブラウザーのホームページが書き換わったり、重要なマシンに対する管理者権限がすべてのユーザーに付与されたりする可能性があります。しかし、イベントログには、変更された設定と、その変更後の内容が記録されません。
• · 変更の出どころ — セキュリティ グループの変更と同様に、グループ ポリシー（Group Policy）の変更を記録するイベントでは、変更がどこから行われたのかは示されません。ほとんどの GPO の変更は限られた数の場所から行われるべきであり、異常な場所からの変更を特定できることは、攻撃を素早く検知するうえで非常に重要です。

課題 3. ディレクトリの読み取りを監視する

Active Directory を保護するうえでのもう 1 つの重要なタスクは、ユーザー アカウントが AD オブジェクトをどのように読み取り、列挙（列挙）するかを監視することです。ネットワークに足場を築こうとする攻撃者は、権限の昇格につながり、最終的には機密データへ到達する攻撃経路を見つけるために、重要なアカウント、グループ、サーバーを列挙することがよくあります。不審な読み取りイベントを監視することで、この偵察活動を検知し、手遅れになる前に攻撃を止められます。

イベントログが記録する内容—およびその限界

Active Directory を調べているのが誰なのかを把握できるように、イベントログは読み取りアクティビティを記録します。イベントでは、ユーザーアカウント、読み取られているオブジェクト、実行中の操作の種類といった詳細が、図 3 のように示されます。

図 3：Domain Admins のプロパティが読み取られたことを示すイベント

しかし、これらのイベントを使って不審なアクティビティを監視しようとすると、いくつかの欠点があります：

• ノイズが多すぎる — 読み取りイベントをログに記録すると、イベントログ内にノイズが大量に発生してしまい、有益な情報を見つけることがほぼ不可能になります。実際、ユーザーがグループを閲覧するだけでも、ログには数十件、場合によっては数百件のイベントが生成されるため、正当なイベントの中から不審なアクティビティを探し出すのはほぼ不可能です。
• 読み取りがどこから来たかの記録がない — さらに、読み取りイベントがどこを起点として発生したのかを知る方法がありません。セキュリティ グループと GPO の変更で見てきたとおり、読み取りイベントがどのコンピューターから発生したのかを把握することは、それが無害な読み取りなのか、偵察を目的とした悪意のある行為なのかを判断するための重要な情報です。
• アクセス拒否イベントが多すぎる — 自分には閲覧権限がない情報を探ろうとしているユーザーを見つけることも同様に重要です。たとえば Active Directory では、コンピューター属性に管理者アカウントの平文パスワードを保存できるため、これらの属性を読み取ろうとするユーザー アカウントは、特権資格情報を侵害しようとしている可能性があります。残念ながら、どのアカウントであっても、どの目的であれオブジェクトを参照すると、その操作によって、意図していなかったとしても読み取り権限のないすべての属性についてアクセス失敗イベントが生成されます。無数の無害なイベントの海の中から、本当に疑わしい失敗アクセス イベントを見つけ出そうとするのは、現実的な戦略ではありません。
• LDAP クエリを手軽に監視できない — LDAP クエリは、Active Directory を探索してユーザー、グループ、コンピューターを見つけるために一般的に使用されます。残念ながら Microsoft は、発行されたクエリとその送信元を確認するための LDAP クエリ監視を簡単に行う方法を提供していません。この問題により、診断レベルの LDAP 監視を有効にしても得られる価値はわずかです。実際、イベント ログに膨大なノイズが発生するため、Microsoft はこの設定を推奨していません。

チャレンジ 4. 認証イベントの追跡

最近のクレデンシャルベースの攻撃の急増に伴い、認証パターンを監視することは、侵害されたアカウントや pass-the-hash の兆候、そして pass-the-ticket attacks、 forged Kerberos tickets または特権の獲得や機密データへのアクセスに悪用されるその他のエクスプロイトを特定するうえで極めて重要です。

イベントログが記録する内容 — そしてその限界

Active Directory は、ドメイン コントローラー、メンバー サーバー、ワークステーションでのユーザーのログオンおよび認証アクティビティを監視するためにイベントを収集します。以下の表に記載されているものも含まれます。

これらのイベントはいくつかの有用な情報を取得しますが、次のような欠点のため、認証に基づく攻撃を効果的に見つけるための方法にはなりません。

• ノイズが多すぎる — ユーザーがどのコンピューターにログオンするたびにイベントが作成されます。これは通常、非常に大量のアクティビティです。ほかにも、裏側で多数のイベントが作成されます。たとえば、ユーザーが AD ドメインに参加しているメンバー サーバーにログオンすると、サーバーはグループ ポリシー情報を取得するために DC への接続を開始し、その結果として、ログオン/ログオフのイベントが DC のイベントログに表示されます。ドメイン コントローラーに対する重要なログオン アクティビティを無視せずに、通常のユーザー ログオン アクティビティのログ記録を無効化する方法はありません。
• DC でログオン タイプの記録がない — ログは DC のログオン イベントに対するログオン タイプを追跡しません。これは、アカウントが適切な方法で使用されているかどうかを判断するうえで非常に重要な情報です。たとえば、リモート デスクトップ経由でログオンしたユーザーと、マップされたネットワーク ドライブ経由でのネットワーク ログオンとを簡単に区別できません。そのため、すべてのメンバー サーバーからログを収集し、DC のログと相関付けを試みる必要があります。
• プロトコル固有の詳細情報が不足している — イベントには他にも貴重な情報が欠けています。たとえば Kerberos 認証イベントでは、チケットの有効期限および更新期限のタイムスタンプが記録されません。これは、Golden Ticket exploit に使用された偽造チケットを見分けるための重要な手がかりとなります。同様に、NTLM ログには使用された NTLM のバージョンが指定されておらず、より安全なプロトコルに切り替えるために古い NTLM バージョンを無効化できるかどうかを判断するのに役立つ情報です。

Netwrix ができること

ご覧のとおり、イベントログだけでは攻撃を迅速に検知し、効果的に対応することができません。エンドツーエンドの保護のために、Netwrix Active Directory security solution を検討してください。次のことに役立ちます：

• 徹底的なリスク評価により、セキュリティ上のギャップを先回りして特定します。
• 高コストなダウンタイムや業務の中断を最小限に抑えます。
• 高度な脅威でもいち早く見つけ、すぐに対応しましょう。