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)

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)

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)

North Korea-linked hackers hid a backdoor inside HAProxy, masking C2 traffic and stealing data while keeping the load balancer working normally.

North Korean-linked hackers found a genuinely clever hiding spot for their malware: inside the actual source code of HAProxy, the load balancing software running at the edge of two South Korean companies’ networks. Rapid7’s research documents a previously undocumented Linux toolkit hitting South Korea’s automotive and media sectors, and the depth of integration here goes well beyond a typical backdoor bolted onto a system.

“A new Linux toolkit, identified by Rapid7 Labs, has been targeting organizations across South Korea’s automotive and media industries with minimal detection. The campaign made use of a HAProxy instance named “ted backdoor”, alongside trojanized versions of crond, agetty, atd, sshd, and polkitd.” reads the report published by Rapid7. “This previously undocumented framework enabled threat actors to execute remote commands on compromised servers, inject malicious scripts into web traffic, perform credential harvesting, and engage in long-term surveillance.”

The implant, which Rapid7 calls the “ted backdoor” based on debug strings the attackers left behind, isn’t a separate process running alongside HAProxy. It’s compiled directly into HAProxy’s own source code as a custom plugin, using the software’s native filter API, internal memory management, and event scheduler to intercept HTTP traffic while completely legitimate load balancing keeps running normally on top of it.

“The standout feature of this toolkit is its depth of integration with the target environment. The ted backdoor is compiled as part of the victim’s existing HAProxy version 2.8.12.” continues the report. “It uses its native filter API, internal memory pools, event scheduler, and process management infrastructure to intercept traffic and hide from monitoring, while genuine load balancing traffic operates as expected.”

Rapid7 explains, which is really the whole thesis of why this backdoor is so hard to spot: it’s not an addition to the software, it’s woven into it.

The backdoor receives commands through a surprisingly simple trick. The attackers send a request for a fake image at /favorite_list_2x_m500_ico.jpg. This switches the HAProxy filter into command-and-control mode.

The malware then saves the command in a named pipe and removes traces of the request from HAProxy’s internal counters. It also clears the forwarding buffers, so the request never reaches the backend server. The command ends at the load balancer, leaving nothing in the application logs to show that it happened.

This ability to erase its own traces makes the backdoor very different from a normal web shell. The C2 requests never reach the backend server and are also removed from HAProxy’s statistics.

As a result, neither the application logs nor HAProxy’s connection logs show that the attack happened. A security team checking the logs could find nothing suspicious because the backdoor has already erased the evidence.

Beyond remote command execution, the backdoor can quietly inject malicious scripts or entirely swap out page content for specific victims matched by IP address, browser fingerprint, or even a hidden authentication credential smuggled inside the Accept-Language header, effectively turning a company’s own load balancer into a watering hole against its own visitors. It also hooks response bodies carefully enough to hide the size difference caused by injected content, stripping the header that would let a browser notice the byte-range mismatch. That’s a level of protocol-level care that suggests real HAProxy internals expertise, not a quick copy-paste job.

The main backdoor also comes with a separate toolkit that modifies common Linux system daemons such as crond, agetty, atd, and sshd. These programs continue to work normally but also carry malicious features.

One component acts as an SSH keylogger. It captures passwords that administrators enter in plain text and quietly records them. Another tool, called curlRAT, contacts a remote server every 12 hours by default, or every 30 seconds when the attacker enables its fast-poll mode.

curlRAT also checks whether the system runs inside a virtual machine. If it does not find the expected signs, it refuses to run. This behavior suggests the attackers designed the malware to avoid sandboxes and other analysis environments.

Attribution here sits at medium confidence, and Rapid7 is upfront about the limits of what the evidence actually shows. The targeting pattern, simple XOR-based encryption, a custom substitution cipher, and command-server infrastructure already linked to APT37 by other threat intelligence feeds all point toward North Korean state involvement, with some technical overlap also drawing comparisons to a concurrent Lazarus Group campaign against South Korean media sites.

“Further evidence is necessary to make a more definitive assessment. Moreover, the presence of ngx_* prefixed routines within the ted backdoor suggest code reused from an nginx backdoor. The ngx_* prefixed routines were observed during the latest Funnull campaign, where (similar to our case) a custom nginx filter was registered to hook HTTP traffic, and simple XOR encryption was applied to the configuration file.” Rapid7 states. “However, other than a similar naming convention, no significant code-level overlaps exist to support a stronger linkage.”

If your organization runs HAProxy, or really any edge component handling SSL termination and traffic routing, the practical lesson here is uncomfortable but simple: that software deserves the same scrutiny as your actual application servers, not less. The Hacker News confirmed in early September that the specific command domains used in this campaign have already gone dark, returning no DNS records at all, which is useful for reviewing historical logs but does nothing to stop whatever comes next from the same operators. Checking a load balancer’s own logs isn’t enough anymore when the backdoor’s entire design goal is making sure those logs never see it in the first place.

“ted backdoor and curlRAT were designed to persist during long-term espionage operations with the ability to steal cookie sessions, credentials, redirect selected users, conduct drive-by download attacks, and hide evidence of the tampered page to a specific range of IPs to evade detection.” concludes the report. “Defenders should treat any edge component managing user traffic, SSL, or runtime modules with the same strict security standards as their main application servers. Relying on the component’s own logs is not enough; securing these systems requires independent network correlation, memory behavioral analysis, and binary integrity checks.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, North Korea)

StyleSmuggler Magento zero-day is under active attack, letting unauthenticated attackers execute code and install backdoors on stores that may already be patched.

A new zero-day flaw, dubbed StyleSmuggler, in Magento and Adobe Commerce is under active attack, giving unauthenticated attackers a path to run code on vulnerable online stores. Sansec researchers say it affects current Magento Open Source releases, including 2.4.7, 2.4.8 and 2.4.9. According to the experts, exploitation began on September 4.

“Sansec discovered StyleSmuggler, an unpatched Magento and Adobe Commerce zero-day that gives unauthenticated attackers remote code execution. All current versions are affected, including 2.4.9.” reads the report published by Sansec. “Attacks started September 4th. Sansec is rolling out emergency mitigation.”

This is not a routine patch-cycle problem. Sansec reproduced the full attack chain on clean installations and observed a first victim running Magento 2.4.6-p15 with July and August 2026 patches already applied and a clean patch-status result. In plain terms, a store could be fully updated according to its normal process and still be exposed.

“StyleSmuggler injects malicious code into Magento’s template system.” states Sansec. “By using the styles properties, it can evade existing safeguards. It works in two stages:

1. Inject (poison) PHP code, for example by generating a failure report.
2. Let Magento execute the poisoned code via a failed payment email“

The attack is especially dangerous because it does not require a victim to open an attachment, click a link or even receive a successful email. Magento can execute the injected code while it renders its standard “Payment Transaction Failed Reminder” notification, and the chain can still work if email delivery itself fails.

That makes unusual spikes in failed-payment reminders a useful detection clue, although not conclusive proof of compromise. Legitimate payment failures happen. A sudden burst of them combined with strange system activity is a different conversation.

StyleSmuggler works by placing PHP code into Magento’s templating path and later causing the platform to evaluate it. The first stage creates or poisons a record, while the second stage turns a routine email-rendering process into remote code execution.

The attack reportedly uses GraphQL-related handling and the styles property to evade safeguards that would normally reject dangerous input. Sansec says moving sessions to Redis or a database does not stop the attack, because operators have already adapted their methods when one delivery route fails.

“Moving sessions to Redis or the database does not stop the attack. One merchant reported an attempt that failed against session storage and, eight seconds later, a second attempt that succeeded by using a file uploaded through Magento’s custom options instead.” continues the report. “Both came from the same operator.”

That detail matters because it shows an active operator, not a static proof-of-concept circulating online. Defenders should assume attackers are testing several paths, watching failures and changing tactics quickly.

Once the exploit succeeds, Sansec observed a lightweight Rust backdoor that connects to attacker-controlled infrastructure and waits for commands. At the time of the report, Sansec had not seen evidence that operators had yet used the implant for follow-on actions, but a backdoor that is installed and waiting is not an idle technical curiosity.

The malware initially hid behind a process name resembling [kworker/u:8:0], then appeared as fc-cache on September 6 and as chronyd on September 7.

These names are designed to blend into Linux environments, where administrators may expect to see kernel workers, font-cache utilities and Network Time Protocol daemons.

The fc-cache variant copies itself into a font-cache directory, writes a PID lock file and uses cron to restart twice an hour. The chronyd version can persist through cron as well, but Sansec also observed a build that relaunched itself without relying on a visible cron entry. An empty crontab is not proof that a host is clean.

The command channel is disguised as time synchronisation traffic. The implant sends 48-byte UDP packets to port 123, the standard NTP port, and uses domains that resemble time servers.

“Command and control is disguised as time sync. Every 60 seconds it resolves ntp.timesync.to and sends 48-byte UDP packets to port 123 that look like NTP server replies.” continues the report.

Only the first four bytes look like a normal NTP message; the remaining data can carry the agent ID, hostname, username, operating-system version, memory and disk use, uptime, root status and implant version.

That is a smart concealment choice. Many networks allow NTP traffic without close inspection because reliable time synchronisation is a normal operational requirement. Calling your malware chronyd and making it speak something that resembles NTP is not subtle genius. It is just clever enough to pass a lazy allowlist.

Sansec also found signs of a second, apparently unrelated attacker operating against stores compromised through StyleSmuggler. This actor deployed a compact PHP dropper that placed a web shell inside the product-image cache, using hash-like directory names to make the extra PHP file less obvious.

The web shell returns a normal-looking 404 response unless a request contains the correct X-Cache-Token header. With the header present, it can execute PHP supplied through a POST parameter. That design helps the attacker keep the shell invisible during casual checks and automated scans.

“Before writing that file, the dropper calls out to 457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site, a subdomain of a public service that developers and testers use to confirm that injected code ran.” states the report. “This actor came in through StyleSmuggler. We recovered the dropper from a Store: request header, and its PHP tags are still JSON-escaped from the record Magento logged it into.”

The lesson is not merely to remove the obvious background process. Stores need a full compromise assessment, including a review of PHP files under pub/media, cron spool files, unexpected processes, altered templates, report records, web-server logs and outbound connections.

Adobe was working on a patch as of September 7, according to Sansec, but no release date had been confirmed. A scheduled Adobe security release was due on September 8, although it was not known whether it would address StyleSmuggler.

Until an official fix is available and applied, merchants should consider temporarily disabling GraphQL if they do not have a compensating control capable of blocking this exploit. This can affect storefront and integration functions, so it should be treated as a risk decision rather than a casual configuration change.

Operators should also hunt for processes named [kworker/u:8:0], fc-cache and chronyd that run from unusual paths such as temporary directories, user cache directories or hidden folders. A legitimate chronyd process does not normally emit nine NTP server-mode packets in rapid succession every minute.

Security teams should inspect outbound traffic to suspicious NTP-like domains and UDP port 123 destinations, particularly 185.157.160.251, which Sansec linked to the observed domains on September 7. They should also search authentication and system logs for repeated crontab command not allowed messages generated by the web-service user, such as www-data.

If compromise indicators appear, treat the system as compromised, not merely vulnerable. Isolate the host, preserve logs and forensic evidence, rotate Magento administrator credentials, API tokens, database credentials, payment-provider secrets and cloud keys, then search for secondary backdoors before restoring normal operations.

The Sansec StyleSmuggler report includes current indicators of compromise, malware hashes, C2 infrastructure, suspicious process names and file paths. Its guidance will likely change as the campaign develops, because the attackers have already changed payload names and persistence methods within days.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, StyleSmuggler)