• 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. 

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. 

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. 

​ 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. 

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. 

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. 

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(. 

​ 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.  

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.  

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: 

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.  

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. 

​

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. 

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.  

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.  

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.BadDav-10060502-0
• Win.Backdoor.GoProxShell-10060503-0
• Win.Malware.AmateraStomper-10060507-0
• Win.Backdoor.BadNetSup-10060508-0
• Js.Downloader.ClickFix-10060510-0

Indicators of compromise (IOCs) 

The IOCs for this threat are also available at our GitHub repository here. 

• 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:

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.”

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.

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.

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. 

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.

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.

Should we let AI run our threat hunts? The debate usually splits into two camps. One says, "Yes, obviously! The sheer scale of our security telemetry is impossible for humans to deal with." The other says, "Absolutely not!  You can't trust an AI with something this important."  

The thing is, I think both are wrong, or at least incomplete.  

I've spent a long time as one of the louder voices saying that hunting is specifically a human-driven process. I created the first widely recognized definition of threat hunting back in 2015, and the version I'd have given you until very recently put a human firmly at the center of it.  

But lately I've been reconsidering the role of AI in threat hunting. So this post is, in part, me arguing with my past self.  

We're facing what I call the Hunter's Paradox: Humans can no longer keep up with the volume and velocity of security data on their own, so we need to lean on automation. But the most capable automation available, AI, is exactly the kind we can't fully trust. Both are true at once, and that tension is what I've been wrestling with for a while. We can’t resolve it cleanly by picking either side, so let's take them in turn, starting with the human element. 

Humans have a numbers problem 

So why not just keep humans in the driver's seat and call it a day? Because that math stopped working a long time ago. 

When I started in this field about 30 years ago, the conventional advice was that system administrators should read all their logs every day. It probably wasn't realistic even then, and it has been thoroughly impossible for most of my career. That's the volume problem, and it only ever compounds. There's more data than anyone can read, and there's more of it every year. 

Then there's velocity. Automated attacks already move at close to machine speed, and even human-driven intrusions routinely outpace human defenders. AI on the offensive side is making that gap wider, not narrower. 

And finally, there's capacity. This isn't the usual complaint about being under-resourced. That may still be true, but the problem is deeper than that. Volume and velocity together have pushed us to a place where it is simply not possible for humans to keep up no matter how many of us there are. If your team can still manage today, the trend line says it won't be able to for long. Even a perfectly staffed, perfectly funded team can’t beat that math forever. 

Put those three pressures together and opting out of AI isn't really an option. We can't hunt at scale without it, which lands us right back in the paradox: we need a tool we can't fully trust. 

AI doesn’t deal well with lies 

When most people think about AI and attackers, they think about prompt injection. An attacker slips instructions into something the AI will read, the AI dutifully follows them, and now your defensive tooling is working for the other team. It's real, it's a problem, and you should design with it in mind. It's also the less interesting part of the trust problem, so I'm going to acknowledge it and move on. 

The deeper issue is that attackers lie and cheat constantly, whether or not they think an AI might be watching. Deception isn't a tactic they reach for occasionally; it's the medium they operate in. Every phish, every exploit, every defense evaded is a lie that has to be believed in order to work. That has always been true, long before AI showed up. 

Pervasive deception is a real issue for AI. It’s baked into how we create LLMs: They have no concept that their training data might be deceiving them, and so when they come into the real world and deal with our dirty data, they tend to take it at face value. Not every time, maybe, but enough that their judgment is noticeably skewed even when we explicitly tell them to detect shenanigans.  Even the most accurate telemetry isn't trustworthy if it's faithfully recording a lie, and AI tends to process what it's given and believe it. 

Solving the paradox starts with a definition 

Now that we understand how deep of a hole we’re in, we can start thinking about how we might get out of it. Let’s start with the very definition of threat hunting itself. 

Back in 2015, I was the architect behind the Sqrrl threat hunting framework. I defined hunting as "any manual or machine-assisted process for identifying security incidents your automated detection systems missed." That same definition carried forward into our PEAK framework in 2023, of which I was the lead author. This has been the working definition for much of the field for a decade, though often in different words. 

That phrase right at the front, "manual or machine-assisted," is the entire reason I’ve been thinking about this so hard. What that phrase actually meant was that humans drive the hunt. Machines can assist, through analytics or machine learning or whatever tooling you had, but a person was always the one doing the hunting.  

And honestly, that was the right call at the time. But if I look back at what I was really trying to capture with that definition, the essential ingredient was never the human. It was reasoning. Humans were just the only place to get it in 2015.  

But that’s no longer the case. AI can reason now — maybe not as well as a good human analyst, but it really can reason in a way that the tools of 2015 could not. So maybe the definition should change to match what I really meant. Threat hunting might be better described as "any reasoning-driven process for identifying security incidents your automated detection systems missed."  

Reframing hunting around reasoning rather than around who's doing it feels more accurate to the original intent, and it's a lot more useful for working through the paradox. If reasoning is the point, then the question isn't whether the hunter is human or machine. It's whether there's real reasoning involved. 

If it’s really about reasoning, what does that mean? 

If we accept that AI can reason and hunting is a reasoning-driven process, then letting AI drive starts to seem… well, reasonable. 

The next big question, then, is what should that actually look like? Just saying, "AI, go find the evil!" is not a real plan. I wouldn't hand most human hunters that assignment either. Letting AI hunt responsibly takes careful planning, and more importantly it takes guardrails. At least three things matter. 

The first is tight focus. Decide deliberately which hunts you're willing to let AI drive. The procedure should be reasonably clear, but the hunt should still contain some real ambiguity. It’s the ambiguity that requires reasoning, and if there’s no reasoning at all you don't have a hunt, you have a SIEM rule. A good place to start is the pile of hunts you've run before but never quite managed to fully automate. Most teams have at least one of those sitting in a backlog. 

The second is strict guidelines. An AI agent operating in your environment is a non-human principal with credentials, and it should be treated with at least as much care as a service account: scoped access, audit trails, the ability to revoke and rotate, and never more privilege than your most junior hunter would get. You also have to decide ahead of time which actions the AI can take on its own and which it cannot. Maybe you let it quarantine a user endpoint when it's confident something is wrong. Quarantining a production server? Probably not. 

The third is graduated autonomy. Don't jump straight to full hunting independence. Let the AI act as an advisor first, then an assistant, then an operator on narrowly defined tasks, earning a little more trust at each step. Remember: Your threat actors don’t have to care about collateral damage, but you do. We’ve all heard the horror stories about AIs that deleted the production database. If your AI oversteps its boundaries, you’re more likely to actually cause incidents than to detect them. 

What stays human 

Even with all of that working well, there are still things that humans will be markedly better at for the foreseeable future, but they mostly trace back to one aspect: creativity. 

One important creative area is your hunt strategy — that is, deciding what's worth hunting for in the first place, what to prioritize, and in what order. That's running the hunt program, and it shouldn't be delegated to the AI. It can execute hunts, but it shouldn't be allowed to decide which hunts matter. 

Another important creative area is analytic novelty. Attackers are creative, so we have to be creative too, both in what we choose to look for and in how we analyze our data. The biggest payoff in hunting comes from finding the thing nobody thought to look for, and an AI's training data by definition doesn't include the attacker behavior nobody has seen yet. Lean too hard on AI to generate your hunting procedures and you'll quietly converge on well-trodden ground, leaving the truly new stuff as your blind spot.  

Put together, we almost have another guideline: Humans pick what's worth hunting and how. AI executes within those bounds. 

Where we go from here 

So, should we let AI start driving some hunts? Probably, yes, but that was never really the hard question. The hard question is how, and that's the part we have to work out together. 

I don't have all the answers, and I'm not pretending this is a finished playbook. What I'm sure of is that reframing hunting around reasoning, applying narrow focus and strict guidelines and graduated autonomy, and keeping humans firmly in charge of strategy and novelty are good things to keep in mind as we figure it out. You hunters reading this are the ones who are actually going to shape what AI hunting becomes. It’s going to be on all of us to experiment, to try things, and then to share what we’ve built — whether that's code on GitHub, a blog post, or a conference talk. The whole field gets better when we share what worked and what didn't. I'm eagerly looking forward to seeing what we come up with. 

• Cisco Talos is disclosing UAT-11795, a sophisticated, Russian-speaking, financially motivated adversary that has been conducting a malicious campaign targeting users in the U.S. and Europe since at least June 2025.  
• Talos has discovered that the actor in this campaign delivers a Python-based remote access tool (RAT) that we track as “Starland RAT” and a command-and-control (C2) memory implant known as the “WLDR agent.” 
• The WLDR agent is a sophisticated PowerShell-based C2 memory implant that features encrypted beaconing, task queuing, and a Runspace execution engine for executing additional payloads.  
• UAT-11795 also has CastleStealer and Remcos RAT as alternative payload implants in their arsenal. 
• The actor targets victims' credentials and cryptocurrency wallet assets, establishing a persistent connection to the victims' machines from the C2 server, with the potential to deliver and execute further payloads. 

Victimology 

According to the telemetry data, the infection is predominantly observed in the United States. There are also fewer potential impacts observed in Germany, Romania, and Venezuela, based on the assessment of the passive DNS resolution data of the C2 domains associated with this campaign. 

Talos has observed that the threat actor in this campaign has utilized trojanized installer lures from software categories including: 

The breadth of trojanized software across developer tooling, IT administration utilities, enterprise collaboration platforms, and a consumer gaming application suggests the actor is operating an opportunistic, volume-driven distribution model targeting multiple victim profiles simultaneously, rather than a single vertical. 

Threat actor infrastructure 

The threat actor in this campaign operates a distributed infrastructure across two functional categories, payload staging and persistent C2, with domain naming conventions chosen to blend into legitimate traffic categories. The staging domains, including “eorthopaedics[.]com” (likely a hijacked domain), “web-devtools[.]com” (resembles a developer tooling portal), and “zynaris[.]io” (resembles a technology start-up), with each domain serving a narrow functional role:  

• “eorthopaedics[.]com” and “sastoro[.]com” hosts the PowerShell stage chain under “/feed/” and “/alpha/” paths indicating that the actor has added the malicious routing alongside the legitimate contents. 
• “web-devtools[.]com” serves raw shellcode payloads under the paths (“/starlandfox”, “/x32remka”, “/dopfile”) and a compressed archive. 
• “zynaris[.]io” hosts the potential ClickFix-delivered HTML application (HTA) stager and trojanised installer lures. 

The C2 infrastructure is similarly distributed, with “eorthopaedics[.]com” and “sastoro[.]com” both serving hardware-bound unique identifier (HWID) encrypted envelopes over HWID parameterized URL paths with “eorthopaedics[.]com” under “/feed/” and “sastoro[.]com” under “/alpha/”. This suggests that the two domains represent parallel C2 infrastructure used for the same campaign. 

The domains “windowscreenrepairnearme[.]com” (which is also likely to be a hijacked domain) and “aipythondevs[.]com” serve as the primary C2 for the Starland Python RAT. All C2 URLs incorporate a victim hardware identifier derived from the C: drive volume serial number of the victim machine as the final URL path component, enabling the distinct C2 communication for each of the compromised victims. The actor in this campaign has also implemented C2 infrastructure resilience by using a Polygon smart contract (“0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba”), which stores an XOR-encrypted fallback C2 domain that is retrievable via a public JSON-RPC call.  

Talos discovered that the actor controls two Telegram bots, “8384531459” (“skuefq_bot”) and “7993597060” (“komandastuk_bot”), used for receiving the implant’s execution notification beacons, including messages with victim’s machine fingerprints and cryptocurrency wallet inventories. 

Talos’ research uncovered a private live Telegram channel called “stuk komanda”, controlled by the same threat actor. The stuk komanda channel was created on June 5, 2025, and has three unknown subscribers. It does not contain any chat groups and appears to be structured like a C2. The channel lists messages in the name of file names that appear to be Windows-based binaries, highlighting that the threat actor has been active since at least June 2025. 

Multi-stage attack summary 

The threat actor executed a multistage campaign that involves deploying a weaponized HTA downloader via Microsoft HTML Application Host (“mshta.exe”) on the victim's machine, likely utilizing a ClickFix technique. The execution of the HTA file results in the downloading and execution of trojanized installers bundled with a malicious Python package, which sends the implant status of the installer to an attacker-controlled Telegram bot. The NSIS script associated with the trojanized installer is designed to execute the malicious byte-compiled Python code encapsulated within the installer file. 

This initial byte-compiled Python code acts as a loader that decodes and executes an embedded Python RAT, which we are calling Starland RAT, in the victim's machine memory. Starland RAT offers a wide range of functionalities and has been specifically engineered to operate within the Windows environment. Its capabilities include defense evasion techniques, system reconnaissance, stealing browser data and cryptocurrency wallets, and a fallback C2 connection mechanism that includes a hardcoded C2 URL, as well as a Polygon Ethereum smart contract that serves as a backup. This connection allows it to interact with the smart contract through Eth_call, dynamically resolving the C2 domains. The RAT sends the reconnaissance information to the C2 to register the victim's machine and is proficient in receiving and executing intermediate payloads in several formats, including shellcode for 64-bit and 32-bit Windows environments, directly executing Windows shell commands, and downloading and executing malicious EXE, MSI, and DLL files. 

Talos has observed that the threat actor has distinct infection chains for each type of intermediate payload that Starland RAT receives from the C2. In the case of an x64 shellcode intermediate payload, it implants CastleStealer as the final payload. CastleStealer is a .NET stealer that targets credentials, cryptocurrency wallets, Telegram data, and other browser data from the victim's machine. Similarly, the x32 shellcode implants a variant of the Remcos RAT. 

Furthermore, Talos has observed that the threat actor executed a Windows shell command through Starland RAT as an intermediate payload to download and execute a PowerShell stager. This stager is associated with an undocumented PowerShell C2 framework, which we track as “WLDR C2” in alignment with the internal project designation used by the threat actor in the PowerShell scripts. The PowerShell stager is heavily obfuscated and is designed to decrypt an embedded next-stage PowerShell loader. The second-stage PowerShell loader script has capabilities for defense evasion, connects to the C2, downloads a JSON response, and processes this response to execute another embedded PowerShell payload, the WLDR agent, in the victim's machine memory. The WLDR agent is a bespoke PowerShell script that receives its C2 address through the PowerShell loader injected global variable at the time of execution. The WLDR agent employs capabilities including encrypted HTTP beaconing, comprehensive host reconnaissance, a robust reconnection protocol, and a modular task execution engine to further execute the malicious PowerShell scripts as directed by the threat actor from the WLDR C2 server. 

Initial vector 

The threat actor gains initial access to the victim machine potentially through a ClickFix social engineering technique that entices the user to execute a command, which then stealthily downloads and executes a remotely hosted weaponized HTA file. The HTA file runs an embedded VBScript that drops a Windows batch file into the user profile’s application temporary folder, which contains instructions to first download and implant a trojanized installer from the attacker-controlled staging domain onto the victim machine. 

Once the trojanized installer is executed, the batch file sends a notification beacon to an attacker-controlled Telegram bot, “8384531459”, to confirm successful execution to the threat actor. At the same time, the VBScript establishes persistence under “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the generic value “MyApp”, pointing back to “mshta.exe” to execute the remotely hosted weaponized HTA file every time the victim logs in to the machine. Talos identified a Russian-language developer comment left in the VBScript (“Добавление команды в автозапуск для текущего пользователя”), indicating that a Russian-speaking actor is conducting this campaign. 

Python loader packaged into trojanized installers 

Talos has observed that the threat actor in this campaign has weaponized software installers by utilizing the Nullsoft Scriptable Install System (NSIS). They have packaged the Python runtime executable “pythonw.exe” along with a compiled Python loader, which is disguised as a license file named “LICENSE.txt”. The threat actor has modified the NSI script file of the installer to include instructions for executing the compiled Python loader using the Python runtime executable.  

The compiled Python loader is a relatively large file obfuscated with numerous junk functions that perform random arithmetic operations and print randomly generated strings to the standard output. The actual execution logic is confined to six lines in the loader program, implementing XOR decryption using the XOR key 198 (0xC6) to decrypt the encrypted embedded payload of Starland RAT and execute it in the victim machine's memory.

Starland RAT, a Python-based RAT 

Starland is a Python-based remote access tool (RAT) with the capability to steal cryptocurrency. During its initial execution phase, the RAT resolves and declares all required Windows API function signatures through Python’s ctypes interfaces. It directly loads “kernel32.dll” using WinDLL and explicitly defines the argument types and return types for every Win32 call used later in execution, including VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, VirtualProtectEx, CreateProcessA, QueueUserAPC, and ResumeThread. Custom ctypes Structure subclasses are declared for SECURITY_ATTRIBUTES, STARTUPINFO, and PROCESS_INFORMATION, mirroring the definitions in the Windows SDK. This API mapping mechanism ensures that all injection and process manipulation calls later in execution are ready without further need for Windows API imports or dynamic resolution. 

Before any malicious logic executes, the RAT conducts check for anti-analysis environments. First, it compares the logged-on username of the victim machine against a hardcoded list of usernames, which includes known sandbox service accounts and aliases, including WDAGUtilityAccount. Next, the RAT verifies the victim's computer name against a list of hostnames from recognized sandbox environments, such as Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. If either check matches, the RAT's execution terminates immediately. Additionally, the RAT examines the Downloads folder for a Zone.Identifier alternate data stream on the trojanized installer file, confirming that the file was obtained via a browser download rather than being uploaded or copied directly. 

The RAT establishes persistence before any network communication with the C2 takes place. The primary mechanism involves creating a scheduled task using the PowerShell New-ScheduledTask command, with a randomized name following the pattern PythonLauncher-{3 random characters}. When executed with administrator privileges, the trigger is set to AtLogOn with RunLevel Highest, ensuring the elevated re-execution of the RAT at every user logon. Additionally, a secondary Startup folder LNK shortcut is created via the WScript.Shell COM object, placed in the user's Startup directory, targeting “pythonw.exe” with LICENSE.txt as its argument. If the RAT is not already running with elevated privileges, it also attempts UAC elevation via ShellExecuteW with the runasverb, aiming to upgrade the scheduled task to the higher-privilege logon before proceeding. 

It performs system reconnaissance, assembling the victim profile that includes the system hardware-bound unique identifier (HWID), total RAM size of the victim machine, and installed antivirus by executing the following commands: 

Get-CimInstance -Class Win32_ComputerSystemProduct.UUID  
wmic memorychip get Capacity   
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct

The RAT also conducts Active Directory reconnaissance via the PowerShell command Get-WmiObject Win32_ComputerSystem.Domain. If the victim is identified as a member of Active Directory, the RAT executes the following commands to collect information about domain structure, domain controllers, and the victim’s domain privileges: 

whoami && systeminfo && net user {USERNAME} /dom && nltest /dclist

For workgroup-only hosts, it executes the whoami /all command. The reconnaissance data collected are staged by the RAT for inclusion during the victim machine registration to the primary C2 domain hardcoded in the RAT program. It also captures a screenshot of the victim machine's desktop, saves it as a PNG in the RAT’s working directory, generates a Base64-encoded string for the PNG file in memory, stages it alongside the reconnaissance data, and deletes the PNG file from the disk. 

Additionally, it gathers the victim’s cryptocurrency assets information by enumerating the desktop cryptocurrency wallets and browser extension wallets, checking for the presence of over 40 cryptocurrency wallets. The collected data is also staged alongside the reconnaissance data and the Base64-encoded screenshot (PNG) data. The RAT consolidates all collected data into a single JSON file, XOR encrypts it with the 5-byte key “helo1”, Base64-encodes it, and sends it to the primary C2 through an HTTP POST request using the HTTP user-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36.  

If the primary C2 registration fails, the RAT enables a blockchain-anchored fallback mechanism. An eth_call is triggered via JSON-RPC to the public Polygon RPC endpoint “polygon-rpc[.]com”, targeting the smart contract “0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba” and function selector “0xc659f3b8” for the latest block. The encrypted hexadecimal string that the RAT receives from the smart contract is XOR-decrypted with the key “$m7*rYpry3” to recover a fallback domain to which the RAT sends the victim machine registration request along with the reconnaissance and screenshot data. 

Before transmitting the reconnaissance information to the C2 for the victim's machine registration, the RAT sends a notification message to the attacker-controlled Telegram bot using hardcoded credentials. The message includes the victim's public IP address sourced from “api64.ipify[.]org”, the build name, region locale, computer name presented as a “Crew ID” field, OS platform and release, processor string, and the hardcoded label  
"Windows Defender” as the protection application indicator. If any Chrome cryptocurrency wallet extensions or desktop cold wallet applications were detected during the reconnaissance phase, they were also appended to the message of the Telegram bot, providing the threat actor with visibility into the victim profile and cryptocurrency assets before the actual registration of the victim machine to the C2. 

After the RAT registers the compromised machine with the C2, it sends a GET request to the C2 server every 50 – 60 seconds. It contains minimal JSON content with two randomly named junk fields and the bot's unique identifier, encoded using the same XOR key “helo1” and then Base64 encoded. The C2 server responds with one of the four commands supported by the RAT: 

Windows shell command deploys bespoke WLDR agent C2 implant 

In the current campaign investigation, Talos discovered that the threat actor executed a curl command to download and execute additional PowerShell script payloads of the WLDR C2 framework from another C2.  

WLDR stager 

The WLDR stager PowerShell script represents the initial stage, where it establishes a loop counter and two boolean flags for execution states. Each state creates a runtime alias for PowerShell command execution, resolving .NET Base64 and byte conversion types through an obfuscated string construction mechanism. It also defines an inline decryption routine that XOR decrypts the next stage, which is the embedded encrypted WLDR downloader PowerShell script, using a dynamically computed XOR key. 

WLDR downloader  

WLDR downloader is a compact HWID-bound loader script. Upon execution, it derives a hardware identifier from the victim’s C: drive volume serial number, converts it from hexadecimal to a decimal number, and appends it to two hardcoded C2 URLs for victim-specific payload delivery and a persistent agent task channel. It then issues an HTTP GET request to the C2, and the C2 server only responds to requests whose HWID matches a pre-registered value. The C2 server response is an encrypted JSON envelope containing fields with a Base64-encoded salt, initialization vector, encrypted data, and authentication tag. 

The WLDR loader processes the JSON response by decrypting the envelope through an inline decryption routine using a derived 64-byte key from a hardcoded plaintext password “odg5t8mvssvh” and the salt received from the C2 server in the JSON response. This is followed by the decryption of the encrypted data, which is the next stage of the WLDR agent PowerShell C2 memory implant. Before executing the WLDR agent, it writes the C2 URL and the plaintext password into the global PowerShell scope, making both available for the WLDR agent as its C2 address and session encryption key for all subsequent communication with the C2. 

Bespoke WLDR C2 agent implant 

The WLDR agent is a fully featured PowerShell remote access client that operates entirely in memory. It implements encrypted C2 communications, concurrent task execution through a managed Runspace engine, and a module delivery framework that provides the threat actor with interactive remote PowerShell execution capabilities on the victim's machine. 

Upon execution, the agent initializes the server's URL to a development placeholder and immediately checks for a globally scoped URL and session encryption password that were set by the WLDR loader script. If found, it overwrites the placeholder with the C2 URL and inherits the session encryption password, while also configuring other operational parameters, including polling interval, HTTP timeout, retry counts for the C2 reconnect cycle, and the number of threads for the Runspace pool. 

Before initiating the C2 connectivity, it implements a mutex “f2j398fj239d8j23dkkskskkkkkkkkk” to prevent duplicate instances and performs a dependency check on the inherited session encryption password. If the password is not found, the agent exits its execution. The network communication is encrypted using AES-256-CBC with HMAC-SHA256 in an encryption, then Message Authentication Code (MAC) construction, with session keys derived through PBKDF2-SHA256 over a randomly generated salt at 5,000 iterations. The protocol version tag WSv1 is bound to every MAC computation, with a new random initialization vector (IV) generated for each message. 

The agent performs reconnaissance via WMI queries, gathering information on antivirus products, network adapter configurations, OS version and build, domain membership, CPU, RAM, administrative privilege status, and UAC policy. A hardware identifier is primarily derived from the C: drive volume serial number; if that fails, it queries the machine's registry for the GUID or generates a checksum of the host name, which is appended to all C2 URLs. The initial connection to the C2 is established through an HTTP POST that includes the victim machine profile, the infection identifier, protocol version 2.0.0, and the cryptographic session parameters, with a connection retry timing set to 30 seconds. All subsequent traffic is sent to C2 over HTTPS, with headers designed to mimic a Chrome browser session in version 124. 

After establishing the initial connection with the C2, the agent polls the C2 server every 10 seconds. The response from the C2 server can include either commands or tasks, with the only hardcoded command in the agent being a kill instruction that triggers instance termination, while tasks are queued for execution. 

During our research, we observed that the initial response from the C2 was the idle polling interval response, which included empty fields in both the “commands” and “tasks” arrays. 

Further analysis of the agent program disclosed that the C2 responses to the polling will contain encrypted PowerShell commands or scripts, which are decrypted using the same hardcoded password and executed through one of the two runtime engines defined in the backdoor program.  

The primary agent execution engine is a PowerShell RunspacePool supporting up to 10 concurrent threads. Each PowerShell script payload delivered by the C2 is wrapped with details of execution context and parameters as in scope variables along with event handlers on the script’s execution result of output, error,and warnings. These event handlers registered on the output, error, and warning streams are triggered synchronously as the script execution output is produced, packaging results into stream messages and forwards them to the C2 in real time without waiting for the script execution completion.  

This message streaming capability makes the WLDR agent’s Runspace engine favorable for the interactive operations such as continuous monitoring where the command output reaches the threat actor incrementally, rather than after the completion of the script execution.  

If the Runspace engine fails to initialize the payload, PowerShell script execution defaults to standard PowerShell background jobs. It injects parameters and launches the script as a background job; however, unlike the Runspace path, it collects output only after the job completes, making it suitable only for short-lived batch tasks. 

Other payloads of Starland RAT campaign 

Talos has discovered that the threat actor possesses additional malware, including CastleStealer and Remcos RAT, which can be deployed as payloads to the victim's machine via the Starland RAT. To deliver these payloads, the threat actor utilizes a custom shellcode loader for both x64 and x32 machines, encapsulating the embedded encrypted binaries of the payloads. 

The shellcode loader resolves all required Windows APIs entirely at runtime by enumerating the list of loaded modules in the OS memory, iterating through each module's export directory, and comparing a hash of each function name against stored target values. The shellcode neutralizes both the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) through two sequential bypass mechanisms. The primary technique resolves the target functions AmsiScanBuffer in “amsi.dll” and EtwEventWrite in “ntdll.dll” using runtime hash-based API resolution, then overwrites their first bytes in memory with a patch that forces AMSI to always return a clean scan result and the ETW write function to return immediately without writing the output, effectively neutralizing both interfaces. If the primary patching technique fails, the shellcode executes a fallback mechanism where it calls VirtualProtect to temporarily change the target function's memory page protection value to read-write-execute and writes the same patch bytes directly, then restores the original page protection. 

Then, it decrypts the embedded encrypted payload blob and decompresses the decrypted data using LZX decompression into a newly allocated memory region. The payload is subsequently dispatched either by the reflective PE injection technique or by .NET CLR loading through the ICorRuntimeHost COM interface for .NET binaries, or through the PowerShell Runspace for PowerShell scripts. 

Talos discovered that the threat actor can deliver CastleStealer implant through the x64 shellcode and the Remcos RAT through the x32 shellcode variant.  

CastleStealer is a .NET-based infostealer and credential harvesting implant designed to systematically extract sensitive data from compromised Windows hosts. It incorporates several anti-analysis measures, including a Russian locale exclusion check and a hardcoded build expiry timestamp, ensuring it executes only against genuine targets within a defined operational window. Its credential theft surface is broad, targeting the full Chromium browser family and Firefox through direct SQLite database access, with decryption support for both legacy DPAPI-protected credentials and the AES-GCM application bound encryption scheme. Beyond browser data, it enumerates crypto wallet browser extensions, Discord and Telegram session files, Steam account credentials, and targeted filesystem paths, transmitting all collected material over a TCP socket to the attacker-controlled infrastructure. CastleStealer’s secondary payload delivery capability allows the actor to implant further payloads through process injection technique or PowerShell script execution.  

Remcos RAT (Remote Control and Surveillance) is a commercial remote access tool originally sold as a legitimate remote administration tool. However, it has been extensively abused by a wide range of threat actors since its emergence in 2016. It provides operators with comprehensive post-exploitation capabilitiesincluding real-time keylogging, screen and webcam capture, audio recording, file management, shell command execution, and clipboard monitoring all communicated over an encrypted channel to a configurable C2 server.  

Coverage 

The following ClamAV signature detects and blocks this threat: 

Txt.Downloader.Agent-10060312-0
Html.Downloader.Agent-10060313-0
Html.Downloader.Agent-10060314-0
Py.Loader.Agent-10060315-0
Py.Loader.Agent-10060316-0
Ps1.Trojan.Agent-10060317-0
Ps1.Trojan.Agent-10060318-0
Ps1.Trojan.WLDRAgent-10060319-0
Ps1.Downloader.Agent-10060320-0
Win.Trojan.CastleStealer-10060341-0
Win.Trojan.Starland_Installer-10060342-0
Win.Malware.Starland-10060343-0
Win.Malware.Remka-10060344-0

The following Snort Rules Snort 2 and Snort 3 (SIDs) to detect and block this threat: 66787 – 66790 and 301580  

IOCs

The IOCs for this threat are also available at our GitHub repository here. 

• Component Object Model (COM) is a fundamental Windows technology used by legitimate applications for object activation, inter-process communication, automation and language-independent component reuse. Those same qualities make it useful to threat actors. 
• Malware frequently uses COM interfaces for lateral movement, execution, download and exfiltration, persistence, evasion, system discovery and automation of built-in Windows and Office functionality. 
• Reverse engineering COM-heavy binaries requires researchers to move from opaque GUIDs and indirect vtable calls to meaningful classes, interfaces and method names.  
• This post is based on research conducted for presentations at AVAR 2025 conference in Kuala Lumpur and a CARO 2026 workshop in Innsbruck.

Component Object Model (COM) is one of the Windows technologies that analysts regularly encounter but may not always prioritize during triage, as the manual analysis of COM functionality in binary executable files can be labor-intensive.

The post starts with a brief introduction into COM, following how binaries utilizing COM can be analyzed, and some examples of malware families and their usage of COM. The post concludes with a list of further resources.  

COM as Windows glue 

COM is an application binary interface (ABI) model for reusing software components. COM objects expose interfaces to client applications, and those interfaces can be consumed by multiple programming languages because the contract exists at the binary interface level rather than at a single language runtime level. COM is a fundamental, principal way for components written in different languages to communicate.  

Microsoft describes COM as a distributed, object-oriented system for creating binary software components that can interact with each other. COM is also the foundation for technologies such as OLE and ActiveX.

This language independence is visible in common scripting and automation patterns. The same COM object may be created from VBScript, PowerShell, Python, or C/C++. For example, a script can instantiate the WScript.Shell COM object and use it to read or write registry values, execute a command, create shortcuts, or access environment variables — and it can do it in a very similar way using different scripting languages supporting COM automation. 

DCOM extends the same model across the network 

Distributed COM (DCOM) extends COM so a client can activate and use COM objects on another system. At a high level, the local client talks to a proxy, the remote server exposes a stub, and the COM runtime transports the method invocation over Microsoft RPC.  

The existence of CoCreateInstanceEx API in a binary, with the appropriate parameters, can be used to distinguish between local COM and DCOM. DCOM extends local COM activation by allowing an object to be associated with a specified remote computer. DCOM is also explicitly represented in MITRE ATT&CK as one of the techniques and is described in Remote Services: Distributed Component Object Model, T1021.003. 

Classes, interfaces, and the registry 

Classes and interfaces are two foundational COM concepts. 

COM classes are templates for creating COM objects. A class is identified by a class identifier (CLSID), a GUID that uniquely identifies the component.

GUID is a 128-bit identifier used to uniquely identify COM-related objects and interfaces. The string representation of a GUID is common in the Windows registry, scripts, and configuration text. It is typically formatted as: 

{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} 

A GUID can also appear as a binary structure in a compiled executable. In a binary, the first three fields are typically stored in little-endian byte order, which is why byte-pattern searches for GUIDs differ from the familiar string form. Readers should be aware that many malware families assemble GUID structure dynamically on the stack before attempting to create a new object in order to make the analysis process harder. 

Interfaces are also represented by interface identifiers (IIDs), which also have the GUID's data type. Interfaces define methods an object exposes to clients. The foundational COM interface is IUnknown, which exposes functions QueryInterface, AddRef, and Release. Every COM interface ultimately derives from it. 

COM registration data is stored in the Windows registry. Classes can be inspected under HKEY_CLASSES_ROOT\CLSID, while interface registrations can be found under HKEY_CLASSES_ROOT\Interface. On a typical Windows installation, the number of registered classes can easily reach into the thousands and changes based on Windows version, optional components, and installed software. 

 A common example used in malware is the Windows Task Scheduler service. The newer Task Scheduler 2.0 COM class is commonly referenced by the CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD}. The ITaskService interface has IID {2FABA4C7-4DA9-4013-9697-20CC3FD40F85} and provides access to the Task Scheduler service for managing registered tasks. ITaskService::Connect should be called before using other ITaskService methods. Older Task Scheduler 1.0 samples may instead use the ITaskScheduler interface, which appears in the WarmCookie case study below. 

A program usually loads a COM class by specifying its CLSID, requests a specific interface by specifying its IID, and receives an interface pointer which points in memory at the beginning of the virtual function table (vtable) for the object. The interface methods are called indirectly through a vtable.  

Without type information, the analyst may only see something like: 

call qword ptr [rax+38h] 

With the correct interface recognized and renamed, the same call can become meaningful, which is our main goal when analyzing malware utilizing COM: 

call qword ptr [pTaskServiceVtbl.Connect] 

Basic COM concepts for reverse engineers 

COM clients, servers, and ProgIDs 

A COM client is any code that obtains a pointer to a COM interface and calls methods through that pointer. A COM server is the component that implements the object behind the interface. The two sides may be in the same process, in different processes on the same host, or on different hosts through DCOM. Malware is most commonly just a COM client. Malicious COM servers are encountered less frequently and are outside of the scope of this blog. 

The client asks the COM runtime, implemented in ole32.dll or combase.dll, to instantiate a class (identified by a CLSID) and to return a specific interface (identified by an IID). The dwClsContext argument supplied to activation APIs such as CoCreateInstance tells COM which server locations are acceptable. For reverse engineers, the CLSCTX flags provide a useful context, as they indicate whether the sample is trying to load a DLL into its own process, talk to a local EXE or service, or reach a remote DCOM server.

 A ProgID, or programmatic identifier, is a human-readable registry entry that can be associated with a COM class. Examples include WScript.Shell, Shell.Application, Excel.Application, MSXML2.XMLHTTP and WinHttp.WinHttpRequest.5.1. The registry maps a ProgID to a CLSID, and higher-level languages often use the ProgID directly through functions such as CreateObject or PowerShell’s New-Object -ComObject. Native code can call CLSIDFromProgID to resolve the string to a CLSID before activation. In binaries, the analyst may therefore see either a readable ProgID string, a string-form GUID, or the little-endian binary representation of the CLSID. 

What CoCreateInstance does for an in-process server 

A typical native COM client starts by initializing the COM runtime for the current thread with CoInitializeEx or CoInitialize. In code that will communicate across process or machine boundaries, the client may also configure process-wide COM security with CoInitializeSecurity. After that, the client activates a class, receives an interface pointer, calls methods through the interface, and releases the pointer when finished. 

For an in-process server, CoCreateInstance is a convenience wrapper around the class-factory path. COM resolves the CLSID registration, locates the in-process server DLL for the current bitness, loads the DLL if necessary, and asks the DLL for a class object. That class object usually implements the interface IClassFactory. COM then asks the class factory to create the object and return the requested interface pointer. 

DllGetClassObject is the main activation export and COM calls it to retrieve a class object for the requested CLSID. DllRegisterServer and DllUnregisterServer are self-registration exports used by installers or regsvr32-style workflows to create or remove registry entries; they are not part of the CoCreateInstance call path. 

 A local-server COM EXE follows the same class-factory idea, but the registration points to an executable or service rather than an in-process DLL. The server process typically registers its class object with the COM runtime, and clients receive an interface proxy when the object lives outside the client process. DCOM extends this model to another machine and adds remote activation, RPC transport, authentication, and impersonation state. 

IUnknown, object identity, and vtable layout 

Every COM interface derives from IUnknown. The first three entries in a COM vtable are QueryInterface, AddRef, and Release, regardless of the higher-level interface being used. QueryInterface lets a client ask whether the object supports another interface identified by an IID. AddRef and Release implement reference counting so that objects can manage their lifetime across language boundaries, DLL boundaries and proxy/stub boundaries without relying on a language-specific garbage collector or destructor model. 

COM activation and call security 

COM has its own security model on top of normal Windows process, token, registry, and file-system checks. Security is most visible for local-server and DCOM objects as activation and method calls cross a COM process or RPC boundary.

Activation security controls whether a client can launch or connect to a COM server. The COM Service Control Manager checks launch and activation permissions when a client requests an out-of-process or DCOM object. These permissions may come from machine defaults or from application-specific AppID configuration such as LaunchPermission. A class can be registered and still fail activation if the caller’s token is not permitted, if remote activation is disabled, if the server is not configured for remote use, or if required marshaling information is unavailable. 

Malware samples that call CoInitializeSecurity or CoSetProxyBlanket are often setting up the identity and authentication context needed for WMI, DCOM, or another out-of-process COM interface. For static analysis, the constants passed to these APIs help identify whether the sample expects local-only access, remote access, impersonation, or delegation. 

Tooling for COM exploration 

The first step in COM analysis is usually identification of classes and interfaces used by malware and understanding interfaces together with functions present in their vtables. Tools such as ComView and OleView.NET allow researchers to inspect classes, interfaces, type libraries, proxy/stub information, and method layouts registered on a system. 

OleView.NET, developed by James Forshaw, is particularly useful since it combines a graphical interface with a PowerShell interface, making it suitable for both manual exploration and repeatable research workflows. 

ComView is an older tool still available through internet archive. ComView contains offsets (in decimal) of a function address from the beginning of the vtable, which allows us to identify which functions are being called in the indirect calls observed in compiled executables. In the ComView screenshot below that displays the details of the ITaskService interface, we see that the connect method has offset 40 (28h) from the start of the vtable so any indirect call to a register + offset 28h after a client obtains a pointer to the interface can be transcribed as ITaskService.Connect to improve our understanding of the code functionality.  

 A manual reversing process would contain the following steps: 

1. Find calls to CoCreateInstance, CoCreateInstanceEx, CLSIDFromProgID, CoGetObject, GetActiveObject, IDispatch::Invoke, or related APIs. 
2. Identify the CLSID and IID values passed into those calls. 
3. Look up the class and interface definitions in the registry, Microsoft documentation, OleView.NET, ComView, or a COM database. 
4. Map indirect vtable calls to interface methods based on architecture and interface layout. 
5. Rename types, variables, and calls in the disassembler so the COM workflow becomes readable. 

For this research, we created a simple task scheduler sample written in C, which uses COM to create a Windows scheduled task that runs notepad.exe two minutes after it is created. To simplify the development, the sample was generated by a large language model (LLM).  

We used our Task Scheduler sample to show how compiled binary code differs from its source code. We then reverse engineered the binary to show that once the ITaskService vtable is reconstructed, calls that initially look like generic indirect calls can be renamed to Connect, NewTask, GetFolder, RegisterTaskDefinition, and related methods.  

A faster way to reach the same analysis stage is to use a plugin for your reverse-engineering tool that maps GUIDs to human-readable code. For example, in IDA Pro, the standard COM Helper can identify relevant class and interface IDs and rename locations in the database.  

The remaining task for the analyst is to add the required interface’s vtable structure to the list of code structures currently in use. For example, for ITaskService, we can add ITaskServiceVtbl to IDA Pro and apply the type wherever an indirect call is related to the instantiated interface pointer.

Still, having a thorough understanding is recommended, so that analysts can recognize calls to COM related functions and identify related indirect calls in a binary.  

Applying the workflow to a Qakbot DLL 

Qakbot, also known as Qbot or Pinkslipbot, is a long-running modular banking trojan that has been active since at least 2007 and evolved into a general-purpose malware delivery platform used by financially motivated actors. Early versions focused on credential theft and online banking fraud, but later campaigns added functionality for system reconnaissance, persistence, browser and credential harvesting, email collection, command execution, command and control (C2) communication, payload delivery, and movement inside enterprise environments. Qakbot was frequently distributed through phishing emails, including hijacked email threads, and was used as an initial access and loader component for follow-on malware and ransomware operations. 

In the Qakbot DLL shown below, CoInitializeSecurity is called before the sample references IID_IWbemLocator, and CoCreateInstance creates an instance of the WMI locator class. The GUID is visible in binary form and can be used for type recovery inside the disassembler.

After the class and interface are identified, the next step is to apply the correct interface type to the returned pointer. In this case, the relevant structure is IWbemLocatorVtbl, and the method of interest is ConnectServer.

 The call through a register and offset maps to IWbemLocator::ConnectServer once the vtable type is applied. 

 Several plugins and scripts can accelerate this process. IDA includes a default COM Helper plugin, and Airbus CERT’s COMIDA and Frank Boldewin’s COM Code Helper scripts are also useful options. Binary Ninja users can apply similar type reconstruction workflows to make interface pointers and vtable calls easier to read. Recent Binary Ninja releases include COMpanion-related data rendering support. 

 For dynamic analysis, tracing can help by observing COM activation and dispatch calls at runtime. DispatchLogger, written by Talos’ David Zimmer, is one example of a DLL that can be injected into a process to proxy and log COM-related calls, including IDispatch usage. Researchers can hook or place breakpoints on COM-related calls to identify which interface is being instantiated. For IDA Pro users, the file “<IDAROOT>\cfg\clsid.cfg“ can be used as a reference to map a GUID. OleView.NET can also be run inside the analysis environment to help with the mapping. Dynamic binary instrumentation frameworks such as DynamoRIO can also be used for runtime tracing of COM behaviors. 

How threat actors use COM and DCOM 

Malicious actors use COM as it provides convenient access to existing Windows functionality and can make static analysis efforts more difficult with the functionality of the sample hidden behind indirect register-based function calls.

The following COM classes and interfaces are useful when triaging samples and building hunting logic.

Hunting for COM interfaces 

Static hunting for COM usage starts with known ProgIDs or GUIDs targeted in a hunt. Some binaries contain ProgID strings such as WScript.Shell, Shell.Application, MSXML2.XMLHTTP or WinHttp.WinHttpRequest.5.1. Others contain binary GUIDs without helpful strings. For hunting, we need to be careful about the on-disk byte order for GUIDs because the first three fields are usually stored little-endian in memory and in binaries. 

For the Task Scheduler CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD}, the corresponding byte pattern is: 

9F 36 87 0F E5 A4 FC 4C BD 3E 73 E6 15 45 72 DD 

For the ITaskService IID {2FABA4C7-4DA9-4013-9697-20CC3FD40F85}, the byte pattern is:

C7 A4 AB 2F A9 4D 13 40 96 97 20 CC 3F D4 0F 85

 A simplified YARA hunting rule for binaries that reference the Task Scheduler COM class and interface might look like: 

 This kind of rule will also find legitimate software, so it typically needs to be tightened with detection names, submission dates, file types, family names, and other context to narrow the output. 

Notable malware families and COM 

Although there are many malware families utilizing COM, the following case studies demonstrate only a few notable malware families and their interaction with COM interfaces. 

Case study 1: Gh0stRAT/SimpleRemoter and Task Scheduler 

Gh0stRAT is a long-lived remote access trojan (RAT) whose source code has been publicly available for years, which has made it a convenient base for modified RAT families and actor-specific forks. MITRE ATT&CK describes Gh0stRAT as a remote access tool with public source code that has been used by multiple groups.  

The COM-relevant part of this example is the scheduled task creation logic in the RAT. The code uses Task Scheduler COM interfaces rather than simply invoking schtasks.exe. In process creation telemetry, the task creation may not appear as a direct schtasks.exe launch visible in EDR telemetry as COM calls run inside the malware process.  

Case study 2: Attor and BITS 

Attor is a Windows-based cyberespionage platform first publicly documented by ESET in 2019, with observed activity dating back to at least 2013. It is a modular implant built around a dispatcher component that manages loadable plugins, allowing operators to tailor functionality per victim. Reported capabilities include screen capture, audio recording, keylogging, clipboard capture, file collection and upload, process/window monitoring, persistence, Tor-based C2 communications, and GSM/GPRS device fingerprinting through AT commands. 

Background Intelligent Transfer Service (BITS) is another COM-exposed Windows service that attackers use, as it provides reliable file transfer functionality and an alternative service for C2 communications that may evade the scrutiny of EDR software.  

The IBackgroundCopyJob interface is used to add files to a job, set priority, determine state, and start or stop transfers. Malware using this interface may perform payload download, staging, or exfiltration through the same background transfer service used by legitimate applications. 

In the example used here, the Attor plugin uses IBackgroundCopyJob to communicate with a C2 server. The same plugin also contains COM exposed functionality for launching VBScript and PowerShell through COM client code, and through use of IWbemClassObject to enumerate installed endpoint security software. 

Case study 3: WarmCookie and Task Scheduler 

WarmCookie, also known as BadSpace, is a malware family that Talos reported as emerging in April 2024 and being distributed through malspam and malvertising. 

The COM-specific part of the workflow is visible in the decompiled function responsible for persistence. WarmCookie initializes COM, creates the older Task Scheduler 1.0 object using CLSID_CTaskScheduler, and requests IID_ITaskScheduler. It then creates a work item, configures flags and creates a trigger. In the screenshot below, the class and interface identifiers appear before the follow-on task and trigger creation calls. 

Conclusion  

COM is an integral part of the Windows programming model. As such, it will remain useful to malware authors wishing to utilize existing cross-platform functionality in Windows. COM is often used to hide malicious functionality behind the vtable based indirect function calls but equally for achieving persistence or moving laterally within victim environments.  

For threat researchers, the important skill is recognizing when a sample is using COM and then translating the evidence like ProgIDs, CLSIDs, IIDs, and vtable offsets into the human-readable name of the Windows component, interface, and method that are being used. 

Analysts in most malware cases do not need to fully master COM to analyze COM-based binary malware. They need enough practical knowledge to identify the client-side workflow, recover interface types, and understand whether the malware is using COM for task creation, WMI access, BITS transfers, shell automation, Office automation, local execution, remote activation, or persistence. 

Tools such as OleView.NET, ComView, IDA’s COM Helper, COMIDA, COM Code Helper, COMpanion plugin, and DispatchLogger can shorten the path from an anonymous indirect call to a meaningful API-level action. 

Further reading and tools 

• Microsoft Learn: Component Object Model (COM) and DCOM Remote Protocol overview 
• Microsoft Learn: COM technical overview and COM clients and servers 
• Microsoft Learn: CoCreateInstance, CoCreateInstanceEx, and CLSIDFromProgID 
• Microsoft Learn: IUnknown, IDispatch, and COM reference counting 
• Microsoft Learn: COM security with CoInitializeSecurity, CoSetProxyBlanket, LaunchPermission, and AccessPermission 
• Microsoft Learn: Task Scheduler ITaskService, legacy ITaskScheduler, and BITS IBackgroundCopyJob 
• Google Project Zero: OleView.NET tooling updates 
• James Forshaw: DCOM Research for Everyone! 
• James Forshaw: COM in Sixty Seconds! (well minutes more likely) 
• Mandiant/Google Cloud: Hunting COM Objects 
• Mandiant/Google Cloud: Hunting COM Objects, Part Two  
• Hex-Rays: COM reverse engineering and COM Helper  
• Malwarebytes Labs: Observing COM within Malicious Code  
• Tools: COM Code Helper, DispatchLogger, COMIDA, ComView 

• State-sponsored actors don't break in. They log in, and they use your own tools to stay invisible for months.
• Responding to a state-sponsored threat is nothing like responding to ransomware, and the differences can make or break the outcome. 
• From logging and baselines to OT segmentation and supply chain readiness, the work that matters happens long before the first alert.

Most organizations operate under the assumption that anything residing within their trust boundary is trustworthy. Software arrives from vetted vendors, employees pass background checks, cloud providers hold compliance certifications, and build pipelines produce signed artifacts. 

In practice, these assumptions are rarely scrutinized, and state-sponsored actors have constructed their operational methodology around exploiting precisely this gap. They operate inside the trust boundary, using trusted tools, holding valid credentials, and performing actions that appear entirely authorized. Conventional security architecture is not designed to identify this, and that limitation warrants acknowledgment before turning to what incident response looks like when the adversary is a state-sponsored.

Responding to a state-sponsored intrusion is fundamentally different from responding to a criminal one. The adversary is better resourced, more patient, operationally disciplined, and often in pursuit of objectives that do not trigger any alarms, such as espionage or long-term data extraction. Standard incident response playbooks, typically built around malware containment and ransomware recovery, are not adequate for this category of threat. The tooling, decision-making, legal coordination, and even the definition of what constitutes a successful response all need to be reconsidered.  

This is also the context in which zero trust architecture becomes essential. This is a fundamental reorientation from a model in which trust is assumed to one in which it is continuously verified, and in which systems are architected to handle the case where verification fails. The operative principle is not "trust nothing," which no organization can realistically operationalize, but rather "verify continuously and plan for failure." 

The following sections cover how state-sponsored actors operate across the Cyber Kill Chain, why their techniques demand different detection and response approaches, and what organizations need to have in place before, during, and after an intrusion to mount an effective response.

Same Kill Chain, different objective 

Every cyber attack, from commodity ransomware to state-sponsored espionage, follows the same fundamental sequence as the Cyber Kill Chain developed by Lockheed Martin: reconnaissance, weaponization, delivery, exploitation, installation, command and control (C2), and action on objectives. State-sponsored actors do not deviate from this sequence. They execute each phase with greater patience, greater precision, and a fundamentally different objective. 

A financially motivated attacker requires the target to know it has been compromised. The ransomware note, the leak site, and the negotiation channel are all components of the business model. A state-sponsored actor requires the opposite. Whether the objective is espionage, intellectual property theft, or pre-positioning for future disruption, success depends on the target remaining unaware. That requirement for covertness shapes every technical decision the actor makes and determines what defenders need to look for at each phase. The following are common trends that change the dimensions of defense:

• Reconnaissance: This stage tends to be deeper and more prolonged. Where a financially motivated actor might scan for exposed Remote Desktop Protocol (RDP) and move on, a state-sponsored adversary may spend weeks or months mapping an organization's personnel, technology stack, vendor relationships, and communication patterns, often entirely outside the target's perimeter through open-source intelligence (OSINT) and social engineering of adjacent organizations. This phase frequently leaves no artifacts in defender logs. State-sponsored actors also have lawful access laws in their respective countries that allow them to obtain some of this data without the target being aware that any reconnaissance is taking place.
• Initial access: State-sponsored adversaries can afford to expend significant capabilities against a single target, including zero-days or supply chain vectors that signature-based detection will not identify. More commonly, however, they use legitimate credentials obtained through spear phishing or supply chain compromise, which produce no exploit signature at all. 
• Lateral movement: This is where the covert imperative becomes most technically consequential. Rather than deploying custom malware, state-sponsored actors increasingly operate using tools already present on the target's systems, such as PowerShell, WMI, and PsExec, or they take time to observe what tools are used in the environment. If the environment uses SCCM or Puppet to manage infrastructure, the state-sponsored actor will aim to gain access to these systems and use legitimate deployment methods to compromise additional hosts. When Active Directory is queried through PowerShell, the security stack registers a routine administrative task, because it is indistinguishable from one. Extended dwell times result not from slow operational tempo, but from deliberate use of trusted tools to minimize the detection surface. 
• Persistence: State-sponsored actors operate on the assumption that any single access method may be discovered and therefore establish multiple mechanisms across different parts of the infrastructure. Think aboutscheduled tasks, modified service configurations, dormant accounts, and firmware-level implants. These footholds may remain inactive for extended periods, activating only when an intelligence requirement or geopolitical trigger demands it. 
• Action on objectives: This stage may not resemble what most teams would identify as an incident. If the objective is long-term data collection, exfiltration is structured to blend into normal traffic patterns. If the objective is pre-positioned disruption, as CISA assessed with Volt Typhoon in U.S. critical infrastructure, the actor may take no visible action during peacetime. Salt Typhoon's access to lawful intercept systems required no disruptive action to deliver intelligence value. The access itself was the operation. When that access gets used is a separate question. 
• Anti-forensics: Advanced actors clear event logs, manipulate file timestamps, operate in memory where possible, and use encrypted channels that leave minimal artifacts. Attribution may be further complicated by the deliberate planting of indicators associated with a different threat actor. 

Detection methodology does not require reinvention. The Kill Chain remains the same. It does, however, need to be calibrated for an adversary that treats every phase as an exercise in remaining invisible, that can operate using the target's own tooling, and that measures success in months of undetected access.

Attribution 

Attribution in the context of incident response deserves a straightforward treatment, because it is frequently misunderstood and its operational relevance is often overstated at the tactical level. Technical attribution, associating an intrusion with a known threat actor based on tactics, techniques, and procedures (TTPs); infrastructure; and malware characteristics is possible with varying degrees of confidence and is useful primarily for informing the threat model and anticipating likely next steps. An organization that can assess with reasonable confidence that Volt Typhoon is responsible for an intrusion can make better-informed decisions about what systems to prioritize, what persistence mechanisms to hunt for, and what the likely objectives are. Political attribution, the public or legal assignment of responsibility to a state-sponsored actor, is a government function -not a security team function - and attempting it without the intelligence resources to support it creates more risk than it resolves. 

The practical implication for incident response teams is that TTPs and infrastructure indicators should be shared with national authorities and relevant Information Sharing and Analysis Centers (ISACs), who are better positioned to place them in a broader intelligence context. Internal response should focus on containment, scope determination, and recovery regardless of whether attribution is ever formally established. 

Preparing for the long game 

Encountering a state-sponsored actor during incident response is not the time to discover logging gaps, missing baselines, or that the legal team has never discussed intelligence sharing with government agencies. The following sections cover the areas where preparation most directly determines whether detection and response are feasible. 

Logging and visibility 

Default logging configurations are not sufficient for detecting the techniques described above. 

• Windows process creation (Event ID 4688): Enable full command-line argument logging to track exact parameters used during process execution. 
• PowerShell script block logging (Event ID 4104): Capture the actual code being executed, not just the fact that PowerShell was launched. 
• Sysmon: Deploy with a configuration tuned to detect suspicious parent-child process relationships, flagging legitimate binaries used as proxies for malicious activity, both on Windows and Linux environments. 
• Strategic prioritization: If a full Sysmon rollout is impractical, prioritize critical servers, externally facing web applications, and cloud environments. Deploying Sysmon everywhere is sometimes not feasible due to very extensive and noisy logging. Prioritization is important here. 
• Centralized log aggregation: Forward all logs to a write-once, centralized location, as sophisticated actors routinely clear local event logs, permanently destroying evidence left on compromised hosts 

More broadly, visibility needs to extend across identity systems, endpoints, network infrastructure, and cloud environments. 

Endpoint telemetry alone is insufficient. State-sponsored actors operating through legitimate tools will generate process events that are difficult to distinguish from normal administrative activity, and network-layer visibility provides an independent detection plane that host-based logging cannot replace. 

• NetFlow analysis: Connection metadata without payload content is sufficient to identify unusual communication patterns, including beaconing behavior characteristic of C2 channels and lateral movement between systems that have no operational reason to communicate. 
• DNS logging: Many C2 frameworks rely on DNS for command delivery and exfiltration. A host suddenly querying domains it has never previously resolved, or generating abnormal DNS query volumes, warrantsinvestigation. 
• Encrypted traffic analysis: Machine learning models can identify C2 communication patterns in TLS sessions without breaking encryption, based on session timing, packet size distributions, and connection frequency. These capabilities do not require deep packet inspection and remain viable where privacy or compliance constraints limit payload visibility. 

Behavioral baselines 

CISA's joint advisory on living-off-the-land techniques recommends maintaining continuous baselines across network traffic, user behavior, administrative tool usage, and application activity. The emphasis on "continuously" is not incidental. A baseline established once and left unattended can generate more problems than it resolves, creating false confidence that normal has been adequately defined, when in reality theorganization has moved on. Baselines need to reflect seasonal patterns, organizational changes, infrastructure updates, and role transitions. When an administrator changes teams, their access patterns shift. When a new application is deployed, new NetFlow patterns emerge. If the baseline fails to keep pace, genuine threats blend into an outdated picture of normal, and anomaly detection becomes a source of noise rather than signal.

Statistical anomaly detection can surface the low-and-slow deviations characteristic of state-sponsored lateral movement, but tuning is an ongoing commitment, and false positive management carries a real operational cost that should not be underestimated. 

State-sponsored actors do not typically maintain access through malware alone. Once inside, they move through identity infrastructure. Privileged access management deserves explicit treatment: administrative accounts should operate on a tiered model that prevents domain administrator credentials from being exposed on workstations, and service accounts should be scoped to the minimum access their function requires. Detection logic needs to account for credential abuse patterns that do not involve any malicious tooling. Pass-the-hash and pass-the-ticket attacks use legitimate authentication protocols and will not trigger antivirus. Kerberoasting, where an attacker requests service tickets for offline cracking, is visible in Kerberos event logs but only if those logs are collected and someone is looking. Anomalous authentication patterns, such as accounts authenticating at unusual hours, from unusual sources, or against systems they have never previously accessed, are among the more reliable behavioral signals available, provided the baseline exists to contextualize them. 

Operational security (OPSEC) 

If a state-sponsored breach is confirmed, the response needs to assume the adversary can see internal communications. If they have domain admin access, they can likely read email. If they have compromised a collaboration platform, they may be able to see the incident response channel. Here are some of the common aspects that should be considered:  

• Out-of-band communications: Use encrypted channels on separate, unconnected devices to ensure investigative communications remain outside the compromised infrastructure. 
• Compartmentalization: Limit knowledge of the investigation to essential personnel only, as each additional person aware of the response is a potential vector for the adversary to detect the investigation. 
• Pre-established authority contacts: Maintain established relationships with national authorities, CERTs, and intelligence agencies before a crisis occurs, rather than identifying the right contacts during an active incident. 

Organizations should also have a pre-established relationship with national authorities, including the relevant contacts at national CERTs or intelligence agencies, rather than trying to find the right person during a crisis. 

OT and Industrial Control System (ICS) readiness 

For organizations with OT environments, the threat model extends beyond what most IT-centric IR plans address. 

The IT-OT boundary that appears on network diagrams is a logical construct, and state-sponsored actors treat it as a lateral movement path rather than a barrier. Volt Typhoon demonstrated this in concrete terms by moving from compromised IT infrastructure toward OT-adjacent systems, including those controlling water treatment plants and electrical substations. Through 2025, the group progressed from IT reconnaissance to directly interacting with OT network-connected devices and extracting sensor and operational data, representing a transition from passive espionage to what amounts to a sabotage-ready foothold, maintained quietly and positioned for activation when circumstances require it. Important aspects are:  

• Availability as a safety constraint: OT systems often cannot be taken offline for forensic imaging, as production shutdowns in energy, water, or manufacturing carry significant safety and economic consequences.Investigations must work around live systems. 
• Patching constraints: Many OT systems run legacy software that cannot be updated without vendor involvement, making virtual patching through IDS/IPS rules the only viable near-term remediation option. 
• Insufficient software-defined segmentation: IT/OT boundaries relying solely on software-defined controls are inadequate, as a compromised account with sufficient privileges can reconfigure them. 
• Hardware-enforced unidirectional gateways: Data diodes provide a physical, deterministic guarantee of network separation that cannot be overridden by a compromised account or software misconfiguration. 
• Regulatory alignment: Both CISA and the UK's NCSC recommend engineering-based, deterministic protections for OT boundaries as the baseline standard. 

Supply chain readiness 

Vendors, software dependencies, and network infrastructure are all extensions of the trust boundary, and preparing for supply chain compromise means understanding those dependencies and having response procedures ready before one of them is exploited. Some critical measures are as follows: 

• Software Bill of Materials (SBOM): Maintain an SBOM for all applications and monitor it against vulnerability databases using automated tooling, connected directly to infrastructure. 
• Vendor access inventory: Map which systems each third party can access, through what mechanisms, and at what privilege level. 
• Contractual incident notification: Enforce 24-hour disclosure clauses in vendor contracts to ensure timely notification of compromise, preventing containment windows from closing before the organization is aware. 
• Pre-authorized IR procedures: Define in advance what gets revoked, what gets isolated, and who makes the call for each vendor integration, eliminating delays while an adversary continues to operate. 
• Firmware inventory: Maintain a firmware inventory with patch status for every network device, including firewalls, routers, switches, and VPN concentrators. 
• Legacy and end-of-life (EOL) devices: Apply compensating controls such as network isolation, enhanced monitoring, and virtual patching to devices that can no longer receive patches, as they represent supply chain risk sitting inside the perimeter. 

Insider threat readiness 

In the state-sponsored context, the insider threat is not about a disgruntled employee stealing files. It is a structured intelligence operation that uses the hiring process itself as an attack vector, and preparation requires a cross-functional program spanning security, HR, legal, and finance because the indicators span all four domains. 

For planted insiders, the DPRK IT worker scheme being the most documented example, hiring verification needs to go beyond standard background checks. This includes live, multi-stage video interviews with liveness verification that current deepfake technology cannot reliably defeat (for now), digital footprint validation across independent data sources, detection of VoIP phone numbers and shared credentials across applications, and cross-referencing candidate information for the kinds of inconsistencies a fabricated identity cannot fully conceal. 

For all insider categories, behavioral baselines and data loss prevention policies should be in place before an incident occurs. Legal pre-authorization for employee monitoring is also important to establish ahead of time. Trying to build that legal framework during an active investigation will either delay the response or create legal exposure. 

Why your IR plan needs revisiting 

If your current IR plan covers malware and ransomware but typically it does not address supply chain compromise, insider threats, or living-off-the-land techniques. Most IR plans simply reflect a threat landscape that has already shifted. These gaps should be addressed through distinct playbooks, each with its own containment decision trees, evidence collection procedures, legal coordination requirements, and recovery verification steps. Each playbook should be tested through tabletop exercises built around realistic scenarios. 

One aspect of state-sponsored incident response sets it apart from criminal incident response is that the adversary may be observing the response in real time, will likely attempt to regain access after eviction, and the diplomatic, legal, and intelligence dimensions of the incident extend well beyond the security operations center. 

The containment decision in a state-sponsored incident is rarely straightforward. Treating it as a binary choice between immediate isolation and inaction understates the complexity involved. In a criminal incident, early containment is almost always the correct approach. In a state-sponsored incident, premature containment can eliminate the opportunity to understand the full scope of the adversary's access, forfeit the ability to collect intelligence on their infrastructure, and signal to the adversary that they have been detected. That signal may trigger accelerated action on their objectives before defenses are fully in place. 

The deliberate choice to monitor silently while the adversary operates introduces its own legal, ethical, and operational risks. That decision should never be made unilaterally by the SOC. It requires input from legal counsel and senior leadership, and in many cases a conversation with national authorities before it is exercised. 

The incident response plan should define in advance who holds decision authority over containment timing, what criteria govern the transition from silent monitoring to active containment, and what evidence collection must be completed before containment begins. Tabletop exercises that do not incorporate this decision point are not adequately preparing teams for the reality of state-sponsored incident response. 

Post-incident 

After containment and recovery, the work is not finished. The intelligence collected during the incident has value beyond the organization that was targeted, and sharing it through ISACs and government channels contributes to a broader defensive picture that benefits the entire sector. Internally, the after-action review should map findings to MITRE ATT&CK, not as a compliance exercise but as a structured way to identify where detection failed, where response was too slow, and where controls need to be strengthened. That review should feed directly into updated detection logic, revised access controls, and adjusted monitoring priorities. 

Threat hunting should not stop when the incident is closed. A state-sponsored actor that has been evicted will often attempt to regain access using different infrastructure or modified techniques, and sustained hunting focused on the specific actor's TTPs is the most reliable way to catch that early. Tabletop exercises should also be updated to reflect what was learned, so the next time a similar scenario plays out, the team is not relearning the same lessons under pressure. 

None of this is new guidance, but in the context of state-sponsored threats, where the adversary is persistent, well-resourced, and likely to return, these activities stop being procedural housekeeping and become direct preparation for the next intrusion. 

Where to start when you have low budget, minimal staff, and competing priorities 

Everything covered above assumes an organization can invest in logging, baselines, segmentation, supply chain controls, and dedicated IR planning in parallel. In reality, most security teams are operating under hiring freezes, flat budgets, and competing priorities, and the guidance to "do all of this" is not actionable without a sense of sequencing. The following is a pragmatic order of operations for teams that need to make meaningful progress without a step-change in resourcing. 

Start with visibility, because you cannot defend what you cannot see. Before buying new tooling, turn on what you already own. Enabling Windows command-line logging (Event ID 4688), PowerShell script block logging (Event ID 4104), and centralized log forwarding costs nothing in licensing and addresses the single largest gap most organizations have. If logs are not being collected and retained centrally, no amount of downstream investment will compensate. 

After this, prioritize identity over endpoints. State-sponsored actors move through credentials, not malware that can be easily fingerprinted, blocked, and made public through sandboxes. Enforcing multi-factor authentication (MFA) on all administrative accounts, implementing tiered admin models, and reviewing service account privileges typically delivers more risk reduction per hour invested than any endpoint initiative. These are configuration changes, not procurement cycles. 

Next, focus monitoring where the adversary has to go. If Sysmon everywhere is not feasible, then deploy it on domain controllers, identity infrastructure, externally facing systems, and critical servers. An adversary pursuing meaningful objectives will eventually touch these systems, and concentrated visibility on them is more valuable than thin visibility everywhere. 

The underlying principle is that state-sponsored readiness is not a single large investment. It is a sequence of smaller decisions where the early ones disproportionately determine whether the later ones are ever useful. Visibility and identity come first. Everything else builds on them.