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)

Microsoft tracked over 30 MacSync Stealer domains by focusing on behavioral patterns, revealing a campaign targeting passwords, keys, wallets and other data.

Domain blocking is a losing game when the thing you’re blocking can register a new domain faster than you can add it to a list. That’s the exact problem Microsoft Defender Experts ran into while tracking MacSync Stealer, a macOS-focused information stealer that RST Cloud first flagged for swapping out its command-and-control infrastructure almost immediately after getting publicly outed. Microsoft detailed how its experts stopped chasing individual domains and started tracking the behaviors that stayed constant underneath them.

Instead of tracking individual domains, Microsoft looked at recurring request patterns, HTTP headers and other behaviors. This allowed its researchers to link more than 30 domains to the same campaign and determine that the infrastructure was doing more than just sending commands to infected Macs. It was also being used to collect, stage and exfiltrate stolen data.

“MacSync Stealer is a macOS-focused information stealer that relies on changing infrastructure to deliver payloads, communicate with compromised devices, and exfiltrate data. Earlier reporting by RST Cloud identified the threat through a limited set of domains and documented rapid command-and-control (C2) replacement after public disclosure.” reads the report published by Microsoft.

“Microsoft Defender Experts expanded that view by correlating recurring endpoints and network behaviors across the activity. This behavior-led approach connected more than 30 domains and showed that the infrastructure supported more than C2 communication, extending into active collection, staging, and exfiltration.”

The infection chain starts with a trick rather than an exploit. Victims get social-engineered through a technique known as ClickFix, tricked into pasting or running commands directly in macOS Terminal, and once that shell session fires, curl pulls down attacker-controlled payload content from a path formatted as /curl/[token].

Then, native macOS tools decode and unpack the payload, and an AppleScript-driven layer takes over, blending Unix commands like sh, cp, rm, and killall with osascript calls that make the whole chain look more like ordinary system scripting than malware.

Once active, the stealer focuses on valuable data. The malicious code looks for macOS Keychain data, saved browser passwords and cookies, SSH keys, AWS credentials, Kubernetes configurations and files in common user folders. It also searches for Ledger and Trezor wallet data, showing that the malware targets users with valuable credentials and assets rather than simply collecting random browser history.

What actually confirms exfiltration, rather than just suspicious traffic, is the upload mechanism itself. Collected data gets staged under temporary paths, compressed into an archive, split into chunks, and pushed out through HTTP PUT requests carrying parameters like upload_id, chunk_index, and total_chunks.

“The staged archive was uploaded through rotating infrastructure using curl and HTTP PUT requests. Observed requests included –data-binary, API-key headers, macOS User-Agent string, upload_id values, chunk_index values, and total_chunks parameters.” states Microsoft. “These upload traits confirmed active data exfiltration and provided durable hunting pivots even when domains rotated. “

The researchers pointed out that the exfiltration method stays recognizable even when the destination keeps changing.

RST Cloud’s follow-up work backs up how consistent this infrastructure actually is under the surface. Using the same recurring URI patterns, RST Cloud surfaced eleven additional candidate domains and found a static API-key value shared across four confirmed command-and-control domains, even while the build token attached to each deployment kept rotating. A shared static key sitting inside otherwise rotating infrastructure is exactly the kind of detail that makes automated evasion look less impressive up close.

The attack wraps up with cleanup, deleting temporary archives, staging folders, and lock files after the upload completes. Microsoft notes this reduces what’s left sitting on disk, but it doesn’t erase the behavioral sequence itself.

“After exfiltration, the malware removed temporary archives, staging folders, lock files, and other artifacts. Although this cleanup reduced on-disk evidence, the sequence of archive creation, chunked upload, and deletion can still provide a useful behavioral correlation for defenders.” concludes Microsoft.

For anyone defending Mac fleets, the practical takeaway here isn’t a list of domains to block, since that list will be stale within days. It’s building detection around the recurring shape of the attack itself: shell sessions spawning curl with those specific flag patterns, osascript chaining rapidly into network activity, and archives appearing under /tmp/sync* right before outbound PUT traffic starts. Chase the pattern, not the address, because the address was never going to sit still long enough to matter.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)

Evooo1Bot is a Mirai-based Linux botnet that hijacks routers and IoT devices for DDoS attacks, credential theft and criminal proxy services.

Fortinet’s FortiGuard Labs disclosed Evooo1Bot in mid-August, a previously undocumented Linux botnet that’s been active since July 2026. The bot borrows Mirai‘s DDoS engine but adds encrypted command-and-control communications, an SSH brute-force scanner, a credential sniffer, and a SOCKS5 proxy module on top.

“FortiGuard Labs has been tracking a previously undocumented Linux botnet family, which we have named Evooo1Bot. The name derives from the hardcoded string “evooo1” found in every binary.” reads the report published by Fortinet. “While the malware reuses the DDoS engine from the publicly leaked Mirai source code, it extends the original framework with numerous capabilities, including encrypted C2 communications, an SSH brute-force scanner, a SOCKS relay module, a credential sniffer, and an integrated exploit arsenal targeting multiple known vulnerabilities.”

The botnet targets 18 known CVEs, some of them dating back to 2007, including:

• CVE-2007-3010: Alcatel OmniPCX Enterprise Remote Code Execution Vulnerability
• CVE-2016-6277: NETGEAR Multiple Routers Remote Code Execution Vulnerability
• CVE-2018-14558: Tenda AC7, AC9, and AC10 Routers Command Injection Vulnerability
• CVE-2019-14931: Mitsubishi Electric Europe B.V. ME-RTU devices and INEA ME-RTU devices remote Command Injection vulnerability
• CVE-2020-10987: Tenda AC1900 Router AC15 Model Remote Code Execution Vulnerability
• CVE-2021-46422: Telesquare SDT-CW3B1 Command Injection vulnerability
• CVE-2022-37055: D-Link Routers Buffer Overflow Vulnerability
• CVE-2024-29269, Telesquare TLR-2005KSH Command Injection Vulnerability
• CVE-2025-10123, D-Link DIR-823X Command Injection Vulnerability
• CVE-2025-55583: D-Link DIR-868L B1 router Command Injection Vulnerability

The bot communicates exclusively over port 443, which is intentional: the traffic blends into expected HTTPS flows at the network perimeter. After gaining initial access through one of its exploit modules or via brute-forced SSH credentials, the bot runs a loader script that clears Bash history to erase evidence of the intrusion before pulling the architecture-appropriate binary from an external server.

The breadth suggests the operators are scanning opportunistically for anything unpatched rather than targeting specific organizations.

“This capability significantly increases the value of an infected host to attackers. The victim’s IP address can be used to disguise malicious traffic, bypass geographic restrictions, or provide access to internal networks through an already compromised machine.” continues the report. “In larger botnets, the same functionality could also be used to build a distributed proxy infrastructure, enabling anonymous traffic forwarding or monetization through residential and enterprise proxy services.”

Evooo1Bot stands out because of its proxy module. A network of compromised routers, cameras, and firewalls acting as SOCKS5 relays is a valuable commodity; operators can use it themselves to obscure attack traffic, or sell access to other criminals looking for residential or enterprise IP addresses that don’t trigger geographic blocks.

“Unlike typical botnet commands that focus on downloading payloads or launching attacks, the !socks module turns an infected host into a SOCKS5 proxy that the operator can use as a network relay. It supports two operating modes. In direct mode, it opens a SOCKS5 listener on the infected host on the default TCP port 1080 and waits for incoming client connections. The implementation first attempts to create a dual-stack IPv6 listener and falls back to IPv4 if that fails. Each accepted client is then passed to the session handler for proxying.” continues the report. “The botnet also implements a reverse relay mode. Instead of exposing a listening port, the bot establishes an outbound encrypted connection to an operator-specified relay server. This persistent control channel listens for commands such as RELAY_NEW:<session_id>, which indicate that a new proxy session should be created.”

After establishing C2 contact, the bot accepts commands covering the full post-compromise toolkit: file upload and download, interactive shell access, persistence installation, binary updates, HTTP Basic Auth and Cookie header interception, DDoS over DNS, TCP, and UDP, and the HTTP exploit dispatcher.

The credential sniffer intercepts authentication headers in transit, so any HTTP Basic Auth credentials passing through an infected device can be captured without any additional effort from the operator. If you’re still running devices with unpatched firmware from the CVE list above, or if any of your edge hardware is using default SSH credentials, Evooo1Bot is already scanning for you.

“Beyond traditional botnet functionality, it features encrypted C2 communications, multiple layers of string obfuscation using AES-256-CTR, ChaCha20, and XOR-based key derivation, as well as a 28-command remote administration interface.” concludes the report. “These capabilities place Evooo1Bot well beyond the technical baseline of conventional Mirai-derived malware.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Evooo1Bot botnet)

OVSwrap is a 13-year-old Linux kernel flaw that lets local users gain root privileges on most distributions using Open vSwitch.

Security researcher Asim Manizada disclosed OVSwrap (CVE-2026-64531, CVSS score of 7.8), a local privilege escalation vulnerability in the Linux kernel’s Open vSwitch datapath that lets an ordinary user become root on a wide range of default-configured distributions.

The upstream fix shipped in stable trees on July 24, and a proof-of-concept exploit with pre-built records for roughly 800 kernel builds is now public. If your distribution hasn’t shipped a patched kernel yet, you need to act now.

“Open vSwitch accepts a list of “actions” from userspace and validates/rewrites some of the actions into a larger internal form. These internal actions are stored as Netlink attributes, whose length field is only 16 bits wide. Now, the total internal action stream is allowed to grow past 64 KiB. But an individual nested action attribute (an attribute and all of its recursive children) still needs to fit in that 16-bit length field. Pre-fix, Open vSwitch did not check that second limit.” reads the report published by Manizada. “As a result, an attacker can submit a valid action (e.g., CLONE) containing hundreds of, say, small conntrack actions.”

The unsafe assignment behind this had been in the code for 13 years without being exploitable, held in check by a 32 KiB cap on the total generated action stream. A March 2025 change removed that cap because it was causing unpredictable failures in large OpenStack deployments, and in doing so made the old bug reachable. The enabling commit’s review thread discussed reliability and user-facing failures but never addressed the security consequence of removing the guard.

“The kernel expands those actions until the generated action is larger than 65,535 bytes, then stores that length in the 16-bit nla_len, causing it to wrap to a small value. Later code trusts the wrapped length, advances by it, and resumes parsing from the middle of the generated conntrack data.

“Critically, parts of that conntrack data – labels and timeout names – are controlled by the attacker.” the researcher continues. “Parts of that conntrack data — labels and timeout names — are controlled by the attacker. And because the wraparound redirects parsing to a deterministic offset within the same contiguous buffer, forged action headers can be placed exactly where parsing resumes. No heap grooming needed, which is why Manizada describes it as having “logic-bug-grade reliability.” Memory corruption with the predictability of a logic bug is not something defenders encounter every day.”

The exploit chains three primitives from that wraparound: a kernel pointer leak through a fake OUTPUT action, an arbitrary kernel read through a forged tunnel SET action, and a targeted decrement through teardown of a forged tunnel destination pointer.

The proof-of-concept exploit uses leaked kernel information to locate critical memory structures, bypass kernel protections, and eventually change the attacker’s user and group IDs to zero, effectively granting root privileges.

The PoC corrupts a live kernel credential, modifies /etc/sudoers or /etc/sudoers.d, and opens a root shell, leaving processes and OVS state behind deliberately to avoid unsafe teardown.

The reachability conditions are what make this broadly dangerous.

“Importantly, the attacker does not need much to reach the vulnerable code – no existing OVS bridge, no running ovs-vswitchd, no host-level CAP_NET_ADMIN. All you need is a CAP_NET_ADMIN in the user namespace that owns the network namespace*.” continues the report. “An ordinary user can therefore use an unprivileged user namespace to create a new network namespace, receive CAP_NET_ADMIN over that namespace, and create a private OVS datapath inside it with a plain unshare -Urn. This leaves many distros vulnerable in their default unprivileged-user-namespaces-enabled configuration.”

The tested list of exploitable distributions in default configuration includes AlmaLinux 9 and 10, Alpine 3.22 through 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 and 10, Debian 12 and 13, Fedora 42 through 44, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 and 10, and Ubuntu 22.04. Ubuntu 24.04 blocks direct namespace creation via AppArmor but falls to an aa-exec fallback in the PoC; Ubuntu 26.04 is blocked by default but exploitable after disabling AppArmor’s user-namespace restriction.

Install the patched vendor kernel if one is available. If you can’t patch today and OVS isn’t required on the system, the fastest interim step is to block future module loads with echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf — though a module already loaded in memory still needs to be removed or cleared by rebooting. Disabling unprivileged user namespaces closes the ordinary local-user route but doesn’t protect against a container process that already has CAP_NET_ADMIN over a network namespace it controls. The PoC repository also includes an emergency BPF guard for environments that must keep both OVS and namespaces active.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Linux)

Microsoft says Russian hackers hijacked hotel Wi-Fi portals to spread malware and steal Microsoft 365 tokens from travelers.

Microsoft Threat Intelligence disclosed CaptiveCrunch, a campaign it attributes to Storm-2945, an operational sub-cluster of Midnight Blizzard, the Russian SVR-linked group also known as APT29 and Cozy Bear. Since early May 2026, Storm-2945 has been manipulating DNS and HTTP traffic on captive portal networks at hotels, conference centers, and shared venues worldwide to redirect guests toward malware and credential theft operations. If you connected to hotel Wi-Fi while traveling in the past few months, this report is worth reading carefully.

“Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945 manipulating DNS and HTTP traffic from networks served by captive portals to redirect user traffic through actor-controlled infrastructure.” reads the report published by Microsoft. “To date, Microsoft has identified widespread compromise of Wi-Fi networks at hospitality-related organizations and other networks serviced by captive portal equipment in several countries. ReliaQuest has identified this activity not only at hotels, but also conference centers and other shared venues, and assesses that the goal of this activity is to access the accounts of corporate travelers.”

That last point matters: the shared infrastructure patterns suggest this may not be a series of individual venue compromises but rather access to something shared across portions of the captive portal ecosystem. Microsoft hasn’t named any provider.

The malware delivered through these networks is CornFlake, a full-featured Windows remote access trojan written in Go.

“CornFlake registers as a Windows service named svchost32 with the display name “Cloud Sync Service” and description “Synchronizes files with the cloud storage provider”, deliberately mimicking the legitimate svchost.exe process.” continues the report. “It establishes redundant persistence mechanisms: Windows service registrations, Registry Run keys, named scheduled tasks, and a persistence watchdog routine that runs continuously to restore any persistence mechanism that is removed by defenders or endpoint protection.”

CornFlake establishes an encrypted C2 channel using ECDH P-256 key exchange and supports dynamic reconfiguration without redeployment. Once installed, the RAT can log keystrokes, monitor the clipboard, capture screenshots, audio and webcam feeds, steal browser credentials, exfiltrate files, monitor USB devices, collect detailed system information, and execute remote commands. It also exposes a local HTTP API, allowing companion malware such as ChocoShell to reuse its secure C2 channel for file theft, configuration updates, and connectivity checks.

“For command and control (C2), CornFlake performs an Elliptic Curve Diffie-Hellman (ECDH) P-256 ephemeral key exchange with the C2 server, derives a session key via SHA-256, and communicates over a custom JSON protocol framed within the encrypted channel.” states the report. “This provides an encrypted channel to the C2 server, with each C2 session using a unique ephemeral key, making decryption of captured traffic impossible without the session-specific private key. “

Each C2 session uses a unique ephemeral key, which means captured traffic can’t be decrypted without that session’s private key. The malware also supports a runtime configuration file that lets the attacker reconfigure C2 servers and targeting without redeploying the implant.

CornFlake is delivered via ClickFix-style pages that impersonate Windows Update screens, Google verification pages, DirectX installers, browser update prompts, and disk optimization utilities — whatever looks most plausible for the venue. The victim still has to execute the payload, but the captive portal controls exactly what they see when they try to connect. Microsoft also found indications that Storm-2945 may be targeting Android devices through the same landing pages, which include instructions to download and install an APK.

The second tool, ChocoShell, is a PowerShell infostealer that runs entirely in memory. Its primary target is credentials.

“ChocoShell collects Microsoft 365 and Azure Active Directory (AD) access tokens, refresh tokens, and Web Account Manager (WAM) tokens from .tbres files in the Token Broker cache. Collection of these tokens represents a significant threat to enterprise environments, as threat actors could replay SSO sessions without browser cookies.” states Microsoft. “Additionally, Wi-Fi credentials are harvested via netsh wlan show profile with key=clear.”

ChocoShell also implements three silent UAC bypass techniques with ordered fallback, disables Windows Defender signature updates, and uses Chrome DevTools Protocol to extract browser cookies by launching the browser with a remote debugging port. This technique bypasses Chrome’s App-Bound Encryption entirely.

Since July 16, some CaptiveCrunch landing pages have added device code phishing to the mix, redirecting guests into Microsoft’s legitimate device code authentication flow. The attacker initiates the authentication request and presents the user with a code to enter at Microsoft’s real sign-in page. When the user enters it, they authenticate the attacker’s session instead of their own — an MFA-satisfied session, since the user just completed the factor. Microsoft recommends blocking the device code flow through Conditional Access policies everywhere it isn’t explicitly required.

Researchers also detailed FruitStone, the web-based C2 panel used by Storm-2945 operators to manage the CaptiveCrunch campaign. It provides a centralized interface to control CornFlake implants, deploy payloads, collect stolen data, and manage compromised devices. Disguised as a legitimate “CloudSync Console,” it supports multi-operator access, agent monitoring, remote commands, file theft, credential collection, configuration updates, and campaign infrastructure management.

The practical advice for travelers is blunt: treat hotel, conference, and airport Wi-Fi as hostile. Use a mobile hotspot or cellular data instead wherever possible. Don’t download or execute anything a captive portal presents as an update, certificate, troubleshooting tool, or security utility. Don’t enter corporate credentials on venue registration pages. And if your organization hasn’t already blocked device code flow in Conditional Access, now is a reasonable time to check.

Recently, ReliaQuest’s threat research team also documented attackers compromising the Wi-Fi gateways at hotels and conference centers, then quietly rerouting guests toward fake Microsoft login pages.

There’s a pattern connecting all this to previous campaigns. The tradecraft echoes a Russian-linked operation called FrostArmada, which hit home routers the same way earlier this year, and researchers tie both to the group known as APT28 (aka UAC-0001, aka Fancy Bear, Pawn Storm, Sofacy Group, Sednit, BlueDelta, and STRONTIUM). The link isn’t a smoking gun; it’s shared technique, not shared infrastructure, and the researchers say so plainly.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Hotel Wi-Fi)

SilverFox targeted a Japanese manufacturer with new DLL sideloading techniques, kernel drivers, and resilient ValleyRAT persistence mechanisms.

Cato CTRL documented a new SilverFox campaign targeting a Japanese industrial manufacturer. The attack chain adds two previously undocumented DLL-sideloading hosts, two kernel drivers not previously associated with SilverFox, and a dual-layer recovery architecture that keeps ValleyRAT running even if defenders terminate individual components.

The attack chain starts with an invoice-themed phishing email. The last stage was remote access via ValleyRAT. Everything in between is the interesting part.

“The attack begins with an invoice-themed phishing lure and uses attacker-controlled content hosted through legitimate QQ and Tencent Cloud services. The attackers then abuse ConvertToPDF.exe and PDFDirect.exe to sideload a malicious PDFCORE8.dll.” reads the report published by Cato. “Based on the public research we reviewed, neither application had previously been documented as a DLL-sideloading host.”

Both applications are legitimate products from Zeon Corporation, digitally signed and unmodified. The attack works because Windows resolves DLL dependencies from the local working directory first, so placing a malicious PDFCORE8.dll in the same folder as the trusted executable is enough.

In some samples, the executable was also renamed MicrosoftEdgeUpdate.exe to reduce suspicion further, which at least shows a sense of humor about impersonation targets.

Once loaded, PDFCORE8.dll operates as a self-contained execution framework with all its most dangerous components stored inside as encrypted resources.

“The malicious PDFCORE8.dll embeds BootRepair.sys, EnPortv.sys, and wsftprm.sys and manages them through shared resource-decryption, driver-deployment, service-creation, and device-communication routines.” continues the report. “One of the most significant findings in this campaign is SilverFox’s modular BYOVD framework. Rather than depending on a single signed but vulnerable driver, the malware supports three options: BootRepair.sys, EnPortv.sys, and wsftprm.sys.“

Across variants, the malware mainly changes the driver image, device name, and IOCTL value while reusing the same core framework.

The practical implication of this modular design is that blocking one driver doesn’t stop the attack, the framework simply tries another. BootRepair.sys and EnPortv.sys are both new associations for SilverFox; wsftprm.sys appeared in prior reporting on the group.

All three drivers ultimately serve the same purpose: getting a process identifier into kernel space and calling ZwTerminateProcess() on security products that user-mode processes can’t touch. The user-mode component enumerates running processes, matches them against a hardcoded list of endpoint security tools, and passes the PIDs to whichever driver is loaded. The driver handles the actual kill from kernel mode. The malware also unhooks NTDLL by replacing its in-memory .text section with a clean copy from disk, removing inline monitoring hooks before calling native Windows APIs.

After terminating security processes and cleaning up API hooks, the malware contacts its C2 at 43.128.26[.]132, downloads shellcode, injects it into a suspended svchost.exe process via thread-context hijacking, and stores both the shellcode and its configuration in the registry, under HKCU\Console\0 and HKLM\SOFTWARE\IpDates_sun respectively.

“Before executing the registry-resident shellcode, the malware searches it for the marker: FaCai2024 The marker does not represent executable instructions. Instead, it identifies a reserved region inside the payload where the malware inserts its runtime configuration.” continues the report. “The framework retrieves the configuration from: HKLM\SOFTWARE\IpDates_sun It then replaces the FaCai2024 placeholder with the recovered C2 information, producing a fully configured payload immediately before execution. This separation gives the attacker operational flexibility. The same stored payload can be reused with updated server addresses or ports without changing the payload body itself.”

“Fa Cai” means “become prosperous” in Mandarin. Tencent Security previously documented the same marker and registry location in earlier FaCai phishing group activity.

The recovery architecture is what makes this campaign notably harder to disrupt than typical malware deployments. An internal monitoring routine checks every cycle whether the injected svchost.exe process is still active, and recreates the payload if it isn’t. An external watchdog, a batch script embedded in the DLL’s resources and executed via cmd.exe, checks every 30 seconds whether the loader itself is still running, and relaunches it if not. Defenders who terminate only the injected payload leave the loader running to recreate it.

Defenders who terminate only the loader leave the watchdog running to restart it. Both components need to go simultaneously, and then the scheduled task that relaunches the loader on logon needs to go too.

Detection should focus on behavior sequences rather than individual indicators. ConvertToPDF.exe or PDFDirect.exe executing from %TEMP%, kernel-driver services for any of the three embedded drivers appearing, binary data written to HKCU\Console\0, and tasklist.exe or find.exe running repeatedly from cmd.exe are each individually explainable — together they describe this specific attack chain. Cato’s NGAM blocked the malicious PDFCORE8.dll before the driver deployment stage was reached in the observed incident, which cut the chain at its most central point since the DLL contains every subsequent capability the attack depends on.

“This campaign shows how SilverFox is expanding its defense-evasion and remote-access toolkit. The most significant additions are the previously undocumented SilverFox use of BootRepair.sys and EnPortv.sys, along with the abuse of ConvertToPDF.exe and PDFDirect.exe as DLL-sideloading hosts.” concluders the report. “The malicious PDFCORE8.dll brings these capabilities together in one modular stage that combines vulnerable-driver deployment, security-process termination, NTDLL unhooking, thread-context hijacking, registry-based payload storage, and dual recovery mechanisms. This design improves resilience by allowing the malware to restore execution if either the payload or loader is interrupted.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, SilverFox APT)

Brand impersonation now drives initial access, using fake sites and apps to deliver malware, making rapid takedowns essential to disrupt attacks.

Attackers recently poisoned more than 700 websites, including sites run by Harvard, Oxford, and DuckDuckGo.

They used a fake Cloudflare page to trick visitors into running a ClickFix attack that installed malware. Researchers tracing the incident found the same injected code running across hundreds of unrelated sites, all feeding shared attacker infrastructure.

That Harvard and Oxford can get turned into malware delivery platforms is concerning. That two rival criminal groups were fighting each other for control of the same hijacked sites is cause for immediate action.

Whether you’re a university, online retailer, financial institution, or anything in between, brand impersonation is no longer merely a reputational irritation. It’s attacker infrastructure, and you need to act accordingly.

Brand impersonation is now a delivery mechanism

For most of its history, brand impersonation sat with legal as a trademark problem. What changed is what attackers do with it.

An attacker no longer needs to break into an organization when they can position themselves between a trusted brand and its customers. Phishing sites, fake apps, fraudulent social media accounts, or malicious paid ads all point to the brand itself becoming part of the attack chain.

As far back as 2022, the FBI warned of search-ad impersonation. This attack technique involves cybercriminals buying ads that display in search engine results that closely resemble a real business, so the fraudulent listing ranks above the legitimate one. Customers click the top result, land on a spoofed domain, and either download malware or input their credentials.

Fake apps and cloned shops also follow the same principle, while executive impersonation extends it to a single person’s name and likeness. In every case, attackers pose as something or someone users already trust. That means they don’t actually have to breach anything. Essentially, the brand does the social engineering for them.

These emerging — or, if we’re honest with ourselves, emerged — techniques have led to a steady rise in phishing attacks. The Anti-Phishing Working Group (APWG) recorded 971,181 phishing attacks in the first quarter of 2026, a 13.8% increase over the previous quarter, and impersonation-driven abuse is a growing share of that total rather than a static slice.

Why blocking feels like winning (but isn’t)

One of the big problems with merely blocking phishing URLs is that it feels like you’re doing something. It’s instant gratification at its worst — teams check a box, metrics look green, and the immediate crisis disappears.

Local blocking (whether via firewalls, secure email gateways (SEGs), or DNS-layer blocklists) stops a URL from resolving inside the corporate perimeter, but leaves the broader threat untouched. But that means the domain stays live for every user outside that specific filter.

Even worse, attackers can redeploy the same kit with a new domain, a swapped hosting provider, or a single-character variation, so the campaign continues largely unhindered.

These attack techniques let cybercriminals scale impersonation to previously unimaginable levels. A single phishing kit becomes dozens of near-identical deployments, and one fraudulent account becomes a cluster of linked profiles. Blocking individual URLs treats each deployment as a fresh incident, when the attacker is running the same infrastructure repeatedly.

As a result, organizations are left playing a game of whack-a-mole. They spend enormous energy knocking down individual deployments, when what they should really be doing is unplugging the machine.

The ownership vacuum

Responsibility for brand impersonation tends to belong to three different teams.

Legal owns the trademarks and can pursue enforcement, but their processes move on a slow timeline. Marketing teams own the channels where impersonation happens (like social platforms or app stores) but can’t pursue takedowns. SOCs track alerts generated by activity inside the network, but impersonation targeting customers remains invisible to them.

The problem is that no one really owns takedowns, so it becomes ad hoc. Whoever notices the impersonation attempt files a report through whatever abuse channel the hosting provider, registrar, or ad platform happens to offer. And each of them will have their own evidence requirements and response timeline.

That fragmentation creates a bottleneck that prevents brand protection from keeping pace with automated attackers. Although an analyst can identifya lookalike domain fast, getting it removed can be achingly slow and complicated.

Analysts must navigate a reporting form for every registrar, host, and platform involved, with no guarantee that any of them prioritizes the request. Meanwhile, an attacker running automated tooling spins up new infrastructure faster than any manual process can take down the old.

Treat brand impersonation like C2, measure it like an SLA

The fix is to treat brand impersonation infrastructure like a SOC would treat C2 infrastructure: tracking, correlating, and removing attacker infrastructure on a measured timeline.

That means analyzing the attacker’s operational patterns. Shared ASN registrations, repeated hosting providers and reused SSL certificate issuers link campaigns that look unrelated at the URL level but come from the same source.

Once the SOC has mapped that infrastructure, the response can move from passive legal correspondence to something closer to an enforced service level agreement (SLA), with a defined target for time between detection and takedown, and a way to measure whether they’re meeting that target. You can read Netcraft’s Field Guide to Brand Protection to learn more about the operational details behind that capability.

Reframing this problem also brings in a better metric than just alert volume: detection-to-takedown time and infrastructure recurrence rate. They measure whether teams are actually disrupting anything, which matters when the same kit keeps appearing under a new domain.

Progress against brand impersonation comes from disrupting the infrastructure behind it, and that requires someone to own the work. Assign it to a specific function, attach detection-to-takedown time and recurrence rate as the measures, and hold the process to them.

About the Author: Josh is a Content writer at Bora. He graduated with a degree in Journalism in 2021 and has a background in cybersecurity PR. He’s written on a wide range of topics, from AI to Zero Trust, and is particularly interested in the impacts of cybersecurity on the wider economy.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, brand impersonation)

F5 fixes critical nginx flaw CVE-2026-42533 that can crash servers and, in some cases, allow remote code execution through crafted HTTP requests.

F5 released patches for a critical nginx vulnerability, tracked as CVE-2026-42533 (CVSS score of 9.2), that can allow an unauthenticated attacker to trigger a heap buffer overflow using specially crafted HTTP requests.

“heap buffer overflow might occur in a worker process when using the map directive with regex matching if the map variable was included in a string expression after a capture affected by this map; a similar issue might happen when using a non-cacheable variable in a string expression (CVE-2026-42533).” reads the advisory.

CVE-2026-42533 affects NGINX Plus and Open Source when specific regex-based map configurations are used. An unauthenticated attacker can send crafted HTTP requests to trigger a heap buffer overflow, causing crashes or denial of service. In certain conditions, especially if ASLR is disabled or bypassed, the flaw may also allow remote code execution. The issue affects only the data plane, not the control plane.

The vulnerability affects NGINX versions from 0.9.6 through 1.31.2. F5 fixed the issue in NGINX 1.30.4, 1.31.3 and NGINX Plus 37.0.3.1. The flaw impacts only the data plane and does not expose the NGINX control plane.

As a temporary workaround, affected regex-based map configurations can be modified to use named captures instead of numbered captures, but this does not provide complete protection.

The researchers Mufeed VH of Winfunc Research and Maxim Dounin discovered the vulnerability.

Security researcher Stan Shaw (cyberstan) reported that CVE-2026-42533 may have a higher impact than initially described by F5. While F5 highlights denial-of-service risks, Shaw believes the flaw could also help attackers bypass ASLR protections and achieve remote code execution under certain conditions. He has not released exploit details or a proof-of-concept yet.

Shaw released a static scanner that identifies vulnerable NGINX configurations without exploiting the flaw. The tool checks include files, analyzes directive relationships, and detects exploitable patterns. Shaw is delaying publication of the proof-of-concept and technical exploitation details to give organizations time to patch, noting that similar NGINX flaws were exploited soon after PoCs became public.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, F5)

U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Fortinet FortiSandbox and Microsoft SharePoint flaws to its Known Exploited Vulnerabilities catalog.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added Fortinet FortiSandbox and Microsoft SharePoint flaws to its Known Exploited Vulnerabilities (KEV) catalog.

• CVE-2026-25089 (CVSS score of 9.8) Fortinet FortiSandbox OS Command Injection Vulnerability  
• CVE-2026-39808 (CVSS score of 9.8) Fortinet FortiSandbox OS Command Injection Vulnerability  
• CVE-2026-58644 (CVSS score of 9.8) Microsoft SharePoint Deserialization of Untrusted Data Vulnerability

This week, Microsoft’s July 2026 Patch Tuesday addressed the SharePoint remote code execution bug CVE-2026-58644, which can be triggered without authentication or user interaction. The flaw stems from the deserialization of untrusted data.

“Deserialization of untrusted data in Microsoft Office SharePoint allows an unauthorized attacker to execute code over a network.” reads the advisory. “In a network-based attack, an attacker authenticated as at least a Site Owner, could write arbitrary code to inject and execute code remotely on the SharePoint Server.”

Microsoft confirmed it is aware of active exploitation of this vulnerability.

The second issue added to the KeV catalog is an OS command injection flaw, tracked as CVE-2026-25089, in FortiSandbox products. The vulnerability could allow remote, unauthenticated attackers to send specially crafted HTTP requests and execute arbitrary commands on affected devices. Adham El Karn of Fortinet Product Security team discovered the vulnerability.

The last issue added to the catalog, tracked as CVE-2026-39808, is an OS command injection flaw.

“An Improper Neutralization of Special Elements used in an OS Command (‘OS command injection’) vulnerability [CWE-78] in FortiSandbox may allow an unauthenticated attacker to execute unauthorized code or commands via crafted HTTP requests.” reads the advisory.

Cybersecurity firm Defused Cyber confirmed it’s seen active exploitation of this vulnerability within a 24-hour window.

According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog.

Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure.

CISA orders federal agencies to urgently fix these flaws by July 19, 2026.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CISA)

Russian-speaking UAT-11795 spreads trojanized Zoom, Webex, and MobaXterm installers to deliver Starland RAT and the WLDR memory-only implant.

Cisco Talos researchers published a detailed technical report on July 16 disclosing UAT-11795, a financially motivated, Russian-speaking threat actor that has been running a malware campaign against users in the United States and Europe since at least June 2025. The operation distributes trojanized installers for software that IT professionals and developers actually use: MobaXterm, Cisco Webex, Zoom, DBeaver, and even the gaming platform FACEIT.

“Cisco Talos is disclosing UAT-11795, a sophisticated, Russian-speaking, financially motivated adversary that has been conducting a malicious campaign targeting users in the U.S. and Europe since at least June 2025.” reads the report published by Talos.

The wide range of targets, from developer tools and business collaboration software to gaming platforms, suggests the attackers are trying to infect many different types of users instead of focusing on a single industry.

The campaign delivers two newly documented malware families. The first is Starland RAT, a Python-based remote access tool with credential theft and cryptocurrency wallet enumeration built in. The second is the WLDR agent, a PowerShell-based command-and-control implant that runs entirely in memory. Both are novel. Talos also observed the actor deploying CastleStealer and Remcos RAT as additional payloads delivered through Starland after initial compromise.

Initial access appears to come through a ClickFix social engineering technique, where the victim is tricked into running a command that downloads and executes a malicious HTA file silently. That HTA file drops a Windows batch file and a trojanized installer, while simultaneously establishing persistence through a registry Run key that re-executes the HTA every time the user logs in. A Russian-language developer comment found inside the VBScript, “Добавление команды в автозапуск для текущего пользователя,” confirms the actors are Russian-speaking and, apparently, left their development notes in the deployed code.

The trojanized installers are built using the Nullsoft Scriptable Install System. They package a real Python runtime alongside a compiled Python loader disguised as a file named LICENSE.txt. The NSIS script executes the loader, which decrypts Starland RAT using a single-byte XOR key and runs it directly in memory. The actual software installation proceeds normally, so the victim sees what they expected and has no reason to suspect anything happened.

Before any network activity, Starland checks whether it’s running in a sandbox. It compares the logged-on username against a hardcoded list of known sandbox service accounts including WDAGUtilityAccount, then checks the computer name against hostnames from Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. It also checks for a Zone.Identifier alternate data stream on the installer file to confirm it was downloaded through a browser rather than dropped directly. Any mismatch terminates execution.

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

After clearing those checks, the RAT establishes persistence before making any network calls, creating a scheduled task with a randomized name following the pattern PythonLauncher-{3 random characters} and a Startup folder shortcut as a secondary mechanism. It then runs reconnaissance: hardware ID derived from the C: drive volume serial number, total RAM, installed antivirus, and Active Directory membership. If the machine is domain-joined, it executes whoami, systeminfo, net user, and nltest to map the domain structure. It also enumerates over 40 cryptocurrency wallets from both browser extensions and desktop applications, takes a screenshot of the desktop, and bundles everything into a JSON payload that it XOR-encrypts with the key “helo1” before sending it to the C2.

The C2 design is worth calling out. The RAT sends victim registration data to a hardcoded primary C2 domain, but if that fails, it uses a Polygon Ethereum smart contract as a backup.

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

Blocking a C2 domain doesn’t help if the fallback address lives on a public blockchain that you can’t take down.

Before registering with the C2, the RAT sends a Telegram notification to an attacker-controlled bot with the victim’s public IP, OS details, processor information, computer name presented as a “Crew ID,” and any detected cryptocurrency wallets. Two Telegram bots are used: “skuefq_bot” and “komandastuk_bot.” Talos also found a private Telegram channel called “stuk komanda” created June 5, 2025, structured like a C2 dashboard, confirming the operation’s timeline.

When Starland receives a shellexecute command from the C2, the actor can use it to deploy the WLDR framework. This arrives in three stages: a heavily obfuscated PowerShell stager, a downloader that fetches victim-specific payloads bound to the machine’s hardware ID, and the WLDR agent itself, which runs entirely in memory.

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

The WLDR agent uses AES-256-CBC with HMAC-SHA256 for all communication, derives session keys through PBKDF2-SHA256 at 5,000 iterations, and masks its traffic with headers that mimic a Chrome 124 browser session. The Runspace engine supports up to 10 concurrent threads and streams output back to the C2 in real time as scripts execute rather than waiting for completion, making it suitable for interactive monitoring tasks. The C2 responds only to requests that carry a matching hardware ID, so probing the endpoint directly returns nothing useful.

Starland also delivers CastleStealer, a .NET infostealer that targets browser credentials across the full Chromium family and Firefox, cryptocurrency wallet extensions, Discord and Telegram session files, and Steam credentials. It checks for a Russian locale and exits if it matches, which is consistent with the operator protecting their own environment. Remcos RAT is delivered through a separate 32-bit shellcode path. The custom shellcode loader that handles both payloads disables AMSI and ETW at runtime by patching the first bytes of AmsiScanBuffer and EtwEventWrite in memory, then falls back to a VirtualProtect-based write if the primary patching fails, before decompressing and injecting the final payload using reflective PE injection or .NET CLR loading depending on the payload type.

The full indicator set including domains, IPs, file hashes, and Snort rule IDs is available in Talos’ GitHub repository linked from the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, UAT-11795)

GodDamn ransomware uses the signed PoisonX driver to disable security tools, marking a more advanced version of the Beast ransomware family.

Symantec’s Threat Hunter Team found a new ransomware family called GodDamn that first appeared in the wild on May 21, 2026, and analyzed an attack that took place in early June. The group behind it, which Symantec tracks as Hyadina, has been running ransomware operations since March 2022. GodDamn is their third product: Monster came first, Beast followed in June 2024, and now this.

The lineage isn’t speculation. Symantec researchers noticed significant code overlap between GodDamn and Beast, and the operational toolset, including AnyDesk for remote access, NirSoft-based credential stealers, and the same avoidance of targets in CIS countries, runs consistently across all three iterations.

“Analysis of a recent GodDamn ransomware attack indicates that this seemingly new ransomware is in fact the latest rebrand of the Beast ransomware, which in itself was a rebrand of the Monster ransomware, which was first seen in 2022.” reads the report published by Symantec. “The Symantec Threat Hunter Team tracks the developer behind these ransomware families as Hyadina.”

The headline upgrade in GodDamn is the use of PoisonX, a kernel driver that carries a valid Microsoft signature. That signature matters because Windows loads signed drivers automatically, and a driver running at kernel level can terminate security software processes, strip away the permissions those tools need to function, or tamper with the kernel’s internal event notifications so that security products stop receiving alerts about what’s happening on the machine. They keep running, but they’re effectively blind.

Most bring-your-own-vulnerable-driver (BYOVD) attacks exploit a legitimate but flawed driver that already exists. PoisonX is different.

The cybersecurity community first observed the use of the PoisonX kernel driver in early 2026 when attackers used it to disable security software. At the time, threat actors used it to kill the CrowdStrike Falcon service by sending a crafted IOCTL to the driver’s undocumented interface.

“The driver is signed by Microsoft and so to the system it appears to be a legitimate driver. This means it can be used to stop or disable security software at the kernel level. We commonly call this type of defense evasion a bring-your-own-vulnerable-driver (BYOVD) attack, where a vulnerability in a legitimate driver is exploited to shut down defenses.” continues the report. “However, the PoisonX driver seems to be slightly more unusual, in that it appears to be a malicious driver that its developers succeeded in getting signed by Microsoft, and it is now being used by ransomware attackers.”

Now PoisonX is part of GodDamn’s standard toolkit, and it’s also been adopted by the operators of The Gentlemen ransomware-as-a-service scheme in their custom defense-disabling tool handed to affiliates.

The initial access vector for the investigated attack is unknown. The first confirmed malicious activity appeared on May 29, when AnyDesk turned up on a host inside the organization, placed in the user’s Music folder rather than a standard installation directory. That location is consistent with manual delivery by an attacker who’d already obtained access through some earlier means.

The next day, the attackers deployed their defense evasion capabilities on a second host.

A file named symantec.exe, staged in the Music folder and designed to look like a Symantec product, dropped the PoisonX driver into the system driver store as g11.sys. On the same host, a credential-harvesting toolkit appeared in a subdirectory of the user profile containing 14 separate tools: Mimikatz, WebBrowserPassView, ChromePass, PasswordFox, MessengerPass, VNCPassView, MailPassView, SniffPass, OperaPassView, CredentialsFileView, WirelessKeyView, ExtPassword, PSTPassword, and NetPass. Together they cover browsers, Windows Credential Manager, cached domain credentials, VNC sessions, email clients, Wi-Fi profiles, and live network traffic. Netscan.exe was included to map reachable hosts. That’s a thorough shopping list.

After a two-day gap, lateral movement began on June 1 using PsExec, with all commands sharing a process chain through psexesvc.exe, services.exe, and wininit.exe. The attackers disabled Windows Defender real-time monitoring and mounted administrative shares using stolen credentials to reach adjacent systems.

“There was then a gap in activity by the attackers of approximately two days. On June 1, 2026, lateral movement began across the enterprise network.” states Symantec. “All malicious commands during this phase shared a process lineage running through psexesvc.exe, services.exe, and wininit.exe, confirming that PsExec was being used to push commands to remote targets. “

On each host they reached, they configured AnyDesk for unattended access: a dedicated configuration directory was created, the interactive consent prompt was suppressed, and a remote access password was set by piping it directly to AnyDesk’s standard input.

AnyDesk was then registered as two separate auto-start Windows services to survive reboots, with a PowerShell pre-staged installer used on some machines to streamline the rollout.

“After completing the AnyDesk setup on each host, the attackers terminated the running AnyDesk process, waited briefly, then rebooted the machine.” continues the report. “By the end of June 2, this deployment sequence had been repeated across at least 10 hosts within the targeted organization.”

The four-day gap between the first activity on May 29 and encryption starting June 3 is consistent with a dwell period used for staging, data exfiltration, or further reconnaissance.

GodDamn ransomware was first detected on June 3 on a separate network segment belonging to a distinct part of the organization. The binary was named encrypter-windows-gui-x86.exe and appeared in user Downloads and Music folders. In some attacks, encrypted files are renamed with the .God8Damn extension. In this particular incident, the attackers used the victim organization’s own name as the file extension, which Symantec describes as somewhat unusual. Victims are directed to contact the attackers via email or the qTox encrypted messaging app.

Let’s look at the threat actor behind the new ransomware family. Hyadina’s track record since 2022 shows a consistent pattern: take what worked before, fix the detection problems, add new capabilities, rebrand. Monster used Delphi and targeted 32-bit Windows. Beast added Linux and VMware ESXi support, expanded language options including Chinese, and improved encryption performance. GodDamn adds a legitimately signed malicious kernel driver.

As Symantec observed about the original Monster attacks: “One of the hallmarks of a November 2022 Monster attack documented by Symantec was the use by the attackers of a password protected self-extracting archive containing the Mimikatz credential-dumping tool and a large number of password-harvesting tools developed by NirSoft, much like the tools we saw used in this recent GodDamn attack, with many of the same tools used, including AnyDesk and NetScan also.”

The toolset hasn’t changed much in four years. The evasion techniques have.

“GodDamn appears to be the latest ransomware iteration from this group, which continues to develop its stealth and defense evasion capabilities. GodDamn’s use of the relatively newly discovered PoisonX malicious driver component represents an escalation in defensive evasion capability by this group, indicating that Hyadina is continuing to actively develop its ransomware and its capabilities.” concludes the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, GodDamn Ransomware)

Januscape: A 16-year-old Linux KVM flaw lets cloud VM tenants crash hosts and potentially escape guests. It affects Intel and AMD systems.

Security researcher Hyunwoo Kim has published details of a use-after-free vulnerability in Linux’s KVM hypervisor that allows code running inside a guest virtual machine to corrupt host kernel memory. The bug, tracked as CVE-2026-53359 and named Januscape, has been sitting in the kernel since August 2010. It affects both Intel and AMD processors, which makes it the first publicly documented guest-to-host KVM exploit that works across both architectures.

Kernel-based Virtual Machine (KVM) is a virtualization technology built directly into the Linux kernel that allows one physical computer to run multiple independent virtual machines (VMs).

Introducing "Januscape" (CVE-2026-53359)

A Guest-to-Host Escape in KVM/x86 exploiting a UAF in the shadow MMU. Triggerable on both Intel and AMD hosts. Threatens x86 public clouds (GCP, AWS) that expose nested virtualization.

"16 years" latent. Successfully used as a… pic.twitter.com/UHVC6Tg3Nm

— V4bel (@v4bel) July 6, 2026

Kim used it as a zero-day submission in Google’s kvmCTF program, which offers up to $250,000 for full guest-to-host escapes. The public proof-of-concept reliably panics the host kernel. A separate, complete exploit that achieves code execution on the host exists but hasn’t been released. Kim says that one is planned for the distant future.

KVM maintains its own internal set of page tables to track a guest’s memory layout. When it needs one of these tracking pages, it looks for an existing one to reuse. The problem is that it matched candidates by memory address alone and ignored the type of tracking page it was grabbing.

“Januscape is a use-after-free vulnerability in the shadow MMU emulation of KVM/x86. It can trigger the bug with guest-side actions alone to corrupt the host kernel’s shadow page, and it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization, particularly multi-tenant x86 public clouds (GCP, AWS, etc.).” states Kim. “In fact, Januscape was successfully used as a 0-day exploit in Google kvmCTF.”

This mistake confuses KVM about which memory page it is managing. Once KVM’s internal records become incorrect, the Linux kernel may handle invalid data, causing crashes or potentially allowing an attacker to gain control.

Most of the time, the kernel detects the corruption and shuts itself down immediately to prevent further damage. That’s the crash the public PoC triggers: a guest VM loads a kernel module and races for seconds to minutes until the host panics. Every other tenant VM on the same physical machine goes down with it. The more dangerous outcome happens when the freed tracking page gets allocated for a different use before cleanup runs. The cleanup then writes into memory it no longer owns. The attacker controls where that write lands, not what gets written, but that constrained primitive is enough to develop into full host code execution.

The attack requires root inside the guest VM and nested virtualization exposed by the host. Guest root is a standard condition on cloud instances: when you rent a VM, you get root on your own instance. The nested virtualization requirement is what matters architecturally, because even hosts that use hardware memory management by default have to fall back through the older shadow MMU code path when nested virtualization is active, and that’s exactly where the bug lives.

“Unlike the commonly published QEMU escape vulnerabilities, Januscape occurs in in-kernel KVM, so it is triggered independently of QEMU’s emulation. Because of this, it can also threaten large public clouds that implement and use their own virtualization stack.” continues the researcher.

That’s a meaningful distinction. Custom cloud virtualization stacks that strip out QEMU entirely aren’t protected by that fact.

On distributions like RHEL where /dev/kvm is world-writable with permissions set to 0666, an unprivileged local user could also use this bug to escalate to root without being inside a VM at all. Kim flags this but dismisses it as the lower-value use case. The guest-to-host cloud scenario is the one that matters. (His exact phrasing: doing so would be like paying gold for garbage. Fair enough.)

The fix is a one-line addition to kvm_mmu_get_child_sp(). The reuse condition now checks both the guest frame number and the role type together, so KVM only reuses a shadow page when both values match. Fixed stable kernel versions shipped on July 4, 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260.

NVD hasn’t assigned a CVSS score yet. If you operate an x86 KVM host that accepts multi-tenant guests with nested virtualization enabled, confirm that commit 81ccda30b4e8 is present in your running kernel. Check the package changelog rather than relying on uname -r, because distribution backports may carry the fix under a different version number. If patching immediately isn’t possible, disabling nested virtualization with kvm_intel.nested=0 or kvm_amd.nested=0 removes the attack path for untrusted guests. ARM64 KVM hosts aren’t affected by Januscape specifically, though Kim’s earlier ITScape disclosure (CVE-2026-46316) covers a separate guest-to-host issue on that architecture.

“Januscape (CVE-2026-53359) covers the range from 2032a93d66fa (2010-08-01) to 81ccda30b4e8 (2026-06-16).” the researcher concludes “In other words, this vulnerability lay dormant for about “16 years”.”

Januscape is Kim’s third significant Linux kernel exploit in roughly two months. In May 2026, he disclosed Dirty Frag (CVE-2026-43284 and CVE-2026-43500), a page-cache write vulnerability chain that delivers reliable root on most major Linux distributions, extending the same vulnerability class as Dirty Pipe and Copy Fail. In June, he published ITScape (CVE-2026-46316), the first publicly demonstrated guest-to-host KVM escape on ARM64, exploiting a race condition in the virtual interrupt controller.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Januscape)

Bad Epoll (CVE-2026-46242) lets local attackers gain root on Linux and Android. The flaw was missed by AI but found by a security researcher.

A newly disclosed Linux kernel vulnerability, named Bad Epoll (CVE-2026-46242), allows a local attacker with no special privileges to gain full root access on affected Linux systems and Android devices. Security updates are already available, and users are urged to install them as soon as possible.

The flaw affects the Linux kernel’s epoll subsystem, a core feature used by servers, browsers, and countless applications to efficiently manage multiple network connections and file events. Because epoll is fundamental to Linux, there is no practical workaround other than patching vulnerable systems.

Bad Epoll is a classic use-after-free vulnerability, which occurs when a program continues to use a piece of memory after it has already been released (“freed”).

Two kernel threads attempt to release the same internal object simultaneously. One frees the memory while the other continues using it, creating a brief opportunity to corrupt kernel memory and escalate privileges to root.

“Two of epoll’s close paths run at the same time and collide. One frees an object while the other is still writing into it, and that is the use-after-free (UAF).” continues the advisory. “The race window, and how the exploit drives it. The exploit uses four epoll objects grouped into two pairs. One pair triggers the race, while the other becomes the victim. From there, the exploit turns the 8-byte UAF write into a UAF on a file object, and uses a cross-cache attack to fully control the file’s contents. Turning the bug into an arbitrary kernel memory read through /proc/self/fdinfo. With that control, the exploit gains an arbitrary read of kernel memory through /proc/self/fdinfo. Finally, it hijacks control flow and executes a ROP chain to gain a root shell.”

Although exploiting the flaw requires hitting a timing window only six CPU instructions wide, researcher Jaeyoung Chung developed a reliable proof-of-concept that reportedly succeeds in about 99% of attempts on tested systems. According to the researcher, the exploit can even be launched from Chrome’s renderer sandbox, making it particularly dangerous, and could also impact Android devices.

“Bad Epoll (CVE-2026-46242) is a race-condition use-after-free in the Linux kernel’s epoll subsystem. This bug lets an unprivileged process become root, not only on Linux desktops and servers but also on Android devices.” reads an advisory published by Chung.

One of the most interesting aspects of the vulnerability is its connection to AI-assisted vulnerability research. Bad Epoll originates from the same section of kernel code where Anthropic’s Mythos model previously identified another privilege escalation flaw, tracked as CVE-2026-43074. The AI detected the first bug, but missed this closely related vulnerability, which was later discovered manually.

“A single commit in 2023 introduced two separate race conditions into the epoll code, only about 2,500 lines in all. Both turned out to be critical bugs that can lead to privilege escalation.

The first was found by Anthropic’s Mythos and reported as CVE-2026-43074. That result is impressive on its own, because kernel race bugs are known to be hard to find. It showed a frontier AI model’s ability to find race bugs. An independent researcher later submitted a 1-day exploit for it to kernelCTF.” continunes the advisory. “The other race is Bad Epoll, which Mythos missed.”

Chung believes the miss is understandable. The race condition is extremely difficult to reason about because the vulnerable execution path exists for only a tiny fraction of a second. In addition, once the first flaw was patched, Bad Epoll no longer generated obvious warnings through KASAN, Linux’s memory error detection system, making it even harder to spot.

The good news is that there is currently no evidence that Bad Epoll has been exploited in the wild. The only public exploit is the proof-of-concept released through Google’s kernelCTF program. An Android exploit is reportedly still under development.

The flaw affects Linux kernels based on version 6.4 and later, unless they already include the upstream fix. Older long-term support kernels based on Linux 6.1, including some Android devices such as the Pixel 8, are not vulnerable because the problematic code was introduced after those versions branched.

Bad Epoll joins a growing list of high-profile Linux privilege escalation vulnerabilities recently disclosed, including Copy Fail, Dirty Frag, Fragnesia, and DirtyClone. While many of these newer vulnerabilities are deterministic and relatively easy to exploit, Bad Epoll belongs to the older class of race-condition bugs, which are significantly harder to discover, exploit, and patch.

The case also highlights both the promise and the current limitations of AI in vulnerability research. Models such as Mythos have already demonstrated they can identify complex kernel flaws and even uncover long-standing vulnerabilities in projects like FreeBSD.

At the same time, Bad Epoll shows that highly subtle race conditions can still escape even state-of-the-art AI systems. For now, human expertise remains essential, particularly when vulnerabilities depend on tiny timing windows and complex concurrent execution paths.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Bad Epoll)

DirtyClone: a Linux kernel privilege escalation that silently rewrites executables in memory, leaving no disk trace. Patch now.

JFrog Security Research published a working exploit walkthrough on June 25 for CVE-2026-43503 (CVSS score of 8.8), a Linux kernel privilege escalation they call DirtyClone. It’s the fourth vulnerability in the DirtyFrag family, all sharing the same root failure: file-backed memory gets treated as packet data, and an in-place network operation writes where it should have copied. CVSSIf your kernel doesn’t have the May 21 mainline patch, update now.

“The severity of this issue is significant because it allows any unprivileged local user to gain root access (LPE) by manipulating the Linux page cache.” reads the report published by JFrog. “The attack is silent, leaves no kernel logs or audit traces, and bypasses common on-disk integrity monitoring tools.”

The attacker loads a privileged binary like /usr/bin/su into memory, wires those pages into a network packet, and forces the kernel to clone it through a loopback IPsec tunnel they control. The decryption step overwrites the binary’s authentication logic with attacker-chosen bytes, and the next run of su hands over root — while the file on disk stays untouched.

The exploit requires CAP_NET_ADMIN to configure the IPsec environment. On Debian and Fedora that capability is reachable by any local user through unprivileged user namespaces, which are enabled by default.

“The attacker begins by creating a fresh network namespace:

unshare -Urn

This provides network administrative capabilities inside the namespace.” continues the report. “While capabilities are namespaced, page cache is shared at the host level, so if file-backed pages are modified through shared mappings, the effects may propagate to other processes using those pages.”

Ubuntu 24.04 and later restrict namespace creation via AppArmor, blocking the default exploit path, but every other distribution with default namespace configurations is exposed.

The DirtyFrag family now has four members. Copy Fail (CVE-2026-31431) arrived in late April. DirtyFrag (CVE-2026-43284 and CVE-2026-43500) followed on May 7. Fragnesia (CVE-2026-46300) appeared on May 13, bypassing the DirtyFrag patch through a flag-dropping bug in skb_try_coalesce().

“DirtyFrag is a family of Linux kernel memory corruption vulnerabilities in the core networking stack affecting how socket buffers (skb) reference shared page-cache memory, which are subsequently weaponized through in-place cryptographic transformations in subsystems like XFRM/IPsec or RxRPC.” continues the report. “Despite targeting different packet cloning or forwarding paths, variants like DirtyFrag, Fragnesia, and DirtyClone all rely on a shared technique: tricking the kernel into treating read-only, file-backed page cache memory as writable network buffers.”

Each patch closed one code path and left others open. The underlying contract, that every function moving socket buffer fragments must preserve the shared-frag flag, every time, was never fully enforced across the codebase.

The original DirtyFrag researcher Hyunwoo Kim submitted a broader multi-site patch on May 16 covering the remaining fragment-transfer helpers. JFrog independently rediscovered one of the affected functions on May 19, built a working exploit, and reported it. The combined fix merged on May 21, CVE-2026-43503 was published on May 23, and Linux v7.1-rc5 shipped on May 24 as the first fixed release. Ubuntu, Debian, and SUSE have published advisories; Red Hat has a Bugzilla tracking entry.

If patching today isn’t an option, two workarounds reduce the attack surface. Setting kernel.unprivileged_userns_clone=0 on Debian and Ubuntu blocks the namespace-based path to CAP_NET_ADMIN. Blacklisting the esp4, esp6, and rxrpc kernel modules removes the in-place decryption primitives the exploit needs, though that breaks IPsec and AFS. Neither is a fix. The DirtyFrag class probably isn’t finished: any fragment-transfer function that drops the shared-frag flag along the way is a potential new variant, and auditing every such path in the kernel networking stack is a large and unfinished job.

JFrog published a Proof Of Concept video for the exploitation of the flaw.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Linux)

Samsung’s KNOX flaw (CVE-2026-20971) is a kernel UAF in PROCA/FIVE that can enable corruption via a race; Samsung patched it in Jan 2026.

Experts found a nasty kernel flaw in Samsung’s KNOX stack, and the uncomfortable part is where it lived: inside the software designed to raise the bar for attackers. CVE-2026-20971 is a use-after-free in the interaction between PROCA and FIVE, two kernel-side subsystems that help Samsung validate process integrity.

The bug sits in a race. FIVE tracks a process through a task_integrity object, and when a process changes state, such as by forking or calling execve(), the old integrity object gets dropped and a new one takes its place. That handoff should be clean, but Android’s preemptive kernel gives an attacker just enough breathing room to hit the gap. One thread can read a pointer, get suspended, and then come back to use memory that’s already been freed.

That’s the core problem LucidBit Labs describes: 

The target task executes execve(), specifically task_integrity_put(old_tint), freeing the original struct.  The next step is just as bad: “proc_integrity_value_read() resumes and calls task_integrity_user_read() with a pointer to freed memory. 

“While relatively straightforward, the race window is tiny – the process running proc_integrity_value_read() needs to be scheduled out just at the right time (within a window consisting of a couple of opcodes), and be scheduled out for long enough to gain control of the memory.” states the report published by Lucidbit Labs

Once that happens, the bug is no longer a theory. It’s a live UAF with a real corruption path.

Samsung’s KCFI helps, but it doesn’t save the day. It narrows the abuse surface by blocking arbitrary function calls, which is good news, but not enough to kill the flaw. The researchers still found a route by making the process load a file that can’t be executed, a non-ELF file, which removes the reset_file refcount blocker. From there, reallocate the freed memory in a fully controlled manner. That’s the kind of sentence that makes kernel engineers reach for coffee.

This wasn’t an academic stunt. LucidBit Labs says the issue could be triggered from an untrusted app and could lead to kernel memory corruption, which is exactly the sort of foothold attackers love.

“The vulnerability could be exploited from any untrusted app, and allowed attackers to obtain multiple memory corruption primitives, potentially leading to complete device takeover.” continues the report.

Samsung fixed it in the January 2026 update, and the affected range is broad: Galaxy S9 through Galaxy S25, plus A-series devices and both Exynos- and Qualcomm-based models across Android 13, 14, 15, and 16.

Samsung’s own advisory frames the issue as improper input validation in SecSettings before SMR Jan-2026 Release 1, and it notes that local access plus user interaction are required. That sounds less scary until you remember how often “local” really means “one careless tap away” on a device people trust with everything. Lost phones, borrowed phones, unattended phones, sold phones that weren’t fully wiped. The attack surface gets bigger fast.

The more interesting lesson is broader than one Samsung bug. Security controls don’t get a free pass just because they’re labeled defensive. If they sit in the kernel, inspect process state, or mediate trust decisions, they’re part of the attack surface too. Defenders don’t get to assume the guardrail can’t be used as a handhold. That assumption gets expensive.

This case also fits a pattern enterprise defenders know too well. A flaw that starts as a mobile kernel issue can still matter to the business if a staff device is compromised and the attacker uses it as a launch point into the network. Mobile endpoints are always on, usually trusted, and often less watched than laptops. That’s a bad combo. The punchline is simple: patch fast, and don’t treat security tooling as if it’s automatically safe just because it’s called security.

“Modified code, especially one related to complex mechanisms, is always an interesting area to look for vulnerabilities in. FIVE is a part of the Samsung KNOX security suite, and as we saw, protections can increase the attack surface.” concludes the report. “This research also demonstrated common difficulties related to kernel exploitation of race conditions – short race windows combined with the need to reallocate freed memory in a different cache. It also shows how kernel CFI was a highly effective mitigation in this case, practically blocking an arbitrary call primitive. In spite of that, other powerful primitives did exist.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CVE-2026-20971)

AryStinger hijacks outdated routers via old flaws, turning 4,300+ devices into a stealth network for reconnaissance and intrusion support.

On March 12, 2026, QiAnXin’s XLab threat detection system flagged a single IP address, 107.150.106.14, spreading a Linux binary through two vulnerabilities that were disclosed in 2013 and 2016 respectively. The binary had zero detections on VirusTotal. The devices it targeted were routers built on Realtek’s RTL819X chips, hardware that was mainstream between 2012 and 2015 and has received no firmware updates since. XLab named the malware family AryStinger, based on a source code path hint that the project is called Ary-Attack.

The first thing that sets AryStinger apart is what it doesn’t do. It doesn’t encrypt files. It doesn’t mine cryptocurrency.

“Let’s turn the clock back to March 12, 2026, when the XLab Network-wide Threat Awareness System detected IP 107.150.106.14 spreading a VT 0-detection ELF sample implemented in C through the old vulnerabilities CVE-2013-3307 and CVE-2016-5681″ reads the report published by XLab. “Unlike the common practice of exploiting IoT device vulnerabilities to build DDoS or mining botnets, this campaign aims to build an infrastructure cluster for intrusion reconnaissance activities, possessing information-gathering capabilities such as port scanning, service identification, and subdomain enumeration.”

Each infected router becomes what XLab calls an Executor: a node that receives scan tasks, executes them in parallel with other nodes, and ships the results back to the operator, while hiding the attacker’s real location behind a relay layer.

The infection base currently sits at over 4,300 routers worldwide, a figure XLab says is still rising. It covers only RTL819X devices; the NAS infection scale has no measurement yet. The infected pool is dominated by D-Link hardware, with the DIR-850L accounting for roughly 75% of identified devices. By country, South Korea leads at 48%, followed by China at 32%, then Sweden, Malaysia, and Singapore. None of these are countries that stopped manufacturing security tools. They’re just countries with a lot of old routers that nobody replaced.

The researchers found two separate builds of AryStinger. The RTL819X version is written in C and deliberately stripped down, because the old hardware simply can’t run more. It focuses on mass DNS scanning and traffic tunneling, communicates with its C2 over HTTP using Protobuf-encoded traffic obfuscated with XOR encryption using the hardcoded key sh_#@!_2024_secret, and establishes persistence by downloading Dropbear SSH and running it on port 2332.

A second build, written in Go, appeared on April 26 targeting NAS devices through CVE-2025-11837, a code injection vulnerability in QNAP’s Malware Remover that was demonstrated at Pwn2Own Ireland 2025 and patched in November 2025. Whoever is running AryStinger was exploiting it within five months of the patch. That’s a shorter window than most enterprise patch cycles.

The Go build is considerably more capable. It integrates fscan for internal network scanning, ksubdomain and httpx for subdomain and web service reconnaissance, and Tlsx for TLS fingerprinting. Its most flexible feature is ScriptWork, which executes attacker-supplied source code directly on the infected device.

“ScriptWork supports executing Shell commands as well as source-level Payloads in three categories: Go, Java, and Python.” continues the report. “This design greatly enhances the attacker’s operational flexibility: there is no need to compile binary files separately for different platforms, nor to care about the specific architecture of the target device—it only needs to directly issue the source code to dynamically execute it.”

The downside for the attacker is that source code drops to disk in plaintext and interpreter command lines appear in audit logs, making it more detectable than in-memory binary execution.

The distributed task architecture is the operationally clever part.

“The attacker can split a massive scanning task into multiple small chunks and distribute them to different Executors for parallel execution.” continues the report. “With this distributed-like design, the attacker can efficiently complete the early “footprinting” activities, thereby providing strong assurance for the smoothness and success rate of subsequent intrusion operations.”

XLab confirmed this by running a test device and watching the C2 assign a .ba top-level domain brute-force task with an offset value of 11,654,000,000, placing that specific node at roughly 12% into the length-7 subdomain scanning space. The fleet collectively covers the entire space without any single node doing more than its assigned slice.

The hardcoded key sh_#@!_2024_secret contains “2024,” which may indicate the operation started before XLab’s March 2026 detection. That’s a detail that matters: if the infrastructure has been running since 2024, the reconnaissance data it has already collected could be substantial. XLab hasn’t attributed AryStinger to any known threat actor and says the investigation is ongoing.

“Although many mysteries surrounding AryStinger remain to be solved, the mere fact of its targeted attacks against old routers is enough to define it as a real threat not to be underestimated.” continues the report.

“As a key device for daily internet access, once a router is illegally compromised, it will not only threaten personal privacy and property security, but may even endanger national security.” the Ministry of State Security warned. 

The operational pattern, end-of-life routers compromised through n-day vulnerabilities and turned into relay infrastructure for the pre-intrusion phase, matches what Mandiant and others have documented as Operational Relay Box networks, or ORBs, used by state-linked actors.

“Even more concerning is that this malicious sample and its associated C2 servers have an extremely low detection rate in mainstream security engines.” states the report. “It is precisely in view of the compounded risk of this “low detection rate” and “high potential harm” that we decided to write this article and share our research findings with the security community, in the hope of jointly addressing potential risks and safeguarding overall network security.”

Whether AryStinger is state-sponsored or criminal infrastructure being sold as initial access capability, the model is the same: forgotten hardware, ancient CVEs, quiet and hard to detect.

The remediation guidance is straightforward. Check for outbound connections to AryStinger’s C2 and download infrastructure, primarily ajb8.com, dataexplore.cc, and dataexplore.co hostnames. Check /tmp/bin for binaries you didn’t put there. Look for processes named syswapd0h or syswapd0w. The lasting fix is the one that never gets implemented fast enough: retire hardware that stopped receiving firmware updates years ago. A router running code from 2015 is not a network security device. It’s a vulnerability with an ethernet port.

“Once compromised by malware like AryStinger that possesses reconnaissance and covert control capabilities, it is equivalent to a hacker placing a permanent “invisible listening device” and “attack springboard” within your network.” concludes the report. “There is no doubt that when a large number of old devices are gradually compromised and aggregated, ultimately forming a massive covert botnet, this will pose a continuous, covert, and highly destructive real threat to personal privacy, enterprise security, and even national critical network infrastructure.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)

F5 released emergency updates for critical NGINX flaws (CVE-2026-42530, CVE-2026-42055) that could enable unauthenticated code execution.

F5 has issued out-of-band patches for multiple NGINX vulnerabilities, including two critical flaws, respectively tracked as CVE-2026-42530 and CVE-2026-42055 (CVSS 9.2). The bugs affect HTTP modules and can be exploited remotely without authentication to trigger memory corruption, potentially causing service restarts or enabling arbitrary code execution.

The flaw CVE-2026-42530 (CVSS score of 9.2) is a critical Use-After-Free vulnerability in the ngx_http_v3_module of NGINX Open Source. When HTTP/3 QUIC support is enabled, a remote unauthenticated attacker can exploit a specially crafted HTTP/3 session to reopen a QPACK encoder stream, causing memory corruption in the NGINX worker process. Successful exploitation may lead to service disruption and worker process restarts, and under certain conditions, such as when ASLR is disabled or bypassed, could allow arbitrary code execution.

“NGINX Open Source has a vulnerability in the ngx_http_v3_module module. When NGINX Open Source is configured to use the HTTP/3 QUIC module, a remote unauthenticated attacker along with conditions beyond their control can use a specially crafted HTTP/3 session to reopen a QPACK encoder stream. This may cause a Use-After-Free in the NGINX worker process, leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. (CVE-2026-42530)” reads the advisory. “This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only.”

The second flaw, tracked as CVE-2026-42055 (CVSS score of 9.2), is a critical heap-based buffer overflow vulnerability affecting the ngx_http_proxy_v2_module and ngx_http_grpc_module in NGINX Open Source and Plus. Under specific configurations involving HTTP/2 proxying, disabled header validation, and large header buffers, a remote unauthenticated attacker can send specially crafted oversized headers to trigger memory corruption in the worker process. Successful exploitation may cause service disruption and worker process restarts, and in environments where ASLR is disabled or bypassed, could potentially lead to arbitrary code execution.

“This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution; however, exploitation requires non-default configuration to be present.” states the advisory.

The vulnerability can lead to DoS or potential code execution, but only in non-default configurations. Exploitation requires HTTP/2 proxying, disabled header validation, and unusually large header buffers. Default deployments are not affected, and the issue impacts only the data plane, not the control plane.

F5 has released security updates for NGINX Plus, NGINX Open Source, and NGINX Gateway Fabric to fix the recently disclosed vulnerabilities.

The company also addressed two high-severity vulnerabilities, tracked as CVE-2026-11311 and CVE-2026-50107, in NGINX Gateway Fabric that could allow authenticated attackers to inject arbitrary NGINX configuration directives.

At this time, there is no news of attacks in the wild exploiting one of the vulnerabilities.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, F5)