Kaspersky's Securelist team published a report on 2 November 2026 describing attacks in which a language model, running on the attacker's command-and-control (C2) server, chose the commands for the post-exploitation phase. The framework is CyberStrikeAI, an open-source pentest platform. Confirmed victims were education organizations in several countries in Africa and Latin America. From agent installation to compromised domain administrators took three to four days. If you run coding agents, there is no patch to install; the practical lessons are about speed, credential hygiene and what to watch on the machines that hold your keys.
Beam has covered this tool before from the other side of the wire: TrendAI's reconstruction of 44 CyberStrikeAI agents probing organizations in Japan came from attacker-side open directories. Kaspersky's report is different: it comes from a live intrusion investigated on the victim side, with a timeline.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | Only if your Windows domain is exposed in the way described: a compromised SQL Server was the likely entry point. No coding agent product is vulnerable. |
| Is there a fix? | No patch. Defenses are monitoring and credential controls (see below). |
| What was new? | An LLM on the C2 server selected tools, wrote commands and read results. |
| What was not new? | Every technique: Kerberoasting, LSASS dumps, DCSync, Golden Ticket, WMI lateral movement. |
| Does data leave my machine? | In the incidents, the final stage was database export through the implant's encrypted C2 channel. |
| Who did it? | Unattributed. Clues point to a Chinese-speaking operator, but Kaspersky says it cannot link it to a known group. |
How CyberStrikeAI is built
According to Kaspersky's Securelist report, CyberStrikeAI puts the "intelligent" layer entirely on the control server. C2 functions, such as calling recon and exploitation utilities, managing webshell connections, assigning tasks to agents and reading results, are exposed to the model as MCP tools. The implant is a classic beacon. It polls the listener over HTTP/S, TCP or WebSocket, executes shell commands and touches the file system. To the victim it looks like a remote-control session in which a server-side model queues tasks instead of a live operator.
Kaspersky describes a two-level split of decisions. The human operator states the task in general terms. The model decides which commands to send and in what order. The implant executes. Strategy stays human; technical steps are delegated.
That design has a consequence for defenders: the compromised host contains no AI traces. There are no calls to ChatGPT or Claude from the victim, no API keys on disk and no unusual local resource use. Network traffic goes to attacker-controlled infrastructure, as in any C2 operation.
The attack chain, step by step
Kaspersky reconstructed one incident in detail.
- Human foothold. An operator reached the network through a compromised SQL Server (version 16.0.1000). The first malicious commands came from the
sqlservr.exeprocess. Over nearly a day they collected host information, deployed tools and scanned the network. - Two-week pause. Nothing happened.
- Agent installed. The CyberStrikeAI C2 agent was deployed and began taking commands from the server-side model.
- Persistence and local recon in two minutes. Kaspersky's summary says the agent established persistence and finished local discovery within about 2 minutes.
- Domain recon over five hours. The agent generated PowerShell scripts and LDAP queries, gathered data for Kerberoasting and AS-REP Roasting, and checked for LAPS and Microsoft Azure. It even looked for the
.azcopydirectory in user home folders. - A pause of several days.
- Final stage, under an hour. Lateral movement over SMB and WMI, mass credential dumping and database export.
Total elapsed time from agent deployment to domain admin compromise: three to four days, with the active phases measured in minutes or hours.
Credential access and lateral movement
The credential steps are textbook:
- Registry hives containing credentials were dumped with
reg.exe. - The
lsass.exeprocess was dumped through theMiniDumpfunction ofcomsvcs.dll, using the process ID rather than the name to make command-line signatures harder. - Once the built-in domain administrator was compromised, a renamed Mimikatz performed DCSync and Golden Ticket attacks.
- Impacket's WMIExec and PowerShell
Invoke-CimMethodcarried the implant and a reverse-shell script (p1.ps1) to other hosts, using accounts with local administrator rights.
Collection
Kaspersky highlights data collection as a place where the model adds visible value: it generated SQL and LDAP queries tailored to the environment. On an education organization's SQL server, the agent first checked the privileges of the account it was using, then pulled data through PowerShell. On file shares it scanned directories recursively before choosing files. The implant can upload and download files and take screenshots, but only when the orchestrator tells it to. The report says that in the incidents observed, data collection was the last stage.
Detection artifacts Kaspersky documents
Kaspersky lists several fingerprints that tie an implant or server to CyberStrikeAI:
- Control panel. A self-signed TLS certificate is generated at startup with the framework's name in the issuer and subject. Its
not_beforefield records the process start time, so scan history can reconstruct restarts. - Implant build metadata.
go version -mshows a build path from the built-in generator that is identical across payloads, plus version-control metadata. - Authentication header. The implant sends an
X-Implant-Tokenheader with a fixed, per-server value, both a network indicator and a way to cluster samples.
Indicators published by Kaspersky include a Windows beacon at c:\windows\temp\svchosts.exe (MD5 D726A8B4886C636F76CA6D30EF6A6FF4), another at svcmon32.exe, a renamed Mimikatz at C:\Windows\Temp\wdiag2.exe, RogueWinRM.exe, and C2 addresses 185.186.245[.]144, 104.234.26[.]163 and the domain fastcdn[.]bar. Use the report's full table rather than this summary for blocking.
Attribution: what is and is not known
Kaspersky says the activity could not be linked to a known group. The samples split into two groups with different build metadata and no shared C2 infrastructure, so the report does not tie the two clusters to one operator. The tool is public, and model-generated commands erase an operator's personal style, which weakens behavioral attribution. Chinese-language comments in scripts, use of Chinese services, and C2 restarts mostly during UTC+8 business hours suggest a Chinese-speaking operator, and the tool itself came out of the Chinese security community. Treat that as a lead, not an identification.
Why the model changes the economics, not the techniques
Kaspersky stresses that the model did not write novel exploits. It combined known methods, adapted them to what it found, and handled tool errors on its own. That matters in two ways. First, the skill barrier drops: an operator who cannot hand-craft LDAP queries or SQL exports can still ask for them in plain language. Second, command text varies from run to run, so exact-string signatures age badly; the same intent can be phrased differently each time. Behavioral detections tied to the technique, such as a process opening LSASS or a non-controller requesting directory replication, keep working because they do not depend on the wording.
The report also warns that the same architecture can assemble more complex chains on demand, naming DPAPI secret extraction and attacks on SCCM and Azure IMDS as within reach. As models improve, Kaspersky expects the operator's role to shift from setting tasks to supervising the model.
What this means if you run AI coding agents
Kaspersky's own message is that AI orchestration lowered the skill needed to run a domain takeover but did not move it beyond what defenders already detect. For readers who run coding agents, the actionable points are:
- Assume speed. Two minutes to persistence and five hours to a domain map leave little time for a human to react. Alerts on the following need to page someone: remote scheduled tasks via
schtasks.exe /s, LSASS access,comsvcs.dllMiniDump, WMI and WinRM execution from unusual hosts, and DCSync (replication requests from non-domain-controller systems). - Harden SQL Server. Look for commands spawned by
sqlservr.exe, patch, and do not expose instances to the internet. - Limit what a developer machine holds. The same domain that gets dumped probably contains laptops with
.envfiles, cloud CLI profiles, SSH keys and agent API keys. The VOLTA infostealer analysis and the Sophos report on Aur0ra operators using Cursor agents show attackers going after exactly those files. - Rotate after a domain admin compromise. Standard practice, and one that applies here: reset the
krbtgtaccount twice after a Golden Ticket, enable LAPS, and limit replication rights. - Keep the right logs. Process launches (event 4688), PowerShell script block logging (4104), logons (4624, 4768, 4769) and directory object access (4662) feed the detections.
- Do not hunt for AI on the host. Kaspersky is explicit that the model is remote. Hunt for the C2 pattern and the techniques instead.
For context on how agent-driven attacks fit together, see VAPOR PANDA and ARTEX targeting 200+ organizations in 11 days and Anthropic's September 2026 threat report on agents as orchestrators. Our October 2026 attacks timeline tracks the wider pattern. explainx.ai has the broader news coverage of AI-enabled intrusions.
What Beam can and cannot do here
Beam is local security and observability for AI coding agents. It does not monitor Windows domain controllers, does not replace EDR, and cannot see a C2 server. Where it applies is the developer endpoint: it watches what Claude Code, Codex and similar agents do, flags risky actions such as credential exposure and destructive commands, and keeps data on the device (see what Beam watches). If a coding agent you run reads .env files or cloud credentials on a developer machine, that is the kind of action Beam is designed to surface. Limits: deny is hook-based for Claude Code and Codex rather than a kernel sandbox, detection is heuristic, and it cannot stop a human or malware operating outside an agent session.
Frequently asked questions
What is CyberStrikeAI?
CyberStrikeAI is an open-source, modular penetration-testing platform written in Go. It combines an LLM orchestrator and a built-in C2 server in one process. The model plans actions and calls tools exposed over MCP, while a conventional implant on the victim host runs the commands.
Does the implant contain AI?
No. Kaspersky says the implant has no API keys, no calls to AI services and no autonomous logic. All the language-model work happens on the attacker's server, so there is nothing AI-specific to find on the compromised host.
Who was hit?
Kaspersky confirmed victims among education organizations in several countries in Africa and Latin America. It did not name the institutions or link the activity to a known threat group.
Do I need new detection rules for AI-driven attacks?
Kaspersky's conclusion is that mostly you do not. The model used familiar techniques such as Kerberoasting, LSASS dumps and DCSync, so well-tuned behavioral rules for those steps catch it. The difference is speed.
Is this a risk for people who run Claude Code or Codex?
Not directly, since no coding agent was exploited. The relevance is that a developer laptop or build server inside a compromised domain holds the same credentials and keys that the attack harvests, so rotation and monitoring matter.
Related reading
- CyberStrikeAI: 44 AI agents probed 19 organizations in Japan
- Aur0ra ransomware operators used Cursor agents
- VOLTA infostealer ranks victims with an LLM
- Wiz: seven fingerprints of agentic attacks
Details are accurate as of November 2, 2026, and are based on Kaspersky's Securelist report. Beam is a local prototype, and Kaspersky may update its findings and indicators after publication.