Bauen Sie eine Verbindung zu einem Domain Controller per RDP von Ihrem PC aus auf?
🔥 Deine RDP-Verbindung wird vermutlich sensible administrative Anmeldedaten für Dritte exponieren!
⚠️ Auch wenn Du mit Windows 11 und dem Credential Guard arbeitest: die Anmeldedaten Deines Domain Admin-Kontos bleiben angreifbar, wenn Du eine Verbindung von einem normalen PC per RDP zu einem Domain Controller herstellst.
Warum ist das so?
Das ist ein Problem, dass nicht mit irgendwelchen Features behoben werden kann; hier ist es erforderlich mit eine Priviledged Access Workstation (PAW) und einem sauberen Tiering-Modell zu arbeiten.
Wordurch entsteht das Problem?
1. Credential Guard ist aktiviert – alles sicher und gut, oder?
2. Du baust eine Verbindung per RDP zu einem Domain Controller auf.
3. Du bist jetzt in der RDP-Sitzung
4. Ein Angreifer extrahiert nun die Anmeldedaten aus dem Arbeitsspeicherbereich der mstsc.exe
Kann man das Problem mit der Smart Card umgehen?
Was denkst Du, wird bei der Smart Card anders im Arbeitsspeicher gehalten?
Wussten Sie, dass der Built-in Administrator gesperrt werden kann? Angreifer spielen gerne diese Karte!
Über viele Jahre hinweg konnte der Built-in Administrator (RID 500) nicht gesperrt werden. Angreifer haben dieses Schlupfloch gerne genutzt.
Jedoch hat sich das Blatt hier gewendet:
✅ Seit 2022 gibt es (endlich) eine Einstellung per GPO, welche das Verhalten hierzu steuert
✅ Mit Windows Server 2025 unterliegt der Built-in Administrator der Sperrrichtlinie standardmäßig.
Warum ist das wichtig?
Weil das Kennwort eines lokalen Administrators oft:
❌ einfach und schwach ist und
❌ bei vielen System gleich gehalten wird.
Angreifer können diesen Umstand erkennen und sich lateral, seitlich bewegen ohne Konten aus dem Active Directory benutzen zu müssen.
Sperrichtlinien unterstützen dabei brute-force-Angriffe abzuwehren; jedoch ist zu beachten:
⚠️ Das gilt nur für Netzwerkanmeldungen, nicht für interaktive oder remote-interaktive Anmeldungen!
💡 Trotzdem: nicht das gleiche Kennwort für den lokalen Administrator verwenden!
💡 Wenn dem so sein sollte: Windows LAPS (Local Administrator Password Solution) verwenden um das Kennwort zu rotieren und unterschiedlich zu halten. Diese Möglichkeit gab es schon lange vor Server 2022 und bietet Schutz für das gleiche Szenario.
👉 Kannten Sie dieses Feature?
Setzen Sie den „Restricted Admin Mode“ bei RDP-Verbindungen ein?
⚠️ Fall nein, sollten Sie es tun um die Anmeldedaten zu schützen.
Warum gibt es den „Restricted Admin Mode“?
Der „Restricted Admin Mode“ wurde für administrative User entwickelt, die sich auf potenziell kompromittierte Server verbinden ohne ihre Anmeldedaten dorthin zu übertragen.
Hierzu muss man ein lokaler Administrator auf der Zielmaschine ein, jedoch verlassen die Anmeldedaten in diesem Fall nicht das Quellsystem. Dieses verhindet den Diebstahl der Anmeldedaten und die laterale Bewegung baiserend auf diesen.
💡Warum ist das wichtig?
✅ Es unterbindet den Diebstahl von Anmeldedaten – schützt somit privilegierte Konten bei RDP-Verbindungen
✅ Ideal für Jump Hosts und PAWs – sicheres Verbinden zu den Geräten ohne ein unnötiges Risiko einzugehen.
✅ SSO-Erlebnis – die erneute Eingabe eines Kennwortes entfällt, die Anmeldedaten des lokalen Administrators werden verwendet, werden aber nicht zum Ziel übertragen
💡 Wie wird das aktiviert?
🎯 Auf dem Zielsystem wird ein Registry-Key hinzugefügt:
HKLM\SYSTEM\CurrentControlSet\Control\LSA
REG_DWORD: DisableRestrictedAdmin
Value: 0
♨️ Auf dem Quellsystem wird eine Policy aktiv gesetzt :
Administrative Templates\System\Credentials Delegation\Restrict delegation of credentials to remote servers – Require Restricted Admin
Wissen Sie wie Kerberoasting funktioniert?
Wenn Sie Active Directory verwalten, sollten Sie dies unbedingt tun – denn ein authentifizierter User kann dieses durchführen.
Wie der Name schon sagt, zielt der Angriff auf das Kerberos Authentifizierungsprotokoll ab.
Wenn ein Konto über ein Service Principal Name (SPN) (wie HOST/SERVER01) verfügt, können Sie ein TGS-Ticket dafür anfordern. Dieses Ticket ist teilweise mit dem Kennwort-Hash des mit diesem SPN verknüpften Kontos verschlüsselt.
Das TGS-Ticket, das Sie gerade angefordert haben?
➡️ Sie verfügen nun über einen Datenblock, der mit dem Kennwort Hash des Ziel-Services (der Schlüssel wird abgeleitet vom Kennwort-Hash) verschlüsselt ist. Wenn das Passwort schwach ist, können Sie es offline mit Brute-Force-Methoden knacken. Das ist Kerberoasting.
Und in vielen Umgebungen?
Es handelt sich um ein 10 Jahre altes, noch aktives Dienstkonto, das zu den Domänenadministratoren gehört und ein schwaches Passwort hat.
📉 Das ist ein direkter Eskalations-Pfad vom Standardbenutzer zur vollständigen Domänenkontrolle.
Was kann man machen?
✅ Verwenden Sie nach Möglichkeit MSA/gMSA/dMSA.
✅ Vermeiden Sie Standardbenutzerkonten für Dienste.
Wenn Sie unbedingt ein Standardbenutzerkonto verwenden müssen (das kommt vor, ich weiß):
✅ Wenden Sie detaillierte Passwortrichtlinien an – in der Tschechischen Republik beispielsweise schreibt das Gesetz für technische Konten komplexe Passwörter mit mindestens 22 Zeichen vor.
✅ Authentifizierungsrichtlinien – ich werde diese später erläutern 🙂
Möchten Sie tiefer in Kerberos eintauchen?
Ich behandele es in meinem Kerberos-Kurs, der 100 %ig kostenfrei ist, und in meiner Academy besucht werden kann.
👉 Wie sichern Sie Ihre Dienstkonten? Kennen Sie alle?
Das Attribut „sIDHistory“ kann sehr gefährlich sein!
Verwenden Sie es in Ihrer Umgebung?
Ursprünglich wurde der SID-Verlauf bei Active Directory-Migrationen verwendet, um migrierten Benutzern den Zugriff auf alte Ressourcen zu ermöglichen, indem alte SIDs in das Attribut „SIDHistory“ eingefügt wurden.
Aber hier besteht das Risiko:
👉 Was auch immer dort als SID das Attribut hineingeschrieben wird, gilt wie eine normale Gruppenmitgliedschaft.
Beispiel:
Wenn Sie die Gruppen-SID „Enterprise-Admins“ (S-1-5-21-*-519) in die SIDHistory eines Benutzers einfügen, erhält dieser Benutzer Enterprise-Admin-Berechtigungen, ohne tatsächlich Mitglied der Gruppe zu sein.
Angreifer lieben diesen Trick: er ist unscheinbar aber sehr wirkungsvoll.
Es wurde auch in Multi-Domain-Umgebungen missbraucht, um von einer untergeordneten Domäne zur übergeordneten Domäne zu eskalieren (auf die Vertrauensstellung dürfen Sie sich nicht verlassen!).
⚠ Auch wenn Sie glauben, SIDHistory nicht zu verwenden, überprüfen Sie Ihre Umgebung regelmäßig auf solche Fehlkonfigurationen. (✅ Sie können dazu mein Tool ADProbe verwenden 👉 https://lnkd.in/efXTeJQz)
Wenn Sie SIDHistory in Ihrer Umgebung entdecken, kann es sich um alte Migrationsrückstände oder ein Anzeichen einer Kompromittierung handeln.
So oder so → Überprüfen Sie das Attribut und bereinigen Sie im Bedarfsfall!
👉 Haben Sie Ihren SID-Verlauf in letzter Zeit überprüft?
Wird ein wird ein Mitglied der Domain Admins verwendet um Computer in die Domäne aufzunehmen?
In den meisten Umgebungen ist dies völlig offen – jeder authentifizierte Benutzer kann bis zu 10 Geräte verbinden. Das ist nicht sinnvoll.
Ich habe eine praxisnahe Anleitung zur Verfügung gestellt die zeigt wie es geht:
✔ Richten Sie ein geeignetes Dienstkonto für den Domänenbeitritt ein.
✔ Härten Sie mit GPOs und entfernen Sie unsichere Standardeinstellungen.
🧠 Kein unnötiger Schnickschnack – nur die Schritt-für-Schritt-Anleitung, die funktioniert.
📄 Laden Sie das vollständige PDF in meiner Akademie herunter und sichern Sie Ihre Infrastruktur optimal.
Konten unsichtbar machen
Es ist überraschend einfach, ein Konto nahezu unsichtbar zu machen, und die meisten Administratoren würden es nicht einmal bemerken. So geht’s:
1. Konto nahezu unsichtbar machen
Wenden Sie die ACL „Vollzugriff verweigern“ für „Jeder“ auf das Zielkonto an – so kann niemand das Konto sehen oder ändern.
2. Verbergen Sie die Gruppenmitgliedschaft eines Kontos, auch wenn es ausgeblendet ist.
Auch wenn ein Konto ausgeblendet ist, kann seine Gruppenmitgliedschaft dennoch sichtbar sein.
👉 Verwenden Sie die Funktion „Primäre Gruppe“ anstelle herkömmlicher Gruppenmitgliedschaften. Da die primäre Gruppe in den Kontoattributen gespeichert ist, wird sie in Standardgruppensuchen nicht angezeigt. In Kombination mit deny ACLs ist sie nahezu unsichtbar.
3. Platzieren Sie die Datei in einer irreführenden Organisationseinheit (OU), idealerweise einer, die nur im erweiterten Modus sichtbar ist. Wenden Sie Zugriffskontrolllisten für Inhalte auf die letzte OU an, um sie noch weiter zu verschleiern.
Funktioniert das immer?
Nicht für offiziell privilegierte Gruppen – der AdminSDHolder-Schutz greift für Konten in Gruppen wie Domänenadministratoren (ich habe Beiträge dazu geschrieben).
Kann es immer noch entdeckt werden?
Ja, Sie sollten Folgendes überwachen:
✔ Änderungen der primären Gruppe
✔ Verdächtige ACL-Änderungen (insbesondere Deny)
✔ Änderungen auf AD-Objektebene (Ereignisprotokolle)
Auch das SAM-R-Protokoll kann zur Enumeration verwendet werden (je nach Konfiguration).
Cybersicherheitsbericht
Die fünf größten Probleme zwischen 2020 und 2024.
Verwenden Sie Smartcards im Active Directory?
Oder denken Sie darüber nach?
Vorsicht! NT-Hashes werden weiterhin zwischengespeichert, und das ist alles, was ein potenzieller Angreifer benötigt. Ohne die richtige Konfiguration könnten Sie einen NT-Hash erhalten, der auf unbestimmte Zeit unverändert bleibt und Ihr System angreifbar macht!