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.

AD Tiering Struktur – Funktion und Nutzen

In diesem Artikel wollen wir euch das Thema Tiering näherbringen. Grundsätzlich fällt dieses Thema in den Bereich des Active Directory Hardenings. Allerdings besteht die Einführung dieses Modells nicht nur aus der technischen Umsetzung. Viel wichtiger ist es, den Administratoren der Systeme, den richtig Umgang mit der neuen Struktur aufzuzeigen und diese zu verinnerlichen.

Aber erstmal zurück zum Anfang. Die erste Frage, die sich viele stellen ist:

Was ist überhaupt ein Tiering Modell?

Das Tiering oder auch ESAE (Enhanced Security Admin Environment) wird genutzt, um die administrative Architektur einer Domäne abzusichern. Durch eine Trennung der administrativen Konten und den Systemen in unterschiedliche „Schutzbereiche“, können Angriffe auf die interne Struktur reduziert bzw. deutlich erschwert werden.

Man trennt die vorhandene Struktur in drei Tiering Zonen sowie einen Benutzerbereich auf.

Jedes dieser Tiers bekommt eigene Administratoren. Wie auf dem Bild zu sehen, bekommt der jeweilige Admin nur Zugriff auf den ihm zugeteilten Bereich. Ein Zugriff auf eines der anderen Tiers ist nicht erlaubt.

Wie bereits oben erwähnt, handelt es sich bei den Tiering Benutzern um rein administrative Konten. Mit den Benutzern darf also nicht im normalen Tagesgeschäft gearbeitet werden. Sie sind rein für administrative Tätigkeiten gedacht.

Gearbeitet werden sollte mit diesen Benutzern über eine sogenannte PAW (Priviliged Access Workstation). Eine genauere Erklärung dazu gibt es in einem bald folgenden Blog-Artikel zum Thema  PAW.

Da wir nun schon einmal grob erklärt haben, um was es sich beim Tiering Modell handelt, stellt sich nun natürlich direkt die nächste Frage.

Warum benötige ich ein Tiering Modell?

Nun, auf diese Frage gibt es eigentlich eine sehr einfache Antwort:

MEHR SICHERHEIT!

Grade die letzten Jahre haben gezeigt, dass kein Unternehmen vor Cyberangriffen sicher ist. Ich denke, jeder hat schon von mindestens einer Firma gehört, die Opfer einer Cyberattacke war. Sei es Verschlüsselungen, Datendiebstahl oder eine der anderen Attacken.

Wir müssen also versuchen, die eigene Infrastruktur so sicher wie möglich bzw. es dem Angreifer so schwer wie möglich zu machen, die Infrastruktur zu „infiltrieren“. Durch die Trennung in die drei Sicherheitsbereiche wollen wir eine komplette Kompromittierung der Domäne verhindern. Bei einem sauber eingerichteten und von den Mitarbeitern korrekt genutzten Tiering Modell, kann ein Angriff deutlich eingegrenzt werden. Denn selbst wenn ein Angreifer an ein administratives Kennwort gelangen könnte, hat er dadurch nicht die Möglichkeit sich in dem nächsthöheren Tier zu bewegen.

Erklären wir das mal an einem Beispiel:

Ohne Tiering:

Benutzer A hat sich auf seinem Client einen Trojaner oder ähnliches eingefangen. Er meldet sich beim IT-Support. Dieser schaltet sich nun mit seinem Administrator auf diesem Client auf. Da der Angreifer den Client des Benutzers bereits kompromittiert hat, ist es für ihn nun ein Leichtes an die Anmeldedaten des aufgeschalteten Admin-Benutzers zu gelangen, da diese als Hash-Wert auf dem Client gespeichert werden.

Mit den abgegriffenen Anmeldedaten des Support-Mitarbeiters (meistens ebenfalls Domänen-Administrator) hat der Angreifer nun die Möglichkeit, tiefer ins System vorzudringen und im schlimmsten Fall bis zu einem Domänencontroller zu gelangen. Sollte er Zugriff auf diesen erhalten, kann er sich nun frei in der Domäne bewegen, ohne dass es jemand mitkriegen würde.

Somit wäre die komplette Domäne kompromittiert und müsste im schlimmsten Fall komplett neu aufgesetzt werden. Auch eine komplette Verschlüsselung aller Systeme ist dadurch möglich, da der Angreifer kompletten Zugriff auf sämtliche Ressourcen hätte.

Mit eingerichtetem Tiering:

Im gleichen Szenario wie oben beschrieben hätte der Angreifer keine Chance weiter in die Domäne vorzudringen. Sollte sich im gleichen Beispiel ein Support Mitarbeiter mit seinen eigens für die Client- Administration (z.B. T2-Mustermann) angelegten Benutzer anmelden und der Angreifer ebenfalls die Anmeldedaten abgreifen, kann er sich maximal auf Clientebene bewegen. Er hat aber durch die Trennung in die unterschiedlichen Tiering Bereiche, keine Möglichkeiten, sich auf Anwendungs-server oder im schlimmsten Falle, Domänencontroller fortzubewegen.

Wie gehe ich vor, wenn ich ein Tiering einführen möchte?

Hier gibt es keine einfache Antwort. Grundsätzlich kann ein Tiering Modell von jedem in Betrieb genommen werden. Es müssen die benötigten Active Directory Anpassungen durchgeführt werden, die zugehörigen Benutzer erstellt und per Gruppenrichtlinien die nötigen Einschränkungen ausgerollt werden.

Beispiel einer einfache Tiering OU Struktur:

Das Wichtigste bei der Inbetriebnahme eines solchen Modells ist es aber, die zukünftigen Nutzer des Tiering Modells in die neue Arbeitsweise einzuarbeiten und den Nutzen zu verdeutlichen. Denn nur wenn sich sämtliche Mitarbeiter mit administrativen Konten an die neuen Regeln halten, kann man die Sicherheit der eigenen Infrastruktur erhöht werden.

Auch sollten vorher sämtliche Zugriffe auf die Systeme geklärt werden, denn es sollten auch die diejenigen einen T0 Administrator bekommen, die wirklich Zugriff auf T0 Systeme benötigen. Bei den administrativen Benutzern gilt:

So wenig wie möglich, so viel wie nötig.

Um die Nutzer zu erstellen und zu wissen, worauf sie Zugriff benötigen, gibt es natürlich eine weitere Hürde. Welches System gehört in welches Tier? Hierfür haben wir ein grobes Entscheidung-Diagramm erstellt.

Wie bereits erwähnt, handelt es sich hierbei nur um eine sehr grobe Auswahlhilfe. Jedoch kann es dabei helfen, eine erste Unterteilung seiner Systeme durchzuführen.


Fazit

Ich hoffe, wir konnten euch ein wenig für das Thema Tiering sensibilisieren. Grundsätzlich kann man durch die Einführung eines neuen administrativen Konzeptes die Sicherheit im eigenen Unternehmen deutlich erhöhen. Jedoch darf man nie vergessen, dass sämtliche Änderungen nur dann funktionieren können, wenn die Mitarbeitenden das Konzept unterstützen und mittragen.

Bevor sich jemand dazu entscheidet, ein Tiering bei sich einzuführen, besprecht es bitte mit allen Administratoren und klärt, ob sie dafür bereit sind die Idee mit umzusetzen. Denn das beste Konzept hilft nichts, wenn es Benutzer gibt, die es umgehen bzw. boykottieren.

Die Erfahrung zeigt aber, dass nach einer sachlichen Einweisung der IT-Mitarbeiter und der Beantwortung aller Fragen, kaum noch „Gegenwind“ herrscht.

User Access and Identity

Als Kernstück der Infrastruktur der meisten Unternehmen, spielt das Active Directory eine entscheidende Rolle.

Wichtige Active Directory Security Themen, welche alle AD Administratoren und Administratorinnen kennen und berücksichtigen sollten:

  • Clean Source
  • FGPP für sämtliche Kontentypen
  • Dedizierte Service Accounts
  • Verwendung von gMSA
  • Domain Controller Hardening
  • PKI Hardening
  • Client Hardening
  • Kerberos/KRBTGT
  • RODC für nicht vertrauenswürdige Standorte
  • Netzwerk Segmentierung
  • Backup und Recovery
  • Secure Time Source
  • AdminSDHolder
  • AD Delegation nutzen
  • Security mit GPO’s
  • Verwendung möglichst sicherer Protokolle: LDAPS, Kerberos, Zertifikate, Cipher Hardening
  • Deaktivierung unsicherer Protokolle: SMBv1, LLMNR & NetBIOS, WDigest
  • LAPS
  • Secure RDS
  • AD Cleanup
  • Credential Caching verhindern
  • Protected Users
  • Klartextprotokolle vermeiden
  • Überwachungsrichtlinien
  • Microsoft Security Compliance Toolkit
  • aktives Monitoring
  • AD Tiering Struktur
  • Adminkonzept
  • Windows Hello for Business
  • VM Verschlüsselung
  • Festplattenverschlüsselung

Wichtige Azure Active Directory Themen:

  • Multifaktor Authentifizierung
  • Windows Hello for Business
  • Privileged Identity Management (PIM)
  • Conditional Access (Bedingter Zugriff)
  • Modern Authentication
  • Azure AD Password Protection
  • Device Identity (Azure AD Join AADJ, Hybrid Azure AD Join HAADJ)
  • Defender for Endpoint
  • Defender for Office 365
  • Defender for Cloud Apps
  • Defender for Identity

Zero-Trust-Implementierung mit Microsoft 365

Zero-Trust ist nicht mehr nur ein Schlagwort!

Ob als Basis-Anforderung von Cybersecurity-Versicherungen bis hin zu der Umsetzung von Best-Practices oder Zertifizierungen nach CIS, CISA, Tisax oder dem NIST-Framework.

In der neuen Post-COVID-Welt des hybriden Arbeitens ist es offensichtlich, dass das altmodische Sicherheitskonzept basierend auf Perimeter-Sicherheit nicht mehr ausreichend ist. Wir sprechen hierbei eher von einer dezentralen Belegschaft, welche von nicht vertrauenswürdigen Netzwerken auf Unternehmensressourcen zugreifen soll.

Die Perimeter-Sicherheit basiert darauf, dass sich Unternehmen gegen den externen Zugriff durch Firewalls und Virtual Private Networks (VPN) geschützt haben.

Nur Netzwerktraffic und Zugriffe, die von außen erfolgen, sind potenziell gefährlich und müssen dementsprechend analysiert und beschränkt werden.

Diese Konzepte haben den gewaltigen Nachteil, dass sobald jemand in das Firmennetz eingedrungen ist, kaum noch Sicherheitsvorkehrungen vorhanden sind. Zudem berücksichtigen diese Konzepte die Tatsache nicht, dass ein erhebliches Bedrohungspotential von den eigenen Mitarbeitern und Mitarbeiterinnen ausgeht.

Die Mitarbeiter und Mitarbeiterinnen erwarten, überall, jederzeit und auf jedem Gerät zu arbeiten. Damit verliert die Perimeter-Sicherheit an Wirkung und Bedeutung.

Im Rahmen unserer Tätigkeiten als Microsoft Consultants bemerken wir häufig, wie viele Unternehmen sich weiterhin ausschließlich auf den Schutz durch Firewalls, Anti-Virenscannern etc. verlassen. Der folgende Blog soll daher mehrere Phasen einer Zero-Trust-Implementierung berücksichtigen.

Phasen der Implementierung:

User Access and Identity

Bevor ein Benutzeraccount versucht auf eine Ressource zuzugreifen, müssen Sie folgendes berücksichtigen:

  • Die Identität muss mit einer starken Authentifizierung verifiziert werden (MFA/Passwordless).
  • Sicherstellen, dass der Zugriff konform und typisch für diese Identität ist.
  • Die Grundsätze des geringstmöglichen Privilegs beim Zugriff befolgen.

Nachdem die Identität verifiziert wurde, können wir den Zugriff dieser Identität auf Ressourcen anhand von Unternehmensrichtlinien, laufenden Risikoanalysen und anderen Tools kontrollieren. Hierzu nutzen wir Conditional Access.

Zum Glück ist eine schnelle Zero-Trust-Implementierung relativ einfach, wenn Sie Microsoft 365 verwenden.

Cookie Consent mit Real Cookie Banner