Personal data exposed after a social engineering attack on Apollo

The American asset manager Apollo issued a data breach notice on 21 August 2026. In the letter filed with the California Attorney General, the firm states that it suffered a social engineering incident, and that there was unauthorised access to certain cloud platforms between 6 and 10 July 2026. On 12 August the firm learned that the information potentially affected included names, dates of birth, contact details, home addresses and Social Security numbers. Apollo says the investigation is still under way, and that it has found no evidence so far that the information has been published or used for identity theft or fraud. Reuters reports that Apollo is one of dozens of prominent US financial institutions and other businesses recently targeted by ransom seeking attackers who use phone calls to reach their victims.

What happens technically

Apollo calls the incident a social engineering incident, and the letter says nothing further about how the manipulation was carried out. What the firm does confirm is the outcome. Someone had unauthorised access to certain cloud platforms in the window between 6 and 10 July. The letter names no vulnerability, no CVE reference and no malware. Social engineering is the umbrella term for attacks aimed at the person rather than the machine, and an attack of that kind leaves nothing behind for a vulnerability scan to find. The letter also does not say who the recipients are. TechCrunch makes the same point, noting that the letter does not specify whether the people affected are Apollo employees or individuals at companies Apollo owns. The letter is signed by Matthew Breitfelder, Global Head of Human Capital at the firm.

On the method itself the press coverage is more specific, but it describes the campaign Apollo forms part of rather than Apollo's own case. TechCrunch reports that the attackers call employees and pose as IT help desk staff, in order to get the employee to type their password and their multi factor one time code into a spoofed login portal. SecurityWeek describes the same thing as IT help desk themed vishing, aimed at organisations across North America, Australia and the United Kingdom. Reuters reports that internet intelligence data it reviewed showed the attackers had built websites designed to steal passwords from employees of private equity firms and financial companies. Reuters also quotes experts saying that low tech methods such as phone calls remain among the most effective against the financial industry. SecurityWeek lists several large financial firms as targets, among them Blackstone, Bain Capital, KKR, Bridgewater and CME Group, but states that the list is based on observed phishing infrastructure, domain registrations or reported intrusion attempts. The list therefore does not mean those firms were breached, and several of them have said they detected or blocked attempts with no evidence of data theft.

When an attack of this kind succeeds, the attacker arrives holding a valid login. The system does not see an intrusion attempt, it sees an employee signing in. That explains both why the access can last for days, and why the work of establishing what was actually taken drags on afterwards. At Apollo the gap runs from 10 July, the end of the window given in the letter, to 12 August, when the firm knew which information was affected. The sources do not fully agree on the outcome. The letter says the information was potentially affected, while Reuters writes that the attackers stole personal information. Who the attackers are is also unsettled. Apollo names no one, TechCrunch refers to the group by the aliases Falcon, Helix, Pink and Redact, while SecurityWeek writes that it is tracked as UNC6671 and BlackFile.

What this means for you if you manage access

There is no update to install after an incident like this one, and that is precisely what makes it uncomfortable. If you have built your defences around patching and vulnerability scanning, none of that touches this attack pattern. The attacker walks around it, because the login being used is genuine and somebody handed it over willingly. Our assessment is that the control that matters here sits in two places. The first is the sign in itself. If an employee can type their one time code into a page that is not the real login page, having multi factor enabled does not save you. If you use passkeys or other methods bound to the web address they belong to, the spoofed page collapses on its own, because it is not the address the key was issued for. The second place is the help desk. Password resets and enrolment of a new multi factor device are the two actions this kind of attack ultimately needs, and both should require a confirmation the caller cannot produce.

The second thing worth your attention is the distance between the access and the picture of what happened. Apollo says the access took place in July, and that it was only on 12 August that the firm knew which information was affected. If you have that same gap between "someone was inside" and "this is what they took", your notification deadline becomes a problem long before the lawyers are involved. Under the GDPR you have 72 hours to notify the supervisory authority from the moment you become aware of the breach. A log that shows sign ins but not what was read or downloaded means your notification has to be written with caveats. Apollo is a US company and the letter concerns US notification rules, so carrying this over to European conditions is our assessment and not something the sources say. If you buy asset management or other financial services abroad, it is worth checking what your contract actually says about how quickly the provider has to tell you.

Berigo recommends

• Move the accounts that reach your cloud platforms onto sign in bound to the web address, such as passkeys or FIDO2 keys. A one time code can be typed into the wrong page, a key of that kind cannot.
• Set a firm rule for what the help desk may do on a phone request. Password resets and enrolment of a new multi factor device should require a confirmation the caller cannot supply.
• Turn on logging of reads and downloads in your cloud services, not just of sign ins. Without it you can answer whether someone was inside, but not what they carried out.
• Rehearse the call where an employee is phoned by someone claiming to be IT. People who have heard the script before recognise it, and staff need a place to report it that costs them nothing to use.
• Go through which suppliers hold your personal data in the cloud, and what the contract says about how quickly they must notify you.