このPowerShellスクリプトでActive Directoryのセキュリティリスクを軽減する

サイバー攻撃者は、攻撃戦略の一環としてレガシーテクノロジーを頻繁に利用し、対策をまだ実装していない、あるいは旧式のコンポーネントをアップグレードしていない組織を標的にします。Active Directory環境では、レガシープロトコルがその一例です。攻撃者はこれらを利用してActive Directoryへのアクセス権を得ることができます。

一方、パッチ適用（あるいは仮想パッチ）によって旧式のコンポーネントに対処できる場合もありますが、ほとんどのレガシーコンポーネントは、より新しいバージョンに置き換えるべきか、完全に無効化すべきかを判断するため、攻撃者によって十分に評価されています。Active Directoryのレガシープロトコルも同様です。そこで、Active Directory環境の安全性を確保できるよう、レガシープロトコルが無効になっていることを確認するスクリプトを作成しました。

Active Directoryインフラストラクチャのセキュリティを確保するうえでの主な目標は、攻撃対象領域を縮小することです。Active Directoryの攻撃対象領域を縮小するには、ほかにも考慮すべき問題が数多くありますが、レガシープロトコルは最近特定された重要な問題の1つです。ここではActive Directoryのレガシープロトコルについて説明し、続いてActive Directoryフォレスト内のすべてのドメインコントローラーで、レガシープロトコルが無効になっているかどうかを確認する方法を紹介します。

無効にすべきActive Directoryのレガシープロトコル
レガシープロトコルを無効にする前の考慮事項
TLSバージョン1.1を無効にする
NTLMバージョン1.1またはLAN Managerを無効にする
SMBバージョン1.0を無効にする
ドメインコントローラーのレガシープロトコルを確認するPowerShellスクリプト
結論：Active Directoryでのレガシープロトコルの無効化は不可欠

無効にすべきActive Directoryのレガシープロトコル

レガシープロトコルの露出を抑えなければ、認証情報の窃取は依然として比較的容易です。多くの攻撃者は、レガシープロトコルとそのコンポーネントに関連する脆弱性を悪用しようとするためです。Microsoftは、オペレーティングシステムの新しいバージョンでは、次のレガシープロトコルを無効にするよう推奨しています。

TLSバージョン1.1
NTLMバージョン1.1またはLAN Manager
SMBバージョン1

レガシープロトコルを無効にする前の考慮事項

Active Directoryアプリケーションはこれらのプロトコルを使用するため、いずれかを無効にする前に、該当するプロトコルを使用しているActive Directoryアプリケーションを綿密に評価することが重要です。重要なアプリケーションがまだこれらのプロトコルのいずれかを使用している場合は、その影響を理解しないまま無効にしないでください。また、レガシープロトコルのサポートを無効にする前に、すべてのデバイスとアプリケーションをアップグレードし、新しいバージョンのプロトコルを使用できるようにする必要があります。その方法を以下で説明します。

TLSバージョン1.1を無効にする

TLSは登場から約20年が経過したプロトコルで、BEASTやPOODLEなどの手法による攻撃に対して脆弱であることが確認されています。TLS 1.1プロトコルには、次のような欠点があります。

すべてのレガシープロトコルに共通する問題ですが、TLS 1.1は脆弱な暗号方式をサポートしています。脆弱な暗号方式で暗号化されたパケットを復号するツールが存在するため、これはセキュリティリスクになります。
また、TLS 1.1では最新の接続を安全に実現することもできません。
TLS 1.0には、不十分な暗号方式をサポートしているという欠陥があります。ほとんどのソフトウェア実装ではTLS 1.2がTLS 1.1を上回っており、後者は比較的まれになっています。しかし攻撃者の立場からすれば、TLS 1.1が少しでも使用されていれば、攻撃手段になり得ます。

Azureのヒント：Microsoftはすでに、PowerShellでのTLS 1.1プロトコルのサポートを無効にしている点に注意してください。PowerShellスクリプトを実行してAzureに接続しようとすると、スクリプトを実行する前にTLS 1.1プロトコルを無効にする必要があることを示すエラーメッセージが表示されます。TLSを無効にするステートメントについて詳しくは、こちらを参照してください：Azure ADのTLS 1.0/1.1は非推奨：TLS 1.2のサポートを有効にする – Active Directory | Microsoft Learn。

デバイスやアプリケーションが依然としてTLSバージョン1.1を使用しているかどうかを特定する

ドメインコントローラーでSecure Channelのログを有効にしたり、パケットキャプチャツールを使用したり、より一般的にはWiresharkを使用したりするなど、複数の手法を組み合わせない限り、環境内のどの.NETアプリケーションがTLS 1.1プロトコルを使用しているかを特定するのは困難です。

Secure Channelの方法で、環境内の.NETアプリケーションがTLS 1.1プロトコルをまだ使用しているかどうかを確認するには、ドメインコントローラーでSecure Channelのログを有効にします。Secure Channelのログを有効にした後、接続の確立に使用されたプロトコルのバージョンを記録するイベントID 36880を探してください。TLS 1.1プロトコルの低いバージョンとのネゴシエーションを試みたクライアントのIPを特定するには、複数のイベントを関連付ける必要があります。

ほとんどの場合、アプリケーションベンダーに問い合わせれば、そのアプリケーションがTLS 1.1プロトコルをまだ使用しているかどうかを確認できます。アプリケーションを社内で開発している場合は、開発チームに問い合わせてTLS 1.1のサポートを無効にし、セキュリティを高めるために新しいバージョンを使用してください。

NTLMバージョン1.1またはLAN Managerを無効にする

顧客のActive Directoryセキュリティ評価を実施すると、顧客がアプリケーションでレガシーのNTLMバージョン1プロトコルをまだ使用している、あるいは環境内のアプリケーションがNTMLバージョン1.0プロトコルをまったく使用していないにもかかわらず、有効にしたままにしていることがよくあります。

NTLMプロトコルは、主にActive Directory環境で稼働するデバイスやアプリケーションによって使用されます。NTLMは、クライアントがドメインコントローラーに平文のユーザー名を送信する、チャレンジ／レスポンス方式に基づく認証システムで認証を行うよう設計されている点に注意してください。ドメインコントローラーは、クライアントから平文のユーザー名を受け取ると、「チャレンジ」と呼ばれる乱数を生成し、クライアントに送り返します。クライアントはパスワードハッシュを使ってチャレンジを暗号化し、「レスポンス」としてドメインコントローラーに送り返します。

ここで問題となるのは、クライアントがNTLM 1.1を使用している場合、サーバーから受け取った「チャレンジ」をそのまま利用し、クライアントのノンスを追加してDES暗号化で暗号化し、サーバーに送り返すことです。一方、クライアントがNTMLバージョン2.0を使用する場合は、クライアントのノンス＋サーバーのノンス＋タイムスタンプ＋ユーザー名＋ターゲットなど、ほかのパラメーターを追加します。NTMLバージョン1とNTLMバージョン2の違いは、ドメインコントローラーにレスポンスを返す際に使用するパラメーターにあります。これらの追加パラメーターにより、クライアントとサーバー間の通信を保護できます。

ドメインコントローラーはSAMデータベースに問い合わせ、データベースに保存されている「チャレンジ」とクライアントから受け取ったチャレンジを比較します。データが一致すれば、クライアントは認証を許可されます。

デバイスやアプリケーションが依然としてNTLMバージョン1.0を使用しているかどうかを特定する

環境内のデバイスやアプリケーションがNTLMバージョン1.0プロトコルをまだ使用しているかどうかを確認するには、ドメインコントローラーでイベントID 4624 – アカウントが正常にログオンしました、を探します。イベントを開き、「詳細な認証情報」セクションで、使用中の「認証パッケージ」を確認します。「パッケージ名」に「LMまたはNTLM v1」と表示されている場合、そのドメインコントローラーで認証したデバイスまたはアプリケーションはNTLMバージョン1.0プロトコルを使用しています。そのデバイスまたはアプリケーションは、セキュリティを高めるためにNTMLバージョン2.0へアップグレードする必要があります。

SMBバージョン1.0を無効にする

Active Directory環境で無効にすべきもう1つのレガシープロトコルが、SMBバージョン1.0です。SMB 1.0は、さまざまなネットワーク層をまたいでデバイス同士が通信できるよう設計された古いプロトコルです。たとえばSMB共有にアクセスする場合、SMBクライアントはSMBを実行しているサーバーに接続できます。

ただし、SMB 1.0は登場から30年が経過したプロトコルであり、SMBプロトコルファミリーにはこれまで多くの改良が加えられている点に注意が必要です。現在はSMB 3.0があり、脆弱なハッシュ方式を使用した暗号化と署名をサポートしています。サイバーセキュリティの脅威が増大し、Active Directoryが攻撃者の主な標的となっていることから、ドメインコントローラーではSMB 1.0を完全に無効にし、SMB 2.0以降を使用することが推奨されます。ただしSMB 1.0を無効にする前に、SMB 1.0プロトコルで通信を続けているデバイスを特定する必要があります。

デバイス／アプリケーションが依然としてSMB 1.0プロトコルを使用しているかどうかを特定する

SMB経由でドメインコントローラーに接続する際にクライアントが使用しているバージョンを特定するには、すべてのドメインコントローラーでSMBセッションを調べる必要があります。クライアントとドメインコントローラー（サーバー）の間で使用されるSMBのバージョンは、双方がサポートする最新のバージョンになります。たとえば、Windows 8マシンがWindows 2012サーバーと通信する場合はSMB 3.0プロトコルが使用されます。一方、古いバージョンのWindowsクライアントがWindowsサーバーと通信し、SMB 1.0が有効になっている場合は、SMB 1.0プロトコルが使用されます。ドメインコントローラーにログオンし、Get-SmbConnectionコマンドを実行してSMBセッションを確認します。Get-SmbConnectionコマンドでは、すべての接続と「Dialect」が一覧表示されます。「Dialect」フィールドは、クライアントがSMB 1.0、SMB 2.0、SMB 3.0のいずれを介して接続を要求しているかを示します。

ドメインコントローラーのレガシープロトコルを確認するPowerShellスクリプト

以下のPowerShellスクリプトを使用すると、前述したすべてのプロトコルがドメインコントローラーで無効になっていることを確認できます。PowerShellスクリプトが完了すると、各プロトコルについて、すべてのドメインコントローラーのステータスを記載したCSVファイルが生成されます。ステータスは、該当するプロトコル列で確認できます。

スクリプトの要件： スクリプトを実行する前に、以下の要件をすべて満たしていることを確認してください。

スクリプトはドメイン管理者アカウントで実行してください。スクリプトはActive Directoryドメイン内の各ドメインコントローラーに接続してレジストリエントリを確認し、プロトコルのステータスを報告するためです。
コンピューターがドメインに参加していることを確認してください。
スクリプトを実行するコンピューターにC:\Tempディレクトリが存在することを確認してください。

$ResultFile = "C:\Temp\LegacyProtocolsStatus.CSV"
Remove-Item $ResultFile -ErrorAction SilentlyContinue
$STR = "Domain Controller, Connection Status, TLS 1.1 Status, SMB 1 Status, NTLM Status"
Add-Content $ResultFile $STR

$GDCList = "C:\Temp\AllDCs.TXT"
Remove-Item $GDCList -ErrorAction Continue

$R = (Get-ADForest).Domains | % { Get-ADDomainController -Discover -DomainName $_ } | % { Get-ADDomainController -server $_.Name -filter * } | Select HostName, Domain, Forest, IPv4Address, Site
foreach ($Item in $R)
{
     Add-Content $GDCList $Item.HostName
}

Foreach ($ItemName in Get-Content "$GDCList")
{
   $TLStatus = "Unknown"
   $SMBStatus = "Unknown"
   $NTLMStatus = "Unknow"
   Write-Host "Checking Connection for Domain Controller: $ItemName"

   $Error.Clear()
   $ConnectionCheck = Get-WMIObject Win32_Service -computer $ItemName
   IF ($Error.Count -ne 0)
   {
      $STR = $ItemName + ",Connection Error" + $TLStatus + "," + $SMBStatus + "," + $NTLMStatus
      Add-Content $ResultFile $STR
   }
   else
   {
      Write-Host "Connection Success!

      Write-Host "Checking TLS 1.1. Status..."
      $result = Invoke-Command -ComputerName $ItemName -ScriptBlock {
         $supported = [Net.ServicePointManager]::SecurityProtocol
         [PsCustomObject]@{
            SystemDefault = [bool]($supported -eq 0)
            Tls11 = [bool]($supported -band 768)
            }
      }
      $TLStatus = $result.Tls11

      Write-Host "Checking SMB 1.0 Status..."
      $ThisRegKey = "HKLM:\SYSTEM\CurrentControlSet\Services\LANManServer\Parameters"
      $ThisRegEntry = "SMB1"
      $Error.Clear()
      $dbs = Invoke-Command -ComputerName $ItemName -ScriptBlock { Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\LANManServer\Parameters' -Name "SMB1" }
      IF ($Error.Count -eq 0)
      {
         $CheckValue = $dbs.SMB1
         IF ($CheckValue -ne "0")
         {
            $SMBStatus = "Enabled"
         }
         else
         {
            $SMBStatus = "Disabled"
         }
      }
      else
      {
         IF ($Error.Exception.Message -match "Property SMB1" -or $Error.Exception.Message -match "Cannot find path")
         {
            $SMBStatus = "Enabled"
         }
         else
         {
            $SMBStatus = "ConnectionError"
         }
      }

      Write-Host "Checking NTLM Status..."
      $ThisRegKey = "HKLM:\SYSTEM\CurrentControlSet\Services\Lsa"
      $ThisRegEntry = "LmCompatibilityLevel"
      $Error.Clear()
      $dbs = Invoke-Command -ComputerName $ItemName -ScriptBlock { Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Lsa' -Name "LmCompatibilityLevel" }
      IF ($Error.Count -eq 0)
      {
         $CheckValue = $dbs.LmCompatibilityLevel
         IF ($CheckValue -ne "5")
         {
            $NTLMStatus = "Enabled"
         }
         else
         {
            $NTLMStatus = "Disabled"
         }
      }
      else
      {
         IF ($Error.Exception.Message -match "Property LmCompatibilityLevel" -or $Error.Exception.Message -match "Cannot find path")
         {
            $NTLMStatus = "Enabled"
         }
         else
         {
            $NTLMStatus = "ConnectionError"
         }
      }

      $STR = $ItemName + ",Connection Ok" + $TLStatus + "," + $SMBStatus + "," + $NTLMStatus
      Add-Content $ResultFile $STR
   }
}

上記のスクリプトが完了すると、下のスクリーンショットに示すように、すべてのプロトコルのステータスを記載したレポートファイル「C:Temp LegacyProtocolsStatus.CSV」が表示されます。

Screenshot of a legacy protocols status sample.

いずれかのプロトコルが有効になっている場合は、ドメインコントローラーを確認し、Active Directoryフォレストのセキュリティリスクを軽減するため、そのプロトコルを無効にする措置を講じる必要があります。

結論：Active Directoryでのレガシープロトコルの無効化は不可欠

Active DirectoryとAzure Active Directory（現在のMicrosoft Entra ID）は、IDおよびアクセス管理（IAM）市場の約60%を占め、ハッカーの主な標的となっています。そのため、組織の資産を保護するには、Active Directoryのセキュリティ強化が極めて重要です。レガシープロトコルを無効にすることは、Active Directoryのセキュリティ向上に向けた重要な一歩です。ハッカーはこうした脆弱性を探しているため、私たちも同じように確認すべきです。

関連記事：