CyberStrikeAI in the Wild: An LLM Orchestrator Reached Domain Admin at Education Targets in Latin America and Africa

On 2 November 2026 Kaspersky published a Securelist report and a press release describing intrusions at education-sector organisations in several countries across Latin America and Africa in which the post-exploitation work was directed by a large language model. The tool was CyberStrikeAI, an open-source, Go-based penetration-testing framework whose command-and-control server hosts an LLM that selects tools and writes commands while an ordinary implant executes them on the victim host. In the one case Kaspersky reconstructs in detail, a human operator entered through a compromised Microsoft SQL Server, paused for two weeks, then let the agent run: domain administrator accounts fell within three to four days, and the last stage — lateral movement, mass credential dumping and a database export — finished inside an hour. Kaspersky names no institution and no country, gives no victim count, and says it observed the activity between September and October 2026. The full record for this campaign, with its severity grade, confidence rating and complete source list, is filed in the Orca AI Incident Archive, alongside the other entries on AI-assisted intrusions.

What Kaspersky actually published

The primary document is "CyberStrikeAI in the wild: the use of AI in real-world attacks on organizations," published on Securelist on 2 November 2026 and credited to Kirill Antonov, Vladislav Vlasov and Dmitry Chizhmak of Kaspersky's threat research team. It is accompanied by Kaspersky's own press release, issued the same day, which summarises the same findings. The archive's confidence grade of A describes how well those two documents agree with each other and how specific the technical detail is; it is not a statement that a second organisation has verified the intrusion independently.

The secondary coverage of this report does not supply that second organisation. Cybersecuritynews.com, Cyberpress, SecurityOnline and the Nairobi-based TechTrends Kenya all published accounts between 2 and 3 November 2026, and each one derives from Kaspersky's release rather than from its own investigation; the Kenyan outlet's piece is built around the same press-release quote from Nikita Nazarov, head of Threat Exploration at Kaspersky. As of 9 November 2026 no affected university, ministry of education or national computer emergency response team had publicly confirmed the intrusions, and Kaspersky has not published the victims' identities. That absence is itself part of the record: what is documented in detail is the tradecraft, not the harm to any named institution.

Kaspersky's scope statement is deliberately narrow. Confirmed victims, in its words, were "organizations in the education sector in several countries across Africa and Latin America." It does not say how many, which countries, or how the campaign was detected in the first place — only that the team found it "as part of proactive threat monitoring."

One distinction matters here, because it is easy to blur. Independent organisations have now reported CyberStrikeAI in real intrusions — but not these intrusions. Team Cymru tied infrastructure running the tool to the January–February 2026 campaign against more than 600 FortiGate devices, having observed 21 unique IP addresses serving it between 20 January and 26 February 2026. Trend Micro's TrendAI unit, in research published on 23 October 2026, described an operator running 44 coordinated CyberStrikeAI agents that subjected at least 19 identifiable organisations, at least 16 of them in Japan, to validation activity in a short window that October. The Cloud Security Alliance's research note of 28 October 2026 assembles both and concludes that no published source had yet linked the separate CyberStrikeAI campaigns to a single actor. That body of work corroborates the premise — that this framework is being used to attack real networks — and says nothing about the Latin American and African education victims in Kaspersky's report.

The tool, and where the AI actually sat

CyberStrikeAI, as Kaspersky describes it, is "an open-source, modular platform written in Go for automating penetration testing." Its defining design choice is that the entire intelligent layer lives on the attacker's control server, not on the victim's machine. Reconnaissance and exploitation utilities, webshell management, task assignment to agents and the reading of results are all exposed to the model as MCP tools inside a single server process, and it is the model that decides which of them to call next.

The implant is the other half, and it is deliberately stupid. Kaspersky writes that it is "a classic C2 agent with no AI functionality — no API keys, no calls to AI service APIs, and no autonomous logic." It polls the listener over HTTP/S, TCP or WebSocket, runs shell commands, and touches the file system. It is not a model running in a victim's network, and it never contacts an AI provider. The division of labour is the sentence Kaspersky uses to explain the whole scheme: "Decisions are distributed across two levels: the operator defines the task in general terms, while the model determines how to execute it."

Human control is retained rather than removed. Kaspersky notes a human-in-the-loop mechanism under which "the operator retains full control over the process," and that commands generated by the model "may require manual approval or correction before they are executed." The AI writes the steps; a person can still refuse them.

One reconstructed intrusion, in the order Kaspersky dates it

The report follows a single incident inside the campaign, and its first phase looks like ordinary hands-on-keyboard work. Commands on the victim's systems came from the sqlservr.exe process, pointing to "a compromised SQL Server (version 16.0.1000)" as the likely way in. The operator then collected basic host information, deployed tools and mapped the network by hand. That took "nearly a day," after which the attackers went quiet for about two weeks.

The second phase is where the tempo changes. With the CyberStrikeAI agent deployed, persistence and local reconnaissance were done "within 2 minutes" — a scheduled task named SystemUpdate pointing at the implant, with a registry Run key under HKCU\Software\Microsoft\Windows\CurrentVersion\Run as the framework's alternative on Windows, and a crontab @reboot entry or a nohup line in ~/.bashrc as its alternatives on Linux. Domain reconnaissance ran "over the next 5 hours," using PowerShell scripts the model generated and LDAP queries against Active Directory, including the lookups needed to prepare Kerberoasting and AS-REP Roasting and checks for LAPS, Azure and .azcopy directories. After "a brief pause of several days," the final stage — lateral movement over SMB and WMI, mass credential dumping, and a database export — took "no more than one hour."

Kaspersky's summary line is the one worth keeping: the whole attack, "from agent deployment to the compromise of domain administrators – was completed within 3–4 days."

The credential work is a catalogue of well-known Windows techniques rather than anything new: registry hives copied out with reg.exe, lsass.exe dumped through the MiniDump function of comsvcs.dll using the process ID rather than its name to defeat command-line matching, and — once the built-in domain administrator account was compromised — DCSync and Golden Ticket attacks run through a renamed Mimikatz binary, wdiag2.exe. Lateral movement used Impacket's WMIExec, shared administrative folders and WMI, with a reverse-shell script, p1.ps1, pushed to remote hosts and calling back to 185.186.245[.]144:5501. Payloads were split into fragments such as d3.b64 and reassembled with certutil, and one beacon masqueraded as svchosts.exe.

Collection came last. The agent generated SQL queries tailored to the task but checked the database account's privileges before running them, scanned network shares recursively before pulling files, and returned everything over the same encrypted C2 channel with the data Base64-encoded inside JSON. Screenshots on both Windows and Linux were available but, in Kaspersky's account, taken only when the orchestrator issued the command. The report states that data collection "was the final stage of the attack: the chain ended there, and we observed no further activity."

What was taken, and what the record does not say

Kaspersky records that the agent exported database records from the education organisation's SQL server and collected files from network resources, and it describes the mechanism in detail. It does not say how many records or files left, whether the export completed, or whose data was in the tables. Secondary summaries go further than the report does on this point: SecurityOnline's write-up says the agent "generated targeted SQL queries to steal student and staff records from database tables," while Kaspersky's own text describes the queries against an education SQL server without specifying what the tables held. Readers should treat the "student and staff records" description as a secondary characterisation, not a Kaspersky finding.

Also absent from the record: whether any victim detected the intrusion itself, what each institution did afterwards, whether regulators or data-protection authorities in the affected countries were notified, and whether the campaign is still running. Kaspersky says only that data collection was the last observed step in the incidents it examined. The press release contains no remediation guidance for the affected organisations — its recommendations are aimed at defenders generally.

Attribution: what the evidence supports, and what it does not

Kaspersky is explicit that it cannot name an actor. "The available data does not allow us to link the activity to any known group of attackers, nor to state with certainty that the same operator is behind both campaigns." The artefact it leans on is the Go build metadata inside the implants, which carries version-control hashes, commit times and a dirty-working-copy flag — "a unique fingerprint for a specific build." On that basis the samples split into two groups, and within each group the Windows and Linux payloads share identical metadata, meaning they came from the same working copy.

The groups do not join up. They "do not share a common C2 infrastructure," and different versions of CyberStrikeAI were running on the two sets of control servers. Kaspersky gives two reasons attribution is hard here: the framework is publicly available, so different operators could have built payloads independently under similar conditions, and the commands themselves are model-generated, which inflates their variety while stripping out the individual habits that behavioural attribution depends on.

What remains is suggestive rather than conclusive. Some scripts carried comments in Chinese, the attackers used the Chinese service dnslog[.]cn to confirm internet access from victim hosts, and most control-server restarts — recoverable because the self-signed TLS certificate is regenerated in memory at each start, so its not_before field records the restart time — fell inside UTC+8 business hours. CyberStrikeAI itself was developed within the Chinese cybersecurity community. Kaspersky's press release draws the line plainly: these artefacts "do not establish the attackers' identity or location," and the company "could not attribute the activity to a known threat group or confirm that the same operator controlled all identified infrastructure." A Chinese-speaking operator is an inference, not a finding.

Why Kaspersky says this is not a detection emergency

The report's conclusion pushes back on the idea that an LLM in the kill chain requires a new class of defence. Because the model lives on the attacker's server, it "left no traces of its presence in the infrastructure (such as specific API requests to local LLMs or anomalous patterns of resource consumption by hosts)." What defenders see instead is a human-shaped intrusion: the same utilities, the same sequences, the same event log entries. Kaspersky's verdict is that "the introduction of AI into the attack chain does not yet present fundamentally new challenges for detection," that "classic, well-tuned correlation and behavioral analysis rules are sufficient," and that the novelty "lies not in the methods themselves, but in the speed and ease with which they were executed."

The published detections follow that logic rather than inventing new ones. Kaspersky Anti Targeted Attack raises the network verdict Backdoor.CyberStrikeAI.HTTP.C&C on the implant's traffic; a network anomaly detection rule named "Scanning domain records via LDAP queries" catches the domain reconnaissance; Kaspersky SIEM ships more than 100 rules covering the techniques in the report, including DCSync, Golden Ticket, Kerberoasting and Impacket WMIExec; and the implants are classified as HEUR:HackTool.Win64.CyberStrike.gen and HEUR:HackTool.Linux.CyberStrike.gen. Kaspersky's guidance to customers is conventional — endpoint detection and response, network detection, threat intelligence, and monitoring outside working hours or through a managed service.

Nazarov's statement in the press release is the same argument in one sentence: the attackers "used an AI agent based on CyberStrikeAI to carry out a full attack chain and adapt their next steps within compromised networks," but "the framework still relied on familiar techniques and procedures, including discovery, credential dumping, lateral movement, and collection and exfiltration."

What is established, and what is not

Stated plainly: the mechanism is documented to a level that would let a defender hunt for it tomorrow — process ancestry from sqlservr.exe, a scheduled task named SystemUpdate, LSASS access through comsvcs.dll, DCSync from a non-domain-controller, the X-Implant-Token HTTP header, and the C2 addresses Kaspersky lists. The campaign around that mechanism is not. Kaspersky published no victim list, no country breakdown, no data-volume estimate and no actor. Everything a reader might want to know about who was harmed and how badly stops at the sector and the region.

Two details are worth flagging for anyone who goes to the report expecting more. First, Kaspersky describes the attack as "one of the first public descriptions of a compromise involving an LLM in the wild" rather than the first — a hedge that keeps the claim to what the team could find in public reporting. Second, the report notes that the implant's version does not track the server's, that listener configurations and keys survive operator updates, and that a sample's build date gives only an earliest possible deployment date, not the length of a compromise. The 3–4 day figure is a measurement of one reconstructed incident, not a bound on how long any of these intrusions ran before someone noticed.