Somewhere in the middle of breaching his fourteenth company, the attacker paused to ask the AI to help update his CV. It was the kind of operational mistake that unravels careers. His full name, his LinkedIn profile, and his home address were now sitting inside the same server logs that documented everything else he had done.
Researchers at OALABS recovered those logs after the attacker made a second mistake: he ran his AI tools on someone else’s compromised server, and that server’s owner noticed, downloaded the entire working directory, and handed it to analysts. What they found was not a sophisticated operation. Across more than a thousand recorded sessions, the attacker issued loose, high-level instructions and let the AI handle the rest: identifying exposed services, researching vulnerabilities, writing custom exploit code, executing attacks, and exfiltrating data. Based on the logs and other corroborating evidence, including a moment where he inadvertently confirmed his home IP address to the agent, researchers believe him to be a young man based in Addis Ababa, Ethiopia.
By the time they identified him, he had breached fourteen companies. The AI had also drafted him a detailed monetisation strategy for the stolen data, including suggestions for extortion, access sale, and business email compromise.
The story would be almost comic if the breach count were not real.
The skill floor is gone
There is a concept in security called the “skill floor,” the minimum level of technical knowledge an attacker needs to cause real damage. For decades, that floor held reasonably firm. Exploiting vulnerabilities required understanding them. Writing custom attack tools required knowing how to write code. Piecing together a multi-stage intrusion required experience, patience, and a community of other skilled operators to learn from.
What the OALABS case illustrates is not a sophisticated attacker who happened to use AI. It is an unsophisticated attacker who became capable because of AI. The agent supplied the expertise he lacked, filled the gaps, and handled the technical execution he could not have managed alone. The most directive instruction in the logs was two words: “Recon this.” The AI inferred the rest.
This is not a hypothetical future risk. The logs exist. The companies were compromised. And if anything, this case represents the low end of what is now possible.
There is a further wrinkle worth noting. Across more than a thousand sessions, the AI models involved raised only ten policy violations between them. The attacker bypassed most of them by framing his requests as authorised security research. That framing works precisely because it is also what thousands of legitimate penetration testers use every day. The models cannot verify the claim, and making them refuse anything that sounds like a security test would, as the OALABS researchers put it, hurt defenders far more than attackers. The guardrails will keep improving. So will the techniques for working around them. Expecting AI vendors’ safety measures to act as a meaningful layer of defence is, on the current evidence, wishful thinking.
What this means for your organisation
The implications are clearest for organisations that are not large enterprises with dedicated security operations: law firms, family offices, asset managers, mid-sized financial services companies. These organisations hold valuable and highly sensitive data. They have systems that connect to other systems, banking integrations, client records, and communications that would be damaging if compromised. They generally do not have a full-time red team testing their own defences.
Until recently, that was a defensible position. The attackers who could seriously threaten them were skilled, relatively few, and largely focused on larger or more exposed targets. AI changes that calculus directly. It unbundles skill from intent, and the limit on the attacker’s side is now motivation and time rather than technical expertise, both of which are in plentiful supply.
The right response is not alarm but reassessment. The questions worth asking are concrete ones: which of your services are externally exposed? Which credentials are shared or reused across systems? Does your monitoring look for behavioural anomalies, or only for signatures of known attacks? An AI-assisted attacker will find the answers to those questions faster than most organisations have found them for themselves.
The attacker in Addis Ababa made enough mistakes to be identified. Most will not. The threat environment has changed, and the defences that were adequate two years ago may not be adequate now.
References
1. Zeljka Zorz, “Low-skilled attacker used Claude, Codex to breach 14 companies,” Help Net Security, 17 June 2026. helpnetsecurity.com
2. OALABS (Open Analysis), “Compromised Claude Hacking – Post-Compromise Timeline and Analysis,” research.openanalysis.net, 16 June 2026. research.openanalysis.net
