Logging-Lücken bei Cloud-Authentifizierung verstehen

Ein Sicherheitsteam von TrustedSec hat kürzlich seine dritte und vierte Methode veröffentlicht, mit der sich das Anmeldelogging in Azure umgehen lässt. Das sind vier unabhängige Techniken, um sich bei Microsoft-Cloud-Diensten zu authentifizieren, ohne dass die Authentifizierung in den Logs auftaucht, auf die sich Sicherheitsteams für die Erkennung verlassen. Die Anmeldung hat stattgefunden. Die Logs haben sie nicht erfasst. Wer diese Logs auf verdächtige Aktivitäten überwacht, hat nichts gesehen.

Das ist kein theoretisches Problem. Wenn ein Angreifer Zugangsdaten stiehlt und damit auf deine Azure-Umgebung zugreift, prüft dein Sicherheitsteam als Erstes die Anmeldelogs. Wenn diese Logs unvollständig sind, weil ganze Kategorien von Authentifizierungen gar keine Log-Einträge erzeugen, hat deine Erkennung ein Loch, von dem du nichts weißt. Und du hast Sicherheitsentscheidungen auf der Annahme getroffen, dass die Logs vollständig sind.

Warum Authentifizierungslogs Lücken haben

Die naive Annahme lautet, dass Authentifizierungs-Logging simpel ist: Jemand meldet sich an, also wird es protokolliert. In der Praxis ist Cloud-Authentifizierung ein weitverzweigtes System mit Dutzenden Protokollen, Endpunkten und Token-Typen, und die Logging-Abdeckung variiert je nach Pfad.

Azure Active Directory (heute Entra ID) übernimmt die Authentifizierung für Microsoft 365, Azure-Ressourcen, Drittanbieter-Apps über SAML/OIDC, ältere On-Premises-Anwendungen über App Proxy, Service Principals, Managed Identities und mehr. Jeder dieser Authentifizierungspfade hat sein eigenes Backend, seine eigene Logging-Pipeline und seine eigenen Sonderfälle. Anmeldelogs werden zwar vom Authentifizierungsdienst erzeugt, aber manche Abläufe umgehen den Standarddienst oder nutzen Altpfade, die älter sind als die aktuelle Logging-Infrastruktur.

Lücken durch Legacy-Protokolle

Microsoft hält die Abwärtskompatibilität zu Authentifizierungsprotokollen aus den frühen 2000er-Jahren aufrecht, Protokolle, die älter sind als die heutige Logging-Infrastruktur. Manche SMTP-, IMAP- und POP3-Authentifizierungen nutzen „Basic Auth“-Abläufe, die auf der Mail-Transportschicht authentifizieren und nicht über den regulären Azure-AD-Token-Endpunkt. Diese Anmeldungen erzeugen unter Umständen nicht dieselben Anmeldelog-Einträge wie moderne OAuth/OIDC-Abläufe.

Microsoft fasst Basic Auth schon seit Jahren als veraltet auf, doch in Unternehmensumgebungen geht die Abschaffung nur langsam voran. Organisationen mit alten Mail-Clients, Scannern, die Dokumente per E-Mail verschicken, oder älteren Fachanwendungen haben Basic Auth womöglich noch aktiviert. Jeder Legacy-Pfad ist eine potenzielle Logging-Lücke.

Service-Principal-Authentifizierung

Service Principals, also nicht-menschliche Identitäten, die Anwendungen und Automatisierungen nutzen, authentifizieren sich anders als Benutzer. Ihre Anmeldeereignisse erscheinen in einem eigenen Log-Stream (Service-Principal-Anmeldungen gegenüber interaktiven und nicht-interaktiven Anmeldungen). Sicherheitsteams, die nur das Log für interaktive Anmeldungen überwachen, übersehen Service-Principal-Aktivität komplett.

Das ist wichtig, weil kompromittierte Service Principals ein häufiger Angriffsvektor sind. Ein Angreifer, der die Zugangsdaten oder das Zertifikat eines Service Principals erbeutet, kann sich als diese Anwendung authentifizieren und auf alle Ressourcen zugreifen, für die sie Berechtigungen hat. Wenn das Sicherheitsteam nur Benutzeranmeldungen im Blick hat, bekommt es davon nie etwas mit.

Token-Replay und Refresh

Nicht jeder Zugriff erfordert eine neue Authentifizierung. OAuth-Refresh-Tokens erlauben fortgesetzten Zugriff, ohne dass man sich erneut anmeldet. Wenn ein Angreifer ein gültiges Refresh-Token stiehlt (etwa über ein kompromittiertes Gerät, abgefangenen Traffic oder Malware), kann er es gegen neue Access-Tokens eintauschen, ohne dieselben Anmeldelog-Einträge auszulösen wie bei einer passwortbasierten Anmeldung. Die ursprüngliche Anmeldung wurde protokolliert, doch spätere Token-Erneuerungen tauchen womöglich als nicht-interaktive Anmeldungen auf, und genau die überwachen viele Erkennungsregeln nicht.

Das Problem der Detection Engineering

Lücken im Authentifizierungs-Logging zeigen ein größeres Problem der Cloud-Sicherheit: Wir bauen Erkennungssysteme auf Logs, von denen wir annehmen, dass sie vollständig sind, und sind dann überrascht, wenn Angreifer Wege finden, die keine Logs erzeugen.

Die übliche Sicherheitsarchitektur für Cloud-Umgebungen sieht so aus: Cloud-Dienste erzeugen Logs → Logs fließen in ein SIEM (Security Information and Event Management System) → Erkennungsregeln analysieren die Logs auf verdächtige Muster → Alarme lösen eine Untersuchung aus. Das funktioniert nur, wenn die Logs die gesamte relevante Aktivität erfassen. Tun sie das nicht, ist dein SIEM eine sehr teure Methode, ein unvollständiges Bild zu überwachen.

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

Was du tatsächlich tun kannst

Die Logging-Lücken der Cloud-Anbieter kannst du nicht beheben, das ist Aufgabe von Microsoft (oder AWS oder Google). Du kannst aber Erkennungsstrategien aufbauen, die nicht allein davon abhängen, dass Authentifizierungslogs vollständig sind.

Mehrere Log-Quellen überwachen

Authentifizierungslogs sind nur ein Signal. Aktivitätslogs sind ein weiteres. Selbst wenn die Anmeldung eines Angreifers nicht in den Authentifizierungslogs auftaucht, erzeugen seine folgenden Aktionen (E-Mails lesen, auf Dateien zugreifen, Datenbanken abfragen, Konfigurationen ändern) eigene Log-Einträge. Das Gegenprüfen von Aktivitätslogs mit Authentifizierungslogs deckt Widersprüche auf: Aktivität einer Identität ohne passende aktuelle Anmeldung ist verdächtig, egal warum die Anmeldung nicht protokolliert wurde.

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

Legacy-Authentifizierung deaktivieren

Wenn du keine Legacy-Protokolle (Basic Auth für SMTP, IMAP, POP3) brauchst, schalte sie ab. Damit verschwinden ganze Kategorien von Logging-Lücken, weil die Authentifizierungspfade, die moderne Protokollierung umgehen, schlicht nicht mehr nutzbar sind. Die Conditional-Access-Richtlinien von Azure können Legacy-Authentifizierung pro Benutzer, pro Gruppe oder mandantenweit blockieren.

Prüfe vor dem Abschalten zuerst die aktuelle Nutzung. Die Azure-Anmeldelogs zeigen (ironischerweise) einige Legacy-Authentifizierungsversuche, und das Entra-ID-Workbook für Legacy-Auth hilft dabei, Anwendungen zu finden, die noch alte Protokolle nutzen. Behebe zuerst diese Anwendungen und blockiere dann die Legacy-Authentifizierung.

Token-Aktivität überwachen

Implementiere Continuous Access Evaluation (CAE), sofern deine Umgebung das unterstützt. CAE erlaubt es Azure AD, Tokens nahezu in Echtzeit zu widerrufen, wenn sich Bedingungen ändern (Benutzer deaktiviert, Hochrisiko-Anmeldung erkannt, IP-Standort wechselt). Ohne CAE bleibt ein gestohlenes Access-Token bis zu seinem Ablauf gültig, typischerweise eine Stunde, unabhängig davon, was das Sicherheitsteam tut.

Achte außerdem auf Token-Laufzeiten und Refresh-Muster. Ein Refresh-Token, das von einer neuen IP-Adresse, einem neuen Gerät oder zu ungewöhnlichen Uhrzeiten verwendet wird, sollte markiert werden, denn oft ist das das einzige Signal für Token-Diebstahl.

Das eigene Logging testen

Das Wirkungsvollste, was du tun kannst, ist regelmäßig zu prüfen, ob dein Logging tatsächlich erfasst, was du glaubst. Melde dich über jede Methode an, die deine Umgebung unterstützt (interaktiv, nicht-interaktiv, Service Principal, Legacy-Protokoll), und prüfe, ob jede davon die erwarteten Log-Einträge erzeugt. Wenn nicht, hast du eine Lücke gefunden, bevor es ein Angreifer tut.

Das ist eine Form des Testens im Detection Engineering, das nur wenige Organisationen systematisch betreiben. Die meisten Teams schreiben Erkennungsregeln und gehen davon aus, dass sie funktionieren. Die zugrunde liegende Datenqualität zu validieren, also zu bestätigen, dass die Ereignisse, auf die deine Regeln angewiesen sind, tatsächlich protokolliert werden, ist wohl wichtiger als die Regeln selbst.

Die größere Lehre

Die Umgehungen beim Azure-Anmeldelogging sind nicht auf Microsoft beschränkt. Jeder Cloud-Anbieter hat Authentifizierungspfade mit unvollständigem Logging. AWS CloudTrail hat eigene bekannte Lücken: bestimmte Control-Plane-Operationen in manchen Regionen, bestimmte Übernahmen von Service-Linked Roles und Ketten von Cross-Account-Rollen, die die ursprüngliche Identität verschleiern können. Die Audit-Logs von Google Cloud haben ähnliche Sonderfälle.

Die Lehre lautet nicht „Azure-Logging ist kaputt“. Sie lautet: Alle Logs sind unvollständig, und Sicherheitsarchitekturen, die etwas anderes annehmen, werden scheitern. Defense in Depth bedeutet nicht nur, mehrere Sicherheitskontrollen zu haben, sondern mehrere voneinander unabhängige Quellen der Sichtbarkeit. Hängt deine Erkennung vollständig davon ab, dass eine einzige Log-Quelle lückenlos ist, hast du in deiner Sicherheitslage einen Single Point of Failure.

Baue deine Erkennung auf der Annahme auf, dass jede einzelne Log-Quelle unvollständig sein oder umgangen werden kann. Korreliere Authentifizierungslogs, Aktivitätslogs, Netzwerklogs und Endpoint-Telemetrie. Suche nach Widersprüchen zwischen den Quellen, denn sie weisen oft genau auf die Lücken hin, die Angreifer ausnutzen. Und teste dein Logging regelmäßig, denn die Lücke, von der du nichts weißt, ist diejenige, die gegen dich verwendet wird.