Google has expanded its Cloud Vulnerability Reward Program (VRP) with a new top-tier reward for high-impact architectural security flaws. Starting this month, researchers can earn $250,000 for Root-in-Cloud bugs, including tenant-isolation bypasses and complex cross-service logic flaws that let attackers gain full administrative control over arbitrary Google Cloud organizations. "To earn this premier reward, you must demonstrate full administrative control, the equivalent of 'roles/owner' or complete IAM control, over arbitrary Google Cloud organizations or projects with no prior access or special project setup," said Chris Betz, Google Cloud's Chief Information Security Officer (CISO). "Additionally, valid vulnerability reports demonstrating remote code execution (RCE) in underlying Google production infrastructure (Borg) or achieving root-in-prod will automatically be evaluated by the Google Cloud VRP panel for root-in-cloud eligibility."
In an industrial network, malicious activity can be hard to tell apart from normal data exchange between devices. Malicious actors routinely rely on legitimate tools and the Living-off-the-Land technique, so a single network connection may show no known signs of an attack: the device uses a familiar protocol and transmits ordinary data. An anomaly can hide in subtle details: the data source, the time of access, or the volume of transferred data may be atypical for a particular device. However, to detect this kind of anomaly, you need to understand the roles of the devices at both ends of the connection and know which network activity patterns are typical for them. But an organization’s asset inventory data is often incomplete, which makes it harder to catch unauthorized connections in time. Suppose monitoring detects a host that regularly exchanges data with programmable logic controllers (PLCs). Its IP address is known, but the inventory does not specify what role it plays: is it an engineering workstation, a process data server, or a piece of contractor’s equipment? The host may also have been on the industrial network for a long time, with its record going out of date after a network upgrade. In the joint OT asset inventory guidance released by CISA and its partners in 2025, inventorying devices and classifying them by role are treated as part of OT asset management. For organizations, this is one of the most important areas: according to the SANS 2025 ICS security survey, 50% of respondents had deployed or significantly expanded ICS inventory and visibility tools over the previous 12 months, and 54% named them as investment priorities for the next 12–24 months. Device inventory in Kaspersky Industrial CyberSecurity for Networks In Kaspersky Industrial CyberSecurity for Networks, the Asset Discovery technology is the foundation of asset visibility. Passive network traffic analysis detects devices and their interactions, while recognition rules help determine the device category and extract available information about it, such as the vendor, model, or software version. Exactly which attributes the system can obtain depends on the protocol and the traffic it observes. We covered this in more detail at the Kaspersky Industrial Cybersecurity Conference. Hardware and software information in the device card The product also supports active polling modules (APMs): where polling is allowed, they can request additional configuration and firmware version details from devices. This kind of inventory is far more detailed than a list of IP addresses. Installed modules and their placement in a PLC rack However, even accurate hardware information doesn’t always explain what function a host performs in a specific industrial facility. Gaps appear for various reasons. Some devices send identifying information only at startup or during configuration, while others rarely communicate. Proprietary protocols can’t always be parsed, and encryption may leave only connection metadata for analysis. If the monitoring system doesn’t receive traffic from every segment of the industrial network, some network activity goes unobserved. Active polling doesn’t suit every device or every operating condition. Devices of unknown category When there isn’t enough direct information about a device, its category can be refined by looking at the patterns of its recurring network interactions. Analyzing these interactions is the job of Machine Learning Event Processor (MLEP), a service included in Kaspersky Industrial CyberSecurity for Networks 5.0. This machine-learning-based event processor can both refine device categories and detect anomalies in their network behavior. What data does MLEP analyze? To compare device behavior, you don’t need to store every packet as a separate observation (a data object) in the ML model. MLEP represents network sessions as a sequence of short 15-second fragments. For each fragment, MLEP stores information about the endpoints (IP, MAC, and port), the direction of data exchange, the protocol, and the number and size of the packets transmitted. Together these make up an event, which then gets a timestamp. Traffic thus becomes a sequence of events showing which hosts a device communicated with, when, and how communication intensity changed. Aggregating data into events also sets the method’s limits. An aggregated fragment can’t be used to reconstruct the exact order of individual packets or the content of commands. MLEP can draw conclusions about a new protocol only if another KICS technology has managed to recognize it. That said, comparing stable network connections and changes in exchange volume doesn’t require a detailed record of every packet. These observations form the basis of the device’s behavioral history. From observations to MLEP results Each object has its own behavioral history, and one object’s history can’t be applied to another. But the principles of behavior analysis, along with some common rules, work across different objects. Let’s look at how this works in MLEP, which is built on a spiking neural semantic network (NSN). Event identification Neurosemantic networks structure information as a multilayer ordered graph, where the data in each consecutive layer builds on the data in the previous one. The nodes of this graph — that is, the units of information in each layer — act as neurons.The NSN creates dedicated channels to handle different event parameters (port, IP, and so on). Unique parameter values for each channel are stored as neurons in layer 0. The event itself, which consists of a set of parameter values, is stored as a neuron in layer 1 of the network. If an event occurs for the first time, neurogenesis creates a new neuron with input connections to the corresponding parameter neurons. This lets the network learn and operate on the event stream at the same time. If the event has occurred before, the network activates the same neuron that was created when the event first appeared. This way, the network identifies each event precisely. Each neuron that corresponds to an event also collects basic statistics: when it was last activated and how many times it has been activated. Event history In NSN-based event processing, layer 2 and above store sequences of events over time: recurring patterns and the full history. However, categorization and statistical anomaly detection don’t require storing the full packet sequence or a detailed timeline of every network event. As we noted earlier, events are themselves aggregates, which means the order of network packets has already been averaged out. So MLEP keeps history only temporarily, within each episode (30,000 aggregated events by default), which saves computing resources. Statistics processing in MLEP MLEP processes statistics mainly through specialized listener neurons on layer −1 (minus one) of the network. Attention heads and monitors are built on these neurons. Key components of the NSN When an event arrives, the corresponding neuron is activated, and the network instantly knows whether that neuron is new or was created earlier. Each attention head subscribes to the events or event features it needs and takes in only the activations of the matching neurons. If an event occurs for the first time, all heads are notified and then decide whether to subscribe (grow a connection to the relevant neuron) and receive information about activations of such neurons from then on. It is called a spiking network because activation information is a spike, not a number. This spike tells the head that something it’s interested in has happened. An attention head is configured according to scenarios — the situations that MLEP should send alerts about. The core of a head’s configuration is a query, which filters incoming information and serves as the subscription criterion. Unlike regular database queries, this query runs on the stream, so it can react to an event instantly. Attention heads work very much like the semantics of ordinary human language. A query has a subject of attention (one or more grammatical subjects) and conditions (the other parts of the sentence). In the infrastructure of an industrial enterprise, the subjects are devices on the network, and the conditions are various aspects of network communication, such as ports, protocol, and average packet size. If a head has many subjects (for example, if it’s interested in every device on an industrial network), it fans out: it creates a child head for each individual value of the subject of attention, that is, each device. The child head then watches a specific device and reports to the parent head. Attention heads don’t accumulate or process statistics. They only filter event streams. When an attention head receives a relevant event, it activates and sends a spike to the monitor subscribed to that head. Monitors, in turn, have stacks for accumulating and processing events. They can also have their own queries and post-filter information from the head. For example, they can select only new events from those filtered by the head. There are several types of monitors: Stat monitors track changes in the average count of specific events (for example, device activity) over time intervals typical for those events, or in the average values of numeric event parameters (for example, changes in device traffic volume). Monitors work from the event alone: they fire when an event has occurred a certain number of times within a given interval, or has occurred for the first time. Similar-behavior monitors work with heads that can generalize events, that is, extract just a few parameters whose combination is shared (generalized) across many events. MLEP uses these monitor types to implement scenarios for categorizing devices and detecting their anomalous behavior: For categorization, MLEP uses attention heads and monitors that identify common behavior across different assets and group devices accordingly. MLEP then takes information from Asset Discovery about the known categories of some assets and extends those categories to other assets in the same group. Because a device can show different types of activity, it may land in several groups. MLEP then makes a weighted assessment across all relevant groups. Groups of devices with similar network behavior At the final stage, the system verifies that assigning the category to the asset is permissible. This is again done by special rule monitors loaded into the NSN at system startup. The rules rely on asset metadata available from Asset Discovery and APMs. MLEP takes a similar approach to anomaly detection: an attention head and a monitor define an anomaly scenario, often loosely. When a monitor activates on such a scenario, MLEP generates an alert about unusual behavior. The current version of MLEP ships with preconfigured heads and monitors. The functional dynamic diagram below shows how events from devices on an industrial network are processed. Event processing flow MLEP in practice: how behavior helps complete the asset inventory At a facility with several similar production lines, device information may be more complete on some lines than on others. On one line, devices are identified as PLCs, while on another, after an upgrade, some hosts show up only as addresses: the available traffic didn’t provide enough information to determine their category. Still, these devices communicate with the same types of HMIs and process data collection servers. Their communication directions, frequency, and volumes may be similar. That’s where MLEP comes in. It takes the categories of already known assets and matches recurring features of their network behavior against those of uncategorized devices. When the observed interactions turn out to be similar, MLEP can add a category for that host to the inventory. Device category suggested by MLEP Once the category is refined, the industrial network map provides more context about the equipment on the network. When analyzing network activity, the analyst immediately sees the device’s suggested category and can skip looking up each IP address in the design diagrams. This approach is especially useful where equipment changes faster than the documentation is updated. The suggested category is also checked against existing device information and defined constraints. This helps filter out some contradictory options, but prediction quality still depends on how much of the traffic is visible, especially if the device communicates only rarely. Anomalous activity and streaming statistics Investigations of real-world attacks show that attackers actively use both standard tools and permitted protocols. You don’t always need to know an attacker’s specific technique in advance to spot potentially malicious activity. Signature-based detection helps find known signs of an attack, but it doesn’t assess how typical an observed interaction is for a particular device. MLEP compares current activity with the device’s usual network profile: which hosts it communicates with, which protocols it uses, when and how much data it transmits, its average packet size, and so on. The changes it detects help guide the direction of the investigation. Correlating these changes with other events and the operational context helps determine whether malicious actions could be behind them. When investigating an incident that has already been detected, anomalies help reconstruct the sequence of actions. The first version of MLEP comes with six preconfigured monitors, one for each type of deviation from the device’s usual network profile: Anomaly How it helps with event analysis New external host Flags a new external connection that wasn’t previously seen in the device’s observed behavior, even if the IP address isn’t listed among known IoCs. Helps check whether this connection appeared at the same time as other suspicious events. New combination of destination address and port Shows that the device has begun using a service it hasn’t used before. Once an incident has been detected, this helps trace new connections after the more critical events have been analyzed. Unusually large volume of data sent Highlights data transfers that are atypical for the device and helps correlate their timing and direction with other events. Atypical activity time Shows that the device was active at a time that’s unusual for it. In an already detected incident, this helps reconstruct the timeline of actions around the main alert. New protocol Helps spot a new method of communication, even when the device is communicating with familiar hosts. Activity with signs of scanning Shows that the device has started contacting an unusually large number of neighboring hosts. This signal helps reveal possible reconnaissance ahead of attempts to access equipment. During an investigation, anomalies help reconstruct the sequence of changes: when a specific host established new connections, switched protocols, increased its data transfer volume, or shifted its operating hours. Matching events by device and time shows an analyst how activity unfolded around an incident that has already been detected. This is especially useful when some of the attacker’s actions fell outside the monitored scope or didn’t trigger other KICS technologies. Correlating these changes with the device’s role, protocol analysis data, and events from other technologies gives the analyst a more complete timeline. Behavioral anomalies show exactly where to look for the missing links and which network interactions need attention. Atypical Activity Time anomaly card In the event list, anomalies detected by MLEP are marked with an AI label. Each event shows its name, source, destination, timestamp, and the ID of the triggered scenario. Conclusion In an industrial network, whether behavior is anomalous depends on the host where it occurs and that host’s place in the industrial process. The repetitive nature of many communications makes a change in normal data exchange easier to spot, while knowing a device’s function and criticality helps gauge the possible consequences. Taken together, these observations make network traffic more than a list of connections: it helps assess new events in the context of a specific facility, even without an attack scenario known in advance. Machine learning technologies are well suited to this kind of comprehensive analysis, as they can process and organize huge streams of heterogeneous data. Starting with version 5.0, Kaspersky Industrial CyberSecurity for Networks handles this function with MLEP, which works effectively alongside the product’s existing functionality.
Google dismantled a 1.3 million-device botnet allegedly built by Android TV box maker Videostrong to enable ad fraud and proxy abuse. Google and its partners dismantled a backdoor called XCPE that had enrolled more than 1.3 million set-top boxes in a botnet. The result of the investigation into the malware operation is the striking part: Videostrong Technology Co., an Android device maker, built and ran the botnet for money. Google says it is highly confident that Videostrong deliberately created, spread and operated the backdoor. The company reportedly sold access to criminal groups and installed their malware on infected devices. The malware was used for ad fraud, secretly added devices to residential proxy networks and installed other malicious software. Google says this was not the work of a rogue employee or a simple coding mistake. The backdoor was found in many device models and brands over several years. Its operation involved dedicated infrastructure and regularly changing configurations. “We assess with high confidence that the backdoor and botnet were intentionally developed, deployed, and operated for financial gain by Videostrong Technology Co., an Android Original Equipment Manufacturer (OEM) and Original Design Manufacturer (ODM).” Google states. “Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices. “ Google has now cut all ties with Videostrong. The company is banned from making devices with pre-installed Google apps. The ban also covers any future subsidiaries or business partners, and Videostrong can no longer supply software to other certified device makers. Videostrong got around Google’s compatibility and security tests with code obfuscation. The malicious code loaded after a device’s first boot, which the tests didn’t catch. Google has changed its review process and is improving how it checks firmware on certified Android TV devices. Google also took legal action against the domains and servers Videostrong used to control the botnet, and against the control domains of over a dozen malware families loaded through the backdoor. Those affiliates spread their modules through other channels too, so Google expects the takedown to cut access to at least 10 million more compromised devices. Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI worked on the operation. The malware has three stages. The primary backdoor, x.cpe (called com.oemservice in some builds), is preloaded in the firmware and runs with system privileges. If a user uninstalls it, it reinstalls itself from the /oem/ partition at the next reboot. It handles communication with the control server and passes work to a loader called com.abc.nexus, which carries its own anti-analysis tricks and sets up the money-making modules. These modules are supplied by other criminals working as affiliates. They can arrive as programs built into the backdoor, software packages added to its loader, or extra apps downloaded later. Many turn the device into a residential proxy, allowing other people to use the victim’s home internet connection to hide their online activity. Others commit ad fraud or install additional backdoors. In other words, a set-top box becomes a proxy server without its owner’s knowledge. The backdoor uses two steps to control infected devices. First, the box sends an HTTP request to download settings, location data and network information. It then maintains a live connection through MQTT, a lightweight messaging protocol, to receive commands from the operators. Google found that all analyzed samples used the same MQTT server to communicate with infected devices. “Additional monetization modules as well as various shell scripts and legitimate applications are hosted remotely and downloaded by infected devices upon command from the operator via the MQTT broker.” continues the report. “A significant majority of these files are hosted as Github releases on operator-owned Github pages. Other files are hosted on operator-controlled servers and file hosting sites.” Through this connection, attackers could secretly install apps, run commands and scripts, take screenshots, record keystrokes and map the victim’s network. They could also disable Google Play Protect’s app verification to install software without the user’s knowledge. Google observed operators taking screenshots, recording keystrokes, collecting account and device information, stealing app lists and system logs, and opening remote command-line sessions. However, most of their activity involved installing, removing and managing malware modules. The malicious files came from several sources. The attackers mainly used GitHub releases hosted on their own accounts, the Filemail file-sharing service and two servers under their control. Network traffic analysis also suggests that the operators managed the command infrastructure through remote interfaces and an EMQX web console, connecting from IP addresses outside the infected device network. Most infected devices are Android TV set-top boxes, but Google also found telehealth devices, karaoke machines and digital signage. One device can run several modules at once, up to three residential proxy kits. That shows Videostrong wants to squeeze every infected device as hard as it can. The proxy and bandwidth-sharing kits named in the report include Linkfog, AppSalt, GaGaNode, BWM, Traffmonetizer, EarnFM and NetNut. Some of those kits enroll devices without asking. AppSalt’s SDK, owned by Honeygain, calls an opt-in function without showing any consent screen, and it stops running if the app came from the official Google Play Store. Ad-fraud modules such as Fission and HiddenView fire off fake ad impressions in the background, and HiddenView also uses hidden browser windows to simulate clicks and scrolling. The configuration shows a well-run operation. MQTT messages carry resource limits for each module, download links per processor type, and priority weights. Devices are assigned to one of six timezone-based pools on ott.szbboys[.]com. Devices report their bandwidth use and alarms back, so the modules stay within set limits. Google says the underlying market is resilient. Backdoor operators, ad-fraud rings and residential proxy providers work as an interconnected supply chain, and when one part gets disrupted they quickly switch to new loaders or rival kits. Lasting change, it says, needs accountability across hardware makers, the residential proxy industry and the broader technology sector. Google wants retailers and distributors to require independent security audits from device manufacturers and to delist any implicated in supply-chain abuse. It says proxy providers’ claims of ethical sourcing need transparent, auditable proof of user consent, and that in its analysis these providers asked for consent only when platform policy forced them to. Silent opt-in remains the most common way devices become exit nodes. For consumers, Google advises caution with apps that pay you for “unused bandwidth” or “sharing your internet”, which are a main way illicit proxy networks grow. Stick to app stores you trust, review permissions for third-party VPNs and proxies, and keep Google Play Protect on. Buy connected devices like set-top boxes only from reputable manufacturers, and check the partner list on Google’s Android TV website. Google also urges mobile platforms, ISPs, online marketplaces and other tech platforms to keep sharing intelligence. “A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust. By turning everyday hardware into persistent beachheads for criminal affiliates, Videostrong prioritized illicit post-sale recurring revenue over the safety and privacy of its users.” concludes the report. “Downstream hardware brands, white-label resellers, telecommunications providers, and online e-commerce marketplaces also share responsibility for closing this vector.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, newsletter)
Synology is urging customers to update the DiskStation Manager (DSM) software powering its Network Attached Storage (NAS) devices following ransomware attacks. The Taiwanese vendor said it observed threat actors exploiting a vulnerability patched in December 2024 to target devices running outdated versions of DSM. "These attacks aim to encrypt data and extort ransom," it said in a statement
A maximum-severity security flaw impacting Siemens SIMATIC IoT2050 Advanced devices has come under active exploitation, VulnCheck has revealed. The vulnerability, tracked as CVE-2026-58115 (CVSS score: 10.0), is a case of missing authentication for a critical function that could be exploited by an unauthenticated remote attacker to run arbitrary code. "SIMATIC IoT2050 Advanced devices running
Chinese hackers used ARTEX, an open-source, multi-agent AI penetration-testing framework, in attacks against more than 200 organizations across 14 countries. The operation began on October 17 and targeted government ministries, telecommunications providers, and organizations in the pharmaceutical, semiconductor, defense, nuclear, and financial sectors. The threat actor compromised at least nine organizations and carried out password spraying attacks and credential scanning activity against at least 12 other high-value targets. According to researchers at CrowdStrike, the "campaign marks an escalation in China-nexus use of AI agents, from single intrusions to multiple simultaneous engagements directed by a human operator." Confirmed victims include telecommunications providers in the United States and Belgium, government organizations in Greece, the Middle East, and Latin America, and pharmaceutical firms in the U.S.
Financial technology company Abrigo has restored its Sageworks risk management application, except for borrower-facing capabilities, following an outage triggered by "irregular activity" in its environment. On October 30, the company began emergency maintenance and took the Sageworks application offline to investigate suspicious activity detected earlier that day, with the outage continuing through the weekend. Abrigo provides cloud-based software and analytics solutions for community banks and credit unions across the United States. According to the company, it serves more than 2,400 entities. Its Sageworks product is a software platform that helps lenders process loan applications, analyze borrowers’ finances, assess creditworthiness, and monitor loan portfolios. Due to its nature, Sageworks handles sensitive information, including banking customer details.
VOLTA is an AI-powered infostealer that steals personal data, then uses LLMs to assess victims’ value and rank targets for attackers. Cisco Talos has analyzed a new Windows infostealer called VOLTA, which calls itself VOLTA-AUTODOXER. It steals the usual data, then hands the loot to a large language model that ranks what the victim is worth. Ryan Fetterman laid it out in a Talos report, after the malware turned up through the CAIRN research effort. “There is a new idea in the cybercrime world — cast a wide net, steal everything, and let AI sort out the specifics. A new malware self-named “VOLTA-AUTODOXER,” surfaced through the CAIRN research effort, is a self-deleting Windows infostealer that augments its post-theft workflow with an LLM-powered victim-profiling stage.” reads the report published by Talos. The malware deletes itself after running and does not use servers controlled by the attacker. Instead, it uses third-party systems to carry out its activities. The malicious code supports data-stealing features are advanced. It collects browser passwords, cookies and saved payment card details from Chromium browsers, as well as data from Firefox, Thunderbird and Outlook. It also steals Slack workspace information and login sessions from Discord, Telegram, Steam, Battle.net and Roblox. The malware also collects Microsoft OAuth tokens, SSH keys, cloud service credentials, screenshots and all saved Wi-Fi passwords. For crypto wallets, it tries to crack the wallet password directly on the infected device and saves the results in its report. To steal some browser tokens, it must bypass Chrome’s App-Bound Encryption. But VOLTA goes further. It also builds a detailed profile of the victim. This includes their location and home address, employer and company domain, estimated year of birth, the last four digits of payment cards, Slack workspaces and information about who created documents. It also looks for signs of iPhone backups and checks the current value of the victim’s Roblox account. “After harvesting the standard stealer haul, including browser passwords; cookies; payment cards; cryptocurrency wallet seed phrases; Discord, Telegram, Steam, and Roblox sessions; Microsoft OAuth tokens; SSH and cloud-provider keys; Wi-Fi profiles; and screenshots, VOLTA builds a structured evidence bundle about the person behind the machine.” states the report. It uses the victim’s own logged-in sessions to fill the gaps. It searches Gmail for receipts from Amazon, DoorDash, Uber Eats, Grubhub, Walmart and PayPal to confirm a home address, pulls order histories from Uber Eats and DoorDash, and adds detail to the victim’s Discord profile. Even a takeout history can now count as evidence. The bundle goes to OpenRouter, a routing service for AI models, with a system prompt that tells the model to act as a forensic intelligence analyst drafting a target assessment. “The required output includes a section titled “WHAT THEY’RE WORTH” with valuables ranked by monetization with a low/medium/high tier, and a section on “THEIR OPSEC” containing an assessment of the victim’s security posture and password hygiene.” states the report. “The model is the operator’s triage analyst; it turns a raw credential log into a prioritized and citation-backed dossier of the victim and their monetizable assets.” It also needs a section called “THEIR OPSEC”, rating the victim’s security habits and password hygiene. In short, it’s a performance review for the person it just robbed. The prompt asks for something agents do well: connecting scattered facts. It pushes the model to link names, addresses or universities to patterns in the victim’s passwords. The model isn’t hunting for new data, only stretching what the malware already took. The operator wants a short, blunt assessment with a trail of citations. By default VOLTA calls Anthropic’s Claude Opus 4.6. If the model refuses, which VOLTA spots by scanning replies for phrases like “I can’t” or “I’m not able”, it moves on to Moonshot AI’s Kimi K2 and then Google’s Gemini 2.5 Flash. A low temperature setting of 0.2 keeps the output consistent. The requests are hand-built JSON with no software kit, and the malware still runs without the AI stage if no API key is present. Talos sees the fallback system as evidence that the malware’s author expected security protections and designed ways to bypass them. The AI analysis runs directly on the victim’s computer, using their own internet connection, before any data is sent out. The malware creates a file called Identity_Report.txt, receives the AI’s response in AI_Analysis.txt, and sends both files together in a ZIP archive called volta_dox.zip. The stolen data can be sent to the attacker in up to three stages. The first archive, volta_log.zip, contains the information collected by the malware. The second, volta_dox.zip, contains the AI analysis. A third archive, volta_doxnet.zip, is created if the malware finds additional network information. The attacker receives everything through a Telegram channel. The malware also has six configurable fields that can be changed when it is built. This suggests that its author may offer a builder service, allowing customers to create their own customised versions. The credentials stored in these fields are encrypted, but the encryption is weak because the key is stored inside the malware itself. Anyone who analyses the file can recover them. If VOLTA is sold as a commercial product, its AI feature could allow even inexperienced criminals to identify valuable victims and receive detailed, ranked profiles directly through Telegram. For defense, Talos suggests an application control policy that restricts which processes can launch Chrome with the –headless flag, which would block the App-Bound Encryption bypass. At minimum, alert when Chrome starts with –headless from any process outside a known developer set. Storing credentials in hardware-backed stores also helps. If you’re compromised, the main program may have deleted itself, but try to keep %APPDATA%\volta_debug.txt. It’s a timestamped log of what was collected and whether the AI call worked. Revoke any exposed tokens and change passwords. If a wallet’s seed phrase sat in plaintext on disk, treat the wallet as fully compromised and move the funds to a new wallet whose seed was generated on an air-gapped device. “VOLTA is a mature stealer with a late-stage AI layer added for one purpose: relieving the operator of analytical work. The axis of AI improvement here is not speed or scale but effort displacement; the same logic visible in CLOSEDQUORUM, though applied to a different phase.” concludes the post. “These implants reflect the same underlying logic: Identify the step that requires the most sustained human attention and replace it with a model call. The question for defenders is not whether this pattern will appear elsewhere, but which phase it touches next.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, malware)
The maintainer of BTCPay Server, an open-source cryptocurrency payment processor, has urged users to install the latest version as hackers have been draining “hot wallets” on instances running older versions. Operators were initially advised to shut down their servers pending a full investigation into the unauthorized Bitcoin and Litecoin payments. The BTCPay Server project provides businesses with a self-hosted payment processing solution that allows them to accept Bitcoin and other digital assets directly into their own wallets, eliminating payment intermediaries or paying platform processing fees. It handles checkout invoices and payment verification, including payments over the Lightning Network. Early Monday, the maintainer said it had “identified an attack vector targeting instances running version 2.4.1 (July 23, 2026) or earlier” and strongly urged users to update to version 2.4.7.
A new wave of fridge cyberattacks hit supermarket refrigeration systems across five European countries, raising temperatures and causing food losses. A new wave of fridge cyberattacks has affected supermarket refrigeration systems in several European countries. Fridges and freezers suddenly rose in temperature overnight, with some incidents suspected to be caused by hackers. On Monday, November 2, Ahold Delhaize and Colruyt reported an IT incident affecting dozens of stores in Belgium and Luxembourg. Swedish supermarket chains ICA and Coop also reported similar problems. “Ahold Delhaize and Colruyt said on Monday that an IT incident overnight hit fridges and freezers in dozens of stores in Belgium and Luxembourg, while Swedish grocers ICA and Coop reported similar temperature spikes, with one store blaming a cyberattack.” Reuters states. BREAKING: Swedish grocery giant ICA, one of Sweden's largest supermarket chains, says several of its stores have been hit by a cyberattack overnight, causing refrigerators and freezers to be remotely set to 50°C. The incident has likely resulted in large quantities of food… pic.twitter.com/wrcmGHw1qV — GeoInsider (@InsiderGeo) November 2, 2026 “Problems were discovered at several grocery stores in Sweden overnight Monday.” reported Sweden Herald. “We are aware that a limited number of stores were affected by an incident overnight that affected their refrigeration and freezer systems. Ica is providing support in handling the incident, Ica Group press officer Gustaf Nilsson tells TT.” The latest incidents follow a similar wave of fridge cyberattacks in France last month. In mid-October, a large cyberattack hit the refrigeration systems of hundreds of French supermarkets, BFMTV revealed. The attackers targeted equipment from the Danish maker Danfoss that many French stores use to regulate their cold. Fresh and frozen stock was destroyed, and the Paris prosecutor says there were also fires. The method is simple and nasty. Refrigeration systems have a forced defrost function that clears ice buildup, and the attackers appear to have triggered it remotely in a continuous mode, with a temperature setting of 50 degrees. The equipment heated for several hours instead of keeping goods cold, and when staff opened the fridges and freezers in the morning, a sector source told BFM, “a wave of heat” came out. The attack caused fires and food losses. However, cybersecurity consultant Emil Olofsson of Integrity 360 told Swedish news agency TT that temperatures reached 80°C in some cases and several units caught fire. This figure differs from the one reported by police. ICA Kvantum in Sjöbo said on Facebook that a cyberattack caused the refrigeration problems. ICA Hägerstensåsen in Stockholm was also reportedly affected. According to the Sjöbo store, the temperature inside its fridges and freezers rose to 50°C. In Belgium, Delhaize detected unusual temperature increases in its refrigeration systems on Monday. Spokesperson Sarah De Meester said the company is investigating the incident. Stephan Moelans, CEO of Sabcobel, the company that manages Delhaize’s refrigeration systems, told news agency Belga that hackers had switched the units’ evaporators to defrost mode. His office declined to comment to Reuters. Colruyt Group, which operates Spar stores in Belgium through a franchise system, said five stores had suffered attacks on their refrigeration systems. Meanwhile, Belgian newspaper Le Soir reported that dozens of Delhaize and Carrefour stores were affected. UPDATE: REFRIGERATION DISRUPTIONS SPREAD ACROSS EUROPE – SWEDEN AND BELGIUM AFFECTED IN SWEDEN: • At least 6 ICA supermarkets affected by suspected refrigeration system hacks. • Coop has now CONFIRMED that 6 of its stores in central Sweden are also affected. • Freezer… https://t.co/a3oGMrGdmz pic.twitter.com/8Q3CFDDLhT — Coffe Report (@CoffeReport) November 2, 2026 It follows a similar attack in France last month. Police said hackers seized control of the cooling units at hundreds of supermarkets and raised temperatures as high as 50 degrees Celsius (122 Fahrenheit), which caused fires and food losses. Cybersecurity consultant Emil Olofsson of Integrity 360 told TT, Sweden’s news agency, that temperatures there reached 80 degrees and some units caught fire, a figure that differs from the police number. In Belgium, Delhaize noticed temperature increases in its cooling systems on Monday, spokesperson Sarah De Meester said, and the company is investigating. Stephan Moelans, CEO of the refrigeration firm Sabcobel, which runs Delhaize’s systems, told the news agency Belga it was a cyberattack that switched the units’ evaporators to defrost mode. His office declined to comment to Reuters. Colruyt Group, which runs Spar stores in Belgium under a franchise system, said five shops had their fridge systems attacked, and Le Soir reported that dozens of Delhaize and Carrefour stores were affected. Ahold also reported a cybersecurity incident to Dutch police last month, after it detected suspicious activity in its infrastructure. Nothing in the reporting ties that report to Monday’s incident. Fridges and freezers at dozens of supermarkets in Belgium and Sweden overheated overnight in a suspected cyberattack, similar to the one that hit French stores three weeks ago. Delhaize calls it an "IT incident." Delhaize said about 40 of its Belgian stores were affected… pic.twitter.com/qzw6uDybWb — The Informant (@theinformant_x) November 2, 2026 In Sweden, John Billow, head of the national cybersecurity centre, told Reuters his team was working on several incidents involving refrigeration systems in grocery stores around the country. An ICA Kvantum store in Sjöbo said on Facebook that a cyberattack caused its problems, and an ICA store told its followers that its temperatures had been “hacked” overnight and set to 50 degrees. Fifty degrees is fine for a beach and poor for ice cream. That store later said it had opened. At ICA Baronen in Stockholm, a notice said all the freezers were broken because of a cyberattack. The sales manager said the attack came at 2 a.m. and staff noticed it at 5:30 a.m. ICA Hägerstensåsen in Stockholm was reportedly hit too. ICA said only a limited number of stores were affected and that it is helping them deal with the incident. However, press officer Gustaf Nilsson did not say how many stores were involved. Coop told Swedish news agencies Aftonbladet and TT that six stores in central Sweden had similar problems. Press manager Carlos Cancino said it was still unclear whether any food would need to be thrown away or whether the refrigeration units had simply stopped working or had switched to heating mode. He also did not rule out further incidents affecting other stores. An Estonian supermarket chain was also affected. Its refrigeration systems were reportedly set to 50°C, technology provider Kitman Coldtech told public broadcaster ERR. CEO Jann Mutso did not reveal the name of the supermarket chain, saying: “This is very recent. It happened this morning.” How did the attackers get in? In France, Olofsson says they obtained login details for the control systems, which were exposed directly to the internet. He says the attack targeted a product that controls the cooling systems and that the hack isn’t very complicated, so amateurs may have carried it out. Billow says Swedish authorities have noticed in recent weeks that quite a lot of exposed operational technology devices exist in Sweden, and they’ve been clear that these must be updated or patched. Refrigerators and heating systems, security cameras and alarm networks were once largely mechanical, and now they can be monitored and controlled remotely. That gives cybercriminals new openings. Authorities haven’t said who was behind last month’s incidents, and nobody has claimed responsibility. The Sweden Herald reported that the cause of the attacks on Swedish supermarkets remains unknown. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, fridge cyberattacks)
Confirm this action.
Leaving now will discard your changes.