Die Wurzeln allen Übels: Warum wir Ihr Active Directory übernehmen

Oft stellen wir fest, dass dies eine bewusste Konfiguration ist und der Kunde die Sicherheitsrisiken durchaus kennt. Häufig gibt es jedoch eine veraltete, jedoch geschäftskritische, Legacy-Software die NTLMv1-Unterstützung erfordert. Firewalling und Netzwerksegmentierung können zwar die Ausnutzbarkeit einschränken, aber letztlich besteht die einzige Lösung darin, diese Legacy-Software zu entfernen und die Domänencontroller auf sichere Weise zu konfigurieren. Es gibt jedoch noch einen weiteren Grund, warum wir diese Fehlkonfiguration regelmäßig sehen:

Active Directory-Domänen sind oft 10 bis 25 Jahre alt und haben daher im Laufe ihrer Lebensdauer einige technische Schulden angehäuft. Ein Beispiel wäre eine "Default Domain Controller Policy", die seit ihrer Erstellung unangetastet blieb und daher unsichere Legacy-Konfigurationen (wie beispielsweise NTLMv1-Unterstützung) aufweist. Auch ein fehlerhafter Server-Heraufstufungsprozess kann ein Grund für unsichere Konfigurationen sein: Wenn ein Server, der zuvor wie ein Tier-1- oder Tier-2-Asset behandelt wurde, zu einem Domänencontroller heraufgestuft werden soll, kann er einige Konfigurationen übernehmen, die für ein Tier-0-Asset wie einen DC nicht geeignet sind. Dies kann auch eine Ursache für das nächste Problem sein:

Mehr als einmal habe ich bei Nachbesprechungen von Projekten Kundenreaktionen wie diese erlebt:

• “Oh, jeder kann sich selbst zur VPN-Gruppe hinzufügen?”
• “Oh, diese Gruppe kann die Passwörter aller Benutzer zurücksetzen?”
• “Oh wow, die Gruppe Domain Users hat GenericWrite Berechtigungen auf JEDES Objekt in der Domäne?”

Ein Pentest deckt die kritischsten dieser Objektbeziehungen für Sie auf, ist aber letztlich nur eine Momentaufnahme. Deshalb bieten wir bei r-tec auch BloodHound-Workshops für unsere Kunden an, in denen wir Ihre IT-Abteilung befähigen, diese Beziehungen und Schwachstellen selber aufzudecken.

Es gibt auch einige subtilere Fehlkonfigurationen, wie z. B. falsche "Objekt-Eigentumsverhältnisse": Wenn die Heraufstufung eines Servers zum Domänencontroller wie im vorigen Absatz beschrieben durchgeführt wurde, wird ein DC unter dem Besitz des Benutzers stehen, der das Computerobjekt ursprünglich erstellt hat - und das könnte genauso gut ein beliebiges Tier-2-Konto sein. Wenn dieses Konto kompromittiert wird, kann ein Angreifer diesen Besitz in eine vollständige Kompromittierung der Domäne verwandeln, indem er das DC-Konto übernimmt. Was ist also Tier-0 überhaupt?

Wenn Sie das Microsoft Tiering-Modell oder das modernere Enterprise Access Model, implementiert haben, ist das gut. Aber welche Assets sind Teil Ihres Tier-0? Wenn es sich nur um Ihre Domänencontroller und die Domänenadministratoren handelt, dann habe ich schlechte Nachrichten für Sie: Eine Kompromittierung eines Exchange-Servers kann zu einer Kompromittierung der Domäne führen, da diese zu einem DC Sync berechtigt sind. Eine Kompromittierung der Gruppe "Sicherungs-Operatoren" kann zu einer vollständigen Kompromittierung der Domäne führen, da jedes Mitglied dieser Gruppe die Registry eines Domänencontrollers sichern kann. "Konten-Operatoren" können Passwörter von wahrscheinlich mindestens einem anderen Konto zurücksetzen, das indirekt ein Domänenadministrator ist. Zertifikatsserver? Die Kompromittierung führt zu einem goldenen Zertifikat, so dass sich ein Angreifer als jeder Benutzer in Ihrer Domäne ausgeben kann.

Backup-Server? Hypervisoren? AV/EDR-Verwaltungsserver? Software-Verteilungsplattform? All das (und mehr) sollte als Tier-0-Asset eingestuft werden.

Sie haben sicher schon oft gelesen, dass schlechte Kennwörter eines der Hauptprobleme der Unternehmenssicherheit sind, und darum eine Kennwortrichtlinie eingeführt, die lange, komplexe Kennwörter vorschreibt. Aber haben Sie auch die Kennwörter ALLER Konten zurückgesetzt, nachdem Sie diese Richtlinie festgelegt hatten? Sie haben alle Benutzer darüber informiert, dass sie ein neues Kennwort festlegen müssen, ok, aber was ist mit dem sqlservice-Konto mit dem Kennwort "sqlservice" welches vor 8 Jahren erstellt wurde (und ein Domänen-Admin ist)? Oder mit dem breakglass-Admin mit "Admin123"? Oft sind Konten auf vielen Rechnern als Dienste konfiguriert, und die IT-Abteilung möchte sie nicht ändern, weil sie befürchtet, dass eines dieser Systeme ausfallen könnte. Diese Ausreißer können sich dann als der springende Punkt in einer Angriffskette herausstellen.

Wenn Sie also eine Richtlinie einrichten, sollten Sie diese für ALLE Benutzer durchsetzen, indem Sie auch ALLE Kennwörter zurücksetzen. Außerdem kann Blacklisting eingesetzt werden, damit Kennwörter nicht nur lang und komplex, sondern auch nicht zu trivial sind (wie z. B. "SommerSommer2024" – zwar lang und komplex, aber erratbar). Und Sie sollten wirklich darauf achten, dass Sie keine Muster wie password4\<servicename\> verwenden - wir werden sie finden und verwenden.

Ein weiteres Problem bei Passwörtern sind Standard-Initialkennwörter, wie sie z. B. von Helpdesk-Mitarbeitern festgelegt werden. Als Angreifer ist es oft einfach, an ein in einer Umgebung verwendetes Standardpasswort heranzukommen, z. B. durch Lesen der internen Dokumentation oder durch einen einfachen Anruf beim Helpdesk selbst. Beim Testen dieses Kennworts in der gesamten Domäne werden oft Konten entdeckt, bei denen das ursprüngliche Kennwort nicht geändert wurde (z. B. weil der Benutzer sich nie angemeldet hat) oder stattdessen eine leichte Abwandlung verwendet wurde ("Start12345!!" statt "Start12345!"). Im Idealfall sollte der Helpdesk-Prozess die Festlegung wirklich zufälliger und kryptischer Passwörter beinhalten.

Aber selbst wenn Ihre Passwörter gesichert sind, gibt es noch einen weiteren Fallstrick:

Interne Wissensdatenbanken, Ticketsysteme und Intranets, wie z. B. Confluence, enthalten oft ebenfalls wertvolle Informationen - von Informationen über interne Prozesse bis hin zu Anmeldedaten im Klartext. Und wenn Sie planen, ein Large-Language-Model (LLM) für Ihre Mitarbeiter als Helpdesk einzurichten, sollten Sie sich bewusst sein, auf welche Daten es zugreifen kann und wie ein Angreifer es missbrauchen könnte.

Das große Problem dabei ist, dass es sehr schwierig ist, diese Arten von Aktivitäten zu erkennen: Ein normaler Benutzer benutzt den ganzen Tag irgendwelche Netzwerkfreigaben und Sharepoint-Dateien - woher wissen Sie, dass jemand dies in böser Absicht tut? Wenn der Angreifer ein Token für den Cloud-Zugriff kompromittiert hat, könnte er dies sogar von seinem eigenen Rechner aus tun, so dass Sie überhaupt keinen Einblick in den Endpunkt haben. Oder überprüfen Sie wirklich alle Cloud-Zugriffe?

Sie sollten nicht nur sicherstellen, dass Ihre Berechtigungen für Freigaben, Teams, SharePoint-Websites usw. sauber eingerichtet sind, sondern idealerweise die Benutzer davon abhalten, diese sensiblen Daten überhaupt im Klartext abzulegen: Die Sensibilisierung und das Bereitstellen einer benutzerfreundlichen, zentral verwalteten Lösung für die Speicherung von Kennwörtern (durch z.B. einen Passwort-Manager) ist von entscheidender Bedeutung, um diese Art von Sicherheitslücken zu verhindern.

Wussten Sie, dass Sie, wenn Sie Active Directory Certificate Services (ADCS) in Ihrer Domäne einrichten und den Endpunkt für das Web-Enrollment installieren, gerade eine Schwachstelle geschaffen haben, die es jedem authentifizierten Benutzer ermöglicht, Ihre Domäne zu kompromittieren?

Kennen Sie die vielen Fallstricke, die Microsoft SCCM einsetzt?

Leider liefert Microsoft viele dieser unsicheren Standardkonfigurationen mit seinen verschiedenen Komponenten aus. Meistens fehlt es den IT-Abteilungen an Zeit, Ressourcen und schlussendlich dem Offensive Security Mindset, um alle diese Fehlkonfigurationen zu kennen und zu beachten. Wenn Sie nicht über ein spezielles Security Team verfügen, werden diese in der Regel erst beim nächsten Pentest aufgedeckt. Ein solcher Pentest-Evergreen ist die Sicherheitslücke "NBNS/LLMNR Poisoning". Dieses Legacy-Protokoll ist unter Windows standardmäßig aktiv und ermöglicht es einem Angreifer mit lokalem Netzwerkzugriff, eine Man-in-the-Middle-Position einzunehmen. Von hier aus können NTLM-Authentifizierungen an beliebige Hosts in Ihrem Netzwerk weitergeleitet werden, um beispielsweise Code auszuführen, Zugangsdaten auszulesen oder Dateien zu lesen. Auch IPv6-DHCP-Nachrichten können von einem Angreifer ausgenutzt werden, um in diese Position zu gelangen, und es gibt viele andere Protokolle, die alle standardmäßig anfällig sind. Es gibt zwar Sicherheitsmaßnahmen gegen diese Art von Angriffen (z. B. SMB-Signing oder LDAP-Signing), aber diese sind standardmäßig deaktiviert. Wenn überhaupt sehen wir diese nur in Umgebungen, die bereits einige Pentests hinter sich haben.

Meistens entstehen diese "Standard-Schwachstellen" aus der Idee, die Abwärtskompatibilität zu älteren Windows-Versionen zu ermöglichen - aber sollten Sie wirklich versuchen, mit Windows Server 2003 kompatibel zu sein?

Unsichere Standardeinstellungen gibt es natürlich nicht nur bei Microsoft-Produkten, sondern bei allen möglichen Arten von Software. Oftmals ist die Dokumentation, wie man diese sicher konfiguriert, tief im Nutzerhandbuch versteckt. Wenn Sie eine Software verwenden, die in Ihrer Umgebung weitreichende Rechte hat, wie z. B. ein Unified Endpoint Management (UEM), Server-Management-Lösungen, Backup-Suites, CI/CD-Plattformen oder Patch-Management-Lösungen, sollten Sie deren Konfigurationen unbedingt überprüfen und absichern.

Diese Liste ist bei weitem nicht vollständig, aber sie zeigt, warum gute Sicherheit mehr ist als das reine Beheben von Schwachstellen und das Abhaken einer Checkliste. Die Ursachen sind oft komplexer als ihre Symptome, und wenn man sie ignoriert, führt das in der Zukunft nur zu weiteren Schwachstellen. Leider ist die Behebung dieser Schwachstellen mit höheren Kosten verbunden, denn sie erfordert das Abarbeiten der angehäuften technischen (und organisatorischen) Schulden.

Ein guter Security Consultant sollte Ihnen nicht nur eine Liste der gefundenen Schwachstellen aushändigen, sondern Ihnen auch deren Ursachen aufzeigen und Sie beim Beheben dieser unterstützen. Deshalb bieten wir bei r-tec Beratung zu allen oben genannten Punkten an, sei es ein allgemeiner Sicherheitscheck, eine Gap-Analysis, die Entwicklung und Implementierung eines geeigneten Tiering-Modells oder Netzwerkkonzept, Beratung zum Einsatz von Passwort-Managern und AV/EDRs oder die Unterstützung bei der sicheren Konfiguration Ihrer Dienste.

Schwachstellen zu beheben, ohne die Ursachen zu beseitigen, ist letztlich so, als würde man eine rostige Stelle an einem Auto mit Farbe überstreichen - es sieht vielleicht eine Zeit lang gut aus, aber das Problem wird darunter weiterwachsen und schließlich noch mehr Schaden anrichten.