Was RingCentral tatsächlich bestätigt hat

RingCentrals eigenes Sicherheitsbulletin im Trust Center, datiert auf den 28. Juli 2026 und als HOCH eingestuft, besagt, das Unternehmen habe "kürzlich entdeckt, dass es Ziel einer ausgeklügelten Social-Engineering-Kampagne war" und "umgehend Schritte unternommen, um die unbefugte Aktivität zu stoppen", mit Unterstützung einer externen Forensik-Firma. Das Bulletin ergänzt: "Dieser Vorfall hat Daten eines begrenzten Teils der RingCentral-Kunden betroffen, und wir kontaktieren betroffene Kunden direkt. Wenn Sie nicht von RingCentral kontaktiert wurden, sind Sie nicht betroffen."

Die Erpressergruppe ShinyHunters beanspruchte den Angriff bereits einen Tag zuvor, am 27. Juli 2026, für sich und sprach von 623 GB entwendeter Daten, dann veröffentlichte sie ein 280-GB-Archiv, nachdem RingCentral nicht zahlte. Have I Been Pwned verarbeitete dieses Archiv und nahm es am 13. August 2026 in seine Datenbank auf: rund 1,6 Millionen eindeutige E-Mail-Adressen, dazu Namen, Telefonnummern und Anschriften. RingCentral stellt ausdrücklich klar, dass der Vorfall RingEX, RingCentral Contact Center, RingCX oder andere Kerndienste nicht erreicht hat, die "weiterhin ohne Unterbrechung" liefen.

Ein Muster bei Lieferanten, nicht bei Opfern

ShinyHunters hat 2026 dasselbe Vorgehen bei einem SaaS-Anbieter nach dem anderen wiederholt: Salesforce-Kundeninstanzen, bei Snowflake gehostete Kundendaten und Oracle-PeopleSoft-Installationen, wobei die Gruppe selbst die Gesamtbeute über alle Kampagnen hinweg auf mehr als 1,5 Milliarden Datensätze beziffert. RingCentral ist der jüngste Name auf dieser Liste, und die Methode, die das Unternehmen selbst beschreibt, eine Person wurde überredet, Zugang zu gewähren, statt dass ein Angreifer eine Schwachstelle finden musste, passt zu einem breiteren Trend des Jahres 2026: Vishing- und Social-Engineering-Kampagnen, die gegen Mitarbeiter mit privilegiertem Zugang beim Anbieter erfolgreich sind, nicht beim Kunden.

Dieser Unterschied ist entscheidend für jeden, der RingCentral als Lieferanten bewertet. Ein Kunde kann seine eigene Software patchen und eigene Zugangsdaten rotieren, hat aber keine Möglichkeit zu prüfen oder auch nur zu sehen, wie widerstandsfähig das Support- und Admin-Personal eines Anbieters gegenüber einem überzeugenden Anruf tatsächlich ist. Ziel war hier die Belegschaft von RingCentral, nicht dessen Code.

Die Lücke im Lieferantenregister

Finanzunternehmen, die unter den Digital Operational Resilience Act der EU fallen, müssen nach den DORA-Artikeln 28 bis 30 ein Informationsregister über jeden IKT-Drittanbieter führen und das Risiko bewerten, das jeder Einzelne für die eigene Resilienz darstellt. Wesentliche und wichtige Einrichtungen nach der NIS2-Richtlinie tragen nach Artikel 21 eine parallele Pflicht, das Cybersicherheitsrisiko der Lieferkette zu steuern, einschließlich der Sicherheitspraktiken ihrer direkten Zulieferer. Beide Regelwerke setzen voraus, dass das regulierte Unternehmen von einem Anbieter genug Details erhalten kann, um dessen Risiko überhaupt zu bewerten.

RingCentrals Bulletin nennt weder die Rolle des betroffenen Mitarbeiters noch das interne System, das der Angreifer erreichte, noch welche Kontrolle, Multi-Faktor-Authentifizierung, Rückruf-Verifizierung, Identitätsprüfung am Helpdesk, versagte, sodass aus einem Telefonanruf ein Datenleck wurde. Eine deutsche Bank, eine niederländische Klinikgruppe oder ein britischer Versicherer, der RingCentral im IKT-Drittanbieterregister führt, hat für diesen Eintrag nichts Konkretes hinzuzufügen außer der Tatsache, dass ein Vorfall stattfand. Der übliche Lieferanten-Sicherheitsfragebogen, ein SOC-2-Testat, ein Verschlüsselungszertifikat, eine Pentest-Zusammenfassung, prüft genau jene technischen Kontrollen, die bei einem Vorfall, der mit einem Gespräch begann und endete, nie zum Einsatz kamen.

Was ein Betreiber tatsächlich ändern sollte

Die praktische Abhilfe ist nicht ein weiteres Blatt Verschlüsselungspapierkram. Betreiber, die auf RingCentral oder einen anderen UCaaS- oder CCaaS-Anbieter für regulierte Kunden setzen, sollten den Anbieter direkt fragen, ob er eigene simulierte Social-Engineering-Tests gegen Support- und Admin-Personal durchführt, und die Antwort, oder die Verweigerung einer Antwort, selbst als Eintrag im eigenen Risikoregister behandeln.

Vertragsverlängerungen nach dieser Offenlegung sind der richtige Zeitpunkt für eine konkrete Klausel: ein Recht auf eine technische Nachanalyse, keine Marketingaussage, innerhalb einer festen Frist nach jedem bestätigten Vorfall. Ohne diese Klausel wird die nächste Sicherheitsmeldung eines Anbieters genau wie diese hier klingen, formal vollständig und konform, aber nutzlos für das eine Dokument, das Risikoregister, das die Regulierung von einem Betreiber tatsächlich aktuell verlangt.

Weiterlesen: 45.601 Lücken, 171 werden wirklich genutzt  |  Eine Nachricht erreichte die SSH-Schlüssel