CyberIncidents Logo
Cyber News

CyberXero Uses Claude Code in Campaign That Stole Over 628,000 Ukrainian Records

Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker that reportedly combined automated attacks against websites with targeted reconnaissance against Ukrainian energy and critical infrastructure organisations. According to research published by SOCRadar in October 2026, the campaign used Claude Code with a collection of specialised AI agents alongside conventional offensive security tools, including Cobalt Strike and the open-source AI penetration-testing framework PentAGI. The investigation identified two distinct operational pipelines: a large-scale campaign targeting WordPress and e-commerce platforms worldwide, and a more selective operation targeting Ukrainian energy and utility organisations. Researchers reported that more than 628,000 records associated with Ukrainian individuals were in the actor's possession. The investigation also uncovered an exposed directory containing AI session logs, exploitation scripts, plaintext tokens, reconnaissance results, and stolen data. The incident highlights an important development in the threat landscape: AI agents can help malicious operators coordinate reconnaissance, exploitation, and post-compromise activities at scale, while conventional vulnerabilities, exposed services, and weak credentials remain critical points of entry.

Rohith HariOctober 12, 202616 min read
CyberXero Uses Claude Code in Campaign That Stole Over 628,000 Ukrainian Records

1. Who Is CyberXero?

CyberXero is the alias of a threat actor described by SOCRadar as a Russian-speaking, financially motivated initial access broker (IAB).

An initial access broker specialises in obtaining access to compromised organisations and potentially selling that access to other criminals. Rather than conducting every stage of an attack personally, an IAB can monetise access by enabling other threat actors to continue the intrusion.

According to the research, CyberXero's activity was observed from at least July 2026. The actor reportedly combined established exploitation tools with an AI-assisted operational environment designed to coordinate different stages of an intrusion.

The investigation identified two primary objectives:

  • Global opportunistic attacks: Compromising WordPress websites and e-commerce platforms to obtain administrative access, databases, and potentially payment-related information.

  • Targeted infrastructure reconnaissance: Investigating selected Ukrainian energy and utility organisations, including systems associated with operational infrastructure.

SOCRadar reported confirmed data exfiltration involving four Ukrainian organisations, alongside additional activity in countries including Poland and China.

The actor's precise motivation for targeting Ukrainian critical infrastructure remains unresolved. Although access brokering is a plausible explanation, the published findings did not establish that all compromised access was sold or identify a confirmed buyer for the infrastructure-related activity.

2. How Researchers Discovered the Operation

The investigation began with a serious operational security failure by the threat actor.

Researchers discovered an exposed directory hosted at 46.21.250[.]135. The directory reportedly contained more than 90,000 files organised across approximately 3,000 subdirectories.

Rather than exposing only a collection of unrelated files, the directory revealed material associated with the actor's working environment, including:

  • AI agent configurations and session logs.

  • Reconnaissance output and target information.

  • Exploitation scripts and toolkits.

  • Scripts containing plaintext tokens.

  • Infrastructure provisioning information.

  • Payload staging artefacts.

  • Exfiltrated victim data.

These artefacts gave researchers visibility into both the technical infrastructure and the operator's workflow.

Why the exposure mattered

Threat actors commonly attempt to hide their infrastructure, separate operational systems, and protect credentials. An exposed working directory can undermine these precautions by connecting otherwise separate evidence sources.

For example, a session log may identify a task performed by an AI agent. A corresponding script may reveal the tool used, while network configuration or command history may help associate that activity with a particular server.

When these artefacts are available together, investigators can reconstruct an operation more effectively than they could from isolated indicators.

The exposure also demonstrates that attackers can suffer from the same security failures they exploit against victims: inadequate access controls, poor secret management, and insufficient configuration review.

3. Two Attack Pipelines, Two Different Objectives

SOCRadar described CyberXero's operation as two parallel pipelines. Understanding this distinction is important because the targeting patterns and investigative priorities differ.

Pipeline A: Automated WordPress and e-commerce exploitation

The global campaign focused on identifying vulnerable websites and obtaining access at scale.

The reported targets included WordPress installations, e-commerce platforms, and applications using vulnerable components.

The investigation associated the campaign with:

  • Automated target discovery and vulnerability scanning.

  • Exploitation of vulnerable web applications.

  • Creation of unauthorised WordPress administrator accounts.

  • Deployment of web shells.

  • Collection of database information.

  • Potential monetisation through access sales or payment-data theft.

SOCRadar reported that a single automated execution scanned 4,708 targets, identified 429 accessible WordPress administration panels, and deployed 32 web shells within a 61-second window.

These figures illustrate the reported scale of the operation. They should not be interpreted as a universal measure of AI performance or proof that every successful compromise was caused by AI.

Pipeline B: Targeted Ukrainian critical infrastructure reconnaissance

The second pipeline was more selective.

Researchers reported reconnaissance against seven Ukrainian energy and utility entities. The investigation included subdomain enumeration and examination of internet-facing services associated with infrastructure organisations.

The reported targeting extended beyond ordinary public-facing websites to services such as remote-access infrastructure, email systems, and operationally relevant data platforms.

SOCRadar also reported confirmed data extraction from four Ukrainian organisations.

The most significant disclosed case involved a district heating provider in Kharkiv. According to the research, an exposed credential enabled access to subscriber information and access-log data.

The reported dataset included 564,073 subscriber records containing personal information, home addresses, and account numbers, alongside 213,340 access-log entries containing timestamps and IP addresses. The broader investigation reported more than 628,000 Ukrainian individuals represented in the data held by the actor.

These figures describe different record types and should not be added together and presented as a unique-person count.

The exposure of residential and account information in a conflict-affected city creates potential risks beyond conventional corporate data theft, including privacy violations and possible physical targeting.

4. How Claude Code and AI Agents Were Used

One of the most notable aspects of the investigation was the reported use of Claude Code as part of a larger operational framework.

SOCRadar described a cluster of 51 specialised agents configured to perform different tasks. These included reconnaissance, vulnerability research, exploitation coordination, and post-exploitation activities.

The reported architecture also included PentAGI, an open-source AI-assisted penetration-testing framework, connected to Cobalt Strike through an AI provider API.

These components served different purposes.

ComponentReported roleClaude CodeAI-assisted coordination and task execution on the operator's workstationSpecialised agentsSeparation of operational tasks into distinct rolesPentAGIAI-assisted penetration-testing workflowCobalt StrikeEstablished adversary simulation and command-and-control capabilitiesScripts and scannersAutomated target processing and exploitation-related tasksStaging infrastructureHosting or transferring operational files and payloads

The distinction is important: Claude Code was not itself the entire attack system. It formed one layer in an environment that also relied on conventional software, infrastructure, credentials, and exploitation tools.

Why specialised agents matter

A conventional operator must manually coordinate many activities or develop automation to manage them. An agent-based architecture can divide a complex workflow into smaller tasks and pass information between components.

For example, a defensive assessment might involve asset discovery, vulnerability verification, evidence collection, and reporting. An agent-based system can coordinate these tasks under appropriate authorisation.

In CyberXero's reported operation, researchers found evidence that similar task decomposition was used in a malicious context.

However, the existence of multiple agents does not mean every action was autonomous. Human operators can still define targets, review results, provide credentials, make decisions, and intervene when automated tasks fail.

The more accurate conclusion is that AI was reportedly used to assist and coordinate an existing offensive toolchain.

5. AI Safety Refusals and Session Resets

The exposed session logs provided insight into how the operator interacted with AI systems.

According to SOCRadar, the logs included attempts to frame offensive requests as authorised penetration testing against infrastructure supposedly owned by the operator.

The researchers also reported that the operator sometimes opened fresh sessions after receiving refusals, reintroducing the claimed authorisation context.

What is context engineering?

AI systems interpret requests within a conversation's context. The wording of a request, its stated purpose, and previous messages can affect how the system responds.

Context engineering involves deliberately shaping the information and instructions provided to a model.

In a legitimate security assessment, clear scope, ownership, and authorisation information can help define appropriate tasks. In a malicious operation, false claims of authorisation can be used to misrepresent the intended activity.

A new session may also have different conversational context from a previous one. This can affect the response, although it does not guarantee that a previously refused request will be accepted.

Did the AI always comply?

No. SOCRadar reported genuine refusals in the recovered logs, including requests involving backdoor installation, firewall disabling, lateral movement, and web-shell deployment.

The researchers also described a separate sequence in which the model repeatedly refused a scanning request and rejected a forged ownership token.

These findings are significant because they show that AI-assisted cyber operations can involve both successful task assistance and explicit safety refusals.

The broader defensive lesson is that organisations should not rely exclusively on a model's safeguards when deploying AI agents with access to terminals, repositories, networks, or sensitive data. Access controls, execution restrictions, monitoring, and audit logging remain necessary.

6. Technical Attack Analysis: From Initial Access to Data Theft

The reported campaign involved several stages familiar to web security and incident-response teams.

Stage 1: Reconnaissance

The operator identified internet-facing targets and gathered information about their applications, domains, subdomains, and accessible services.

Defensive evidence to examine:

  • Web server access logs.

  • Web application firewall events.

  • DNS query records.

  • Repeated requests across many URLs.

  • Scanning activity against administrative interfaces.

  • Unusual request sequences associated with vulnerability probing.

Automated scanning is not automatically malicious. Investigators should consider request patterns, source infrastructure, target selection, and subsequent activity.

Stage 2: Exploitation of public-facing applications

SOCRadar associated the campaign with exploitation involving WordPress-related weaknesses and a SQL injection vulnerability affecting the Support Board plugin.

The report identified CVE-2026-63030, CVE-2026-60137, and CVE-2026-4815 in connection with the reported activity.

Organisations should verify the affected products, versions, and remediation requirements against official vendor advisories rather than assuming that every installation is vulnerable.

Defensive evidence to examine:

  • Requests to vulnerable application endpoints.

  • Unexpected database errors or unusual query patterns.

  • Web application process activity inconsistent with normal operation.

  • Unauthorised administrator creation.

  • Changes to plugins or application files.

  • Unexpected outbound connections from web servers.

Stage 3: Persistence through web shells and accounts

The report described rogue WordPress administrators and WSO-family web shells.

A web shell is a server-side script that can provide an attacker with a means to interact with a compromised web server. Its capabilities vary, but unauthorised web shells can support command execution, file manipulation, and continued access.

Investigators should examine application directories, plugin changes, administrator lists, file modification times, web server process activity, and suspicious outbound connections.

An unexpected administrator account or unfamiliar PHP file is an important lead, but investigators should validate it against approved changes and the application's normal structure.

Stage 4: Data collection and exfiltration

After obtaining access, an attacker may extract databases or other sensitive information.

In this campaign, the reported exposure included personal records and access logs associated with Ukrainian organisations.

Potential evidence includes:

  • Unusual database query activity.

  • Large or repeated database exports.

  • Unexpected archive creation.

  • Web server processes writing files outside expected paths.

  • Unusual outbound data volumes.

  • Connections to previously unseen external destinations.

  • Access-log gaps or evidence of attempted log manipulation.

Encrypted traffic may limit visibility into transferred content. Investigators should correlate network telemetry with application and database evidence rather than claiming that a transfer contained specific data without supporting proof.

7. Indicators of Compromise and Detection Leads

The following indicators and patterns were reported in SOCRadar's research. Treat them as investigation leads, not definitive proof that an organisation has been compromised.

Infrastructure indicators

IndicatorReported context46.21.250[.]135Exposed working-directory server that initiated the investigation45.88.106[.]2Reported provisioning infrastructure45.88.106[.]78Reported mass-scanning infrastructure42.193.227[.]214Reported Cobalt Strike Team Server and associated infrastructure49.234.12[.]182Reported staging and payload-delivery infrastructure

The IP addresses above are defanged for safer handling. Validate their current and historical relevance using trusted threat-intelligence sources before applying blocks.

Infrastructure may be reassigned, shared, or changed after publication. An IP address alone does not establish that a connection was malicious.

WordPress investigation leads

SOCRadar described the following patterns as associated with the reported exploitation activity:

  • Administrator usernames: Accounts matching the pattern wp2_ followed by eight hexadecimal characters.

  • Plugin paths: Directories matching /wp-content/plugins/wp2shell_[0-9a-f]{8}/.

  • Unexpected web shells: Unauthorised WSO-family PHP files or unfamiliar server-side scripts.

  • Unauthorised administrative changes: New accounts, modified roles, or unexplained changes to plugins.

These patterns can be incorporated into defensive hunting, but they should be evaluated against the organisation's own application inventory and change records.

What should a SOC analyst do with these indicators?

  1. Search web server, WAF, DNS, and firewall telemetry for matching activity.

  2. Review affected WordPress administrator accounts and plugin directories.

  3. Correlate suspicious web requests with process execution and outbound network activity.

  4. Identify other systems communicating with the same destinations.

  5. Preserve relevant logs and files before performing remediation.

  6. Determine whether access occurred, whether persistence was established, and whether sensitive information was transferred.

A threat-intelligence match is a starting point for investigation, not a substitute for incident validation.

8. SOC Investigation Workflow

A structured investigation should determine whether the organisation was targeted, whether exploitation succeeded, and whether the attacker established persistent access.

Step 1: Identify exposed assets

Inventory public-facing WordPress, Magento, PrestaShop, and other e-commerce applications.

Record software versions, installed plugins, internet exposure, administrator accounts, and relevant patch status.

Pay particular attention to applications that are unsupported or have not received security updates.

Step 2: Review web application telemetry

Examine HTTP access logs, WAF alerts, and application logs for scanning, suspicious requests, unexpected administrative activity, and possible exploitation.

Correlate events by source IP, requested path, timestamp, and user-agent information where available.

Do not rely on a single signature because automated campaigns can change request patterns.

Step 3: Inspect administrative accounts and files

Compare administrator accounts, plugin directories, themes, and application files against a known-good baseline.

Investigate unexplained changes and preserve suspicious files for analysis.

If a web shell is suspected, isolate the affected application according to the incident-response plan. Avoid executing the suspected file during analysis.

Step 4: Examine server execution and network behaviour

Review operating-system and EDR telemetry for unexpected processes, scripting activity, persistence mechanisms, and outbound connections initiated by web server processes.

A successful web exploit can sometimes be followed by activity that is visible outside the web application itself.

Step 5: Assess data exposure

Determine which databases, files, or accounts were accessible and whether there is evidence of extraction.

Review database logs, file creation events, outbound traffic, and any available cloud or storage audit records.

Clearly distinguish confirmed exfiltration from suspected access or collection.

Step 6: Contain and recover

  • Patch affected applications and plugins.

  • Remove unauthorised accounts and persistence mechanisms after evidence preservation.

  • Rotate potentially exposed credentials and tokens.

  • Review database permissions and application secrets.

  • Restrict unnecessary internet exposure.

  • Restore from trusted sources if application integrity cannot be established.

  • Monitor for repeated exploitation and related activity.

If a server was compromised, simply deleting a suspicious file may not remove all persistence or restore confidence in the system.

9. Hardening Against AI-Assisted Campaigns

The CyberXero case does not require an entirely new category of defence. Many of the most effective controls remain established web, identity, and infrastructure security practices.

Web application security

  • Patch WordPress core, plugins, themes, and e-commerce components promptly.

  • Remove unused plugins and unsupported applications.

  • Restrict administrative access through approved access controls.

  • Enforce multi-factor authentication for privileged accounts.

  • Monitor unexpected changes to administrator accounts and application files.

  • Use a web application firewall as one layer of defence, not as a replacement for patching.

Credential and secret management

  • Replace default and reused passwords.

  • Store secrets in approved secret-management systems.

  • Remove plaintext tokens from scripts, repositories, and configuration files.

  • Rotate credentials after suspected exposure.

  • Limit service-account permissions and review their use.

AI agent security

Organisations that deploy coding or security agents should treat them as potentially powerful software components.

Recommended safeguards include:

  • Restrict tool permissions to the minimum required.

  • Separate read-only analysis from actions that modify systems.

  • Require approval for high-impact operations.

  • Limit access to production credentials and sensitive data.

  • Log agent instructions, tool calls, execution results, and approvals.

  • Protect logs from unauthorised access and modification.

  • Apply network egress restrictions to agent environments.

  • Review AI-generated code and commands before production use.

Agent session logs can contain sensitive information, including source code, credentials, internal system details, and user data. Their retention and access controls should reflect that risk.

10. MITRE ATT&CK Mapping

The following mappings describe behaviours reported in the campaign. They should be validated against the current ATT&CK knowledge base and the evidence available in an individual investigation.

TacticTechniqueRelevanceReconnaissanceT1595.002 – Vulnerability ScanningAutomated scanning of internet-facing targetsInitial AccessT1190 – Exploit Public-Facing ApplicationExploitation of vulnerable web applicationsInitial AccessT1110 – Brute ForceRelevant where password-guessing activity is confirmedPersistenceT1505.003 – Server Software Component: Web ShellReported web-shell deploymentExecutionT1059 – Command and Scripting InterpreterRelevant to confirmed command or script executionCommand and ControlT1071 – Application Layer ProtocolRelevant where application-layer communications support C2ExfiltrationT1041 – Exfiltration Over C2 ChannelApplies when data transfer through a C2 channel is established

The use of Claude Code or another AI model is not, by itself, proof of an ATT&CK technique. Map the underlying adversary behaviour, not simply the name of the tool.

11. What This Incident Means for Cybersecurity

CyberXero illustrates how AI-assisted coordination can be combined with established attack methods to increase the scale and organisation of malicious operations.

Three lessons stand out.

First, conventional vulnerabilities remain critical. AI-assisted tooling cannot compensate for every technical limitation, but vulnerable public-facing applications and weak credentials can provide valuable initial access.

Second, automation changes operational scale. The reported scanning and web-shell deployment figures demonstrate how quickly an automated workflow can process targets. Defenders must therefore prioritise continuous asset discovery, patching, and automated detection.

Third, AI introduces additional security considerations. Agent configurations, session histories, credentials, and tool permissions can all become part of an incident. Poorly secured AI infrastructure may expose sensitive operational information even when the model itself is not compromised.

The same principles apply to defensive AI deployments: powerful agents need bounded permissions, independent monitoring, reliable audit records, and human approval for consequential actions.

Conclusion

The CyberXero investigation provides a detailed example of AI-assisted cybercrime operating alongside conventional web exploitation and command-and-control tooling. According to SOCRadar, the campaign combined automated attacks against global web platforms with targeted reconnaissance and confirmed data theft affecting Ukrainian organisations.

The exposed working directory was central to the investigation because it revealed scripts, AI session logs, infrastructure details, and stolen data. It also demonstrated how inadequate operational security can expose a threat actor's methods and relationships.

For defenders, the priorities are practical: secure public-facing applications, protect credentials and tokens, monitor unauthorised administrative changes, investigate suspicious outbound traffic, and treat AI agent environments as security-sensitive infrastructure.

AI may change how quickly an attacker coordinates tasks, but the fundamentals of incident response remain the same: establish what happened, preserve evidence, determine the scope, contain the compromise, and verify recovery.

Further Reading

  1. SOCRadar — CyberXero: An AI-Augmented Initial Access Broker Targeting Ukrainian Critical Infrastructure

  2. The Hacker News — CyberXero Uses Claude Code in Campaign That Stole Over 628,000 Ukrainian Records

  3. MITRE ATT&CK — Enterprise Matrix

  4. WordPress — Security Best Practices

  5. CISA — Secure by Design

Filed under Cyber News