Identitätsschutz in Cloud-Umgebungen Wenn der legitime Login zum Angriffspfad wird

Anbieter zum Thema

Kaspersky Labs GmbH

secunet Security Networks AG

Hyland Software Germany GmbH

Angreifer missbrauchen legitime Cloud-Dienste, OAuth-Flows und gültige Sitzungen. Unternehmen müssen deshalb Identität, Gerät, Anwendung und Telemetrie als zusammenhängende Angriffsfläche absichern.

Zwischen Juli 2025 und Juni 2026 registrierten Kaspersky-Lösungen weltweit rund 4,7 Millionen Angriffsversuche mit Inhalten, die verbreitete Arbeitsplatzdienste wie Zoom, Outlook, OneDrive oder Teams imitierten. Die Zahl verdeutlicht, wie attraktiv bekannte Plattformen für Angreifer sind: Nutzer vertrauen diesen Marken, während Sicherheitsmechanismen Angriffe über legitime Cloud-Infrastrukturen nicht pauschal blockieren können.

Wie Angreifer legitime Cloud-Anmeldungen missbrauchen

So nutzen Angreifer zum Beispiel Device-Code-Phishing in Microsoft-365-Umgebungen, um sich Zugriff zu verschaffen. Der Angreifer initiiert einen Device-Authorization-Prozess und erhält dabei unter anderem einen einmaligen Code. Anschließend bringt er den Nutzer dazu, diesen Code auf der echten Microsoft-Anmeldeseite einzugeben und die Authentifizierung abzuschließen – gegebenenfalls einschließlich Multifaktor-Authentifizierung.

Anders als beim klassischen Credential Harvesting fängt der Angreifer dabei keine Zugangsdaten ab. Er missbraucht vielmehr einen nativen, für Geräte mit eingeschränkten Eingabemöglichkeiten vorgesehenen Autorisierungsablauf und bringt den Nutzer dazu, den vom Angreifer initiierten Vorgang selbst zu bestätigen. Abhängig von Anwendung und Berechtigungsumfang ermöglichen sie beispielsweise den Zugriff auf E-Mails, OneDrive-Dateien oder Teams-Kommunikation. So können legitime Cloud-Speicher und Kollaborationsplattformen zur Verteilung schädlicher Dateien oder Links dienen.

Cloud-Sicherheit braucht mehrere Schutzschichten

Für einen wirksamen Schutz reicht es nicht, nur die Reputation einer Domain oder den Inhalt einer einzelnen E-Mail zu bewerten. Entscheidend ist die Kombination aus Identität, Zugriffsweg, Anwendung, Gerät und anschließendem Verhalten. Eine Cloud-Umgebung wie Microsoft 365 benötigt mehrere aufeinander abgestimmte Sicherheitsmaßnahmen:

1. Phishing beim Erstkontakt erkennen
Am Anfang prüfen E-Mail- und Web-Schutz eingehende Nachrichten, Links und Anhänge. Sie können den Erstkontakt und klassische Phishing-Varianten reduzieren.

2. Cloud-Zugriffe risikobasiert steuern
Der „Conditional Access“ muss über die Bedingung „MFA erfüllt“ hinausgehen. Besonders sensible Daten und administrative Funktionen sollten möglichst nur von verwalteten und konformen Endgeräten erreichbar sein. Risikoreiche Anmeldungen, unbekannte Geräte oder nicht vorgesehene Client-Anwendungen können zusätzliche Prüfungen, einen eingeschränkten Zugriff oder eine Blockierung auslösen. Nicht benötigte Device-Code- und ältere Authentifizierungsverfahren sollten deaktiviert oder auf klar definierte Geräteszenarien begrenzt werden. Diese Richtlinien werden in der Identitäts- und Geräteverwaltung der jeweiligen Cloud-Plattform umgesetzt – bei Microsoft-Umgebungen insbesondere in Entra ID und gegebenenfalls in Verbindung mit Microsoft Intune.

3. FIDO2 und WebAuthn für phishing-resistente MFA einsetzen
Phishing-resistente, FIDO2- oder WebAuthn-basierte Verfahren – etwa verwaltete Passkeys oder hardwaregebundene Sicherheitsschlüssel – sollten zuerst für Administratoren, privilegierte Konten und besonders sensible Nutzer eingeführt werden. Denn sie reduzieren die Abhängigkeit von Einmalcodes oder Push-Bestätigungen, die Nutzer irrtümlich für einen vom Angreifer initiierten Vorgang freigeben können. Die Einführung und Verwaltung dieser Authentifizierungs­verfahren erfolgt über die jeweilige Identitätsplattform sowie geeignete Authenticatoren oder Sicherheitsschlüssel.

4. OAuth- und Anwendungsrechte kontrollieren
Unternehmen benötigen ein vollständiges Inventar der Anwendungen, die auf Unternehmensdaten zugreifen. Weitreichende delegierte oder anwendungsbezogene Berechtigungen müssen einem kontrollierten Freigabeprozess unterliegen. Nicht mehr benötigte Anwendungen und Zugriffsrechte gehören entfernt. Nutzer sollten zudem nicht uneingeschränkt selbst über Berechtigungen mit hohem Schadenspotenzial entscheiden können.

5. Berechtigungen konsequent begrenzen
Auf der SaaS- und Datenebene begrenzen Richtlinien, welche Anwendungen und Identitäten auf Mailboxen, Dateien oder Kollaborationsräume zugreifen dürfen. Die Gerätesicherheit liefert ergänzend Informationen über Browser, Prozesse, lokale Schadsoftware und den Compliance-Status des Endgeräts.

6. Zentrale Cloud-Telemetrie
Den Abschluss der Architektur bildet die zentrale Telemetrie: Sign-in-, Audit-, App-, E-Mail-, Cloud- und Endpoint-Ereignisse müssen in SIEM oder XDR zusammenlaufen. Nur so lassen sich mehrere für sich genommen unauffällige Signale zu einer Angriffskette verbinden.

Für Security Operations sind vor allem Abweichungen vom erwartbaren Verhalten relevant. Dazu gehören Device-Code-Anmeldungen ohne nachvollziehbaren Geschäftsprozess, neue Anwendungen, ungewöhnlich weitreichende OAuth-Berechtigungen, Änderungen an Service Principals sowie Cloud-Zugriffe aus einem auffälligen geografischen, zeitlichen oder technischen Kontext. Ein einzelnes Signal weist jedoch noch nicht zwangsläufig auf einen Vorfall hin. SIEM- oder XDR-Erkennungen sollten deshalb nicht nur isolierte Ereignisse, sondern konkrete Verhaltensketten abbilden.

Gewappnet für den Ernstfall: Incident Response

Hat ein Nutzer einen fremden Device Code bestätigt oder einer unbekannten Anwendung Zugriff erteilt, sollte der Vorgang wie eine Identitätskompromittierung behandelt werden. Zunächst sind die relevanten Authentifizierungs-, Audit-, App-, Cloud- und gegebenenfalls Endpoint-Logs zu sichern. Anschließend müssen aktive Sitzungen beendet und relevante Token widerrufen werden. Bei einem solchen Angriff sollten zusätzlich die unerwünschten App-Berechtigungen oder Consent Grants entfernt und gegebenenfalls die Anwendung oder der zugehörige Service Principal vollständig gesperrt werden. Ein Passwortwechsel kann Teil der Reaktion sein, darf aber nicht die einzige Maßnahme bleiben.

Danach sollte der Umfang der Kompromittierung bestimmt werden. Dazu muss das Sicherheitsteam unter anderem klären, welche Rechte die Anwendung oder Sitzung besaß und auf welche Mailboxen, Dateien, Kalender oder Teams-Inhalte zugegriffen werden konnte. Besteht zusätzlich der Verdacht auf lokalen Schadcode, sollte das Endgerät isoliert und forensisch untersucht werden.

Die gewonnenen Erkenntnisse sollten anschließend in Erkennungsregeln, Conditional-Access-Richtlinien und das Incident-Response-Playbook einfließen. Ziel ist nicht nur, das betroffene Passwort zu ändern, sondern sämtliche Bestandteile der Angriffskette zu schließen.

APIs, SaaS und KI locken Angreifer

Die unsichtbare Gefahr: Neue Angriffspfade in der Cloud-Lieferkette

Besonderheiten hybrider Identitäten

In hybriden Umgebungen besteht die Herausforderung, dass moderne Cloud-Dienste, lokale Systeme und Legacy-Anwendungen parallel betrieben werden. Nicht alle Systeme unterstützen bereits moderne, Phishing-resistente Authentifizierungsverfahren. Unternehmen sollten deshalb zunächst erfassen, wo FIDO2 beziehungsweise WebAuthn eingesetzt werden kann und wo ältere Authentifizierungsverfahren vorerst bestehen bleiben müssen. Für verbleibende passwortbasierte Zugriffe ist eine stärkere Überwachung erforderlich.

Zugriffe sollten dabei nach dem Least-Privilege-Prinzip auf die tatsächlich benötigten Ressourcen beschränkt werden. Gleichzeitig müssen Sicherheitsdaten aus Cloud-, Identity- und Endpoint-Systemen zentral zusammengeführt werden. So können Security Operations Aktivitäten über unterschiedliche Teile einer hybriden Umgebung hinweg korrelieren und daraus konkrete Detection Use Cases ableiten.

Warum einzelne Sicherheitsmaßnahmen nicht genügen

MFA bleibt unverzichtbar, ist aber keine alleinige Lösung. Beim Device-Code-Phishing kann der Nutzer einen technisch legitimen Authentifizierungsvorgang selbst bestätigen. Auch gut geschulte Mitarbeiter können an Grenzen stoßen, wenn eine echte Cloud-Plattform oder Anmeldeseite Teil der Angriffskette ist. URL- und Domain-Prüfungen können legitime Infrastruktur nicht generell blockieren. Endpoint-Schutz wiederum beendet keinen bereits erteilten Cloud-Zugriff, und ein Passwortwechsel entfernt keine App-Berechtigung.

Die Maßnahmen behalten dennoch ihren Wert beziehungsweise entfalten ihn dann, wenn sie zusammenwirken: Phishing-resistente Authentifizierung erschwert die Kontoübernahme, Conditional Access begrenzt Zugriffe, App-Governance kontrolliert Berechtigungen, E-Mail- und Endpoint-Schutz liefern weitere Signale und zentrale Telemetrie macht die gesamte Angriffskette sichtbar.

Im Hinblick auf die Bedrohungslandschaft darf das Sicherheitsziel nicht mehr allein lauten, jeden schädlichen Link bereits am Entry-Point zu erkennen. Vielmehr muss Cloud-Sicherheit auch dann funktionieren, wenn Domain, Anmeldeseite und Authentifizierung technisch legitim sind – der Kontext und die Absicht dahinter aber nicht.

(ID:50966953)