Hvad RingCentral faktisk har bekræftet
RingCentrals eget sikkerhedsbulletin i Trust Center, dateret 28. juli 2026 og vurderet HØJ, oplyser, at selskabet "for nylig opdagede, at det var mål for en sofistikeret social engineering-kampagne" og "øjeblikkeligt tog skridt til at stoppe den uautoriserede aktivitet" med hjælp fra et eksternt retsteknisk firma. Bulletinen tilføjer: "denne hændelse har berørt data for en begrænset del af RingCentrals kunder, og vi kommunikerer direkte med berørte kunder. Hvis du ikke er blevet kontaktet af RingCentral, er du ikke berørt."
Afpresningsgruppen ShinyHunters tog allerede ansvaret for angrebet dagen før, den 27. juli 2026, og hævdede at have stjålet 623 GB data, hvorefter gruppen offentliggjorde et 280 GB-arkiv, efter RingCentral afviste at betale. Have I Been Pwned behandlede dette arkiv og tilføjede det til sin database den 13. august 2026: omkring 1,6 millioner unikke e-mailadresser, sammen med navne, telefonnumre og fysiske adresser. RingCentral har været tydelig om, at bruddet ikke nåede RingEX, RingCentral Contact Center, RingCX eller andre kernetjenester, som ifølge selskabet "fortsætter med at fungere uden afbrydelser."
Et mønster hos leverandører, ikke hos ofre
ShinyHunters har i 2026 gentaget den samme fremgangsmåde mod den ene SaaS-leverandør efter den anden: Salesforce-kundeinstanser, kundedata hostet hos Snowflake og Oracle PeopleSoft-implementeringer, hvor gruppen selv opgør det samlede udbytte af sine kampagner til over 1,5 milliarder registreringer. RingCentral er det seneste navn på den liste, og metoden, som selskabet selv beskriver, en person overtalt til at give adgang, i stedet for en fejl en angriber skulle finde, passer til en bredere 2026-tendens: vishing- og social engineering-kampagner, der lykkes mod medarbejdere med privilegeret adgang hos leverandøren, ikke hos kunden.
Den forskel betyder noget for enhver, der vurderer RingCentral som leverandør. En kunde kan patche sin egen software og udskifte sine egne loginoplysninger, men har ingen måde at teste, eller blot se, hvor godt en leverandørs eget support- og administrationspersonale modstår et overbevisende opkald. Målet her var RingCentrals medarbejdere, ikke selskabets kode.
Hullet i leverandørrisikoregistret
Finansielle enheder under EU's forordning om digital operationel modstandsdygtighed skal ifølge DORA-artikel 28 til 30 føre et informationsregister over hver IKT-tredjepartsudbyder og vurdere den risiko, hver enkelt udgør for enhedens egen modstandsdygtighed. Væsentlige og vigtige enheder under NIS2-direktivet har en parallel forpligtelse i artikel 21 til at styre forsyningskædens cybersikkerhedsrisiko, herunder sikkerhedspraksis hos deres direkte leverandører. Begge regelsæt forudsætter, at den regulerede enhed kan få nok detaljer fra en leverandør til reelt at vurdere dennes risiko.
RingCentrals bulletin nævner hverken den berørte medarbejders rolle, det interne system angriberen nåede, eller hvilken kontrol, multifaktorautentifikation, tilbagekaldsverifikation, identitetstjek hos support, der svigtede, så et telefonopkald endte som et brud. En tysk bank, en hollandsk hospitalskoncern eller et britisk forsikringsselskab, der har RingCentral opført i sit IKT-tredjepartsregister, har intet konkret at tilføje til den post ud over, at der skete en hændelse. Det sædvanlige leverandørsikkerhedsspørgeskema, en SOC 2-erklæring, et certifikat for kryptering af data i hvile, et pentest-resumé, tester præcis de tekniske kontroller, der aldrig var i spil i en hændelse, der begyndte og sluttede med en samtale.
Hvad en operatør reelt bør ændre
Den praktiske løsning er ikke endnu et lag krypteringspapirarbejde. Operatører, der er afhængige af RingCentral, eller enhver anden UCaaS- eller CCaaS-leverandør, der betjener regulerede kunder, bør spørge leverandøren direkte, om den selv gennemfører simulerede social engineering-tests mod support- og administrationspersonale, og behandle svaret, eller afvisningen af at svare, som en post i sit eget risikoregister.
Kontraktfornyelser efter denne offentliggørelse er tidspunktet til at tilføje en konkret klausul: en ret til en teknisk efteranalyse, ikke en markedsføringsudtalelse, inden for en fast frist efter enhver bekræftet hændelse. Uden den klausul vil den næste leverandørs bruddmeddelelse lyde præcis som denne, komplet og compliant på papiret, men ubrugelig for det ene dokument, risikoregistret, som reguleringen faktisk kræver, at en operatør holder opdateret.
Læs videre: 45.601 huller, 171 bliver faktisk brugt | En enkelt besked nåede SSH-nøglerne
