A threat actor operating under the moniker 'LAPSUS-GROUP' with deep affiliate level links to the Scattered Lapsus$ Hunters collective has claimed to have exfiltrated approximately 815,000 rows of data from the Adidas Extranet. This is a restricted web-based portal that is used by business partners, suppliers, and licensed distributors. The breach has exposed customer PII including first and last names, email addresses, passwords, dates of birth, company information, and a significant volume of technical data.

Adidas has confirmed the compromise but added that it did not originate from within its own core IT infrastructure. Instead, the intrusion was linked to an independent licensing partner and specific product distributor. This entity is a third party operating its own IT systems with some level of access to the Adidas's partner-facing portal.

Adidas's has experienced such breaches in the past. In May 2025, unauthorized access to a third-party customer service provider led to the leak of contact details of Adidas customers. The continuing challenges that businesses are facing due to third-parties, is becoming a matter of concern as we have seen earlier in the instances of the Nissan Red Hat breach and the Korean Air cyber incident.  

Before we move forward, don’t forget to check out our previous blog post on “the CIRCIA town halls could be a watershed moment for critical infrastructure” here.

How did the breach happen? Reconstructing the attack path

The extranet as an attack surface

An extranet is, by design, a controlled extension of a company's internal network opened exclusively to vetted external parties. In Adidas's case, licensed partners, suppliers, and distributors were granted need-based access to this portal. These portals are operationally necessary to ensure deeper collaboration. Suppliers, for instance, need to access product catalogues, order systems, and logistics data. Retailers need timely inventory feeds. Licensees need design assets and compliance documentation. The problem is that the more access points you offer to external parties, the more attack surface gets created. This surface is only as strong as its weakest participant (or their security practices).

The alleged breach did not involve Adidas's own consumer-facing e-commerce platform or any part of its core enterprise IT environment. Instead the attacker's entry point was a third-party licensee's IT environment that had been granted privileged access to Adidas's Extranet. This is a textbook example of a supply chain attack vector. But not through a software vulnerability when seen in the traditional sense, but through trust abuse. The attacker did not need to penetrate Adidas directly. Instead, they just needed to compromise someone who already had the keys and take the keys from them.

Understanding the Lapsus$ playbook: Social engineering over exploitation

The group behind this incident that is associated with the broader Lapsus$ approach, has a well-documented track record of preferring social engineering and credential theft in the past. This group considers social engineering as a preferable shortcut over technical zero-day exploits. Lapsus$ historical campaigns including the intrusions at Microsoft, Okta, Nvidia, Samsung, and Uber share a common thread.  They often target people and processes rather than code vulnerabilities.

The Lapsus$ approach usually involves at least one or more of the following tactics: SIM swapping to hijack mobile authentication, purchasing or phishing credentials from insiders and external contractors, recruiting employees within target organizations for direct access, exploiting MFA fatigue through repeated push notification bombing until a user accidentally approves, and accessing poorly secured internal portals where credential reuse from other breaches provides an entry point.

In the Adidas incident, this is the most probable scenario (consistent with Lapsus$ methodology). The third-party partner's credentials for the Adidas Extranet were stolen through a social engineering attack and these very credentials were used to access the portal.  

Where the governance possibly failed

When a third-party partner is granted access to an extranet, several security assumptions are implicitly made. The partner is assumed to enforce strong authentication, protect access credentials and does not share them, ensure that it’s IT environment meets a minimum security baseline, and that the partner will notify the primary organization of any security incidents affecting their systems.

In the vast majority of enterprise partner programs, such assumptions are at the best aspirational and at the worst an overlook. Partners often sign acceptable use policies, but very few organizations conduct ongoing technical verification of their partners' security posture (not even as part of a risk and security assessment). A licensing partner for a specific product line is not a cybersecurity firm and their IT maturity, authentication hygiene, and incident response readiness may be well below what Adidas's own security team would be expected to maintain internally.  

What the '420GB French Market' claim signals

The threat actor's claim of holding approximately 420GB of Adidas’ data directly tied to the French market deserves separate attention. If determined to be accurate, this suggests that the exfiltration was not a rapid smash-and-grab. Instead it was a prolonged and deliberate extraction. Data exfiltration of this nature typically requires persistent access over an extended period. This in turn suggests the intrusion may have gone undetected for weeks or months within the third-party environment before the breach was discovered. It also raises the question of whether the Adidas Extranet had adequate egress monitoring mechanisms in place to detect anomalous data transfer patterns from partner accounts.

Lessons for the industry: What the Adidas breach tells us

Lesson 1: Third-party risk is no longer a secondary concern

Many established businesses have spent decades hardening perimeters and some internal controls. But the perimeter has more or less dissolved. Today, the weakest link in a large organization's security chain is almost never inside the organization but lies in the supply chain, the partner ecosystem, the vendor network. The Shieldworkz Threat Report has consistently shown that third-party-involved breaches are among the most common and most damaging. Adidas's back-to-back third-party incidents in 2025 and 2026 are not outliers by any length of imagination. They are instead the norm for many organizations that have not yet made third-party risk management a priority.

Lesson 2: Extranets are high-value targets that are frequently under-protected

Extranet portals aggregate access and data for dozens or hundreds of external partners. They sit at the quintessential boundary between a company-controlled environment and the less predictable security posture of its partner ecosystem. Yet many organizations treat extranets as an IT convenience rather than a security-critical system or even an extended environment. Authentication requirements are often way weaker than internal systems. There is no single-factor or legacy MFA, no device posture checks, no anomaly-based access controls, and insufficient logging. For an attacker, a compromised partner credential to an extranet can be more valuable than a direct intrusion, because it comes pre-authenticated and pre-authorized with less chances of detection.

Lesson 3: MFA alone is insufficient against modern social engineering

In many ways, the Lapsus$ group's effectiveness despite the industry's widespread MFA adoption is a wake-up call. Push notification-based MFA, SMS-based OTP, and even TOTP codes can all be defeated through social engineering. This can be done either by tricking users into approving malicious push requests, by intercepting OTPs through SIM swapping, or by real-time phishing proxies that relay credentials as the victim enters them. Phishing-resistant MFA that is specifically hardware security keys (FIDO2/WebAuthn) or passkeys is the only form of authentication that can hold up against such techniques. Organizations that run extranet portals with SMS or push-based MFA should treat such portals as an active risk to be dealt with.

Lesson 4: Data minimization is a security control, not just a compliance requirement

The alleged breach has exposed birthdates, passwords, company data, and what the threat actor described as “substantial technical data”. Some of this information raises immediate questions about necessity. Why are passwords stored in a format that can be exfiltrated as readable data? Properly hashed passwords using bcrypt, Argon2, or scrypt should be computationally infeasible to reverse in any operationally useful timeframe. If passwords were compromised in a usable form, it suggests either inadequate hashing practices or that what was accessed was a credential cache rather than a properly secured password store. Additionally, the presence of birthdates in a partner-facing extranet dataset begs the question: was that data necessary for the partner relationship, or was it retained beyond its useful purpose?

Lesson 5: A pattern of third-party incidents indicates a structural gap

One third-party breach is an incident. Two third-party breaches within nine months are a pattern. The May 2025 compromise of a customer service provider and the February 2026 Extranet breach share a structural root cause: Adidas's third-party security governance did not prevent either. This does not mean Adidas's internal security is weak. It means that the security controls applied to third-party relationships have not been adequate. The lesson for other large enterprises is that reviewing your own security posture is insufficient. You must review the security posture of everyone who touches your data.

How to prevent It: A practitioner's framework

Third-party risk management: Move from paper to technical verification

Most third-party risk programs are questionnaire-based. A partner fills out a security assessment form annually and the result is filed. This approach is fundamentally inadequate because it relies entirely on self-reporting and captures a point-in-time snapshot. The remediation requires a shift to continuous, evidence-based third-party risk management.

• Require technical attestation, not just policy acknowledgment: Ask for penetration test results, vulnerability scan reports, and SOC 2 / ISO 27001 certifications and review them.

•  Tier your partners by access level and data sensitivity: A partner with Extranet access to product data deserves a higher scrutiny tier than a marketing vendor. Apply proportionate controls.

• Use Cyber Risk Intelligence platforms to continuously monitor the external security posture of partners with elevated access. A partner whose domain infrastructure shows signs of compromise should trigger immediate access review.

• Contractually mandate incident notification timelines: If a partner's systems are compromised, you should know within 24-48 hours, not weeks. Make this a binding contractual requirement with defined consequences for non-disclosure.

Harden the Extranet authentication model

Partner-facing portals should not have weaker authentication than internal employee systems. In many organizations, the opposite is true. The following controls should be non-negotiable for any extranet carrying sensitive data:

• Enforce FIDO2/WebAuthn hardware keys or passkeys for all partner accounts and not SMS OTP, not push notifications.

• Implement Conditional Access or adaptive authentication: Reject logins from unexpected geographies, unrecognized devices, or outside business hours without stepped-up verification.

•  Apply device posture checks at login: Partners accessing sensitive extranet functions should do so from managed or certified devices, not arbitrary personal machines.

• Enforce session timeouts and concurrent session limits: An active session that goes unmonitored for hours is an open door.

• Implement just-in-time (JIT) access provisioning: Partner access should be active only during agreed operational windows, not persistent 24/7.

Instrument the Extranet for anomaly detection

An attacker exfiltrating 815,000 rows of data or 420GB from a portal leaves behavioral signatures. The data transfer volume, timing, query patterns, and access sequences associated with bulk exfiltration are detectably different from normal partner activity. However, this is only detectable if the right telemetry is being collected and analyzed.

•  Log all access events at the extranet layer: who authenticated, from where, what they accessed, how much data was transferred, and when.

• Establish behavioral baselines per partner account and trigger alerts on deviation: a distributor who normally accesses 50 records a day should not be able to silently pull 800,000.

•  Integrate extranet logs with your SIEM and apply User and Entity Behavior Analytics (UEBA) rules specifically tuned for partner portal abuse patterns.

• Tools like Shieldworkz, which offer anomaly detection, heuristic analysis, and rapid risk remediation, are directly applicable here to enable detection of the kind of sudden, high-volume, or unusual command patterns that characterize credential-based bulk exfiltration.

• Implement Data Loss Prevention (DLP) controls at the API and data export layer: cap single-session download volumes, require justification for bulk data requests, and enforce rate limiting.

Apply the principle of least privilege

Every partner account in an extranet should have access to the minimum data necessary for their specific business function. This sounds obvious, but it is frequently violated in practice because broad access is easier to configure and less likely to generate operational complaints.

• Map each partner's business function to a specific data access scope and enforce it technically, not just by policy.

• Separate read and write permissions explicitly: a distributor checking inventory should not also have access to customer PII.

•  Audit access permissions for all partner accounts at least quarterly and immediately upon any change in the partner relationship.

• Remove access immediately upon contract expiration, personnel changes at the partner organization, or any indication of security compromise at the partner.

Fix the password and PII hygiene issues

The reported exfiltration of passwords in a format that appears exploitable is a fundamental security failure that must be addressed regardless of the breach's origins.

• Audit all credential stores: ensure passwords are hashed with a modern adaptive algorithm.  

•  Enforce password rotation and uniqueness policies for all partner accounts.

• Apply data minimization principles to all partner-facing data: if a field is not operationally necessary, do not collect or retain it. Birthdate exposure in a B2B partner portal is a red flag for unnecessary data collection.

• Encrypt sensitive fields at rest at the field level, not just at the database level, so that even a database dump does not yield plaintext sensitive data.

Build a third-party Incident Response playbook

Most organizations have incident response plans for their own environment. Very few have a tested playbook for third-party-originated incidents that, as this case demonstrates, have fundamentally different investigation and response dynamics. You do not control the compromised environment. You cannot conduct forensics on your partner's servers. You are dependent on their cooperation and candor.

•  Define a Third-Party Security Incident Response procedure: who is notified internally, how partner access is suspended, how the scope of data exposure is determined, and how affected individuals are notified.

• Pre-establish communication protocols with high-risk partners for security incident escalation.

• Conduct tabletop exercises that simulate a partner-originating breach scenario specifically — not just a direct intrusion.

• Maintain a Partner Access Registry that can be used to immediately enumerate all accounts and permissions associated with a compromised partner.

The Adidas Extranet breach is not a story about a failed firewall or an unpatched vulnerability. It is a story about trust. Specifically, the security assumptions large enterprises make about the partners they grant access to their systems. In a hyperconnected business environment, your attack surface extends to every third party that touches your data, your portals, and your systems.

The Lapsus$ group and its affiliated collectives have demonstrated repeatedly that technical controls alone are insufficient against well-executed social engineering. The organizations that will fare better in this threat landscape are those that combine rigorous third-party security governance, phishing-resistant authentication, continuous behavioral monitoring, and the organizational humility to recognize that their security is only as strong as the least-secure partner in their ecosystem.

For Adidas, the immediate priority must be a comprehensive review of all third-party access relationships and not just the Extranet, but every partner-facing portal and API. The pattern of incidents demands a structural response, not a reactive patch.

Talk to Shieldworkz for a comprehensive risk and security audit

Downloadable assets

OT / ICS Cybersecurity Operational Security Checklist

State of OT Security Report

Strategic implementation of ISA/IEC 62443-3-2

Enhancing OT cybersecurity and resilience for a leading utility provider