French Bank Crédit Mutuel Arkéa says hackers exploited a service provider to steal up to $133 million using the bank’s own account. French cooperative bank Crédit Mutuel Arkéa was hit by a cyberattack that let attackers make fraudulent transactions of up to $133 million, forcing it to suspend certain systems. Crédit Mutuel Arkéa is a major French cooperative banking and insurance group headquartered in Brest, Brittany, France. The bank says the attacker used its own account to send transactions to other banking organizations, and that customer assets weren’t affected. “French lender Credit Mutuel Arkea said on Thursday hackers had stolen around €100 million ($112.61 million) in a cyber heist and it was working to try to recover the money, in a rare case of cybercriminals successfully stealing from a mainstream bank.” Reuters states. Blockchain researcher ZachXBT first warned of a large unauthorized withdrawal from multiple centralized exchange accounts a day earlier. He said the attacker may have stolen up to 118 million euros ($133 million) and withdrawn it as the USDC and USDT stablecoins. “Over the past 24 hours the illicit actor has been aggressively swapping USDC for ETH, transferring to instant exchanges (WellWallet, Kyrrex, etc), converting to XMR via Wagyu, and bridging across multiple chains.” ZachXBT wrote. “While the illicit actor remains unidentified, I can say with a high degree of confidence it is NOT Lazarus Group based on multiple laundering indicators.” The attacker remains unidentified, but ZachXBT believes it is highly unlikely to be Lazarus Group, based on money-laundering patterns. According to BleepingComputer, the expert pointed out that the lack of public disclosure allowed attackers to launder $30 million by November 3, potentially preventing EU authorities from freezing the funds. The Paris prosecutor’s cybercrime unit opened an investigation after receiving a complaint from Crédit Mutuel Arkéa, with France’s cybercrime police leading the probe. Arkéa disclosed the incident on November 4, saying it was contained, customer assets were unaffected and some transfers had been delayed. Attackers reportedly accessed the bank through a service provider’s platform, not Fortuneo, and used Arkéa’s own account to move funds through other banks and convert them into cryptocurrency. The bank also warned customers about increased phishing risks. “Crédit Mutuel Arkéa announces that it has been the target of an attack that enabled the execution of fraudulent transactions.” reads the notice published by the bank. “Upon detecting this attack, and in accordance with standard procedures, the Group contacted the relevant regulatory and supervisory authorities to inform them of the situation.” “This incident is now closed and fully under control. Operations are gradually resuming this morning, following thorough verification by the Group and its subsidiaries and the implementation of enhanced security measures.” Crédit Mutuel Arkéa says customer assets were unaffected, although some transfers were delayed. The bank maintains its financial stability, warns of possible phishing attempts and urges customers not to share sensitive information. Its teams are assessing the incident and strengthening security measures, with further updates expected. Arkéa did not confirm ZachXBT’s reported figure but acknowledged significant losses and said some funds were blocked. The bank ruled out internal human error, described the incident as a sophisticated attack and is working with law enforcement to identify the attackers and establish how the breach occurred. When the FAQ asked whether 118 million euros had been stolen, Arkéa wouldn’t give a number: We do not confirm this information and can only validate the order of magnitude. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Crédit Mutuel Arkéa)
Hunt.io traced ARTEX servers and AI-powered hacking tools used in breaches affecting seven South Korean financial institutions. Between late September and early October 2026, seven South Korean financial institutions had data breached through internet-facing systems. About 66,000 to 67,000 people and around 2,200 corporations were affected, and personal, employment, income and loan data was exposed. Hunt.io dug into the infrastructure behind the campaign, and its findings add a lot to what CrowdStrike and Genians already published. CrowdStrike reported on October 7 and Genians Security Center on October 12, and both pointed to ARTEX, an open-source autonomous penetration testing framework developed in China and licensed under AGPL-3.0. CrowdStrike assessed with moderate confidence that a single Chinese-speaking individual motivated by money ran it, and not an established threat group. DeepSeek v4.1 Flash was the main model, with GLM 5.3 and Grok 4.6 as backups, reached partly through a reseller domain, xcai[.]pro. The public indicators were a server at 38.244.50[.]120, which hosted the ARTEX console, plus a Hong Kong address and nine proxies. Genians said the ARTEX GitHub repository and Docker image were removed on October 11, though forks and mirrors remain. “CrowdStrike assessed with moderate confidence that the operator was a single Chinese-speaking individual motivated by financial gain rather than an established threat group.” reads the report published by Hunt.io. “The infrastructure reportedly accessed these services in part through the reseller domain xcai[.]pro. Both reports described a two-server configuration, consisting of a Hong Kong-based IP address used as primary infrastructure and 38.244.50[.]120, which hosted the ARTEX console.” Hunt.io notified the relevant national CERT before publishing, and says the report holds no personal records or credentials. The company’s own scanning showed 38.244.50[.]120 sits on Cogent’s network in Los Angeles, with 15 open ports. The ARTEX login page, with a Chinese title meaning “autonomous penetration testing console”, appears on ports 443 and 8090. Other services include a Gemini2API admin console and a Tinyproxy server. Searching its AttackCapture platform for that address, Hunt.io found another open directory at 23.248.226[.]250, a jump server in Hong Kong on AS138415. It held 42 files in 2 subdirectories, 105 MB in all, and the platform had logged warnings on September 5, September 26 and October 5. A file in it names 38.244.50[.]120 as the jump host, and its own comment tells the operator never to paste the credentials into a session. It sat in an open directory. Three scripts back up the link. They keep reverse SSH tunnels alive, run a local relay, and copy files to the jump host, one tunnel is named grok2api, and the credentials file also holds keys for Zhipu AI’s GLM models, an OpenAI-compatible relay and a proxy service. That explains how several language models ran in one campaign. The AI setup is the most striking part. A state file shows the harness is Claude Code itself, version 2.1.221, started 510 times since August 4, but it isn’t talking to Anthropic. A small proxy, ds-models-shim.py, fixes a compatibility problem by faking a model list and sending requests to DeepSeek, and another, xcai-effort-shim.py, adds a reasoning setting because the DeepSeek backend otherwise skips its reasoning step. The route runs from Claude Code through Claude Code Router, an open-source project, to xcai and then to DeepSeek. “A small local proxy, ds-models-shim.py, addresses a compatibility issue: the official /v1/models endpoint returns a 404 response when queried against a non-Anthropic backend, preventing Claude Code from discovering the available models. The shim intercepts that specific request and returns a locally defined model list containing deepseek-v4-pro and deepseek-flash. All other requests are forwarded to api.deepseek.com/anthropic.” states the report. The same file counts 19 custom skills, reusable instruction sets for the agent, with 147 recorded uses. They cover code audit, reconnaissance, web injection, WAF bypass testing, authentication testing, Telegram Mini Apps, APK download and decompiling, cloud phone control and payment logic testing. Next to the payment skill sat three self-registered test accounts with tokens for a cash-in deposit API, dated September 12, and a comment calls them an authorized, self-built test. The setup fits testing for insecure direct object reference flaws, a technique CrowdStrike and Genians described against Korean loan and inquiry services. The directory also held supporting tools. A script queried FOFA, a Chinese asset search engine like Shodan, through a third-party API, and a comment says the primary membership had expired and a backup key was in use. Proxy scripts enumerated a rotating proxy service at 154.201.79[.]246:443, where 79 unique exit IPs showed up among the first 100 identities tested. A separate directory at 23.248.226[.]250:8001 held a small staged setup for JNDI and LDAP exploitation, retrieved on October 5 at 03:42 UTC. It confirms command execution through a DNS callback, and one script lets web and LDAP traffic share a single port. Hunt.io’s analysis describes the tooling without publishing steps to reproduce it. Other recovered files include tools aimed at a cryptocurrency exchange’s admin session and withdrawals, Linux privilege escalation exploits, iOS probe source code and Android kernel and firmware utilities. Hunt.io says their connection to the Korean breaches isn’t confirmed. Hunt.io then showed how to hunt ARTEX servers. Searching for an ARTEX certificate issuer returned 19 IP addresses, and searching its malware classification returned 1,303 addresses across 30 countries, led by the United States, China and Hong Kong. Those figures show where addresses are registered, not where the operator sits. “The result returned 19 distinct IP addresses, including 38.244.50[.]120. This method is precise but limited to hosts that expose a matching certificate. Systems using a different certificate will not appear in these results.” continues the report. Matching the console’s page title returned about 1,300 IPs, and a looser search found 21 title strings, 19 of them likely ARTEX consoles, in English, Chinese, Korean, Japanese, Russian, Portuguese and Vietnamese. A malware-name search in AttackCapture gave 280 results with open directories. One at 130.94.31[.]86:18888 in Seoul held two small scripts, and another at 156.251.11[.]39 held an SMB reconnaissance toolkit whose test script writes a file named artex_probe_11876.txt. More hosts held exploitation kits for DedeCMS and FangCMS, a CAPTCHA bypass suite, a RuoYi and Spring administrative console exploit and CAPTCHA-based login automation. Together they show the framework attracting many operators. For defenders, the advice is plain. Remove public access and put administration behind VPNs or allowlists, and reset SSH passwords and rotate API keys, proxy credentials and tokens that exposed files may have revealed. Patch internet-facing services, watch for unexpected LDAP and JNDI activity, DNS callbacks and remote script downloads, and store secrets in a managed vault with least-privilege permissions. Also restrict access to model gateways, watch their requests, and enforce compliance rules on managed phones. Hunt.io’s lesson is that an investigation shouldn’t stop at the first list of indicators, because The company also published indicators of compromise in its analysis. “The findings highlight risks associated with exposed administrative services, reusable credentials, remote access tunnels, proxy infrastructure, and exploitation tooling.” concludes the report. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, ARTEX)
Software vendors can boost revenue by tracking customer usage across products, while AI accelerates pricing and consumption decisions. It is hard to find any software vendor that sells just one product. Portfolios have expanded from modules to editions, cloud services, add-ons, and now AI capabilities. A lot can be achieved through an expanded portfolio. IDC research commissioned by Thales shows that customers with consolidated agreements “spend more, churn less, and deepen their relationship with the vendor over time.” However, there is one thing to note. Purchasing four products from the same vendor does not mean they will be treated as a single vendor, as each product has its own licensing, measurement, and sales terms. The Size of the Prize Existing customers are an obvious place to look for growth. The possible upside could be considerable. According to IDC research on software vendors from June 2026, 55% of software vendors believe that enhanced monetization would bring a 6% to 10% uplift in revenue, and 29% expect more than 10%. IDC has also linked a SaaS provider’s ability to capitalize systematically on new features and capabilities to net revenue retention and growth. Companies that excel at this see it in their valuations too. McKinsey research shows top-quartile B2B SaaS companies achieve 113% net revenue retention, growing 13% from existing customers alone, against 98% for bottom-quartile peers. Capturing that opportunity becomes harder when the commercial systems behind the portfolio cannot see across it. Sales teams may know a customer well, but they also need to know what that customer has bought, what they are entitled to use, and how much of it they are consuming. That information is what turns a general cross-sell conversation into a relevant one. Where Portfolio Revenue Leaks Away Product launches or acquisitions might occur at different times, and the business units could operate independently. With time, each one may build its own licensing approach, customer database, product catalog, and commercial model. IDC’s vendor research found that only 25% of software vendors have centralized usage data. In practice, vendors need to at least unify the entitlement system first. All of the products need to sit in one catalog before the vendor can create a bundled offer across them. Getting there can stall for technical, organizational, or budget reasons. But the reason to overcome those barriers comes back to the customer experience. A company may be optimized internally around separate product lines or business units, while customers still have to go to multiple places to access and manage products they bought from the same vendor. Customer pressure has historically forced companies to restructure and centralize around that problem. Licensing and entitlement ownership can move out of individual product lines and into a central function, such as engineering operations, product operations, supply chain operations, or SaaS operations. For that to work, the central function needs real authority rather than existing in name only. A customer could be approaching the limits of Product A while another part of the company sells Product B, which would be a logical next purchase. The usage data contains the signal, but it may sit in a system that the team responsible for Product B never sees. AI can multiply this problem quickly. Vendors no longer need to launch an entirely new application before they have something new to monetize. A new model, agent, workflow, or premium feature could all require decisions about entitlements, usage, and price. Over time, however, customers can end up with a growing collection of meters, contract terms, entitlements, and invoice lines. The vendor sees one expanding portfolio. The customer sees the work required to understand and manage it. Buyers are already feeling this pressure. IDC’s customer research found that 45% struggle to reconcile purchased licenses with actual usage, while 39% cite inflexible licensing models as a challenge. At the same time, 60% of buyers report an active drive to reduce the number of software vendors they use. Consolidating with a strategic supplier becomes much less attractive if it leaves the customer managing the same complexity under a single company name. What Unified Portfolio Monetization Enables A shared entitlement system brings products from different business units into one catalog, giving vendors a consistent view of what customers have bought and what they can use. That common foundation is what makes portfolio-wide bundles and offers possible. Vendors do not necessarily have to wait for every commercial system to be consolidated before they get there. Thales can bring third-party license generators onto one platform, while Central Migrate and Thales’s internal migration expertise and best practices support the move from existing licensing systems. Shared credits or pooled consumption can provide another option. Customers have a single balance that can be used across multiple products or capabilities. As vendors add AI features with different consumption patterns, this gives them room to introduce new capabilities without automatically introducing a standalone commercial model for each. M&A Creates Another Portfolio Opportunity The same issue appears after an acquisition. CEOs are looking for the “1+1=3” outcome: creating more value from the combined business than the two companies could separately. The acquirer can sell its portfolio to the acquired company’s customers, while the acquired company’s products can be introduced to the acquirer’s customer base. The problem is that full M&A integration can take time, particularly when ERP and ordering systems are involved. Entitlement systems can be unified much sooner and with considerably less work than a full ordering-system integration. That allows portfolio monetization to run in parallel with the heavier systems work rather than waiting for it to finish. The business can start cross-selling across the combined customer base sooner, giving leadership a way to demonstrate acquisition ROI faster. Turning Usage Into Expansion Opportunities Usage data then becomes useful beyond billing. Vendors can see which customers own Product A but not Product B, which customers are consuming, and which customers are regularly reaching the limits of their current entitlement. They can also change the renewal conversation. Actual consumption provides a much stronger basis for discussing the next contract than assumptions made when the previous agreement was signed. It shows what customers are using heavily, what they are barely touching, and where there may be a natural opportunity for upselling and cross-selling. Buyers appear open to this kind of consolidation. IDC found that 86% are somewhat and extremely interested in a single licensing agreement covering multiple products from the same vendor. Runaway costs are the biggest concern around vendor consolidation, cited by 74%, followed by lack of flexibility at 62% and lack of transparency at 59%. Those concerns put some useful boundaries around portfolio monetization. Bringing more products into one commercial relationship needs to make them easier for the customer to understand and manage. Visibility into consumption, clear entitlements, and controls over spend become more important as the portfolio grows. Making a Larger Portfolio Easier to Buy AI is likely to keep adding features, agents, models, and new forms of consumption to software portfolios. Portfolio growth works better when the entitlement system cuts across product and business-unit silos. Customers can see what they own, understand what they are consuming, and use more of the vendor’s products without having to navigate a new commercial process each time. The IDC report shows that buyers already want greater flexibility, visibility, and control. The opportunity for vendors is to make expansion across the portfolio easier to buy and manage, even as the underlying technology becomes more complex. About the Author: Manoj Tharakan is Director of Product Management, CDI, at Thales, where he works on software licensing, SaaS billing, and monetization. With over 20 years across software licensing, SaaS billing, and monetization, he’s helped build the systems vendors rely on to actually get paid for the value they create. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, AI)
Passwords and API keys that developers typed into commands they approved in Claude Code are sitting in public GitHub repositories, where anyone can read them. When a user selects "Yes, and don't ask again," Anthropic's AI coding assistant can save the command, word-for-word, including the secret, in a project settings file. Software security company Apiiro said yesterday that 1,122 public
Layer3 found residential proxy traffic using the White House network, raising concerns about potential exposure of internal systems. Layer3 Intel says it found residential proxy traffic leaving through the White House network. The researchers spotted it while browsing their new Residential Proxy Observatory, a tool that gives a global view of residential proxy and anonymized internet activity. “While our team was looking through it, we noticed residential proxy exit activity on AS2650. AS2650 is registered to the Executive Office of the President, the federal agency that hosts the White House network.” reads the report published by Layer3. A residential proxy service allows customers to use everyday devices to route their internet traffic. This makes their activity look as if it comes from the device’s normal home internet connection. Layer3 detected this activity on AS2650, a network registered to the Executive Office of the President, the agency responsible for the White House network. Layer3 has not accused anyone at the White House of wrongdoing and says its data cannot identify who or what caused the activity. Between October 5 and November 3, Layer3 detected 236 connections through this network. The traffic came from six IP addresses and was recorded on 26 of those 30 days. A total of 28 residential proxy services were able to use the network. To check their findings, researchers compared the IP addresses with data from other security services, including Spur and Synthient. Both services also identify these addresses as residential proxy exit points. Getting this data took no special skill. Anyone can sign up to a public residential proxy service, pay a few dollars and send requests through it. Layer3 says it didn’t target the network or try to steer its probes there, and it caught the activity by chance, simply by requesting global rotating access through these services. The timing suggests something more than a guest network. About half the activity falls between 5 p.m. and midnight Eastern time, and almost none happens in the early morning. Layer3 reads that as a person, not public guest Wi-Fi: someone regularly on the White House network late into the evening whose device carries a proxy SDK, a software kit that turns a device into an exit point. “Past research has shown that poorly secured proxy SDKs can allow internal network access and lateral movement. This is how past botnets have spread. In A Broken System Fueling Botnets, the researchers at Synthient documented how the Kimwolf botnet reached at least 2 million devices, mostly Android devices with an exposed ADB service, through residential proxy networks.” continues the report. “If an SDK on this network has the same kind of flaw, anyone buying proxy access could use it to reach internal systems.” That matters because poorly secured proxy SDKs have let attackers into internal networks before. Synthient’s research, A Broken System Fueling Botnets, documented how the Kimwolf botnet reached at least 2 million devices, mostly Android devices with an exposed ADB service, through residential proxy networks. If an SDK on the White House network has the same kind of flaw, anyone buying proxy access could reach internal systems. Layer3 doesn’t claim that’s the case here, and it describes the risk as conditional. The White House isn’t the only surprise. The observatory also finds residential proxies in some of the most isolated places on the planet. Saint Helena, Ascension and Tristan da Cunha, a South Atlantic territory that includes the most remote inhabited island in the world, shows 413 addresses and more than 32,000 observations, split between Starlink and the local provider, Sure Saint Helena. Layer3 also detected three instances of proxy activity in Antarctica. All came from a Cloudflare WARP address linked to McMurdo Station. The researchers jokingly noted that penguins are not suspects. On Pitcairn Island, they found one Starlink address and one observation. Norfolk Island had one Norfolk Telecom address with four observations, while Svalbard had one Starlink address in Longyearbyen with three observations. The researchers also found 388 addresses in the Falkland Islands, 43 in the Chagos Islands, 21 in Tokelau and seven in South Georgia. These findings suggest that residential proxy networks now operate in almost every corner of the world. For security teams, the main concern is that devices connected to protected networks could unknowingly become proxy exit points, potentially exposing those networks to outside traffic. However, Layer3 says its data only shows where proxy traffic exits. It cannot identify the device being used or the person behind it. As the company explains, “Our data shows the exits, not the device or the person behind them.” “Residential proxies have infected every corner of the world, and it looks like there is no place they cannot reach. Layer3 Intel tracks residential proxy and anonymization infrastructure worldwide. Even when the proxies hide in networks on the farthest corners of the planet, we can still observe them, leaving threat actors no place to hide.” concludes the report. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, proxy traffic)
QNAP urges users to update Plex Media Server to the latest version available in the QNAP App Center, as hackers are exploiting the Plex2Shell vulnerability chain. The vendor said it had received multiple reports of suspected compromises involving customers’ network-attached storage (NAS) devices. "QNAP has received reports from some users that Plex Media Server on their NAS appears to have been compromised through [Plex2Shell] vulnerabilities, and QNAP Technical Support is assisting the affected users,” the company says in an advisory today. Plex2Shell is a chain of four vulnerabilities in the Plex Media Server, tracked as CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656. Security researcher Zach Main discovered and reported the flaws to Plex on July 27. Exploitation started shortly after the full technical details became public on October 16.
In April 2026, BleepingComputer reported that Canadian authorities arrested three men for operating an “SMS blaster,” a device that pretends to be a cell tower to send phishing texts to nearby phones. It’s a close cousin of the IMSI catcher, the fake-tower device used for surveillance. Both work by tricking phones into connecting to the strongest signal and sharing information before anything is authenticated. One of the main things a fake tower can collect this way is your IMSI, the identifier tied to your SIM, but it’s far from the only thing your phone gives away. Your phone has several radios that connect to different kinds of signals and share different information. The Wi-Fi and Bluetooth radios share hardware addresses, which modern phones randomize or rotate to reduce tracking.
D-Link shared mitigation measures for multiple unpatched security flaws affecting DGS-3130 series managed Gigabit stackable switches. These switch models provide multi-gigabit uplinks, allowing enterprise network administrators to eliminate data bottlenecks, and are designed primarily for small-to-medium businesses (SMBs) and metro Ethernet deployments. While D-Link didn't share details on these flaws and has yet to publicly disclose the CVE IDs for easier tracking, it said Spectrum Community Solutions network engineer Giresh Kumar Enugu found the bugs in the D-Link Discovery Protocol (DDP) authentication, access control, and information handling. Successful exploitation could allow attackers to obtain sensitive device data, make unauthorized credential/configuration changes, leak SNMP communities, or cause service disruptions and device resets.
Introduction Incidents in virtual environments can begin with a software vulnerability, human error, a configuration weakness, or several of these factors at once. The investigation is rarely limited to the workload. Hypervisors, container runtimes, management consoles, monitoring platforms, identity systems, virtual networks, datastores, backups, and automation accounts all influence what an attacker can reach. Kaspersky GERT recently investigated two more ransomware cases on ESXi and Proxmox environments in which weak access controls, insufficient network separation, exposed administrative services, and poor management of privileged credentials contributed to the impact. A monitoring system that could reach the virtualization layer also exposed a reusable root credential. Once the attacker controlled that route, ordinary administrative access was enough to affect several hosts. No VM escape was required. The incidents show why patching and secure configuration must be managed together. A fully patched hypervisor can still be compromised through a shared password, an overprivileged monitoring account, an open SSH path, or an administrator interface reachable from a general server network. NIST guidance places secure configuration baselines, restricted administrative access, current patches, and monitoring across all layers within the same set of sound security practices. In this article, we’re going to describe both incidents with additional focus on common unsafe practices that were exploited, leading to compromise, as well as remediation tactics. We’ll also discuss the broader scope of threats targeting virtual environments for a better understanding of possible protection strategies. The connected system defenders must protect A business virtual environment is not just Hyper-V, VMware, or Docker but rather a connected stack. Management consoles, orchestration tools, monitoring platforms, and automation accounts sit above hypervisors and container engines. Registries, image stores, virtual switches, datastores, and backup systems connect the layers. Applications and business services run at the bottom, while much of the administrative power sits near the top. The important boundaries extend beyond guest to host. They include workload to management plane, monitoring system to hypervisor, registry to deployment, administrator workstation to console, management plane to storage, and one virtual network segment to another. An attacker only needs one usable route. The possibility of compromise may lie in one stolen or insecurely placed administrator credential rather than in a complex escape exploit. In the GERT case, the compromise route passed through the monitoring platform and included a valid virtualization platform credential. Case #1: From network monitoring to ESXi encryption The investigation began with evidence of BlackNevas ransomware activity on a Windows system in a virtualized domain controller segment. UserAssist artifacts recorded execution of the AnyDesk RMM tool and GMER binaries. The environment also used PRTG Network Monitor to monitor its virtual infrastructure. UserAssist artifacts The available evidence showed that the PRTG deployment had broad access to the ESXi hosts and that the same root password was reused across several nodes. After obtaining access to the monitoring environment, the attacker used the ESXi credential to connect over SSH to the hosts that shared the same password. This design joined monitoring, credential storage, and direct administration into one attack path. PRTG supports storing VMware credentials at the device or inherited group level. That feature is operationally useful, but a monitoring server becomes privileged infrastructure when it holds credentials that can administer the systems it observes. The security question is therefore not whether monitoring needs access, but whether the identity, privileges, storage method, and permitted network path are limited to the monitoring task. The threat actor gained root access to the ESXi environment and used the esxcli command to bypass the system restriction by disabling the execInstalledOnly policy to execute the encryption binary and also perform anti-forensic log deletion. Let’s look closely at the timeline of the initial host compromise. ESXi (192.168.*.*) timeline 2025-10-18 Connection attempts from IP address 192.168.*.*. 2025-10-19 During an SSH session by root from IP 192.168.*.*, the file esx is uploaded to the system. 2025-10-19 User "root" attempts to execute the binary esx with the error "Execution of non-installed file prevented". chmod 777 esx ./esx /log 2025-10-19 User "root" deactivates the execInstalledOnly option. esxcli system settings advanced set -o /User/execInstalledOnly -i 0 2025-10-19 User "root" executes the malware esx. 2025-10-19 New connection attempts from IP 192.168.*.*.Now, at the same time, the following activities ensued on a different host with the same password for the root user: ESXi (172.16.*.*) timeline 2025-10-19 SSH connection by user "root" from IP 172.16.*.*. 2025-10-19 User "root" executes the malware esx and clears the logs. chmod a+x esx && chmod 777 esx ./esx /selftest nohup ./esx /p /vmfs/ /depth 5 /log /wipe ./esx /depth 5 /log /wipe Case #2: Credential notes impacting the whole Proxmox environment GERT responded to a ransomware incident by The Gentlemen group, in which the threat actor gained access to Proxmox using information collected during the dwell time between initial access and visible impact. On a compromised system administrator workstation, the actor discovered administrative credentials and access details stored in notes in plain text. These records provided the information needed to log in to Proxmox using the root account. The actor then activated the VNC web socket through the compromised root account, gaining extensive control over the Proxmox environment. This access was subsequently used to download and execute ransomware within the cluster, which resulted in the encryption of the entire virtual environment. Below are the log records showing the root account being used to access other hosts via a VNC web socket. root@pam [01/08/2026:00:28:36 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=**** root@pam [01/08/2026:00:30:17 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=**** root@pam [01/08/2026:00:31:19 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=**** root@pam [01/08/2026:00:43:38 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=**** root@pam [01/08/2026:00:44:49 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****This incident is a clear example of the risks of storing privileged credentials in unsecured notes or other easily accessible files. Once the administrator workstation was compromised, the saved credentials allowed the actor to move from a single endpoint into the virtualization management layer. Because the credentials belonged to a highly privileged root account, one poor credential handling practice significantly increased the scope and impact of the attack. Privileged credentials should instead be stored in an approved password manager or privileged access management system, protected with multifactor authentication and rotated immediately if an administrator workstation is suspected of being compromised. Why the misconfiguration caused broad impact Both cases exhibited unsafe misconfiguration practices whose exploitation led to a bigger impact on the host system. Next, we will break down each misconfiguration to see how it enabled further compromise and what should be done to avoid it. Monitoring inherited excessive privilege In Case 1, the monitoring platform could do more than collect health and performance data. It held or could use credentials with enough privilege to reach ESXi directly. A compromise of the monitoring system therefore became a compromise of the management plane. Monitoring identities should be dedicated to the task and given only the permissions required by the deployed sensors. Credential reuse Password reuse converted one recovered secret into farm-wide access. System administration should use named identities through the central management plane. Each host should have unique credentials and proper password storage hygiene. Password strength alone does not limit the impact of theft, but where the credential can be used and where it is stored do. Direct root access bypassed central control Direct SSH access allowed the actor to authenticate as root, upload a binary, and change a security setting without first passing through vCenter role controls. Broadcom, the parent company of VMware, recommends managing vSphere through vCenter, disabling SSH during normal operation, and using Lockdown Mode where suitable. Required service accounts should be explicit exceptions rather than members of a broad administrator group. Lack of enhanced security settings The initial execution attempt was blocked by execInstalledOnly, but the attacker had enough privilege to disable this policy. Broadcom documents enforcement options that combine execInstalledOnly with UEFI Secure Boot and TPM-backed configuration protection. These controls must be enabled, tested, and monitored for change. A setting that can be silently disabled by the same credential used for daily administration provides limited resistance after account compromise. Unsafe credential storage Case 2 demonstrated the possibility of compromise lying in privileged credential exposure. The mitigation strategy involves not only securing the administrative credential storage but also general hardening practices of secret handling, such as privilege management and regular access audits. How to close this attack path In this section, we share remediation advice on how to mitigate such attacks, and detect and prevent them from going further. We recommend the following actions: Separate monitoring from administration. Create a dedicated monitoring identity for each platform and restrict it to the smallest set of objects and actions that the monitoring sensors require. Do not use ESXi root or another emergency account for routine polling. Prevent monitoring servers from starting interactive administrator sessions unless a separately approved support workflow requires it. The same principle applies beyond VMware. Replace stored root passwords. Locate every copy of hypervisor, management, storage, and backup credentials in monitoring tools, scripts, scheduled tasks, connection managers, and service configurations. Replace static passwords with vault retrieval, brokered identities, or limited API tokens where the platform supports them. Record every retrieval and rotate the secret after emergency use or compromise. Restrict direct host access. Route normal ESXi administration through vCenter and enable an appropriate Lockdown Mode after testing monitoring, backup, and recovery dependencies. Keep ESXi Shell and SSH stopped by default. When support work requires SSH, enable it for a defined period, restrict the source, and alert on service activation, root login, and changes to the exception list of users who are allowed to connect via SSH. Use a specialized security solution. In our portfolio, Kaspersky Cloud Workload Security (KCWS) is perfectly suited to address virtual environment risks, offering a powerful combination of two products: Kaspersky Hybrid Cloud Security (KHCS) and Kaspersky Container Security (KCS). Kaspersky Hybrid Cloud Security is specifically built to secure virtualized infrastructures, private data centers, and hybrid clouds. A patented Light Agent architecture minimizes resource impact without compromising performance, while comprehensive infrastructure visualization through a unified console gives administrators complete visibility and control over the entire hybrid network. Kaspersky Container Security covers every stage of a containerized app’s lifecycle, from development to operation. Among other capabilities, the solution allows for detecting misconfigurations using a dedicated scanner for images, file systems, and repositories that contain IaC files (such as Terraform, CloudFormation, Azure ARM templates, Helm charts, and Dockerfiles). Treat configuration changes as security events. Alert when execInstalledOnly, Secure Boot enforcement, Lockdown Mode, SSH, local accounts, exception users, firewall rules, or remote logging settings change. Baseline the expected state and test whether the security team can detect an unauthorized change. A secure configuration set once does not mean that the control remains active on the host. Isolate the management network. Place hypervisor, monitoring, backup, storage, and cluster administration on restricted management networks. Permit only the exact source and destination services required. Administrative workstations should enter through hardened jump hosts with named identities and multifactor authentication. Protect logs, backups, and recovery. Forward ESXi, vCenter, Proxmox monitoring, identity, and network logs to protected storage that a compromised administrator cannot erase. Backup platforms should use separate identities, restricted management paths, and recovery copies outside ordinary administrative reach. Configuration checks for monitored virtualization Below are recommended checks to run when enabling virtualization monitoring. The safest state depends on the platform and monitoring method, but each control should be tested. Control area Safer state Verification Monitoring identity Dedicated service account or token with only required read and polling rights Review assigned roles and test every sensor without root or global administrator access Credential storage No recoverable host root password on a monitoring or general-purpose server Review tool configurations, scripts, scheduled tasks, and connection stores for embedded credentials, access tokens, or other secrets Network path Monitoring reaches only required polling services while administration uses a jump host Test management ports from monitoring server, user segments and untrusted network segments Direct host access Lockdown Mode where suitable with SSH and ESXi Shell stopped by default Attempt direct client API and SSH access to host using a routine account Configuration integrity Secure Boot and execInstalledOnly enforcement enabled where supported and tested Change a test setting through the approved process and confirm an alert is generated Evidence Host, management, identity, monitoring, firewall, and PAM logs stored remotely Generate successful and failed logins and verify source, account, host, time, and action The wider attack surface Closing the monitoring and credential routes does not secure the environment by itself. Virtualization also relies on isolation boundaries, trusted images, management APIs, virtual networks, storage, and backups. Each layer requires a different control and leaves evidence in a different place. VM and container escapes In a VM escape, code inside a guest reaches past the VM boundary and affects the host or another guest. The weakness may be in a virtual device, an integration feature, a hypercall interface, or another component that translates guest requests for the host. If the escape works, control of one VM may lead to control of the physical server and every workload on it. VMware CVE-2025-22224 showed this risk: an attacker with administrator rights inside a VM could execute code as the VMX process on the host, and Broadcom reported exploitation in the wild. A container escape can reach a similar result, but the starting point is different. Linux containers share the host kernel, so their isolation model differs from that of a VM. Namespaces limit what processes can see, cgroups control resource use, and capabilities split root privileges into smaller parts. A kernel or runtime bug can break this isolation. Copy Fail (CVE-2026-31431) is a good example of a kernel flaw. Code already running in a container could use a Linux AF_ALG crypto socket to change pages in the shared Linux kernel page cache. Because the host and other containers may read the same cached pages, the effect did not have to stay inside one container. The fix is a kernel update; Docker Engine 29.4.3 also tightened its default security profiles to reduce exposure on hosts that had not yet been patched. Unsafe settings can also break the boundary. Privileged mode, excessive capabilities, writable host mounts, or access to the Docker socket may remove isolation without any software exploit. For instance, runc CVE-2024-21626 involved leaked file descriptors that could expose the host filesystem to a malicious image or container process. This difference changes the investigation. A VM can often be treated like a separate computer with its own kernel, memory, and disk. A container is a group of host processes placed inside namespaces. If investigators collect only the container filesystem, they may leave the most useful process, socket, and control-plane evidence on the host. Images and templates A compromised golden VM image or container base image can spread through normal automation. Common weaknesses include unofficial public images, mutable tags, overprivileged build tokens, recoverable secrets in older layers, and stale templates that restore vulnerable software or forgotten accounts. Scanning might help, but it does not establish who built the artifact or whether the exact image tested and approved was the one ultimately deployed to production. Use controlled builders, provenance records, signature checks, and planned rebuilds from trusted sources. Management tools and APIs A stolen vCenter identity, exposed Docker API, overpowered Portainer role, or compromised backup console may give an attacker an easier route than an escape exploit. Portainer advisory GHSA-7fw3-x4r2-g7wc showed how a proxy validated one bind-mount representation but missed an equivalent API form, allowing an authenticated non-administrator with container creation privileges to reach host paths. The runtime performed a valid request after authorization had already failed in the management layer. Administrative file-copy operations also deserve attention. Docker fixed archive and mount-handling flaws in CVE-2026-41567, CVE-2026-41568, and CVE-2026-42306. These cases required particular conditions and operator or API activity. They are a reminder to patch the daemon and record who initiated copy operations, which container was involved, the source and destination paths, and the result. Virtual networks, storage, and backups East-west traffic between virtual workloads may stay inside one host and bypass a physical sensor. Management, migration, storage, and workload traffic should use separate zones with filtering between them. Snapshot and memory files may contain credentials, while weak datastore permissions can expose whole virtual disks. Backup systems need broad access to recover services, which also makes them valuable to an attacker who wants to delete recovery points or reach several hosts. Attack surface examples by layer To sum up, the described attack vectors might be mitigated as follows: Attack surface Initial access Possible impact Primary control Credentials and configuration Password recovered from monitoring or an overprivileged account Direct control of several hypervisor nodes Unique vaulted credentials, segmented access, and configuration monitoring VM escape Administrative access or code execution privileges inside a guest plus a hypervisor flaw Host process or neighboring workload compromise Patch the hypervisor and reduce risky virtual devices and guest privilege Malicious container affecting kernel or runtime Code in a container or a malicious image Host filesystem, kernel, or shared cache impact Patch kernel and runtime, and remove privileged settings Images and templates Compromised build input registry or golden image Repeated deployment of the compromise Immutable digests, controlled builds, provenance, and verification Management API Stolen identity exposing endpoint or authorization gap Fleet-wide administrative actions MFA, least privilege, network restrictions, and complete API validation Networks, storage, and backups Flat network or broad datastore and access through backups Lateral movement, data theft, encryption, and recovery loss Segmentation, least privilege, protected backups, and traffic monitoring Conclusion GERT cases that we presented in this article did not require an attacker to break the VM boundary. The attack path was created by an overprivileged monitoring relationship, an insecure password storage approach, a recoverable and reused root credential, broad management-network reachability, and direct SSH administration. Each element was legitimate on its own, but together they allowed one compromise to reach virtualization hosts and their workloads. Misconfiguration should therefore receive the same operational attention as vulnerability management. Teams need to know where privileged credentials exist, which systems can use them, which network paths make them effective, and which logs will show their use. Escape flaws, unsafe images, API weaknesses, virtual network exposure, and attacks on storage or backups remain serious, but closing the known administrative route should come first.
Cryptocurrency wallet provider MetaMask said a recent security incident has not affected MetaMask wallets or its wallet infrastructure. The MetaMask non-custodial crypto wallet (developed by blockchain software company Consensys) lets users store and manage assets on the Ethereum network and compatible blockchains. MetaMask revealed on September 30 that it was investigating an "ongoing infrastructure security incident" and exited affected validators (Ethereum network nodes responsible for proposing blocks, verifying crypto transactions, and maintaining Ethereum blockchain security) within non-custodial staking operations. While the company shared almost no details at the time and redirected BleepingComputer to the public statement when asked what part of its infrastructure was affected, in a Thursday update it said that a threat actor gained access to systems used to store recipient addresses and diverted some execution-layer staking rewards.
Confirm this action.
Leaving now will discard your changes.