For Windows administrators, the distinction matters. This was not evidence of an AI inventing an unprecedented attack. It was evidence that assistance with analysis, scripting and troubleshooting may help an intruder make better use of access already obtained.
What changed when the commands changed
Symantec describes activity across an internet-facing Windows web server and at least six other servers, most running Microsoft SQL Server. The retailer is unnamed, and the initial infection vector remains unknown. The earliest observed malicious activity occurred on September 18, 2026, on three SQL Server hosts—before the web-server phase that provides the clearest before-and-after comparison.
On the web server, the contrast was striking:
| Observation | September 22 | September 23 |
|---|---|---|
| Command activity | 110 distinct actions | Around 50 long scripts over roughly two hours |
| Command length | About 45 characters on average | More than 500 characters at the median |
| Typing errors | Three, corrected shortly afterward | None observed |
| Approach | Repeated attempts to launch a blocked loader | Combined probes, structured output and revised strategies |
Those measurements are not quite apples to apples: one length figure is an average, the other a median. Nevertheless, Symantec’s account describes a substantial change in command structure and operator behavior, not merely longer lines of PowerShell.
The scripts grouped several checks together, labelled their results, handled errors and limited output. More revealingly, some contained comments explaining why an earlier conclusion needed revisiting. In one instance, the comments questioned results obtained through a SOCKS proxy and proposed repeating the checks from a host with a direct network route. Symantec considers that embedded deliberation stronger evidence of AI assistance than tidy formatting alone.
The confidence levels deserve to stay attached to the claim. Symantec assesses AI assistance with high confidence, but a human relaying results between an AI tool and the compromised server with only moderate confidence. Submissions were never less than seven seconds apart, and strategy changes followed pauses of two to eight minutes. The researchers could not identify the model or service. Similar structured scripts appeared on database servers on September 18, so September 23 was not necessarily the attackers’ first use of AI within this network.
The reasonable conclusion is therefore narrower than “an autonomous AI hacked a retailer”: the telemetry strongly suggested assistance, while the precise workflow remained unobserved.
A Windows intrusion built from familiar components
The early database activity showed cmd.exe running beneath sqlservr.exe. Symantec interprets that as command execution through SQL Server, most likely using xp_cmdshell. Attackers searched point-of-sale synchronization folders for credentials and connection strings, then assembled and compiled EfsPotato on one host before saving the SAM, SYSTEM and SECURITY registry hives.
There is useful Microsoft context here. xp_cmdshell is disabled by default on new SQL Server installations, and Microsoft recommends generally leaving it disabled. Where legacy workloads require it, Microsoft advises enabling it only for the task that needs it. Its presence in an attack does not, by itself, establish a SQL Server vulnerability; administrators must investigate configuration, permissions and the credentials used.
Microsoft also documents an important privilege boundary: commands invoked through xp_cmdshell by a sysadmin execute in the SQL Server service account’s security context. Non-sysadmin execution can instead use a configured proxy account. Consequently, reviewing the feature’s enabled state is only part of the job; service-account rights and execution permissions determine how damaging its misuse can become.
On the IIS server, the attackers’ commands appeared beneath w3wp.exe, consistent with execution through a compromised web application. They placed ASP web shells in an images directory and attempted DLL sideloading using legitimate Bitdefender and G DATA executables beside malicious companion files. Security software repeatedly terminated launches.
The operators then introduced BreakChain, a utility intended to relaunch payloads without leaving them directly beneath the IIS worker process. They used shell and WMI launch modes, obtained another build about 75 minutes after the first was blocked, and copied one executable to a ProgramData file named w3wp.exe. These were attempts to change how execution appeared to defenders—not proof that every defensive control had been defeated.
The practical lesson is straightforward: a familiar filename is not an identity, and a blocked launch is not necessarily the end of an intrusion.
The pivotal move: Orion’s RabbitMQ shared secret
The most consequential sequence began with credential collection. Symantec says the attackers examined connection strings, IIS configuration, transfer-client settings, saved RDP files and other locations that might contain useful authentication material. They also queried Orion’s local SQL Server data, read a Zabbix agent pre-shared key and tested privileges on remote SQL Servers using credentials already held.
They then found the RabbitMQ component bundled with the victim’s Orion installation and read its .erlang.cookie file. Using the bundled Erlang executable and that shared secret, they issued a remote procedure call to a RabbitMQ node on another web server. The first operating-system command checked the execution identity; subsequent calls targeted registry locations associated with stored credential material. About ten minutes separated the first Orion service query from the lateral-movement breakthrough.
RabbitMQ’s own clustering documentation explains why the cookie matters: nodes and command-line tools use the shared secret to authenticate communication, and cluster members share its value. The documentation says the cookie file must be accessible only to its owner. This is infrastructure authentication material, not an ordinary application preference file.
That primary-source context sharpens the defensive takeaway. Protecting a monitoring system means protecting its supporting services and their secrets, not just its web console.
The report does not establish that every Orion installation is susceptible to this exact path, identify an affected-version range, or attribute the activity to a new Orion vulnerability. Its documented sequence concerns stolen authentication material and reachable infrastructure in this victim’s environment.
The intrusion continued beyond the breakthrough
Symantec’s timeline extends through at least September 29. Further activity included registry-hive exports, searches for the Active Directory database, attempts to locate Group Policy Preferences passwords and LAPS-managed passwords, internal service scanning, and password spraying from an older SQL Server host. Commands on one machine suggested it might also be a domain controller, although that role was inferred rather than definitively established.
The researchers also found loader and infrastructure overlaps with an August intrusion at another organization and a July intrusion at a securities firm. Neither earlier incident showed signs of AI assistance. That supports the interpretation that AI was added to an existing operational toolkit rather than generating the entire operation.
Attribution remains unsettled. The publicly available Yuze tunnelling tool appeared in the August case, but its use does not establish a connection to Warlock ransomware or Longlegs, also known as Storm-2603. Symantec additionally identified a possible connection to a retailer-focused operation reported by Gambit Security: a shared address, retail targeting and searches for point-of-sale credentials. Those overlaps are suggestive, not conclusive. Symantec reported no observed data theft or encryption in the retailer incident; credential collection should not be confused with proof that payment-card data was exfiltrated.
Other cases show a broader pattern—not one proven campaign
The retailer investigation sits alongside several other cases in Symantec’s report. They should not be treated as a single attributed operation merely because the commands looked similar.
- Vietnamese university, June 2026: Attackers modified a compromised web server, attempted to obtain PrintSpoofer and reconstructed the tool from text after downloads failed. Chinese-language notes embedded in a script appeared to address the operator.
- East African ICT provider, late August: During approximately 61 hours of activity, attackers sought domain credentials and mobile-payment integration secrets. One phase contained 212 long, structured scripts without observed typing errors.
- South Asian hydroelectric company, August: Following manual reconnaissance, attackers used structured PowerShell for database credential testing and lateral-movement attempts. One script retained an unedited address placeholder.
- South Asian hosting server, July: Roughly 970 commands accompanied credential searches, database access and persistence attempts. After a security product blocked an exploit download, the operators tried several alternative retrieval methods.
- Three linked South Asian cases: Shared infrastructure or tools accompanied web-server compromise, privilege escalation, persistence and tunnelling. One organization saw 290 commands in 28 minutes; another remained subject to malicious activity into early October.
Across these examples, Symantec’s central observation was faster adaptation using established techniques. Some command timing suggested automation, but the available evidence usually could not settle whether a human was supervising each step.
What Windows security teams should prioritize
The following priorities are defensive analysis drawn from the documented behaviors, rather than a claim that one checklist can remediate every affected environment:
- Correlate IIS and SQL Server execution. Investigate unexpected shells, PowerShell activity and downloaded executables associated with web or database services. Expand the timeline beyond the first blocked payload.
- Review database-to-operating-system privileges. Confirm whether
xp_cmdshellis required, who can invoke it and which Windows identity executes its commands. Microsoft’s guidance favors disabling unnecessary use and limiting privileges where execution is justified. - Treat configuration-file access as potential credential exposure. Include IIS settings, connection strings, transfer-client configurations and monitoring secrets when scoping an incident—not just malware files.
- Protect broker authentication material. Review access to Erlang cookie files and the hosts that can communicate with broker nodes. RabbitMQ explicitly treats the cookie as a shared authentication secret with restricted file access.
- Look for credential collection and adaptation. Registry-hive exports, unexpected compilation with
csc.exe, new ProgramData payload folders, renamed binaries and altered launch ancestry deserve investigation together, rather than as unrelated alerts.
The enduring lesson is not that familiar Windows security controls have become obsolete. In this investigation, those controls repeatedly interrupted payload execution. The concern is what happened next: the operators appeared to become more effective at diagnosing failure and selecting another route. Defenders should plan around that shorter recovery cycle—not wait for an unmistakable “AI attack” signature that the evidence does not promise.