Identity & Access Archives - IT-Consulting Blog

Übersicht über Windows LAPS

In diesem Blogbeitrag möchte ich Ihnen eine spannende neue Funktion vorstellen, welche mit dem heutigen Sicherheitsupdate vom 11. April 2023 für die folgenden Windows-Editionen direkt im Betriebssystem enthalten sind:

Windows 11 Pro, EDU, and Enterprise
Windows 10 Pro, EDU, and Enterprise
Windows Server 2022 and Windows Server Core 2022
Windows Server 2019

Windows Local Administrator Password Solution (Windows LAPS) für Azure Active Directory

Native Integration in Windows

Windows LAPS ist sofort einsatzbereit. Sie müssen kein externes MSI-Paket mehr installieren, kein AD-Schema mehr erweitern und keine Gruppenrichtlinien verteilen! Alle zukünftigen Anpassungen, Verbesserungen oder Funktionsupdates werden über die normalen Windows-Patching-Prozesse bereitgestellt.

Was ist Windows LAPS?

Windows LAPS ist eine Windows-Funktion, die bereits für in Windows Server Active Directory eingebundene Geräte verfügbar ist. Sie ermöglicht es Ihnen, die Kennwörter der lokalen Administratorkonten auf Ihren Geräten automatisch zu generieren, zu ändern und zu speichern. Dies erhöht die Sicherheit, da Sie nicht mehr das gleiche Kennwort für alle Geräte verwenden müssen, und vermeidet somit das Risiko von Pass-the-Hash-Angriffen und unterbindet aktiv das sogenannte Lateral Movement.

Windows LAPS bietet einige Vorteile gegenüber anderen Methoden zur Verwaltung von lokalen Administratorpasswörtern, wie z.B.:

Es generiert zufällige und komplexe Passwörter für jedes Gerät und ändert sie regelmäßig nach einem festgelegten Zeitplan.
Es speichert die Passwörter verschlüsselt in einem Active Directory-Attribut, das nur von berechtigten Benutzern oder Gruppen abgerufen werden kann.
Es vermeidet die Verwendung eines gemeinsamen Passworts für alle Geräte oder die manuelle Verfolgung von Passwörtern in einer Excel-Tabelle oder einem anderen Medium.
Es ermöglicht es Administratoren, die Passwörter bei Bedarf schnell zu ändern oder zurückzusetzen, z.B. bei einem Sicherheitsvorfall oder einem Mitarbeiterwechsel.
Es ist einfach zu implementieren und zu verwalten, ohne dass zusätzliche Hardware oder Software erforderlich ist.

Windows LAPS ist eine nützliche Lösung für alle Organisationen, die lokale Administratorpasswörter auf ihren Windows-Geräten effektiv verwalten wollen. Es ist kostenlos und einfach zu verwenden und bietet einen hohen Grad an Sicherheit und Kontrolle.

Windows LAPS unterstützt Azure AD

Windows LAPS für Azure Active Directory erweitert die bestehende Funktion um die Möglichkeit, die Kennwörter der lokalen Administratorkonten in Azure Active Directory zu sichern. Dies hat mehrere Vorteile:

Sie können die gespeicherten Kennwörter über Microsoft Graph abrufen.
Sie können zwei neue Microsoft Graph-Berechtigungen erstellen, um nur die Kennwort-„Metadaten“ (z. B. für Sicherheitsüberwachungs-Apps) oder das sensible Klartextkennwort selbst abzurufen.
Sie können Azure-Richtlinien für rollenbasierte Zugriffssteuerung (Azure RBAC) verwenden, um Autorisierungsrichtlinien für das Abrufen von Kennwörtern zu erstellen.
Sie können das Azure-Verwaltungsportal verwenden, um Kennwörter abzurufen und zu ändern.
Sie können die Funktion über Intune verwalten!
Sie können das Kennwort automatisch ändern, nachdem das Konto verwendet wurde.

Wie kann ich Windows LAPS für Azure Active Directory einrichten?

Um Windows LAPS für Azure Active Directory einzurichten, müssen Sie zunächst einen Mechanismus zur Bereitstellung von Richtlinien auf Ihren Geräten wählen. Die bevorzugte Option ist die Verwendung von Microsoft Intune mit dem Windows LAPS-Konfigurationsdienstanbieter (CSP). Wenn Sie Microsoft Intune nicht verwenden, können Sie auch andere Methoden verwenden, wie z. B. die direkte Änderung der Registrierung oder die Verwendung von Gruppenrichtlinie für lokale Computer.

Microsoft meldet neuen Angriff mit Azure AD Connect

In diesem Blogbeitrag möchte ich den Inhalt des Artikels https://practical365.com/mercury-attack-april-2023 auf Deutsch zusammenfassen.

Der Artikel beschreibt einen neuen Angriff, welcher Azure AD Connect ausnutzt, um sowohl On-Premises- als auch Cloud-Ressourcen zu kompromittieren.

Wer steckt hinter den Angriffen?

Der Angriff wurde von Microsoft Threat Intelligence aufgedeckt und wird zwei Gruppen zugeschrieben: MERCURY, einer mit der iranischen Regierung verbundenen Nation-State-Akteurin, und DEV-1084, einer Gruppe, welche von MERCURY beauftragt wurde, die Netzwerkzugriffe auszunutzen.

Wie begann der Angriff?

Bei Angriffen wie diesem hört man oft zwei Begriffe: Eskalation von Privilegien und Lateral Movement.

Lateral Movement klingt kompliziert, ist aber einfach: Der Begriff bedeutet nur, dass ein Angreifer ein Gerät oder System in einem Netzwerk kompromittiert hat und dies als Sprungbrett oder Drehpunkt nutzt, um in andere Geräte oder Systeme zu gelangen. Diese Bewegung kann sofort erfolgen, aber oft ist sie verzögert (wie in diesem Fall) – ein kluger Angreifer wird eindringen, eine Persistenz herstellen und dann eine Weile warten, das Zielnetzwerk studieren und jede offensichtliche Aktion vermeiden, welche die Verteidiger auf seine Anwesenheit aufmerksam machen könnte.

In diesem Fall begann der Angriff mit der Ausnutzung der bekannten log4j-Schwachstelle, um in das Netzwerk einzudringen und Persistenz zu erlangen. Die Angreifer bewegten sich dann durch das Netzwerk und griffen sowohl On-Premises- als auch Hybrid-Ressourcen an. Für die On-Premises-Angriffe nutzten sie Gruppenrichtlinienobjekte (GPOs), um Sicherheitstools (Endpoint Protection) zu stören und Ransomware über die NETLOGON-Freigaben auf den Active Directory-Domänencontrollern zu verteilen. Für die Hybrid-Angriffe nutzten sie Azure AD Connect, um sich mit Azure AD zu synchronisieren und Zugriff auf Cloud-Ressourcen zu erhalten. Die Angreifer löschten anschließend Daten aus Azure Storage-Konten und Azure SQL-Datenbanken. Mit einem vernünftigen Tier-Modell wäre der Angriff in diesem Ausmaß vermutlich nicht umsetzbar gewesen.

Microsoft empfiehlt dringend, Azure AD Connect zu überprüfen und sicherzustellen, dass es keine unbefugten oder verdächtigen Synchronisierungen gibt. Außerdem sollten die Sicherheitsmaßnahmen für Domänencontroller und GPOs verstärkt werden, um ähnliche Angriffe zu verhindern oder zu erkennen. Microsoft bietet verschiedene Sicherheitstools an, die bei der Untersuchung und Abwehr solcher Angriffe helfen können, wie z.B. Microsoft Defender for Endpoint, Microsoft 365 Defender und Azure Sentinel.

Dennoch zeigt dieser Angriff wieder, wie wichtig es ist, sowohl On-Premises- als auch Cloud-Umgebungen zu schützen und zu überwachen. Hybrid-Umgebungen bieten viele Vorteile, aber auch neue Herausforderungen und Risiken. Es ist daher unerlässlich, sich über die aktuellen Bedrohungen zu informieren und die besten Praktiken für die Sicherheit von Azure AD Connect zu befolgen. Zum Schutz gehört auch der Aufbau von Tier-Strukturen.

Wozu ist ein Azure AD Connect Server notwendig?

Azure AD Connect ist ein wichtiges Werkzeug für die Synchronisation von Identitäten zwischen lokalen Active Directory-Domänen und Azure Active Directory. Da der Azure AD Connect Zugriff auf die Anmeldeinformationen und Attribute aller Benutzer und Gruppen in den verbundenen Domänen hat, muss dieser Server entsprechend gut geschützt werden. Daher sollten Sie den Azure AD Connect wie einen Domänencontroller behandeln und in Tier-0 aufnehmen.

Was bedeutet Tier-0?

Tier-0 ist die höchste Sicherheitsstufe in einem Active Directory-Design, das auf dem Prinzip der administrativen Grenzen basiert. Tier-0 umfasst alle Systeme und Konten, die in der Lage sind, Änderungen an der Active Directory-Domänenstruktur oder den Sicherheitsrichtlinien vorzunehmen. Diese sollten von anderen Tiers isoliert und mit strengen Zugriffs- und Überwachungsregeln versehen werden.

Indem der Azure AD Connect Server in Tier-0 aufgenommen wird, wird sichergestellt, dass nur berechtigte Administratoren darauf zugreifen können und dass alle Aktivitäten auf dem Server protokolliert und überprüft werden. Dies reduziert das Risiko eines unbefugten Zugriffs oder einer Kompromittierung von Azure AD Connect.

Trends zur Identity Security 2023

Willkommen im Jahr 2023! Es wird Zeit endlich alle externen Benutzerzugriffe mit einer Multifaktor-Authentifizierung abzusichern. Vorzugsweise einer sicheren!

Jüngste Studien von Expert Insights bestätigen, was wir seit Ewigkeiten wissen, in den meisten Fällen sind Angriffe wie Ransomware nur die zweite Stufe, welche auf eine Identitätskompromittierung beruht. Viele neuartigen Techniken beruhen auf der Kompromittierung der Identität. Dies zeigt, wie wichtig es ist, den Schutz der Identitäten zur Grundlage unserer Sicherheitsstrategie zu machen.

Passwort-Angriffe

Einfache Passwortangriffe sind allgegenwärtig. Sie sind wie die Luft, welche wir alle atmen. Hierbei spielt die Größe oder der Umsatz des Unternehmens, welches angegriffen wird, keine Rolle. Denn diese Angriffe können effektiv in großem Umfang ausgeführt werden. Warum Kennwörter unsicher sind und selbst MFA nicht immer ausreichend ist! Erkläre ich ausführlich in dem folgenden Artikel.

Password spray: Erraten gängiger Kennwörter.
Phishing: Jemanden dazu bringen, seine Anmeldedaten auf einer gefälschten Website oder als Antwort auf eine SMS oder E-Mail einzugeben.
Breach replay: Die Wiederverwendung von Kennwörtern, welche von einer anderen Website entwendet wurden.

Microsoft wehrt mehr als 1.000 Passwortangriffe pro Sekunde ab. Bei 99,9 Prozent der kompromittierten Konten ist keine Multifaktor-Authentifizierung aktiviert. Eine mehrstufige Authentifizierung ist heute eine der effektivsten und grundlegendsten Abwehrmaßnahmen gegen Identitätsangriffe.

Oftmals werden leider aus Gründen der Bequemlichkeit keine mehrstufigen Authentifizierungen verlangt. Dabei gehört es doch selbst im privaten Umfeld zum absoluten Standard.

Online-Banking, Paypal, Apple etc. sind ohne mehrstufige Authentifizierung nicht mehr nutzbar.

Die Nutzung der Multifaktor-Authentifizierung ist das Wichtigste, was wir für unsere Sicherheit tun können.

Die altmodische Multifaktor-Authentifizierung war unsexy und erforderte das Kopieren von Codes vom Telefon oder einem Hardware-Token (OTP). Moderne Multifaktor-Authentifizierung mit Apps, Token oder dem Gerät selbst ist sehr reibungsarm oder sogar unsichtbar für die Benutzer. Vorzugsweise müssen die Benutzer nicht mal mehr ein Kennwort eingeben.

Windows 10 und Windows 11 bieten eine kostengünstige und einfache In-Box-Alternative zu Kennwörtern, Windows Hello for Business, eine starke Zwei-Faktor-Authentifizierung für Azure Active Directory und Active Directory.

Sie sollten sich für das Jahr 2023 die Kampagne #GoPasswordless2023 auf die Fahne schreiben!

Warum Kennwörter unsicher sind und selbst MFA nicht immer ausreichend ist!

Alle paaren Wochen führen Sebastian und ich mindestens ein Gespräch, in welchem wir den Entscheidern erklären, warum die Aussagen wie „Wir haben komplexe und lange Kennwörter im Einsatz“, „Uns greift doch keiner an“ oder „Wir verwenden eine MFA-Lösung“ oftmals ein falsches Gefühl von Sicherheit vermitteln.

Denn die Sache ist die:

Viele der heutigen Attacken werden automatisch durchgeführt. Ein Taschendieb bewegt sich auch in der Menge, ohne sein wirkliches Opfer zu kennen.
Meistens spielt die Länge Ihres Kennwortes keine Rolle.

Um zu verstehen, warum dem so ist, sollten wir uns die wichtigsten Angriffe auf Kennwörter ansehen.

Attacke	weitere Namen	Schwierigkeitsgrad	Benutzerinteraktionen	Spielt das Kennwort eine Rolle?
Phishing	Man-in-the-middle, Abfangen von Anmeldedaten	Einfach: Öffentlichen Hotspot bereitstellen. Links zu falschen Anmeldemasken via E-Mail, oder DNS, LLMNR, NetBios Spoofing, DHCPv6 verteilen. Einfache Tools wie Modlishka unterstützen den Angreifer	Verwendet ein x-beliebiges WLAN Meldet sich an und bestätigt die MFA	Nein, der Angreifer kann entweder das Kennwort erhalten, oder nutzt eine Pass-The-Hass und Pass-The-MFA Methode
Keylogger	Malware, Keystroke logging	Mittel: Malware zeichnet Benutzernamen und eingegebene Kennwörter auf und überträgt diese.	Anklicken von Links, Ausführen als Administrator, keine aktuellen Sicherheitsupdates oder Virensignaturen	Nein, sämtliche Informationen werden im Klartext übermittelt
Password spray	Guessing, hammering, low-and-slow	Trivial: Verwenden von öffentlichen Benutzerlisten und allgemeinen Kennwortlisten. Hierbei werden die Top 100 Kennwörter für Deutschland für eine große Anzahl an Benutzernamen verwendet.	Es werden häufige Kennwörter wie Spring123!, Winter2022, Sommer2023! etc. verwendet. Diese erfüllen häufig die Komplexitätsanforderungen	Nein, wenn das Kennwort einem Top-Kennwort, befindet sich auf einer Kennwortliste, entspricht.
Brute force	Database extraction, cracking	Unterschiedlich: Kann einfach sein, wenn das Zielunternehmen nur schwach geschützt ist. Hash-Cracking des Passworts. Schwieriger wenn die NTDS.DIT physisch und betrieblich geschützt ist.		Nein, außer Sie verwenden ein unbrauchbares Kennwort

Password Spray

Passwort-Spraying ist ein Angriff, bei welchem versucht wird, mit einigen wenigen, häufig verwendeten Kennwörtern auf eine große Anzahl von Konten (Benutzernamen) zuzugreifen. Die Angreifer „sprühen“ diese gängigen Kennwörter somit über ein ganzes Unternehmen. Dieser Angriff verfolgt demnach einen Massenansatz. Der Angreifer beginnt in der Regel mit einem verbreiteten Kennwort wie P@$$w0rd123, von dem er hofft, dass es von einem Benutzer im Unternehmen verwendet wird.

Die Benutzer wählen die gleichen Kennwörter vor allem deshalb, weil sie sehr einfach zu merken sind. Die Angreifer probieren daher gezielt oft verwendete Kennwörter von veröffentlichten Kennwortlisten aus.

Phishing/Man-in-the-middle

Leider können praktisch alle heute gebräuchlichen Authentifikatoren wie Telefon, SMS, E-Mail, OTP-Token (One-Time-Passcode) oder Push-Benachrichtigungen relativ einfach über Real-Time-Phishing abgefangen und genutzt werden. Hierzu muss ein Angreifer lediglich den Kommunikationskanal (Channel-Jacking) übernehmen. Aus diesem Grund empfehlen wir auch die Nutzung von eigenen LTE-Modems für besonders schützenswerte Benutzer wie Mitglieder der Geschäftsführung, Vorstand, Aufsichtsrat etc.

Wer wählt sich nicht gerne am Flughafen in den kostenlosen Hotspot „DUS Free WiFi Airpot“ ein?

Das macht aber nicht alle Authentifikatoren gleich anfällig.

Es ist sehr wichtig zu wissen, dass nur drei der genannten Authentifikatoren Ihre Benutzer vor Phishing-Angriffen schützen.

FIDO2
Windows Hello for Business
Zertifikatsbasierte Authentifizierung (CBA)

Die unvermeidliche Pointe
Ihr Passwort spielt keine Rolle, außer für Passwort-Spray (vermeiden Sie die am häufigsten erratenen Passwörter mit einer Art Wörterbuch-Checker wie dem Password Protection Feature von Microsoft) oder Brute-Force (verwenden Sie mehr als 8 Zeichen, oder benutzen Sie einen Passwort-Manager, wenn Sie *wirklich* nervös sind). Das soll nicht heißen, dass Ihr Passwort sicher ist. Es ist *definitiv* nicht sicher, wenn man bedenkt, wie hoch die Wahrscheinlichkeit ist, dass es erraten, abgefangen, gefälscht oder wiederverwendet wird.

Effektive Passwortrichtlinien für Ihr Unternehmen mit FGPP: Tipps für die erfolgreiche Umsetzung

Die „Fine-Grained Password Policies“ (FGPP) sind ein Feature von Active Directory (AD), das es Administratoren ermöglicht, die Passwortrichtlinien für bestimmte Benutzer oder Benutzergruppen innerhalb einer Domäne zu konfigurieren. Mit FGPP können Administratoren unterschiedliche Passwortrichtlinien für verschiedene Benutzergruppen definieren, anstatt eine einzige Passwortrichtlinie für die gesamte Domäne zu verwenden.

FGPP ermöglicht es Administratoren, verschiedene Passwortrichtlinien auf der Grundlage von Attributen des Benutzers zu erstellen, z.B:

Mindestlänge des Passworts
Verwendung von Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen
Passwortdauer und Anzahl der erlaubten Passwortänderungen
Passworthistorie

Diese Funktion kann helfen die Sicherheit zu erhöhen, da es ermöglicht die Passwortrichtlinien entsprechend dem Risiko der Benutzer oder Gruppen anzupassen. Zum Beispiel kann für administrative Accounts eine höhere Passwortkomplexität erforderlich sein als für normale Benutzer.

Es ist wichtig, dass Passwortrichtlinien regelmäßig überprüft und angepasst werden, um sicherzustellen, dass sie den aktuellen Sicherheitsbedürfnissen entsprechen und die Sicherheit nicht beeinträchtigt wird.

Im Zusammenhang mit der AD Tiering Struktur können so für die unterschiedlichen Tiers verschiedene Kennwortrichtlinien angewendet werden.

Im Folgenden werden wir eine typische Empfehlung umsetzen:

Alles, was wir hierzu benötigen, ist eine Powershell samt Active Directory Module.

Erstellung einer „PSO 190 days“ Richtlinie für Service-Accounts:

New-ADFineGrainedPasswordPolicy -Name "PSO 190 days" -Precedence 500 -ComplexityEnabled $true -Description "Password Policy for service accounts 190 days" -DisplayName "PSO 190 days service accounts" -LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 2 -MaxPasswordAge "190.00:00:0" -MinPasswordAge "1.00:00:00" -MinPasswordLength 15 -PasswordHistoryCount 5 -ReversibleEncryptionEnabled $false

Erstellung einer „PSO 180 days“ Richtlinie für normale Benutzer:

New-ADFineGrainedPasswordPolicy -Name "PSO 180 days" -Precedence 500 -ComplexityEnabled $true -Description "Password Policy for Office Users 180 days" -DisplayName "PSO 180 days Office Users" -LockoutDuration "0.00:30:00" -LockoutObservervationWindow "0.00:15:00" -LockoutThreshold 5 -MaxPasswordAge "180.00:00:0" -MinPasswordAge "1.00:00:00" -MinPasswordLenght 10 -PasswordHistoryCount 5 -ReversibleEncryptionEnabled $false

Erstellung einer „PSO 90 days“ Richtlinie für T-0 sowie T-1 Administratoren:

New-ADFineGrainedPasswordPolicy -Name "PSO 90 days" -Precedence 500 -ComplexityEnabled $true -Description "Password Policy for administrative Users 90 days" -DisplayName "PSO 90 days administrative Users" -LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 5 -MaxPasswordAge "90.00:00:0" -MinPasswordAge "1.00:00:00" -MinPasswordLength 12 -PasswordHistoryCount 5 -ReversibleEncryptionEnabled $false

Die Zuweisung der einzelnen Richtlinien erfolgt über Gruppenmitgliedschaften. Hierzu erstellen wir 3 globale Gruppen im AD.

Nun verknüpfen wir die Richtlinien mit den neuen globalen Gruppen:

Add-ADFineGrainedPasswordPolicySubject "PSO 180 days" -Subjects k_PSO_180days
 
Add-ADFineGrainedPasswordPolicySubject "PSO 90 days" -Subjects k_PSO_90days
 
Add-ADFineGrainedPasswordPolicySubject "PSO 190 days" -Subjects k_PSO_190days

Nun ordnen wir sämtlichen Benutzeraccounts eine Richtlinie zu. Hierzu nehmen wir den Benutzer Julian.Schuetz mit in die Gruppe „k_PSO_180days“ mit auf. Den Benutzer T0-pad-jschuetz nehmen wir in die Gruppe „k_PSO_90days“ mit auf. Und den Service-Account T1-SVC-Sophos, Sie ahnen es sicherlich schon, nehmen wir in die Gruppe „k_PSO_190days“ mit auf.

Mit dem folgenden Befehl können wir nun die Anwendung der neuen Kennwortrichtlinie validieren:

Get-ADUserResultantPasswordPolicy -Identity julian.schuetz

Es empfiehlt sich für sämtliche Service-Accounts ein Verzeichnis zu pflegen:

#	Service Account	SOP	Interval
1	KRBTGT	PWChange_KRBTGT.docx	Alle 3 Monate
2	Azureadssoacc	PWCHange_AzureADCCOACC.docx	Alle 30 Tage
3	T1-SVC-Sophos	PWCHange_T1-SVC-Sophos.docx	k_PSO_190days
4	Ergänzen und Pflegen

Service-Account Verzeichnis

Der Vorteil liegt auf der Hand, durch die Pflege von einem Verzeichnis, können regelmäßige Kennwortänderungen für die Service-Accounts in den Administratoren Alltag leicht integriert werden. Jede Applikation erhält somit einen eigenständigen Account und eine passende Anleitung für den regelmäßigen Kennwortwechsel.

Für die kritischen Administratoren Gruppen im Active Directory sollten Break Glass Accounts eingerichtet. Die Passwörter für diese Accounts sind entsprechend lang und schützenswert und müssen ebenfalls in regelmäßigen Abständen geändert werden.

Kerberos – KRBTG

In diesem Artikel wollen wir uns dem Thema Kerberos widmen und warum man das Kennwort des dazugehörigen KRBTGT-Accounts regelmäßig ändern sollte.

Fangen wir damit da zu erläutern, was Kerberos überhaupt ist und wie es funktioniert und…

…Nein! Kerberos ist nicht der 3-köpfige Hund aus griechischen Mythologie, der das Tor zu Unterwelt bewachen soll! Jedenfalls nicht im Bezug auf die Themen die wir auf diesem Blog anbieten.

Kerberos ist ein Protokoll, um sich innerhalb eines Netzwerkes zu authentifizieren und somit den Zugriff auf bestimmte Ressourcen zu erhalten. In diesem Vorgang werden sogenannte Tickets ausgestellt, die es einem Benutzer erlauben, auf die benötigten Daten zuzugreifen.

Jeder Domänencontroller innerhalb eines Active Directory führt einen KDC-Dienst (Kerberos Distribution Center) aus, der für die Bearbeitung der Ticketanfragen genutzt wird. Das KDC wiederum nutzt das oben erwähnte KRBTGT-Konto (zu finden unter der „Users“-Organisationseinheit in der Active Directory Struktur) um die auszustellenden Tickets zu signieren. Es ist quasi die Unterschrift auf dem Ticket, um die Gültigkeit zu gewährleisten. Alle Domänencontroller in der Domäne nutzen das gleiche KRBTGT-Konto, sodass die Tickets in der gesamten Domäne und von jedem DC überprüft und als validiert angesehen werden. Ein Ausnahme bilde da nur die sogenannten RODC’s (Read Only Domain Controller), da diese jeweils ihren eigenen KRBTGT-Account besitzen.

Wie funktioniert eine Ticketanforderung?

Der genaue technische Ablauf der Ticketanforderung eines Benutzer oder Computers ist sehr komplex. Dort geht es insbesondere um diverse Schlüssel und zugehörige Ver- und Entschlüsselungsverfahren, die auf den getauschten bzw. Client und Server bekannten Schlüsseln basieren. Daher werden wir hier die Kurzfassung darstellen, um den Ablauf einer Anforderung zu erläutern.

Die einzelnen Schritte nochmal etwas genauer erläutert:

Der Benutzer meldet sich mit seinen Anmeldedaten an. Er möchte gerne Zugriff auf eine Ressource. Dafür fragt er beim KDC nach einem TGT (Ticket Granting Ticket). Die Anfrage ist verschlüsselt und kann vom Domänencontroller mit den ihm bekannten in der Ntds.dit gespeicherten Schlüsseln für den Client entschlüsseln.
Wenn der KDC die Anfrage entschlüsseln kann, da der Antragssteller bekannt ist, wird diesem nun das TGT ausgestellt. Dieses Ticket ist im Normalfall 10 Stunden gültig.
Nun schickt der Client eine Anfrage an den TGS, zusammen mit Informationen zum Ziel (Name, Domäne, SPN, Dienst). Diese Anfrage ist ebenfalls wieder mit einem Schlüssel versehen.
Der KDC erhält nun die Anfrage und überprüft, ob er die Anfrage entschlüsseln kann (auch hier werden wieder Key aus den bereits generierten Informationen genutzt), stellt er für den Client und die angeforderte Ressource das passende Service Ticket aus.
Mit dem erhaltenen Service Ticket, kann der Client den Zugriff auf die angeforderte Ressource, in unserem Fall den Fileserver, anfordern. Der Zielserver kann das erhaltenen Paket nun mit seinen bekannten Schlüsseln entpacken und erhält somit den Service Ticket sowie den sogenannten Session Key der ebenfalls mit getauscht wird.
Mit den ihm nun bekannten Informationen ist der Client auch auf dem Fileserver berechtigt und eine Verbindung zwischen den beiden wird aufgebaut.

Sowohl TGS als auch Service Tickets besitzen einen Gültigkeitsreitraum. Das bedeutet, einmal ausgestellt, werden keine Kennwörter mehr über das Netz verschickt, solange das Ticket noch gültig ist. Das ist einer der großen Sicherheitsvorteile von Kerberos.

Kleiner Tipp am Ende:

Einer der Verschlüsselungsattribute ist die Uhrzeit der Systeme. Laufen die Systeme mehr als 5 Minuten auseinander, kann der KDC die Anforderung des Clients nicht mehr entschlüsseln. Dies führt dazu, dass eine Authentifizierung und somit der Austausch der Tickets nicht mehr möglich ist. Also, sollte eine Anmeldung oder der Zugriff auf eine Ressource nicht funktionieren, schaut ob die Zeiten auf beiden Systemen synchron laufen.

PKI – Public Key Infrastruktur

Wir alle wissen, Zertifikate sind oftmals ein leidiges Thema. Die Erfahrung zeigt, dass viele sich an das Thema nicht so recht ran trauen. In der heuten Zeit kommt man aber an einer sauber konfigurierten PKI-Infrastruktur nicht mehr vorbei.

Leider ist uns im Zuge unserer Tätigkeiten immer wieder aufgefallen, dass es sich bei den genutzten Zertifizierungsstellen oftmals um eine „Quick & Dirty“ Lösung handelt. Das bedeutet, dass die Rolle der Zertifizierungsstelle nicht per Best Practice aufgebaut wurde, sondern einfach als zusätzliche Rolle auf einem bestehenden Server, oder noch schlimmer, auf einem der Domänencontroller installiert wurde. Auch die Konfiguration der Sperrlisten ist allzu oft nicht korrekt durchgeführt worden.

Der ein oder andere wird sich jetzt eventuell Fragen: Ist das denn so schlimm?

Ja, ist es!

Abgesehen davon, dass eine Zertifizierungsstelle und die damit ausgestellten Zertifikate eine immer größere Rolle in der Absicherung der eigenen Infrastruktur spielen und somit natürlich auch dementsprechend abgesichert werden müssen, führen auch grade die auf einem Domänencontroller installierten PKI’s zu Problemen sobald man den Domänencontroller einmal ersetzen möchte. Denn, wer schon mal vor so einer Situation stand, weiß, dass sich ein Domänencontroller nicht herunterstufen lässt, sobald dort eine Zertifizierungsstelle läuft. Spätestens dann kommt man in die Bedrängnis, die PKI zu migrieren.

Wie sollte also eine PKI-Infrastruktur aussehen?

Die minimale Konfiguration einer abgesicherten sogenannten 2-stufigen Zertifizierungsstellen-Infrastruktur beinhaltet eine Offline ROOT CA und eine Online ISSUING CA. Optional bietet ein OCSP eine weitere Möglichkeit, Sperrlisten abzugleichen und diese z.B. für extern genutzte Zertifikate erreichbar zu machen.

Offline ROOT CA

Die Offline ROOT CA wird als eigenständige Maschine installiert und darf kein Mitglied der bestehenden Domäne sein. Da die restliche Struktur der PKI auf der ROOT CA aufbaut, muss diese natürlich so sicher wie möglich aufgebaut werden. Das bedeutet in diesem Fall, dass die CA nur die Zertifikate für die ISSUING CA’s ausstellt. In kleineren Unternehmen wird das vermutlich nur ein einziges sein. Nachdem die ROOT CA das Zertifikat ausgestellt hat und alle weiteren Konfigurationen durchgeführt wurden, wird die Maschine ausgeschaltet. Nur bei Aktualisierung der Sperrlisten oder Erneuerung des ISSUING CA Zertifikates wird das System wieder hochgefahren (kleiner Tipp: Dieser Zeitpunkt bietet sich dann natürlich auch super für Windows Updates an).

Dadurch, dass das System also eigentlich dauerhaft ausgeschaltet ist, ist ein Angriff und somit eine Kompromittierung des Systems nahezu unmöglich. Allein diese Tatsache führt zu einem hohen Anstieg der Sicherheit der gesamten PKI-Infrastruktur.

ISSUING CA

Neben der Offline ROOT CA wird dementsprechend eine ISSUING CA konfiguriert. Diese wird als Teil der bestehenden Domäne installiert und dient als Zertifikatsherausgeber für die benötigten Zertifikate im Unternehmen. Sie dient als erste Anlaufstelle für sämtliche Zertifikatsanforderungen und bietet meist ebenfalls die Sperrlisten an.

OCSP

Eine dritte Komponente ist der sogenannte OCSP – Online Certificate Status Protocol. Hierbei handelt es sich um eine Web-Komponente, über die Clients die Abfrage der Sperrlisten durchführen lassen können. Der OCSP dient als Mittelsmann und gibt den Clients die Rückmeldung, ob ein Zertifikat noch gültig ist oder dieses bereits gesperrt wurde. Das verlagert die Last von den Clients hin zum OSCP Server. Aussehen kann eine korrekt eingerichtete PKI-Infrastruktur also wie folgt:

So sollte eine minimale PKI Infrastruktur aufgebaut sein.

LLMNR & NBT-NS Spoofing

Leider beobachten wir immer wieder, dass veraltete und unsichere Protokolle wie LLMNR und NBT-NS weiterhin aktiv sind. Hintergrund ist, dass diese gravierenden Schwachstellen vielen nicht bewusst sind.

Doch der Reihe nach, was ist eigentlich Spoofing?

Spoofing beschreibt eine Methode, bei welcher sich ein Angreifer als vertrauenswürdige Person oder Gerät ausgibt, um an eine sensible Information zu gelangen. Wie beispielsweise wertvolle Password-Hashes.

Nun gut und was hat es nun mit LLMNR und NBT-NS auf sich?

Sowohl LLMNR (Local Link Multicast Name Resolution) als auch NetBIOS Naming Service dienen leider weiterhin als Fallback-Szenario für die Namensauflösung. Das bedeutet, sobald die DNS-Server keine passende Antwort liefern, begibt sich der Client via Broadcast selbst auf die Suche. Das erschreckende dabei ist, dass der Client hierbei jeder Antwort vertraut.

Folgendes Beispiel soll die Einfachheit einer Attacke verdeutlichen.

Der Laptop erhält keine passende Antwort von einem DNS-Server. Eventuell hat der Anwender sich nur vertippt. Nun fragt der Client trotzdem via Broadcast sämtliche Netzwerkteilnehmer nach einer passenden Antwort. Ein Angreifer kann sich dies nun zu nutzen machen und sich einfach als it-consulting-fs01 ausgeben und antworten.

Der Client wird nun sogar sein Password-Hash an den Angreifer senden. Der Angreifer besitzt nun zwei Möglichkeiten, er kann offline mit dem Cracking beginnen. Oder der Angreifer verwendet einfach eine Pass-The-Hash Attack und nutzt den vorhanden Password-Hash für eine Authentifizierung an weiteren Systemen. Sie können sich daher vorstellen, was passieren würde, wenn Sie keine Rollentrennung verwenden und gar als Domänen-Administrator arbeiten.

In Zeiten von einer hybriden Arbeitswelt, in denen die mobilen Laptops in nicht vertrauenswürdigen Netzwerken agieren, müssen die Protokolle daher zwingend deaktiviert werden.

Mitigation

Deaktivieren Sie LLMNR und NBT-NS via GPO
Aktivieren Sie die Windows Firewall
Erzwingen Sie SMB-Signing via GPO
Arbeiten Sie niemals mit einem Domänen-Administrator auf einem Client

Application Protection

Ein weiterer wichtiger Schritt hin zu einer Zero-Trust-Implementierung ist es, sämtliche Anwendungen zu schützen. Azure AD (AAD), als zentrales IAM ermöglicht es einfach, die strengen Benutzerzugriffskontrollen, welche mit MFA und dem bedingten Zugriff (Conditional Access) eingerichtet wurden, für weitere Anwendungen durchzusetzen.

Um Ihre Anwendungen zu schützen, sollten Sie daher zunächst AAD für alle Ihre SaaS-Anwendungen mit SAML, OAuth oder OIDC konfigurieren.

Für Anwendungen, welche diese modernen Protokolle nicht unterstützen, verbinden Sie Ihre VPN-Lösung mit der Azure AD Authentifizierung. Dadurch können Sie die erweiterte Geräte- und Benutzervalidierung nutzen, um so die Sicherheit signifikant zu erhöhen.

Der nächste Schritt besteht darin, Anwendungen von VPNs weg zu verlagern, indem bestehende On-Prem-Geschäftsanwendungen und IaaS-Anwendungen über Azure App Proxy, Kemp Loadbalancer oder NetScaler veröffentlicht werden.

Bedingter Zugriff in Verbindung mit Kemp als Reverse Proxy

Dies schützt nicht nur die Anwendung, sondern ermöglicht es Ihnen auch, Benutzerkonten den Zugriff auf eine einzelne Anwendung zu beschränken. Im Gegensatz zu herkömmlichen VPNs, welche häufig Zugriff auf alle Ports und Protokolle in einem Netzwerk bieten. Und somit eher der Vergangenheit angehören.

Wir erinnern uns, ein wichtiger Ansatz von einer Zero-Trust-Implementierung ist es:

Benutzerkonten erhalten keinen pauschalen Zugriff auf Anwendungen, Dienste und Dateien, sondern lediglich Zugriff auf die Ressourcen, welche diese für die jeweilige Aufgabe benötigen.

LAPS – Local Administrator Password Solution

„Kleines Tool, große Wirkung“

Was ist LAPS?

Im Zuge der Absicherung der internen Windows Systeme gibt es diverse Hilfsmittel, um schnell und unkompliziert gewisse Risiken zu minimieren. Eines dieser Hilfsmittel ist LAPS.

Die Funktionsweise des von Microsoft unterstützten Tools ist relativ einfach erklärt. LAPS ändert in definierten Zeitabständen das lokale Administrator-Kennwort eines Systems in ein zufällig generiertes Kennwort, welches im AD-Objekt des Computers abgelegt wird. Dieses kann, bei Bedarf, per PowerShell oder installierte GUI von den berechtigten Benutzern ausgelesen werden.

Vorteile von LAPS

Allein die regelmäßige Änderung der lokalen Administrator-Kennwörter führt in vielen Umgebungen zu einem erheblichen Anstieg der Sicherheit, da, wie die Erfahrung zeigt, viele Server oder auch Clients mit dem gleichen Kennwort installiert und ausgerollt werden. Aufgrund dieser Tatsache würde es einem potenziellen Angreifer leichtfallen, sich auf den Systemen innerhalb der eigenen Infrastruktur fortzubewegen, wenn ihm dieses Kennwort in die Hände fällt.

Doch nicht nur der Schutz vor Angriffen steht hier im Fokus. Auch die temporäre Herausgabe von Adminstrationsrechten an Dritte kann darüber realisiert werden. Sollte z.B. ein Dienstleister für die Installation einer Software oder dergleichen administrativen Zugriff auf ein System benötigen, so kann man der betroffenen Person das durch LAPS generierte Kennwort mitteilen. Durch das Kennwort ist es nun möglich, administrativ auf der Maschine zu arbeiten, ohne einen Domänenbenutzer mit den Rechten ausstatten zu müssen. Nach erfolgreich durchgeführter Arbeit, kann nun durch LAPS ein neues Kennwort generiert werden und das mitgeteilte Kennwort verliert seine Gültigkeit. Somit ist kein Zugriff mehr auf das System möglich.

Gleiches gilt natürlich nicht nur für externe Zugriffe. Auch bei internen Zugriffen kann LAPS ein großer Vorteil sein. Benötigen beispielsweise die Auszubildenden oder Praktikanten einmal administrativen Zugriff auf einen Client oder Server, so kann man diesen ebenfalls das temporäre Kennwort mitteilen damit die benötigten Arbeiten durchgeführt können, ohne den Active-Directory Benutzern mit zu vielen Rechten auszustatten oder das eventuell allseits genutzte lokale Administratorkennwort mitzuteilen.

Ein weiterer Vorteil liegt darin, dass diese Kennwörter, nach dem per Gruppenrichtlinien definierten Zeitraum, garantiert ihre Gültigkeit verlieren. Das bedeutet, selbst wenn man durch den stressigen Arbeitsalltag vergessen sollte das Kennwort zurückzusetzen, verliert es automatisch seine Gültigkeit und kann somit nicht mehr genutzt werden.

Sicherheitsbedenken

Des Öfteren sind im Zuge der Einführung von LAPS einige Fragen zur Sicherheit aufgekommen. Denn wie wir im oberen Abschnitt gelernt haben, schreibt LAPS die Kennwörter im Klartext in das Computerobjekt. Nicht ohne Grund kommt daher die Frage auf:

Ist LAPS denn nun sicher?

Die kurze Antwort: Ja

Damit LAPS allerdings auch wirklich sicher ist, gibt es einige Dinge zu beachten. Bei der Einführung von LAPS werden im AD Schema zwei zusätzliche Attribute hinzugefügt. In diese werden bei erfolgreichem Rollout zum einen das Kennwort, zum anderen das Datum der Kennwortänderung gespeichert. Diese Attribute können in der Standardkonfiguration nur die Benutzer der Gruppe „Domänen-Admins“ auslesen. Über die mitgelieferten PowerShell Module können diese Berechtigungen per Active Directory OU für weitere Gruppen definiert werden. Dabei ist darauf zu achten, dass die richtigen Gruppen genutzt werden.

Zusätzlich dazu sollte aber allgemein die Active Directory Struktur auf eventuell manuell gesetzte Berechtigungen geprüft werden. Denn falsch gesetzte Berechtigungen können dazu führen, dass nicht definierte Gruppen und Benutzer die Kennwörter bzw. die eigentlich geschützten Attribute auslesen können.

Fazit

Wenn das Active Directory richtig gepflegt und administriert wird, ist LAPS eine großartige Ergänzung, um die Sicherheit im Unternehmen zu erhöhen. Wir empfehlen daher den Einsatz des Tools unter den unter Sicherheitsbedenken erwähnten Voraussetzungen.