A Russian-speaking access broker known as CyberXero used up to 51 Claude Code agents to break into Ukrainian organizations and steal data on more than 628,000 people, according to SOCRadar. The largest haul came from a district heating provider in Kharkiv: 564,073 subscriber records with home addresses and account numbers. SOCRadar found the operation through an open directory on the attacker’s own server and says the actor was still active when it published on October 6 (Security Affairs).
What happened
- JulyFirst CyberXero infrastructure observed
- Late JulyAI account created and Claude Code agents added; the WordPress campaign scales up
- Oct 6SOCRadar publishes its report; the actor is still active
SOCRadar describes CyberXero as a financially motivated initial access broker, a seller of footholds in other organizations’ networks. Data theft is confirmed at four Ukrainian organizations, and seven more energy and utility firms, including the national transmission system operator, were under reconnaissance. Targets elsewhere included 284 Polish state administration domains, a Redis cluster in China, and two Pakistani national-security entities.
The actor’s workstation, at 46.21.250[.]135, ran up to 51 Claude Code agents with roles such as exploit-chainer, lateral-movement, and scada-attacker. A custom tool, wp2shell, abused the WordPress REST API to inject SQL, create a rogue administrator, and plant a webshell; one run scanned 4,708 targets and deployed 32 shells in 61 seconds. A separate AI pentesting framework, PentAGI, was wired to a Cobalt Strike server on Tencent Cloud at 42.193.227[.]214.
The Ukrainian intrusions were hand-picked. In Kharkiv, an administrator credential hardcoded in the actor’s script gave direct access. At an e-commerce portal, the agents chained blind SQL injection, password-reset token extraction, and PHP deserialization into remote code execution. They then used pass-the-hash and dumped MySQL, MongoDB, and Redis.
Claude refused in many sessions SOCRadar reviewed, declining to install a backdoor, disable a firewall, move laterally, or deploy a webshell, and it rejected a forged ownership token. The operator worked around those refusals with a fictional authorization protocol and fresh sessions. SOCRadar ties the alias to a Russian-speaking operator in the Moscow time zone through billing records, a personal email, and forum posts.
How it could have been caught
The agents ran on the attacker’s machine, yet every action they chose had to execute on a victim’s server. A storefront’s PHP workers talk to one database and almost never start a shell. The first behavior a baseline would have flagged at the e-commerce portal is the PHP process spawning a shell after the deserialization exploit, followed by database dump tools that host had never run.
What this looks like in Trace
Here is the e-commerce portal’s intrusion traced inside its cloud, since SOCRadar documents that chain in the most detail. Techniques and attacker addresses come from SOCRadar; hostnames, tool binaries, which address received each step, and timings are illustrative.
Network trace. Workload shop/storefront, the internet-facing PHP application the agents exploited.
- T+0:00nginx → php-fpm (storefront)
- Destination
- mysql.internal:3306
- Baseline
- Known
- T+0:41php-fpm → sh
- Baseline
- Anomaly
- T+0:43sh → mysqldump
- Destination
- mysql.internal:3306
- Baseline
- Anomaly
- T+0:44sh → mongodump
- Destination
- mongo.internal:27017
- Baseline
- Anomaly
- T+0:45sh → redis-cli
- Destination
- redis.internal:6379
- Baseline
- Anomaly
- T+1:10sh → python3 (pass-the-hash)
- Destination
- fileserver.internal:445
- Baseline
- Anomaly
- T+1:32sh → curl
- Destination
- 46.21.250[.]135:443, bulk
- Baseline
- Anomaly
Inference. Claude Code ran on the attacker’s workstation, so its model calls never touched the portal’s network. An implant that needed a model inside the portal would have to cross the AI proxy with a key the portal never issued, or start a model process the host had never run.
Traceback. At T+0:43 the triage agent opens a case and follows the chain:
mysqldump → sh → php-fpm (storefront) → no deploy → no commit → no ticket → no author
The chain ends at the storefront process with no change behind it, and that dead end is the finding.
Verdict: an outside intrusion reaching customer databases from a public web application. The case goes to the portal’s security team with the process chain, the dump tools, and the internal hosts touched, seconds after the first shell and almost a minute before the bulk transfer out.
This analysis reconstructs the incident from public reporting and walks through where Trace would have raised the first alert inside the e-commerce portal’s cloud. Detection times are illustrative.