The phone call is the attack: what the Apollo Global breach should change about how you test
If your last security test proved your perimeter holds, it answered a question nobody is asking any more. The breaches that have done the most damage over the past 18 months did not begin with an exploit. They began with a convincing person on a phone, and an employee who believed them. Claranet has built an agile-scope red team engagement around exactly that pattern, and this is why we think regulated and global organisations need it.
What reporting says happened at Apollo Global Management
Apollo Global Management disclosed on 21 August 2026 that unauthorised users accessed certain of its cloud platforms between 6 and 10 July 2026. The disclosure was made through a breach notice filed with the California attorney general, listing Apollo Management Holdings, L.P. as the reporting organisation. According to the notice, the information involved may have included names, dates of birth, contact information, home addresses, and Social Security numbers. Reporting by Bloomberg described the incident, in Apollo’s own characterisation, as social engineering. Public notices do not point to ransomware, malware, or a software vulnerability. Apollo said it notified law enforcement, engaged outside forensic specialists, and is offering affected individuals 24 months of credit monitoring.
We want to be careful here, and we’d encourage you to be too. Everything above comes from Apollo’s own filings and from press reporting on them. Claranet has no inside knowledge of the incident and we are not asserting anything beyond what those sources say. That caveat matters, because the value of this kind of analysis collapses the moment it drifts into speculation.
What makes the case instructive is the context around it. On 6 August 2026, Google Threat Intelligence Group and Mandiant published research on a financially motivated extortion group they track as UNC6671, describing voice phishing against enterprise employees by operators posing as corporate IT helpdesk staff. The researchers noted a shift through July towards financial services, private equity, law firms, and professional services. Reuters, drawing on Google data, subsequently reported that operators had built credential-stealing sites aimed at employees of firms including Apollo, Blackstone, Bridgewater Associates, Bain Capital, KKR, TPG, CME Group, Clearlake Capital, and Moody’s. That named list came from Reuters, not from Google’s public post.
The technique, as Google described it, is plain enough. Call the employee on a personal mobile number. Present as the corporate helpdesk. Steer them towards a look-alike login page that captures both the credential and the multi-factor token. Then use the organisation’s own cloud tooling against it.
This is not a new pattern. It is a maturing one
British organisations have already had a hard lesson in it. Reporting on the Marks and Spencer intrusion in April 2025 attributed the attack to the group commonly tracked as Scattered Spider, and researchers linked it to helpdesk impersonation, credential harvesting, and abuse of single sign-on platforms. Press accounts described exfiltration of the Active Directory NTDS.dit database and subsequent encryption of VMware ESXi hosts using DragonForce ransomware.
The Jaguar Land Rover incident that began on 31 August 2025 went further. The Cyber Monitoring Centre classified it as a Category 3 systemic event and published an estimate of £1.9 billion in total UK economic impact. JLR reported a direct cost of £196 million. Analysis published since has pointed to social engineering, specifically phone calls impersonating internal staff, as the route in.
Three incidents. Three sectors. One recurring shape. The adversary did not defeat a control. They persuaded a person who held one.
Why conventional testing does not answer the board’s question
When a breach of this profile lands, the question that reaches the board is not technical. It is: could this have happened to us? Most assurance programmes cannot answer it honestly, and we’d argue there are three reasons why.
Scope. A scoped penetration testing engagement assesses a defined technical estate against a defined set of weaknesses. It is essential work, and it is not designed to tell you whether your helpdesk would reset a multi-factor token for a confident caller at 4pm on a Friday.
Pace. Formal, regulator-recognised testing frameworks are rigorous and valuable. They are also slow to scope. Adversary tradecraft moves in weeks. If your last full-scope assessment predates the tactics currently in the headlines, its findings have aged in a way the certificate does not show.
Framing. Purple team exercises produce genuinely useful improvement, because the defenders know the test is happening and learn in real time. But a defender who has been told to expect something is not the defender you have at 4pm on a Friday. To know whether a malicious actor can get in, somebody has to try to get in without telling anyone.
What we built, and what we changed
Claranet has delivered intelligence-led adversary simulation for organisations for some time, and those engagements have supported customers through exactly this sort of question before. What has changed is the methodology behind them. As reporting and vendor threat intelligence on the most recent attacks has become available, we have gone back through our approach and updated the tradecraft we replicate to reflect what we can evidence about how these groups now operate. The pretexts, the identity-layer techniques, and the staging all follow the current picture rather than a playbook written for last year’s adversary.
The engagement itself is deliberately narrow. It is an agile-scope red team assessment with one objective: reach remote code execution or privileged access into in-scope services. Once we are there, we stop. We do not exfiltrate data, we do not deploy anything destructive, and we do not persist. The point is to prove whether the path exists and to evidence every step of it, not to cause the damage a real adversary would.
It is also not a CBEST engagement, and we are explicit about that with every customer. It sits alongside regulator-mandated testing, filling the interval between formal cycles when tradecraft has moved and your last assessment is aging.
The permission model is the service
An engagement that targets people rather than systems carries obligations that a technical test does not. Nothing begins until we have written approval from an authorised signatory in your organisation, and permission from every relevant party whose systems or people fall inside the target path.
In practice that means a working session with senior stakeholders first. CXOs, general counsel, and where appropriate, board members. We set out the objective, the boundaries, the legal position, and what will and will not happen to your people. Only then does our side of the work begin: reconnaissance on targets, staging of attack infrastructure, and execution against the agreed systems.
The challenges this actually solves
It converts an unanswerable board question into an evidenced one. You get a report that says, with timestamps, whether the current attack pattern would have worked against you and precisely where it would have been stopped.
It tests the identity layer as an attacker sees it. Helpdesk process, joiner-mover-leaver workflow, and single sign-on now sit on the critical path to your most sensitive services. Very little conventional assurance treats them that way.
It gives your defenders a genuine measurement. What your Security Operations Centre and your Managed Detection and Response capability do when nobody has warned them is the only number worth having.
It targets remediation where it will pay. Findings feed directly into role-specific security awareness training, identity hardening, and helpdesk process change, rather than a generic all-staff module.
It keeps working between engagements. Pairing the simulation with Continuous Security Testing and attack surface monitoring means the exposure an adversary would find next month is found by us first.
Where to start
If your board has already asked whether the Apollo, JLR, or M&S pattern could play out in your organisation, the honest answer is that you do not currently know. That is not a criticism of your programme. It is a statement about what conventional testing is designed to measure.
A scoping conversation takes an hour and commits you to nothing. If you’d like to talk it through with our cybersecurity team, we’re ready when you are.
Sources
Apollo Global Management breach notice filed with the California attorney general (reporting entity: Apollo Management Holdings, L.P.), disclosed 21 August 2026.
Bloomberg reporting on Apollo Global Management’s characterisation of the incident as social engineering, August 2026.
Google Threat Intelligence Group and Mandiant research on UNC6671, published 6 August 2026.
Reuters reporting on credential-harvesting infrastructure targeting employees of named financial services and private equity firms, August 2026.
Press reporting on the Marks and Spencer intrusion and its attribution to Scattered Spider, April 2025 onwards.
Cyber Monitoring Centre classification and economic impact estimate for the Jaguar Land Rover incident, and JLR’s reported direct cost, 2025.
All breach details in this article are drawn from the public sources listed above. Claranet has no privileged knowledge of any incident described and makes no assertion beyond what those sources report.