12 days to global data access — and not a single alert.
A $100B+ global retailer asked a blunt question: could a determined attacker actually destroy us? Four operators answered it, chaining physical and digital, past $329M of security spend, undetected.
- Sector
- Retail
- Revenue
- In excess of $100B
- Footprint
- Global
- Duration
- 8 weeks (max)
- Team
- 4 operators
- Test areas
- Cyber & physical
Published by OSec as a red team case study. Client anonymised; identifying specifics generalised.
“Could we be destroyed by a cyber attack?”
This was the question our client posed. A single cyber attack rarely brings a giant organisation to its knees. A hack, data theft or ransomware causes damage, but seldom enough on its own. Technology is usually the conduit to a larger outcome, not the outcome itself.
The real damage comes when a company consistently fails its customers: trust erodes, and they leave for a more reliable competitor. That was the outcome we set out to engineer against one of the largest retailers in the world.
With stakeholders, we first agreed what “catastrophic” would mean in their terms: a 10% drop in revenue. We mapped the business processes that could get there. After two weeks of analysis and follow-up, several high-impact scenarios emerged, and we settled on one: Death by 1,000 Cuts.
Not one breach. A thousand small ones.
Death by 1,000 Cuts was a multi-pronged campaign built to erode customer confidence over time, rather than land one dramatic blow. Across a range of stores, refrigeration and heating could be disrupted, deliveries delayed, staff-management systems compromised, internal communications read and hijacked, and key customer databases accessed and exfiltrated.
With finite time, the objective wasn’t to do all of it. It was to prove each target component could be breached. Customer database, HRMS and communications were centralised; HVAC, refrigeration and deliveries were standardised across every store and distribution centre. Breach one, and you’ve shown the attack works at scale.
Three vectors. Six weeks to prove one.
With the scenario set and six weeks on the clock, the team chose three vectors to test:
- 01The management room in a store
- 02An internet-facing application
- 03A room at a vendor location
The client rated the risk of a breach through any of these as significant, but was confident that its technical controls and staff security-awareness training made success unlikely.
We weren’t given exact figures. But per Deloitte, the average 2023 technology budget was 5.49% of revenue, with security typically 6–14% of IT spend. For a $100B business, that implies roughly $329M allocated to security. On paper, enough to stop anything short of a well-funded nation-state.
Source: Deloitte Insights, “From tech investments to impact: Strategies for allocating capital and articulating value.”
A polo shirt, a fake ID, and Super Bowl Sunday.
In every location, the store management room sat at the back, behind swing doors with no access control. Of the approaches considered, this is the breach we ran:
- 1
On Super Bowl Sunday, an operator walked into a store in a polo shirt and khakis, claiming to be from company tech support.
- 2
Using information found online, he carried a fake company ID and the right names to drop. He asked to see the store manager.
- 3
He explained he’d been sent to fix a technical issue. After a short chat, the manager gave him a desk and let him get to work.
- 4
He deployed a remote-access tool from a system he’d brought in — a tunnel straight into the network. The manager chatted openly about his job the whole time.
- 5
He left after about an hour. The remote-access tool stayed live for the rest of the engagement, and was never detected.
Access from the management room gave full reach into the internal network.
Vendor room
The vendor location was accessible from the street. Turnstiles were in place, but tailgating in behind an employee was trivial. The operator found an empty room and installed a second remote-access system, confirming network connectivity. With two footholds established, the team focused on the vendor room.
Application
One application was selected for testing. Several vectors for possible exploitation were identified, but given the timeframe, they were scheduled for a later date.
Twelve days to all the data — and not one alert.
In twelve days, the objective was met: full access to the company’s global data-analytics platform. The underlying Hadoop cluster was reached with full privileges: the ability to delete data, reconfigure the system, and perform database-administrator actions, all without being detected. No alerts were raised. Every security control was bypassed.
It took patience. Stealth meant no intrusive tools, just careful analysis of SharePoint and a long read through scripts and configuration. Here is how the trophy was reached:
- Step 01
Valid credentials
Access to the internal SharePoint surfaced an extensive list of Linux servers and the engineers who ran them. Documents those engineers had authored included details of internal repositories.
- Step 02
Public file share
Browsing the repository, the team analysed the packages on it. One — named after a user — held a private key and a server name. That server was accessed.
- Step 03
Privilege escalation
Modifying a script on the server let the team run commands as root. A “go” script admins used to hop between hosts revealed an SSH root key, opening the door to other machines.
- Step 04
Cloudera access
On a host running Cloudera, scripts pointed to a MySQL instance used for configuration. The MySQL root password sat in a backup script. The team connected, created a root and admin user, and reached Cloudera.
- Step 05
Full access to all data
The data-management portal ran over plain HTTP. A few hours of tcpdump on the compromised servers yielded DBA credentials, and with them, full access to all data. The trophy was captured.
Three systemic issues. One root cause.
Tied together, the findings pointed to a misunderstanding of risk management, and an over-reliance on compliance as the final word in security.
The idea that “an attacker only has to succeed once” does a disservice to attackers and defenders alike. One vulnerability rarely destroys a business. A collection of them, in the hands of an attacker fixed on a high-impact outcome, is a risk-management problem. It demands a view of the whole operation, not just its technical support systems.
Security awareness can’t carry the load
Confidential data sat in SharePoint files any employee could open. Awareness training is a compliance box, and it rarely overrides basic human instinct. Controls that remove the chance for human error work far better than posters and a slide deck.
The programme wasn’t built on business impact
It had been designed with little thought for how the business actually makes money, or which attacks would hurt most. Those questions were never put to leadership. A standard defence-in-depth playbook was deployed instead. Securing everything, everywhere, and monitoring all of it, is a recipe for disaster.
Risk doesn’t hold still
An annual pen test of specific applications catches something, but new vulnerabilities appear constantly and chain across technical and non-technical targets. Poor perimeter access, a flat network, secrets in SharePoint and monitoring not modelled on real attacks add up to exposure.
The math the board understood.
Because the business itself judged the trophy to have a material impact on revenue, the engagement gives an unusually clean read on return. Run with precision against specific business impacts, red teaming surfaces the vulnerabilities worth fixing to protect customer trust and growth.
$10B is a 10% hit to revenue — the catastrophic bar set at the outset. Figures as published in the OSec case study.