In our previous blog, we explored a series of disclosures from the leak persona Nightmare-Eclipse that focused heavily on Microsoft's ecosystem, including Windows Defender, Cloud Files, and core operating system functionality.

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

This is a collaborative follow-up to our original post, developed jointly with Emmanuel C., a security researcher not affiliated with LevelBlue, who contributed additional infrastructure and tooling findings based on an analysis of the same GitHub staging account.

All threats

In Q2 2026, the percentage of ICS computers on which malicious objects were blocked continued to decrease, falling to 19.15%, its lowest level since 2022.

Percentage of ICS computers on which malicious objects were blocked, Q3 2023–Q2 2026

Regionally, the percentages ranged from 8.1% in Northern Europe to 27.9% in Africa.

Regions ranked by percentage of attacked ICS computers

The figures increased in five regions over the quarter, most notably in East Asia (by 2.0 pp) and Africa (by 0.5 pp).

East Asia saw increases in percentages for all threats except miners. The region ranked first in terms of growth for malicious scripts and phishing pages, spyware, and viruses. East Asia also led in terms of growth in threats from the internet. The percentage of ICS computers on which email threats were blocked also increased.

Selected industries

The biometrics sector (26.44%) has traditionally led the rankings of industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked. Biometric systems are characterized by the availability of internet access, extensive email use for data exchange and approvals (e.g. access granting), and, in many cases, minimal cybersecurity controls within the organizations that use them.

Industries ranked by percentage of ICS computers on which malicious objects were blocked

The biometrics sector ranked first among industries in terms of the following threat categories: malicious scripts and phishing pages, malicious documents, spyware, ransomware, and worms. The sector is also leading among industries in terms of email threats. At the same time, unlike other industries, the percentage of affected ICS computers for email threats in biometrics exceeds that for internet threats.

In all selected industries, the global average follows a downward trend.

Threat categories

In Q2 2026, Kaspersky security solutions blocked malware from 10,904 different malware families of various categories on industrial automation systems.

Over the quarter, the percentage of ICS computers on which malicious objects of the following categories were blocked increased: denylisted internet resources, malicious documents, worms, ransomware, and malware for AutoCAD.

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

Malicious scripts and phishing pages (JS and HTML)

Malicious scripts and phishing pages remained in first place in the threat category rankings based on the percentage of ICS computers on which the respective threats were blocked. In Q2 2026, the global average dropped to 5.42%.

Over the quarter, the figure for this category only increased in East Asia, rising by 0.93 pp to 4.86%. This is the second-highest figure in the region in the last three years.

In East Asia, the percentage of ICS computers affected by malicious scripts and phishing pages increased in all the industries surveyed, except construction. The highest figures were recorded for biometrics (9.01%) and building automation (6.49%).

Denylisted internet resources

In Q2 2026, denylisted internet resources rose in the threat category rankings from third to second place, displacing spyware. Globally, the percentage of ICS computers on which denylisted internet resources were blocked has been increasing for two quarters in row and reached 4.31%.

The figures increased in all regions over the quarter, most notably in Russia (by 1.33 pp). Moreover, Russia ranked first (5.17%) among the regions in terms of denylisted internet resources. Since 2022, the region has topped these rankings twice before, both times in Q2: in 2022 and 2024.

Among the selected industries in Russia, the highest figures for the denylisted internet resources were in the electric power (6.61%) and engineering and ICS integration (5.62%) industries.

Malicious documents (MSOffice + PDF)

Malicious documents ranked fourth in the threat category rankings by the percentage of ICS computers on which they were blocked. The percentage for this category decreased over the previous three quarters, reaching its lowest level in three years. However, in Q2 2026, it increased to 1.77%.

Over the quarter, the figures for malicious documents increased in seven regions, most notably in South America (by 1.35 pp) and Southern Europe (by 0.48 pp). These two regions are among the top three in terms of malicious documents, malicious scripts and phishing pages, as well as threats from email clients.

South America ranked second in the rankings of regions in terms of malicious documents. In Q2 2026, the percentage of ICS computers in the region on which this threat was blocked was 3.56%, which was the fourth highest in three years.

Among the selected industries in South America, the highest percentage of ICS computers on which malicious documents were blocked was in biometrics (6.67%).

Southern Europe ranked first in the rankings of regions in terms of malicious documents. In the previous quarter, the percentage of ICS computers in the region on which this threat was blocked was the lowest in three years, but in Q2 2026 it increased to 3.63%.

Among the selected industries in Southern Europe, the highest percentage of ICS computers on which malicious documents were blocked was once again in biometrics (11.48%).

Spyware

Spyware ranked third in the threat category rankings based on the percentage of ICS computers on which it was blocked. The percentage for this category (3.30%) is the lowest since 2022.

Over the quarter, the figures increased in three regions, most notably in East Asia (by 0.53 pp) and Southeast Asia (by 0.42 pp).

East Asia ranked third based on the figures for spyware (4.77%), behind Africa and Southeast Asia. This is the region’s highest rate since Q2 2025. Among the countries and territories in the region, the highest percentage of ICS computers on which spyware was blocked was in mainland China (6.61%). Among the selected industries in East Asia, the highest figures for spyware were in the electric power (11.75%) and manufacturing (5.87%) industries. In all the industries surveyed, the figures are higher than the regional average.

Southeast Asia ranked second after Africa in the ranking of regions in terms of spyware, with 5.32%. Among the selected industries in Southeast Asia, the highest figures for spyware were in biometrics (8.93%) and manufacturing (7.32%). The figures increased in all industries over the quarter.

Ransomware

The percentage of ICS computers on which ransomware was blocked decreased in the previous three quarters but increased to 0.16% in Q2 2026.

During the quarter, the percentage increased in all regions, except Western and Southern Europe and North America (Canada). Africa led the ranking in terms of growth for this metric.

In Q2 2026, Africa ranked first among the regions in terms of the percentage of ICS computers on which ransomware was blocked (0.29%). The only time the figure in the region was higher in the past three years was Q2 2025 (0.31%).

Among the selected industries in Africa, the highest figures for ransomware were in the electric power industry (0.72%) and biometrics (0.52%). Over the quarter, the figures increased in all industries, except manufacturing and construction. The biggest increase was recorded in the electric power industry.

In Russia, the percentage of ICS computers on which ransomware was blocked in biometric systems has increased for three consecutive quarters, reaching 1.22%. This is the highest level of ransomware across all industries in all regions.

Miners

In Q2 2026, the percentage of ICS computers on which miners were blocked was the lowest since 2021, for both miners in the form of executable files for Windows (0.48%) and web miners running in browsers (0.14%).

The figures for both categories decreased in all regions, except for Africa where figures for miners in the form of executable files for Windows increased slightly.

On average, the oil and gas industry led the rankings among the selected industries both in terms of miners in the form of executable files for the Windows OS (0.66%) and in terms of web miners (0.34%).

Worms

In Q2 2026, the percentage of ICS computers on which worms were blocked increased to 1.43%.

In Q2 2026, the Middle East (2.11%) was second (after Africa) in the rankings of regions in terms of worms, displacing Central Asia and the South Caucasus.

Among the selected industries in the Middle East, the highest percentage of ICS computers on which worms were blocked was in building automation (2.90%). Over the quarter, the figures increased in all industries.

Australia and New Zealand ranked 12th among the regions in terms of the percentage of ICS computers on which worms were blocked (0.41%). Over the past three years, the figure in this region was only higher in Q2 2024 (0.42%). The figures increased in all the surveyed industries in the region, most notably in manufacturing and electric power. As a result, for these industries they exceeded the regional average by 2.9 and 2.3 times, respectively.

Viruses

In Q2 2026, the percentage of ICS computers on which viruses were blocked decreased to 1.29%.

The top three regions for this metric remain unchanged: Southeast Asia (6.03%), Africa (4.22%), and East Asia (3.14%). These same regions lead the rankings in terms of malware for AutoCAD.

The figures increased in three regions: East Asia, Australia and New Zealand, and Africa, where it has been growing for four consecutive quarters and reached its highest value since 2022.

Among the selected industries in Africa, the highest percentage of ICS computers on which viruses were blocked was in construction (5.47%).

East Asia ranked third among the regions in terms of viruses, reaching the highest level in the region for the past three years. Among the countries and administrative regions of East Asia, mainland China is the clear leader in terms of viruses (5.07%).

Among the selected industries in East Asia, the highest percentage of ICS computers on which viruses were blocked was in construction (5.93%).

In Australia and New Zealand, the increase in the percentage of ICS computers on which viruses were blocked was primarily due to a 4.3-fold increase in the figure for the electric power industry: from 0.29% to 1.24%. For a region where the percentage of attacked ICS computers for all threats is 0.12%, this is a very high value.

Malware for AutoCAD

In Q2 2026, the percentage of ICS computers on which malware for AutoCAD was blocked increased to 0.31%.

The most notable increase over the quarter was observed in Africa. After more than doubling in the previous quarter, the figure for the region continued to rise (although not so dramatically), reaching 1.02%.

Among the selected industries across all regions, the highest percentage of ICS computers on which malware for AutoCAD was blocked was in construction in East Asia (6.38%) and in Southeast Asia (4.05%).

Main threat sources

In Q2 2026, of all the threat sources, the percentage increased only for email.

Percentage of ICS computers on which malicious objects from various sources were blocked

Internet

The percentage of ICS computers on which threats from the internet were blocked decreased to 7.61%, reaching its lowest level since 2021.

Over the quarter, the percentage increased in three regions: East Asia by 0.8 pp (to 6.3%), South Asia by 0.3 pp (to 10.4%), and Russia by 0.3 pp (to 6.4%).

Among the selected industries across all regions, the highest percentage of ICS computers on which threats from the internet were blocked was in biometrics (13.03%) and engineering and ICS integration (12.16%) in South Asia.

Email

The percentage of ICS computers on which email threats were blocked increased to 2.84%.

In Q2 2026, the percentage of ICS computers on which email threats were blocked increased in South America by 1.0 pp (to 5.2%) and in Africa by 0.7 pp (to 4.3%).

Among the selected industries across all regions, the highest percentage of ICS computers on which email threats were blocked was in biometrics (19.14%) and building automation (12.49%) in Southern Europe.

Removable media

The percentage of ICS computers on which threats from removable media were blocked continued to decrease, reaching 0.24%, the lowest value for the period under review.

Among the selected industries across all regions, the highest percentage of ICS computers on which threats from removable media were blocked was in the electric power industry in East Asia (1.34%) and biometrics in Africa (1.29%).

Network folders

The percentage of ICS computers on which threats from network folders were blocked continued to decrease. In Q2 2026, it was the lowest for the period under review, at 0.023%.

The only region to see an increase in the percentage of ICS computers on which threats from network folders were blocked during the quarter was Africa. This was mainly due to an increase in the building automation figure to 0.05%.

Among the selected industries across all regions, the highest percentage of ICS computers on which threats from network folders were blocked was in biometrics (0.23%), building automation (0.17%), and engineering and ICS integration (0.13%) in East Asia.

For more information on industrial threats see the full version of the report.

Following GreenPlasma, YellowKey and MiniPlasma, RoguePlanet and GreatXML, and LegacyHive, the Nightmare-Eclipse disclosure actor has published ShieldBreak — its latest Windows proof of concept (PoC) released shortly after Microsoft's August 2026 Patch Tuesday.

To stay ahead of evolving threats, LevelBlue utilizes a machine-learning-based URL scanner that constantly evaluates the digital landscape. We closely monitor VirusTotal for instances where LevelBlue acts as the sole detection layer — a crucial tactic for spotting new phishing campaigns early. In this blog, we will unpack several notable phishing campaigns discovered through this method.

IT threat evolution in Q2 2026. Mobile statistics
IT threat evolution in Q2 2026. Non-mobile statistics

The mobile section of the quarterly cyberthreat report includes statistics on malware, adware, and potentially unwanted software for Android, as well as descriptions of the most notable threats for Android and iOS discovered during the reporting period. These statistics are based on detection alerts from Kaspersky products, collected from users who consented to provide statistical data to Kaspersky Security Network.

The quarter in figures

According to Kaspersky Security Network, in Q2 2026:

• More than 1.99 million attacks on mobile devices utilizing malware, adware, or unwanted mobile software were blocked.

• The Trojan-Banker category was the most prevalent mobile malware threat with a 30.77% share of total detected applications.
• More than 304,000 malicious installation packages were discovered, including:
  • 93,574 packages were related to mobile banking Trojans;
  • 570 packages were related to mobile ransomware Trojans.

Quarterly highlights

Attacks on mobile devices involving malware, adware, or unwanted software continued their downward trend, falling to 1,996,823 in Q2 from 2,676,328 the previous quarter.

Attacks on users of Kaspersky mobile solutions, Q4 2024 — Q2 2026 (download)

We noted a downward trend in attacks driven by specific strains of pre-installed Trojans — a shift likely tied to the rollout of patched vendor firmware.

In Q2, our telemetry uncovered multiple malicious loaders hosted directly on Google Play. As highlighted in a prior report (link in Russian), one such instance involved a PDF reader app trojanized to drop the Anatsa banking malware. Upon execution, the app presented users with a fake request to install an update, which served as a front to stage the banking Trojan on the victim’s device.

Another notable case involves a loader we detected in the Cleanova app alongside several others. The malware sent requests to a command-and-control server containing telemetry gathered from various SDKs that track the installation source. A malicious payload was returned only for certain sources. This is a fairly interesting method for bypassing app store review processes while ensuring precise victim targeting. If an analytics SDK indicates that an arbitrary installation originated from a source outside the threat actors’ scope, the malicious logic remains dormant. This effectively hides the malware from app store scanners.

Mobile threat statistics

In Q2, the number of Android malware samples totaled 304,128. It remained steady compared to the previous reporting period.

Detected malicious and potentially unwanted installation packages, Q2 2025 — Q2 2026 (download)

The detected installation packages were distributed by type as follows:

Detected mobile apps by type, Q1 — Q2 2026* (download)

* Data for the previous quarter may differ slightly from previously published data due to certain verdicts being retrospectively revised.

While the number of newly discovered banking Trojan variants fell precipitously, they continued to dominate the threat landscape as they did in Q1. Notably, the share of Creduz malware family among identified banking samples has grown significantly despite low activity in victim telemetry. This discrepancy suggests the threat actors are actively iterating on the malware — likely testing new features or bypasses — by generating a high volume of builds before staging a broader campaign.

Share* of users attacked by the given type of malicious or potentially unwanted apps out of all targeted users of Kaspersky mobile products, Q1 — Q2 2026 (download)

* The total may exceed 100% if the same users experienced multiple attack types.

Within the adware category, the sharpest declines were observed in the HiddenAd and MobiDash families. Meanwhile, the proportion of users targeted by Trojan-Dropper malware increased, primarily driven by surges in banking droppers such as Trojan-Dropper.AndroidOS.Banker and Trojan-Dropper.AndroidOS.Mamont. The corresponding drop in the Trojan-Banker category is partially explained by a shift in tactics: several banking Trojans which are now being packed were subsequently reclassified as droppers.

TOP 20 most frequently detected types of mobile malware

Note that the malware rankings below exclude riskware or potentially unwanted software, such as RiskTool or adware.

* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.

The distribution of top malware families in Q2 largely mirrors the rankings from the previous reporting period. Newer variants of the Mamont banking Trojan climbed the leaderboards, displacing older iterations. This shift points to ongoing, active development of new variants by the threat actors behind the malware.

Mobile banking Trojans

In Q2, the total volume of Trojan-Banker applications dropped sharply compared to the previous quarter, totaling 93,574 installation packages.

Number of installation packages for mobile banking Trojans detected by Kaspersky, Q2 2025 — Q2 2026 (download)

Against the backdrop of this trend, the distribution shifted heavily toward Creduz Trojans. However, as noted earlier, this shift was not reflected in real-world attack metrics: virtually the entire leaderboard by proportion of targeted users continues to be dominated by diverse Mamont variants.

TOP 10 mobile bankers

* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats.

The LevelBlue OpsCTI Team recently identified a large-scale phishing campaign leveraging a new social engineering method to deploy unauthorized ConnectWise ScreenConnect clients. Rather than relying on conventional phishing pages, the campaign recreates convincing software update and installation alerts by impersonating the Microsoft Store and Apple App Store while reproducing the look and behavior of trusted applications through dynamic modal dialogs and other interactive web elements. The campaign impersonates trusted software and services, including Google Meet, Adobe Acrobat, Microsoft Teams, Zoom, Docusign, Secure Access Manager, Blue Mountain, Paperless Post, and other popular applications.

Europe faced a ransomware onslaught in the first half of 2026 that sets a troubling precedent for the remainder of the year. According to Cyble Research and Intelligence Labs (CRIL), the region experienced 866 documented ransomware attacks, 51 confirmed data breach incidents, and 7 initial access sales between January and June 2026. These figures represent not just a volume problem, but a fundamental shift in how threat actors are organizing, targeting, and monetizing their operations within European territory.

What distinguishes the ransomware threats in Europe from other global regions is the concentration of power among a small number of highly sophisticated threat actors. While the threat ecosystem encompasses dozens of groups, five dominant ransomware operators account for approximately 55% of all documented activity. This concentration creates predictability—European security leaders can now identify, profile, and build specific defensive strategies against known adversaries.

The Five Dominant Ransomware Groups Targeting Europe

1. Qilin: The Biggest Ransomware Threat in Europe

Attack Volume: 158 documented incidents (18.2% of regional total)

Qilin stands as the dominant ransomware threat actor targeting Europe, commanding operational superiority through sophisticated affiliate management, rapid exploit weaponization, and industry-specific targeting intelligence.

Geographic Concentration:

• Germany: 32 attacks (highest single-country targeting)
• France: 28 attacks
• United Kingdom: 26 attacks
• Spain: 20 attacks
• Italy: 19 attacks

Worldwide Sectoral Targeting: Qilin demonstrates deliberate sectoral selection rather than opportunistic targeting:

• Construction: 103 incidents (primary focus)
• Professional Services: 90 incidents (legal, accounting, consulting firms)
• Manufacturing: 67 incidents (industrial operations)
• Government & Law Enforcement: 19 incidents
• Technology: 22 incidents

Operational Characteristics:

Qilin's dominance stems from understanding European organizational economics. Construction projects operate under time-sensitive contracts with contractually-defined penalties for delay. A single day of downtime on a €50 million construction project can trigger cascading costs exceeding €100,000. This economic reality translates directly into ransom payment likelihood, making Qilin's targeting strategy rational and highly effective.

The group maintains an extensive affiliate network capable of concurrent operations across multiple European nations. Evidence suggests Qilin has compartmentalized its operations: initial access brokers handle reconnaissance and network compromise, mid-tier operators manage lateral movement and privilege escalation, and final-stage operators execute encryption and exfiltration. This division of labor enables rapid scaling and reduces attribution risk.

Why Qilin Dominates:

• Industry Expertise: Deep understanding of construction project timelines and financial exposure
• Affiliate Loyalty: Competitive payout structures (estimated 70-80% to affiliates) ensure consistent operator recruitment
• Exploit Library: Rapid weaponization of both known and zero-day vulnerabilities
• Data Monetization: Established data brokerage partnerships ensure exfiltrated data reaches buyers

European Security Implications: Organizations in construction, professional services, and manufacturing should treat Qilin as their primary threat actor concern. Defensive strategies must prioritize data exfiltration prevention, network segmentation, and immutable backup infrastructure.

2. The Gentlemen: The Rising European Threat

Attack Volume: 144 documented incidents (16.6% of regional total)

The Gentlemen represent an emerging threat actor that has achieved remarkable scale in a relatively short operational window. Unlike established groups that evolved from other cybercriminal operations, The Gentlemen appear purpose-built for ransomware-as-a-service operations.

Geographic Concentration:

• Europe: 144 attacks (primary focus)
• United States: 100 attacks (secondary focus)
• Thailand: 35 attacks (supply-chain targeting)
• South Asia: 40 attacks

Worldwide Sectoral Targeting:

• Construction: 45 incidents
• Manufacturing: 56 incidents
• Healthcare: 37 incidents
• IT & ITES: 36 incidents
• Professional Services: 29 incidents

Operational Characteristics:

The Gentlemen's rapid emergence and sustained growth suggest significant operational funding and technical sophistication. The group's geographic diversification—maintaining European dominance while aggressively expanding into Asia-Pacific—indicates either organizational scale or partnerships with regional threat actors.

Notably, The Gentlemen's Thailand targeting (35 incidents) suggests supply-chain attack sophistication. By compromising manufacturing and logistics operations in Thailand, the group can leverage these beachheads for downstream attacks against Western European organizations. This cross-continental supply-chain targeting represents a significant evolution in ransomware operational sophistication.

Key Distinction: While Qilin focuses on maximizing ransom payments from individual targets, The Gentlemen appear to prioritize operational scale and geographic expansion. This suggests the group may be building toward either:

1. A mega-RaaS platform rivaling LockBit's historical dominance
2. Preparation for potential acquisition or partnership with state-sponsored actors
3. Geographic arbitrage—leveraging lower prosecution risk in developing nations while maintaining European operations

European Security Implications: The Gentlemen's emergence signals market competition is intensifying. Organizations should monitor this group's operational evolution closely, as aggressive growth often precedes operational mistakes that create defensive opportunities.

3. LockBit: The Persistent Legacy Threat

Attack Volume: 61 documented incidents (7.0% of regional total)

LockBit's presence in European targeting represents a significant finding given sustained law enforcement pressure and multiple platform disruption attempts. Despite being targeted by coordinated international takedown operations, LockBit maintained operational capability throughout H1 2026.

Geographic Concentration:

• Europe: 61 attacks (Primary operations)
• North America: 47 attacks (Secondary operations)
• Distributed: Global presence indicating resilient infrastructure

Worldwide Sectoral Targeting:

• Construction: 22 incidents
• Manufacturing: 22 incidents
• Government & LEA: 12 incidents
• Healthcare: 19 incidents
• Professional Services: 13 incidents

Operational Resilience:

LockBit's continued operations despite international enforcement actions demonstrate several critical lessons:

1. Affiliate Compartmentalization: By maintaining separate operational cells, LockBit can continue operations even when core infrastructure is disrupted
2. Rapid Rebranding: The group has adopted multiple identities and platform variants, complicating attribution
3. Infrastructure Redundancy: Multiple command-and-control server locations across jurisdictions with varying law enforcement cooperation levels
4. Operator Recruitment: Continuous recruitment of new affiliates from emerging cybercriminal talent pools

The group's continued viability suggests that law enforcement actions, while disruptive, are insufficient to eliminate established RaaS operations. Organizations cannot rely on law enforcement intervention as a defensive strategy; they must assume LockBit and similar groups will remain operational threats indefinitely.

European Security Implications: LockBit should remain on European security teams' active threat monitoring lists. The group maintains technical sophistication, access to critical zero-day exploits, and demonstrated willingness to target European critical infrastructure.

4. Akira: The Opportunistic European Operator

Attack Volume: 59 documented incidents (6.8% of regional total)

Akira represents a secondary-tier ransomware group with focused European operations. The group demonstrates strong preference for Manufacturing and Construction sectors, suggesting industry-specific expertise or targeted affiliate recruitment.

Geographic Concentration:

• Europe & UK: 59 attacks (Secondary focus)
• North America: 268 attacks (Primary focus)
• Secondary: Limited operations in other regions

Worldwide Sectoral Targeting:

• Manufacturing: 54 incidents
• Construction: 57 incidents
• Professional Services: 47 incidents
• Consumer Goods: 34 incidents
• Healthcare: 13 incidents

Operational Profile:

Akira's disproportionate North American presence (268 attacks) with lower European activity (59 attacks) suggests the group may have established affiliate networks in North America with secondary capacity for European operations. The strong manufacturing and construction focus mirrors Qilin's strategy, indicating these sectors offer superior ransom payment likelihood across multiple geographic markets.

European Security Implications: While not as immediately threatening as Qilin or The Gentlemen, Akira's persistent operations warrant inclusion in threat modeling exercises. European manufacturing and construction organizations should monitor Akira's affiliate recruitment channels and tactical innovations.

5. Dragonforce: The Supply-Chain Specialist

Attack Volume: 54 documented incidents (6.2% of regional total)

Dragonforce rounds out the top-five European threat actors with apparent specialization in Manufacturing and Technology sectors, suggesting possible supply-chain attack capabilities.

Geographic Concentration:

• North America: 135 attacks (Primary focus)
• Europe & UK: 54 attacks (Secondary focus)
• Secondary: Limited global operations

Worldwide Sectoral Targeting:

• Manufacturing: 31 incidents
• Construction: 48 incidents
• Professional Services: 28 incidents
• Food & Beverages: 9 incidents
• Healthcare: 9 incidents

Operational Pattern:

Dragonforce's heavy US focus with secondary European operations suggests the group may be leveraging North American-based supply chains to gain access to European targets. Manufacturing supply chains are deeply interconnected across transatlantic partners; compromising US manufacturers could provide lateral access into European operations.

European Security Implications: European manufacturing organizations should implement aggressive third-party risk management programs, particularly for US-based suppliers. Dragonforce's supply-chain sophistication suggests the group may bypass direct targeting in favor of compromising upstream vendors.

Also read: The Most Active Threat Actors of H1 2026

The Five Most Targeted European Nations

Germany: The Manufacturing Battleground

Attack Volume: 155 ransomware attacks (17.9% of regional total)

Germany's position as Europe's manufacturing powerhouse places it at the center of ransomware targeting campaigns. The nation's industrial sector—encompassing automotive, machinery, chemicals, and precision manufacturing—represents the most valuable ransomware target set in Europe.

Threat Actor Concentration:

• Qilin: 32 attacks (20.6% of German total)
• The Gentlemen: 32 attacks
• LockBit: 18 attacks
• Akira: 32 attacks
• Dragonforce: 9 attacks

Sectoral Breakdown:

• Manufacturing: 67 incidents (significant concentration)
• Construction: 38 incidents
• Professional Services: 28 incidents
• Technology: 15 incidents
• Healthcare: 12 incidents

Why Germany Faces Maximum Pressure

German organizations represent an optimal target combination: high asset value, supply-chain criticality, strong operational technology integration, and proven willingness to pay ransoms to maintain production schedules. Additionally, Germany's federal structure creates jurisdictional complexity that may slow law enforcement response.

The nation's Mittelstand (mid-market manufacturing firms) are particularly vulnerable—large enough to justify ransom payments, but sometimes lacking enterprise-grade security infrastructure.

Defensive Priority: German manufacturing organizations should assume Qilin, The Gentlemen, Akira, and Dragonforce all maintain active operations targeting their sector. Network segmentation between IT and operational technology (OT) environments should be elevated to critical priority.

United Kingdom: The Financial Services Crosshairs

Attack Volume: 138 ransomware attacks (15.9% of regional total)

The UK faces a different threat profile than Germany, driven primarily by London's position as a global financial services hub. While manufacturing is targeted, Banking, Financial Services, and Insurance (BFSI) organizations command disproportionate attention.

Threat Actor Concentration:

• Qilin: 26 attacks
• The Gentlemen: 26 attacks
• LockBit: 18 attacks
• Akira: 13 attacks
• Dragonforce: 11 attacks

Sectoral Breakdown:

• BFSI: 38 incidents (concentrated targeting)
• Technology: 32 incidents
• Retail: 26 incidents
• Professional Services: 24 incidents
• Government & LEA: 16 incidents

Why the UK Is Targeted

London's financial services ecosystem manages trillions in assets, making it extraordinarily valuable to data-exfiltrating threat actors. BFSI organizations hold customer financial data, internal financial records, and strategic information that commands premium prices on dark web marketplaces.

Additionally, regulatory requirements (FCA, PRA, etc.) create pressure for rapid ransom payment to avoid breach notification delays that could trigger regulatory sanctions.

Data Exfiltration Risk: The UK's status as a financial services hub makes it particularly vulnerable to data-centric attack strategies. Organizations should assume that successful breach attempts will include aggressive data exfiltration alongside encryption deployment.

Defensive Priority: UK BFSI organizations must implement robust data loss prevention (DLP), encryption for data in transit and at rest, and aggressive monitoring for unauthorized data access or exfiltration attempts.

France: The Balanced Threat

Attack Volume: 119 ransomware attacks (13.7% of regional total)

France experiences balanced threat distribution across multiple sectors, reflecting both its manufacturing capacity and significant professional services sector.

Threat Actor Concentration:

• Qilin: 28 attacks
• The Gentlemen: 28 attacks
• LockBit: 15 attacks
• Akira: 14 attacks
• Dragonforce: 8 attacks

Sectoral Breakdown:

• Professional Services: 26 incidents
• Manufacturing: 24 incidents
• Construction: 19 incidents
• Technology: 14 incidents
• Healthcare: 10 incidents

Why France Faces Distributed Threat

As Europe's second-largest economy, France is attractive to ransomware operators across multiple sectors. The nation's professional services sector (legal, accounting, consulting) is particularly valuable for data exfiltration, while manufacturing remains a consistent target.

Defensive Priority: French organizations should implement sector-specific defensive strategies: professional services firms should prioritize client data protection and DLP, while manufacturing organizations should focus on OT segmentation and operational resilience.

Italy: The Construction and Manufacturing Hub

Attack Volume: 115 ransomware attacks (13.3% of regional total)

Italy faces concentrated targeting in construction and manufacturing sectors, with particular pressure on small-to-medium enterprises in industrial regions.

Threat Actor Concentration:

• Qilin: 19 attacks
• The Gentlemen: 18 attacks
• LockBit: 12 attacks
• Akira: 16 attacks
• Dragonforce: 8 attacks

Sectoral Breakdown:

• Construction: 48 incidents (concentrated)
• Manufacturing: 38 incidents
• Professional Services: 18 incidents
• Retail: 14 incidents

Why Italy Faces Sector-Specific Pressure

Italy's construction industry is particularly vulnerable to ransom attacks due to tight project timelines and significant financial exposure. The nation's manufacturing sector, while sophisticated, sometimes operates with legacy infrastructure that creates exploitation opportunities.

Defensive Priority: Italian construction and manufacturing organizations should prioritize incident response readiness, backup infrastructure resilience, and supply-chain risk management.

Spain: The Emerging Risk

Attack Volume: 87 ransomware attacks (10.0% of regional total)

Spain experiences lower absolute attack volume than Germany, UK, France, or Italy, but faces concentrated pressure in manufacturing and professional services sectors.

Threat Actor Concentration:

• Qilin: 20 attacks
• The Gentlemen: 18 attacks
• LockBit: 8 attacks
• Akira: 12 attacks
• Dragonforce: 7 attacks

Sectoral Breakdown:

• Manufacturing: 28 incidents
• Professional Services: 19 incidents
• Construction: 16 incidents
• Technology: 10 incidents

Regional Observation: Spain's lower attack volume may reflect either lower overall ransomware targeting or more effective defensive implementations. Spanish security teams should not interpret lower numbers as reduced threat but rather as a baseline for future comparison.

Where European Organizations Face Maximum Risk: A Sectoral Analysis

Construction: The Ransomware Goldmine

Attack Volume: 107 documented incidents (58% of all sector targeting across regions – not just in Europe – analyzed)

Construction organizations face disproportionate ransomware targeting across the entire European region. This concentration reflects understood economic vulnerabilities that threat actors exploit with precision.

Why Construction Is Targeted

1. Time-Sensitive Financial Exposure: Construction projects operate under contractually-defined timelines. Each day of delay triggers cascading costs, financial penalties, and potential contract termination. Organizations facing potential loss of €50-100 million contracts will prioritize rapid recovery over law enforcement involvement.
2. Operational Technology Integration: Modern construction increasingly relies on Building Information Modeling (BIM), cloud-based project management, and real-time equipment tracking. This IT/OT convergence creates exploitation pathways unavailable in purely IT-based industries.
3. Supply-Chain Complexity: Construction projects depend on dozens of subcontractors and suppliers. Compromising a single upstream supplier can provide lateral access into prime contractors.
4. Financial Pressure: Construction firms often operate with tight cash flow, making ransom negotiation essential to preserve solvency.
5. Accessibility: Many construction firms, particularly smaller regional players, operate with basic security infrastructure, creating easy exploitation opportunities.

European Construction Risk Mapping:

• Germany (14 attacks): Heavy machinery and precision manufacturing integration
• Switzerland (10 attacks): Legacy infrastructure vulnerabilities
• Spain (13 attacks): Emerging targeting activity
• France (10 attacks): Balanced threat across major metropolitan areas
• UK (21 attacks): Infrastructure project concentration (rail, utilities, etc.)

Defensive Recommendations for Construction:

• Network Segmentation: Isolate operational technology (project equipment, heavy machinery) from corporate IT networks
• Access Control: Implement strict authentication for remote project management tools (Autodesk Forge, Procore, etc.)
• Immutable Backups: Maintain offline, immutable backups of critical BIM files and project documentation
• Incident Response Readiness: Develop construction-specific response playbooks addressing project continuity
• Supply-Chain Due Diligence: Implement security requirements for subcontractors and equipment suppliers

Professional Services: The Data Exfiltration Target

Attack Volume: 86 documented incidents

Professional services firms (law, accounting, consulting) face sophisticated targeting driven by data exfiltration opportunities rather than operational disruption pressure.

Why Professional Services Are Targeted

1. Client Confidentiality Risk: Legal privilege and client confidentiality create existential regulatory and reputational exposure. Threat actors leverage this to demand premium ransoms.
2. Sensitive Data Concentration: Professional services firms accumulate client financial records, litigation strategies, tax information, and corporate secrets—all commanding premium dark web prices.
3. Regulatory Exposure: GDPR breach notification requirements create pressure for rapid response and ransom payment to avoid regulatory sanctions.
4. Supply-Chain Position: Professional services firms advise major corporations; compromising advisors provides indirect access to clients.
5. Trust-Based Business Model: Client relationships depend on confidentiality. A single breach can destroy long-term client relationships and firm reputation.

European Professional Services Risk:

• France (16 attacks): Concentrated targeting of Paris-based firms
• Germany (16 attacks): Heavy focus on Frankfurt financial advisory firms
• UK (17 attacks): London-based legal and accounting partnerships
• Italy (6 attacks): Milan and Rome-based advisory firms
• Spain (7 attacks): Barcelona and Madrid professional services sector

Key Finding: Professional services firms experience disproportionate data breach incidents (exfiltration with confirmed leak activity) compared to other sectors. Of the 51 total data breach incidents across Europe and UK, professional services represents a concentrated target.

Defensive Recommendations:

• Client Data Segregation: Isolate client data on separate network segments with distinct access controls
• Data Loss Prevention (DLP): Deploy DLP solutions with aggressive egress controls monitoring client data exfiltration
• Encryption Standards: Implement client-facing encryption for all sensitive communications
• Access Auditing: Maintain comprehensive logs of all access to sensitive client data
• Ransomware-Specific Insurance: Consider cyber insurance with specific ransomware coverage addressing confidentiality exposure

Manufacturing: The Supply-Chain Critical Target

Attack Volume: 123 documented incidents

European manufacturing organizations face sophisticated, supply-chain-aware threat actors who understand production dependencies and downtime economics.

Why Manufacturing Is Targeted

1. Operational Technology Integration: Modern factories integrate IT and OT systems. Ransomware deployment can halt production lines, creating catastrophic financial exposure.
2. Supply-Chain Criticality: Manufacturing downtime cascades through dependent enterprises. A single organization's compromise can impact dozens of downstream customers.
3. Export Dependency: European manufacturers serve global markets. Production delays translate directly into lost revenue and market share.
4. Legacy Infrastructure: Many manufacturing facilities operate aging, unpatched systems integrated with newer IT infrastructure, creating exploitation bridges.
5. Financial Pressure: Manufacturing organizations face razor-thin margins; production downtime can drive solvency crises.

Geographic Manufacturing Risk Concentration:

• Germany (27 attacks): Automotive, machinery, precision manufacturing
• Italy (21 attacks): Fashion, machinery, chemical manufacturing
• France (15 attacks): Automotive, aerospace, industrial manufacturing
• Spain (10 attacks): Automotive, machinery, manufacturing
• UK (14attacks): Aerospace, automotive, precision manufacturing

Critical Vulnerability Pattern: Manufacturing organizations are disproportionately targeting known, exploitable vulnerabilities in critical infrastructure appliances (network appliances, security tools, identity systems). Rather than deploying zero-days, threat actors exploit patched vulnerabilities that organizations have not implemented.

Defensive Recommendations:

• OT/IT Segmentation: Implement airgapped network separation between operational technology and corporate IT
• Vulnerability Management Prioritization: Focus patching efforts on network appliances, security tools, and identity systems
• Industrial Control System (ICS) Monitoring: Deploy behavioral monitoring for unusual activity on manufacturing control systems
• Immutable Backup Strategy: Maintain completely offline backups of critical manufacturing configurations
• Supply-Chain Security Program: Implement tier-1 and tier-2 supplier security assessments and vulnerability scanning
• Incident Response Scenario Planning: Develop detailed playbooks for production-line ransomware scenarios

Healthcare: The Critical Infrastructure Threat

Attack Volume: 35 documented incidents

Healthcare organizations face a unique threat dynamic where ransomware directly endangers patient safety, creating existential operational pressure distinct from financial threats.

Why Healthcare Is Targeted

1. Patient Safety Risk: Ransomware disables critical medical systems (diagnostic equipment, pharmaceutical dispensing, patient records). Unlike other industries, downtime directly threatens life.
2. Regulatory Pressure: GDPR, HIPAA-equivalent regulations, and national privacy laws create breach notification requirements that incentivize ransom payment.
3. Data Value: Patient medical records, pharmaceutical research data, and clinical trial information command premium dark web prices.
4. Continuous Operation Requirement: Unlike manufacturing or services, healthcare cannot delay critical procedures. The operational pressure to pay ransoms is existential.
5. System Complexity: Healthcare IT environments integrate numerous legacy systems (PACS, EHR, medical devices) with varying security architectures.

European Healthcare Risk Distribution:

• Germany (14 attacks): Concentrated in Berlin, Munich, and Frankfurt urban medical centers
• Austria (2 attacks): private healthcare sector
• France (5 attacks): Concentrated in Paris and Lyon region hospitals
• Switzerland (3 attacks): medical centers
• Spain (3 attacks): Barcelona and Madrid hospital networks

Critical Finding: Healthcare organizations experience disproportionately high data breach incident rates, suggesting organized threat actors specifically target health information exfiltration.

Defensive Recommendations:

• Clinical System Isolation: Implement complete network separation between clinical systems and corporate IT
• Redundant Critical Systems: Deploy redundant diagnostic and pharmaceutical systems capable of manual operation
• Patient Data Encryption: Implement end-to-end encryption for all patient medical records
• Breach Response Planning: Develop healthcare-specific incident response plans addressing patient notification and continuity of care
• Medical Device Security: Implement inventory and monitoring for all connected medical devices
• Supply-Chain Assessment: Assess security of medical device manufacturers and pharmaceutical distributors

The Data Exfiltration Reality: Beyond Encryption

Confirmed Data Breaches: 51 Incidents Across Europe and UK

While ransomware attacks total 866, only 51 incidents resulted in confirmed data breaches and leaks (5.9% confirmation rate). This apparent low percentage masks a critical operational truth: organizations cannot distinguish between encryption-only attacks and data exfiltration scenarios until exfiltration attempts or threats emerge.

Data Breach Distribution by Sector:

Critical Observation: BFSI and Telecom sectors experience disproportionate data breach incidents, suggesting these industries are specifically targeted for data exfiltration rather than operational disruption. The strategic implication is clear: threat actors targeting financial and telecommunications organizations prioritize data monetization over ransom payment.

Most Active Threat Actors in Data Exfiltration: The Leak Economy

Primary Exfiltration Actors:

Strategic Finding: While Qilin, The Gentlemen, and LockBit dominate ransomware attack volume, data exfiltration is fragmented across numerous smaller actors, including tanaka (6 posts), kazutlg (4 posts), and dozens of single-incident operators. This suggests a mature data brokerage ecosystem where extracted data is resold to specialized exfiltration actors.

Dark Web Data Marketplace Activity:

• 916 unique domains impacted by data leaks
• Approximately 86 distinct leak posts across dark web channels
• Data types: Financial records, customer PII, medical records, intellectual property, trade secrets

Implication: Organizations can no longer assume encrypted data is "lost forever" if backups are restored. Exfiltrated data will be monetized regardless of whether organizations pay ransoms. Data loss prevention becomes as critical as ransomware detection.

Geopolitical and Ideological Dimensions: The Activism-Cybercrime Convergence

Pro-Russian Hacktivism: Blurred Lines Between Ideology and Profit

H1 2026 witnessed increasing overlap between geopolitically motivated hacktivism and financially motivated cybercrime, particularly among pro-Russian collectives targeting NATO-aligned European nations.

Key Threat Actors to Monitor

NoName057(16) - The Pro-Russian DDoS Coalition

• Primary Activity: Large-scale DDoS attacks against NATO-aligned governments and Ukrainian supporters
• Secondary Activity: Data exfiltration for monetization
• Geographic Targets: Estonia, UK, Ukraine, Italy, Spain, France, Poland, Norway, Denmark, Lithuania, Latvia, Czech Republic, Germany, Moldova
• Operational Pattern: Coordinated DDoS campaigns often accompanied by data theft and subsequent leak activity

Operational Evolution: NoName057(16) began as a purely activist collective claiming ideological motivation (anti-NATO, pro-Russia). By H1 2026, the group had evolved to include data exfiltration and monetization—suggesting either organizational evolution or infiltration by financially motivated threat actors.

Strategic Implication: European organizations cannot compartmentalize threat modeling. A geopolitically motivated attack that begins as a DDoS campaign can transition into ransomware deployment when exfiltration opportunities present themselves.

Strategic Defense Recommendations for European Organizations

Prioritized Defensive Roadmap

Based on CRIL's H1 2026 regional data, European security leaders should prioritize defensive investments in the following sequence:

Phase 1: Critical Infrastructure Protection (30 days)

1. Inventory Network Appliances: Document all network appliances (firewalls, SD-WAN platforms, security gateways, VPNs)
2. Patch Critical CVEs: Prioritize patches for Cisco, Ivanti, Palo Alto, Fortinet, and Microsoft appliances
3. Access Control Hardening: Implement MFA for all remote administrative access to network infrastructure
4. Monitoring Deployment: Deploy behavioral monitoring on network appliances for anomalous activity

Phase 2: Data Protection (60 days)

1. Data Inventory: Identify and catalog sensitive data holdings (customer data, financial records, intellectual property)
2. DLP Implementation: Deploy data loss prevention solutions with egress monitoring
3. Encryption Standards: Implement encryption for data in transit (TLS 1.3+) and at rest (AES-256)
4. Access Logging: Enable comprehensive audit logging for all sensitive data access

Phase 3: Operational Resilience (90 days)

1. Immutable Backups: Establish offline, immutable backup infrastructure isolated from network access
2. Incident Response Planning: Develop organization-specific incident response playbooks addressing ransomware scenarios
3. Business Continuity: Identify critical business functions and develop continuity strategies
4. Disaster Recovery Testing: Conduct quarterly backup restoration testing to verify recovery capabilities

Phase 4: Threat Hunting and Detection (Ongoing)

1. Threat Intelligence Integration: Subscribe to European threat intelligence feeds focusing on Qilin, The Gentlemen, LockBit, Akira, and Dragonforce
2. Behavioral Detection: Deploy endpoint detection and response (EDR) solutions with behavioral analytics
3. Supply-Chain Monitoring: Implement continuous monitoring of vendor and supplier security posture
4. Insider Threat Program: Develop insider threat detection capabilities focusing on data exfiltration attempts

Regional Threat Actor Summary: Who Targets Your European Organization

Sector-Specific Threat Actor Mapping

If You're in Construction:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: Akira, Dragonforce
• Vulnerability: Network segmentation gaps, supply-chain vulnerabilities, legacy OT systems
• Defensive Focus: OT/IT segmentation, immutable backups, supplier security assessment

If You're in Professional Services:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: LockBit, Akira
• Vulnerability: Client data exfiltration, regulatory exposure, ransomware payment pressure
• Defensive Focus: DLP, client data encryption, ransomware-specific insurance

If You're in Manufacturing:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: Akira, Dragonforce
• Vulnerability: OT/IT integration, supply-chain exploitation, operational downtime pressure
• Defensive Focus: OT segmentation, vulnerability prioritization, continuity planning

If You're in BFSI:

• Primary Threat: Qilin, The Gentlemen, LockBit
• Secondary Threat: Data exfiltration actors (tanaka, kazutlg)
• Vulnerability: Financial data value, regulatory breach notification pressure, customer trust exposure
• Defensive Focus: Data encryption, DLP with aggressive egress controls, cyber insurance

If You're in Healthcare:

• Primary Threat: Qilin, The Gentlemen, LockBit
• Secondary Threat: Data exfiltration operators
• Vulnerability: Patient safety risk, critical operational pressure, medical device security
• Defensive Focus: Clinical system isolation, redundant critical systems, incident response for operational continuity

Conclusion: The European Ransomware Reality

Europe and the UK face a mature, organized ransomware ecosystem dominated by five sophisticated threat actors who have developed deep understanding of regional economic vulnerabilities. The threat is not random or opportunistic—it is strategic, targeted, and evolved.

Key Takeaways:

1. Five groups dominate: Qilin (158 attacks), The Gentlemen (144), LockBit (61), Akira (59), and Dragonforce (54) collectively account for 476 of 866 documented attacks (55%). European security leaders can build specific defensive strategies against known adversaries.
2. Geography matters: Germany, UK, France, Italy, and Spain face distinct threat profiles. Security strategies must be regionally and sector-specific, not generic.
3. Sectors are targeted deliberately: Construction, Professional Services, and Manufacturing are not randomly selected—they face extraordinary pressure due to economic vulnerabilities that threat actors systematically exploit.
4. Data exfiltration is the primary leverage: Of 866 attacks, only 51 resulted in confirmed breaches—but this understates the risk. Organizations must assume all breaches involve data exfiltration and cannot rely on backup restoration alone.
5. Patch management is the primary defense: Nearly 90% of exploited vulnerabilities had patches available. Disciplined patch management, particularly for network appliances, would prevent the vast majority of successful attacks.
6. Known vulnerabilities are the current threat: Despite awareness of zero-day sophistication, threat actors continue exploiting known vulnerabilities because patches lag adoption. This creates a predictable exploitation window that defensive teams can close.

For European security leaders, the path forward is to understand your regional threat actors, prioritize critical infrastructure protection, implement robust data protection measures, and establish resilient backup and recovery infrastructure. The threat is severe, but it is also understood and defensible. The question is not whether European organizations will face ransomware attacks in the remainder of 2026 and beyond—the data confirms they will. The question is whether they will be prepared.

The post Ransomware Threats in Europe H1 2026: A Deep Dive into Regional Attack Patterns and Dominant Threat Actors appeared first on Cyble.

Analysis of ChainDrop, an npm supply chain worm extracting GitHub Actions runner secrets and using Ethereum smart contracts for C2 routing.

The post ChainDrop: Inside a Self-Propagating npm Worm appeared first on Unit 42.

In light of the water-sector activity described below, we've increased monitoring for related indicators of compromise across our client environments. Please contact your LevelBlue account team with questions specific to your environment.

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

Introduction

Because of the amount of data that can be obtained and the high impact that successful attacks may have, educational institutions are frequent targets of cybercriminals. Both public and private schools and universities rely on software for managing personally identifiable information (PII) that is often insecure or insufficiently tested against known vulnerabilities. In addition, machines used by multiple people without accountability can be vulnerable to insider threats.

The complexity of academic environments amplifies this risk. Unlike corporate networks, educational institutions have to provide a network that supports students, professors, researchers, administrative staff, third-party contractors, and visitors. Each of these groups has different security requirements and access control levels, making it difficult to enforce consistent security policies. A security breach can have severe consequences since it may expose vast amounts of sensitive information, such as social security numbers (CPF in Brazil), addresses, phone numbers, and even parents’ names. Armed with this information, attackers can attempt phishing attacks and impersonate the victims in SIM swapping attacks, a common practice in Brazil.

In this article, we provide details about attacks on educational institutions in Brazil observed by our Global Emergency Response Team (GERT) since 2025. We share general statistics, common threats, initial access vectors, and the impact of such violations. Additionally, we present some interesting cases encountered by our team and the identified TTPs. Finally, we offer recommendations to help institutions protect themselves against future attacks.

Key findings and statistics

Our dataset encompasses incident response cases from January 2025 to June 2026. As the chart below shows, the majority of attacks targeted institutions in São Paulo state, Brazil’s most populous state and a significant center of economic and financial activity. We also had cases in Rio de Janeiro and Pernambuco.

Geographical distribution of incident response requests at educational institutions (download)

Of the customers who requested incident response, 60% were private institutions and 40% were public institutions.

Private and public institutions (download)

The most frequent reasons for requesting IR services were related to suspicious endpoint activities, encrypted files, and the presence of suspicious files.

Incident response request reasons (download)

High-severity incidents accounted for 40% of the total cases, while the remaining 60% were medium severity.

Distribution of incidents by severity (download)

The high-severity incidents were mainly related to ransomware attacks. Interestingly, private institutions were the most targeted by ransomware, while incidents in public institutions were mostly related to suspicious endpoint activity and privilege escalation attempts. The most common ransomware families found in our dataset were DragonForce and LockBit 3, whose builder was leaked back in 2022. By using the leaked LockBit builder with a valid privileged account, attackers can build variants capable of disabling defenses and erasing logs.

The most common initial access vectors included the use of valid accounts, exploitation of public-facing applications, and insiders.

Initial access vectors (download)

For privilege escalation, the attackers often relied on Potato variants (GodPotato, SweetPotato, and BadPotato).

We also observed attackers using tools like AnyDesk for remote access, PsExec for lateral movement within compromised infrastructures, and AV-killer malware to terminate the system’s defenses. The latter was mainly used in ransomware-related incidents.

These data reveal an interesting pattern in the threat landscape affecting educational institutions in the region. Many incidents were not caused by highly sophisticated techniques but rather by the abuse of common weaknesses such as valid accounts, exposed applications, and inadequate patch management, as well as the use of publicly available tools that are well-known to the adversaries. The prevalence of ransomware in private institutions suggests a stronger financial motivation, likely because attackers assume these organizations are more capable of paying for data recovery than public schools and universities.

Most attacks were discovered promptly and lasted from a few minutes to a couple of hours. However, technical incident response activities averaged 9.6 hours. This indicates that the impact caused by an incident often extends beyond the timeframe of the active attack, requiring extensive triage and analysis by the forensic investigators to fully restore operations.

One interesting fact is that we are still observing the use of Windows 10 in the infrastructures of educational institutions, even after Microsoft’s official end-of-support date of October 2025. In addition, we found that some customer organizations were using Windows Server 2016 without security patches and fixes. Using outdated and unsupported operating systems increases the attack surface of an infrastructure because attackers can exploit publicly available vulnerabilities to access vulnerable systems and expand their presence in the network. In addition, legacy operating systems may be incompatible with modern evidence collection tools, necessitating extra time and alternative procedures for forensic acquisition.

Obsolete systems in organizations (download)

Interesting cases

Case 01 – Leaked LockBit builder

In one case, we identified the use of a custom version of LockBit that was generated using the leaked builder. The ransomware was delivered to the organization’s infrastructure via a valid account that had been leaked. It encrypted the organization’s internal systems, including file servers and databases that stored student profiles and other data. There was no evidence of data exfiltration from the affected machines.

During our analysis of the LockBit sample, we were able to extract its configuration. Interestingly, it was configured without the impersonation and spreading options. This meant the attacker had to perform manual lateral movement to deploy the malware across the network.

"config": {
    "settings": {
      "impersonation": false,
      "local_disks": true,
      "network_shares": true,
      "kill_processes": true,
      "kill_services": true,
      "set_wallpaper": true,
      "self_destruct": true,
      "kill_defender": true,
      "wipe_freespace": true,
      "psexec_netspread": false,
      "gpo_netspread": false,
…

Further analysis revealed that the attacker used PsExec for lateral movement. By analyzing the Update Sequence Number (USN) Journal, we were able to identify .KEY files associated with PsExec that showed us the previously compromised machines used by the attacker.

After gaining access to the target machines, the adversaries deployed a batch script to disable the system’s defenses. Our analysis of this artifact showed that they had the administrative credentials to disable the EDR in place. In addition, the script enabled RDP, which gave the attackers remote access to the target. The listing below shows an excerpt of the script:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
netsh advfirewall firewall add rule name="allow RemoteDesktop" dir=in protocol=TCP localport=3389 action=allow
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v DisableRealtimeMonitoring /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableBehaviorMonitoring /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableOnRealTimeProtection /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableIOAVProtection /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableScriptScanning /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SpyNetReporting /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SubmitSamplesConsent /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "SecurityHealth" /t REG_SZ /d "" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{UUID}" /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v ServiceKeepAlive /t REG_DWORD /d 0 /f
sc stop WinDefend
sc config WinDefend start= disabled

Finally, by cross-checking the Prefetch files, we were able to identify the precise dates of PsExecSvc.exe and LBB.exe (LockBit) execution. This revealed that the attacker established the initial connection to the analyzed machine around 5:30am UTC and ran LBB.exe for the last time at 10am UTC on the same day, resulting in an activity window of approximately four hours and thirty minutes. We were able to identify the extent of the compromise and the additional machines that required network isolation for further forensic analysis, containment, and remediation.

Case 02 – DragonForce deployed via AnyDesk

In another incident, we identified a compromised user account that the adversaries used to install the AnyDesk software to enable remote access. Although the attacker erased the system logs after encrypting the victim’s files, we were able to identify the ransomware execution event via the Prefetch and Amcache.hve files, which provided us with the SHA-1 hash of the sample.

Once we obtained the SHA-1 of the malicious artifact (named by the attacker as 1.EXE), we were able to confirm that it was a DragonForce variant. Even though the lack of evidence made the analysis more difficult, this case shows that forensic investigators must be prepared to identify information that the attackers missed or left untouched.

Case 03 – Python keylogger used by an insider

The third incident illustrates how a series of bad practices enabled an insider to collect passwords from other users inside the infrastructure. First, the customer contacted us stating that a machine was exhibiting strange behavior: files containing passwords were being created. We started with triage collection on one of the affected machines.

Evidence from the Program Compatibility Assistant (PCA) showed the execution of two suspicious files, Windows Host Widgets.exe and Windows Host Widgets_.exe, both located in the C:\Users\<user>\.vscode\dlo directory, where <user> represents a user account shared by everyone who uses the machine. The same artifacts were identified within the Amcache.hve file, and multiple executions were also confirmed by analyzing the Prefetch files. Another interesting source of evidence, UserAssist, confirmed that the threat actor also executed both EXE files by double-clicking on them.

MFT analysis showed that multiple log files named cacheX.txt were created in the previously mentioned directory, where X was a number that increased with each malware execution. We then analyzed the EXE files to confirm their behavior. Luckily, both proved to be the same Python script, which we could easily decompile.

As shown in the listing below, the script contains methods and strings with Portuguese names. It is capable of hiding the log files from view in Explorer. The developer also set a procedure to identify when the Caps Lock key was pressed, in order to record the correct passwords.

def get_base_path():
    ...

def encontrar_proximo_nome(base='cache'):
    ...

def set_file_hidden(filepath):
    ...
    ctypes.windll.kernel32.SetFileAttributesW(str(filepath), FILE_ATTRIBUTE_HIDDEN)
    ...

with open(log_file, 'a', encoding='utf-8') as f:
    f.write(f'\n\n--- Registro iniciado em {datetime.datetime.now()} ---\n')
set_file_hidden(log_file)
...

def is_capslock_on():
    return bool(ctypes.windll.user32.GetKeyState(20) & 1)

...

def on_press(key):
    ...

def on_release(key):
    ...

def main():
    with keyboard.Listener(on_press=on_press, on_release=on_release) as listener:
        listener.join()

if __name__ == '__main__':
    main()

This simple script did not implement any persistence or automated data exfiltration mechanisms. Therefore, the insider likely had to manually retrieve the generated log files containing the text typed by the victims. By revisiting the previously collected evidence, we identified USB connections around the same time as the script’s executions. This suggests that removable media was probably used to collect the generated keylogging logs from the environment. As a result of the investigation, the customer changed the passwords of all affected accounts. However, without additional evidence or footage, it was not possible to conclusively attribute the activities to a specific individual and take the appropriate disciplinary and legal measures.

Conclusions and recommendations

The incidents highlighted in this article demonstrate that Brazilian educational institutions face a diverse set of threats, ranging from ransomware operations to insider activity. In many cases, the attackers relied on valid credentials, exposed services, remote access tools, poor patch management, and insufficient endpoint hardening rather than advanced malware or new techniques. Based on these findings, educational institutions should prioritize controls that reduce the likelihood of account compromise and the impact of ransomware deployment. They should also improve forensic visibility after an incident.

Institutions should enforce the use of multi-factor authentication (MFA) for all publicly accessible services, especially VPNs, remote access portals, and email accounts. Since valid accounts were one of the most common initial access vectors observed in our dataset, MFA can significantly reduce the likelihood that stolen or reused credentials alone will compromise the entire environment. We also recommend periodically reviewing privileged accounts, removing unnecessary administrative permissions, and avoiding shared accounts, especially on machines accessed by multiple users, since this makes accountability extremely difficult.

Each user should have their own account, following the principle of least privilege to prevent unauthorized software execution. Additionally, it is advisable to restrict and monitor the use of remote access tools such as AnyDesk or TeamViewer. Unexpected installations or executions of these tools should be treated as high-priority alerts.

To minimize the impact of ransomware, educational institutions should improve their backup and recovery strategy. Backups should be isolated from the primary environment (preferably in more than one location) and tested regularly. Centralized logging, extended EDR telemetry retention, and proper time synchronization across hosts can also improve the ability to reconstruct an attack timeline and implement the necessary response measures.

The use of outdated systems increases the attack surface, so we recommend that organizations adopt an effective update and patch management policy. It is also important to raise security awareness, since users must understand the risks associated with credential sharing, unknown executables, and unauthorized software.

From a digital forensics and incident response (DFIR) perspective, the reviewed incidents demonstrate that effective incident response activities require correlating multiple forensic artifacts in order to reconstruct the attacker’s actions. Investigators should be aware of how to find information even when logs are missing. Many other artifacts are preserved and can be used for this purpose, such as Amcache, PCA, Prefetch, UserAssist, MFT, and USN Journal. The attackers may fail to erase all traces of their activity, so taking a broad forensic approach is of the utmost importance for determining the scope of the compromise and supporting containment and remediation actions.

Observed TTPs

The table below shows the observed TTPs in our dataset, including cases not detailed in this post.

Explore the latest tactics, techniques, and procedures (TTPs) our incident response (IR) experts are actively facing in the quarterly TTP Briefing, a report built on frontline threat intelligence from our global incident response investigations across LevelBlue during Q2 2026.

Vexed researcher Nightmare-Eclipse (aka Chaotic Eclipse, Dead Eclipse, and MSNightmare) released his ninth unpatched Windows vulnerability called LegacyHive. This latest bug drop is a Local Privilege Escalation (LPE) vulnerability affecting Windows User Profile, a component responsible for loading and unloading Windows user profiles. When exploited, LegacyHive can enable attackers to load other users’ hives and gain access to application data and Windows Explorer history, among others.

In June 2025, LevelBlue SpiderLabs published Tracing Blind Eagle to Proton66, in which we assessed with high confidence that Blind Eagle (also tracked as APT-C-36, APT-Q-98, TAG-144, AguilaCiega), a threat actor focused on Latin America, had moved part of its VBScript delivery infrastructure onto the Russian bulletproof hosting provider Proton66. A year later, we're still tracking this cluster closely, and the group hasn't slowed down. If anything, it has kept building.

You're browsing a legitimate small business website. Before the page loads, a familiar Cloudflare box appears: "Verify you are human." It asks you to open Terminal, paste a code, and press Enter. You've seen this before. You follow the steps. The page loads normally.

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. 

Introduction

In January 2026, we identified multiple attacks involving unknown malware that captures the contents of cryptocurrency wallet windows. During the investigation, we reconstructed the complete infection chain, which consisted of four tightly linked stages initiated by the execution of the previously described malicious PowerShell script TookPS. However, this campaign differs from previous activity in that it uses a new framework to deliver all malicious modules and orchestrate them via an SSH tunnel. In total, the framework includes more than 20 malicious payloads and implants, covering a wide variety of functions. At the time of writing, the threat remains active.

Kaspersky’s products detect this threat as Trojan-Downloader.Win32.TookPS.*, Trojan.Win64.BypassUAC.*, Trojan-Banker.Script.Agent.gen, Trojan.Win32.Dllhijack.*, Backdoor.Win32.TeviRat.*, Trojan-PSW.Win64.Stealer.*, Trojan-Spy.Win64.Keylogger.*, Trojan-Spy.Win64.Agent.*, Trojan.Win64.Agent.*.

Background

TookPS is a downloader used for retrieving malicious commands and scripts from attacker-controlled servers to further propagate attacks. The first campaign using TookPS was discovered in March 2025. At that time, malicious scripts delivered a Python‑based infostealer along with a script that installed and configured an SSH tunnel on the victim’s machine. The next wave appeared in April 2025: the payload was changed, and TookPS was used to deliver the TeviRAT malware with the same SSH installer.

Then at the end of April 2025, TookPS underwent minor changes, yet its attack chain was completely redesigned. Unlike previous incidents, in this case, TookPS was used solely for the initial infection, with an automated SSH bot responsible for payload delivery. This new malicious campaign has multiple stages that cover the full attack lifecycle, from initial infection to persistence and data exfiltration. Among various malware strains, at one of the stages, the TeviRAT backdoor is delivered to the compromised host, ultimately fetching another version of a TookPS script.

We dubbed this updated TookPS campaign “OkoBot”.

Original OkoBot infection chain

We will break down this chain in greater detail later in the article. However, this is not the only version of OkoBot we were able to find. Already in March 2026, we discovered a new phase in the development of the framework, with Volume2 now being installed directly using TookPS. The HDUtil launcher → extl injector → Rilide chain was found to be abandoned in this newer version since it was replaced in full by the identical ext_daemon Volume2 plugin. TeviRAT was also removed, most likely because its functions were covered by the new plugins dispatcher.

New OkoBot infection chain

Initial infection

The initial infection is primarily delivered through two vectors: a ClickFix attack, and malware distributed through GitHub that masquerades as legitimate software. One such example is the fake SQL Server Management Studio (SSMS) package distributed through GitHub. In fact, it is actually the legitimate Audacity — a popular audio editor — compiled with a malicious implant embedded in one of its libraries. Because the repository was indexed by most search engines and appeared at the top of the results for the query SSMS, the malware looked legitimate and quickly earned users’ trust.

Malicious application distribution report

This repository was created at the end of March 2025 and existed until June of that year. It consisted of a single file, README.md, which provided a fake SSMS installation guide written in an official style and likely derived from excerpts of Microsoft’s documentation. However, the download link for the program, located at the beginning of the guide, pointed to the latest release in the same repository.

Both infection vectors trigger the execution of the malicious script TookPS, which installs SSH on the victim’s system, establishes a connection to the attacker-controlled SSH server and subsequently forwards the SSH daemon port. Following a delay, an automated SSH bot connects to the forwarded port.

Back connection

The automated SSH bot collects system information such as usernames, antivirus software installed, the IP address, and OS version. It harvests cryptocurrency wallet files, browser cookies, profiles, and other credentials through an SSH tunnel. For subsequent delivery of malicious modules, it disables Windows Defender notifications via a registry modification. Moreover, it gains access to the graphical session on the victim’s system using the following sequence:

1. Open firewall ports for inbound RDP traffic
2. Create a user in the “Remote Desktop Users” group
3. Replace the legitimate termsrv.dll with a patched one to permit multiple concurrent RDP sessions
4. Create a scheduled task named Apple Sync to maintain a reverse SSH tunnel that forwards the local RDP port every hour

After that, the SSH bot begins retrieving malicious modules over SFTP.

Launcher with advanced options

One of the deployed modules is HDUtil, an auxiliary utility protected with VMProtect and heavily obfuscated. This launcher is used by the SSH bot during an attack to deploy various malicious modules via the target command. Additionally, it implements three auxiliary commands that were not observed during the attacks we analyzed. Nevertheless, their presence and potential capabilities further demonstrate the high degree of integration among all components of the framework.

Active sessions

At startup, the launcher verifies its execution environment by checking the HWID in the contents of %PROGRAMDATA%\hwid.dat, a technique consistently employed throughout the framework. If the file is missing or contains invalid data, such as a non‑MD5 hash, the launcher terminates without performing any further actions. Otherwise, the specified commands are executed. For example, enumsessions provides a list of sessions along with detailed information, including the session type (Console, Services, RDP, and others), username, connection host, and domain. In turn, enumadapters returns the names of all graphics adapters present on the system.

Example output of HDUtil enumeration commands

UAC bypass

The most important command of the launcher is target, which enables payload execution on the system. An optional nouac argument enables automatic UAC bypassing via Windows RPC and an auto-elevated msconfig.exe program, allowing the payload to run with elevated privileges stealthily. This technique has been known for a long time, discovered and described in 2019 by the Project Zero team, who provided a full report with a detailed technical description.

Below is the list of all HDUtil commands.

Browser extensions loader

The first malicious module delivered to the infected system via SFTP is executed using the previously described launcher with the command .\HDUtil.exe target extl.exe. It is a heavily obfuscated DLL injector protected with VMProtect. At startup, the module enters an infinite loop and uses the EnumWindows and IsWindowVisible API methods to enumerate the PIDs of active windows and retrieve the corresponding executable filenames. For processes associated with widely used Chromium‑based browsers, the module invokes a routine that injects a specialized implant.

The injector opens a process, allocates a memory region, and writes the payload directly into this region as unencrypted raw bytes. Then it resolves two exported implant functions, LdrInitMain and LdrCallMain, based on a pre-specified hash derived from a modified version of DJB2 hash function. The first function performs the final PE unpacking, including rebase operations and the initialization of the import and exception tables. The second function directly initiates malware execution.

Setting up protections on the regions and launching the implant

This loader installs malicious browser extensions and hides them from the user. It uses an internal engine that resolves the addresses of stripped functions by analyzing the byte patterns of their calls using YARA-style syntax. This approach enables the malicious code to access critical Chromium engine functions required for extension installation and management. This functionality is also implemented for other browsers with appropriate modifications. For example, in the case of Microsoft Edge, the corresponding DLL msedge.dll is hooked using the specific patterns.

List of the functions hooked by the malware

Using the obtained address of the BrowserProcess object, the loader traverses the inheritance hierarchy and subsequently resolves a pointer to the function responsible for registering observers of browser‑window creation, specifically ProfileManager::BrowserListObserver::OnBrowserAdded. With a specialized built‑in engine, they are hooked using the attacker’s own implementations while preserving the original function’s address.

The loader replaces the functions it finds with its own

When a new Chromium window is opened, a hooked function is invoked that silently installs extensions. This routine scans the user’s %APPDATA% directory, loads all .crx files (Chromium-based browsers extension format), and records them in the ext_table. The extensions are then installed in the browser.

During installation, the extension is unpacked into a non‑default extensions directory, Local Extension Settings, and its manifest is dynamically modified. An object named custom_args is added, containing the fields hwid (the identifier of the infected system) and browser (the name of the browser in which the extension is installed). Then, using previously resolved internal functions of chrome.dll, the extension is installed and all requested permissions are granted.

Extensions are unpacked into a non-default directory

All extensions loaded in this manner are added to a special array to be subsequently identified among regular extensions and to remain hidden from the user.

The remaining patched functions are used to hide the installed malicious extensions from the user. When invoked with registered extensions as parameters, they perform no operation and return a constant value. This enables the threat actor to suppress notifications related to the malicious nature of the extensions and to exclude them from the displayed list of installed extensions. As a result, the behavior of other extensions remains unaffected.

Stub for hiding malicious extensions

During the attack, the Rilide extension was installed on the victim’s system using the previously described loader. Rilide is a stealer targeting Chromium-based browsers that has been frequently used by Russian-speaking threat actors since April 2023. The malware is designed to steal sensitive user data, including login credentials, cookies, and financial information, with a specific emphasis on cryptocurrency theft.

Plugins dispatcher

The final module delivered via SFTP is an open-source utility called Volume2, which is executed with elevated privileges using the command .\HDUtil.exe target nouac noattach Volume2.exe. The executable was linked with the malicious protobuf.dll library. Although the library seems identical to the legitimate DLL, it has been modified to include a malicious exported function, ProtobufGetVer2. This function decrypts and initiates a malicious implant. The payload is encrypted using AES GCM, initialized with a static 256‑bit key and a 96‑bit nonce. The GCM authentication tag is omitted, resulting in the absence of integrity verification. Starting in March 2026, the name of protobuf.dll was changed to version.dll, although its contents remained a modified ProtoBuf library.

Decrypting implant using AES GCM and subsequent mapping

The loaded implant functions as a malicious plugin dispatcher. Upon initialization, it reads and verifies the HWID before establishing communication with the C2 server via the HTTP protocol. Each request follows a predefined binary format: a 2-byte numeric bot identifier encoded in little-endian format, followed by an AES CBC-encrypted JSON object. By default, the BotID is set to 0, and the key and IV consist of 32 and 16 bytes of 0xff, respectively. The implant polls the server every 20 seconds to retrieve new commands. The request contains client data encoded in Base64, and the server may respond with a command containing three mandatory fields: TaskIndex (the command number from the dispatcher), TaskID (a unique task identifier), and HWID (the client identifier). The dispatcher supports four built-in commands:

Each plugin is required to export two functions: RegisterPlugin and PluginDispatch. These functions are used to manage and configure plugins. The RegisterPlugin function registers the plugin’s tasks with the dispatcher, whereas the PluginDispatch function is invoked when the plugin is called. Both these functions, as well as other external API functions, are located within the base libraries using one algorithm. This algorithm iterates through the export table and uses a specialized callback that calculates the MurmurHash3 hash and compares it against the target value to identify the appropriate function.

Resolving a plugin initialization function

During the analysis, we were able to discover five plugins that implement functions under their unique task identifiers.

• CMD wrapper (10xx): allows running scripts and individual commands in cmd.
• PowerShell wrapper (11xx): allows running scripts and individual commands in PowerShell.
• Environment enumerator (12xx): gathers system information, active sessions, and processes.
• Dropper (14xx): downloads an additional payload directly onto the system both from embedded Base64-encoded binary blob and via URL.
• Process injector (16xx): launches additional malicious implants on the target system by injecting them into legitimate processes.

We identified four malicious implants that are delivered to the system via the process injector plugin.

ext daemon

The malware is functionally identical to the browser extensions loader (extl.exe) described above, but less obfuscated and not protected with VMProtect.

SeedHunter

Similarly to extl.exe, this malware monitors the list of active processes in the system and injects an implant into Trezor Suite, Ledger Wallet, and Ledger Live processes. The implant is malware that collects seed phrases of Ledger and Trezor cryptocurrency wallets. Initially, it verifies the HWID, and if it fails, it terminates immediately. Then, based on the value of BaseDllName, the malware determines the process context and uses the corresponding implementation for either Trezor or Ledger. It then utilizes the previously described technique to hook the internal Electron framework functions.

List of functions hooked by the malware

Then the malware communicates with the C2 (moonsand[.]store) over HTTPS, sending a Base64-encoded JSON request containing the fields Pid, HWID, and Build. In response, it receives a JSON payload containing the Wait flag. If this flag is set to true, the malware initiates periodic USB device scans filtered by VID and PID (Vendor and Product ID). Upon detecting a connected Trezor or Ledger hardware wallet, it invokes the hooked functions to display a hard‑coded phishing page designed for seed phrase recovery, with a distinct layout used for each identified wallet. If the Wait flag is set to false, the phishing page is displayed immediately.

When the seed phrase is entered and validated, the JavaScript code of the page outputs the phrase to the console prefixed with @:app:print. This prefix helps identify the malware messages in the hooked function mal_LogConsoleMessage.

Phishing pages for seed phrase recovery

The obtained seed phrase is subsequently sent to the C2 server within a JSON payload containing fields such as App (ledger or trezor), Build, DeviceName, DeviceHardwareId, and SeedData. Furthermore, an identical JSON, encrypted with the RC4 algorithm using the HWID as the key, is saved in a temporary directory under the filename sh_<ts>.json, where <ts> is the file creation timestamp.

MC Keylogger

This module is a keylogger that, in addition to recording user input, performs three malicious activities:

1. Clipboard logging: periodically checks various clipboard formats, including CF_HDROP for files dragged between windows, CF_DIB for copied bitmap images, and CF_UNICODETEXT for Unicode text. Each format is handled appropriately, and all copy events are logged under the Clipboard section. Text data is written directly to the log, while copied files are recorded by their file paths. Images are saved as JPG files following the naming pattern bf_YYYY-MM-DD hh_mm_ss.jpg, and the path to the saved image is added to the log.
2. Logging connected devices: logs information about USB devices connected to the system, including hardware characteristics like VID, PID, manufacturer, and other details.
3. Screenshot creation: creates a screenshot every five minutes with a name in the format sc_YYYY-MM-DD hh_mm_ss.jpg. A corresponding message is recorded in the log under the Screenshot section, including the path to the screenshot.

Thus, the keylogger creates three types of different file artifacts, which are placed in a temporary directory. Below is an example of a log file generated by the keylogger.

Example of the keylogger log file

OkoSpyware

This module, which we dubbed OkoSpyware, captures both keystrokes and the video stream of the target application’s window. It first compiles a list of over 100 executable names, including cryptocurrency wallet applications (such as Exodus or Litecoin QT), password managers (such as KeePassXC or 1Password), and other widely used applications, to identify which processes should be monitored among all active system processes. For each identified process, the module uses a bundled FFmpeg instance to capture an MP4 video of the window while concurrently logging keystrokes within that window. The resulting video file is saved in %TEMP% as media_<ts> (where <ts> is the recording’s start timestamp). In the same folder, a JSON file named oko_<ts>.json is created, containing metadata about the captured stream, such as the process name, intercepted input, the stream’s MD5 hash, and additional details.

Example of an OkoSpyware metadata file

The malware also monitors the state of browsers, and when the window title matches a specified regular expression — for instance, a MetaMask or Tonkeeper wallet extension page — it performs video recording and input logging, adding the window title value to the corresponding field in the JSON metadata file.

Artifacts exfiltration

The TookPS script launched via a scheduled task receives a PowerShell exfiltration script as its payload from the C2. All files created by the MC Keylogger and OkoSpyware are sent to the C2 server to the endpoint ir-post.php. After that, the files are deleted from the victim’s system and a command history file, ConsoleHost_history.txt, is cleared.

Sequential exfiltration of artifacts from the temporary directory

Victims

At the time of writing, we have detected hundreds of victims of the OkoBot campaign in more than 25 countries, with the largest proportion of attacked end users found in Brazil, Vietnam, Canada, Mexico, and Türkiye.

Distribution of users attacked by OkoBot by country, April 2025–June 2026 (download)

Attribution

At the time of writing, we can’t attribute this malicious campaign to any known crimeware actor. However, during the analysis, we observed that the servers hosting the PowerShell scripts used in the initial infection stage implement server-side geoblocking. When attempting to retrieve the malicious script using an IP from Russia or CIS countries, the server returns an empty response. This technique is very popular among Russian-speaking threat actors.

It was previously mentioned that the campaign uses the malicious Rilide extension, an infostealer that is actively spreading on Russian-speaking, invitation-only cybercrime forums. Additionally, the source code of the SeedHunter phishing pages includes comments in Russian.

Conclusion

The framework described here has numerous modules — mostly written in C and C++ — that are obfuscated and use a variety of packing techniques. Across all stages, specific patterns and techniques can be identified that are borrowed and used in other modules, which allows us to conclude that there is a close interconnectedness among all stages, forming a full‑fledged high‑level framework. Overall, these modules enable a wide range of functions, such as collecting local files, executing remote commands, downloading arbitrary browser extensions, and stealing crypto wallets.

The OkoBot campaign has been ongoing for over a year, and it remains active at the time of publication. Moreover, it is adapting, which indicates that this framework is being maintained and distribution campaigns continue.

Indicators of compromise

Additional information about this threat, with a comprehensive IoC list and decryption scripts, is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

Dispatcher

B07D451EE65A1580F20A784C8F0E7A46 # protobuf.dll
187A1F68AE786E53D3831166DC84E6D2 # protobuf.dll
D84E8DC509308523E0209D3CD3544619 # protobuf.dll
83E6B8FCB92A0B13E109301F8FF649CF # version.dll

Plugins

7306885BB4C98F2A9F056104CF092BC9 # PowerShell wrapper
B4C2E16CDB513BE4DC798F88E2527334 # CMD wrapper
2157D2429124AD28DB7A26F2477CB985 # Environment enumerator
77CECF5E2A622AE07D8AE9913457AB57 # Dropper
E0C3BC27A65750E740C4F1719E531C7D # Process injector

Injector payloads

3D2B43F91F65BFBF36A9C71B6B418876 # ext_daemon.exe
70FEF9FD6E351F4D53CFEEE8DCDFCD99 # seedhunter_x64.exe
ACD31C9941B6C1CABD4E45E6877B9038 # keylog_x64.dll
DD52F5108A176C62AD807C327734AD12 # oko.dll

SSH bot utilities

AC93A821617AEA1F56D4BC0BEF4AF327 # HDUtil.exe
11DBC8A2BEA04B15F8F68F3F01E8FAF9 # extl.exe

File paths

%USERPROFILE%\.ssh\go.bat
%PROGRAMDATA%\HDVideo\HDUtil.exe
%PROGRAMDATA%\hwid.dat
%PROGRAMDATA%\oko_ver
%TEMP%\extl.exe
%APPDATA%\hwid.dat

Domains and IPs

2baserec2[.]guru          # TookPS
recavb22[.]online         # TookPS
kbeautyreviews[.]com      # TookPS
coffeesaloon[.]online     # TookPS
104.243.43[.]16           # SSH bot
104.243.32[.]213          # SSH bot
62.210.188[.]209          # SSH bot
livewallpapers[.]online    # Volume2 C2
thatwascringe[.]com        # Volume2 C2
moonsand[.]store          # SeedHunter C2