Kohler is facing backlash after an engineer pointed out that the company’s new smart toilet cameras may not be as private as it wants people to believe. The discussion raises questions about Kohler’s use of the term “end-to-end encryption” (E2EE) and the inherent privacy limitations of a device that films the goings-on of a toilet bowl.
In October, Kohler announced its first “health” product, the Dekoda. Kohler’s announcement described the $599 device (it also requires a subscription that starts at $7 per month) as a toilet bowl attachment that uses “optical sensors and validated machine-learning algorithms” to deliver “valuable insights into your health and wellness.” The announcement added:
Data flows to the personalized Kohler Health app, giving users continuous, private awareness of key health and wellness indicators—right on their phone. Features like fingerprint authentication and end-to-end encryption are designed for user privacy and security.
The average person is most likely to be familiar with E2EE through messaging apps, like Signal. Messages sent via apps with E2EE are encrypted throughout transmission. Only the message’s sender and recipient can view the decrypted messages, which is intended to prevent third parties, including the app developer, from reading them.
An anonymous reader quotes a report from TechCrunch: Earlier this year, home goods maker Kohler launched a smart camera called the Dekoda that attaches to your toilet bowl, takes pictures of it, and analyzes the images to advise you on your gut health. Anticipating privacy fears, Kohler said on its website that the Dekoda's sensors only see down into the toilet, and claimed that all data is secured with "end-to-end encryption." The company's use of the expression "end-to-end encryption" is, however, wrong, as security researcher Simon Fondrie-Teitler pointed out in a blog post on Tuesday. By reading Kohler's privacy policy, it's clear that the company is referring to the type of encryption that secures data as it travels over the internet, known as TLS encryption -- the same that powers HTTPS websites. [...] The security researcher also pointed out that given Kohler can access customers' data on its servers, it's possible Kohler is using customers' bowl pictures to train AI. Citing another response from the company representative, the researcher was told that Kohler's "algorithms are trained on de-identified data only." A "privacy contact" from Kohler said that user data is "encrypted at rest, when it's stored on the user's mobile phone, toilet attachment, and on our systems." The company also said that, "data in transit is also encrypted end-to-end, as it travels between the user's devices and our systems, where it is decrypted and processed to provide our service."
Organizations are spending more than ever on cybersecurity, layering defenses around networks, endpoints, and applications. Yet a company’s documents, one of the most fundamental business assets, remains an overlooked weak spot. Documents flow across every department, cross company boundaries, and often contain the very data that compliance officers and security teams work hardest to protect...
Learn how to implement granular access control policies in post-quantum AI environments to protect against advanced threats. Discover strategies for securing Model Context Protocol deployments with quantum-resistant encryption and context-aware access management.
Data residency is no longer enough. As governments lose faith that storing data within their borders, but on someone else’s servers, provides real sovereignty, regulators are demanding something more fundamental: control over the encryption keys for their data.
Privatim, a collective of Swiss local government data protection officers, last week called on their employers to avoid the use of international software-as-a-service solutions for sensitive government data unless the agencies themselves implement end-to-end encryption. The resolution specifically cited Microsoft 365 as an example of the kinds of platforms that fall short.
“Most SaaS solutions do not yet offer true end-to-end encryption that would prevent the provider from accessing plaintext data,” said the Swiss data protection officers’ resolution. “The use of SaaS applications therefore entails a significant loss of control.”
Security analysts say this loss of control undermines the very concept of data sovereignty. “When a cloud provider has any ability to decrypt customer data, either through legal process or internal mechanisms, the data is no longer truly sovereign,” said Sanchit Vir Gogia, chief analyst at Greyhound Research.
The Swiss position isn’t isolated, Gogia said. Across Europe, Germany, France, Denmark and the European Commission have each issued warnings or taken action, pointing to a loss of faith in the neutrality of foreign-owned hyperscalers, he said. “Switzerland distinguished itself by stating explicitly what others have implied: that the US CLOUD Act and foreign surveillance risk renders cloud solutions lacking end-to-end encryption unsuitable for high-sensitivity public sector use, according to the resolution.”
Encryption, location, location
Privatim’s resolution identified risks that geographic data residency cannot address. Globally operating companies offer insufficient transparency for authorities to verify compliance with contractual obligations, the group said. This opacity extends to technical implementations, change management, and monitoring of employees and subcontractors who can form long chains of external service providers.
Data stored in one jurisdiction can still be accessed by foreign governments under extraterritorial laws like the US Clarifying Lawful Overseas Use of Data (CLOUD) Act, said Ashish Banerjee, senior principal analyst at Gartner. Software providers can also unilaterally amend contract terms periodically, further reducing customer control, he said.
“Several clients in the Middle East and Europe have raised concerns that, regardless of where their data is stored, it could still be accessed by cloud providers — most of which are US-based,” Banerjee said.
Prabhjyot Kaur, senior analyst at Everest Group, said the Swiss stance accelerates a broader regulatory pivot toward technical sovereignty controls. “While the Swiss position is more stringent than most, it is not an isolated outlier,” she said. “It accelerates a broader regulatory pivot toward technical sovereignty controls, even in markets that still rely on contractual or procedural safeguards today.”
Given these limitations, Privatim called for stricter rules on cloud use at all levels of government: “The use of international SaaS solutions for particularly sensitive personal data or data subject to legal confidentiality obligations by public bodies is only possible if the data is encrypted by the responsible body itself and the cloud provider has no access to the key.”
This represents a departure from current practices, where many government bodies rely on cloud providers’ native encryption features. Services like Microsoft 365 offer encryption at rest and in transit, but Microsoft retains the ability to decrypt that data for operational purposes, compliance requirements, or legal requests.
More security, less insight
Customer-controlled end-to-end encryption comes with significant trade-offs, analysts said.
“When the provider has zero visibility into plaintext, governments would face reduced search and indexing capabilities, limited collaboration features, and restrictions on automated threat detection and data loss prevention tooling,” said Kaur. “AI-driven productivity enhancements like copilots also rely on provider-side processing, which becomes impossible under strict end-to-end encryption.”
Beyond functionality losses, agencies would face significant infrastructure and cost challenges. They would need to operate their own key management systems, introducing governance overhead and staffing needs. Encryption and decryption at scale can impact system performance, as they require additional hardware resources and increase latency, Banerjee said.
“This might require additional hardware resources, increased latency in user interactions, and a more expensive overall solution,” he said.
These constraints mean most governments will likely adopt a tiered approach rather than blanket encryption, said Gogia. “Highly confidential content, including classified documents, legal investigations, and state security dossiers, can be wrapped in true end-to-end encryption and segregated into specialized tenants or sovereign environments,” he said. Broader government operations, including administrative records and citizen services, will continue to use mainstream cloud platforms with controlled encryption and enhanced auditability.
A shift in cloud computing power
If the Swiss approach gains momentum internationally, hyperscalers will need to strengthen technical sovereignty controls rather than relying primarily on contractual or regional assurances, Kaur said. “The required adaptations are already visible, particularly from Microsoft, which has begun rolling out more stringent models around customer-controlled encryption and jurisdictional access restrictions.”
The shift challenges fundamental assumptions in how cloud providers have approached government customers, according to Gogia. “This invalidates large portions of the existing government cloud playbooks that depend on data center residency, regional support, and contractual segmentation as the primary guarantees,” he said. “Client-side encryption, confidential computing, and external key management are no longer optional capabilities but baseline requirements for public sector contracts in high-compliance markets.”
The market dynamics could shift significantly as a result. Banerjee said this could create a two-tier structure: global cloud services for commercial customers less concerned about sovereignty, and premium sovereign clouds for governments demanding full control. “Non-US cloud providers and local vendors — such as emerging players in Europe — could gain market share by delivering sovereign solutions that meet strict encryption requirements,” he said.
Privatim’s recommendations apply specifically to Swiss public bodies and serve as guidance rather than binding policy. But the debate signals that data location alone may no longer satisfy regulators’ sovereignty concerns in an era where geopolitical rivalries are increasingly playing out through technology policy.
An anonymous reader shared this report from the Associated Press:
The information needed to decipher the last remaining unsolved secret message embedded within a sculpture at CIA headquarters in Virginia sold at auction for nearly $1 million, the auction house announced Friday. The winner will get a private meeting with the 80-year-old artist to go over the codes and charts in hopes of continuing what he's been doing for decades: interacting with would-be cryptanalyst sleuths.
The archive owned by the artist who created Kryptos, Jim Sanborn, was sold to an anonymous bidder for $963,000, according to RR Auction of Boston. The archive includes documents and coding charts for the sculpture, dedicated in 1990. Three of the messages on the 10-foot-tall (3-meter) sculpture — known as K1, K2 and K3 — have been solved, but a solution for the fourth, K-4, has frustrated the experts and enthusiasts who have tried to decipher the S-shaped copper screen... One side has a series of staggered alphabets that are key to decoding the four encrypted messages on the other side.
"The purchaser's 'long-term stewardship plan' is being developed, according to the auction house."
BitLocker is the most common way to encrypt your Windows PC to protect it against data theft in the event that someone steals your PC, but it isn't the only option. If your PC doesn't have BitLocker and you want something more fully-featured than Device Encryption, VeraCrypt is probably the tool for you.
An anonymous reader shares a report: CISA has warned that state-backed snoops and cyber-mercenaries are actively abusing commercial spyware to break into Signal and WhatsApp accounts, hijack devices, and quietly rummage through the phones of what the agency calls "high-value" users.
In an alert published Monday, the US government's cyber agency said it's tracking multiple miscreants that are using a mix of phishing, bogus QR codes, malicious app impersonation, and, in some cases, full-blown zero-click exploits to compromise messaging apps which most people assume are safe.
The agency says the activity it's seeing suggests an increasing focus on "high-value" individuals -- everyone from current and former senior government, military, and political officials to civil society groups across the US, the Middle East, and Europe. In many of the campaigns, attackers delivered spyware first and asked questions later, using the foothold to deploy more payloads and deepen their access.
Sturnus, an advanced Android banking trojan, has been discovered by ThreatFabric. Learn how this malware bypasses end-to-end encryption on Signal and WhatsApp, steals bank credentials using fake screens, and executes fraudulent transactions.
Tsundere is a new botnet, discovered by our Kaspersky GReAT around mid-2025. We have correlated this threat with previous reports from October 2024 that reveal code similarities, as well as the use of the same C2 retrieval method and wallet. In that instance, the threat actor created malicious Node.js packages and used the Node Package Manager (npm) to deliver the payload. The packages were named similarly to popular packages, employing a technique known as typosquatting. The threat actor targeted libraries such as Puppeteer, Bignum.js, and various cryptocurrency packages, resulting in 287 identified malware packages. This supply chain attack affected Windows, Linux, and macOS users, but it was short-lived, as the packages were removed and the threat actor abandoned this infection method after being detected.
The threat actor resurfaced around July 2025 with a new threat. We have dubbed it the Tsundere bot after its C2 panel. This botnet is currently expanding and poses an active threat to Windows users.
Initial infection
Currently, there is no conclusive evidence on how the Tsundere bot implants are being spread. However, in one documented case, the implant was installed via a Remote Monitoring and Management (RMM) tool, which downloaded a file named pdf.msi from a compromised website. In other instances, the sample names suggest that the implants are being disseminated using the lure of popular Windows games, particularly first-person shooters. The samples found in the wild have names such as “valorant”, “cs2”, or “r6x”, which appear to be attempts to capitalize on the popularity of these games among piracy communities.
Malware implants
According to the C2 panel, there are two distinct formats for spreading the implant: via an MSI installer and via a PowerShell script. Implants are automatically generated by the C2 panel (as described in the Infrastructure section).
MSI installer
The MSI installer was often disguised as a fake installer for popular games and other software to lure new victims. Notably, at the time of our research, it had a very low detection rate.
The installer contains a list of data and JavaScript files that are updated with each new build, as well as the necessary Node.js executables to run these scripts. The following is a list of files included in the sample:
The last three files in the list are legitimate Node.js files. They are installed alongside the malicious artifacts in the user’s AppData\Local\nodejs directory.
An examination of the CustomAction table reveals the process by which Windows Installer executes the malware and installs the Tsundere bot:
This will execute Node.js code that spawns a new Node.js process, which runs the loader JavaScript code (in this case, B4jHWzJnlABB2B7). The resulting child process runs in the background, remaining hidden from the user.
Loader script
The loader script is responsible for ensuring the correct decryption and execution of the main bot script, which handles npm unpackaging and configuration. Although the loader code, similar to the code for the other JavaScript files, is obfuscated, it can be deobfuscated using open-source tools. Once executed, the loader attempts to locate the unpackaging script and configuration for the Tsundere bot, decrypts them using the AES-256 CBC cryptographic algorithm with a build-specific key and IV, and saves the decrypted files under different filenames.
The configuration file is a JSON that defines a directory and file structure, as well as file contents, which the malware will recreate. The malware author refers to this file as “config”, but its primary purpose is to package and deploy the Node.js package manager (npm) without requiring manual installation or downloading. The unpackaging script is responsible for recreating this structure, including the node_modules directory with all its libraries, which contains packages necessary for the malware to run.
With the environment now set up, the malware proceeds to install three packages to the node_modules directory using npm:
ws: a WebSocket networking library
ethers: a library for communicating with Ethereum
pm2: a Node.js process management tool
Loader script installing the necessary toolset for Tsundere persistence and execution
The pm2 package is installed to ensure the Tsundere bot remains active and used to launch the bot. Additionally, pm2 helps achieve persistence on the system by writing to the registry and configuring itself to restart the process upon login.
PowerShell infector
The PowerShell version of the infector operates in a more compact and simplified manner. Instead of utilizing a configuration file and an unpacker — as done with the MSI installer — it downloads the ZIP file node-v18.17.0-win-x64.zip from the official Node.js website nodejs[.]org and extracts it to the AppData\Local\NodeJS directory, ultimately deploying Node.js on the targeted device. The infector then uses the AES-256-CBC algorithm to decrypt two large hexadecimal-encoded variables, which correspond to the bot script and a persistence script. These decrypted files, along with a package.json file are written to the disk. The package.json file contains information about the malicious Node.js package, as well as the necessary libraries to be installed, including the ws and ethers packages. Finally, the infector runs both scripts, starting with the persistence script that is followed by the bot script.
The PowerShell infector creates a package file with the implant dependencies
Persistence is achieved through the same mechanism observed in the MSI installer: the script creates a value in the HKCU:\Software\Microsoft\Windows\CurrentVersion\Run registry key that points to itself. It then overwrites itself with a new script that is Base64 decoded. This new script is responsible for ensuring the bot is executed on each login by spawning a new instance of the bot.
Tsundere bot
We will now delve into the Tsundere bot, examining its communication with the command-and-control (C2) server and its primary functionality.
C2 address retrieval
Web3 contracts, also known as smart contracts, are deployed on a blockchain via transactions from a wallet. These contracts can store data in variables, which can be modified by functions defined within the contract. In this case, the Tsundere botnet utilizes the Ethereum blockchain, where a method named setString(string _str) is defined to modify the state variable param1, allowing it to store a string. The string stored in param1 is used by the Tsundere botnet administrators to store new WebSocket C2 servers, which can be rotated at will and are immutable once written to the Ethereum blockchain.
The Tsundere botnet relies on two constant points of reference on the Ethereum blockchain:
In order to change the C2 server, the Tsundere botnet makes a transaction to update the state variable with a new address. Below is a transaction made on August 19, 2025, with a value of 0 ETH, which updates the address.
Smart contract containing the Tsundere botnet WebSocket C2
The state variable has a fixed length of 32 bytes, and a string of 24 bytes (see item [2] in the previous image) is stored within it. When this string is converted from hexadecimal to ASCII, it reveals the new WebSocket C2 server address: ws[:]//185.28.119[.]179:1234.
To obtain the C2 address, the bot contacts various public endpoints that provide remote procedure call (RPC) APIs, allowing them to interact with Ethereum blockchain nodes. At the start of the script, the bot calls a function named fetchAndUpdateIP, which iterates through a list of RPC providers. For each provider, it checks the transactions associated with the contract address and wallet owner, and then retrieves the string from the state variable containing the WebSocket address, as previously observed.
Malware code for retrieval of C2 from the smart contract
The Tsundere bot verifies that the C2 address starts with either ws:// or wss:// to ensure it is a valid WebSocket URL, and then sets the obtained string as the server URL. But before using this new URL, the bot first checks the system locale by retrieving the culture name of the machine to avoid infecting systems in the CIS region. If the system is not in the CIS region, the bot establishes a connection to the server via a WebSocket, setting up the necessary handlers for receiving, sending, and managing connection states, such as errors and closed sockets.
Bot handlers for communication
Communication
The communication flow between the client (Tsundere bot) and the server (WebSocket C2) is as follows:
The Tsundere bot establishes a WebSocket connection with the retrieved C2 address.
An AES key is transmitted immediately after the connection is established.
The bot sends an empty string to confirm receipt of the key.
The server then sends an IV, enabling the use of encrypted communication from that point on.
Encryption is required for all subsequent communication.
The bot transmits the OS information of the infected machine, including the MAC address, total memory, GPU information, and other details. This information is also used to generate a unique identifier (UUID).
The C2 server responds with a JSON object, acknowledging the connection and confirming the bot’s presence.
With the connection established, the client and server can exchange information freely.
To maintain the connection, keep-alive messages are sent every minute using ping/pong messages.
The bot sends encrypted responses as part of the ping/pong messages, ensuring continuous communication.
Tsundere communication process with the C2 via WebSockets
The connections are not authenticated through any additional means, making it possible for a fake client to establish a connection.
As previously mentioned, the client sends an encrypted ping message to the C2 server every minute, which returns a pong message. This ping-pong exchange serves as a mechanism for the C2 panel to maintain a list of currently active bots.
Functionality
The Tsundere bot is designed to allow the C2 server to send dynamic JavaScript code. When the C2 server sends a message with ID=1 to the bot, the message is evaluated as a new function and then executed. The result of this operation is sent back to the server via a custom function named serverSend, which is responsible for transmitting the result as a JSON object, encrypted for secure communication.
Tsundere bot evaluation code once functions are received from the C2
The ability to evaluate code makes the Tsundere bot relatively simple, but it also provides flexibility and dynamism, allowing the botnet administrators to adapt it to a wide range of actions.
However, during our observation period, we did not receive any commands or functions from the C2 server, possibly because the newly connected bot needed to be requested by other threat actors through the botnet panel before it could be utilized.
Infrastructure
The Tsundere bot utilizes WebSocket as its primary protocol for establishing connections with the C2 server. As mentioned earlier, at the time of writing, the malware was communicating with the WebSocket server located at 185.28.119[.]179, and our tests indicated that it was responding positively to bot connections.
The following table lists the IP addresses and ports extracted from the provided list of URLs:
IP
Port
First seen (contract update)
ASN
185.28.119[.]179
1234
2025-08-19
AS62005
196.251.72[.]192
1234
2025-08-03
AS401120
103.246.145[.]201
1234
2025-07-14
AS211381
193.24.123[.]68
3011
2025-06-21
AS200593
62.60.226[.]179
3001
2025-05-04
AS214351
Marketplace and control panel
No business is complete without a marketplace, and similarly, no botnet is complete without a control panel. The Tsundere botnet has both a marketplace and a control panel, which are integrated into the same frontend.
Tsundere botnet panel login
The notable aspect of Tsundere’s control panel, dubbed “Tsundere Netto” (version 2.4.4), is that it has an open registration system. Any user who accesses the login form can register and gain access to the panel, which features various tabs:
Bots: a dashboard displaying the number of bots under the user’s control
Settings: user settings and administrative functions
Build: if the user has an active license, they can create new bots using the two previously mentioned methodologies (MSI or PowerShell)
Market: this is the most interesting aspect of the panel, as it allows users to promote their individual bots and offer various services and functionalities to other threat actors. Each build can create a bot that performs a specific set of actions, which can then be offered to others
Monero wallet: a wallet service that enables users to make deposits or withdrawals
Socks proxy: a feature that allows users to utilize their bots as proxies for their traffic
Tsundere botnet control panel, building system and market
Each build generates a unique build ID, which is embedded in the implant and sent to the C2 server upon infection. This build ID can be linked to the user who created it. According to our research and analysis of other URLs found in the wild, builds are created through the panel and can be downloaded via the URL:
At the time of writing this, the panel typically has between 90 and 115 bots connected to the C2 server at any given time.
Attribution
Based on the text found in the implants, we can conclude with high confidence that the threat actor behind the Tsundere botnet is likely Russian-speaking. The use of the Russian language in the implants is consistent with previous attacks attributed to the same threat actor.
Russian being used throughout the code
Furthermore, our analysis suggests a connection between the Tsundere botnet and the 123 Stealer, a C++-based stealer available on the shadow market for $120 per month. This connection is based on the fact that both panels share the same server. Notably, the main domain serves as the frontend for the 123 Stealer panel, while the subdomain “idk.” is used for the Tsundere botnet panel.
123 Stealer C2 panel sharing Tsundere’s infrastructure and showcasing its author
By examining the available evidence, we can link both threats to a Russian-speaking threat actor known as “koneko”. Koneko was previously active on a dark web forum, where they promoted the 123 Stealer, as well as other malware, including a backdoor. Although our analysis of the backdoor revealed that it was not directly related to Tsundere, it shared similarities with the Tsundere botnet in that it was written in Node.js and used PowerShell or MSI as infectors. Before the dark web forum was seized and shut down, koneko’s profile featured the title “node malware senior”, further suggesting their expertise in Node.js-based malware.
Conclusion
The Tsundere botnet represents a renewed effort by a presumably identified threat actor to revamp their toolset. The Node.js-based bot is an evolution of an attack discovered in October of last year, and it now features a new strategy and even a new business model. Infections can occur through MSI and PowerShell files, which provides flexibility in terms of disguising installers, using phishing as a point of entry, or integrating with other attack mechanisms, making it an even more formidable threat.
Additionally, the botnet leverages a technique that is gaining popularity: utilizing web3 contracts, also known as “smart contracts”, to host command-and-control (C2) addresses, which enhances the resilience of the botnet infrastructure. The botnet’s possible author, koneko, is also involved in peddling other threats, such as the 123 Stealer, which suggests that the threat is likely to escalate rather than diminish in the coming months. As a result, it is essential to closely monitor this threat and be vigilant for related threats that may emerge in the near future.
Cryptocurrency wallets Note: These are wallets that have changed the C2 address in the smart contract since it was created.
0x73625B6cdFECC81A4899D221C732E1f73e504a32
0x10ca9bE67D03917e9938a7c28601663B191E4413
0xEc99D2C797Db6E0eBD664128EfED9265fBE54579
0xf11Cb0578EA61e2EDB8a4a12c02E3eF26E80fc36
0xdb8e8B0ef3ea1105A6D84b27Fc0bAA9845C66FD7
0x10ca9bE67D03917e9938a7c28601663B191E4413
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0x46b0f9bA6F1fb89eb80347c92c9e91BDF1b9E8CC
Austrian researchers used a WhatsApp contact-lookup flaw to map 3.5 billion phone numbers, revealing how basic metadata can build a directory of accounts.
Austrian researchers used a WhatsApp contact-lookup flaw to map 3.5 billion phone numbers, revealing how basic metadata can build a directory of accounts.
Back in 2024, we gave a brief description of a complex cyberespionage campaign that we dubbed “PassiveNeuron”. This campaign involved compromising the servers of government organizations with previously unknown APT implants, named “Neursite” and “NeuralExecutor”. However, since its discovery, the PassiveNeuron campaign has been shrouded in mystery. For instance, it remained unclear how the implants in question were deployed or what actor was behind them.
After we detected this campaign and prevented its spreading back in June 2024, we did not see any further malware deployments linked to PassiveNeuron for quite a long time, about six months. However, since December 2024, we have observed a new wave of infections related to PassiveNeuron, with the latest ones dating back to August 2025. These infections targeted government, financial and industrial organizations located in Asia, Africa, and Latin America. Since identifying these infections, we have been able to shed light on many previously unknown aspects of this campaign. Thus, we managed to discover details about the initial infection and gather clues on attribution.
While investigating PassiveNeuron infections both in 2024 and 2025, we found that a vast majority of targeted machines were running Windows Server. Specifically, in one particular infection case, we observed attackers gain initial remote command execution capabilities on the compromised server through the Microsoft SQL software. While we do not have clear visibility into how attackers were able to abuse the SQL software, it is worth noting that SQL servers typically get compromised through:
Exploitation of vulnerabilities in the server software itself
Exploitation of SQL injection vulnerabilities present in the applications running on the server
Getting access to the database administration account (e.g. by brute-forcing the password) and using it to execute malicious SQL queries
After obtaining the code execution capabilities with the help of the SQL software, attackers deployed an ASPX web shell for basic malicious command execution on the compromised machine. However, at this stage, things did not go as planned for the adversary. The Kaspersky solution installed on the machine was preventing the web shell deployment efforts, and the process of installing the web shell ended up being quite noisy.
In attempts to evade detection of the web shell, attackers performed its installation in the following manner:
They dropped a file containing the Base64-encoded web shell on the system.
They dropped a PowerShell script responsible for Base64-decoding the web shell file.
They launched the PowerShell script in an attempt to write the decoded web shell payload to the filesystem.
As Kaspersky solutions were preventing the web shell installation, we observed attackers to repeat the steps above several times with minor adjustments, such as:
Using hexadecimal encoding of the web shell instead of Base64
Using a VBS script instead of a PowerShell script to perform decoding
Writing the script contents in a line-by-line manner
Having failed to deploy the web shell, attackers decided to use more advanced malicious implants to continue the compromise process.
Malicious implants
Over the last two years, we have observed three implants used over the course of PassiveNeuron infections, which are:
Neursite, a custom C++ modular backdoor used for cyberespionage activities
NeuralExecutor, a custom .NET implant used for running additional .NET payloads
the Cobalt Strike framework, a commercial tool for red teaming
While we saw different combinations of these implants deployed on targeted machines, we observed that in the vast majority of cases, they were loaded through a chain of DLL loaders. The first-stage loader in the chain is a DLL file placed in the system directory. Some of these DLL file paths are:
C:\Windows\System32\wlbsctrl.dll
C:\Windows\System32\TSMSISrv.dll
C:\Windows\System32\oci.dll
Storing DLLs under these paths has been beneficial to attackers, as placing libraries with these names inside the System32 folder makes it possible to automatically ensure persistence. If present on the file system, these DLLs get automatically loaded on startup (the first two DLLs are loaded into the svchost.exe process, while the latter is loaded into msdtc.exe) due to the employed Phantom DLL Hijacking technique.
It also should be noted that these DLLs are more than 100 MB in size — their size is artificially inflated by attackers by adding junk overlay bytes. Usually, this is done to make malicious implants more difficult to detect by security solutions.
On startup, the first-stage DLLs iterate through a list of installed network adapters, calculating a 32-bit hash of each adapter’s MAC address. If neither of the MAC addresses is equal to the value specified in the loader configuration, the loader exits. This MAC address check is designed to ensure that the DLLs get solely launched on the intended victim machine, in order to hinder execution in a sandbox environment. Such detailed narrowing down of victims implies the adversary’s interest towards specific organizations and once again underscores the targeted nature of this threat.
Having checked that it is operating on a target machine, the loader continues execution by loading a second-stage loader DLL that is stored on disk. The paths where the second-stage DLLs were stored as well as their names (examples include elscorewmyc.dll and wellgwlserejzuai.dll) differed between machines. We observed the second-stage DLLs to also have an artificially inflated file size (in excess of 60 MB), and the malicious goal was to open a text file containing a Base64-encoded and AES-encrypted third-stage loader, and subsequently launch it.
Snippet of the payload file contents
This payload is a DLL as well, responsible for launching a fourth-stage shellcode loader inside another process (e.g. WmiPrvSE.exe or msiexec.exe) which is created in suspended mode. In turn, this shellcode loads the final payload: a PE file converted to a custom executable format.
In summary, the process of loading the final payload can be represented with the following graph:
Final payload loading
It is also notable that attackers attempted to use slightly different variants of the loading scheme for some of the target organizations. For example, we have seen cases without payload injection into another process, or with DLL obfuscation on disk with VMProtect.
The Neursite backdoor
Among the three final payload implants that we mentioned above, the Neursite backdoor is the most potent one. We dubbed it so because we observed the following source code path inside the discovered samples: E:\pro\code\Neursite\client_server\nonspec\mbedtls\library\ssl_srv.c. The configuration of this implant contains the following parameters:
List of C2 servers and their ports
List of HTTP proxies that can be used to connect to C2 servers
List of HTTP headers used while connecting to HTTP-based C2 servers
A relative URL used while communicating with HTTP-based C2 servers
A range of wait time between two consecutive C2 server connections
A byte array of hours and days of the week when the backdoor is operable
An optional port that should be opened for listening to incoming connections
The Neursite implant can use the TCP, SSL, HTTP and HTTPS protocols for C2 communications. As follows from the configuration, Neursite can connect to the C2 server directly or wait for another machine to start communicating through a specified port. In cases we observed, Neursite samples were configured to use either external servers or compromised internal infrastructure for C2 communications.
The default range of commands implemented inside this backdoor allows attackers to:
Retrieve system information.
Manage running processes.
Proxy traffic through other machines infected with the Neursite implant, in order to facilitate lateral movement.
Additionally, this implant is equipped with a component that allows loading supplementary plugins. We observed attackers deploy plugins with the following capabilities:
Shell command execution
File system management
TCP socket operations
The NeuralExecutor loader
NeuralExecutor is another custom implant deployed over the course of the PassiveNeuron campaign. This implant is .NET based, and we found that it employed the open-source ConfuserEx obfuscator for protection against analysis. It implements multiple methods of network communication, namely TCP, HTTP/HTTPS, named pipes, and WebSockets. Upon establishing a communication channel with the C2 server, the backdoor can receive commands allowing it to load .NET assemblies. As such, the main capability of this backdoor is to receive additional .NET payloads from the network and execute them.
Tricky attribution
Both Neursite and NeuralExecutor, the two custom implants we found to be used in the PassiveNeuron campaign, have never been observed in any previous cyberattacks. We had to look for clues that could hint at the threat actor behind PassiveNeuron.
Back when we started investigating PassiveNeuron back in 2024, we spotted one such blatantly obvious clue:
Function names found inside NeuralExecutor
In the code of the NeuralExecutor samples we observed in 2024, the names of all functions had been replaced with strings prefixed with “Супер обфускатор”, the Russian for “Super obfuscator”. It is important to note, however, that this string was deliberately introduced by the attackers while using the ConfuserEx obfuscator. When it comes to strings that are inserted into malware on purpose, they should be assessed carefully during attribution. That is because threat actors may insert strings in languages they do not speak, in order to create false flags intended to confuse researchers and incident responders and prompt them to make an error of judgement when trying to attribute the threat. For that reason, we attached little evidential weight to the presence of the “Супер обфускатор” string back in 2024.
After examining the NeuralExecutor samples used in 2025, we found that the Russian-language string had disappeared. However, this year we noticed another peculiar clue related to this implant. While the 2024 samples were designed to retrieve the C2 server addresses straight from the configuration, the 2025 ones did so by using the Dead Drop Resolver technique. Specifically, the new NeuralExecutor samples that we found were designed to retrieve the contents of a file stored in a GitHub repository, and extract a string from it:
Contents of the configuration file stored on GitHub
The malware locates this string by searching for two delimiters, wtyyvZQY and stU7BU0R, that mark the start and the end of the configuration data. The bytes of this string are then Base64-decoded and decrypted with AES to obtain the C2 server address.
Snippet of the implant configuration
It is notable that this exact method of obtaining C2 server addresses from GitHub, using a string containing delimiter sequences, is quite popular among Chinese-speaking threat actors. For instance, we frequently observed it being used in the EastWind campaign, which we previously connected to the APT31 and APT27 Chinese-speaking threat actors.
Furthermore, during our investigation, we learned one more interesting fact that could be useful in attribution. We observed numerous attempts to deploy the PassiveNeuron loader in one particular organization. After discovering yet another failed deployment, we have detected a malicious DLL named imjp14k.dll. An analysis of this DLL revealed that it had the PDB path G:\Bee\Tree(pmrc)\Src\Dll_3F_imjp14k\Release\Dll.pdb. This PDB string was referenced in a report by Cisco Talos on activities likely associated with the threat actor APT41. Moreover, we identified that the discovered DLL exhibits the same malicious behavior as described in the Cisco Talos report. However, it remains unclear why this DLL was uploaded to the target machine. Possible explanations could be that the attackers deployed it as a replacement for the PassiveNeuron-related implants, or that it was used by another actor who compromised the organization simultaneously with the attackers behind PassiveNeuron.
When dealing with attribution of cyberattacks that are known to involve false flags, it is difficult to understand which attribution indicators to trust, or whether to trust any at all. However, the overall TTPs of the PassiveNeuron campaign most resemble the ones commonly employed by Chinese-speaking threat actors. Since TTPs are usually harder to fake than indicators like strings, we are, as of now, attributing the PassiveNeuron campaign to a Chinese-speaking threat actor, albeit with a low level of confidence.
Conclusion
The PassiveNeuron campaign has been distinctive in the way that it primarily targets server machines. These servers, especially the ones exposed to the internet, are usually lucrative targets for APTs, as they can serve as entry points into target organizations. It is thus crucial to pay close attention to the protection of server machines. Wherever possible, the attack surface associated with these servers should be reduced to a minimum, and all server applications should be monitored to prevent emerging infections in a timely manner. Specific attention should be paid to protecting applications against SQL injections, which are commonly exploited by threat actors to obtain initial access. Another thing to focus on is protection against web shells, which are deployed to facilitate compromise of servers.
Cryptography is a fundamental skill to cybersecurity!
Cryptography is what keeps our systems and data secure. Without it, all of our information is at risk.
This class to designed to give you a strong background in cryptography further enhancing you knowledge and skill in this key field making you even more valuable in the cybersecurity marketplace.
With quantum computing and quantum cryptography emerging on the near-term horizon, a strong background in cryptography will help your organization prepare and keep your data secure.
If you are a cybersecurity professional or manager, you will want to attend this training!
1. Foundations & Mathematical Background
Probabilistic and computational security
Number theory basics (modular arithmetic, cyclic groups)
Login
