When we talk about security, breaches like the one at Red Hat remind us how complex that ecosystem really is.
Even trusted environments can become part of the risk chain when they hold sensitive data.
This isn’t about pointing fingers. It’s about understanding what happened, why it matters, and what we can learn from it.
What happened
On 13 September 2025, a group known as the Crimson Collective (linked to LAPSUS$ / Scattered Spider) gained unauthorised access to Red Hat’s internal GitLab environment, used for consulting work.
The incident was disclosed publicly on 3 October 2025. Based on the information that is currently available, roughly 570 GB of (compressed) data was taken, including:
- Over 28,000 repositories
- 3.4 million files
- Consulting reports for several global enterprises (HSBC, Vodafone, Walmart)
- Private keys and certificates (.pfx) belonging to organisations such as ING Bank and Delta Airlines
- Credentials, configuration files, source code, and internal documentation
*So the data above can still be changed as more information becomes available.
Why it matters
The breach highlights a growing challenge: consulting and development environments often hold client data that’s just as sensitive as production systems. When attackers access these repositories, they’re not just stealing files – they’re compromising the trust.
Leaked certificates and credentials can be used to impersonate systems or intercept data.
This isn’t theoretical, parts of the dataset are already circulating online.
For Dutch organisations, especially in finance and technology, this serves as an important reminder that third-party security is part of your own security posture.
What we know about the attackers
Group: Crimson Collective
Affiliations: LAPSUS$ / Scattered Spider
Approach: Public leaks, extortion, attention-driven tactics
Typical targets: Telecom, finance, consulting, and tech supply chains
While Red Hat hasn’t shared the exact entry point, similar incidents have started with:
- Stolen or reused credentials
- Misconfigured access permissions
- Exposed tokens or API keys
What can be learned
Incidents like this reinforce a few key lessons for any organisation:
- Protect what’s shared. Consulting and testing environments often contain production-level data. Treat them the same way.
- Secure secrets properly. Keep certificates, keys, and credentials out of code repositories – store them in secure vaults.
- Plan for compromise. Regularly rotate credentials and monitor for unusual access patterns.
- Know your dependencies. Review external deliverables and integrations for embedded secrets or credentials.
In summary
This isn’t just about one company.
It’s a reminder of how connected we all are – and it’s a case study in how modern supply chains share both value and risk.
By applying lessons from incidents like this, organisations can improve how they store, share, and monitor sensitive data across partners and systems.
Zerocopter will continue to monitor developments and will share updates as new information becomes available.
