Huy Kha | Senior Architekt für Identität und Sicherheit

Active Directory (AD) steht immer noch im Mittelpunkt der meisten Unternehmensumgebungen, und Angreifer wissen das. Da die Bedrohungen zunehmend auf die Identität abzielen, ist AD nach wie vor ein Schlüsselpunkt für den Zugang und die Ausweitung von Privilegien. Das Problem ist, dass viele der gleichen Fehlkonfigurationen und Versäumnisse in verschiedenen Unternehmen auftreten, unabhängig von deren Größe oder Branche.

Nach der Überprüfung der Ergebnisse mehrerer Active Directory Security Assessments (ADSAs) im Jahr 2025 hat das Team von Semperis Identity Forensics and Incident Response (IFIR) ein klares Muster erkannt. Bestimmte Risiken tauchen einfach immer wieder auf. Einige sind bekannt, werden aber nicht angegangen, während andere ohne die richtigen Tools oder den richtigen Überblick leicht zu übersehen sind.

In diesem Beitrag gehe ich die 10 häufigsten AD-Risiken in realen Umgebungen durch und erkläre, was sie sind, warum sie wichtig sind und wie Angreifer sie ausnutzen.

Risiko 1: Durch falsch konfigurierte Berechtigungen geöffnete Angriffswege der Stufe 0

Eine der gefährlichsten Fehlkonfigurationen, die das IFIR-Team bei ADSA-Einsätzen beobachtet hat, ist, wenn Konten oder Gruppen durch indirekte Berechtigungen mit DCSync-Rechten ausgestattet werden. Das bedeutet nicht, dass jemand die Berechtigungen direkt zugewiesen hat. Stattdessen könnte zum Beispiel ein nicht privilegiertes Konto Teil einer Gruppe sein, die volle Kontrollrechte über ein privilegiertes Konto hat, das bereits über DCSync-Funktionen verfügt.

Infolgedessen muss ein Angreifer nicht direkt auf das privilegierte Konto abzielen. Er kann sich das schwächere Glied in der Kette vornehmen und erhält trotzdem Zugriff auf die gleiche Ebene der Kontrolle. Die Fehlkonfiguration erfolgt in der Regel, weil die Berechtigungen zu weitreichend delegiert werden, was zu einer indirekten Tier 0-Verletzung führt(Abbildung 1).

Abbildung 1. Dieser Scan zeigt einen Indikator für eine Gefährdung (IOE), die durch eine Fehlkonfiguration der delegierten Berechtigungen entstanden ist.

Ein weiteres Beispiel für einen Angriffspfad, der zu einer Tier 0-Verletzung führt, ist die Kompromittierung eines Kontos mit Schreibrechten auf Domänencontroller (DC)-Objekte(Abbildung 2). Dieser Zugriff kann missbraucht werden, um einen RBCD-Angriff (Resource-Based Constrained Delegation) durchzuführen, der es dem Angreifer ermöglicht, sich als ein Konto mit hohen Rechten auszugeben.

Abbildung 2. Dieser Indikator zeigt nicht standardmäßige Benutzer oder Gruppen an, denen Schreibzugriff auf ein DC-Objekt gewährt wurde.

Risiko 2: Übermäßiger Gebrauch von integrierten AD-Gruppen mit hohen Rechten

Ältere Windows-Umgebungen enthalten häufig integrierte Gruppen, die für die delegierte Verwaltung von Funktionen wie Kontobetreiber, Server-Betreiber, Backup-Betreiber und Druck-Betreiber vorgesehen sind. Diese Gruppen werden oft übersehen, können aber dennoch über hohe Privilegien in Active Directory verfügen(Abbildung 3). Wenn diese Gruppen besetzt sind, können ihre Mitglieder Aktionen durchführen, die zu einer Eskalation der Berechtigungen und direktem Zugriff auf Tier 0-Ressourcen führen.

Abbildung 3. Bei diesem Scan wird das AD auf alte integrierte Gruppen mit hohen Rechten untersucht, die ein Sicherheitsrisiko darstellen.

Die fortgesetzte Verwendung älterer integrierter Gruppen erhöht das Risiko einer Kompromittierung, insbesondere wenn die Konten in diesen Gruppen nicht genau überwacht oder kontrolliert werden. Bewährte Verfahren empfehlen im Allgemeinen, dass Sie sich nicht auf die meisten integrierten Gruppen in AD (z.B. DnsAdmins, DHCP-Administratoren, Gruppenrichtlinienersteller, Remotedesktop-Benutzer) verlassen sollten, da diese häufig über weitreichende Berechtigungen verfügen(Abbildung 4).

Abbildung 4. Dieser Indikator identifiziert Mitglieder gemeinsamer integrierter Gruppen, die über weitreichende Berechtigungen verfügen können.

Risiko 3: Unsichere LAN Manager-Konfiguration

NT LAN Manager Version 1 (NTLMv1) ist ein veraltetes Authentifizierungsprotokoll, das in einigen Umgebungen immer noch erstaunlich weit verbreitet ist - was es aber nicht sein sollte. Es verwendet eine schwache Kryptographie, die es Angreifern leicht macht, den Authentifizierungsverkehr abzufangen und zu knacken(Abbildung 5). Wenn ein Angreifer einen Rechner dazu bringt, sich mit NTLMv1 zu authentifizieren (in der Regel mit einem Angriffstool wie Responder), kann er den Passwort-Hash abfangen und offline knacken, um das Textpasswort zu erhalten.

Abbildung 5. Diese Warnung von Microsoft weist auf die Anfälligkeit von veralteten Authentifizierungsprotokollen hin.

Derzeit unterstützen alle Microsoft-Betriebssysteme die neuere NT LAN Manager Version 2. Bevor Sie NTLMv2 in der gesamten Domäne erzwingen, sollten Sie zunächst die NTLM-Überprüfung aktivieren, um Systeme oder Anwendungen zu identifizieren, die noch NTLMv1 verwenden. Sobald Sie die Protokolle überprüft und etwaige Legacy-Abhängigkeiten beseitigt haben, können Sie damit beginnen, ein domänenweites Gruppenrichtlinienobjekt (GPO) zu konfigurieren, um die LAN Manager-Authentifizierungsebene auf Send NTLMv2 response only. Refuse LM & NTLM (Abbildung 6). Diese Einstellung erzwingt eine moderne Authentifizierung und blockiert schwächere Protokolle.

Abbildung 6. Stellen Sie sicher, dass Sie Sicherheitsrichtlinien festlegen, um moderne Authentifizierungsprotokolle durchzusetzen.

Risiko 4: Unsichere ADCS-Konfiguration

Unser IFIR-Team stellt fest, dass falsch konfigurierte Active Directory Certificate Services (ADCS) in vielen Umgebungen nach wie vor ein übersehenes, aber hochwirksames Risiko darstellen. Wenn Zertifikatsvorlagen, Registrierungsberechtigungen oder Webregistrierungsfunktionen nicht ordnungsgemäß abgesichert sind, können Angreifer ADCS missbrauchen, um sich als Benutzer auszugeben, ihre Rechte zu erweitern und unbefugte Kontrolle über sensible Systeme zu erlangen.

Ein häufiges Problem sind zu freizügige Zertifikatsvorlagen, die es jedem authentifizierten Benutzer erlauben, sich für Zertifikate mit dem Client Authentication EKU. In Kombination mit dem ENROLLEE_SUPPLIES_SUBJECT ermöglicht diese Konfiguration den Benutzern, den Betreff des Zertifikats selbst festzulegen (Abbildung 7), die es niedrig privilegierten Benutzern ermöglichen, Zertifikate im Namen anderer Konten, einschließlich Domänenadministratoren, anzufordern. Diese Zertifikate können dann verwendet werden, um sich als diese Konten auszugeben und erweiterten Zugriff zu erhalten. Diese Art von Fehlkonfiguration wird als ESC1 klassifiziert..

Abbildung 7: Falsch konfigurierte ADCS-Zertifikatsvorlagen können es Angreifern ermöglichen, Zertifikate für hochprivilegierte Konten anzufordern und sich erweiterten Zugriff zu verschaffen.

Ein ähnliches Risiko besteht, wenn wenig privilegierte Benutzer die Möglichkeit haben, Zertifikatsvorlagen zu ändern. Angreifer können diese Schwachstelle missbrauchen, um unsichere Einstellungen einzuführen, wie z.B. die Aktivierung von ENROLLEE_SUPPLIES_SUBJECTdie eine zuvor sichere Vorlage in eine Vorlage verwandeln kann, die anfällig für Angriffe wie ESC1 (Abbildung 8). Diese Art von Fehlkonfiguration fällt unter ESC4.

Abbildung 8. Dieser Sicherheitsindikator warnt davor, dass Fehlkonfigurationen von Zertifikatsvorlagen ein Risiko darstellen können.

Risiko 5: Uneingeschränkte Delegation

Unbeschränkte Delegation(Abbildung 9) ist gefährlich, denn wenn ein Benutzer ein Service-Ticket auf einem Server mit dieser Einstellung anfordert, wird sein Ticket-gewährendes Ticket (TGT) mit einbezogen und bleibt im Speicher. Wenn ein Angreifer diesen Server übernimmt, kann er sich das TGT schnappen und sich damit als der Benutzer ausgeben. Das Risiko erhöht sich, wenn der Windows Print Spooler-Dienst auf den DCs läuft. Ein Angreifer kann den Druckerfehler ausnutzen, um einen DC dazu zu bringen, sich bei dem kompromittierten Server zu authentifizieren, wodurch die eigene TGT des DC durchsickert und der Angreifer die volle Kontrolle erhält.

Um das Risiko zu verringern, stellen Sie sicher, dass Ihre Tier 0- oder gleichwertigen Konten über die Account is sensitive and cannot be delegated aktiviert haben, und fügen Sie sie der Gruppe Geschützte Benutzer hinzu.

Abbildung 9. Wenn Sie die uneingeschränkte Delegation auf einem Server einstellen, ist der Kerberos-TGT anfällig für Kompromisse und Missbrauch.

Risiko 6: Unbefugte Benutzer können der Domäne Computerkonten hinzufügen

In den meisten AD-Umgebungen kann jeder authentifizierte Benutzer bis zu 10 Computer zu einer Domäne hinzufügen. Das ist eine Standardeinstellung, die oft vergessen wird. Aber Angreifer vergessen das nicht. Wenn sie Zugriff auf ein beliebiges niedrigprivilegiertes Konto erhalten, können sie ein Computerobjekt erstellen(Abbildung 10) und es in Angriffen verwenden, die RBCD ausnutzen.

Es wird noch schlimmer, wenn bestimmte Zertifikatsvorlagen die Registrierung von Domänencomputern erlauben und die Client Authentication EKU mit dem ENROLLEE_SUPPLIES_SUBJECT Flagge. Diese Kombination öffnet die Tür für einen klassischen ESC1-Angriff, bei dem der Angreifer ein Zertifikat anfordern kann, mit dem er sich als ein anderer Benutzer ausgeben kann. Wenn Sie keinen Grund haben, Benutzern das Hinzufügen von Rechnern zur Domäne zu erlauben, setzen Sie am besten das ms-DS-MachineAccountQuota zu 0 und halten Sie das fest.

Abbildung 10. Dieser Sicherheitsindikator weist Sie darauf hin, dass Sie sicherstellen müssen, dass Benutzer keine Rechner zu Ihrer Domäne hinzufügen können.

Risiko 7: Privilegierte Konten mit konfiguriertem SPN

Die Zuweisung von Service Principal Names (SPNs) an privilegierte Benutzerkonten wie Domain Admins oder andere Tier 0-Konten stellt ein ernstes Sicherheitsrisiko dar. Wenn ein privilegiertes Konto einen SPN hat (Abbildung 11), kann jeder authentifizierte Benutzer in der Domäne eine Kerberos Ticket-Granting Service (TGS)-Anforderung für dieses Konto senden. Das Ticket, das sie erhalten, ist mit dem Passwort-Hash des Kontos verschlüsselt, was bedeutet, dass ein Angreifer es extrahieren und eine Kerberoasting Angriff. Eine häufige Fehlkonfiguration ist die Zuweisung eines MSSQL SPN auf das integrierte Administratorkonto (RID 500), wodurch Angreifer einen direkten Kerberoasting-Pfad zu einem der mächtigsten Konten in der Domäne erhalten.

Das Hauptproblem ist, dass das Knacken vollständig offline erfolgt. Sobald der Angreifer das Ticket hat, kann er mit Tools wie hashcat einen Brute-Force- oder Wörterbuch-Angriff durchführen, ohne weiteren Datenverkehr oder Warnmeldungen auf dem DC zu erzeugen. Privilegierten Konten sollten niemals SPNs zugewiesen werden. Wenn ein Dienst einen SPN benötigt, sollte er unter einem separaten, wenig privilegierten Dienstkonto mit einem starken, verwalteten Passwort laufen.

Abbildung 11: Dieser Scan identifiziert privilegierte Konten mit definierten SPNs.

Risiko 8: Veraltete Dienstkonten noch aktiviert

Servicekonten neigen dazu, sich mit der Zeit anzuhäufen. Sie werden oft für Systeme erstellt, die ersetzt wurden, für einmalige Skripte oder für alte Projekte, die niemand mehr pflegt. Das Problem ist, dass viele dieser Konten noch lange aktiviert bleiben, nachdem sie nicht mehr benötigt werden. Einige von ihnen haben immer noch erhöhte Berechtigungen oder sind von den regulären Kennwortrichtlinien ausgeschlossen, was sie zu einem perfekten Ziel für Angreifer macht. Wenn eines dieser vergessenen Konten kompromittiert wird, kann es schwer zu entdecken sein. Da es niemand aktiv nutzt, können verdächtige Aktivitäten unbemerkt bleiben.

Es lohnt sich, Ihre Servicekonten regelmäßig zu überprüfen, wie Abbildung 12 zeigt. Wenn ein Konto schon lange nicht mehr benutzt wurde und niemand seinen Zweck rechtfertigen kann, sollten Sie es deaktivieren und auf mögliche Auswirkungen achten.

Abbildung 12. Eine regelmäßige Überprüfung der Servicekonten und ihrer Aktivitäten stellt sicher, dass ungenutzte Konten bereinigt werden, bevor sie kompromittiert werden können.

Risiko 9: Fehlende Durchsetzung der Stufe 0

Die Implementierung eines vollständigen Unternehmens-Tiering-Modells ist eine Herausforderung und oft unrealistisch. Aber ein minimales Modell für Tier 0-Systeme ist nicht verhandelbar.

Tier 0 sind die Systeme, die die Identität kontrollieren, und wenn sie kompromittiert werden, fällt der Rest der Umgebung mit ihnen. In den meisten ADSAs haben wir festgestellt, dass viele Unternehmen überhaupt kein Tiering-Modell haben.

Wenn Sie noch kein Tier 0-Modell eingeführt haben, ist es jetzt an der Zeit, damit zu beginnen. Um Ihnen dabei zu helfen, zeigt Abbildung 13 eine Liste von Systemen, die in gut gesicherten Umgebungen üblicherweise als Tier 0 behandelt werden, sowie ein Modell zur Bestimmung ihres Tier 0-Status.

Abbildung 13. Das Verständnis, die Identifizierung und der Schutz von Tier 0-Ressourcen, wie sie in dieser Liste aufgeführt sind, sind für die Cybersicherheit eines Unternehmens unerlässlich.

Risiko 10: Unzuverlässige, nicht wiederherstellbare Active Directory-Backups

AD ist das Herzstück der Authentifizierung und des Zugriffs in der gesamten Umgebung. Und doch ist eine der kritischsten Lücken, die wir in vielen Unternehmen immer noch sehen, das Fehlen einer angemessenen Backup-Strategie für Active Directory.

Einige Unternehmen gehen davon aus, dass es ausreicht, Domain-Controller an verschiedenen Standorten zu haben, oder sie verlassen sich auf allgemeine VM-Snapshots, ohne zu überprüfen, ob diese Backups AD auf konsistente, unterstützte Weise wiederherstellen können.

Wenn Active Directory ausfällt und kein sauberes, wiederherstellbares Backup vorhanden ist, wird die Wiederherstellung extrem schwierig, insbesondere nach einem Cyberangriff.

Ein zuverlässiges AD-Backup ist nicht nur eine Kopie oder ein Snapshot auf Dateiebene. Erstellen Sie ein vertrauenswürdiges, validiertes Backup. Isolieren Sie es von der Produktionsdomäne. Schützen Sie es vor Manipulationen. Und testen Sie es regelmäßig. Denn ohne sie setzen Sie Ihre wichtigste Infrastruktur irreversiblen Schäden aus.

Semperis Schnappschuss

In einer Zeit, in der Cyberangriffe nicht mehr eine Frage des "ob" , sondern des "wann" sind , müssen Unternehmen Maßnahmen ergreifen, um ihre Widerstandsfähigkeit vor, während und nach einem Cybervorfall sicherzustellen.

Beginnen Sie damit, allgemeine Schwachstellen wie diese zu beseitigen. Dann arbeiten Sie mit Identitätsexperten zusammen und wählen Sie identitätsorientierte Tools aus, die Sie dabei unterstützen:

  • Stärken Sie Ihre Abwehrkräfte
  • Proaktiv wirksame Strategien zur Reaktion auf Vorfälle entwickeln
  • Erholen Sie sich schnell, wenn ein Zwischenfall eintritt
  • Verringern Sie Ihr langfristiges Risiko

Möchten Sie Ihre Identitätsinfrastruktur genauer unter die Lupe nehmen? Nutzen Sie das jahrzehntelange Wissen unseres IFIR-Teams aus erster Hand.

Erfahren Sie mehr über die Beseitigung von Sicherheitslücken in Active Directory