ShinyHunters-Angriffe: Mandiant zeigt wirksame Schutzmaßnahmen gegen SaaS-Datendiebstahl

Sicherheitsforscher von Mandiant dokumentieren eine Zunahme von Angriffen auf Cloud-basierte Software-as-a-Service-Umgebungen durch Akteure im Umfeld von ShinyHunters. Die Angreifer setzen dabei auf ausgefeilte Social-Engineering-Methoden statt auf technische Schwachstellen. Der IT-Sicherheitsdienstleister stellt nun einen umfassenden Leitfaden mit konkreten Handlungsempfehlungen bereit.

Angriffsmuster ohne Produktschwachstellen

Die beobachteten Kampagnen nutzen keine Sicherheitslücken in den Produkten oder der Infrastruktur der SaaS-Anbieter selbst. Stattdessen setzen die Angreifer auf weiterentwickelte Voice-Phishing-Techniken und die systematische Kompromittierung von Zugangsdaten. Ihr Ziel: Single-Sign-On-Credentials zu erlangen und nicht autorisierte Geräte in die Multi-Faktor-Authentifizierungssysteme der Zielpersonen einzuschleusen.

Der Erfolg dieser Methode basiert auf der Effektivität von Social Engineering zur Umgehung von Identitätskontrollen. Mandiant liefert praxisorientierte Empfehlungen für Härtungsmaßnahmen, Protokollierung und Erkennung.

Sofortmaßnahmen bei aktiven Angriffen

Organisationen, die mit einem laufenden oder vermuteten Angriff konfrontiert sind, sollten folgende Schritte priorisieren:

Sitzungsverwaltung: Kompromittierte Benutzerkonten müssen identifiziert und deaktiviert werden. Sämtliche aktiven Sitzungstoken und OAuth-Autorisierungen auf Identitätsanbieter- und SaaS-Plattformen sind zu widerrufen.

Passwortverwaltung: Öffentlich zugängliche Self-Service-Portale zur Passwortzurücksetzung sollten temporär eingeschränkt oder deaktiviert werden. Für Administratorkonten muss die Self-Service-Option grundsätzlich gesperrt sein.

MFA-Kontrolle: Die Möglichkeit für Anwender, neue Geräte beim Identitätsanbieter zu registrieren oder anzumelden, ist vorübergehend zu unterbinden.

Fernzugriffssteuerung: VPN-Verbindungen und Virtual Desktop Infrastructure sollten eingeschränkt werden, insbesondere von nicht vertrauenswürdigen Endgeräten.

Geräterichtlinien: Der Zugriff auf Identitätsanbieter und SaaS-Anwendungen ist auf unternehmensverwaltete, konforme Geräte und bekannte vertrauenswürdige Standorte zu beschränken.

Notfallprotokoll: Der Service Desk muss über die erhöhte Gefährdungslage informiert werden und auf manuelle, hochsichere Verifizierungsverfahren für alle kontobezogenen Anfragen umstellen.

Verstärkte Helpdesk-Verifikation erforderlich

Da die Kampagnen gezielt auf menschliche Arbeitsabläufe durch Social Engineering und Vishing abzielen, empfiehlt Mandiant mehrschichtige Identitätsprüfungen für Support-Interaktionen. Besonders kritisch sind Anfragen zu Passwortzurücksetzungen oder MFA-Änderungen.

Als temporäre Maßnahme während erhöhter Bedrohungslage schlagen die Experten vor:

Live-Videoanrufe mit physischem amtlichen Ausweis neben dem Gesicht des Anrufers
Visuelle Überprüfung der Übereinstimmung durch Helpdesk-Mitarbeiter
Abgleich des Ausweises mit Unternehmensunterlagen
Out-of-Band-Genehmigung durch den direkten Vorgesetzten
Ablehnung von Anfragen, die ausschließlich auf Mitarbeiter-ID oder Sozialversicherungsnummer basieren
Rückrufprozedur unter bekannter Telefonnummer zur Vermeidung von Spoofing

Bei Drittanbieter-Anfragen gilt: Der Helpdesk darf unter keinen Umständen direkt Zugriff gewähren. Der eingehende Anruf muss beendet und unabhängig der zuständige Kundenbetreuer über hinterlegte Kontaktdaten kontaktiert werden.

Identitäts- und Zugriffsmanagement als Kernkomponente

Unternehmen sollten mehrschichtige Kontrollen implementieren:

Zugriffsbeschränkungen: Cloud-Identitätsanbieter, Cloud-Konsolen, SaaS-Anwendungen sowie Dokumenten- und Code-Repositories sollten nur von vertrauenswürdigen Ausgangspunkten erreichbar sein.

Lokale Konten: Standard-Zugangsdaten sind gemäß Passwortrichtlinie zu aktualisieren, die Verwendung lokaler Konten außerhalb des zentralisierten Identitätsanbieters zu minimieren.

MFA-Modernisierung: Der Wechsel zu phishing-resistenten Methoden wie FIDO2-Sicherheitsschlüsseln oder Passkeys wird dringend empfohlen. SMS, Telefonanrufe, Push-Benachrichtigungen und E-Mail-basierte Authentifizierung sollten entfernt werden.

Geräteverwaltung: Der Zugriff ist auf verwaltete und konforme Geräte zu beschränken. Gerätezustandsprüfungen über den Identitätsanbieter müssen implementiert werden.

Multi-Kontext-Kriterien: Neben der Identität sollten auch spezifische Geräte- und Standortattribute als Teil der Authentifizierung berücksichtigt werden.

Nicht-menschliche Identitäten schützen

Angreifer zielen systematisch auf nicht-menschliche Identitäten ab, da diese eingeschränkte Erkennungsmöglichkeiten bieten. Mandiant empfiehlt:

Vollständige Inventarisierung aller programmatischen Identitäten
Zentralisierung der Speicherung in Secrets Managern
Verhinderung der Einbettung von Zugangsdaten in Quellcode
Einschränkung der Authentifizierungs-IPs für programmatische Credentials
Umstellung auf Workload-Identitätsverbund zur Ablösung langlebiger statischer Zugangsdaten
Strikte Bereichs- und Ressourcenbindungen für API-Schlüssel

Plattformspezifische Sicherheitsmaßnahmen sollten ebenfalls umgesetzt werden. Für Okta bedeutet dies die Aktivierung von ThreatInsight, bei Microsoft Entra ID sind Conditional Access Policies zu implementieren, während Google Workspace-Nutzer Context-Aware Access-Ebenen einsetzen sollten.

Infrastruktur- und Cloud-Plattformen absichern

Der Schutz von Cloud-Konsolen und SaaS-Anwendungen erfordert plattformspezifische Sicherheitsvorkehrungen:

Google Cloud Platform: Sicherheitsperimeter mit VPC Service Controls konfigurieren, organisatorische Richtlinien wie „iam.disableServiceAccountKeyCreation“ durchsetzen, IAM-Bedingungen auf sensible Rollenbindungen anwenden.

Amazon Web Services: Service Control Policies auf Stammebene anwenden, Datenperimeter durch Ressourcensteuerungsrichtlinien definieren, Warnmeldungen für Erkundungsbefehle wie GetCallerIdentity implementieren.

Microsoft Azure: Conditional Access Policies durchsetzen, Just-In-Time-Zugriff über Privileged Identity Management verlangen, verwaltete Identitäten für Azure-Ressourcen erzwingen.

Quellcodeverwaltung: Single Sign-On mit SCIM durchsetzen, FIDO2/WebAuthn vorschreiben, Push Protection aktivieren, kryptografische Commit-Signierung verlangen.

Protokollierung als Grundlage der Erkennung

Moderne SaaS-Angriffe nutzen gültige Zugänge für Massenexporte und administrative Änderungen. Ohne ausreichende Transparenz ist eine Erkennung praktisch unmöglich.

Identitätsanbieter: Authentifizierungsereignisse, MFA-Lebenszyklusereignisse, administrative Identitätsereignisse sowie Änderungen an Richtlinien müssen erfasst werden.

Google Workspace: OAuth-Autorisierungen, Gmail-Auditprotokolle für Löschaktionen und Google Takeout-Auditprotokolle sind in das SIEM zu integrieren.

Salesforce: Neben Anmeldeprotokollen müssen Daten aus Event Monitoring erfasst werden: ApiEventStream, ReportEventStream und BulkApiResultEvent sind kritisch.

Microsoft 365: SharePoint-/OneDrive-Dateivorgänge inklusive UserAgent-Informationen sollten protokolliert werden, um PowerShell-basierte Zugriffsmuster zu identifizieren.

SaaS-Pivot-Plattformen: DocuSign und Atlassian-Audit-Protokolle müssen Authentifizierungsereignisse, administrative Änderungen, Massenaktivitäten und API-Nutzung erfassen.

Erkennungsregeln für typische Angriffsmuster

Mandiant stellt Erkennungslogiken bereit, die auf beobachtete Verhaltensmuster abzielen:

MFA-Manipulation: Registrierungen und Änderungen von MFA-Geräten, die unmittelbar nach einer Kontoübernahme auftreten, gelten als hochgradig zuverlässiger Indikator.

OAuth-Autorisierungen: Die Autorisierung spezifischer Anwendungen wie ToogleBox-Callback deutet auf Postfachmanipulationen hin.

Löschung von Sicherheits-E-Mails: Das gezielte Entfernen von Benachrichtigungen über MFA-Änderungen stellt kein normales E-Mail-Verhalten dar.

Google Takeout: Takeout-Exporte sind in Unternehmensumgebungen ungewöhnlich und repräsentieren einen direkten Datenexportpfad.

Netzwerkanomalie: Authentifizierungsversuche von IPs oder ASNs, die mit der Kampagne in Verbindung stehen, weisen keine legitimen geschäftlichen Überschneidungen auf.

PowerShell-Downloads: SharePoint/OneDrive-Downloads mit PowerShell-User-Agent, die Volumenschwellenwerte überschreiten, deuten auf skriptgesteuerten Datenabruf hin.

Aktivitäten außerhalb der Geschäftszeiten: Identitätsereignisse wie Anmeldungen oder MFA-Registrierungen zu ungewöhnlichen Zeiten sind verdächtig.

Mehrfach-MFA-Registrierungen: Wenn dieselbe Quell-IP innerhalb kurzer Zeit die MFA für mehrere Benutzer registriert, spiegelt dies eine bekannte Social-Engineering-Taktik wider.

Langfristige Verteidigungsstrategie

Die nachhaltige Abwehr erfordert den konsequenten Übergang zu phishing-resistenter Multi-Faktor-Authentifizierung. FIDO2-Sicherheitsschlüssel oder Passkeys bieten deutlich höhere Widerstandsfähigkeit gegen Social Engineering als Push-basierte oder SMS-Authentifizierung.

Zusätzlich sollten Organisationen ihre Mitarbeiter durch regelmäßige interne Vishing- und Phishing-Übungen schulen. Die Sensibilisierung für die Nichtweitergabe von Passwörtern und erhöhte Vorsicht bei unangekündigten Kontaktaufnahmen bildet eine wichtige Verteidigungslinie. Bei Unsicherheit über die Identität eines Anrufers sollten Mitarbeiter die Kommunikation beenden und sich an bekannte Support-Kanäle wenden.

Die Kombination aus technischen Kontrollen, umfassender Protokollierung, effektiven Erkennungsmechanismen und geschulten Mitarbeitern bildet nach Mandiants Einschätzung die beste Verteidigung gegen die weiterentwickelten Social-Engineering-Kampagnen im Zusammenhang mit ShinyHunters-Aktivitäten.

„Die in diesem Beitrag bereitgestellten Informationen wurden sorgfältig recherchiert, erheben jedoch keinen Anspruch auf Vollständigkeit oder absolute Richtigkeit. Sie dienen ausschließlich der allgemeinen Orientierung und ersetzen keine professionelle Beratung. Die Redaktion übernimmt keine Haftung für eventuelle Fehler, Auslassungen oder Folgen, die aus der Nutzung der Informationen entstehen.“

Mehr erfahren