In September 2026, attackers compromised a U.S. retail organization’s web server and struggled for an entire day to make progress. Their manually typed commands contained errors. Every malware loader they attempted to deploy was terminated by the victim’s security software. They re-ran the same blocked payload five times with no change of approach.
The next day, everything changed. For two hours the attackers submitted long, error-free PowerShell scripts with labeled output sections and comments that appeared to record an AI model’s reasoning. Within 10 minutes of querying the victim’s SolarWinds Orion monitoring software, they had identified an unfamiliar message broker, extracted its shared secret, and used it to reach another host. They successfully deployed DLL sideloading payloads, used a process-tree breaking utility to evade detection, and moved laterally across at least six servers.
The AI made them faster, more precise, and more adaptive. But it didn’t change the fundamental requirement: every tool they used had to be written to disk before it could execute.
Why Signature-Based Security Failed
The victim’s security software blocked the first five loader attempts. The attackers didn’t give up — they used AI to generate variations until one got through. This is the core problem with signature-based detection: it’s a pattern-matching game. Change the pattern, bypass the signature.
The article notes that the attackers deployed two different DLL sideloading pairs: bdreinit.exe with log.dll and log.txt, and ask.exe with ask.dll and ask.txt. Both used legitimate signed executables to load malicious DLLs from the same directory. They also deployed BreakChain, a utility that relaunches a target process so it no longer appears as a child of the IIS worker process (w3wp.exe), breaking the process tree that many security tools rely on for detection.
Every one of these files had to be written to the web server’s file system before it could be executed. The AI helped the attackers find creative workarounds, but it couldn’t eliminate that dependency.
How FileSure Would Have Blocked the Attack
FileSure Defend operates at the Windows kernel level via a filter driver. It intercepts file operations — read, write, create, delete, rename — before they reach the file system. It doesn’t care what the file contains. It enforces behavioral policies: which users, which programs, and which machines are allowed to perform which operations.
A simple rule would have stopped this attack at the first payload write:
File name filter: *.exe;*.dll;*.bat;*.cmd;*.ps1
Program name filter: \w3wp.exe (IIS worker process)
Operations: Write, Create
Drive type: Hard drives
Action: Block
When the compromised web shell attempted to write bdreinit.exe, log.dll, or any other executable file to disk, FileSure would have intercepted the operation and blocked it. The IIS worker process has no legitimate reason to write executable files. It serves web pages. Blocking executable writes from w3wp.exe doesn’t break the web server — it just prevents the web server from being used as a malware staging platform.
No payload on disk means no execution. No execution means no lateral movement. The AI-generated scripts would have nothing to run.
The article also describes lateral movement to database servers. FileSure’s REMOTE ACCESS filter blocks file write operations from remote machines accessing local drives through SMB network shares. The attackers couldn’t have written tools to the database servers from the compromised web server without local file system access on the target.
The Real Lesson
AI lowers the skill floor for attackers. It helps them write better scripts, find obscure configuration details, and adapt faster when defenses block them. But it doesn’t change the attack surface. Malware still needs to land on disk. Lateral movement still requires writing files to remote systems. Data exfiltration still requires reading files from disk.
Signature-based tools chase attack patterns. Kernel-level file operation control enforces what’s allowed to happen, regardless of the pattern. The attackers in this incident used AI to generate dozens of variations. A file system policy doesn’t care how many variations they generate — the operation is either allowed or it isn’t.
Start a free trial at bystorm.com and see how kernel-level file access control blocks attacks that signature-based tools miss.
Source: How AI Revived a Stalled Attack on a U.S. Retailer | SECURITY.COM
Category: Threat Intelligence
Tags: ai-assisted attack, dll sideloading, lateral movement, shadowpad, web shell, kernel filter driver, file system security, iis compromise
