Ein PowerShell-Skript zur Eindämmung von Sicherheitsrisiken in Active Directory

Cyberangreifer nutzen häufig veraltete Technologien als Teil ihrer Angriffsstrategien und nehmen Organisationen ins Visier, die noch keine Gegenmaßnahmen implementiert oder veraltete Komponenten aktualisiert haben. In einer Active-Directory-Umgebung sind ältere Protokolle eine solche Komponente, die Angreifer nutzen können, um Zugriff auf Active Directory zu erlangen.

Das Patchen (oder sogar virtuelle Patchen) kann zwar helfen, veraltete Komponenten zu adressieren, doch die meisten älteren Komponenten wurden von Angreifern gründlich daraufhin untersucht, ob sie durch eine neuere Version ersetzt oder vollständig deaktiviert werden sollten. Das gilt auch für ältere Active-Directory-Protokolle. Um Sie bei der Absicherung Ihrer Active-Directory-Umgebung zu unterstützen, haben wir daher ein Skript erstellt, mit dem Sie sicherstellen können, dass ältere Protokolle deaktiviert sind.

Das wichtigste Ziel bei der Absicherung der Active-Directory-Infrastruktur besteht darin, die Angriffsfläche zu verkleinern. Es gibt zahlreiche weitere Aspekte, die berücksichtigt werden müssen, um die Angriffsfläche von Active Directory zu reduzieren. Ältere Protokolle gehören jedoch zu den wichtigen Punkten, die kürzlich identifiziert wurden. Wir erklären die älteren Protokolle in Active Directory und sehen uns anschließend an, wie Sie überprüfen können, ob sie auf allen Domänencontrollern in einer Active-Directory-Gesamtstruktur deaktiviert sind.

Ebenfalls lesenswert: So erkennen Sie, ob Active Directory kompromittiert wurde

Welche älteren AD-Protokolle sollten deaktiviert werden?

Der Diebstahl von Zugangsdaten bleibt relativ einfach, wenn die Angriffsfläche durch ältere Protokolle nicht reduziert wird, da die meisten Angreifer versuchen werden, Schwachstellen auszunutzen, die mit älteren Protokollen und ihren Komponenten verbunden sind. Microsoft empfiehlt, die folgenden älteren Protokolle in neueren Betriebssystemversionen zu deaktivieren:

• TLS-Version 1.1
• NTLM-Version 1.1 oder LAN Manager
• SMB-Version 1

Was vor der Deaktivierung älterer Protokolle zu beachten ist

Es ist wichtig zu verstehen, dass Active-Directory-Anwendungen diese Protokolle verwenden. Führen Sie daher vor der Deaktivierung eines dieser Protokolle eine gründliche Prüfung der Active-Directory-Anwendungen durch, die darauf zurückgreifen. Wenn eine wichtige Anwendung noch eines dieser Protokolle verwendet, deaktivieren Sie es nicht, solange Sie die Folgen nicht verstehen. Vor der Deaktivierung der Unterstützung für ältere Protokolle müssen Sie außerdem alle Geräte und Anwendungen aktualisieren, damit sie neuere Protokollversionen verwenden. Wie das geht, erklären wir weiter unten.

TLS-Version 1.1 deaktivieren

TLS ist ein fast zwei Jahrzehnte altes Protokoll und wurde als anfällig für Angriffe wie BEAST und POODLE eingestuft. Das TLS-1.1-Protokoll weist mehrere Nachteile auf:

• Wie bei allen älteren Protokollen unterstützt TLS 1.1 eine schwache Kryptografie. Das stellt ein Sicherheitsrisiko dar, da Tools verfügbar sind, mit denen sich Pakete mit schwacher Kryptografie entschlüsseln lassen.
• TLS 1.1 trägt außerdem nicht dazu bei, moderne Verbindungen sicher zu verschlüsseln.
• TLS 1.0 weist den Mangel auf, dass es eine unzureichende Kryptografie unterstützt. TLS 1.2 hat sich in den meisten Softwareimplementierungen gegenüber TLS 1.1 durchgesetzt, sodass Letzteres relativ selten verwendet wird. Aus Sicht eines Angreifers wird jede Verwendung von TLS 1.1 jedoch zu einer potenziellen Waffe in seinem Arsenal.

Azure-Tipp: Microsoft hat die TLS-1.1-Unterstützung von PowerShell bereits deaktiviert. Wenn Sie versuchen, ein PowerShell-Skript zur Verbindung mit Azure auszuführen, wird eine Fehlermeldung angezeigt, die darauf hinweist, dass das TLS-1.1-Protokoll deaktiviert werden muss, bevor das Skript ausgeführt werden kann. Weitere Informationen zur Anweisung zum Deaktivieren von TLS finden Sie hier: TLS-1.2-Unterstützung aktivieren, da Azure AD TLS 1.0/1.1 veraltet ist – Active Directory | Microsoft Learn.

Ermitteln, ob Geräte und Anwendungen noch TLS-Version 1.1 verwenden

Es ist schwierig festzustellen, welche .NET-Anwendungen in Ihrer Umgebung das TLS-1.1-Protokoll verwenden, sofern Sie nicht mehrere Verfahren kombinieren, etwa die Aktivierung der Secure-Channel-Protokollierung auf dem Domänencontroller, den Einsatz eines Paketerfassungstools oder höchstwahrscheinlich die Verwendung von Wireshark.

Um mithilfe der Secure-Channel-Methode festzustellen, ob eine Ihrer .NET-Anwendungen in Ihrer Umgebung noch das TLS-1.1-Protokoll verwendet, aktivieren Sie die Secure-Channel-Protokollierung auf den Domänencontrollern. Suchen Sie nach der Ereignis-ID 36880, nachdem Sie die Secure-Channel-Protokollierung aktiviert haben. Sie protokolliert die zum Herstellen der Verbindung verwendete Protokollversion. Um die IP-Adresse des Clients zu ermitteln, der versucht hat, die niedrigere Version des TLS-1.1-Protokolls auszuhandeln, müssen Sie mehrere Ereignisse miteinander abgleichen.

In den meisten Fällen können Sie beim Anbieter der Anwendung nachfragen, ob die Anwendung das TLS-1.1-Protokoll noch verwendet. Wurde die Anwendung intern entwickelt, wenden Sie sich an das Entwicklungsteam, um die TLS-1.1-Unterstützung zu deaktivieren und aus Sicherheitsgründen die neuere Version zu verwenden.

NTLM-Version 1.1 oder LAN Manager deaktivieren

Bei Sicherheitsprüfungen von Active Directory für Kunden stelle ich häufig fest, dass Kunden für ihre Anwendungen noch das ältere NTLM-Protokoll Version 1 verwenden oder es einfach aktiviert gelassen haben, obwohl die Anwendungen in ihrer Umgebung das Protokoll NTML Version 1.0 überhaupt nicht verwenden.

Das NTLM-Protokoll wird hauptsächlich von den Geräten und Anwendungen verwendet, die in Ihren Active-Directory-Umgebungen ausgeführt werden. Beachten Sie, dass NTLM für die Authentifizierung auf Grundlage eines Challenge-Response-Systems entwickelt wurde, bei dem ein Client den Benutzernamen im Klartext an den Domänencontroller sendet. Der Domänencontroller generiert beim Empfang des Klartextbenutzernamens vom Client eine Zufallszahl, die als „Challenge“ bezeichnet wird, und sendet sie an den Client zurück. Der Client verschlüsselt die Challenge mithilfe des Passwort-Hashs und sendet sie als „Response“ an den Domänencontroller zurück.

Der entscheidende Punkt ist, dass ein Client bei Verwendung von NTLM 1.1 die vom Server empfangene „Challenge“ unverändert übernimmt, die Client-Nonce hinzufügt, sie mit DES verschlüsselt und an den Server zurücksendet. Verwendet der Client hingegen NTML Version 2.0, fügt er weitere Parameter hinzu, etwa Client-Nonce + Server-Nonce + Zeitstempel + Benutzername + Ziel. Der Unterschied zwischen NTML Version 1 und NTLM Version 2 liegt in den Parametern, die beim Zurücksenden der Response an den Domänencontroller verwendet werden. Diese zusätzlichen Parameter können dazu beitragen, die Kommunikation zwischen Client und Server zu schützen.

Der Domänencontroller fragt die SAM-Datenbank ab und vergleicht die in der Datenbank gespeicherte und die vom Client empfangene „Challenge“. Stimmen die Daten überein, darf sich der Client authentifizieren.

Ermitteln, ob Geräte und Anwendungen noch NTLM Version 1.0 verwenden

Um zu prüfen, ob eines Ihrer Geräte oder eine Ihrer Anwendungen in Ihrer Umgebung noch das NTLM-Version-1.0-Protokoll verwendet, suchen Sie auf den Domänencontrollern nach der Ereignis-ID 4624 – Ein Konto wurde erfolgreich angemeldet. Öffnen Sie das Ereignis und suchen Sie den Abschnitt „Detaillierte Authentifizierungsinformationen“. Dort sehen Sie das verwendete „Authentifizierungspaket“. Wenn unter „Paketname“ „LM oder NTLM v1“ steht, hat das Gerät oder die Anwendung, das bzw. die sich am Domänencontroller authentifiziert hat, das NTLM-Version-1.0-Protokoll verwendet. Dieses Gerät oder diese Anwendung muss aus Sicherheitsgründen auf NTML Version 2.0 aktualisiert werden.

SMB-Version 1.0 deaktivieren

Ein weiteres älteres Protokoll, das in einer Active-Directory-Umgebung deaktiviert werden muss, ist SMB Version 1.0. SMB 1.0 ist ein altes Protokoll, das entwickelt wurde, damit Geräte über verschiedene Netzwerkebenen hinweg miteinander kommunizieren können. Um beispielsweise auf SMB-Freigaben zuzugreifen, kann sich ein SMB-Client mit einem Server verbinden, auf dem SMB ausgeführt wird.

Es ist jedoch wichtig zu beachten, dass SMB 1.0 ein 30 Jahre altes Protokoll ist, das durch zahlreiche Verbesserungen in der SMB-Protokollfamilie überholt wurde. Inzwischen gibt es SMB 3.0, das Verschlüsselung und Signierung mit schwachen Hashing-Verfahren unterstützt. Aufgrund der zunehmenden Cybersecurity-Bedrohungen und der Tatsache, dass Active Directory ein primäres Ziel für Angreifer ist, wird empfohlen, SMB 1.0 auf Domänencontrollern vollständig zu deaktivieren und SMB 2.0 oder höher zu verwenden. Vor der Deaktivierung von SMB 1.0 müssen jedoch die Geräte identifiziert werden, die noch über das SMB-1.0-Protokoll kommunizieren.

Ermitteln, ob Geräte/Anwendungen noch das SMB-1.0-Protokoll verwenden

Sie müssen die SMB-Sitzungen auf allen Domänencontrollern untersuchen, um festzustellen, welche Version der Client bei der Verbindung mit den Domänencontrollern über SMB verwendet. Die zwischen Client und Domänencontroller (Server) verwendete SMB-Version ist die neueste Version, die beide unterstützen. Wenn beispielsweise ein Windows-8-Computer mit einem Windows-2012-Server kommuniziert, wird das SMB-3.0-Protokoll verwendet. Kommuniziert hingegen ein Client mit einer älteren Windows-Version mit einem Windows-Server und ist SMB 1.0 aktiviert, wird das SMB-1.0-Protokoll verwendet. Melden Sie sich am Domänencontroller an und führen Sie anschließend den Befehl Get-SmbConnection aus, um die SMB-Sitzungen zu überprüfen. Alle Verbindungen und die „Dialect“-Angabe werden vom Befehl Get-SmbConnection aufgelistet. Das Feld „Dialect“ gibt an, ob Clients Verbindungen über SMB 1.0, SMB 2.0 oder SMB 3.0 anfordern.

PowerShell-Skript zur Prüfung auf ältere Protokolle auf Domänencontrollern

Mit dem folgenden PowerShell-Skript können Sie überprüfen, ob alle oben genannten Protokolle auf den Domänencontrollern deaktiviert sind. Nach Abschluss des PowerShell-Skripts wird eine CSV-Datei mit dem Status aller Domänencontroller für jedes Protokoll erstellt. Der Status ist in der jeweiligen Protokollspalte zu sehen.

Anforderungen an das Skript: Bitte stellen Sie sicher, dass Sie alle unten aufgeführten Anforderungen erfüllen, bevor Sie das Skript ausführen.

1. Führen Sie das Skript mit einem Domänenadministratorkonto aus, da es eine Verbindung zu jedem Domänencontroller in einer Active-Directory-Domäne herstellt, um Registrierungseinträge zu überprüfen und anschließend den Status der Protokolle zu melden.
2. Stellen Sie sicher, dass der Computer der Domäne beigetreten ist.
3. Stellen Sie sicher, dass das Verzeichnis C:\Temp auf dem Computer vorhanden ist, auf dem das Skript ausgeführt wird.

$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
   }
}

Nach Abschluss des obigen Skripts sehen Sie eine Berichtsdatei unter „C:Temp LegacyProtocolsStatus.CSV“, die den Status aller Protokolle enthält, wie im folgenden Screenshot dargestellt.

Beachten Sie, dass Sie die Domänencontroller überprüfen und Maßnahmen zur Deaktivierung des Protokolls ergreifen müssen, wenn eines der Protokolle aktiviert ist, um Sicherheitsrisiken in Ihrer Active-Directory-Gesamtstruktur einzudämmen.

Fazit: Die Deaktivierung älterer Protokolle in Active Directory ist entscheidend

Active Directory und Azure Active Directory (jetzt Microsoft Entra ID) machen rund 60 % des Marktes für Identitäts- und Zugriffsverwaltung (IAM) aus und sind die primären Ziele von Hackern. Daher ist die Verbesserung der Active-Directory-Sicherheit von entscheidender Bedeutung, um die Ressourcen einer Organisation zu schützen. Die Deaktivierung älterer Protokolle ist ein wichtiger Schritt hin zu mehr Sicherheit in Active Directory. Hacker suchen nach diesen Schwachstellen – das sollten Sie ebenfalls tun.

Weiterführende Lektüre:

• Die wichtigsten Sicherheitstools für Active Directory
• Living-off-the-Land-Angriffe: Definition und Prävention von LOTL
• Cybersecurity-Behörden veröffentlichen Leitfaden zur PowerShell-Sicherheit