No exploit. No malware. No patch to apply. A business communications provider serving hundreds of thousands of companies was compromised through a conversation — and the stolen contact data is now ideal ammunition for the next round of the same attack.
In July 2026, RingCentral — a cloud provider of business phone, messaging, and video services — was breached through what the company described as a sophisticated social engineering campaign. The extortion group ShinyHunters claimed responsibility, demanded payment, and when RingCentral declined, published the data.
The details that follow matter because of what was taken. Not source code, not credentials, not call recordings — a contact list. Names, email addresses, phone numbers, and physical addresses for roughly 1.6 million people. For a group whose primary method is phoning employees and talking them into granting access, that is not a trophy. It is a targeting database.
One correction to how this incident is sometimes described: this is a single breach, not a series of them. But it sits inside a campaign that has now touched a very large number of organizations, and that context is essential to understanding it.
What happened
The timeline, drawn from RingCentral's own disclosure and public reporting:
- July 2026 — Attackers gained access to RingCentral systems. The company attributes the intrusion to a 'sophisticated social engineering campaign' rather than a technical vulnerability.
- 27 July — ShinyHunters added RingCentral to its Tor-hosted leak site, claiming to have stolen more than 623 GB of data, with a payment deadline of 30 July.
- 28 July — RingCentral publicly disclosed the incident via a security bulletin on its trust center. The company said it stopped the unauthorized activity on detection, engaged an external forensic firm, and had seen no further unauthorized activity following remediation.
- 3 August — RingCentral did not pay. ShinyHunters published a compressed 280 GB archive of files it claimed to have taken.
- 13 August — Have I Been Pwned analyzed the published archive and added it to its breach database, counting approximately 1.6 million unique email addresses, each accompanied by a name, phone number, and physical address.
RingCentral's position is that only a limited portion of its customer base was affected, that those individuals were contacted directly, that anyone not contacted is not affected, and that the core platform was untouched with services operating normally throughout.
An important qualification: RingCentral has not confirmed the attackers' claims, has not publicly named ShinyHunters, and has not confirmed the 1.6 million figure. That number comes from an independent analysis of the leaked archive by Have I Been Pwned, not from the company. As of mid-August the company had also not disclosed how many individuals it notified — so the gap between "a limited portion of customers" and 1.6 million records remains unexplained publicly.
How the attack works
RingCentral has not said which specific technique was used against it, so what follows describes the playbook this group is documented as using, not a confirmed account of this intrusion.
❌ Vishing — voice phishing. An attacker telephones an employee, usually posing as internal IT support or a helpdesk technician. There is no malicious attachment and no credential-stuffing. The objective is to talk a real person into performing an action that grants access.
❌ The OAuth consent trick. In the campaign Microsoft documented running from mid-2025 into mid-2026, callers walked employees through their own platform's legitimate consent screen and had them authorize an attacker-controlled application dressed up as a genuine administrative tool. Once consent is granted, the application can query data through the API as that user — without re-triggering multi-factor authentication, because nothing is being "logged into." The trust was granted, not stolen.
❌ Device code phishing. A related method abuses the OAuth device authorization flow — the mechanism designed for devices without a keyboard, such as smart TVs. The victim is guided into entering a code on the identity provider's real verification page, which hands the attacker an authenticated session.
❌ Persistence and concealment. Reported tradecraft includes enrolling attacker-controlled MFA devices to retain access, deleting the security notification emails that would have alerted the victim, enumerating everything reachable through single sign-on to map the blast radius, and routing activity through commercial VPNs and residential proxies to blend in.
Two terms, in plain language:
- OAuth consent — the "Allow this app to access your account?" prompt. Approving it grants an application ongoing permission to act on your behalf.
- Blast radius — everything a single compromised identity can reach. In a modern SSO environment, one account often unlocks dozens of connected systems.
The critical property of this whole class of attack: there is nothing to patch. No vulnerability was exploited, so no security update closes the door.
Why it matters
The stolen data is the raw material for the next attack. ShinyHunters' method depends on calling employees and sounding credible. A verified list of names, direct phone numbers, email addresses, and home addresses tied to a business communications platform is precisely what makes a cold call convincing. Expect this data to surface in vishing and business email compromise attempts against the affected individuals and their employers.
A precedent exists for exactly this dynamic. When the same group breached Aura — a company selling identity theft protection — in March 2026, researchers noted the particular cruelty of the outcome: the victims were people who had specifically paid for protection against this. The RingCentral case has a similar shape. Contact data taken from a communications provider feeds attacks conducted over communications channels.
Refusing to pay is defensible, and it has consequences. RingCentral did not pay, and the data was published. That is the trade-off organizations face: paying funds the ecosystem and buys an unenforceable promise, while refusing means the data becomes permanently public. Neither branch is a good outcome, which is why the decision belongs in a pre-agreed playbook rather than in the middle of a crisis.
Your security perimeter includes your vendors' helpdesks. Nothing any RingCentral customer did wrong caused this. The exposure came through a supplier relationship — which is why third-party risk management cannot stop at a completed questionnaire.
Who is affected
Directly: the roughly 1.6 million individuals whose records appear in the published archive. RingCentral has said affected customers were contacted individually and that those not contacted are unaffected — though that guidance is difficult to reconcile with the independently counted volume of leaked records, so it should not be treated as a guarantee of safety.
Indirectly: the organizations those people work for. RingCentral serves a very large business customer base, and its platform is used for business calling, messaging, and meetings. Employee contact details from that environment are directly useful against the employer.
In terms of data categories: the leaked records, as catalogued by Have I Been Pwned, comprise names, email addresses, phone numbers, and physical addresses. RingCentral has stated the core platform was not impacted. Public reporting has not indicated that passwords, payment data, or call and message content were part of the published set — but absence of reporting is not the same as confirmation, and organizations should treat the full scope as not yet settled.
What attackers can do
- Highly credible vishing. A caller who already knows your name, your employer, your direct line, and your home address clears the plausibility bar that most staff use to judge a suspicious call.
- Business email compromise. Verified corporate email addresses paired with names and phone numbers support convincing impersonation of colleagues, executives, or suppliers.
- Multi-channel pressure. This group's documented escalation tactics include SMS harassment of employees and denial-of-service attacks against victim websites.
- Identity fraud and account recovery abuse. Full name, address, phone number, and email is the standard bundle used to answer identity verification questions and hijack account recovery flows.
- Secondary extortion. Individuals named in leaked datasets have previously been approached directly with their own extortion demands, separately from the original victim organization.
What organizations and individuals should do
If your organization uses RingCentral:
- Confirm whether you were notified, through your account team rather than by acting on an inbound email about the breach — breach notifications themselves are a favoured phishing pretext.
- Warn affected staff specifically, telling them what the attackers now know about them. Generic "stay vigilant" advice does not work; "someone may call you by name, quoting your direct line and home address, claiming to be IT" does.
- Review OAuth and connected-app grants across your own SaaS estate. Look for applications with broad API scopes that no one recognizes or can justify, and revoke them.
- Audit MFA enrolment events for devices added by anyone other than the account owner, and alert on new enrolments as a matter of routine.
- Check for suppressed alerting — mailbox rules or third-party apps that delete or divert security notification emails.
Harden the human path, because that is the attack surface here: - Establish an out-of-band verification rule for helpdesk interactions. No one grants access, approves a consent prompt, resets MFA, or reads out a code because of an inbound phone call. Verification happens through a known internal channel, initiated by the employee.
- Train staff on the consent screen itself. Most awareness programmes cover suspicious links and attachments and never mention "Allow access?" prompts. That is the gap this campaign walks through.
- Restrict who can authorize third-party applications so that consent requires administrative approval rather than individual user discretion.
- Make it safe and fast to report a suspicious call. The employees who get socially engineered are usually trying to be helpful. If reporting a mistake is embarrassing or slow, you lose your best detection signal.
- Rehearse the extortion decision before you need it — who decides, on what criteria, with which regulators and counsel involved.
For individuals in the leaked data: - Treat unexpected calls, texts, and emails referencing your employer or accounts as untrusted, regardless of what the caller appears to know about you. Hang up and call back on a number you already have.
- Check exposure through Have I Been Pwned, and enable phishing-resistant multi-factor authentication (a passkey or hardware key) wherever it is offered.
- Be alert to account recovery attempts and to "we can help you remove your leaked data" follow-on scams.
Final thoughts
Every technical control RingCentral had in place was, as far as anyone has reported, working. No vulnerability was exploited. There is no CVE to track and no update to deploy. The intrusion ran on a phone call.
That is the uncomfortable centre of this incident, and it is why the RingCentral breach deserves more attention than its record count alone would suggest. Attacks that abuse legitimate trust — a consent prompt, a helpdesk convention, an employee's instinct to be useful — are invisible to vulnerability management. They do not appear in a scan. They are defeated by process and verification habits, not by tooling.
Contact data stolen through social engineering becomes the fuel for better social engineering. The 1.6 million people in that archive are now easier to deceive than they were in June, and their employers are the eventual target.
