CyberStrikeAI: How an LLM Orchestrated C2 in a Real Intrusion

Kaspersky documented an LLM orchestrated C2 campaign against education-sector organizations in Africa and Latin America. CyberStrikeAI's model ran on the attacker's server and chose post-exploitation commands for a plain beacon with no AI logic. Once the final stage began, lateral movement, mass credential dumping and database export finished in under an hour.

What Kaspersky actually confirmed

Kaspersky’s Cyber Threat Intelligence team found the campaign during proactive threat monitoring. Confirmed victims are education-sector organizations in several countries across Africa and Latin America. The report does not list the countries, give a victim count or name a threat actor.

Kaspersky calls the case one of the first public descriptions of a compromise involving an LLM in the wild. Until recently, attackers used models in preparation: phishing emails, debugging code, hunting for vulnerabilities. Here the model sat inside the operation and drove payload execution, persistence, discovery, lateral movement, collection and exfiltration.

The operator states the task in general terms. The model picks which commands to send and in what order, and the implant executes them.

• No named threat actor. Kaspersky does not attribute the campaign.
• No calendar dates. The timeline is given in minutes, hours, days and weeks.
• No CVE and no patch. Initial access ran through a compromised Microsoft SQL Server. How that server was compromised is not established.
• Chinese-language comments appear in some delivered scripts. Kaspersky reports them as an observation, not an attribution. The framework is open source, so anyone can run it.

For a separate public report on the same framework, see our coverage of CyberStrikeAI’s Japan cluster. Kaspersky’s addition is a host-level reconstruction from inside victim networks.

Where does the model sit in an LLM orchestrated C2 setup?

Entirely on the attacker’s control server. The implant on the victim host is a classic beacon with no AI logic, so a hunt for a chatbot on the endpoint misses the intrusion. The host sees a beacon, PowerShell and stock Windows utilities.

CyberStrikeAI is an open-source, modular penetration-testing platform written in Go. One server process holds the LLM orchestrator, a built-in C2 server and the agents. C2 functions reach the model as MCP tools. Model Context Protocol is how an AI application calls external tools, and here it connects the model to the attacker’s C2 tooling.

Layer	Runs on	What it does
LLM orchestrator	Attacker’s control server	Plans actions, selects tools, generates commands
MCP tool layer	Attacker’s control server	Exposes recon and exploitation utilities, webshell management, agent tasking and result reading
Human operator	Attacker side	Sets the task; can approve or correct model-generated commands
Implant (beacon)	Victim host	Polls the listener over HTTP/S, TCP or WebSocket; runs shell commands; reads and writes files

The implant does none of the thinking. Kaspersky found no API keys in it, no calls to AI service APIs and no autonomous logic. The LLM decides which tasks get queued, not how they reach the host. To the victim, the traffic looks like an ordinary remote-control session whose queue is fed by a model instead of a live operator. There is no on-host AI malware to signature, and blocking AI-provider domains on egress does nothing, because that traffic leaves the attacker’s server.

Implant and server versions are decoupled. Listener configuration and keys survive server updates, so one agent build can run for months while the operator upgrades orchestration. In the incidents Kaspersky examined, a single agent version ran throughout. A sample’s build date gives the earliest possible date of the infrastructure, not the length of the compromise.

The choice of persistence method is delegated to the connected LLM, but model-generated commands may require manual approval or correction before execution. A model drafts the next move at machine speed, and a human holds a veto that may or may not get used.

If you run MCP in your own stack, tool schemas that reach shell, file or network actions deserve the scrutiny you give an admin API. MCP server and tool-chain security testing checks whether a confused model, or a hostile document steering one, can drive those tools past the approval gate.

Why did a day of manual work precede an hour of domain loss?

The operator did the judgment-heavy work by hand and handed breadth to the model. The clock collapsed only after the CyberStrikeAI agent was running. Kaspersky’s reconstruction of one incident shows two phases separated by long quiet gaps.

Phase one: an operator working by hand inside SQL Server

The first malicious commands on victim systems came from sqlservr.exe. Kaspersky reads that as the likely initial access vector and the context in which the attacker gained code execution. Everything before the agent arrived was typed by the operator inside that process.

Kaspersky records the SQL Server version as 16.0.1000 and stops there. Weak credentials, an exposed instance or a separate vulnerability all remain possible, and the report does not choose among them.

Inside that process the operator spent nearly a day collecting host information, deploying tools and mapping the network. Then activity stopped for two weeks.

Phase two: the agent compresses the clock

Once the agent was deployed, the gaps between steps shrank from days to minutes.

Stage	Duration	Who
Host information, tool deployment and network reconnaissance	About 1 day	Human operator
Pause	Two weeks	Human operator
Persistence and local reconnaissance	About 2 minutes	CyberStrikeAI agent
Domain reconnaissance	About 5 hours	CyberStrikeAI agent
Pause	Several days	Human operator
Lateral movement via SMB and WMI, mass credential dumping, database export	Under 60 minutes	CyberStrikeAI agent

Kaspersky says the attackers went “from reconnaissance to full domain compromise.” The final stage is SMB and WMI movement, credential dumping across hosts and a database export, all inside one hour.

A model was in the workflow before the agent

Before the agent was installed, the payload was split across files: fragments were written in sequence into d3.b64, decoded with certutil and executed. Kaspersky says these scripts, delivered at a stage that usually needs a human, “clearly bear the hallmarks of being generated by an LLM.”

Once assembled, one script decrypted DPAPI secrets from C:\ProgramData\dsn_line.txt. A separate command had filled that file with a DSN connection string pulled from the SQL Server Reporting Services config, rsreportserver.config. Some of these scripts carry Chinese comments, which Kaspersky records as a fact about the files, not an actor name.

The report does not say how the operator produced those scripts, only that they look model-written. Deploying the agent moved the model into the execution loop. We read the pauses as the human part, plausibly a decision on whether a target was worth the next step. That reading is our inference. The minutes and hours between pauses are the machine.

What did the operator's model actually task?

A standard Windows post-exploitation sequence: PowerShell, scheduled tasks, WMI, administrative shares and file staging. Kaspersky presents no new exploit primitive. What changed is who picked the order, and how little time the sequence needed once the agent was live.

Deployment and execution

• Before the drop, a PowerShell script checked the agent’s default deployment paths: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\ and C:\Temp.
• The file name can imitate a system process. In the incident it was svchosts.exe, one letter off svchost.exe.
• The agent runs payloads through PowerShell, with commands Base64-encoded to get past keyword-based detection.

Persistence

• The first step on the host was a scheduled task named SystemUpdate whose action is the implant path.
• With administrative rights, including a domain administrator account, the agent on remote hosts often created scheduled tasks so payloads ran as SYSTEM, using schtasks or the Schedule.Service COM object, which skips schtasks entirely.
• Source code also writes a Run value named SystemUpdate under HKCU\Software\Microsoft\Windows\CurrentVersion\Run. That path is in the code, not a confirmed artifact in every incident.

Discovery

• Before the agent, the operator gathered basic system information with a small manual command set and ran net.exe against remote hosts.
• Internet access and external IP were checked through dnslog[.]cn, which issues a random third-level domain and shows the external address if the host resolves it.
• The agent mapped privilege-escalation paths through SCCM, or through msiexec where AlwaysInstallElevated is set.
• It inventoried services running under domain accounts and tasks running as SYSTEM, and periodically checked Microsoft Defender detections.
• In the main phase it used PowerShell’s built-in functionality for remote discovery, with obfuscated LDAP queries.

Collection and exfiltration

The attackers obfuscated SQL queries during collection, as they did LDAP queries during discovery, and the final stage ended in a database export. The exfiltration channel, exported tables and data volume are not in the material we reviewed. Check database-tier egress and large outbound transfers in the hour after lateral movement starts.

Reporting Services connection settings plus decrypted DPAPI secrets from dsn_line.txt would hand an operator database credentials. That link is our inference; Kaspersky does not spell it out.

The final hour

After a pause of several days, lateral movement ran over SMB and WMI. Administrative shares and WMI carried scripts such as the reverse-shell payload p1.ps1 to other hosts. Kaspersky reports mass credential dumping on those hosts and the database export in the same window.

How do you detect LLM orchestrated C2 when the model is off-host?

Detect it the same way you detect a human behind a beacon: process lineage, persistence artifacts and identity behavior. There is no on-host AI signature. Final-stage alerts need a response measured in minutes, because that stage finished in under an hour.

Hunting reference

Artifact	Where to look	Meaning
sqlservr.exe parenting a shell	Process telemetry	Likely initial access context
C:\Windows\Temp\, C:\Windows\, C:\ProgramData\, C:\Temp	File system	Default agent paths
svchosts.exe	File and process names	Masqueraded agent
d3.b64 followed by a certutil decode	File writes, process telemetry	Staged script assembly
Reads of rsreportserver.config; C:\ProgramData\dsn_line.txt	File access	DSN and DPAPI secret theft
p1.ps1	Admin shares, WMI	Reverse-shell payload in lateral movement
Task and HKCU Run value named SystemUpdate	Task Scheduler, registry	Persistence
@reboot crontab entry; nohup line in ~/.bashrc	Linux user config	Persistence
dnslog[.]cn lookups	DNS logs	Egress and external IP check
Self-signed TLS cert with the framework name in issuer and subject	Internet scan data	Control panel; not_before marks process start
Go build path with the generator’s temporary directory	Sample analysis (go version -m)	Clustering payloads
X-Implant-Token HTTP header	HTTP, decrypted TLS	Links samples to one C2 server

Kaspersky’s report also lists the server that p1.ps1 called back to. Our editorial policy is not to reprint C2 addresses, so take network indicators from the vendor advisory.

Framework markers, used carefully

These markers help clustering more than blocking. The panel certificate is regenerated in memory at each launch, so scan history of its not_before field reconstructs restarts, the same approach analysts use with Cobalt Strike. The build path is identical across generated payloads, and VCS metadata in the build info lets samples be compared. The token is fixed per server, embedded at build time, and hidden inside HTTPS unless you inspect TLS. The certificate changes on every restart. Pair the markers with host behavior.

Practitioner notes (ours, not Kaspersky’s)

The sqlservr.exe parent rule is easy to leave in a backlog. SQL Server service accounts are often over-privileged, and database hosts produce noise that SOCs learn to ignore. Confirm the rule exists and fires.

Base64 hides keywords from string matching, not from PowerShell’s own logging. With Script Block Logging enabled, PowerShell records the decoded script block, which is where keyword content should run.

Someone on the attacker side may have approved each command, and you will never see that record. Build the timeline from your own telemetry: process starts, task creation, share writes and authentication. Our piece on the agent incident identity record covers the defending side.

What should a CISO change when the attacker moves at machine speed?

Plan for about one hour from the start of lateral movement to domain loss, and test whether detection and escalation fit inside it. The human pauses, two weeks and then several days, were the long opportunities. Once the model-driven stage resumed, the last step took under 60 minutes.

• Triage SLAs. A credential-dumping or unusual-admin alert that waits four hours for review arrives after the domain is gone. Alerts of that class on Tier-0 assets need an on-call page or automatic containment.
• Detection validation over vulnerability counts. No CVE exists for this chain, so a scanner report would not describe it. Run the behaviors above as a timed exercise and record how many minutes each alert took.
• Start from the foothold. An assumed breach assessment that begins inside a database service account reproduces the part of this incident Kaspersky actually measured.
• Close the paths the model went looking for: SCCM elevation, AlwaysInstallElevated, services running as domain accounts, and broad rights on the SQL Server service account.

CyberStrikeAI’s shape is a model, MCP tools with real side effects, and a human approval gate. The same shape now runs IT automation and coding agents inside many companies. The attacker’s gate is a convenience. Yours only works if something checks that the executed tool call matches the action a human approved. That check is a core scope item in AI agent penetration testing: tool permissions as enforced, approval gates as tested, and blast radius when hostile input reaches the model.

What is still unknown?

We do not know who ran the campaign, how many organizations were hit or in which countries. Without calendar dates, the report does not show whether the activity is ongoing.

We do not know how the SQL Server instances were compromised. Version 16.0.1000 is a data point, not a root cause, and there is no CVE to ticket.

We also do not know how often the operator used the approval gate. Kaspersky confirms the mechanism but not whether the operator reviewed every command, a subset or none. That gap decides how campaigns built this way scale.

FAQ

What is CyberStrikeAI?

An open-source Go platform that puts an LLM orchestrator, a built-in C2 server and agents in one process. The model calls C2 functions as MCP tools. The implant only polls the listener and runs commands.

Did an AI model run on the victims' machines?

No. Kaspersky found no API keys, no calls to AI service APIs and no autonomous logic in the implant. The model ran on the attacker's server and chose which commands to queue.

How fast did the CyberStrikeAI agent move?

Persistence and local reconnaissance took about two minutes, domain reconnaissance about five hours. After several days, SMB and WMI movement, mass credential dumping and database export took under an hour.

How do you detect LLM orchestrated C2?

With beacon telemetry: sqlservr.exe parenting PowerShell or certutil, a SystemUpdate task or Run value, Schedule.Service task creation, and WMI or admin-share fan-out. The response has to fit the one-hour final stage.

If your team needs to know whether detection fires inside a one-hour window, our AI-powered penetration testing replays chains like this one under a human operator and times every alert along the way.