13 Million Tickets, One Request: How the Adobe BPO Breach Exposes the Third-Party Credential Blind Spot

Here's the number that should make every CISO audibly gasp: one. One HTTP request. That's all it took for a threat actor to export 13 million Adobe support tickets from a third-party helpdesk platform. No brute force. No zero-day exploit chain. No days-long lateral movement operation. Just one API call from a compromised BPO support agent's session — and the entirety of Adobe's customer support history walked out the door undetected (Cybersecurity News, April 2026).

The threat actor, who goes by "Mr. Raccoon," has publicly claimed responsibility and described the attack in granular detail to International Cyber Digest. Adobe has not confirmed or denied the breach at time of writing, but independent researchers assessing the sample data call it "plausible." Whether Adobe's internal investigation ultimately validates the full 13-million-ticket claim or not, the attack vector Mr. Raccoon described isn't hypothetical. I've run enough breach post-mortems to recognise it on sight: it's the exact playbook that BPO-pivot attacks have followed for three years running, and the one your security stack almost certainly cannot see.

---

The Attack Every Traditional Tool Was Built to Miss

Mr. Raccoon didn't need a sophisticated exploit. The attack chain, as described, was almost embarrassingly simple:

1. Initial access via RAT delivery: A malicious email delivered a Remote Access Tool to a BPO employee's machine. The BPO firm is reportedly an Indian outsourcing company contracted to handle Adobe customer support.

2. Credential and session harvesting: The RAT gave the attacker persistent access to the employee's machine, including active browser sessions, authentication tokens, and — critically — the agent portal for Adobe's support ticketing platform.

3. Lateral phishing to escalate: Mr. Raccoon then used the compromised employee's identity to send a targeted phishing message to the employee's manager, broadening control within the BPO network.

4. Mass exfiltration in a single request: Once inside an agent account with sufficient privileges, the attacker discovered that the platform allowed any agent to export the entire ticket database in one API call. "They allowed you to export all tickets in one request from an agent," Mr. Raccoon told International Cyber Digest. Thirteen million records. One request.

What was stolen matters: 13 million support tickets containing customer PII, bug bounty submissions pulled from HackerOne, 15,000 employee records, and internal operational documentation. The HackerOne component alone — unpatched vulnerability disclosures — is potentially catastrophic for Adobe's product security posture.

Every step of this happened outside Adobe's direct perimeter. The RAT landed on a BPO machine, not an Adobe endpoint. The credential theft happened in a BPO browser session. The lateral phishing happened inside a BPO email environment. Adobe's EDR saw none of it. Adobe's DLP saw none of it. Adobe's SIEM had no telemetry from a third-party vendor's internal network.

---

Why This Is Not an Adobe Problem — It Is Yours

Every organisation that uses BPO firms, managed service providers, or outsourced support functions for customer-facing operations has built the same structural blind spot.

The numbers are sobering. According to Gartner's 2025 Third-Party Risk Management survey, 73% of enterprise organisations suffered at least one significant third-party breach in the prior 24 months, yet only 23% had continuous monitoring controls extending into vendor environments. The Ponemon Institute's 2025 Cost of a Data Breach Report found that breaches originating from third-party access cost an average of $4.76 million — 14.5% higher than the global average breach cost — because detection takes dramatically longer when your monitoring doesn't reach into vendor networks.

The Adobe incident follows a now-recognisable pattern. Synnovis (June 2024), Toyota's GitHub credential exposure (October 2025), the Marriott BPO pivot (November 2025) — in each case, attackers found that the organisation had hardened its own perimeter while leaving vendor access points wide open and unmonitored. I walked through that same Marriott dynamic in our piece on the Marriott breach settlement and deception prevention, and the structural lesson hasn't changed. Third-party contractors have legitimate access to production systems, live customer data, and internal APIs. They authenticate with real credentials. Their traffic looks identical to normal operations. And when they're compromised, they become invisible insiders — the same problem we unpacked in the Toyota GitHub secrets exposure.

---

Why Your DLP, SIEM, and CASB Did Not Save Adobe

Let me be precise about why traditional controls fail in the BPO pivot scenario.

Data Loss Prevention (DLP) tools assume that sensitive data exfiltration looks different from legitimate data access. But a support agent legitimately exports tickets every day. The access pattern Mr. Raccoon used — a single large API export — would have looked identical to a legitimate bulk export. DLP policies built on volume thresholds or content inspection can't tell an authorised data pull apart from an attacker who has simply acquired authorised credentials. The Adobe platform had no rate limiting on the export endpoint. Even if it had, an attacker with a legitimate agent session would have passed every authentication check.

SIEM correlation rules work on telemetry from systems you control. When the attack chain begins on a BPO employee's endpoint — outside your network, outside your EDR coverage, outside your log aggregation pipeline — your SIEM is blind from the very first step. By the time Mr. Raccoon was making API calls from the agent portal, every action looked like a normal authenticated session from the expected BPO IP range.

Cloud Access Security Brokers (CASBs) add visibility over SaaS applications, but they operate on session metadata and can't tell a legitimate agent apart from an attacker riding a legitimate agent's stolen session token. Without anomaly baselines specific enough to flag "this agent has never exported more than 50 tickets in a session before," a CASB alert never fires.

Privileged Access Management (PAM) solutions protect privileged administrative accounts — but BPO support agents aren't privileged users in the PAM definition. They're regular application users with the specific permissions their jobs require. PAM tools aren't designed to monitor or control normal user sessions in third-party support applications.

The fundamental problem is architectural. Traditional security controls are built around a trusted insider and an untrusted outsider. BPO-pivot attacks exploit the fact that the compromised third-party user is an insider by definition — authenticated, authorised, and invisible to every control that depends on telling legitimate and malicious access apart at the authentication layer.

---

How Credential Mines and Data Mines Catch What Everything Else Misses

Mine2's deception technology inverts the detection problem. Instead of trying to spot malicious behaviour in a sea of legitimate activity, Credential Mines and Data Mines lay tripwires that real users doing real work never touch.

Credential Mines are fake credentials — usernames, passwords, API keys, OAuth tokens, service account credentials — planted strategically across the environment. They're seeded where an attacker navigating a compromised account would naturally stumble onto them: browser credential stores, configuration files, shared drives accessible to vendor accounts, password managers synced to BPO machines. Real employees and real BPO agents never need these credentials. They already have their own legitimate access. The moment any Credential Mine is used for an authentication attempt anywhere — against Adobe's internal APIs, AWS, or any monitored service — the detection fires with zero ambiguity. No false positives. No tuning required. No baseline to game.

In the Adobe scenario, Credential Mines seeded in locations accessible to BPO support agent environments would have fired the instant Mr. Raccoon began exploring beyond the initial foothold. The attacker's tool set would have harvested every credential it found — real and fake alike. The moment a mine was tested against any authentication endpoint, Mine2 would have generated an alert with the precise credential used, the source IP, the timestamp, and the access pattern — handing the security team a clear, actionable signal days before the mass export happened.

Data Mines extend the same principle to document-level detection. Fake customer records, fake support tickets, fake employee PII documents — all indistinguishable from real data but instrumented to beacon home when accessed or exfiltrated. If a Data Mine embedded in the support ticket dataset is exported and opened, it phones home. The attacker's location, tooling, and operational patterns become immediately visible. A Data Mine in a fake HackerOne submission would have given Adobe precise intelligence on the attacker's infrastructure within hours of the breach beginning. This is exactly the model we detailed in our walkthrough of supply chain honeytokens.

MineField decoy TCP services, deployed as fake internal APIs and endpoints within the BPO-accessible network segment, detect lateral movement before it reaches production systems. Any connection attempt to a MineField service — which looks exactly like a real internal endpoint but is never touched in normal operations — immediately signals that an attacker is exploring the environment.

The key insight is zero false positives. Mines are never touched by legitimate activity. When they fire, the signal is unambiguous, actionable, and early — it arrives before the attacker reaches their primary objective.

---

Compliance Implications: 13 Million Records Means Mandatory Notification

The alleged Adobe breach isn't just a reputational event. It's a multi-jurisdictional compliance emergency, and the clock starts the moment the breach is confirmed.

GDPR (Articles 33 and 34): 13 million support tickets containing EU customer PII triggers mandatory notification to the supervisory authority within 72 hours of the organisation becoming aware. If the breach is deemed high-risk for data subjects — which exposure of support histories, contact information, and bug reports almost certainly qualifies — individual notification to affected customers is also mandatory. Fines under GDPR Article 83 can reach €20 million or 4% of global annual turnover, whichever is higher.

India's Digital Personal Data Protection (DPDP) Act: Given that a BPO firm operating in India is reportedly implicated, the DPDP Act's breach notification provisions apply to both the data fiduciary (Adobe) and the data processor (the BPO). The DPDP Act requires prompt notification to the Data Protection Board of India upon knowledge of a personal data breach, with penalties up to ₹250 crore for significant violations.

PCI-DSS Requirement 11: If any of the 13 million support tickets contain payment card information — which customer support interactions frequently do — PCI-DSS Requirement 11 mandates that the organisation test all system components and establish a formal incident response process. Failure to maintain adequate third-party oversight for PCI-scoped data can bring significant fines and potential loss of card processing privileges.

CERT-In 6-Hour Reporting: Under India's CERT-In Directions of 2022, any cybersecurity incident involving Indian infrastructure or Indian users must be reported to CERT-In within six hours of detection. For organisations operating in India with BPO partnerships, this timeline is extraordinarily compressed — and entirely dependent on having detection mechanisms that fire immediately upon breach, not days later during forensic analysis.

RBI and SEBI Directives: For financial sector organisations using third-party BPO support, the Reserve Bank of India's Outsourcing Framework and SEBI's cybersecurity guidelines both mandate continuous monitoring of outsourced operations. The Adobe pattern — where an outsourced support function became the primary breach vector — is precisely the scenario these regulators had in mind when issuing third-party risk management mandates.

HIPAA (for healthcare sector parallels): In healthcare environments where BPO firms handle patient communication, the same BPO-pivot vector triggers HIPAA Breach Notification Rule requirements for covered entities and business associates alike, including HHS notification within 60 days and individual notification requirements.

Mine2's Credential Mines and Data Mines build the audit trail compliance requires: precise timestamps of when the breach began, which credentials were compromised, which data was accessed, and the attacker's operational fingerprint. That's not just a detection capability. It's forensic evidence that satisfies notification timelines and regulator inquiries.

---

The Practitioner Playbook: Five Controls for the BPO Blind Spot

If you have BPO relationships, managed service provider access, or any outsourced function with access to internal systems or customer data, put these controls in place now:

1. Seed Credential Mines in every BPO-accessible environment. Map every location a BPO agent or third-party contractor might encounter credentials — shared network drives, configuration files, internal wikis, onboarding documentation, browser sessions on shared machines — and plant Credential Mines in each. Use Mine2's single-click deployment to cover all locations in under an hour. Any mine usage triggers an immediate alert.

2. Embed Data Mines in your highest-risk datasets. For customer support databases, ticket systems, employee records, and any dataset accessible to third-party agents, embed a percentage of Data Mine records — fake but indistinguishable entries that beacon when accessed or exported. If an attacker exports your entire dataset, the Data Mines exit with it and report back.

3. Deploy MineField decoy services on BPO-accessible network segments. Any internal API, internal portal, or internal service that BPO agents could reach should have corresponding MineField decoys listening on adjacent ports. Lateral movement exploration — the inevitable step after initial access — trips MineField alerts before production systems are reached.

4. Enforce API-level export rate limits and session anomaly detection. The single-request mass export vector is a product configuration failure, not a security tool failure. No legitimate support operation needs to export 13 million records in one API call. Session-scoped rate limits on bulk export endpoints, paired with Mine2-triggered alerts when vendor accounts behave anomalously, create an immediate tripwire.

5. Extend your threat model explicitly to the BPO perimeter. Most third-party risk management programs assess vendor security posture at contract time and annual review. That's insufficient. BPO environments are high-churn, endpoint-diverse, and hard to continuously monitor. Deception technology — mines seeded in the artefacts and environments that BPO agents routinely access — provides continuous, passive monitoring of third-party access patterns without requiring any visibility into the BPO's own network.

---

The Zero-Alert Failure Is Structural, Not Accidental

The most disturbing detail in Mr. Raccoon's account isn't the 13-million-ticket export. It's that no alert fired during the entire operation. Not a DLP alert. Not a CASB alert. Not a SIEM correlation. Not a rate limit. Zero signals from an arsenal of enterprise security tools — because every step of the attack used legitimate access from a legitimate account operating within its authorised permissions.

This isn't a failure of the individual tools. It's a structural failure of the detection paradigm. Behaviour-based detection, anomaly detection, and signature-based controls all share the same assumption: that malicious activity looks different from legitimate activity at some detectable layer. BPO-pivot attacks are designed precisely to break that assumption. The attacker is the authorised user.

Deception technology doesn't make that assumption. Credential Mines don't care whether the authentication attempt looks normal. Data Mines don't care whether the export volume looks suspicious. They fire the instant a fake artefact is touched — and fake artefacts are never touched by real users doing real work. The detection isn't a probability. It's a certainty.

---

Conclusion

The alleged Adobe breach will be studied for years as the definitive example of the BPO supply chain blind spot. Thirteen million support tickets. Fifteen thousand employee records. HackerOne submissions. All of it, extracted in one request, through a compromised support agent's session, with no alert from any deployed security control.

If your organisation uses BPO firms, managed service providers, or any third-party function with access to customer data or internal systems, you carry the same structural exposure Adobe allegedly had. The question is whether you have the controls to detect the moment a third-party account starts getting weaponised.

Credential Mines, Data Mines, and MineField are the controls that operate at the detection layer BPO-pivot attacks can't evade. They need no network visibility into vendor environments. They generate no false positives. And they fire at the earliest possible moment — when the attacker first tests what they stole.

Close the third-party credential blind spot before it's your post-mortem. See how Mine2 works at https://www.mine2.io/product.

---

Sources: Cybersecurity News (April 2026), Security Online / International Cyber Digest, GBHackers, Cybernews, SC Media, Ponemon Institute 2025 Cost of a Data Breach Report, Gartner 2025 Third-Party Risk Management Survey