- Symantec says attackers stuck at a US retailer switched to AI-written scripts and reached a second server about 10 minutes after probing monitoring software.
- The techniques were long documented. Symantec says AI changed the speed and reliability with which attackers applied them.
- Teams should treat repeated blocked attempts as an alert in themselves and protect secrets inside monitoring tools.
A blocked attacker is not always a stopped one
Security teams often treat a blocked attacker as a slowed attacker. A September intrusion at a US retail organization, detailed by Symantec, shows the limit of that comfort. The lesson here is that AI did not hand these attackers a new weapon. It shortened the distance between hitting a wall and finding a way around it.
What Symantec found
Symantec's researchers say the attackers entered the retailer's internet-facing web server on September 21, 2026, and then made little progress. The next day, the logs look like a person at a keyboard. Across 110 actions, Symantec counted three typos, including "systemifo" and "pwoershell". Each was fixed within seconds.
The attackers also launched the same blocked loader about five times in under 20 minutes, without changing tactics. A loader is a small program that starts the real attack tool. Security software ended it each time.
On September 23, the logs look different. For about two hours, the attackers submitted around 50 long scripts. Symantec says the median script ran past 500 characters, more than ten times the length of the earlier typed commands. None had a typo.
How a stolen secret opened the next server
The attackers found SolarWinds Orion, a network monitoring product, on the web server. Orion ships with RabbitMQ, a message broker that passes data between systems. Symantec says the attackers read its Erlang cookie file. That file holds a shared secret the broker's nodes use to trust one another.
With that secret, they ran a tool bundled with Orion to send a command to the broker on a second web server. The command was written as a list of decimal numbers, so it did not appear as readable text in logs. The first one decoded to "whoami". Symantec says about 10 minutes had passed since the attackers first queried the Orion service.
Symantec stresses that the methods were not new. Remote calls between Erlang nodes, cookie theft and password harvesting from configuration files have all been described before. The change it points to is speed and reliability. By Symantec's account, the same operators with the same access had got little done a day earlier.
Why Symantec believes AI was involved
The evidence is in the scripts. Each one bundled several probes, labelled every result and capped the output. Symantec says that layout is common in code generated by large language models. Some scripts opened with comments that stated a hypothesis and revised an earlier conclusion. One noted that earlier negative results came from a proxy channel known to report false successes.
The timing points to a person in the loop. Symantec says gaps between submissions were at least seven seconds, with pauses of two to eight minutes before changes of strategy. It reads this as an operator copying output into an AI tool and pasting back the reply. Symantec has high confidence in the AI finding and moderate confidence in the operator model. It could not identify the model or service.
What the report does not settle
Symantec does not know how the attackers first got in. It says the same loader files and staging server appeared in an August 2026 intrusion at another organization, with no signs of AI there. Symantec concludes that AI was bolted onto a toolkit that already existed. The loader pairing is also used by several threat actors, so Symantec says it does not identify the actor on its own.
The timeline is also less tidy than the web-server story suggests. Symantec saw similar labelled scripts on September 18 on three database servers in the same network, before the web server stalled. So AI use did not begin at the stall. Symantec also says the comment style changed between September 19 and 22, which may mean more than one AI model was in use.
Symantec also calls this one of dozens of AI-assisted attacks its Threat Hunter team has investigated in recent months, with most in September. That is Symantec's own count of its caseload. It is not a measure of the wider threat.
Questions to put to your security team
Dick O'Brien, a principal intelligence analyst at Symantec, told Dark Reading that "the retry pattern is a signal itself." His advice is to block on what software does, not on file names or exact commands. He added that defenders can use the pattern, because AI tends to test variants of a technique in quick succession.
Four questions follow from this case. In Symantec's account, the first attacker commands on the database servers ran as command shells launched directly by the SQL Server service. The same happened under the web server process. Does your monitoring raise an alert when a web server process or a database service starts a command shell? Does a run of blocked launches from one host trigger a human response, not only a log entry? Are the secrets inside monitoring tools treated as credentials to rotate and restrict? And does your response plan assume an attacker needs hours to find a workaround?
In this case, the block was a pause, not an end. A control that stops a file but ignores the retries behind it may be measuring the wrong thing.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Symantec.
