Honestly, this one feels like a wake-up call wrapped in two different stories that rhyme: first, Google confirmed a breach of one of its corporate Salesforce instances tied to Google Ads prospect data; then, Google Cloud warned developers about “dangling bucket” takeovers that let attackers hijack deleted storage names and push malware or grab data. Google says the Salesforce theft happened in June and was pulled off by a financially motivated group it tracks as UNC6040, widely linked to ShinyHunters, using convincing voice‑phishing to get employees to authorize a malicious connected app and exfiltrate business contacts and notes. The stolen dataset was described as basic business info (names, emails, phone numbers, notes), not payment data or Ads credentials, but it’s exactly the sort of material criminals use to craft believable extortion and social‑engineering campaigns later on.

How attackers pulled this off (and why it keeps working)

The crew’s playbook is depressingly effective: impersonate IT on the phone, push a modified Salesforce Data Loader or OAuth connected app approval, and then pull down CRM records at speed. Google notes the actor is evolving toward custom scripts and TOR/VPN infrastructure, and may delay extortion for months, which keeps victims guessing while data gets monetized in the background. Reports attribute a 20‑BTC demand to ShinyHunters, later dismissed as “for the lulz,” but the real pressure point is a likely data leak site to name‑and‑shame victims — a tactic that raises stakes even when the data isn’t “sensitive” in the strict sense.

The second shoe: Cloud “dangling buckets” are a soft target

Separately, Google Cloud warned that deleting a storage bucket without purging all references leaves a “dangling” name attackers can reclaim to serve malware or siphon data from users and apps that still point to it. The fix isn’t glamorous but it’s critical: decommission deliberately, audit who/what still hits the bucket, wait at least a week to cover weekly jobs, scan logs and code for stale references, and — if needed — recreate the bucket name in a locked‑down project to prevent hijack. It’s a supply‑chain‑style risk hiding in plain sight: once a bucket name is trusted by code, CDNs, or documentation, takeover can quietly turn into mass drive‑by compromise.

What’s not being discussed enough

  • CRM as crown‑jewel metadata: Even “basic” business contacts plus seller notes are fuel for precision vishing, BEC, and cross‑tenant pivoting; treat CRM export controls like payment data controls, not like marketing lists.

  • OAuth sprawl and “approved app” debt: The weakest link is often a helpful employee approving one powerful connected app under time pressure; least‑privilege and allowlisting for OAuth apps deserve the same rigor as VPN or SSO policy.

  • Extortion timelines: Months‑delayed shakedowns reduce defenders’ ability to map blast radius and notify downstream partners; plan playbooks that assume staggered pressure campaigns, not a single event.

Business implications and hidden risks

For enterprises, the immediate risk isn’t only regulatory exposure — it’s surge‑priced fraud: more convincing lures to sales ops, partner managers, and SMB customers that trigger account takeovers, fake renewals, or invoice fraud. On cloud ops, a dangling‑bucket incident can become a reputational event fast if hijacked names serve malware to end users; that’s a brand and legal problem, not just a Sev2 ticket. Expect insurers to ask harder questions about CRM export monitoring, OAuth governance, and decommission runbooks; premiums and exclusions follow where repeatable kill chains exist.

Practical steps that actually move the needle

  • Lock down Salesforce data paths: remove “API Enabled” for non‑export roles, allowlist connected apps, and restrict “Customize Application” to few admins; monitor large exports and anomalous OAuth grants.

  • Train for vishing, not just phishing: script “pause‑and‑verify” for any IT request to approve an app or share an MFA code; socialize internal callback numbers and challenge phrases.

  • Shrink OAuth blast radius: inventory connected apps, kill unused ones, and enforce least‑privilege scopes with approval workflows and time‑bound access.

  • Bake decommission discipline: adopt a one‑week quiet period, code/reference scans, and reclaim risky names before deletion; treat bucket names like domains in change control.

  • Assume delayed extortion: pre‑stage comms, legal, and customer‑contact playbooks for staggered threats and potential data‑leak‑site pressure.

Why this matters now

This isn’t a one‑off. Multiple high‑profile Salesforce thefts, plus ongoing OAuth abuse and name‑hijack attacks, suggest a durable economics‑driven shift: criminals target business metadata and trust anchors because they scale and convert into cash with less heat than smashing vaults. The lesson is simple and annoying: basic contact data isn’t “low risk” if it fuels high‑precision fraud, and “deleted” cloud resources aren’t gone if references live on in code and docs.