Kaspersky says an LLM on the attacker's server chose the commands; agent to domain admin took 3 to 4 days

Two minutes to persistence, five hours of domain reconnaissance, and a model that is not on the victim's machine

Kaspersky says that in one incident its Cyber Threat Intelligence team reconstructed, the CyberStrikeAI agent set persistence and finished local reconnaissance within 2 minutes of being deployed, then spent the next 5 hours on domain reconnaissance. Five hours is 300 minutes, which is 150 times the first step (derived). The same incident began with a human operator who used a compromised SQL Server for nearly a day and then went quiet for two weeks. From deployment of the agent to compromise of the domain administrators took 3 to 4 days, Kaspersky's summary says.

This briefing reads Kaspersky's Securelist post, dated 2 November 2026, in full, including the indicators and detection sections, on 3 November 2026, from 15:50 UTC. Help Net Security was read as a secondary, only to cross check the headline figures. Kaspersky sells the endpoint, network and SIEM products its post names, and its team says it found this campaign in its own proactive monitoring; the findings are the vendor's, not an independent test.

What that opening fact does not establish matters as much as the fact. The post gives no count of victims or incidents, names no country, gives no calendar dates for the campaign or for the incident, and prints no log, transcript or model name from the server where the model is said to run. It describes the framework's design and the style of the scripts it found, and the claim that a language model chose the commands rests on that, not on a view of the orchestrator. It also does not say whether a person approved or corrected the model's commands during the agent phase, how the SQL Server was compromised, or who the operator is.

The finding is still useful, and Kaspersky's own conclusion is the useful part: the introduction of AI into the attack chain, it says, "does not yet present fundamentally new challenges for detection", because the host sees familiar actions. What changes is the pace. The sections below set out what the post says, what it leaves open, the indicators it prints, and what a defender can do with a window of days.

What Kaspersky says it found, and what it does not count

The post's introduction says Kaspersky's team "identified a malicious campaign involving C2 agents controlled by artificial intelligence", with confirmed victims among organisations in the education sector in several countries across Africa and Latin America. CyberStrikeAI, it says, played a key role in the post exploitation phase. It is an open source framework in which an LLM orchestrator on the command and control server plans actions, selects tools and generates commands, while an implant executes them on compromised hosts. Kaspersky calls this "one of the first public descriptions of a compromise involving an LLM in the wild". That ranking is Kaspersky's own claim, and this briefing does not rank it against other vendors' reports of agentic intrusions.

Two label checks. First, "AI attack" is shorthand here for a human operated intrusion in which a model chooses the commands after entry. The post says so itself: a human operator got in and did the first phase by hand, and "the strategic planning remains with the human". Second, "Chinese speaking" is a clue based label from Kaspersky, not a government attribution and not a named group.

This is a different report, about a different actor and tool, from the CrowdStrike post on ARTEX that this site covered: CrowdStrike says VAPOR PANDA used ARTEX against more than 200 organisations. That report names a China nexus group and agents running on DeepSeek. Kaspersky names no group, and its model sits on the attacker's C2 server. Help Net Security covers both in one article, which is easy to read as one story; it is two.

The design: the model stays on the attacker's server, the implant is an ordinary executor

The post says the framework is a modular platform written in Go for automating penetration testing, and that its key feature is combining LLM based attack orchestration with a built in C2 server and agents, called beacons, in a single server process. The entire intelligent layer, it says, is isolated on the control server. Functions such as calling reconnaissance and exploitation utilities, managing webshell connections, assigning tasks to agents and reading results are offered to the model as MCP tools.

The implant is the other half. Kaspersky describes "a classic C2 agent with no AI functionality", with no API keys, no calls to AI service APIs and no autonomous logic. It polls the listener server periodically over HTTP/S, TCP or WebSocket, executes shell commands and works with the file system. To the victim, the post says, this looks like a typical remote control session in which a server side LLM orchestrator queues tasks instead of a live operator.

Zoom

The two level split is the post's argument. The operator "defines the task in general terms"; the model decides which commands to send and in what order; the implant carries them out. That is why Kaspersky says the model leaves no trace of its presence in the victim's infrastructure, such as requests to local LLMs or unusual resource use on hosts, and why communication between agents and the C2 server happens "without accessing AI platforms". A defender looking for outbound calls to an AI service from the victim network would, on this design, find none.

The post also notes a human control in the framework: the choice of persistence method is delegated to the model, but through a human in the loop mechanism, commands generated by the model "may require manual approval or correction before they are executed". That describes what the framework allows. The post does not say whether the operator used it in the incidents it describes.

The one incident the post walks through, in the order and durations it prints

Kaspersky reconstructs one incident from the campaign. In the first phase, a human operator gets in "via a compromised SQL Server (version 16.0.1000)", collects basic information about the host, deploys tools and conducts network reconnaissance. That takes nearly a day, followed by a two week pause. In the second phase the CyberStrikeAI C2 agent is deployed and takes commands from the server based orchestrator.

The post gives three durations for the agent phase: persistence and local reconnaissance within 2 minutes; domain reconnaissance over the next 5 hours; and, after "a brief pause of several days", lateral movement via SMB and WMI, mass credential dumping on hosts and a database export, with the entire operation taking no more than one hour. Its summary adds that key phases took only a few hours and that the whole attack, from agent deployment to the compromise of domain administrators, was completed within 3 to 4 days.

Zoom

That figure carries details the text does not. It labels initial access as "Medium Confidence: SQL Server Compromise", so the entry route is Kaspersky's best reading, not an observed fact. It shows two tools dropped about 36 minutes into the human phase and manual network discovery at about 24 hours. In the agent phase it shows the final burst with database access and data exfiltration at its start, then lateral movement at plus 30 minutes and credential dumping at plus 9 minutes. The text lists those three steps in a different order, and neither the text nor the figure says what each plus value is measured from, so this briefing does not add them up.

Zoom

One check the post does not make for the reader: if the pause before the final burst was about 4 days, as the figure labels it, then 4 days plus the 5 hours and 2 minutes already exceeds 3 to 4 days (derived). The labels are approximate ("about", "several"), so this is rounding and not an error, but it is why the 3 to 4 days is quoted here as Kaspersky's summary figure and not recomputed. The derived 18 to 19 days from first access treats "nearly a day" as one day and takes the two week pause as 14 days.

How Kaspersky knows a model was choosing the commands, and what it does not show

The post never shows the orchestrator. It does not say Kaspersky had access to the attacker's C2 server, and it prints no prompts, no transcripts and no model name. What it offers as evidence is indirect, and it is worth listing, because "AI controlled" is the headline claim.

None of that makes the claim wrong. It is a reasoned reading by a team that read the framework's source and saw the artefacts on hosts. It does mean the claim is best written "Kaspersky says a model chose the commands", which is how this briefing and its title carry it. The word "confirmed" in the post attaches to the victims, not to a transcript of the model.

Attribution: clues and a hedge, no named group

Kaspersky says the available data "does not allow us to link the activity to any known group of attackers", and that it cannot say with certainty that the same operator is behind both campaigns. It gives two reasons. The tool is publicly available, so different operators could have deployed it independently. And because the model generates the commands, the signature of an individual operator is largely shaped by the model, which "strips them of their individual characteristics" and weakens behavioural attribution.

The clues it does list are these: Chinese language comments in the attackers' scripts; the use of a Chinese service, dnslog[.]cn, to check internet access and learn the external address of compromised machines; and the timing of C2 restarts. The server's self signed certificate is regenerated at each start, so its not_before field records the restart time, and most of the restarts fell in business hours in the UTC+8 time zone. The tool itself "was developed within the Chinese cybersecurity community and is well known there", which the post says points "indirectly" the same way. From these Kaspersky concludes only that they "still suggest a connection" with a Chinese speaking operator.

A second, less quoted point: the implant build metadata divides the samples into two independent groups. Within each group the Windows and Linux implants have identical build metadata, which Kaspersky reads as the same working copy of the project. The two groups share no C2 infrastructure and run different versions of the framework, so the metadata links samples within a group and, in Kaspersky's words, gives no grounds to link the two groups together. That is why the post speaks of "both campaigns" and why the number of operators, one or two or more, is not stated.

What "AI powered" does and does not change on the host

The friendly name here is "AI". It suggests a new kind of weapon that needs a new kind of defence. Kaspersky's own text says otherwise: all the intelligent work stays on the attacker's side, and the compromised host "is subjected to familiar actions", from Kerberoasting and AS-REP roasting through LSASS dumps to DCSync and Golden Ticket attacks. In its words, "the novelty of the attack lies not in the methods themselves, but in the speed and ease with which they were executed", and AI orchestration "has lowered the skill requirements for the operator" without taking the attack beyond what defenders can detect.

Two things follow, and one cuts the other way. The comfort: classic, well tuned correlation and behavioural rules are, per the post, sufficient, because the agent's actions are indistinguishable from a human's. The warning: a defence tuned to a human operator's pace, a few alerts a day and a lot of waiting, is tuned to the wrong clock. The post also expects the gap to narrow: "as models evolve", it says, the operator's role will shift from setting tasks to monitoring the model's actions. That is a forecast, not a finding.

Zoom

What defenders see, and what Kaspersky advises

The post's advice is detection logic, not hardening. It says detecting the agent itself needs rules based on the agents' specific characteristics, and points to Hunt Hub filters for those. For the attack described, it says a different logic applies: because the model sat outside the network and left no traces, "classic, well-tuned correlation and behavioral analysis rules are sufficient". Its examples come from its own products, which it names: Kaspersky Next EDR Expert, Kaspersky Anti Targeted Attack (KATA), NDR with its NAD technology, Kaspersky SIEM and the Kaspersky Threat Intelligence Portal. Those are the vendor's products and its commercial interest; the behaviours they match are the useful part, and they are standard ones.

What the post says the rules look for, in words: a scheduled task created on a remote host with a standard tool; a scheduled task created as SYSTEM via the task scheduler tool; a scheduled task that runs PowerShell; LSASS memory dumped through a Windows library function; remote execution over WMI and WinRM from PowerShell; a network verdict for CyberStrikeAI agent traffic to its C2 server (traffic decrypted for analysis); and a network anomaly rule for scanning domain records with LDAP queries. For the SIEM it says the product repository holds over 100 rules for the techniques discussed, and lists the most critical, grouped by technique, in the Technical details section below.

Kaspersky also says the rules only work if the SIEM receives the relevant events. The post lists the log sources it needs, with their Windows security log event identifiers, and they are reproduced as printed below. Missing logging is the most common reason a well written rule never fires.

A ranked checklist: what the post advises and what this site suggests

The post gives detection examples and no hardening advice. Items marked "this site's suggestion" are not Kaspersky's; they follow from what the post reports. The post does not say why education was targeted, so nothing below assumes the sector matters beyond where the victims happened to be.

Technical details

Everything below is copied from the Securelist post of 2 November 2026 as read on 3 November 2026. Kaspersky shows its commands and scripts as screenshots; none of them is reproduced here, and no decoded payload, script or webshell code is given. The post cites no MITRE ATT&CK technique identifiers, so none is listed. Where this site adds a word, it says so.

How the post says to recognise a CyberStrikeAI server and implant. In words: the control panel generates a self signed TLS certificate at each start with the framework's name in the issuer and subject fields, so the not_before value records when the process was launched and the restart history can be rebuilt from scan history, as with Cobalt Strike. The implant's build metadata, read with the Go tool listed first below, contains a path to the main package that is identical across payloads, and version control fields that let samples be compared. The implant sends a fixed value in a request header, unique to each C2 server and fixed at build time. A defender uses these to cluster samples and servers.

go version -m
not_before
X-Implant-Token
vcs.modified=true

Persistence as printed. The agent created a scheduled task named SystemUpdate that pointed to the implant. The post says the framework's source shows a second route on Windows, a value of the same name under the current user's Run key, and two Linux routes, a crontab entry and a bash profile entry. Placeholders in angle brackets are Kaspersky's. The post says the choice of method is delegated to the model.

SystemUpdate
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
@reboot <path_to_beacon> &
(nohup <path_to_beacon> &>/dev/null &)
~/.bashrc

Default drop folders and the disguised name. Before launching the agent the attackers checked for its presence, and Kaspersky deduced the default deployment paths below from that check. The post says the attacker can disguise the agent as a legitimate system process and shows the name svchosts.exe, one letter away from svchost.exe. Other names printed: p1.ps1, a reverse shell script that connects out to the address shown in the indicators, and d3.b64, a file to which script fragments were written before they were decoded with the certutil utility.

C:\Windows\Temp\
C:\Windows\
C:\ProgramData\
C:\Temp
svchosts.exe
p1.ps1
d3.b64

Hunt targets in words, as the post describes them: the process that started the first commands (sqlservr.exe); commands encoded in Base64 and run through PowerShell; scheduled tasks created on remote hosts so that code runs as SYSTEM; a payload split across several files and rebuilt with certutil; registry hive dumps with reg.exe; an LSASS dump by process identifier through the comsvcs library; DCSync and Golden Ticket activity with a renamed mimikatz; Impacket WMIExec; shares and WMI for lateral movement; tool downloads that may come from the attackers' servers or from GitHub; periodic checks of Microsoft Defender detections. The post's figure also names two tools dropped in the human phase, RogueWinRM and GodPotato.

Detection names as printed. These are Kaspersky product rule names, and they are the vendor's; other products will have their own. They show which behaviours the vendor considers worth a rule.

Kaspersky Next EDR Expert:
create_task_on_remote_host_using_standard_tool
scheduled_task_creation_as_system_via_schtasks
scheduled_task_with_powershell_execution
dumping_memory_with_com_services_dll
suspicious_lsass_memory_access
using_powershell_for_remote_execution_via_wmi
winrm_send_command

KATA verdict:
Backdoor.CyberStrikeAI.HTTP.C&C

NDR:NAD rule:
Scanning domain records via LDAP queries

Execution of various commands from the sqlservr.exe process:
R300_04_Windows shell started by a web application
Downloading and executing a payload via PowerShell:
R110_03_PowerShell code downloaded and executed
Creating Windows scheduled tasks:
R099_04_Suspicious arguments when running schtasks.exe
R300_03_Windows shell started by the scheduler
Persisting via crontab or bashrc:
R099_06_Suspicious cron job activity
R405_02_UNIX shell configuration modification
Rules that aggregate detections by reconnaissance tools:
R224_14_Windows reconnaissance activity
R224_09_System information discovery by running multiple utilities within a short period
R224_04_System information discovery via standard Linux tools
Data collection for Kerberoasting and AS-REP Roasting:
R034_01_Multiple TGS ticket requests (Kerberoasting)
R452_18_AS-REP Roasting
Dumping registry hives containing credentials using the reg.exe utility:
R230_02_Copying data containing credentials from the Windows registry
Dumping the lsass.exe process using the MiniDump function of the comsvcs.dll library:
R233_04_Process memory dump via comsvcs.dll
R262_Suspicious access to the LSASS process
DCSync and Golden Ticket attacks using the renamed mimikatz utility:
R073_DC Sync attack
R450_41_Golden Ticket Attack
R100_03_Traces of Mimikatz use via cmd
Lateral movement using WMIExec:
R460_08_Lateral movement using WMIexec Impacket
R460_09_Lateral movement using WMIExec and Impacket

Process launches (Windows security log - 4688, auditd - execve) and PowerShell commands (4104)
User logins to the system (Windows security log - 4624, 4768, 4769)
Various object manipulations (Windows security log - 4662, 4663, 4656; auditd - openat)
Interaction with shared resources (Windows security log - 5145)

Indicators as printed, defanged by Kaspersky. Never browse to or connect to any of them: block, search logs and stop. The hashes are printed without a label; 32 hexadecimal characters is the length of an MD5 value (derived, the post does not name the algorithm). The post's layout puts a hash first and a path after it; the pairing of each hash with a path is not stated, so this site does not assert one. The address shown is also the one the p1.ps1 reverse shell is said to connect to, on port 5501, and the post names dnslog[.]cn as a Chinese service the attackers used to learn external addresses.

File-based indicators:
CyberStrikeAI Windows Beacon
D726A8B4886C636F76CA6D30EF6A6FF4
c:\windows\temp\svchosts.exe
2770562d104391b92b42671c270079bb
c:\windows\temp\svcmon32.exe
c:\programdata\svcmon32.exe
CyberStrikeAI Linux Beacon
09e1da2afa1216ecc55648ec8e122d2a
805B9E4AE74C903787416800999B8418
Tools & Scripts
29EFD64DD3C7FE1E2B022B7AD73A1BA5
C:\Windows\Temp\wdiag2.exe (mimikatz)
74F57B3E897A4960DCDD5B7E8A54F9DF
c:\rwx\RogueWinRM.exe
0BBD08AF95F877F1D568B03DE2EB76B4
c:\ProgramData\p1.ps1 (reverse shell PS script)

Network indicators:
185.186.245[.]144
C2 for Windows Beacon
fastcdn[.]bar
C2 for Windows Beacon
media.fastcdn[.]bar
C2 for Linux Beacon
104.234.26[.]163
C2 for Payload Delivery + Linux Beacon

The question the report leaves open

Kaspersky's post shows that a model does not need to be on the victim's machine to change how fast an intrusion moves, and that the host can look like any other intrusion. It does not show how often this happens, to whom, or who runs it. It shows one incident in which a quiet fortnight was followed by two minutes to persistence, five hours of domain reconnaissance and a domain admin compromise inside four days.

If your database server is quiet for two weeks and then a shell starts under it, what in your estate raises an alert within the first five hours, and who is awake to read it?

Key facts