cPGuard supply chain attack: an update channel compromise pushed a backdoor in versions 5.88.12-5.88.19. Update to 5.88.25 and rotate credentials.

Related Posts:

• Ubuntu Kernel Fixes for CVE-2026-98432 (CVSS 9.8) Land in Proposed Pocket
• TeamViewer Client Vulnerability Enables Remote Code Execution
• 7 Unpatched phpMyAdmin Vulnerabilities Exposed

The post cPGuard Supply Chain Attack Pushes Backdoor Through Update Channel appeared first on Daily CyberSecurity.

Google dismantled a 1.3 million-device botnet allegedly built by Android TV box maker Videostrong to enable ad fraud and proxy abuse.

Google and its partners dismantled a backdoor called XCPE that had enrolled more than 1.3 million set-top boxes in a botnet. The result of the investigation into the malware operation is the striking part: Videostrong Technology Co., an Android device maker, built and ran the botnet for money.

Google says it is highly confident that Videostrong deliberately created, spread and operated the backdoor. The company reportedly sold access to criminal groups and installed their malware on infected devices. The malware was used for ad fraud, secretly added devices to residential proxy networks and installed other malicious software.

Google says this was not the work of a rogue employee or a simple coding mistake. The backdoor was found in many device models and brands over several years. Its operation involved dedicated infrastructure and regularly changing configurations.

“We assess with high confidence that the backdoor and botnet were intentionally developed, deployed, and operated for financial gain by Videostrong Technology Co., an Android Original Equipment Manufacturer (OEM) and Original Design Manufacturer (ODM).” Google states. “Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices. “

Google has now cut all ties with Videostrong. The company is banned from making devices with pre-installed Google apps. The ban also covers any future subsidiaries or business partners, and Videostrong can no longer supply software to other certified device makers.

Videostrong got around Google’s compatibility and security tests with code obfuscation. The malicious code loaded after a device’s first boot, which the tests didn’t catch. Google has changed its review process and is improving how it checks firmware on certified Android TV devices.

Google also took legal action against the domains and servers Videostrong used to control the botnet, and against the control domains of over a dozen malware families loaded through the backdoor. Those affiliates spread their modules through other channels too, so Google expects the takedown to cut access to at least 10 million more compromised devices. Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI worked on the operation.

The malware has three stages. The primary backdoor, x.cpe (called com.oemservice in some builds), is preloaded in the firmware and runs with system privileges. If a user uninstalls it, it reinstalls itself from the /oem/ partition at the next reboot. It handles communication with the control server and passes work to a loader called com.abc.nexus, which carries its own anti-analysis tricks and sets up the money-making modules.

These modules are supplied by other criminals working as affiliates. They can arrive as programs built into the backdoor, software packages added to its loader, or extra apps downloaded later. Many turn the device into a residential proxy, allowing other people to use the victim’s home internet connection to hide their online activity. Others commit ad fraud or install additional backdoors. In other words, a set-top box becomes a proxy server without its owner’s knowledge.

The backdoor uses two steps to control infected devices. First, the box sends an HTTP request to download settings, location data and network information. It then maintains a live connection through MQTT, a lightweight messaging protocol, to receive commands from the operators. Google found that all analyzed samples used the same MQTT server to communicate with infected devices.

“Additional monetization modules as well as various shell scripts and legitimate applications are hosted remotely and downloaded by infected devices upon command from the operator via the MQTT broker.” continues the report. “A significant majority of these files are hosted as Github releases on operator-owned Github pages. Other files are hosted on operator-controlled servers and file hosting sites.”

Through this connection, attackers could secretly install apps, run commands and scripts, take screenshots, record keystrokes and map the victim’s network. They could also disable Google Play Protect’s app verification to install software without the user’s knowledge. Google observed operators taking screenshots, recording keystrokes, collecting account and device information, stealing app lists and system logs, and opening remote command-line sessions. However, most of their activity involved installing, removing and managing malware modules.

The malicious files came from several sources. The attackers mainly used GitHub releases hosted on their own accounts, the Filemail file-sharing service and two servers under their control. Network traffic analysis also suggests that the operators managed the command infrastructure through remote interfaces and an EMQX web console, connecting from IP addresses outside the infected device network.

Most infected devices are Android TV set-top boxes, but Google also found telehealth devices, karaoke machines and digital signage. One device can run several modules at once, up to three residential proxy kits. That shows Videostrong wants to squeeze every infected device as hard as it can. The proxy and bandwidth-sharing kits named in the report include Linkfog, AppSalt, GaGaNode, BWM, Traffmonetizer, EarnFM and NetNut.

Some of those kits enroll devices without asking. AppSalt’s SDK, owned by Honeygain, calls an opt-in function without showing any consent screen, and it stops running if the app came from the official Google Play Store. Ad-fraud modules such as Fission and HiddenView fire off fake ad impressions in the background, and HiddenView also uses hidden browser windows to simulate clicks and scrolling.

The configuration shows a well-run operation. MQTT messages carry resource limits for each module, download links per processor type, and priority weights. Devices are assigned to one of six timezone-based pools on ott.szbboys[.]com. Devices report their bandwidth use and alarms back, so the modules stay within set limits.

Google says the underlying market is resilient. Backdoor operators, ad-fraud rings and residential proxy providers work as an interconnected supply chain, and when one part gets disrupted they quickly switch to new loaders or rival kits. Lasting change, it says, needs accountability across hardware makers, the residential proxy industry and the broader technology sector.

Google wants retailers and distributors to require independent security audits from device manufacturers and to delist any implicated in supply-chain abuse. It says proxy providers’ claims of ethical sourcing need transparent, auditable proof of user consent, and that in its analysis these providers asked for consent only when platform policy forced them to. Silent opt-in remains the most common way devices become exit nodes.

For consumers, Google advises caution with apps that pay you for “unused bandwidth” or “sharing your internet”, which are a main way illicit proxy networks grow. Stick to app stores you trust, review permissions for third-party VPNs and proxies, and keep Google Play Protect on. Buy connected devices like set-top boxes only from reputable manufacturers, and check the partner list on Google’s Android TV website. Google also urges mobile platforms, ISPs, online marketplaces and other tech platforms to keep sharing intelligence.

“A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust. By turning everyday hardware into persistent beachheads for criminal affiliates, Videostrong prioritized illicit post-sale recurring revenue over the safety and privacy of its users.” concludes the report. “Downstream hardware brands, white-label resellers, telecommunications providers, and online e-commerce marketplaces also share responsibility for closing this vector.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

Cursor removed a malicious Claude Code extension backdoor. Learn how the Cursor Claude Code extension backdoor planted SSH keys on up to 5,000 developer PCs.

Related Posts:

• INJ3CTOR3 FreePBX Malware Steals 17 Configuration Files for Off-Box Toll Fraud
• CyberDakait Deploys Seven Android Trojan Families Against 17,960 Indian Banking Devices
• Qilin Ransomware Targets VMware ESXi Servers and Healthcare Networks After Claiming 900 Victims in 2026

The post Malicious Claude Code Extension Injects SSH Backdoor in Cursor Marketplace appeared first on Daily CyberSecurity.

Trellix uncovers the Sirius Backdoor in fake FedEx tax invoices. See how the fileless Sirius Backdoor blinds EDRs and survives Windows OS resets.

Related Posts:

• Yoba Malware Campaign Sideloads Payloads Through Signed OpenAI and Anthropic Binaries
• Fake Phantom, Jupiter, and Bitget Firefox Extensions Steal Crypto Recovery Phrases
• Brazilian Magecart Group Hits Convertr Ecommerce Platform in Plausible Analytics Supply Chain Attack

The post Fake FedEx Tax Invoice PDFs Deliver Fileless Sirius Backdoor to Windows Systems appeared first on Daily CyberSecurity.

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.

APT28 used the Hookedge backdoor, SSH tunnels, and a new loader to spy on a naval shipbuilder and defense firms in two NATO countries.

Related Posts:

• APT41 Deploys BlackX UEFI Bootkit Against Central Asian Diplomatic Agencies
• China-Linked Operator Used AI Agents to Breach 48 Government and Corporate Targets Across Asia
• Lazarus Operation FlashHole Abuses CrossWeb EX and GitHub to Spy on South Korean Firms

The post APT28 Uses Hookedge Backdoor to Spy on Naval Shipbuilder and Defense Firms in Two NATO Countries appeared first on Daily CyberSecurity.

Attackers infected 333 Tor exit nodes with Ebury malware to hijack SSH logins and steal passwords. See how a researcher exposed them.

Related Posts:

• Aoki Infostealer Harvests API Keys and Tokens From AI Coding Assistants
• CL-UNK-1211 Deploys SysGoRAT Malware and AI Scripts Against Government Linux Servers
• Qilin, Inc and Settra Ransomware Gangs Exploit PAN-OS Flaw CVE-2026-0257 for VPN Access

The post 333 Tor Exit Nodes Hijacked by Ebury Malware for SSH Attacks appeared first on Daily CyberSecurity.

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.

Operation FlashHole attack flow during initial compromise

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.

Appearance of the malicious websites

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.

Suspected use of an AI-generated image on the résumé site

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.

Initial infection chain

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.

Expanded infection chain after gaining persistence

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.

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’s communication sequence

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.

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.

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.

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

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.

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.

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.

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.

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

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.

Timeline of LPEClient

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.

Data relay flow between LPEClient and C2 via ClientHub

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.

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.

Data leakage site linked to the COPPERHEDGE backdoor on the dark web

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.

Overlaps between the recent attacks by Lazarus Group

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

An active WordPress XSS campaign exploits Ninja Forms flaw CVE-2026-94504 and CVE-2026-93836 to plant hidden admin accounts. Patch now.

Related Posts:

• Apache DolphinScheduler 3.4.3 Fixes Six Authorization Flaws That Leak Passwords and Kubernetes Credentials
• wolfSSH 1.6.0 Fixes Five Flaws, Including Critical Host Key Bypass CVE-2026-16516
• Cisco Finesse SSRF Flaw CVE-2026-20362 Publicly Disclosed, With Fixes Not Due Until 2027

The post Hackers Exploit Ninja Forms and WPC Product Bundles XSS Flaws to Plant Hidden WordPress Admins appeared first on Daily CyberSecurity.

The ClingSTUN backdoor hijacks unpatched IoT devices and hides in traffic to public STUN servers. Learn how it spreads and how to stop it.

Related Posts:

• Four Attacker Clusters Exploit Citrix NetScaler Flaw CVE-2026-88771 to Plant Web Shells
• Moroccan Intelligence Deploys Vast Surveillance Panopticon
• DragonForce Backdoor Adds MQTT Fallback to Microsoft Teams TURN Command Channel

The post ClingSTUN Linux Backdoor Turns Unpatched IoT Devices Into Proxy Nodes appeared first on Daily CyberSecurity.

Fortinet details ClingSTUN, a Linux backdoor exploiting unpatched IoT devices and abusing public STUN servers to route traffic past NAT.

FortiGuard Labs researchers spotted a Linux malware family they call ClingSTUN, and the name gives away its trick immediately. Instead of relying on a dedicated command server, the malicious code leans on STUN, the protocol that helps devices behind a router figure out their real public IP address. Video calling apps use it constantly, which means ClingSTUN’s network traffic hides inside something that already looks completely normal.

“ClingSTUN functions as a back-connect proxy backdoor, turning infected systems into remotely controlled proxy nodes. It abuses public STUN (Session Traversal Utilities for NAT) infrastructure to discover externally mapped IP addresses and ports, maintain NAT bindings, and improve connectivity between compromised hosts and remote operators.” reads the report published by Fortinet. “Because many of the STUN servers it contacts are legitimate public services, the resulting traffic easily blends with normal VoIP and WebRTC communications.”

The attack starts with a familiar problem: old, unpatched devices exposed to the internet. Fortinet first spotted the campaign exploiting a known command injection flaw in Hytec Inter routers. As the campaign evolved, the attackers changed their download infrastructure and expanded the list of vulnerabilities they were exploiting.

In the latest wave, they were targeting devices from more than a dozen vendors, including D-Link, TP-Link, Realtek and Linksys, as well as several DVR and IoT cloud platforms. Many of these devices are easy targets because they are rarely updated or closely monitored.

Once the attackers find a vulnerable device, a small downloader script installs the right malware version for its hardware. It supports common architectures such as ARM, MIPS, PowerPC and Intel.

The latest version also checks the device for other malware before installing itself. It scans mounted filesystems and kills suspicious processes running from temporary directories. In other words, ClingSTUN is not just trying to infect the device. It also tries to remove competing malware and take full control.

The persistence mechanism is almost old-fashioned in its simplicity. The malware copies itself into two separate locations, then appends itself to three different boot scripts so it survives a reboot no matter which startup path the device actually uses. It also walks through every running process, checks whether the command line matches what the process claims to be, and kills anything that doesn’t line up, which is both a defense mechanism and a fairly blunt way of eliminating rival malware fighting for the same compromised box.

Two details stand out as genuinely well thought through rather than copy-pasted from some other botnet’s source code. First, it opens the device’s watchdog timer and quietly disables it, so the device never auto-reboots itself out of the infection the way embedded hardware is designed to if something goes wrong. Second, once it’s running as root, it swaps its own process metadata for a copy of PID 1’s, the very first process the kernel starts, which makes a basic process listing show what looks like the init system instead of malware.

“After setting up persistence, ClingSTUN clears its original command-line arguments so that its command line appears empty in tools such as “ps.” It then checks whether it is running as root (UID 0).” reads the report. “If so, it copies selected process information files from “/proc/1/” to “/tmp” and bind-mounts “/tmp” over its own “/proc/” directory, concealing its process information behind metadata copied from PID 1.”

The STUN part is especially interesting because it helps ClingSTUN hide in normal network traffic. The malware sends standard requests to public STUN servers to find out its external IP address and port. These are the same services commonly used by VoIP and WebRTC applications.

Later versions reduced the number of STUN servers and required all connections to work, which suggests the attackers were improving reliability. Because the traffic goes to legitimate third-party services, it can be difficult for defenders to tell the difference between ClingSTUN activity and normal traffic from apps such as Zoom.

Command delivery itself still needs a human on the other end willing to send a 20-byte packet the right way.

“ClingSTUN establishes a UDP socket, binds to a random local port, and sends standard 20-byte STUN binding requests. It sends these to 24 public endpoints and ensures at least half succeed.” Fortinet states. “The third evolution reduced this to 13 endpoints and ensures every endpoint connection succeeds.”

A single control datagram can trigger ClingSTUN to open a fresh outbound TCP connection to an address the operator specifies, pull down a command over that connection, and execute it, which keeps the heavy lifting off the STUN channel and limits what shows up in any one place. The malware also carries hardcoded exploits for seven more vulnerabilities purely for spreading itself further, meaning every infected device doubles as a scanner looking for its next host.

Fortinet stresses that the STUN servers are not compromised or malicious. They are simply working as intended. These third-party services should not automatically be treated as attacker-controlled infrastructure.

“ClingSTUN’s exploitation of known, unpatched vulnerabilities reinforces the importance of consistent cyber hygiene.” concludes the report. “Organizations should inventory Internet-facing devices, track their firmware and support status, and promptly apply available security updates, prioritizing vulnerabilities known to be actively exploited.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, ClingSTUN)

A new DragonForce backdoor hides in Microsoft Teams TURN relays and falls back to MQTT. See how it works and how defenders can spot it.

Related Posts:

• Moroccan Intelligence Deploys Vast Surveillance Panopticon
• New 2CLoader Malware Delivers Vidar and Remus Infostealers While Dodging Sandboxes
• BPFDoor Backdoor and New AVERAT Implant Hide in SMTP Traffic on Telecom Edge Devices

The post DragonForce Backdoor Adds MQTT Fallback to Microsoft Teams TURN Command Channel appeared first on Daily CyberSecurity.

Jamf Threat Labs details CloudSyncD, a fake macOS Zoom installer that hides a phished password using invisible zero-width Unicode characters.

Jamf Threat Labs found CloudSyncD while doing routine scanning on VirusTotal, buried inside a disguised Zoom client. They first spotted it on September 15, clearly still under construction, and within two days watched it move from a private test address to live command-and-control infrastructure on real domains. That’s a fast turnaround for something that started as an obviously unfinished build.

The delivery method is a classic macOS trick, made to look like a normal installer. The disk image opens as a volume called Zoom, with an app icon and an Applications shortcut. The background image then guides the victim step by step on how to bypass Gatekeeper, because the app is only ad-hoc signed and macOS would normally block it.

After the app starts, a fake dialog asks for the user’s password, claiming it is needed to continue the installation. The prompt keeps appearing until the password is correct.

“Once a password is entered, the dropper validates it against the local account using dscl and does not continue until the check succeeds.” reads the analysis published by Jamf Threat Labs. “After the password has been validated a fake progress window reading Downloading Zoom... appears.”

The captured password doesn’t get sent anywhere immediately. It gets base64 encoded, padded with a random amount of filler text, and buried inside a field that looks like an innocent cache value in a fake settings file named data.json. Nothing about that file screams malicious on a casual read, since it’s formatted to look exactly like ordinary application preferences with a theme and a language setting.

The trick used to find the hidden password is also where the file gets its name. After the visible version number, 1.0.0, there are 48 invisible Unicode characters. They are zero-width spaces and zero-width non-joiners, so they cannot be seen in normal text. When decoded, they tell the malware where the real password starts and how long it is inside the padded text. The amount of filler changes each time, so the password is hidden in a different position on every run, while the technique stays the same.

The malware does not download the payload separately. The full payload is already inside the dropper as a universal Mach-O file. It first tries to run the payload directly from memory through an anonymous file descriptor, avoiding writing it to disk. On most Macs, however, System Integrity Protection blocks this method. Jamf also saw the attempt fail during testing and recorded the exact error. When the fileless method fails, the malware writes the payload to a temporary file and runs it with sudo, using the password it just stole to get the privileges it needs.

“The dropper does not download its payload. It carries a complete universal Mach-O inside itself, roughly 756 KB in the development build, and extracts it at runtime. The same payload is also present on disk inside the application bundle, so the dropper has two sources for it. The dropper first writes the payload to an anonymous file descriptor and attempts to execute it through /dev/fd, presumably to avoid writing the Mach-O to disk.” continues the analysis. “In our testing this failed, with the dropper logging /dev/fd spawn failed rc=13. This technique will fail on the majority of macOS systems due to System Integrity Protection. Upon failure, it uses mkstemp to write the file temporarily to disk, then executes it using sudo along with the collected user’s password.”

A cleanup script follows, assembled at runtime from scattered obfuscated fragments and designed to swap in a replacement app bundle before deleting itself either way. In the builds Jamf actually recovered, though, the replacement bundle simply doesn’t exist, so this entire swap mechanism never fires. It’s a feature built and wired up for a payload that hadn’t shipped yet.

The second stage, which Jamf calls cloudsyncd after its disguised daemon name, is a fairly restrained implant once it’s actually running. It doesn’t set up persistence, doesn’t install a LaunchAgent, doesn’t rename itself to blend in the way its own configuration suggests it’s designed to. It just builds a working directory, logs its activity with encrypted records, and checks in with its server every 8 to 16 seconds carrying nothing but a hardware identifier.

The more interesting part is what happens after the malware checks in with its server. The server can send back either a compressed archive to unpack or a complete executable to run. So the backdoor is not limited to sending individual shell commands. It can deliver and run entire programs, which gives defenders a different clue to look for: a suspicious new file being created or executed rather than a series of strange terminal commands.

By the time Jamf published its research, the malware had moved beyond testing and was communicating with two live domains. Both were registered through the same registrar in 2011 and were protected by Cloudflare. At the time, neither domain was detected as malicious. All the samples also used the same encryption key and initialization vector. That means a single sample recovered by Jamf could potentially be used to decrypt the network traffic of other versions of the malware.

“CloudSyncD is a good reminder that although infostealers may dominate the threat landscape, attackers still have use for quieter malware that lies low until further access is needed.” concludes the report. “Its behaviors illustrate how macOS malware continues to move toward native implementations, string protection, and execution paths that attempt to avoid writing payloads to disk, while still depending on the oldest technique available: asking the user for their password.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)

Cisco Talos details UAT-11587, a China-linked group using the Antino backdoor and Microsoft 365 as cover to spy on Asian governments.

Cisco Talos has been tracking a cluster of espionage activity since September 2025 that it calls UAT-11587, and by July 2026 the group had hit at least 16 government and policy organizations across eight Asian countries. The toolset includes a previously undocumented backdoor Talos named Antino, and the thing that makes it worth paying attention to isn’t how it gets in. It’s where it hides once it’s there.

Antino is written in Rust and works on both 32-bit and 64-bit versions of Windows. It supports the usual backdoor features, including shell and PowerShell access, file transfers, in-memory shellcode execution and persistence.

“Antino is a Rust-compiled Windows backdoor that supports host reconnaissance, shell and PowerShell execution, file transfer, in-memory shellcode loading and persistence. Its native command-and-control channel operates exclusively through Microsoft 365, using Microsoft Graph to interact with Outlook and OneDrive.” reads the report published by Talos.

None of these features are particularly new. What makes Antino different is how it communicates: instead of using its own command-and-control server, it uses Microsoft Graph to read commands from an Outlook mailbox and send stolen files to OneDrive. This allows its traffic to blend in with normal Microsoft 365 activity.

The attack starts in a more traditional way, with a convincing phishing email. UAT-11587 created highly targeted documents that suggest the attackers had researched their victims, including a fake workshop document about Taiwan’s information warfare and a document that closely copied a real Taiwan Ministry of Finance ruling about tax treatment for legislators.

“The document exactly reproduces a public Taiwan Ministry of Finance ruling to make the decoy appear credible.” conctinues the report. “Its subject strongly suggests that it was prepared for members of Taiwan’s public sector.”

In another case, the attackers reused a real Associated Press story about alleged Russian offers to the US over Venezuela. Matching malware samples appeared on VirusTotal two days after the original article was published.

The delivery trick is a simple but effective email spoofing technique that takes advantage of a gap many people overlook. The attackers sent the email through a legitimate provider, using one domain as the technical sender, while the visible From address showed the organization they were impersonating. SPF passed because the real sending domain was authorized, but DMARC detected the mismatch and failed. That still wasn’t enough to block the message. The impersonated domain had a DMARC policy set to monitoring rather than rejection, so the failed email still reached the inbox.

The Gmail trick is even more interesting. The attackers recreated Gmail’s normal attachment preview card almost pixel by pixel using images embedded in the email’s HTML. They then made the fake preview a link to a page controlled by the attackers. Open the email in Gmail and it looks just like the real thing because Gmail simply renders the HTML it receives. There is no exploit here. It’s just a very convincing copy of something users already trust.

From that click, a five-stage chain kicks in, leaning on legitimate-looking HTA files, Windows Script Host, and a scripted .NET deserialization trick that abuses a known gadget chain to load malicious code inside a trusted process. The final stage sideloads Antino through a signed Microsoft diagnostic binary, meaning the thing dropping the backdoor onto disk is a tool Windows itself trusts by default. Cloudflare Pages, R2, and Amazon CloudFront carried almost every stage of this, which kept the traffic blending into ordinary HTTPS the whole way through.

Once Antino is running, it checks its Outlook mailbox for new commands every ten seconds. The commands and results are sent as structured JSON hidden inside specially formatted email subjects.

“The Antino backdoor receives commands through email messages. The implant actively pulls commands from the threat actor’s Outlook mailbox folder every 10 seconds. The protocol uses two message types: command emails contain tasking from the controller, while response emails contain the implant’s results.” states Talos. “Command messages are identified by the subject prefix command_req_[session_id] and responses by command_res_[session_id], as indicated in the HTTP GET request sent by Antino: “

A separate system is used to upload stolen files to one OneDrive folder and download attacker tools from another. Even the naming makes the attacker’s perspective clear: “uploads” are files sent to the victim, while “downloads” are files pulled back from the victim.

The attribution case leans on accumulated small details rather than any single smoking gun, which is honestly how these assessments should work. Decoy document metadata carries Simplified Chinese language tags and a UTC+8 timestamp, a combination more consistent with mainland China than Taiwan or Hong Kong, where Traditional Chinese dominates. Separately, ten different Antino builds reference a Rust package mirror built specifically to speed up dependency downloads inside mainland China, the kind of tooling choice a developer picks for convenience, not for disguise.

The victim list reads like a checklist of what an intelligence service would actually want: defense ministries, legislatures, foreign affairs offices, border and interior security agencies, plus the think tanks and civil society groups that tend to know things governments care about early. Around 350 compromised endpoints turned up across eight countries, with the largest single wave, roughly 57 new endpoints, hitting India over two days in June. That’s not noise. That’s a deliberate and sustained collection effort.

“Based on the development, preparation-environment, and targeting indicators detailed in this report, Talos assesses with high confidence that UAT-11587 is China-nexus.” the report concludes.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Antino backdoor)

UAT-11587 Antino backdoor attacks hit Asian targets. Cisco Talos reveals how the Antino backdoor abuses Microsoft 365 for cyberespionage.

Related Posts:

• PaperCut Zero-Day Attack Hides AdaptixC2 Implant Inside Fake Microsoft Copilot
• Microsoft Details NeedyMantis Malware Used for Long-Term Access in Targeted Intrusions
• New MacSync macOS Infostealer Targets Crypto Wallets

The post UAT-11587 Targets Asian Governments With Antino Backdoor appeared first on Daily CyberSecurity.