Schlagwort: Security

Storm-2949: Warum Microsoft-Cloud-Umgebungen heute aktiv betrieben und geschützt werden müssen

Die Angriffsfläche moderner Unternehmen hat sich in den letzten Jahren grundlegend verändert. Während früher primär lokale Server und Netzwerke im Fokus standen, richten professionelle Angreifer ihre Aktivitäten heute gezielt auf Microsoft 365, Azure und Microsoft Entra ID.

Die aktuelle Analyse der Hackergruppe Storm-2949 durch Microsoft zeigt eindrucksvoll, wie moderne Cloud-Angriffe funktionieren — und warum klassische Sicherheitsmaßnahmen alleine längst nicht mehr ausreichen.

Die Angreifer nutzen dabei keine spektakulären Zero-Day-Exploits, sondern kombinieren:

  • kompromittierte Identitäten,
  • Social Engineering,
  • Fehlkonfigurationen,
  • schwache Governance,
  • und mangelnde Überwachung von Cloud-Umgebungen.

Das macht diese Angriffe besonders gefährlich: Viele Aktivitäten wirken zunächst wie legitime Administratoraktionen und bleiben dadurch lange unentdeckt.

Die Angriffskette von Storm-2949

Microsoft beschreibt einen mehrstufigen Angriff auf Microsoft-Cloud-Umgebungen, bei dem sich die Angreifer schrittweise durch Identitäten, Azure-Dienste und Ressourcen bewegen.

Quelle:
Microsoft Security Blog – Storm-2949 Analyse

Wie die Angreifer vorgehen

Die Kampagne beginnt häufig mit Social Engineering oder kompromittierten Benutzerkonten.

Typische Einstiegspunkte:

  • Self-Service Password Reset (SSPR)
  • MFA-Manipulation
  • Phishing
  • Passwort-Spraying
  • Device-Code-Phishing
  • kompromittierte Legacy-Authentifizierung

Nach dem initialen Zugriff bewegen sich die Angreifer systematisch durch die Cloud-Umgebung:

1. Kompromittierung von Entra-ID-Konten

Sobald Benutzerkonten übernommen wurden, versuchen die Angreifer:

  • weitere MFA-Methoden hinzuzufügen,
  • Persistenz aufzubauen,
  • privilegierte Rollen zu identifizieren,
  • und Sicherheitsmechanismen zu umgehen.

2. Ausnutzung von Azure- und Microsoft-365-Diensten

Die Gruppe nutzt anschließend legitime Microsoft-Dienste für laterale Bewegungen:

  • SharePoint
  • Azure Virtual Machines
  • Azure Key Vault
  • Azure Storage Accounts
  • Azure SQL
  • Web Apps

Besonders kritisch:
Die Aktivitäten sehen oft wie normale Administratoraktionen aus.

3. Zugriff auf sensible Daten

Ziel der Kampagne ist häufig:

  • Datendiebstahl,
  • Persistenz,
  • oder die Vorbereitung weiterer Angriffe.

Betroffen sind typischerweise:

  • Kundendaten,
  • interne Dokumente,
  • Datenbanken,
  • Zugangsschlüssel,
  • Servicekonten,
  • API-Secrets,
  • Entwicklungsumgebungen.

Warum klassische Security heute nicht mehr ausreicht

Viele Unternehmen verlassen sich noch immer auf:

  • Antivirus,
  • klassische Firewalls,
  • einzelne MFA-Lösungen,
  • oder einmalige Security-Projekte.

Moderne Cloud-Angriffe umgehen diese Schutzmechanismen jedoch zunehmend über:

  • kompromittierte Identitäten,
  • legitime Cloud-Funktionen,
  • OAuth-Token,
  • Fehlkonfigurationen,
  • und überprivilegierte Konten.

Ich betone es immer wieder, die Realität ist:
Die Identität ist heute der eigentliche Sicherheitsperimeter.

Was Unternehmen jetzt tun sollten

Technische Schutzmaßnahmen

Phishing-resistente MFA einsetzen

Empfohlen werden:

  • FIDO2-Sicherheitsschlüssel
  • Passkeys
  • Conditional Access Policies

Conditional Access konsequent nutzen

Zugriffe sollten abhängig gemacht werden von:

  • Standort,
  • Gerätetyp,
  • Risiko-Level,
  • Benutzerrolle,
  • Compliance-Status.

Legacy Authentication deaktivieren

Alte Authentifizierungsprotokolle sind weiterhin ein häufiger Angriffsvektor.

Rollen und Berechtigungen minimieren

Wichtige Prinzipien:

  • Least Privilege
  • Just-in-Time-Administration
  • Trennung privilegierter Konten
  • regelmäßige Rechte-Reviews

Besonders kritisch:

  • Global Administrator
  • Key Vault Zugriff
  • Service Principals
  • Managed Identities

Cloud-Monitoring etablieren

Unternehmen benötigen heute:

  • zentrales Logging,
  • SIEM-Anbindung,
  • Security Monitoring,
  • Anomalie-Erkennung,
  • Incident Response Prozesse.

Warum Security alleine nicht genügt

Ein zentrales Problem vieler Unternehmen:
Cloud-Sicherheit wird noch immer als Einzelprojekt betrachtet.

Doch moderne Microsoft-Cloud-Umgebungen verändern sich permanent:

  • neue Dienste,
  • neue Funktionen,
  • neue Sicherheitsanforderungen,
  • neue Angriffsmethoden.

Deshalb reicht es nicht aus, einmalig Sicherheitsmaßnahmen einzuführen.

Microsoft 365 und Azure benötigen einen kontinuierlich betreuten und professionell betriebenen Tenant.

Tenant as a Service: Sicherheit als Betriebsmodell

Ein moderner „Tenant as a Service“-Ansatz verbindet:

  • Betrieb,
  • Security,
  • Governance,
  • Monitoring,
  • und kontinuierliche Optimierung.

Dabei geht es nicht nur um Support, sondern um den aktiven sicheren Betrieb der gesamten Microsoft-Cloud-Umgebung.

Was ein Tenant-as-a-Service-Modell ermöglicht

Kontinuierliche Härtung der Umgebung

Ein professionell betriebener Tenant wird laufend:

  • überprüft,
  • optimiert,
  • gehärtet,
  • und an neue Bedrohungen angepasst.

Permanente Überwachung

Dazu gehören:

  • Monitoring von Entra ID,
  • Analyse verdächtiger Logins,
  • Überwachung privilegierter Konten,
  • Erkennung ungewöhnlicher Datenbewegungen,
  • Auswertung von Security Alerts.

Schnellere Reaktion auf Angriffe

Im Ernstfall zählt Geschwindigkeit.

Ein betreuter Tenant ermöglicht:

  • schnelle Incident Response,
  • Eindämmung kompromittierter Konten,
  • forensische Analyse,
  • Wiederherstellung betroffener Dienste.

Entlastung der internen IT

Viele interne IT-Teams sind bereits stark ausgelastet durch:

  • Tagesbetrieb,
  • Projekte,
  • Support,
  • Migrationen,
  • Compliance-Anforderungen.

Tenant as a Service schafft:

  • klare Betriebsprozesse,
  • standardisierte Security-Governance,
  • dokumentierte Richtlinien,
  • und nachhaltige Betriebsunterstützung.

Der Faktor Mensch bleibt entscheidend

Die meisten Angriffe beginnen weiterhin mit:

  • Social Engineering,
  • Phishing,
  • oder manipulierten Benutzern.

Technische Schutzmaßnahmen alleine reichen daher nicht aus.

Wichtige organisatorische Maßnahmen:

  • Security Awareness Trainings
  • Phishing-Simulationen
  • klare Notfallprozesse
  • Rollen- und Berechtigungskonzepte
  • definierte Security-Verantwortlichkeiten

Fazit

Die Storm-2949-Kampagne zeigt deutlich:

Moderne Angriffe auf Microsoft 365, Azure und Entra ID sind hochprofessionell, identitätsbasiert und oft nur schwer erkennbar.

Die größte Gefahr entsteht dabei häufig nicht durch einzelne Sicherheitslücken, sondern durch:

  • fehlende Governance,
  • unzureichendes Monitoring,
  • überlastete IT-Teams,
  • und mangelnden kontinuierlichen Betrieb der Cloud-Umgebung.

Unternehmen benötigen deshalb heute mehr als klassische Security-Produkte.

Sie brauchen:

  • kontinuierliche Sicherheitsüberwachung,
  • professionellen Cloud-Betrieb,
  • klare Governance,
  • schnelle Reaktionsfähigkeit,
  • und einen dauerhaft gehärteten Microsoft-Tenant.

Genau hier setzt ein moderner Tenant-as-a-Service-Ansatz an:
Security wird nicht mehr als Einzelmaßnahme verstanden, sondern als kontinuierlicher Bestandteil des gesamten IT-Betriebs.

Exchange Server Security 2025 – Gemeinsame Empfehlungen von NSA, CISA, ACSC und dem kanadischen Cyber Centre

Microsoft Exchange bleibt für viele Organisationen die zentrale Kommunikationsplattform – und ein Dauerziel für Cyberangriffe. Zahlreiche Schwachstellen und Zero-Day-Exploits der letzten Jahre haben gezeigt, wie wichtig eine systematische Härtung von Exchange-Umgebungen ist.

Im Oktober 2025 haben vier führende Sicherheitsbehörden – die National Security Agency (NSA), die Cybersecurity and Infrastructure Security Agency (CISA), das Australian Cyber Security Centre (ACSC) sowie das Canadian Centre for Cyber Security – ihre gemeinsamen Microsoft Exchange Server Security Best Practices veröffentlicht.
Ziel ist es, Administratoren klare Handlungsempfehlungen zu geben, um On-Premises-Exchange-Server nachhaltig abzusichern.

Microsoft Exchange bleibt für viele Organisationen die zentrale Kommunikationsplattform – und ein Dauerziel für Cyberangriffe. Zahlreiche Schwachstellen und Zero-Day-Exploits der letzten Jahre haben gezeigt, wie wichtig eine systematische Härtung von Exchange-Umgebungen ist.

Im Oktober 2025 haben vier führende Sicherheitsbehörden – die National Security Agency (NSA), die Cybersecurity and Infrastructure Security Agency (CISA), das Australian Cyber Security Centre (ACSC) sowie das Canadian Centre for Cyber Security – ihre gemeinsamen Microsoft Exchange Server Security Best Practices veröffentlicht.
Ziel ist es, Administratoren klare Handlungsempfehlungen zu geben, um On-Premises-Exchange-Server nachhaltig abzusichern.

1. Präventionsstrategie als Grundprinzip

Die Leitlinie aller Empfehlungen ist eine konsequente „Prevention-first“-Strategie. Das bedeutet, Angriffe gar nicht erst zu ermöglichen, statt nur auf Vorfälle zu reagieren.
Zentrale Prinzipien dabei sind:

  • Deny-by-default: Nur das erlauben, was unbedingt nötig ist.
  • Least privilege: Benutzer- und Adminrechte auf das Minimum beschränken.
  • Timely updates: Sicherheitsupdates ohne Verzögerung installieren.
  • Attack surface minimization: Nicht benötigte Dienste und Ports deaktivieren oder isolieren.

Diese Maßnahmen senken das Risiko eines erfolgreichen Angriffs erheblich und bilden die Grundlage für jede weitere Absicherung.

2. Sicherheitsupdates und Patchmanagement priorisieren

Die wichtigste Verteidigung gegen Exploits bleibt konsequentes Patchmanagement.
Microsoft veröffentlicht:

  • Zwei Cumulative Updates (CUs) pro Jahr
  • Monatliche Sicherheitsupdates und Hotfixes

Angreifer entwickeln oft innerhalb weniger Tage nach Veröffentlichung eines Patches neue Exploits. Administratoren sollten deshalb:

  • Den Exchange Health Checker regelmäßig ausführen
  • Die Exchange Team Blog Updates abonnieren
  • Updates automatisiert und zeitnah einspielen

Nur Systeme mit aktuellem Patchstand sind wirklich geschützt.

3. End-of-Life-Versionen abschalten

Seit Oktober 2025 ist ausschließlich die Exchange Server Subscription Edition (SE) offiziell unterstützt.
Ältere Versionen wie Exchange 2016 oder Exchange 2019 sind „End of Life“ und stellen ein erhebliches Risiko dar, da sie keine Sicherheitsupdates mehr erhalten.

Empfohlene Maßnahmen:

  • Migration auf Exchange SE oder eine alternative, unterstützte E-Mail-Plattform
  • Alte Server vom Internet trennen und nur intern verwenden
  • Optional: Mail-Gateway als Schutzschicht für eingehenden und ausgehenden Datenverkehr einsetzen

Für Unternehmen gilt: Je schneller die Migration, desto geringer das Risiko.

4. Emergency Mitigation Service aktiv lassen

Der Exchange Emergency Mitigation (EM) Service ist ein automatischer Schutzmechanismus von Microsoft. Er erkennt und blockiert bekannte Angriffsmuster, bevor ein offizielles Update verfügbar ist.

Beispiele für Schutzmaßnahmen sind das Sperren gefährlicher HTTP-Anfragen oder das automatische Deaktivieren kompromittierter Dienste.

Wichtig:
Der EM-Service ersetzt keine regulären Sicherheitsupdates, bietet aber einen wertvollen temporären Schutz und sollte stets aktiviert bleiben.

5. Sicherheitsbaselines konsequent anwenden

Sicherheitsbaselines schaffen Einheitlichkeit in der Konfiguration und erleichtern das Erkennen von Schwachstellen.
Empfohlene Quellen für Baselines:

  • DISA STIG (Security Technical Implementation Guide)
  • CIS Benchmarks
  • Microsoft Security Baselines

Diese Standards sollten sowohl für Exchange Server, Windows Server als auch für Office-/Outlook-Clients umgesetzt werden.
Einheitliche Baselines ermöglichen schnelle Audits und reduzieren die Angriffsfläche.

6. Eingebaute Schutzfunktionen nutzen

Wenn keine Drittanbieter-Tools verwendet werden, sollten alle integrierten Microsoft-Sicherheitsfunktionen aktiviert sein:

  • Microsoft Defender Antivirus (MDAV)
  • Antimalware Scan Interface (AMSI)
  • Attack Surface Reduction (ASR)
  • AppLocker / App Control for Business
  • Endpoint Detection and Response (EDR)
  • Exchange Anti-Spam und Anti-Malware

Ergänzend sollten Organisationen DMARC, SPF und DKIM konfigurieren – entweder manuell über DNS oder mithilfe externer Gateways, da Exchange On-Prem diese Standards nicht nativ unterstützt.

7. Administrative Zugriffe beschränken

Administrationsschnittstellen wie Exchange Admin Center (EAC) und PowerShell sind beliebte Einfallstore.
Empfehlungen:

  • Zugriff nur über dedizierte Administrator-Workstations
  • EAC-Zugriff extern über Client Access Rules sperren
  • Zugriff über Firewall-Regeln auf autorisierte IPs begrenzen

So bleibt der Verwaltungszugang geschützt, auch wenn der Rest des Systems kompromittiert wird.

8. Authentifizierung und Verschlüsselung härten

Transport Layer Security (TLS)

Nutzen Sie immer aktuelle TLS-Versionen für interne und externe Kommunikation.
Konsistente TLS-Konfigurationen verhindern Downgrades und stellen sicher, dass Verbindungen verschlüsselt bleiben.

Extended Protection (EP)

EP schützt vor Relay- und Man-in-the-Middle-Angriffen.
Die Funktion ist ab Exchange 2019 CU14 standardmäßig verfügbar und setzt korrekt konfigurierte TLS- und Kerberos-Einstellungen voraus.

Kerberos statt NTLM

NTLM ist veraltet und wird künftig entfernt.
Empfohlen wird der vollständige Umstieg auf Kerberos, das in Exchange SE (CU1) bereits als Standard gilt.

Modern Authentication und MFA

Ab Exchange 2019 CU13 steht Modern Authentication (OAuth 2.0) mit Unterstützung für Multi-Faktor-Authentifizierung (MFA) über ADFS oder Entra ID zur Verfügung.
Nach der Aktivierung sollte Basic Authentication vollständig deaktiviert werden.

PowerShell absichern

Seit dem Sicherheitsupdate vom November 2023 ist die Zertifikat-basierte Signierung von PowerShell-Serialisierungen standardmäßig aktiv.
Diese Funktion schützt vor Manipulationen und sollte auf allen Exchange-Servern aktiviert bleiben.

9. Weitere empfohlene Schutzmaßnahmen

  • HTTP Strict Transport Security (HSTS): Erzwingt HTTPS-Verbindungen und verhindert Man-in-the-Middle-Angriffe.
  • Download Domains: Trennt Outlook-Web-Sitzungen von Dateidownloads und schützt vor CSRF-Angriffen.
  • RBAC und Split Permissions: Trennen Sie Exchange-Administrationsrechte von Active-Directory-Privilegien, um eine Kompromittierung von Domain- oder Enterprise-Admin-Konten zu verhindern.
  • Tiering: Ordnen Sie Exchange-Server konsequent dem Tier-1-Segment zu. Damit bleibt der Server in einer kontrollierten Verwaltungsschicht und ist getrennt von Tier-0-Komponenten wie Domänencontrollern oder Schema-Administratoren.
    In Kombination mit Split Permissions wird so verhindert, dass Exchange-Administratoren unbeabsichtigt oder böswillig erweiterte Active-Directory-Rechte erlangen.
  • P2 FROM Header Detection: Erkennt und blockiert E-Mail-Spoofing-Angriffe automatisch.

Ein klar definiertes Admin-Tiering-Modell ist entscheidend, um die laterale Bewegung von Angreifern in der Infrastruktur zu verhindern.
Tier-1-Systeme (wie Exchange oder Fileserver) sollten immer durch dedizierte Admin-Konten und separate Workstations verwaltet werden, die keinen Zugriff auf Tier-0-Systeme besitzen.

10. Fazit: Zero Trust als dauerhafte Sicherheitsstrategie

Die beteiligten Behörden betonen: Zero Trust ist keine Option, sondern Pflicht.
Das bedeutet, jedes System – auch interne Server – wird als potenziell kompromittierbar betrachtet.

Durch konsequentes Patchmanagement, Minimierung von Berechtigungen, klare Tiering-Trennung und verschlüsselte Kommunikation lässt sich das Risiko deutlich senken.
Ein sicher konfigurierter Exchange-Server schützt nicht nur E-Mails, sondern die gesamte Kommunikationsinfrastruktur eines Unternehmens.

Die zehn wichtigsten Sofortmaßnahmen

  1. Immer auf neueste Cumulative und Security Updates upgraden
  2. Exchange 2016/2019 außer Betrieb nehmen
  3. Emergency Mitigation Service aktiv halten
  4. Security Baselines anwenden
  5. Defender, AMSI, ASR und EDR aktivieren
  6. TLS und Extended Protection korrekt konfigurieren
  7. Kerberos statt NTLM verwenden
  8. Modern Authentication und MFA erzwingen
  9. RBAC, Tiering und Split Permissions nutzen
  10. Zero Trust als Sicherheitsgrundlage umsetzen

Quelle:
Gemeinsames Dokument von NSA, CISA, Australian Cyber Security Centre (ACSC) und Canadian Centre for Cyber Security:
„Microsoft Exchange Server Security Best Practices“, Oktober 2025

https://www.nsa.gov/Portals/75/documents/resources/cybersecurity-professionals/CSI_Microsoft_Exchange_Server_Security_Best_Practices.pdf

Versteckte bösartige OAuth-Apps in Microsoft 365 entdecken – mit dem Tool Cazadora

Die Nutzung von Cloud- und Identitätsdiensten wie Microsoft 365 nimmt ständig zu – damit steigt auch das Risiko neuer Angriffswege. Ein besonders heimtückischer Ansatz: Angreifer nutzen OAuth-Apps, die in Azure/Entra ID registriert wurden, um Zugriffe auf Daten zu erlangen – oft ohne dass es die Administratoren oder Nutzer merken. In einem aktuellen Blogbeitrag erklärt Huntress Labs, wie solche Apps funktionieren, wie häufig sie auftreten – und stellt mit Cazadora ein Open-Source-Skript vor, mit dem sich verdächtige Anwendungen aufspüren lassen. BleepingComputer
Als IT-Consultant lohnt es sich, dieses Thema im Blick zu behalten, denn selbst gut verwaltete Microsoft-365-Tenants sind nicht immun.

Was sind OAuth Apps in Azure/Entra ID – und warum sind sie relevant?

In der Welt von Azure AD / Entra ID und Microsoft 365 gibt es zwei zentrale Kategorien von Apps:

  • Application Registrations: Anwendungen, die innerhalb des eigenen Tenants entwickelt oder registriert wurden. BleepingComputer+1
  • Enterprise Applications: Instanzen von Anwendungen, die von anderen Tenants registriert wurden, aber in Ihrer Tenant-Umgebung verwendet werden. BleepingComputer

Der typische Ablauf sieht so aus: Ein Benutzer oder Administrator erlaubt einer App, sich mit ihrem Konto (Authentifizierung) zu verbinden und über OAuth entsprechende Rechte (Autorisierung) zu erteilen. Sobald das geschehen ist, wird in Ihrem Tenant ein Service-Principal für diese App angelegt, über den die App im Namen der Nutzer agieren kann. BleepingComputer

Warum ergeben sich daraus Risiken?

  • Die Funktionalität ist legitim und zentraler Bestandteil moderner Cloudanwendungen – das macht sie attraktiv für Angreifer, da sie wenig auffällig ist. BleepingComputer+1
  • Manche Einstellungen erlauben es, dass jeder Nutzer ohne Überprüfung Apps registrieren bzw. ihnen Rechte geben kann – je nach Tenant-Konfiguration. BleepingComputer
  • Eine bösartige oder kompromittierte App kann somit Zugriff auf sensible Daten erlangen, ohne dass klassische Malware- oder Endpoint-Kontrollen sie zwingend aufdecken.

Angriffstypen: „Traitorware“ und „Stealthware“

Huntress unterscheidet zwei relevante Kategorien von missbräuchlichen OAuth-Apps:

Traitorware

Hierbei handelt es sich um eigentlich legitime Apps oder weit verbreitete Tools, die allerdings von Angreifern für bösartige Zwecke genutzt werden. Die App selbst ist nicht zwangsläufig bösartig designt, aber ihre Nutzung erscheint ungewöhnlich und riskant.

  • Huntress fand z. B., dass ca. 10 % der ausgewerteten Tenants mindestens eine solche App installiert hatten. BleepingComputer
  • Merkmale: bekannte App-Namen, aber oft ungewöhnliche Berechtigungen oder eine ungewöhnliche Nutzerzuordnung.

Stealthware

Diese Kategorie umfasst echt bösartige oder speziell für Angriffe erstellte OAuth-Apps – klein, maßgeschneidert, selten und damit schwer zu entdecken.

  • Sie haben oft sehr geringe Verbreitung (z. B. < 1 % aller Tenants) und hohe Delegated-Berechtigungen auf einzelne Nutzer. BleepingComputer
  • Da die Namen willkürlich oder unerkennbar sind („…………“, „Test App“, Domain-Name etc.), entziehen sie sich oft automatisierten Erkennungsmechanismen.

Warum sollte man auditieren?

Die Daten zeigen: Selbst bei Organisationen mit etabliertem Sicherheits­rahmen tauchen solche Apps auf – teilweise seit Jahren unentdeckt. BleepingComputer
Ein (zu) beruhigender Befund: Wenn eine App nicht automatisch gefunden wird, heißt das noch nicht, dass keine bösartige App vorhanden ist. Vigilanz bleibt erforderlich.

Vorstellung von Cazadora

Um Administratoren und Sicherheitsverantwortlichen zu helfen, hat Huntress das Werkzeug Cazadora veröffentlicht. BleepingComputer

Was macht Cazadora?

  • Es handelt sich um ein Open-Source-Skript, das über die Microsoft Graph API Daten über alle Application Registrations und Enterprise Applications im Tenant abruft. BleepingComputer
  • Es führt eine automatisierte Analyse durch und markiert Applikationen mit auffälligen Merkmalen (z. B. ungewöhnlicher Name, seltene Verbreitung, starke Berechtigungen, Loopback-Reply-URL etc.). BleepingComputer
  • Ziel ist nicht, alle bösen Apps sicher aufzuspüren, sondern einen schnellen Überblick zu geben und potenzielle „Rauchzeichen“ sichtbar zu machen.

Wichtige Hinweise

  • Kein Tool ersetzt eine vollständige manuelle Prüfung oder eine laufende Sicherheitsüberwachung – Cazadora ist ein Sprungbrett, keine Garantie. BleepingComputer
  • Ergebnisse sollten von einem Administrator oder Sicherheitsanalysten bewertet werden.
  • Anpassungen im Tenant (z. B. Benutzerrechte bei App-Registrierung) können helfen, den Angriffs­raum zu reduzieren.

Achtung: Neue Phishing-Welle nutzt Azure Blob Storage – so schützen Sie Ihr Microsoft 365 mit Passwordless Authentication

Cyberkriminelle sind heute kreativer denn je – und sie nutzen sogar Microsoft-Dienste selbst, um Nutzer zu täuschen.
Ein aktueller Fall zeigt, wie Angreifer über Azure Blob Storage glaubwürdige Microsoft-Login-Seiten fälschen, um Zugangsdaten zu stehlen.

Doch wer Passwordless Authentication einsetzt, schließt genau diese Lücke – und eliminiert Passwörter als Einfallstor.

Phishing über Azure Blob Storage – so funktioniert der Angriff

Die aktuelle Angriffswelle nutzt legitime Microsoft-Domains wie *.blob.core.windows.net.
Betroffene erhalten Links, die auf den ersten Blick harmlos wirken, z. B.:

forms.office.com/<zufälliger-wert>

Nach dem Klick wird man auf eine Seite weitergeleitet, die wie eine echte Microsoft-Login-Seite aussieht – aber in Wahrheit gefälscht ist.
Die Domain endet oft auf:

https://<zufälliger-name>.blob.core.windows.net/<datei>.pdf

Sobald man sich dort mit seinem Microsoft-365-Konto anmeldet, werden Passwort und Authentifizierungstoken abgefangen.
Damit erhalten Angreifer Zugriff auf den gesamten Microsoft-365-Mandanten des Unternehmens.

Besonders perfide:
Da die Domain windows.net zu Microsoft gehört, halten viele Benutzer sie für sicher.

Warum herkömmliche Schutzmaßnahmen nicht ausreichen

Auch wenn Unternehmen heute Firewalls, MFA, Webfilter und Awareness-Trainings einsetzen – Phishing bleibt ein Problem.
Denn Angreifer täuschen vertraute Umgebungen perfekt nach.

Selbst Multi-Faktor-Authentifizierung (MFA) hilft nur bedingt:
Bei Token-Phishing oder Session Hijacking kann sie umgangen werden.

Das Kernproblem bleibt: Passwörter sind phishbar.

Passwordless Authentication – Sicherheit durch den Wegfall des Passworts

Mit Passwordless Authentication löst Microsoft das Problem elegant:
Anstelle eines Passworts nutzt der Benutzer starke kryptografische Schlüssel, die an sein Gerät oder seinen Authenticator gebunden sind.

Beispiele für Passwordless-Login-Methoden

  • Windows Hello for Business – Anmeldung per PIN oder Gesichtserkennung
  • Microsoft Authenticator – Anmeldung durch Push-Bestätigung
  • FIDO2-Sicherheits-Keys – z. B. YubiKey oder Feitian-Key

Damit entfällt die Notwendigkeit, ein Passwort einzugeben – und somit das Risiko, dass es abgefangen wird.

So funktioniert Passwordless technisch

Passwordless basiert auf einem sicheren Public/Private-Key-Verfahren:

  1. Der Private Key bleibt sicher auf dem Gerät oder Token des Benutzers.
  2. Der Public Key wird bei Microsoft Entra ID (ehemals Azure AD) gespeichert.
  3. Beim Login signiert das Gerät eine Challenge – ohne dass ein Passwort übertragen wird.

👉 Selbst eine täuschend echte Phishing-Seite kann diese Anmeldung nicht nachahmen,
weil der Private Key das Gerät niemals verlässt.

Vorteile von Passwordless Authentication

VorteilBeschreibung
🛡️ Phishing-resistentKeine Passwörter = kein Angriffsziel
🚀 Schneller LoginKein Eintippen, kein „Passwort vergessen“
💼 Weniger SupportaufwandReduziert Helpdesk-Tickets
🔑 Stärkere SicherheitBasierend auf Kryptografie, nicht Wissen
🔗 Microsoft 365 integriertUnterstützt in Entra ID, Windows & Azure

Fazit: Phishing verhindern, bevor es passiert

Der Phishing-Angriff über Azure Blob Storage verdeutlicht, dass Angreifer heute legitime Dienste nutzen, um Vertrauen zu missbrauchen.

Mit Passwordless Authentication nehmen wir ihnen das wichtigste Werkzeug –
das Passwort – einfach weg.

💬 „You can’t phish what doesn’t exist.“
– Microsoft Security Engineering Team

Passwordless ist keine Zukunftstechnologie mehr,
sondern der nächste logische Schritt in der Sicherheitsstrategie moderner Microsoft-Umgebungen.

Cloud-Managed Remote Mailboxes – der nächste Schritt zur finalen Exchange-Server-Stilllegung

Hintergrund: Das „Last Exchange Server“-Problem

Viele Unternehmen, die mittlerweile sämtliche Postfächer in Exchange Online betreiben, behalten dennoch einen lokalen Exchange-Server – allein zur Verwaltung von Empfängerattributen. In Hybrid-Szenarien ist das Bearbeiten von Remote-Mailbox-Eigenschaften in der Cloud standardmäßig blockiert, da die Quelle der Autorität (Source of Authority, SOA) in der On-Premises-Exchange-Umgebung liegt (techcommunity.microsoft.com).

Die neue Cloud-Management-Funktion

Microsoft hat ein neues Feature in Exchange Online (aktuell im Preview-Status) angekündigt, das es ermöglicht, die Exchange-Attribute synchronisierter Benutzerkonten mit Remote-Postfächern direkt aus der Cloud zu bearbeiten. Identitätsattribute wie Name oder Telefon bleiben dabei nach wie vor On-Premises-verwaltet (techcommunity.microsoft.com).

Zentrales Element ist der neue Parameter IsExchangeCloudManaged. Setzt man diesen auf True, übernimmt Exchange Online die Quelle der Autorität für die betreffenden Exchange-Attribute eines Benutzers (techcommunity.microsoft.com).

So funktioniert es im Detail

  • Standardmäßig ist bei synchronisierten Benutzern IsExchangeCloudManaged = False, d. h. Exchange-Attribute werden in der On-Premises-AD verwaltet und in die Cloud repliziert.
  • Wird IsExchangeCloudManaged = True, kann man Exchange-Attribute wie E-Mail-Adressen, spezielle Attribute (z. B. CustomAttribute1–15, proxyAddresses) über Exchange Online PowerShell oder das Admin Center ändern. Diese Änderungen bleiben erhalten, da der On-Prem-Sync sie nicht mehr überschreibt (learn.microsoft.com).
  • Identitätsattribute – z. B. Name, Abteilung, Telefonnummer – verbleiben weiterhin unter der Kontrolle der lokalen Active Directory und sind von der Änderung nicht betroffen (techcommunity.microsoft.com).
  • In Phase 1 (aktuell verfügbar) kann pro Postfach entschieden werden, welches Attributset cloud-gesteuert wird. Eine Rückumstellung (Rollback) ist möglich (learn.microsoft.com).
  • In einer späteren Phase (Phase 2) ist geplant, dass Änderungen an Exchange-Attributen in der Cloud automatisch wieder zurück in das lokale AD geschrieben werden („Write-Back“), vorausgesetzt, Entra Cloud Sync wird genutzt (learn.microsoft.com).
  • Bereits verfügbar ist eine object-level SOA-Übertragung für Gruppen (Group SOA); künftig sollen Attribute auch für Benutzer- und Kontaktobjekte cloud-gesteuert werden können (learn.microsoft.com).

Vorteile dieser Entwicklung

  • Endlich Exchange-Server-frei – Der „Last Exchange Server“ wird überflüssig, selbst in Hybrid-Szenarien.
  • Weniger administrative Komplexität – Verwaltung über Exchange Online PowerShell, Admin Center oder Microsoft 365 Admin Center.
  • Sicherheitsgewinn – Reduzierter On-Prem-Fußabdruck bedeutet weniger Angriffsfläche und weniger Patchaufwand.
  • Zukunftssicher – Mit geplantem Write-Back und Cloud-SOA für Gruppen und Kontakte entsteht eine echte Cloud-Zielarchitektur.

Umsetzung: So hebst du IsExchangeCloudManaged auf

  1. In Exchange Online PowerShell: Set-Mailbox -Identity <User> -IsExchangeCloudManaged $true
  2. Status prüfen: Get-Mailbox -Identity <User> | Format-List Identity, IsExchangeCloudManaged

Meine Meinung als IT-Consultant

Für viele unserer Kunden ist dies ein Herzenswunsch, der nun endlich Realität wird: weg vom letzten lokalen Exchange-Server, hin zu einer komplett cloudbasierten Verwaltung. In zahlreichen Projekten haben wir immer wieder erlebt, dass die Pflicht, einen On-Premises-Server nur für die Exchange-Verwaltung stehen zu lassen, nicht nur technisch, sondern auch organisatorisch und sicherheitsrelevant ein großes Ärgernis war. Mit den Cloud-Managed Remote Mailboxes ist diese Hürde nun gefallen – und das macht den Weg zur echten „Cloud Only“-Strategie frei.

Fazit

Mit Cloud-Managed Remote Mailboxes macht Microsoft einen bedeutenden Schritt in Richtung endgültige Ablösung des lokalen Exchange Servers – auch für hybride Umgebungen. Diese neue Funktion bündelt Verwaltung, Sicherheit und Flexibilität in der Cloud und zeigt deutlich, wie die Zukunft der Exchange-Verwaltung aussieht.

Conditional Access und Microsoft Defender for Endpoint: Ein Teufelskreis?

Eine wirkungsvolle Möglichkeit, die Sicherheit innerhalb eines Unternehmens zu erhöhen, besteht darin, den Microsoft Defender for Endpoint Status über eine Compliance-Richtlinie in den Compliance-Status für Intune verwaltete Geräte einzubinden. Auf diese Weise können gefährdete Geräte schnell identifiziert und vom Zugriff auf Unternehmensdaten ausgeschlossen werden. Dieser Ansatz schafft eine zusätzliche Schutzebene. Zusätzlich stellt dieser sicher, dass nur Geräte mit einem sicheren Status auf sensible Informationen zugreifen können. Insbesondere bei schwerwiegenden Sicherheitslücken oder Sicherheitsvorfällen ist dies eine zuverlässige Methode die Geräte bis zur Mitigation der Ursache vom Zugriff auf Unternehmensdaten zu sperren.

Dender for Endpoint in Compliance Policy
Dender for Endpoint in Compliance Policy

Allerdings kann die Verknüpfung von Microsoft Defender for Endpoint und Conditional Access Richtlinien schnell in einen Teufelskreis führen. Das passiert , wenn eine Conditional Access Regel implementiert ist, die den Zugriff für nicht kompatible Geräte blockiert. Dadurch entsteht ein Dilemma: Die betroffenen Geräte können sich nicht erneut als kompatibel registrieren. Der Grund dafür ist die Conditional Access Policy die den Zugriff sperrt. Das macht es für den Administrator schwer das Gerät, ohne ein komplettes Zurücksetzen wieder kompatibel zu bekommen.

Wie der Teufelskreis entsteht?

Standardmäßig können die beiden Microsoft Defender for Endpoint Applikationen nicht direkt aus Conditional Access Richtlinien ausgenommen werden. Die Folge ist, dass Geräte, die durch den Conditional Access blockiert werden, keine Möglichkeit haben, sich wieder als kompatibel zu registrieren. Der Zugriff auf dafür notwendige Dienste wird gesperrt, wodurch der Status „nicht kompatibel“ bestehen bleibt. Standardmäßig stehen die beiden Applikationen „MicrosoftDefenderATP XPlat“ und „Microsoft Defender for Mobile TVM app“ nicht im Conditional Access zur Auswahl.

Wie kann der Teufelskreis durchbrochen werden?

Um diesen Teufelskreis zu durchbrechen, müssen die beiden Service Principals registriert werden: „MicrosoftDefenderATP XPlat app“ (a0e84e36-b067-4d5c-ab4a-3db38e598ae2) und Microsoft Defender for Mobile TVM app (e724aa31-0f56-4018-b8be-f8cb82ca1196).

Dies funktioniert mit der Powershell mit folgendem Code:

Install-Module Microsoft.Graph

Import-Module Microsoft.Graph.Applications

 

Connect-MgGraph

$params = @{

              appId = "a0e84e36-b067-4d5c-ab4a-3db38e598ae2"

}

New-MgServicePrincipal -BodyParameter $params

$params = @{

              appId = "e724aa31-0f56-4018-b8be-f8cb82ca1196"

}

New-MgServicePrincipal -BodyParameter $params

Nach der Registrierung können die Anwendungen aus den Conditional Access Richtlinien ausgeschlossen werden. Dieser Ausschluss sorgt dafür, dass die Geräte weiterhin Zugriff auf die notwendigen Dienste haben, selbst wenn sie als nicht kompatibel markiert sind. Dadurch wird es möglich, die Geräte wieder als kompatibel zu registrieren und den Zugriff zu normalisieren.

Defender for Endpoint aus Conditional Access Policy ausschließen.
Defender for Endpoint aus Conditional Access Regel ausschließen

Fazit

Mit diesem Trick kann der Teufelskreis durchbrochen werden und die Geräte erhalten wieder Zugriff auf die M365 Dienste, sobald die Compliance wiederhergestellt ist. Auch bleibt während der Non-Compliance die Kommunikation mit dem Defender for Endpoint bestehen und wird nicht „abgeschnitten“. Das erhöht die Sicherheit und hilft dabei das Potential des Defender for Endpoints bestmöglich zu nutzen. Der Defender for Endpoint Status kann unter anderem in den Compliance Policies für Windows, iOS und Android genutzt werden.

Neuer Missbrauch der DHCP-Administratorengruppe zur Erweiterung der Privilegien in Windows-Domänen

Als IT-Consultant möchte ich Sie, die IT-Administratoren, über eine kritische Sicherheitsbedrohung informieren, die die DHCP-Administratorengruppe in Windows-Domänen betrifft. Dieses Risiko könnte unzureichend abgesicherte DHCP-Server in Machtinstrumente für Angreifer verwandeln, die vollständige Domain-Übernahmen anstreben.

Was Sie wissen müssen: Die DHCP-Administratorengruppe kann in einigen Fällen dazu missbraucht werden, erweiterte Berechtigungen innerhalb einer Windows-Domäne zu erlangen. Dies geschieht durch das Manipulieren von DHCP-Optionen, die eigentlich dazu dienen, Netzwerkkonfigurationen zu verteilen.

Wie genau funktioniert der Angriff?

Der Angriff mittels der DHCP-Administratorengruppe für Privilegienerweiterung in Windows-Domänen erfolgt durch die missbräuchliche Verwendung der DHCP-Konfigurationsmöglichkeiten. Angreifer, die Zugang zur DHCP-Administratorengruppe haben, können spezielle DHCP-Optionen manipulieren. Ein kritischer Punkt dabei ist die Veränderung der DNS-Servereinstellungen über DHCP, was es ermöglicht, DNS-Anfragen umzuleiten. Dies kann zu einer Maschine-im-Mittelpunkt (MITM)-Attacke führen, bei der der Angreifer DNS-Anfragen abfängt oder manipuliert, um weitergehende Angriffe wie Kerberos-Authentifizierungsumleitungen durchzuführen. Solche Angriffe ermöglichen eine Eskalation der Privilegien bis hin zur Übernahme eines Domain Controllers, wenn der DHCP-Server auf diesem installiert ist.

Ein kritischer Aspekt dieses Angriffs auf die DHCP-Administratorengruppe ist, dass er auf legitimen Konfigurationsmöglichkeiten beruht und keine direkten Schwachstellen ausnutzt. Daher existiert keine einfache „Fix“ oder Patch, um diese Angriffsart zu unterbinden.

Präventionsmaßnahmen

In der Welt der Netzwerksicherheit ist die korrekte Platzierung und Verwaltung von Rollen innerhalb einer Active Directory (AD)-Umgebung entscheidend, um Sicherheitsrisiken zu minimieren. Ein häufig übersehener, aber kritischer Aspekt ist die Trennung von Diensten durch das AD Tiering Modell, speziell die Positionierung der DHCP-Rolle in Bezug auf Domain Controller (DC).

Das Risiko einer inkorrekten Rollenverteilung: Wenn der DHCP-Dienst auf einem Domain Controller installiert ist, öffnet dies Tür und Tor für potenzielle Angriffe. Angreifer, die Zugriff auf die DHCP-Administratorengruppe erlangen, können diese Position nutzen, um weitreichende Privilegien innerhalb der Domäne zu eskalieren. Diese Gefahr wird durch die Nutzung von DHCP-Optionen verstärkt, die manipuliert werden können, um bösartige Netzwerkkonfigurationen zu verbreiten oder unerlaubte DNS-Updates zu initiieren.

Die Lösung durch AD Tiering: Ein gut durchdachtes AD Tiering Modell bietet eine effektive Strategie, um solche Risiken zu mindern.

Im idealen Modell:

  • Tier 0 umfasst die Domain Controller und andere kritische Infrastrukturkomponenten, die die höchsten Sicherheitsanforderungen haben.
  • Tier 1 sollte Dienste wie DHCP beherbergen, die zwar wichtig sind, aber eine klare Trennung von den Kernkomponenten des Active Directory benötigen.

Durch die Einhaltung dieses Modells wird verhindert, dass DHCP-Administratoren Zugriff auf die kritischsten Bereiche der IT-Infrastruktur erhalten und somit das Risiko einer Privilegienerweiterung drastisch reduziert.

Schritte zur Implementierung und Überwachung:

  1. Überprüfung der aktuellen Infrastruktur: Identifizieren Sie alle Instanzen, in denen DHCP-Dienste auf Domain Controllern laufen, und planen Sie deren Migration.
  2. Einrichtung von Zugriffsbeschränkungen: Stellen Sie sicher, dass nur autorisierte Benutzer Zugriff auf kritische Systeme im Tier 0 haben.
  3. Regelmäßige Überwachung und Anpassungen: Überwachen Sie die Einhaltung des Tiering-Modells und passen Sie die Zugriffsrechte kontinuierlich an.

Fazit: Die strikte Trennung von Diensten nach dem AD Tiering Modell ist ein wesentlicher Bestandteil einer robusten Sicherheitsstrategie. Indem Sie sicherstellen, dass kritische und weniger kritische Systeme ordnungsgemäß isoliert sind, stärken Sie die Sicherheit Ihrer gesamten IT-Infrastruktur und minimieren das Risiko von Sicherheitsvorfällen, die durch eine falsche Rollenzuweisung entstehen könnten. Mehr zum Tiering Model finden Sie hier:

AD Tiering Struktur – Funktion und Nutzen

Wie Hacker Schwachstellen durch Netzwerkerkennung (NDR) aufdecken

Netzwerkerkennung und -reaktion (Network Detection and Response, kurz NDR) ist eine fundamentale Komponente in der Sicherheitsarchitektur vieler Unternehmen. Sie bietet tiefe Einblicke in den Netzwerkverkehr und ermöglicht es Sicherheitsteams, ungewöhnliche Aktivitäten zu erkennen, die auf eine Kompromittierung hindeuten könnten. Doch obwohl NDR viele Vorteile bietet, gibt es bestimmte Aspekte, durch die Hacker in der Lage sind, Lücken in dieser Sicherheitsebene zu finden und zu nutzen.

Die Doppelrolle von NDR

NDR als Detektor: NDR-Systeme sind darauf ausgelegt, Anomalien im Netzwerkverkehr zu erkennen. Sie nutzen fortschrittliche Algorithmen und maschinelles Lernen, um Muster zu identifizieren, die auf Malware-Infektionen, Datenexfiltration oder unautorisierten Zugriff hinweisen könnten. Diese Systeme sind essenziell, um schnell auf Bedrohungen reagieren zu können, die traditionelle Sicherheitslösungen wie Firewalls und Antivirus-Programme umgehen.

NDR als Ziel: Gleichzeitig können NDR-Systeme selbst zum Ziel werden. Hacker, die die Funktionsweise von NDR verstehen, entwickeln Methoden, um diese Systeme zu umgehen oder irrezuführen. Beispielsweise können sie verschleierten oder getarnten Datenverkehr nutzen, der so gestaltet ist, dass er von NDR-Systemen als normal eingestuft wird. Außerdem können Angriffe zeitlich so geplant werden, dass sie während Volumenspitzen stattfinden, bei denen die Wahrscheinlichkeit größer ist, dass sie in der Masse des normalen Verkehrs untergehen.

Wie Hacker NDR-Systeme austricksen

1. Einsatz von Verschleierungstechniken: Hacker verwenden Techniken wie das Splitting von Datenpaketen oder das Verschlüsseln von Malware-Kommunikation, um die Erkennung durch NDR-Systeme zu erschweren. Diese Methoden können dazu führen, dass bösartiger Datenverkehr als harmlos eingestuft wird.

2. Ausnutzung von Konfigurationsschwächen: Schwachstellen in der Konfiguration von NDR-Systemen können es Angreifern ermöglichen, Warnungen zu unterdrücken oder Fehlalarme zu generieren, die Sicherheitsteams ablenken und echte Angriffe verbergen.

3. Angriffe auf die Datenintegrität: Durch Manipulation der von NDR-Systemen erfassten Daten können Hacker die Glaubwürdigkeit der Systemausgaben untergraben. Dies kann durch gezielte Netzwerkangriffe geschehen, bei denen Datenpakete modifiziert oder gefälschte Pakete injiziert werden.

Strategien zur Stärkung von NDR

A. Fortlaufende Überprüfung und Anpassung: Regelmäßige Updates und Patches für NDR-Systeme sind unerlässlich, um Schutzmaßnahmen gegen neu entdeckte Angriffstechniken zu verstärken.

B. Erweiterte Schulung der Sicherheitsteams: Sicherheitsteams sollten speziell geschult werden, um die Taktiken, Techniken und Prozeduren (TTPs) der Angreifer, die auf NDR-Systeme abzielen, zu verstehen und effektiv zu bekämpfen.

C. Integration in eine umfassende Sicherheitsstrategie: NDR sollte nicht isoliert betrachtet werden. Eine Integration in eine übergreifende Sicherheitsstrategie, die andere Ebenen und Maßnahmen umfasst, ist entscheidend, um die Wirksamkeit zu maximieren und Sicherheitslücken zu minimieren.

Obwohl NDR-Systeme eine kritische Rolle in der modernen Netzwerksicherheit spielen, ist es wichtig, sich bewusst zu sein, dass keine Technologie allein ausreicht, um gegen fortschrittliche Cyberbedrohungen immun zu sein. Unternehmen müssen eine mehrschichtige Verteidigungsstrategie verfolgen, die sowohl präventive als auch reaktive Sicherheitsmaßnahmen umfasst.

Warum EDR und XDR gegenüber ausgefeilten Angriffen immer wieder scheitern

In der heutigen komplexen IT-Landschaft, die von ständigen Bedrohungen und sich entwickelnden Angriffstechniken geprägt ist, setzen viele Unternehmen auf Endpoint Detection and Response (EDR) und Extended Detection and Response (XDR) Lösungen, um ihre Netzwerke zu schützen. Obwohl diese Tools entscheidend sind, um viele Arten von Sicherheitsvorfällen zu erkennen und darauf zu reagieren, zeigen Erfahrungen, dass sie bei besonders ausgeklügelten Angriffen an ihre Grenzen stoßen können.

Die Grenzen von EDR und XDR

1. Abhängigkeit von bekannten Signaturen und Verhaltensmustern: EDR- und XDR-Systeme sind oft stark abhängig von Signaturen bekannter Malware und definierten Verhaltensmustern, um Bedrohungen zu identifizieren. Fortgeschrittene Angreifer entwickeln jedoch maßgeschneiderte Lösungen und Methoden, die speziell darauf ausgelegt sind, diese Erkennungsmechanismen zu umgehen. Das bedeutet, dass neue oder angepasste Schadsoftware, die keine erkennbaren Signaturen oder typischen Verhaltensmuster aufweist, möglicherweise nicht erkannt wird.

2. Mangel an Kontext und ganzheitlicher Sicht: Obwohl XDR-Lösungen eine breitere Datensammlung aus verschiedenen Quellen bieten, fehlt es ihnen oft an dem notwendigen Kontext, um die Daten effektiv zu korrelieren und zu interpretieren. Dies führt dazu, dass zwar viele Datenpunkte gesammelt werden, die Analyse jedoch oberflächlich bleibt und somit komplexe Angriffsszenarien nicht vollständig aufgedeckt werden können.

3. Falsche Alarme und Überwachungsmüdigkeit: Ein weiteres Problem stellt die hohe Anzahl von Fehlalarmen dar, die sowohl EDR- als auch XDR-Systeme produzieren können. Dies führt zu einer Überwachungsmüdigkeit bei den Sicherheitsteams, wodurch echte Bedrohungen in einem Meer von Fehlalarmen untergehen können.

4. Ressourcen- und Know-how-Begrenzungen: Viele Unternehmen verfügen nicht über die notwendigen Ressourcen oder das spezialisierte Wissen, um EDR- und XDR-Tools vollständig zu nutzen und zu warten. Dieses Manko wird besonders deutlich, wenn es darum geht, die von diesen Systemen gelieferten Daten zu interpretieren und darauf basierend angemessene Reaktionen zu formulieren.

Beispiele aus der Praxis

Die Herausforderungen und Grenzen von EDR- und XDR-Systemen lassen sich anhand einiger Beispiele aus der Praxis veranschaulichen:

1. Umgehung durch Polymorphismus: Angreifer nutzen polymorphe Malware, die ihr Erscheinungsbild ständig ändert, um Signaturen zu umgehen. Da EDR und XDR stark von Signaturen abhängig sind, können solche Malware-Arten oft unentdeckt bleiben.

2. Ausnutzung von Zero-Day-Schwachstellen: Zero-Day-Exploits, also Schwachstellen, die noch nicht öffentlich bekannt oder gepatcht sind, können von Angreifern genutzt werden, bevor Sicherheitssysteme wie EDR oder XDR darauf eingestellt sind. Diese Art von Angriff ist schwer zu erkennen, da sie keine bekannten Signaturen oder Verhaltensmuster verwenden.

3. Seitliche Bewegungen und legitime Tools: Fortgeschrittene Angreifer verwenden Techniken des seitlichen Bewegens (Lateral Movement) und setzen dabei legitime Administrationswerkzeuge ein, was die Erkennung durch EDR und XDR erschwert. Diese Werkzeuge generieren Aktivitäten, die normal erscheinen und daher oft nicht als bösartig erkannt werden.

4. Angriffe auf das EDR-System selbst: In einigen Fällen richten sich Angriffe direkt gegen die EDR- oder XDR-Lösungen, um diese zu deaktivieren oder zu manipulieren. Solche Angriffe können schwerwiegende Folgen haben, da sie das gesamte Sicherheitssystem kompromittieren.

5. Hohe Rate von Falschpositiven: Die hohe Anzahl von Fehlalarmen, die durch EDR und XDR generiert werden können, führt oft dazu, dass Sicherheitsteams wichtige Warnungen übersehen. Dieses Phänomen wird auch als „Alarmmüdigkeit“ bezeichnet und kann dazu führen, dass echte Bedrohungen nicht rechtzeitig erkannt oder behandelt werden.

Diese Beispiele unterstreichen die Notwendigkeit, Sicherheitssysteme kontinuierlich zu überprüfen und zu verbessern, um mit den sich ständig ändernden Taktiken und Techniken der Angreifer Schritt zu halten.

Strategien zur Verbesserung der Cybersicherheit

A. Anpassung und Weiterentwicklung: IT-Entscheider und Administratoren müssen kontinuierlich in die Weiterbildung ihrer Teams und die Anpassung ihrer Sicherheitssysteme investieren, um mit den sich ändernden Angriffstechniken Schritt zu halten.

B. Einsatz von KI und maschinellem Lernen: Der Einsatz von fortgeschrittenen KI-Technologien kann dazu beitragen, das Erkennungsvermögen von EDR- und XDR-Systemen zu verbessern, indem ungewöhnliche Muster erkannt werden, die sonst unentdeckt bleiben könnten.

C. Betonung auf proaktive Verteidigungsmaßnahmen: Statt sich ausschließlich auf Erkennung zu verlassen, sollten Unternehmen eine proaktivere Sicherheitsstrategie verfolgen, die Risikomanagement, die Stärkung von Endpunkten und die Schulung der Mitarbeiter umfasst.

D. Verbesserung der Incident Response: Eine effektive Incident-Response-Strategie ist entscheidend, um die Auswirkungen von Sicherheitsvorfällen zu minimieren. Diese sollte eine schnelle Identifikation, eine umfassende Untersuchung und eine koordinierte Reaktion auf Sicherheitsvorfälle beinhalten.

E. Härtung durch die Implementierung von einem „Berechtigungskonzept“ unter Berücksichtigung von einer AD Tiering Struktur.

F. Implementierung einer vollständigen Zero-Trust-Architektur.

Siehe hierzu: Zero-Trust-Implementierung mit Microsoft 365

Trotz der fortschrittlichen Technologien, die EDR und XDR bieten, sind sie keine Allheilmittel. Die Sicherheitslandschaft erfordert eine ständige Anpassung und Weiterentwicklung der Strategien und Werkzeuge, um den Bedrohungen immer einen Schritt voraus zu sein

Exchange Online: Abschied von Basic Auth bei SMTP AUTH – Was Sie wissen müssen

Im September 2025 wird Exchange Online die Unterstützung für die Basic Authentication bei der Client Submission über SMTP AUTH einstellen. Diese Änderung betrifft alle Anwendungen und Geräte, die derzeit diese Methode nutzen, um E-Mails zu senden. Stattdessen wird OAuth als sicherere Authentifizierungsmethode erforderlich sein.

Wer ist betroffen?

Betroffen sind Organisationen und Einzelpersonen, die Exchange Online für das Versenden von E-Mails über SMTP AUTH nutzen. Insbesondere diejenigen, die bisher Basic Authentication verwendet haben, müssen auf moderne Authentifizierungsmethoden umstellen.

Was muss berücksichtigt werden?

  1. Überprüfung der Authentifizierungsmethode: Nutzer sollten im Exchange Admin Center überprüfen, ob bereits OAuth verwendet wird oder noch Basic Auth im Einsatz ist.
  2. Anpassung der E-Mail-Clients: Sollte Ihr E-Mail-Client noch Basic Auth verwenden, ist ein Update oder Wechsel des Clients notwendig, um OAuth zu unterstützen.
  3. Alternative Lösungen: Falls eine Umstellung auf OAuth nicht möglich ist, sollten Nutzer alternative E-Mail-Lösungen in Betracht ziehen, wie z.B. High Volume Email für Microsoft 365 oder Azure Communication Services Email.

Diese Umstellung erfordert eine frühzeitige Planung und gegebenenfalls technische Anpassungen, um einen reibungslosen Übergang zu gewährleisten und die Sicherheit der Datenkommunikation zu erhöhen. Es ist wichtig, dass betroffene Organisationen und Individuen rechtzeitig mit den Vorbereitungen beginnen, um Unterbrechungen im E-Mail-Verkehr zu vermeiden. Weitere Informationen finden Sie auf der offiziellen Ankündigungsseite von Microsoft.

Cookie Consent mit Real Cookie Banner