Vor wenigen Tagen gab der Bildungs- und Verlagsriese McGraw Hill einen Cybervorfall bekannt, an dem die berüchtigte Threat-Actor-Gruppe ShinyHunters beteiligt war. Der Vorfall begann als ein Incident mit "eingeschränktem Zugriff" und eskalierte nach Unternehmensangaben schnell in seinem Ausmaß, als nahezu 13 Millionen Datensätze im Dark Web auftauchten und von Datenhändlern aufgenommen wurden. Während McGraw Hill erklärt hat, dass ShinyHunters eine Fehlkonfiguration in der kompromittierten Salesforce-Umgebung ausnutzten, um den Angriff auszuführen, waren andere Salesforce-Konten, Courseware, Kundendatenbanken oder interne Systeme des Unternehmens nicht betroffen.

Ein Datenverstoß bleibt ein Datenverstoß. Daten wurden einschließlich Zugangsdaten offengelegt, und im Bereich Identity- und Access-Governance auf der Anwendungsschicht ist tatsächlich etwas schiefgelaufen. In diesem Blogbeitrag untersuchen wir diesen Vorfall und zeigen Möglichkeiten auf, wie sich eine Wiederholung verhindern lässt.

Bevor wir in die Tiefenanalyse einsteigen, vergessen Sie bitte nicht, unseren vorherigen Blogbeitrag mit dem Titel Top 15 challenges in CPS protection and how OT teams can address them hier anzusehen.  

Verlauf des Sicherheitsvorfalls und Angriffspfad

Der Vorfall wurde am 14. April 2026 öffentlich bekannt. Dies fiel mit einer von ShinyHunters gesetzten Frist für die Erpressung zusammen.

Die Ursache: die Falle der "Experience Cloud"

Der primäre Angriffsvektor war kein Zero-Day-Exploit. Stattdessen handelte es sich um eine Fehlkonfiguration in Salesforce Experience Cloud (ehemals Community Cloud). Unternehmen nutzen diese Funktionen, um öffentliche oder partnerseitige Portale für Kunden und Partner bereitzustellen.

• Gastbenutzer-Berechtigungen: Standardmäßig hat Salesforce die Berechtigungen für Gastbenutzer in den letzten Jahren verschärft. Allerdings bleiben ältere Konfigurationen häufig bestehen. In diesem Fall scheint es so, als seien Gastbenutzerprofilen übermäßige Rechte in Form von "Read"-Zugriff auf interne Objekte eingeräumt worden.

·  Die Ausnutzung von "Aura": Es wurde beobachtet, dass ShinyHunters automatisierte Scanner einsetzen, um Salesforce-Aura-Komponenten abzufragen und Schwachstellen zu identifizieren. Durch das Ansprechen bestimmter nicht authentifizierter Endpunkte können sie das System "fuzzing"-artig testen bzw. genauer gesagt:

o   Missbrauch von /s/sfsites/aura- oder /aura-Endpunkten

o   Aufruf serverseitiger Apex-Controller

o   Ausnutzung falsch exponierter @AuraEnabled-Methoden

o   in Kombination mit dem Gastbenutzer-Kontext

( um Datensätze auszulesen, die nicht ordnungsgemäß durch Object Permissions (CRUD), FLS und das Sharing Model abgesichert sind.)

Die Datenabweichung

Unsere Hypothese: Die inkonsistente Datenstruktur in den geleakten Dateien deutet darauf hin, dass die Angreifer nicht einfach eine einzelne Datenbank exportiert haben; stattdessen haben sie Daten über mehrere Salesforce-Objekte hinweg über einen längeren Zeitraum hinweg "gescraped". Dies spricht für eine Low-and-Slow-/langandauernde Exfiltrationsstrategie, die herkömmliche volumenbasierte Alarmtriggers umgangen hat.

ShinyHunters waren eine Zeit lang im System und haben Daten langsam exfiltriert.

Forensische Tiefenanalyse: "Begrenzt" vs. "tödlich"

McGraw Hill stellte schnell klar, dass Sozialversicherungsnummern und Finanzdaten nicht von dem Vorfall betroffen waren. Auch wenn diese Aussage technisch korrekt ist, kann sie als Versuch gewertet werden, die volle Tragweite des Vorfalls herunterzuspielen. Selbst wenn die kompromittierten Daten keine SSNs enthalten, werden Hacker und Hacktivisten die geleakten Zugangsdaten nutzen, um Zugriff auf andere Bereiche der McGraw-Hill-Infrastruktur zu erlangen.

Auch wenn finanzielle und hochsensible Identifikatoren in diesem Vorfall möglicherweise nicht offengelegt wurden, bleibt das Risiko eines schweren Angriffs ausreichend hoch, um Aufmerksamkeit und Maßnahmen zu rechtfertigen. E-Mail-Adressen und zugehörige Metadaten werden routinemäßig eingesetzt für:

• Credential-Stuffing-Angriffe

• Phishing-Kampagnen

• Identitätskorrelation mithilfe von OSINT-Datensätzen

Mit der Zeit ermöglichen solche Datensätze Angreifern, Verhaltens- und Organisationsidentitätsgraphen aufzubauen und so die Wahrscheinlichkeit eines erfolgreichen Kompromittierens in zukünftigen Kampagnen zu erhöhen. Wir können sogar ein weiteres Szenario in Betracht ziehen, das sich daraus ergeben könnte.

Jedes Mal, wenn Zugangsdaten offengelegt werden, speisen Hacker die Daten in SLMs ein, um auf individueller Ebene Passwortmuster durch Passwortmodellierung (oder sogar Credential Stuffing) vorherzusagen. Über einen gewissen Zeitraum hinweg, wenn einige der Betroffenen, deren Daten kompromittiert wurden, in höhere Positionen aufsteigen (entweder im selben Unternehmen oder anderswo), stehen genügend Daten zur Verfügung, um zukünftige Passwörter zu erraten. Das Risiko eines schwerwiegenden Vorfalls steigt mit jedem solchen Ereignis. Solche Vorfälle sollten daher als Gelegenheit verstanden werden, solche Muster zu durchbrechen und für mehr Unvorhersehbarkeit zu sorgen.   

Der Threat Actor: ShinyHunters

Vielleicht erinnern Sie sich an ShinyHunters aus diesem Vorfall. Sie haben sich gewissermaßen weiterentwickelt. Sie machen sich nicht mehr die Mühe mit komplexer Verschlüsselung (Ransomware) und dem Verkauf von Decryptors. Sie sind zu reinen Erpressern geworden (so rein, wie es nur geht).  

ShinyHunters TTPs

• Asset Discovery

  • Scannen nach exponierten Salesforce-Experience-Cloud-Domains (*.force.com, *.site.com)

• Endpoint-Enumeration

  • Zielgerichtet auf:

    • /s/

    • /aura

  • Identifizierung aufrufbarer serverseitiger Komponenten

• Privilegienmissbrauch

  • Betrieb innerhalb von:

    • Gastbenutzer-Kontext

    • Fehlkonfigurierten Standardprofilen

• Datenextraktion

  • Automatisiertes Harvesting über skriptbasierte Anfragen

  • Fokus auf hochwertige Objekte (Kontakte, Benutzer, Konten)

• Erpressungs-Workflow

  • Veröffentlichung von Leak-Samples

  • Direkte Verhandlung oder Weiterverkauf an Affiliates

Präventive Maßnahmen: Den Tresor schließen

Um zu verhindern, dass Ihre Organisation Opfer dieser Gruppe wird, sollten Sie diese "Zero Trust"-Salesforce-Konfigurationen umgehend umsetzen:

Strategische Härtung

• "Public Access" standardmäßig deaktivieren: Prüfen Sie jede Salesforce Site und jedes Experience-Cloud-Portal. Stellen Sie sicher, dass "Public Access" nur für Seiten aktiviert ist, die dies zwingend erfordern.

• Die "Guest User"-Sperre: Verwenden Sie die Guest User Sharing Rules, um sicherzustellen, dass Gastbenutzer standardmäßig niemals auf Datensätze zugreifen können. Sie sollten nur das sehen, was ausdrücklich über "Secure Guest User Sharing"-Regeln freigegeben wurde.

• API-Sicherheit: Beschränken Sie den API-Zugriff auf bestimmte IP-Bereiche und erzwingen Sie Mutual TLS (mTLS) für sensible Integrationen.

• Prüfen Sie alle öffentlich zugänglichen Sites und Berechtigungen. Entziehen Sie nicht mehr benötigte Berechtigungen  

• Veranlassen Sie die Änderung der Zugangsdaten für alle externen E-Mail-IDs und fordern Sie anschließend alle internen Mitarbeitenden auf, ihre Zugangsdaten zu ändern. Die neuen Passwörter sollten keine Muster, Buchstaben oder Sonderzeichen der alten Passwörter enthalten

·       Prüfen Sie Aura-fähige Apex-Klassen

·       Identifizieren Sie alle @AuraEnabled-Methoden

·       Stellen Sie sicher:

o   Authentifizierungsprüfungen

o   Eingabevalidierung

o   Keine direkte Exponierung von Objekten

·       Härtung von Experience Cloud

·       Prüfen Sie alle Sites:

o   Nicht verwendete Endpunkte entfernen

o   Öffentlichen Zugriff deaktivieren, wo dies nicht erforderlich ist

·       Governance verbundener Apps

·       Durchsetzen:

o   IP Relaxation = Restricted

o   High Assurance Sessions

o   Minimierung des OAuth-Scopes 

Taktische Kontrollen

• Salesforce Shield (Event Monitoring): Aktivieren Sie Shield, um "Report Export"- und "Bulk API"-Ereignisse zu verfolgen. Wenn ein Gastbenutzer (oder irgendein Benutzer) plötzlich auf mehrere Datensätze zugreift, sollte das System idealerweise die Sitzung automatisch unter Quarantäne stellen und eine mehrstufige Warnung auslösen. Gemeint sind Transaction-Security-Policies, Event Monitoring und benutzerdefinierte Regeln, die mehrere Szenarien abdecken.

• Field-Level Security (FLS): Auch wenn ein Benutzer ein Objekt sehen kann, sollte er nicht jedes Feld sehen. Maskieren Sie PII-Felder für alle außer den wesentlichsten administrativen Rollen.

• Überwachen:

·  URI-Zugriffsmuster (/aura, /s/)

·   API-Ereignisspitzen

·   Berichtsexporte

KPIs: So verfolgen Sie Ihre Exposition

Was Sie nicht messen, können Sie nicht steuern. Verfolgen Sie diese Kennzahlen monatlich:

• Anzahl der Gastbenutzerberechtigungen: Anzahl der Objekte, auf die authentifizierungslose "Guest"-Profile zugreifen können. (Ziel: 0 für sensible Objekte).

• Konfigurationsdrift-Rate: Wie häufig werden nach einem Bereitstellungszyklus "permissive" Einstellungen eingeführt.

• Mean Time to Detection (MTTD) für Bulk-Exporte: Wie viele Minuten zwischen einer Massenabfrage von Daten und einem SOC-Alarm vergehen.

• Prozentsatz der Benutzer mit MFA: Stellen Sie sicher, dass alle internen und Partner-Benutzer durch Multi-Faktor-Authentifizierung abgesichert sind.

Der McGraw-Hill-Vorfall ist ein klassischer Fall von SaaS Sprawl. Wenn ein Unternehmen schnell digitale Lernplattformen bereitstellt, bleibt die Sicherheit oft hinter dem Komfort zurück.

Dies war kein Einbruch in die Infrastruktur. Es war ein Versagen der Konfigurationsdisziplin in einer SaaS-Umgebung. ShinyHunters sind nicht "eingebrochen". Stattdessen gingen sie durch eine Tür, die der "User Experience" zuliebe nur angelehnt war. Der Angreifer hat keine Schwachstelle im herkömmlichen Sinn ausgenutzt. Sie bewegten sich innerhalb der Grenzen dessen, was das System im Wesentlichen erlaubte.

Für die 13,5 Millionen Personen, deren Daten nun im Umlauf sind, ist die Lehre klar: In der Cloud ist die Konfiguration ein wesentliches Sicherheitselement.

Halten Sie Ihre Protokolle eng und Ihre Berechtigungen noch enger.

Zusätzliche Ressourcen     

Umfassender Leitfaden zu Network Detection and Response NDR im Jahr 2026 hier 
Ein herunterladbarer Bericht zum Stryker-Cybervorfall hier     
Remediation Guides hier   
OT Security Best Practices und Leitfaden zur Risikobewertung hier  
IEC 62443-basierte Checkliste zur OT/ICS-Risikobewertung für den Bereich Lebensmittel- und Getränkeherstellung hier