Brinks Home Data Breach: How ShinyHunters Used a Single Phone Call to Steal 4.9 Million Records
On July 13, 2026, a Brinks Home employee picked up what looked like a routine internal IT support call. Twenty minutes later, an attacker calling themselves ShinyHunters had a foothold inside the company's Salesforce environment. Seven days would pass before anyone at Brinks Home noticed. By the time incident responders shut the door, the extortion crew claimed to be walking away with 4.9 million records — customer contacts, employee PII, and nearly 3.8 million customer support chat transcripts.
This is not a exotic zero-day story. There's no exploit chain, no malware sample, no CVE to patch. It's a story about a phone call — and it's the same story that's now played out at dozens of major US enterprises in 2026. If you run a SOC, manage identity infrastructure, or advise leadership on cyber risk, the Brinks Home data breach is worth studying in detail, because the attack technique behind it is still active and still working.
Table of Contents
- What Happened: Brinks Home Breach Timeline
- Understanding the Attack: Entra Vishing Against Salesforce
- Who Is ShinyHunters and Why Salesforce?
- What Data Was Allegedly Exposed
- Key Indicators & Logs to Check
- Detection Queries and Tools
- Detection & Prevention Strategy
- Expert Tips from the SOC Floor
- Related Articles
- FAQ
- Conclusion
What Happened: Brinks Home Breach Timeline
Brinks Home is one of the largest residential security and smart-home monitoring providers in North America, serving well over a million customers across the US, Canada, and Puerto Rico. That scale is exactly what makes this incident notable — a company whose entire business is "security" still fell to a low-tech social engineering call.
| Date | Event |
|---|---|
| July 13, 2026 | ShinyHunters allegedly gains access via a Microsoft Entra vishing call, tricking an employee into completing an authentication/registration step |
| July 20, 2026 | Brinks Home detects unauthorized activity and activates incident response — roughly one week of undetected attacker dwell time |
| July 27, 2026 | ShinyHunters lists "BH Security, LLC (brinkshome.com)" on its extortion leak site alongside other victims, with a payment deadline |
| July 30, 2026 | Ransom deadline passes without confirmed payment |
| August 1, 2026 | Brinks Home publicly confirms the intrusion, states core alarm monitoring and system functionality were unaffected |
Brinks Home has been clear on one point: the compromised systems were tied to Salesforce customer relationship management (CRM) and a customer support chat platform — not the physical alarm hardware or monitoring network. That distinction matters for customers, but it doesn't make the data exposure any less serious.
Understanding the Attack: Entra Vishing Against Salesforce
The technique ShinyHunters used isn't new — it's the same playbook that hit Google, Qantas, Allianz Life, Adidas, and a growing list of Fortune 500 names throughout 2025 and 2026. Here's how it typically works, step by step:
- Reconnaissance: Attackers scrape LinkedIn, corporate directories, and breach data to build a target list of employees — often IT help desk staff or Salesforce admins.
- The call: The attacker phones the employee (or the employee calls a spoofed "help desk" number) posing as internal IT support, claiming there's an urgent access issue with their account.
- Credential/MFA abuse: The victim is walked through what looks like a normal Microsoft Entra ID (formerly Azure AD) authentication or device-registration flow. In reality, they're approving the attacker's own MFA prompt or registering the attacker's device as a trusted one.
- OAuth abuse: Once inside the identity layer, attackers frequently connect a malicious or modified version of the Salesforce Data Loader app via OAuth, which is then used to mass-export CRM records without triggering traditional malware alerts.
- Exfiltration: Data is pulled out through legitimate API calls that blend into normal business traffic — which is exactly why these breaches often go undetected for days.
No malware. No exploit. Just a convincing voice, a trusted brand name, and an employee trying to be helpful.
Who Is ShinyHunters and Why Salesforce?
ShinyHunters is a financially motivated extortion collective that has been active since 2020, tied loosely to the broader "Scattered Lapsus$ Hunters" / "The Com" cybercrime ecosystem. Their 2025–2026 campaign has focused almost exclusively on Salesforce environments, using the vishing-plus-OAuth method described above against dozens of organizations.
Salesforce is an attractive target for a simple reason: it's a centralized repository of exactly the data extortion groups want to monetize — customer names, emails, phone numbers, support history, and internal notes — and it's usually managed by business teams rather than security teams, which means weaker monitoring around who connects new integrations or exports bulk data.
What Data Was Allegedly Exposed
According to ShinyHunters' own claims (not yet independently confirmed by Brinks Home), the exposed dataset breaks down as follows:
- Over 1.1 million rows of customer data from the Salesforce "Contacts" object
- More than 4,000 rows of employee PII — names, emails, job titles, phone numbers
- Roughly 3.8 million customer support chat logs from the Brinks Care Cresta platform
Combined, that's the "4.9 million records" figure attackers advertised — though security researchers are quick to note this is a sum of records and chat transcripts, not a distinct count of affected individuals. Brinks Home itself has stated it has not yet confirmed exactly what data or how many people are impacted.
The support chat logs deserve special attention. Unlike a flat contact list, chat transcripts often contain service addresses, equipment/system details, account history, and troubleshooting conversations — the kind of granular context that makes a follow-up phishing call sound completely legitimate.
Key Indicators & Logs to Check
If you run Microsoft Entra ID and Salesforce in your environment, these are the log sources and indicators that matter most when hunting for this attack pattern:
| Log Source | What to Look For |
|---|---|
| Entra ID Sign-in Logs | MFA registration or authentication events from unfamiliar devices/locations shortly after a help-desk-style support ticket or unusual phone activity |
| Entra ID Audit Logs | New MFA method added ("Register security info"), especially outside normal onboarding workflows |
| Salesforce Login History | Logins from new IP ranges or ASN's immediately followed by large data exports |
| Salesforce Setup Audit Trail | New Connected App / OAuth grant added by a user account, particularly Data Loader or similar bulk-export tools |
| Salesforce Event Monitoring | ReportExport, BulkApiResultEventStore, or API events showing high-volume record pulls in a short window |
| Helpdesk/ITSM Ticketing System | Password reset or MFA reset tickets that don't match the employee's normal request pattern or origin |
Detection Queries and Tools
Here are practical starting points your SOC or identity team can adapt today. Always test in a non-production workspace first and tune thresholds to your organization's baseline before deploying as alerts.
1. Microsoft Sentinel / KQL — Detect new MFA method registration followed by unusual sign-in:
AuditLogs
| where OperationName == "Register security info"
| project TimeGenerated, InitiatedBy, TargetResources, Result
| join kind=inner (
SigninLogs
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName
) on $left.InitiatedBy == $right.UserPrincipalName
| where TimeGenerated between (TimeGenerated .. TimeGenerated + 1h)
What it does: Flags accounts where a new MFA method was registered and then immediately used to sign in — a common pattern in Entra vishing attacks. Expected output: A table of users, timestamps, and sign-in locations for manual triage.
2. Salesforce Event Monitoring — Spot bulk export spikes:
SELECT UserId, EventType, COUNT(Id)
FROM EventLogFile
WHERE EventType IN ('BulkApiResultEventStore','ReportExport')
AND LogDate = TODAY
GROUP BY UserId, EventType
HAVING COUNT(Id) > 50
What it does: Surfaces users pulling an abnormally high number of records or reports in a single day. When to use it: Run daily as a scheduled job feeding into your SIEM. Expected output: Any user/event pair crossing your export-volume threshold.
3. Quick check for newly authorized Connected Apps (Setup Audit Trail):
SELECT CreatedDate, CreatedBy.Name, Display, Section
FROM SetupAuditTrail
WHERE Section = 'Connected Apps'
ORDER BY CreatedDate DESC
What it does: Lists every new OAuth/Connected App authorization, which is exactly how attackers plug in tools like Data Loader after gaining access. Review this weekly at minimum.
Detection & Prevention Strategy
The Brinks Home incident — like the dozens before it — is a strong argument for treating your help desk as a security perimeter, not just a productivity function. Recommended controls:
- Kill call-based MFA resets. Require identity verification through a separate, pre-established channel (video callback to a known number, manager approval) before any MFA reset or device registration over the phone.
- Enforce phishing-resistant MFA. Move high-privilege and Salesforce-admin accounts to FIDO2/WebAuthn security keys, which can't be socially engineered the way push-notification MFA can.
- Restrict Connected App creation. Lock down who can authorize new OAuth Connected Apps in Salesforce; require admin approval for any new integration, especially bulk-data tools.
- Monitor export volume, not just failed logins. Most SOC alerting focuses on failed authentication. This attack succeeds through valid logins — your detection needs to catch abnormal data volume, not just access anomalies.
- Run help desk social engineering drills. Regularly test your own IT support staff with simulated vishing calls, the same way you'd run phishing simulations for email.
- Segment CRM data by need. Support chat platforms like Cresta shouldn't retain full account/service history indefinitely if it's not operationally necessary — data minimization limits blast radius.
- Have a customer communication plan ready before a breach, not after. Brinks Home's advisory to customers (never share info via unsolicited calls/texts, verify through official channels only) is standard, correct guidance — but it should already be pre-drafted and ready to publish the moment ShinyHunters (or any group) lists you.
Expert Tips from the SOC Floor
- Treat any "MFA registered" event as a Tier-1 alert if it happens outside a scheduled onboarding or device-refresh window — this single signal is the earliest tripwire in nearly every Entra vishing case reported this year.
- Don't just monitor for malware in your CRM stack — Salesforce breaches almost never involve malware. Your detection logic needs to shift toward behavioral and volume-based anomalies.
- Cross-reference help desk ticket metadata (caller ID, ticket origin) against HR records. Attackers frequently use employee names pulled from LinkedIn but can't match internal ticketing metadata patterns.
- If you outsource support chat to a third-party platform (Cresta, Zendesk, Intercom, etc.), that vendor's access controls are now part of your attack surface — audit them the same way you'd audit an internal system.
Related Cybersecurity Topics You Should Explore
- GPG Command Tutorial: The Encryption Trick Real SOC Analysts Use
- AI Found a Chrome Bug Hiding for 13 Years. Here's How.
- This Open-Source AI Agent Turns ChatGPT Into a Hacker
- GenieLocker Ransomware Explained: How Toy Ghouls Hack ESXi Servers
- ln Command Explained: How Hackers Abuse Symlinks to Hack Root
- NVIDIA BlueField Flaw Lets Hackers Hijack Cloud Servers
- NGINX Buffer Overflow (CVE-2026-42533): Patch Before It's Exploited
- Windows 11 Finally Fixes Its Slowest File Deletion Problem
- Microsoft Just Killed the Fake KMS Server Trick for Good
- GitLab RCE Bug: How a Simple Notebook Diff Gave Attackers Root
- PentesterFlow: The AI Tool That Hacks Like a Human
- Bash History Forensics: A SOC Analyst's Real Breach Story
Frequently Asked Questions
Is Brinks Home's alarm monitoring system affected by this breach?
No. Brinks Home has stated that the breach was confined to its Salesforce CRM and customer support chat platform. Alarm monitoring, sensors, and system functionality continued operating normally throughout the incident.
What data was stolen in the Brinks Home breach?
ShinyHunters claims to have taken over 1.1 million customer contact rows, more than 4,000 employee records, and roughly 3.8 million customer support chat logs. Brinks Home has not yet independently confirmed the exact scope or which individuals are affected.
How did the attackers get in?
According to ShinyHunters, access was gained through a Microsoft Entra voice phishing (vishing) attack on July 13, 2026, in which an employee was socially engineered into completing an authentication step that handed attackers account access.
Is this related to other 2026 Salesforce breaches?
Yes. This incident fits a broader ShinyHunters campaign in 2026 that has used the same vishing-and-OAuth technique against other organizations, including Cushman & Wakefield, Kodak, Sysco, EY, and RingCentral.
Did Brinks Home pay the ransom?
This has not been publicly confirmed. ShinyHunters set a July 30, 2026 deadline before threatening to publish the data; as of Brinks Home's public confirmation on August 1, no payment has been verified either way.
What should Brinks Home customers do right now?
Be cautious of unsolicited calls, texts, or emails referencing the breach. Never provide personal information or credentials to inbound contacts — verify anything through Brinks Home's official channels only, and watch for account notifications if you're confirmed as affected.
Can phishing-resistant MFA have prevented this?
In most Entra vishing cases documented this year, yes — FIDO2/hardware security key MFA cannot be approved over the phone or via a push notification the way OTP or app-based MFA can, which removes the core mechanism these attacks rely on.
Conclusion
The Brinks Home breach won't be remembered for technical sophistication — it will be remembered as one more entry in a growing list of enterprises undone by a single convincing phone call. That's the uncomfortable truth security teams need to sit with: your firewalls, EDR, and SIEM rules mean little if a help desk agent can be talked into handing over the keys.
If there's one action item to take from this incident today, it's this: audit how your organization handles MFA resets and device registration requests over the phone, and close that gap before ShinyHunters — or the next group using the same playbook — finds it first.
Found this breakdown useful? Share it with your SOC team, drop your thoughts in the comments, and subscribe for more real-world incident analysis as this story develops.