In September 2026, attackers broke into a U.S. retail organization but struggled to progress the intrusion. Overnight their pattern of activity changed, and it was clear that they began using an AI to assist them and find a way around the obstacles thrown in their path.
None of the techniques used in this second phase of the attack were new. What changed was how quickly the attackers identified a complex workaround and how reliably it was applied. About 10 minutes after first querying the SolarWinds Orion service on the victim’s server, they had identified an unfamiliar message broker, taken its shared secret and used it to reach another host.
Some of the scripts used carried comments that appear to record a model's reasoning, and the timing between commands points to a human operator relaying output to an AI tool rather than an autonomous agent.
The primary victim was a U.S. retail organization. The attackers worked across its internet-facing web server and at least six further servers, most of which ran Microsoft SQL Server. They searched point-of-sale synchronization scripts for stored passwords, which may indicate a focus on retail systems.
Symantec also found overlaps in loader files and infrastructure with an August 2026 intrusion at a different organization and a July 2026 intrusion at a securities firm. Neither showed signs of AI assistance. The staging server used in August was the same one used against the retailer, and a reverse proxy tool known as Yuze also appeared on a host at that organization.
Activity on the web server began on September 21, 2026, with a short burst of discovery commands, followed by a gap of about 12 hours. When it resumed on September 22, the commands showed the marks of manual typing. Across 110 distinct actions there were three typing errors (including systemifo and pwoershell), each corrected within seconds, and the command lengths averaged about 45 characters.
The attackers re-ran the same blocked loader five times in about 20 minutes with no change of approach.
On September 23, the attackers executed around 50 long scripts over roughly two hours. The median script ran to more than 500 characters, over 10 times the length of the hand-typed commands. None of the scripts contained a typing error.
Each submission bundled several probes, labelled each result with a banner such as ===FILES MENTIONING CONN STRINGS===, wrapped cmdlets in error handling and capped the amount of output returned. That layout suits a consumer reading results back through a narrow text channel, and it is a common pattern in code generated by large language models (LLMs).
The strongest evidence of AI usage was in the comments. Several scripts opened with text that stated a hypothesis, cited earlier results and revised a previous conclusion before acting. One recorded that earlier negative results about a server had come from a SOCKS proxy channel known to report false successes, so the conclusion had to be re-measured from a host with a direct route.
Human operators do not usually write that kind of deliberation into a one-shot web shell command.
The gap between submissions never fell below seven seconds and longer pauses of two-to-eight minutes came before changes of strategy. There was no scanner-style burst activity and no fixed-interval beaconing. This is consistent with an operator copying output into an AI tool and pasting the next command into the web shell.
Symantec assesses the AI assistance with high confidence and the operator-in-the-loop model with moderate confidence. The model or service involved could not be identified.
Similar labelled scripts also appeared on September 18, 2026 on three database servers in the same network, so the web server was not the first place the attackers appeared to use AI. Comments disappeared from the data between September 19 and 22 and returned in a different style, which may mean that more than one AI model was in use.
The attackers downloaded an old, legitimate Bitdefender executable (bdreinit.exe) with a malicious DLL (log.dll) and a file named log.txt. The executable loads log.dll from its own folder, and the DLL reads and decrypts the text file, which holds the payload. The pairing has been documented in public reporting by Elastic and SecureWorks (now part of Sophos) on ShadowPad loaders.
However, the bdreinit.exe and log.dll pairing has also been used by several threat actors in different operations, so it does not on its own identify the malware or the actor. A second set used a G DATA signed executable (ask.exe) with ask.dll and ask.txt.
ShadowPad is a modular remote access Trojan (RAT) that is closely associated with China-based APT groups. It is associated with various threat groups, particularly the APT41-nexus groups such as Blackfly, Grayfly and Redfly. It was documented being used by Glowworm in 2024, which was the first time that group had been observed using the malware.
It has more recently been used in attacks where ransomware has been deployed. Typically, ShadowPad is loaded onto victim networks via DLL sideloading. DLL sideloading is a technique where the attackers use the DLL search order mechanism in Windows to plant and then invoke a legitimate application that executes a malicious DLL payload.
After repeated terminations, the attackers deployed a utility called BreakChain, which relaunches a target so that it no longer appears as a child of the IIS worker process (w3wp.exe). It offers five launch modes and…
