NetCease と SAMRi10 を使用した内部偵察の防護

内部偵察とは何ですか？

内部偵察は、攻撃者がネットワーク内でユーザーまたはコンピューターアカウントを侵害した後に行う最初のステップの1つです。攻撃者はさまざまなツールやスクリプトを使用して情報を列挙・収集し、望む結果を得るために次にどの資産を侵害しようとするべきかを特定できるようにします。たとえば、BloodHound は、攻撃者が一般ユーザーから管理者へ権限を昇格できる攻撃パスをマッピングします。

ほとんどすべての一般的な列挙（enumeration）手法は、権限のないユーザーでも実行できます。そのため、検知してブロックすることが非常に困難になります。この記事では、内部偵察の2種類に対する防御として、どのように活用するのかを説明します：

• 権限のないユーザーによるセッション列挙
• 次へのクエリ：MS-SAMR protocol

偵察の種類

侵入したネットワークに関する情報を見つけるため、攻撃者はしばしば次の種類のデータを列挙します。:

• セッション — 誰がどこにログオンしているかを確認するため
• ユーザー — ドメイン内のすべてのユーザーを把握するため（可能なら所属するグループも含めて）
• グループ — ドメイン内のすべてのグループを確認するため（可能ならメンバーも含めて）
• Active Directory アクセス制御リスト（ACL） — どのセキュリティプリンシパル（ユーザーやグループなど）が、どのリソースにアクセスできるかを理解するため
• ローカル グループのメンバーシップ — そのマシンで誰がアクセス権を持っているかを確認するため（特に管理者権限を持つユーザー）

NetCeaseでセッション列挙（Session Enumeration）をブロックする

このブログ記事では、セッション列挙（session enumeration）に焦点を当てています。これにより、攻撃者はユーザーアカウントやサービスアカウントがどこにログインしているかを特定できるようになります。この情報は、管理者がログインしているホストなど、最初に侵害を試みるべきホストの優先順位を決めるのに役立ちます。

注記： Windows 10 の既定の権限は、攻撃者がセッション列挙を実行できないように変更されています。ただし、やはり確認しておく価値はあります。

NetCease は、NetSessionEnum メソッドの権限を制御するレジストリ キーを変更することで、セッション列挙を防ぐのに役立つ短い PowerShell スクリプトです。（これを手動ではなくスクリプトで実施する理由は、対象のキーである SrvsvcSessionInfo が、reg のバイナリ値でのみ編集可能だからです。）SrvsvcSessionInfo キーへのパスは次のとおりです：

パス： HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/DefaultSecurity

SrvsvcSessionInfo レジストリ キーの既定値は、NetSessionEnum メソッドの使用を許可する ACL です。これは次のものに割り当てられます:

• Administrators のメンバー
• Server Operators のメンバー
• Power Users のメンバー
• 認証済みユーザー

「Authenticated Users」の権限により、攻撃者は侵害された任意のユーザー アカウントを使用してセッションの偵察を行えます。

NetCease スクリプトは、現在のレジストリ値をバックアップしたうえで権限を変更し、次の ACE が ACL に含まれるようにします:

• InteractiveSid
• ServiceSid
• BatchSid
• Administrators
• Server Operators
• PowerUsers

ACL を確認中

セキュリティ記述子を表示するには、次の PowerShell のスニペットを使用できます。これにより ACL が表示されます：

      #Registry Key Information
$key = "HKLM:SYSTEMCurrentControlSetServicesLanmanServerDefaultSecurity"
$name = "SrvsvcSessionInfo"

#Get the Registry Key and Value
$Reg_Key = Get-Item -Path $key
$BtyeValue = $reg_Key.GetValue($name, $null)

#Create a CommonSecurityDescriptor Object using the Byte Value
$Security_Descriptor = New-Object -TypeName System.Security.AccessControl.CommonSecurityDescriptor -ArgumentList $true, $false, $ByteValue, 0

#Output of the ACL to make it simple to see for document. Use only $Security_Descriptor.DiscretionaryAcl if you want to see the full ACL!
$Security_Descriptor.DiscretionaryAcl | Select-Object SecurityIdentifier, ACEType | Format-Table -AutoSize
      

NetCease 実行前の出力：

NetCease 実行後の出力：

注： 有名な SID に関する情報はこちら。

セッション列挙のテスト

一般ユーザー アカウントによるセッション列挙（session enumeration）をブロックできているかどうかを簡単にテストするには、 NetSess Joeware.net のツールを使用しますが、SharpHound など他にもさまざまな選択肢があります。実施する際は、Administrators、Server Operators、または Power Users のメンバーではないユーザー アカウントを使用していることを確認してください。

NetCease 使用前の出力

      Netsess.exe [Computer]
      

低権限アカウントで NetCease を使用した後の出力

      Netsess.exe [Computer]
      

特権ユーザー アカウントで NetCease を使用した後の出力

      Netsess.exe [Computer]
      

Remote SAM（SAMR）を使用した偵察（Reconnaissance）のブロック

攻撃者は SAMR プロトコルを使用して偵察（reconnaissance）を実行できます。SAMR はリモートでデバイスを照会できるだけでなく、Active Directoryも照会できます。SAMR を使うと、攻撃者は管理者権限が一切なくても、高度に特権を持つグループやユーザー、さらにネットワーク上のすべてのシステムに対するローカル ユーザーやグループを見つけることが可能です。その後、BloodHound のようなツールを使えば、この情報を自動的に攻撃パス（attack paths）へマッピングして、Active Directory を侵害（compromise）することができます。

Microsoft は Windows 10 で、SAMR を照会する際の保護機能を導入し、2017 年には RestrictRemoteSAM レジストリ キーを使用して、Windows 7 および Server 2008 R2 までの以前のオペレーティング システムに対する更新を追加しました。このキーは文字列（REG_SZ）であり、Remote SAM 呼び出し（calls）を保護するセキュリティ記述子（security descriptor）の SDDL が格納されます。

Windows 10（1607）のアニバーサリー エディションおよび Windows Server 2016 以降では、既定の SDDL が変更され、Remote SAM を照会できるのはローカル管理者のみとなりました。

以下の表は、すべてのオペレーティング システムについて、要件、既定の動作、および保護オプションを整理したものです：

RestrictRemoteSAM レジストリ キーを設定する方法は 3 つあります：

• レジストリ
• グループポリシー
• SAMRi10 (Samaritan)

それぞれを見ていきましょう。

レジストリ オプション

RestrictRemoteSAM レジストリ キーは、管理者が必要に応じて更新できるよう用意されています。

パス：HKLM/System/CurrentControlSet/Control/Lsa

名前：RestrictRemoteSAM

Windows 10 の既定値（SDDL）：O:SYG:SYD:(A;;RC;;;BA)

SDDL の構成要素

ご覧のとおり、Windows 10 が設定する既定値は、Owner と Primary Group が SYSTEM、Built-in Administrators が Read Control です。

適用する前に SDDL を確認する

変更を適用する前に SDDL が正しいことを確認するには、PowerShell の ConvertFrom-SDDLString コマンドを使用して、読み取りやすい security descriptor（セキュリティ記述子）に変換できます。

グループ ポリシーまたはローカル セキュリティ ポリシーのオプション

グループ ポリシーとローカル セキュリティ ポリシー の設定により、管理者はこのキーを簡単に設定できます。これは、すべてのシステム、または複数のシステム グループに対して同じ値を設定したい管理者にとって効果的です（例：特定の OU 内のすべてのサーバー、または特定のアプリケーション サーバー群に対して Remote SAM 接続を許可する）。

設定の詳細は以下のとおりです：

SAMRi10（Samaritan）オプション

SAMRi10 は、以前のオプションに比べて重要な利点を提供する PowerShell スクリプトです。新しいローカル グループを作成し、そのグループが Remote SAM の呼び出しを実行できるようにアクセス権を委任します。これにより、管理者は Group Policy Preferences でこの機能を完全に制御することも、必要に応じてアカウントに手動で権限を付与することも可能になります。

SAMRi10 スクリプトは次の処理を行います：

1. 「Remote SAM Users」という名前のローカル グループを作成します
2. 新しく作成したグループを含めるように SDDL を修正します：
   • デフォルトの SDDL がない場合は、Built-in Administrators にアクセス権を付与します。
   • SDDL が存在する場合は、Remote SAM Users グループ向けの新しい ACE を含めるようにそれを修正します。

SAMRi10 を使用するメリット

• Remote SAM アクセスのためのきめ細かなアクセス権を簡単に付与
• 最小特権アクセスを徹底したい組織を支援します
• ローカル グループ メンバーシップ の Group Policy と組み合わせて使用し、項目レベルのターゲティングによりユーザーのアクセスを一元的に付与できます
• privileged access management (PAM) システムで、アカウントまたはプロセスがこの特定の権限を必要とする場合に、動的（ジャストインタイム）アクセスを簡単に付与できます

Netwrix ソリューションで偵察（Reconnaissance）に対抗する

Netwrix StealthAUDIT には攻撃パス分析機能が含まれており、管理者が Active Directory ACL を把握できるようにすることで、攻撃者に悪用される前に潜在的なギャップを埋められます。 Netwrix StealthINTERCEPT LDAP クエリを監視し、その後 Netwrix StealthDEFEND に渡します。これにより、BloodHound を含む、すべての SPN へのクエリや、 password never expires を持つすべてのアカウントへのクエリなど、複数の偵察シナリオとクエリを標準で検出できます。

よくある質問

内部リコンとは何で、なぜ気にする必要があるのでしょうか？

内部リコン（内部偵察）は、攻撃者がすでにあなたのネットワークへの初期アクセスを獲得した後に、価値の高い標的を見つけるために環境を洗い出し（マッピング）し始めるときに発生します。もう侵入しているわけではありません。すでにログイン済みで、周囲を見回しているのです。ここで多くのセキュリティ戦略が行き詰まります。攻撃者が正規の資格情報を使って内部を自由に移動しているのに、対策は境界防御ばかりに偏ってしまうからです。

現実はシンプルです。見えないものは守れず、理解していないものは制御できません。内部リコンは、攻撃者が Active Directory の構造に関する情報を集め、高価値アカウントを特定し、最も機密性の高いデータへの到達経路をマッピングするための重要な段階です。 Data security は Identity から始まります。つまり、そもそも攻撃者があなたのアイデンティティ基盤を列挙（enumerating）できないようにすることが必要です。

セッション列挙（session enumeration）を防ぐために、NetCease をどのように導入しますか？

NetCeaseは、不正なユーザーがドメインコントローラーおよびサーバー上のアクティブなセッションを一覧表示できないようにすることで、セッション列挙攻撃を阻止します。実装はシンプルですが、計画が必要です。まず、公式リポジトリから NetCease をダウンロードし、PowerShell 5.1 以降を搭載したシステムで実行していることを確認してください。

前提条件：

• 管理者権限
• PowerShell 5.1 以降
• Windows Server またはドメイン参加済みのシステム

このツールは、セッション列挙要求に対して Windows Server サービスがどのように応答するかを制御するレジストリ設定を変更することで動作します。保護したい各サーバーで、管理者権限にて NetCease を実行してください。テストは重要度の低いシステムから始めることを推奨します。変更は再起動を必要とせずすぐに反映されますが、正当な管理ツールや監視ソリューションが引き続き適切に機能することを必ず確認してください。

ベストプラクティスは、環境全体に一度に展開するのではなく、NetCease を段階的に導入することです。まずは業務においてクリティカルなアプリケーションをホストしていないサーバーから開始し、影響（中断）がないかを監視したうえで、ドメインコントローラーやその他の高優先度のターゲットへ拡張してください。偵察（reconnaissance）を防ぐことは、ネットワークを見えなくすることではありません。攻撃者の作業をより困難にし、検知システムが悪意のある活動を特定するまでの時間を増やすことが目的です。

SAMRi10 と Group Policy による SAM 制限の違いは何ですか？

SAMRi10 と Group Policy はどちらも Security Account Manager（SAM）データベースへのアクセスを制限しますが、動作するレベルが異なり、用途（ユースケース）も異なります。SAMRi10 は PowerShell スクリプトで、各マシン上のレジストリ設定を直接変更するため、特定のシステムに対して SAM のアクセス制限をきめ細かく制御できます。

Group Policy による SAM 制限はドメイン レベルで機能し、複数のシステムに対して同時に一貫したポリシーを適用できます。Group Policy のアプローチは、多数のマシンに対して一様な保護が必要な大規模展開に適しています。SAMRi10 は、特定のサーバー、テスト環境、または標準の Group Policy テンプレートに当てはまらないカスタム構成が必要な状況に最適です。

技術的な実装方法も異なります。SAMRi10 は RestrictRemoteSAM レジストリキーを直接変更するのに対し、Group Policy は同じ結果を得るために管理用テンプレートの仕組みを使用します。どちらの方法も有効ですが、SAMRi10 の方がトラブルシューティングやカスタム設定において柔軟性が高くなります。多くの組織では、ハイブリッドアプローチが最も効果的です。ドメイン全体のベースラインとなる SAM 制限には Group Policy を使用し、その後、追加の強化が必要な特定のシステムに対して SAMRi10 を使用します。

偵察（reconnaissance）に対する防護措置が機能していることを、どのように確認しますか？

偵察（reconnaissance）に対する防護をテストするには、業務を中断せずに実際の攻撃者の手口をシミュレートする、体系的なアプローチが必要です。まずは非管理者アカウントで NetSess のようなツール、または PowerShell の Get-WmiObject コマンドを使って基本的なセッション列挙テストを行います。NetCease が正しく動作していれば、これらの試行は失敗するか、限られた情報しか返さないはずです。

SAM の制限については、Linux システムから enum4linux や rpcclient のようなツールを使って、または Windows から net use コマンドを使って、Security Account Manager データベースへのリモートアクセスをテストします。適切に設定された SAM の制限では、不正な列挙の試行はブロックされつつ、正当な管理者のアクセスは引き続き許可されるはずです。

ポイントは、攻撃者の視点からテストすることです。標準ユーザー権限でテスト用アカウントを作成し、ドメイン列挙、共有の発見、ユーザーアカウントの一覧表示など、一般的な偵察（reconnaissance）手法を試してみます。うまくいくこと／うまくいかないことを記録し、その結果に基づいて防護策を調整してください。効果的なセキュリティとは、すべてを遮断することではありません。正当な業務機能が引き続き適切に動作することを確実にしつつ、どの情報が誰に対して利用可能であるかを制御することが重要です。

NetCease と SAMRi10 の変更は、いつロールバックすべきですか？

ロールバックのシナリオは、通常、正当な管理ツールとの互換性の問題、予期しないアプリケーションの障害、またはテスト中に特定されなかった業務プロセスの中断が関係します。NetCease と SAMRi10 のいずれもロールバックのオプションを提供しますが、各ツールで手順が異なります。

NetCease のロールバックは、セッション列挙を制御するレジストリの変更を元に戻すことです。ツールには元の設定に復元するためのパラメーターが含まれていますが、変更を行う前に必ず baseline configuration を記録してください。手順とタイミングを理解できるように、まずはラボ環境でロールバック手順をテストしてください。

SAMRi10 のロールバックは、複数のレジストリキーを含み、場合によってはグループポリシー（Group Policy）との相互作用が関係するため、より複雑です。グループポリシーを通じて SAM の制限を実装している場合は、ポリシー管理ツールを使って変更を元に戻してください。レジストリを直接変更した場合は、SAMRi10 には復元機能が含まれますが、完全にロールバックできていることを確認するために手動での検証が不可欠です。

最適なアプローチは事前に備えることです。メンテナンスウィンドウ中に変更を実施し、ロールバック手順を文書化してテストしておき、導入後少なくとも 24〜48 時間は影響を受けるシステムを綿密に監視してください。多くの互換性の問題はすぐに表面化しますが、一部は特定の業務プロセスやシステム操作の中で初めて明らかになる場合があります。