Lektionen aus dem Angriff auf Südwestfalen-IT: Prävention und Schutzmaßnahmen

Der Angriff auf Südwestfalen-IT durch die Ransomware-Gruppe „Akira“ im Oktober 2023 bietet wertvolle Einsichten in Cybersicherheitsrisiken und Präventionsstrategien. Dieser Blogbeitrag analysiert die einzelnen Schritte der Angreifer und diskutiert, wie diese hätten vermieden werden können. Als Quelle fungierte der öffentliche forensische Bericht.

Schritt 1: Identitäten absichern und Sicherheitsupdates einspielen

Schwachstelle in der VPN-Lösung: Der Angriff begann mit dem Ausnutzen einer Schwachstelle (CVE-2023-20269) in der VPN-Lösung ohne Multi-Faktor-Authentifizierung (MFA).

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

Die angebliche Zero-Day Schwachstelle, welche von der Akira Ransomware Gruppe ausgenutzt wurde, wurde bereits am 24ten August von Cisco in einem Blog Artikel erwähnt. Von einer Zero-Day Attacke (CVE-2023-20269) kann bei 55 Tagen nach Bekanntgabe daher nun wirklich keine Rede sein. Ein passendes Sicherheits-Update wurde am 11ten September zur Verfügung gestellt. Erste identifizierte Angriffe wurden am 18ten Oktober identifiziert werden.

Akira Ransomware Targeting VPNs without Multi-Factor Authentication – Cisco Blogs

Prävention: Die Implementierung von einer sicheren MFA hätte den Zugriff deutlich erschwert. Außerdem sollte bei Bekanntgabe von CVE’s immer eine direkte Bewertung sowie passende Maßnahmen umgesetzt werden. Die Einrichtung von Systemen zur Erkennung verdächtiger Aktivitäten, wie ungewöhnliche Anmeldeversuche oder auffällige Netzwerkbewegungen, hätte die frühzeitige Erkennung des Angriffs ermöglichen können.

Schritt 2: Ausbreitung

Erhalten administrativer Berechtigungen: Nach dem Zugang zum Netzwerk erlangten die Angreifer administrative Rechte.

Die Angreifer konnten das Administrator-Kennwort ausnutzen, weil es seit 2014 in einem Gruppenrichtlinienobjekt in entschlüsselbarer Textform hinterlegt war. Jeder Angreifer mit gültigen Domänen-Zugangsdaten konnte dadurch das Kennwort auslesen. Unter Verwendung eines von Microsoft bereitgestellten AES-Schlüssels ließ sich das Kennwort entschlüsseln, was den Angreifern ermöglichte, ihre Zugriffsberechtigungen auf das Niveau eines Domänen-Administrators zu erhöhen, ohne dabei typische forensische Anzeichen für Privilege Escalation oder Lateral Movement zu hinterlassen.

Prävention: Striktere Zugriffskontrollen und regelmäßige Überprüfungen der Berechtigungen hätten dies verhindern können. Sie sollten regelmäßig ihre Identity und Access Management Systeme auditieren.

Schritt 3: Verbreitung der Ransomware

Verbreitung der Ransomware: Die Ransomware wurde innerhalb der Windows-Domäne verbreitet. Die Verteilung der Ransomware erfolgte gezielt und anscheinend mittels Zugriffen auf das C$-Netzwerkshare der einzelnen Server. Es wurde angenommen, dass die Ransomware von Zielsystemen durch diese Zugriffe ausgeführt wurde. Diese Annahme stützt sich darauf, dass keine Spuren gefunden wurden, die auf andere Verteilungsmethoden hindeuten. Außerdem wurde festgestellt, dass die Ransomware w.exe selbst Logfiles schrieb, welche dokumentierten, welche Aktionen durch die Schadsoftware durchgeführt wurden und welche Fehler beim Verschlüsseln auftraten.

Es wurden 961 Systeme identifiziert, auf denen die Ransomnote akira_readme.txt vorzufinden war. Zum Glück wurden keine GPO’s, wie bei anderen Ransomware Gruppen üblich, verwendet. Andernfalls wären ca. 4200 Clients und 800 Server betroffen.

Prävention: Bessere Netzwerksegmentierung, ein AD Tiering, eine klassische Server Härtung und strengere Zugangskontrollen hätten die Ausbreitung eingedämmt.

AD Tiering Struktur – Funktion und Nutzen

Schritt 4: Verschlüsselung von Daten

Die Ransomware verschlüsselte das Dateisystem von Südwestfalen-IT, indem sie einen rekursiven Ansatz verfolgte. Das Programm durchlief das gesamte Dateisystem und verschlüsselte jedes Verzeichnis einzeln, beginnend mit dem angegebenen Startpfad. Interessanterweise nutzte die Ransomware, benannt als w.exe, eine Blacklist, um bestimmte Dateitypen, Dateiendungen und Verzeichnisse von der Verschlüsselung auszunehmen. Nachdem die Verschlüsselung in einem Verzeichnis abgeschlossen war, platzierte die Ransomware in jedem betroffenen Verzeichnis eine Erpressungsnachricht mit dem Namen „akira_readme.txt“​

Prävention: Regelmäßige Backups und ein effektiver und regelmäßig erprobter Disaster-Recovery-Plan hätte zudem eine schnellere Wiederherstellung der Systeme ermöglicht.

Schlussfolgerung:

Das Fazit aus dem Angriff auf Südwestfalen-IT durch die Ransomware-Gruppe „Akira“ unterstreicht die Wichtigkeit einer umfassenden und proaktiven Cybersicherheitsstrategie. Die Schlüsselerkenntnisse sind:

  1. Bedeutung von Multi-Faktor-Authentifizierung: Die Abwesenheit von MFA, insbesondere bei kritischen Zugangspunkten wie VPNs, kann Türöffner für Cyberangriffe sein. MFA ist ein wesentlicher Bestandteil zur Verstärkung der Sicherheitsmaßnahmen.
  2. Wichtigkeit regelmäßiger Sicherheitsaudits: Die Identifizierung und Behebung von Schwachstellen, wie z.B. schlecht gesicherte Passwörter, ist entscheidend, um potenzielle Angriffsvektoren zu minimieren.
  3. Notwendigkeit von Netzwerksegmentierung und strengen Zugriffskontrollen: Diese Maßnahmen können die Bewegungsfreiheit von Angreifern im Netzwerk begrenzen und die Ausbreitung von Malware verhindern oder zumindest einschränken.
  4. Proaktive Überwachung und Anomalie-Erkennung: Frühzeitige Erkennung von verdächtigen Aktivitäten und Angriffsversuchen ist entscheidend, um Eindringlinge abzuwehren, bevor sie ernsthaften Schaden anrichten können.
  5. Bewusstsein und Schulung der Mitarbeiter: Da Menschen oft das schwächste Glied in der Sicherheitskette sind, ist es wichtig, das Bewusstsein und die Wachsamkeit der Mitarbeiter zu stärken.
  6. Robuste Backup- und Disaster-Recovery-Strategien: Diese sind unerlässlich, um die Resilienz gegen Ransomware-Angriffe zu erhöhen und die Geschäftskontinuität im Falle eines Datenverlusts sicherzustellen.
  7. Einsatz fortschrittlicher Sicherheitslösungen: Der Einsatz moderner Antivirus- und Endpunkt-Schutzlösungen kann dazu beitragen, Bedrohungen frühzeitig zu erkennen und zu neutralisieren.

Der Vorfall zeigt einmal mehr, dass Cybersicherheit ein kontinuierlicher Prozess ist, der ständige Aufmerksamkeit und Anpassung erfordert, um mit den sich ständig weiterentwickelnden Bedrohungen Schritt zu halten.

Abschließend lässt sich sagen, dass der Angriff auf Südwestfalen-IT die Notwendigkeit eines Zero-Trust-Ansatzes in der Cybersicherheit unterstreicht. Zero-Trust bedeutet, grundsätzlich keinem Akteur innerhalb oder außerhalb des Netzwerks zu vertrauen, sondern jede Anfrage als potenzielle Bedrohung zu behandeln. Dieser Ansatz fordert eine kontinuierliche Überprüfung und Authentifizierung, um Sicherheit in einer immer komplexeren und vernetzteren digitalen Welt zu gewährleisten. Der Vorfall zeigt deutlich, dass der Übergang zu einem Zero-Trust-Modell für Unternehmen unerlässlich ist, um sich gegen fortgeschrittene und sich ständig weiterentwickelnde Cyberbedrohungen zu schützen.

Exchange Hybrid: Neuer Assistent für die Hybridkonfiguration (HCW)

Heute möchte ich euch über die neueste Version des Hybrid Configuration Wizard (HCW) berichten, die Microsoft am 24ten Januar 2024 veröffentlicht hat. Der HCW ist ein nützliches Tool, um eine Hybrid-Konfiguration zwischen Exchange Server und Exchange Online einzurichten und zu verwalten.

Neuer HCW

Was ist neu am HCW?

Die wichtigste Neuerung ist die Möglichkeit, bei einem erneuten Ausführen des HCW explizit auszuwählen, welche Konfigurationen durchgeführt werden sollen. Bisher konnte es passieren, dass der HCW einige Einstellungen, die manuell angepasst wurden, auf die Standardwerte zurücksetzte. Dies war vor allem bei der wichtigen Einstellung „Centralized Mail Transport“ ein kritischer Punkt. Denn die zuvor gesetzte Einstellung wurde bei einem erneuten Ausführen des Assistenten immer deaktiviert. Was gravierende Auswirkungen auf dem Mail-Fluss zur Folge hatte.

Das ist nun vorbei, denn der HCW erlaubt es, gezielt die gewünschten Konfigurationen anzuhaken. Das ist besonders praktisch für wiederkehrende Aufgaben wie das Zertifikatsmanagement.

Einfachere Aktualisierung der Zertifikate

Eine weitere neue Funktion ist die Option “Update Secure Mail Certificate for connectors”. Diese findet man im Bereich “Configure Mail Flow”. Damit kann man das TLS-Zertifikat, welches für den Mail-Fluss zwischen Exchange Server und Exchange Online verwendet wird, erneuern oder ersetzen. Nachdem man das neue Zertifikat installiert hat, muss man nur noch den HCW ausführen, die Option ankreuzen und auf “Update” klicken. Der HCW kümmert sich dann um die nötigen Anpassungen der Konnektoren.

Änderungen der notwendigen Berechtigungen

Außerdem hat Microsoft Anforderungen der Berechtigungen, die für die Durchführung von Hybrid-Konfigurationen in Microsoft 365 erforderlich sind, angepasst. 

Diese Anpassungen reduzieren die Szenarien, in denen Globale Admin-Berechtigungen erforderlich sind, wenn man den HCW ausführt, um Änderungen an einer bestehenden Hybrid-Konfiguration vorzunehmen.

Organisationsverwaltungs-Berechtigungen in Exchange On-Premises und Exchange Online sind nun für die häufigsten Szenarien ausreichend

Bitte beachten Sie, dass für eine erste Hybrid-Einrichtung weiterhin Globale Admin-Berechtigungen in Microsoft 365 erforderlich sind!

Was sind die Vorteile des HCW?

Der HCW erleichtert die Einrichtung und Verwaltung einer Hybrid-Konfiguration zwischen Exchange Server und Exchange Online. Er führt automatisch die erforderlichen Schritte aus, um eine sichere und zuverlässige Verbindung zwischen den beiden Umgebungen herzustellen. Er unterstützt auch verschiedene Szenarien, wie z.B. die Migration von Postfächern, die gemeinsame Nutzung von Kalendern und Kontakten, die Verwendung von Teams oder die Einhaltung von Compliance-Anforderungen.

Wo kann man mehr über den neuen HCW erfahren?

Microsoft hat die Dokumentation des HCW aktualisiert, um die neuesten Änderungen und die Szenarien, in denen die neue Funktion “Exchange Hybrid-Konfiguration auswählen” verwendet werden kann, zu erklären. Man kann die Dokumentation hier finden.

Fazit

Der HCW ist nun flexibel und anpassbar. Er ermöglicht es, die Hybrid-Konfiguration nach den eigenen Bedürfnissen und Präferenzen zu gestalten. Er bietet die Möglichkeit, die Konfiguration jederzeit zu ändern oder zu aktualisieren, ohne die bestehende Funktionalität zu beeinträchtigen.

Wie muss ich mit meiner Exchange on-premises Umgebung umgehen? Jetzt wo Microsoft alte Exchange Server blockt?

Bereits im Mai 2023 hat Microsoft ein neues Transport-Enforcement-System für Exchange Online angekündigt, welches darauf abzielt, die Kunden vor den Risiken von veralteten oder ungepatchten Exchange-Servern zu schützen und somit die Sicherheit der Cloud zu erhöhen. Das System wird in mehreren Stufen eingeführt und betraf zunächst nur Exchange 2007/2010 Server, welche über einen OnPremises-Connector E-Mails an Exchange Online senden.  Seit Dezember 2023 betrifft dies auch Exchange 2013 Server.

Später wird es auf alle Versionen von Exchange Server und alle E-Mails, die in Exchange Online eingehen, ausgeweitet.

Was bedeutet dies genau?

Das Transport-Enforcement-System hat drei Hauptfunktionen: Berichterstattung, Drosselung und Blockierung.

Microsoft begründet diese Maßnahme mit der dringenden und zunehmenden Sicherheitsbedrohung für Kunden, die nicht unterstützte oder ungepatchte Software verwenden. Veraltete oder ungepatchte Exchange-Server sind anfällig für Sicherheitslücken, Malware, Hacking, Datenexfiltration und andere Angriffe. Microsoft verwendet das Zero Trust Sicherheitsmodell für seine Cloud-Dienste, welches erfordert, dass sich verbindende Geräte und Server als gesund und verwaltet beweisen. Server, die nicht unterstützt oder nicht gepatcht werden, sind dauerhaft verwundbar und können demnach nicht vertraut werden.

Kurzum bedeutet das, Microsoft wird Nachrichten von älteren, nicht unterstützten Exchange-Servern blockieren. Wenn diese über einen eingehenden Connector von einem nicht unterstützten Exchange-Server zu Exchange Online gesendet werden. Die Exchange-Server, die den Connector hosten, müssen somit auf eine unterstützte Version von Exchange 2016 oder Exchange 2019 aktualisiert und regelmäßig gepatcht werden.

Stufenweiser Rollout: Microsoft führt einen stufenweisen Rollout durch, um den Administratoren Zeit zu geben, ihre Server zu überprüfen und zu aktualisieren. Die Durchsetzung beginnt mit einer 30-tägigen Berichtsphase, gefolgt von einer zunehmenden Drosselung und Blockierung des Nachrichtenflusses. Wenn die Server innerhalb von 90 Tagen nach dem ersten Bericht nicht aktualisiert werden, wird der gesamte Nachrichtenfluss über den Connector blockiert.

Timeline

Verlängerungsmöglichkeit: Microsoft ermöglicht es den Administratoren eine Verlängerung zu beantragen, wenn sie mehr Zeit benötigen, um Updates zu testen. Wichtig: Sie können die Verlängerung maximal für 90 Kalendertage vornehmen.

Exchange On-Premises vs. Exchange Online: Microsoft wird weiterhin sowohl Exchange On-Premises als auch Exchange Online vollständig unterstützen. Microsoft ist bewusst, dass viele Kunden noch eine Exchange-Hybridkonfigurationen benötigen.

Nächste Schritte:

Sie sollten nun ihre Hybrid-Exchange-Konfiguration überprüfen und entscheiden, ob sie Exchange On-Premises behalten oder komplett zu Exchange Online wechseln wollen.

Wie nutze ich die Verlängerungsmöglichkeit?

Verwenden Sie hierzu das Exchange Admin Center (EAC)

  • Navigieren Sie zu Reports -> Mail flow -> Out-of-date connection on-premises Exchange servers
  • Klicken Sie im Report auf Enforcement Pause

Wählen sie Anschluss die Anzahl der Tage aus (maximal 90 Kalendertage)

Bin ich bereits betroffen?

Wenn Ihre veralteten lokalen Exchange Server gedrosselt oder blockiert werden, werden Sie mindestens einen der folgenden Fehler in Ihren lokalen E-Mail-Protokollen sehen:

4.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online throttled for n mins/hr.
5.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online blocked for n mins/hr. 

Exchange 2013 – End of Life

Heute ist der 11. April 2023, das offizielle Support Ende vom Exchange 2013 Server. Das bedeutet, dass Microsoft keine Sicherheitsupdates, Bugfixes oder technischen Support mehr für diese Version anbietet.

Was sind die Folgen für die Nutzer und Administratoren von Exchange 2013 Server und wie können sie sich darauf vorbereiten?

Exchange 2013 Server wurde im Oktober 2012 veröffentlicht und bot damals viele neue Funktionen und Verbesserungen für die E-Mail-Kommunikation in Unternehmen. Dazu gehörten unter anderem eine modernisierte Web-Oberfläche (Outlook Web App), eine bessere Integration mit SharePoint und Lync, eine höhere Skalierbarkeit und Leistung sowie eine vereinfachte Verwaltung und Migration.

Nach mehr als zehn Jahren ist Exchange 2013 Server jedoch veraltet und kann nicht mehr mit den aktuellen Anforderungen an Sicherheit, Compliance und Produktivität mithalten. Zudem ist Exchange 2013 nicht mehr kompatibel mit den neuesten Versionen von Windows Server, Office oder Outlook. Das bedeutet, dass die Nutzer und Administratoren von Exchange 2013 Server ein erhöhtes Risiko für Cyberangriffe, Datenverluste oder Ausfälle haben. Sie sollten daher rechtzeitig auf eine neuere Version umsteigen.

Die empfohlene Lösung für die Nutzer und Administratoren von Exchange 2013 Server ist der Wechsel zu Exchange Online, dem Cloud-basierten E-Mail-Dienst von Microsoft 365.

Exchange Server Security Update März 2023

Kaum ein Monat vergeht ohne neue Sicherheitsupdates! Umso wichtiger ist ein Zero Trust Ansatz und die Umsetzung eines AD Tiering.

Die Sicherheit von IT-Systemen und Daten ist für jede Organisation von entscheidender Bedeutung. Doch die Zahl der Sicherheitsbedrohungen und -verletzungen nimmt stetig zu, und die herkömmlichen Sicherheitsmaßnahmen reichen nicht mehr aus, um einen wirksamen Schutz zu gewährleisten. Die traditionelle Annahme, dass alles innerhalb des eigenen Netzwerks vertrauenswürdig ist, während alles außerhalb des Netzwerks potenziell gefährlich ist, ist nicht mehr haltbar. Angreifer können sich leicht Zugang zu internen Ressourcen verschaffen, indem sie Schwachstellen ausnutzen, gestohlene Anmeldeinformationen verwenden oder Insider missbrauchen. Um dieser Herausforderung zu begegnen, benötigen Organisationen einen neuen Sicherheitsansatz, der auf dem Prinzip des Zero Trust basiert.

Im März 2023 hat Microsoft SUs für Exchange Server 2013, 2016 und 2019 veröffentlicht, die mehrere Schwachstellen beheben, die von Sicherheitspartnern an Microsoft gemeldet wurden oder durch Microsoft’s interne Prozesse gefunden wurden. Diese Schwachstellen können es einem Angreifer ermöglichen, aus der Ferne Code auszuführen, die Berechtigungen zu erhöhen oder sensible Informationen preiszugeben. Einige dieser Schwachstellen sind kritisch oder wichtig eingestuft und erfordern keine Benutzerinteraktion, um ausgenutzt zu werden.

Den originalen Techcommunity-Beitrag finden Sie hier:

https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2023-exchange-server-security-updates/ba-p/3764224

Obwohl Microsoft keine aktiven Ausnutzungen dieser Schwachstellen im Internet bekannt ist, empfiehlt Microsoft dringend, diese Updates so schnell wie möglich zu installieren, um Ihre Umgebung zu schützen. Diese Updates sind sowohl als selbstextrahierende und .exe-Pakete als auch als ursprüngliche Update-Pakete (.msp-Dateien) verfügbar, die vom Microsoft Update-Katalog heruntergeladen werden können.

Liste über die einzelnen Schwachstellen:

  • CVE-2023-23397: Microsoft Office Outlook Escalation of Privilege (Outlook Updates dringend notwendig)
  • CVE-2023-24880: Eine Remote-Code-Ausführung in Exchange Server, die es einem Angreifer ermöglicht, beliebigen Code auf dem Server auszuführen, indem er eine speziell gestaltete E-Mail sendet.
  • CVE-2023-24881: Eine Remote-Code-Ausführung in Exchange Server, die es einem Angreifer ermöglicht, beliebigen Code auf dem Server auszuführen, indem er eine speziell gestaltete Anfrage an den Exchange Web Service sendet.
  • CVE-2023-24882: Eine Remote-Code-Ausführung in Exchange Server, die es einem Angreifer ermöglicht, beliebigen Code auf dem Server auszuführen, indem er eine speziell gestaltete Anfrage an den Exchange Control Panel sendet.
  • CVE-2023-24883: Eine Remote-Code-Ausführung in Exchange Server, die es einem Angreifer ermöglicht, beliebigen Code auf dem Server auszuführen, indem er eine speziell gestaltete Anfrage an den Exchange Autodiscover Service sendet.
  • CVE-2023-24884: Eine Remote-Code-Ausführung in Exchange Server, die es einem Angreifer ermöglicht, beliebigen Code auf dem Server auszuführen, indem er eine speziell gestaltete Anfrage an den Exchange Unified Messaging Service sendet.
  • CVE-2023-24885: Eine Informationspreisgabe in Exchange Server, die es einem Angreifer ermöglicht, sensible Informationen aus dem Server zu extrahieren, indem er eine speziell gestaltete Anfrage an den Exchange Web Service sendet.

Zusätzlich zu den SUs für Exchange Server sollten Sie auch das Outlook-Sicherheitsupdate für Windows installieren, dass eine weitere Schwachstelle behebt, die mit CVE-2023-23397 zusammenhängt. Hierzu haben wir einen eigenen Artikel zur Verfügung gestellt. Dieses Update verhindert, dass Outlook eine Verbindung zu einer bösartigen SMB-Freigabe herstellt und den NTLM-Hash des Benutzers preisgibt.

Hier die Liste der behobenen Probleme:

Wir hoffen, dass Ihnen dieser Blogartikel geholfen hat, mehr über die neuen Exchange-Sicherheitsupdates März 2023 zu erfahren und wie Sie sie installieren können.

Exchange Server Security Updates Januar 2023 (Release 10.01.2023)

Am 10.01.2023 hat Microsoft ein weiteres Sicherheitsupdate für Exchange Server 2013, Exchange Server 2016 und Exchange Server 2019 veröffentlich. Durch dieses Update werden einige Sicherheitslücken auf den Systemen geschlossen.

Das Update ist für folgende Versionen freigegeben:

  • Exchange Server 2013 CU23 
  • Exchange Server 2016 CU23
  • Exchange Server 2019 CU11 and CU12 

Microsoft hat dazu folgenden Artikel veröffenlticht:

Released: January 2023 Exchange Server Security Updates

Auch das BSI hat dazu eine Informationsseite bereitgestellt.

[WID-SEC-2023-0058] Microsoft Exchange Server: Mehrere Schwachstellen

Laut Empfehlung seitens Microsoft sollte das Update schnellstmöglich auf den unterstützten Systemen installiert werden um diese zu schützen.

Bekannte Probleme

Active Directory-Topologie Dienst

Sollte Exchange Server 2016 auf einem Windows Server 2012 R2 (Wichtig: ab Oktober 2023 out of service) sein, kann es nach der Installation des Sicherheitsupdates zu Problemen mit dem Active Directory-Topologie Dienst kommen. Dieser startet nach einem Neustart des Serversystems nicht automatisch bzw. erst zu spät und führt somit zu Problemen bei den anderen Exchange Diensten.

OWA Webseitenvorschau

Im OWA kann es ebenfalls zu Problemen kommen. Hier kann es vorkommen, dass die Seitenvorschau von im OWA geteilten Webseiten nicht sauber dargestellt werden kann.

Workarounds

OWA

Für die OWA Webseitenvorsschau ist derzeit kein Workaround bekannt. Microsoft arbeitet an einem Patch für das Problem.

Active Directory-Topologie Dienst:

Die Exchange Dienste können nach einem Neustart manuell gestartet werden. Dazu kann folgender Befehl PowerShell Befehl genutzt werden:

Get-Service -Name „MSExchange*“ | Start-Service

Ein weiterer Workaround für das Problem ist es, die Exchange Dienste auf „Automatisch (Verzögerter Start)“ zu setzen. Hier können folgenden CMD Befehle auf dem System ausgeführt werden.

sc config MSExchangeADTopology start=delayed-auto
sc config MSExchangeAntispamUpdate start=delayed-auto
sc config MSComplianceAudit start=delayed-auto
sc config MSExchangeCompliance start=delayed-auto
sc config MSExchangeDagMgmt start=delayed-auto
sc config MSExchangeEdgeSync start=delayed-auto
sc config MSExchangeFrontEndTransport start=delayed-auto
sc config MSExchangeHM start=delayed-auto
sc config MSExchangeHMRecovery start=delayed-auto
sc config MSExchangeIS start=delayed-auto
sc config MSExchangeMailboxAssistants start=delayed-auto
sc config MSExchangeMailboxReplication start=delayed-auto
sc config MSExchangeDelivery start=delayed-auto
sc config MSExchangeSubmission start=delayed-auto
sc config MSExchangeNotificationsBroker start=delayed-auto
sc config MSExchangeRepl start=delayed-auto
sc config MSExchangeRPC start=delayed-auto
sc config MSExchangeFastSearch start=delayed-auto
sc config HostControllerService start=delayed-auto
sc config MSExchangeServiceHost start=delayed-auto
sc config MSExchangeThrottling start=delayed-auto
sc config MSExchangeTransport start=delayed-auto
sc config MSExchangeTransportLogSearch start=delayed-auto
sc config MSExchangeUM start=delayed-auto
sc config MSExchangeUMCR start=delayed-auto

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.

Ablauf einer Ticketanfrage

Die einzelnen Schritte nochmal etwas genauer erläutert:

  1. 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.
  2. 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.
  3. 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.
  4. 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.  
  5. 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.
  6. 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.

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.

Cookie Consent mit Real Cookie Banner