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.

Microsoft 365 Dienstprobleme (MO502273) – Stand 25.01.2023

[Update 11:35 Uhr] – Auch Intune und Defender for Cloud Apps scheinen betroffen zu sein. Es scheint, dass eine Änderung des WAN Routings seitens Microsoft zu den Problemen führt.

[Update 10:50 Uhr] – Microsoft meldet, dass der Fehler möglicherweise auf getätigte Änderungen der Netzwerkinfrastruktur zurückzuführen ist. Derzeit wird daher ein Rollback der Netzwerkeinstellungen durchgeführt.

Microsoft meldet derzeit Probleme mit ihren M365 Diensten. Der Incident mit der Bearbeitungsnummer MO502273 führt zu Problemen beim Zugriff auf diverse M365 Produkte.

Auch der Zugriff auf die Administrationsportale scheint problematisch zu sein. Laut Microsoft sind folgende Dienste betroffen:

Microsoft Teams
Exchange Online
Outlook
SharePoint Online
OneDrive for Business
Microsoft Graph
PowerBi
M365 Admin Portal
Microsoft Intune
Microsoft Defender for Cloud Apps, Identity and Endpoint.

Microsoft arbeitet derzeit an der Lösung des Problems.

Wir informieren euch über den aktuellen Stand auch auf unserem Twitter Account: https://twitter.com/consulting_blog oder auf der Statusseite von Microsoft: https://status.office365.com/

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