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.
Hackers are using fake OpenAI, SpaceX, and Anthropic event invitations to lure employees into phishing attacks, using two different phishing-as-a-service platforms to steal Microsoft and Google account credentials and authentication sessions. According to a new report from Push Security, the attackers use convincing event registration pages offering free access to premium AI services and other rewards to trick victims into signing in with their corporate accounts. What makes the attacks interesting is that the same phishing pages integrate two separate phishing-as-a-service (PhaaS) platforms, Kali365 and VoidProxy, to target Microsoft and Google accounts using different authentication attacks. Kali365 conducts Microsoft device code phishing attacks, while VoidProxy acts as an adversary-in-the-middle (AiTM) reverse proxy to intercept Google sign-ins and steal authentication session cookies.
Truffle Security has launched the Secrets Revocation Program, a free initiative that helps API key issuers revoke 1.4 million publicly exposed secrets that remain valid. Since 2022, the company has discovered secrets embedded in public repositories, packages, container images, datasets, and applications. Earlier this year, Truffle Security reported that it had found 543,000 valid credentials leaked in public GitHub repositories. In a separate investigation, the company identified more than 431,000 AWS secrets across code repositories, Git histories, datasets, Docker images, registries, and CI logs. These secrets are typically exposed by mistake during the development process, by committing credentials to a public repository, including them in published Docker images or packages, or leaving them in configuration files uploaded with an app or dataset.
Zyxel GS1900 network switches that received the vendor's earlier fix for an actively exploited flaw are still open to the exploit attackers used, researchers at Binarly found. The exploit lets anyone who can reach a switch's web management interface run commands on it without logging in. Zyxel has released new firmware for 10 GS1900 models that closes the hole. The earlier fix is the 2.90
Barracuda patched two flaws that can be chained to give attackers root access to Email Security Gateway appliances. Barracuda has patched two vulnerabilities that can be chained to gain root access to its Email Security Gateway (ESG) appliances. CVE-2026-116606 (CVSS score of 9.3) is an authentication bypass that lets unauthenticated attackers modify appliance configurations. CVE-2026-111560 (CVSS score of 8.6) is a command injection flaw affecting six Barracuda products. An attacker with administrator privileges could exploit it to execute operating system commands as root. “Barracuda has identified two vulnerabilities affecting certain Barracuda products: a pre-authentication authorization bypass vulnerability and a command injection vulnerability. The vulnerabilities have been assigned CVE-2026-116606 and CVE-2026-111560, respectively.” states the advisory. “Successful exploitation requires an attacker to have access to the administrative interface of an affected product. If exploited in combination, these vulnerabilities could allow an attacker to bypass authorization controls and obtain root access to the device.” Barracuda quickly began fixing the problem and released security patches for affected products. Customers should check the affected products and follow the remediation guidance, make sure their systems use the latest firmware, and install all security patches. It has released patches and urges customers to update their systems, below are the affected products: Email Security Gateway (ESG) — affected by both vulnerabilities; patch with BNSF-40425 for version 9.4.017 or later, or BNSF-40430 for versions below 9.4.017. Load Balancer Application Delivery Controller (ADC) — affected by CVE-2026-111560; patch with BNADC-16586. Message Archiver (BMA) — affected by CVE-2026-111560; patch with BNMA-32468. WAF Control Center (WCC) — affected by CVE-2026-111560; patch with BNWF-60060. Web Application Firewall (WAF) — affected by CVE-2026-111560; patch with BNADC-16586. Web Security Gateway (WSG) — affected by CVE-2026-111560; patch with BNYF-24789. The vendor recommends that customers: Restrict administrative interfaces to trusted internal networks and use network access controls to reduce exposure. Check that devices are running the latest firmware and that all security patches are installed. If a device is several versions behind, install updates step by step; more than one update may be needed. Contact Barracuda Support if help is required. “If a patch has not been automatically applied, customers should manually apply the appropriate patch as soon as possible. If customers have turned off automatic patching, Barracuda recommends setting devices to automatically receive patches.” concludes the advisory. “Guidance on how to manually apply the patch or update firmware can be found on Barracuda Campus.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Barracuda)
A phishing campaign used Google Calendar invites, trusted redirects, and fake login pages to hijack corporate Google sessions and bypass MFA protections. Material Security examines how Operation CloudFire tracked the attacks, blocked malicious messages, and helped take down nearly 900 domains used by the attackers.
SonicWall has warned of two vulnerabilities impacting end-of-life Global Management System (GMS) systems that it said will not be patched. Details of the security flaws, which affect SonicWall GMS 9.5.2 and earlier versions, are below - CVE-2026-109593 (CVSS score: 9.1) - An unauthenticated file read vulnerability that could allow an attacker with network access to read internal GMS files,
Binance reveals how fake job interviews, malware and internal AI abuse enabled attackers to steal $6.34 billion. The Binance security incident on October 29 shows how a fake recruitment process can become the entry point to critical financial infrastructure. The attackers combined social engineering, compromised developer tools, stolen credentials and abuse of an internal AI application to reach the cryptocurrency exchange’s wallet signing systems. “Woah – so the Binance hack was indeed via a dodgy job interview for one of its developers who was tricked into downloading malware as part of the “interview” – costing the company >$3bn…” the popular best seller author and cybercrime expert Geoff White wrote on LinkedIn. “Worth noting: – The 2016 hack of Bangladesh Bank also attributed to North Korea’s Lazarus Group of hackers was via a job application – The 2022 theft of $625m from video game Axie Infinity happened via offering an employee a juicy job offer RECRUITMENT IS RISK. If you’re not educating employees on this, start now… – The 2024 heist of $1.5b from Bybit relied on tricking an employee of its supplier into downloading a dodgy share trading app onto the work machine (so not using a recruitment lure, but still deceiving a target into downloading malware)” In its initial findings and response update, published on November 3, Binance described the operation as a “sophisticated, multi-stage campaign.” The company estimates that approximately $6.34 billion in digital assets were affected. The FBI attributed the incident to the North Korea-linked APT “TraderTraitor,” also tracked as Lazarus Group and APT38. “Our current investigation indicates that this was a sophisticated, multi-stage campaign. It was not a single isolated breach or a simple phishing incident.” reads the update published by the crypto firm. “The attackers combined a range of techniques, including social engineering by fake recruitment interviews, malicious software downloads, compromised internal AI tooling, endpoint compromise, and an advanced transaction-authorisation method.” The operation began months before the theft. In June 2026, an engineer from Binance’s Wallet DevOps team downloaded a tampered Homebrew installation while searching online for a popular AI coding tool. Binance detected the suspicious activity, replaced the device and rotated the associated credentials, but information about the engineer’s role and colleagues had already been exposed. The attackers then targeted another software engineer through a legitimate job-hunting platform. In September, someone posing as a Project Director arranged two interviews: first with an HR representative, then with someone claiming to be the CEO of a fictitious company. During the first video interview, the supposed HR representative shared a social media account containing personal photos and videos to establish credibility. At the end of the second interview, the engineer was asked to download a technical assignment containing a malicious code repository onto his work computer. The malware executed during setup, replacing a legitimate development tool component with a malicious version. It used obfuscation to evade detection, executed commands and established communication with an attacker-controlled server. Binance said its endpoint security tools didn’t detect the malware at the time. “The second interview was conducted in a popular social chat app, near the end of the interview, Engineer B was instructed to download an “assignment” containing a malicious code repository onto his work computer.” states the firm. “The repository contained malicious code that executed during the setup process, initiating a series of unauthorized activities.” The compromise then moved beyond the affected workstation. On October 20, attackers used the compromised computer to abuse an internal AI tool and gain access to the systems of two other employees, including the Wallet DevOps engineer initially targeted in June. They discovered that his computer contained a token with container deployment permissions. This is one of the more significant aspects of the incident. The report doesn’t identify a vulnerability in the AI model itself. Instead, it shows how an internal application can become an attack pivot when an adversary gains access to a compromised employee’s environment and the permissions available to that user. “The attacker leveraged the compromised computer of engineer B and used an internal AI tool to gain control over the Wallet DevOps Engineer A and another Wallet Software Engineer C.” states the report. “The attacker soon discovered Wallet DevOps Engineer A had a container deployment permission token on his computer.” On October 29, the attackers used stolen credentials to access another engineer’s computer, deploy a container and execute a malicious script. This gave them access to Binance’s internal wallet signing service, allowing them to initiate transactions outside the normal withdrawal process. The transfers involved several blockchain networks. Five Binance hot wallets sent 233.46 million XRP to an attacker-controlled address, while other transfers involved approximately 970,500 SOL, 44.2 million OP and 18,270 BTC. The attackers also exploited Ethereum’s EIP-7702 authorization mechanism to grant a malicious smart contract partial execution rights over a Binance hot wallet. “EIP-7702 allows an account to delegate certain execution rights to a smart contract without exposing the private key. In this case, the attacker used that mechanism to give an attacker-controlled smart contract partial execution rights over a Binance hot wallet.” the company states. Suspending withdrawals wasn’t enough to stop the transfers because the malicious authorizations already existed on-chain and operated independently of Binance’s normal withdrawal infrastructure. Binance had to develop a specific procedure to revoke them. The use of Multi-Party Computation (MPC) meant there was no single private key that could immediately invalidate the unauthorized permissions. The final unauthorized transfer, involving 2,961.9 ETH, was finalized at 23:56 UTC. Binance cleared the malicious authorization at 00:10 UTC on October 30. The company estimates that approximately $6.34 billion in assets were affected, of which around $2.85 billion had been frozen or intercepted as of its November 3 update. Binance says it will absorb the financial impact and has already replenished 98% of the affected token assets, based on figures reported on October 31. The exchange has rebuilt the affected wallet infrastructure and internal AI tool, replaced compromised devices, revoked associated credentials and tokens, and strengthened endpoint monitoring and wallet-service controls. It is also engaging independent cybersecurity firms to review the incident. The attack highlights the need to treat recruitment processes, developer workstations and internal AI applications as part of the corporate attack surface. Technical assignments should run in isolated environments, deployment credentials should be short-lived and tightly restricted, and internal AI tools should never inherit unnecessary access to sensitive systems. Binance also said its security team had detected and prevented 57 suspected North Korea-linked cyber threat cases during 2026. These included fake job interviews, malicious developer tools, compromised software packages and browser extensions, fake video-conferencing applications and campaigns designed to steal credentials or deploy remote-access malware. The incident is another reminder that attackers don’t always need to break directly into critical infrastructure. Sometimes, compromising the people and tools that manage it is enough. “We are sharing this initial report because security improves when the industry learns together.” concludes the update. In September, Japan’s National Police Agency, the FBI, the US Department of Defense’s Cyber Crime Center, and intelligence agencies from Australia and Germany published a joint advisory about a group called WaterPlum, better known as Contagious Interview. The name says it all. The job interview is the infection vector. The numbers in the advisory are hard to shrug off. At least 30,000 devices infected across more than 100 countries, funds or credentials stolen from over 7,000 cryptocurrency wallets, and a total of 1.7 billion yen, roughly $10.71 million, funneled back to North Korea. The victims are almost always the same type: freelance developers and specialists in blockchain and Web3 work. Japan’s NPA and the FBI assess that both WaterPlum operators and some North Korean IT workers report to the same place, the 313 General Bureau of the Munitions Industry Department, under the Workers’ Party’s Central Committee. That’s not a loose affiliation. It’s an org chart. The trap itself is almost embarrassingly simple. WaterPlum actors pose as recruiters or hiring managers, often impersonating real AI, crypto, or NFT companies, and reach out on social media, job boards, and freelance platforms. Candidates get invited to a technical interview, then told to download a file to complete a coding test or fix a supposed bug on the video call. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Binance)
Large language model hijacking attacks, also known as LLMjacking, are generating large fraudulent cloud charges, with some organizations losing more than $100,000 per day. Companies can record costs as high as $1 million due to fraudulent calls using stolen API keys, researchers at Google's Threat Intelligence Group (GTIG) and Mandiant in analyzed incidents. Based on their observations, there are "two distinct operational clusters coordinating to compromise and monetize enterprise LLM infrastructure." The researchers identified two categories of threat actors: those who scan for publicly exposed LLM endpoints and those who steal valid API keys from unprotected machines. After gaining initial access, the attackers sell it to services known as LLM mixers, which provide their subscribers with unauthorized access to LLMs.
Confirm this action.
Leaving now will discard your changes.