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.
ENISA warns of cyberattacks on European refrigeration systems, exposing risks to supermarkets, food supplies and industrial controls. The European Union has issued a coordinated cybersecurity warning after a series of attacks hit commercial refrigeration systems in several Member States. The incidents, which began in October and continued with a new wave on November 1 and 2, have raised concerns about the security of equipment that plays an essential role in food distribution and other critical operations. In a joint statement published on November 4, ENISA, the European Commission, Europol and European cybersecurity coordination bodies urged organisations to take immediate steps to protect vulnerable systems. “Following a new wave of incidents having occurred on 1-2 November, ENISA, the European Commission (DG CNECT), Europol’s European Cybercrime Centre (EC3), the Network of the EU national computer security incident response teams (EU CSIRTs Network) and the European cyber crisis liaison organisation Network (EU- CyCLONe), advise organisations to take immediate action to mitigate exposure in the affected systems.” reads the advisory. The warning highlights the need for “immediate action to mitigate exposure”, as attackers continue to target systems that are often overlooked in traditional cybersecurity strategies. The attacks have already had tangible consequences. In France, hackers targeted refrigeration management systems used by hundreds of supermarkets, remotely changing their settings and forcing freezers into continuous defrost mode. Some systems reportedly reached temperatures of up to 50 degrees Celsius, destroying large quantities of fresh and frozen food. According to reports, around 300 Intermarché and Netto stores and fewer than 100 Coopérative U outlets were affected. Other retailers also reported disruptions to their cooling equipment. The French incidents also exposed a broader problem: the security of industrial control systems that manage physical processes. These systems are increasingly connected to corporate networks and remotely accessible, but they don’t always receive the same security attention as traditional IT infrastructure. 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. Targeted devices were older Danfoss refrigeration controllers that had reached the end of their support life and no longer received security updates. Other systems were running outdated firmware. Researchers had previously identified vulnerabilities in some Danfoss controllers, including weaknesses that could allow attackers to bypass authentication. However, authorities haven’t confirmed whether those specific flaws were exploited in the attacks. The European response reflects the fact that these incidents aren’t isolated technical problems. ENISA says national cybersecurity teams and EU crisis management authorities are sharing information and coordinating their investigations. The agencies also stress the importance of “rapid information-sharing” and a coordinated response to understand the scale of the campaign and help affected organisations. ENISA has also published a collection of technical advisories from national CSIRTs to help organisations identify the risks and apply appropriate protective measures. These recommendations are particularly relevant to companies operating refrigeration equipment, supermarkets, food distribution networks and other facilities that depend on industrial control systems. The statement also draws attention to existing European cybersecurity legislation. Since September 11, 2026, manufacturers of hardware and software products have been required to report severe incidents and actively exploited vulnerabilities through the Cyber Resilience Act’s Single Reporting Platform. The main cybersecurity requirements of the CRA will apply from December 11, 2027, requiring manufacturers to adopt security-by-design principles and provide security support throughout the product lifecycle, including timely vulnerability fixes. The NIS2 Directive also requires organisations within its scope to manage cybersecurity risks affecting their operations and report significant incidents to their national CSIRT or competent authority. ENISA is supporting these efforts through its Secure by Design and Default Playbook, technical advisories and initiatives aimed at improving product security across the European market. The refrigeration attacks are a reminder that cybersecurity failures can have consequences well beyond data theft or temporary IT outages. Manipulating an industrial controller can destroy food stocks, disrupt business operations and potentially affect services that people depend on every day. Organisations must therefore treat the security of operational technology as a core part of their risk management strategy, rather than an issue to address only after an incident. “The main cybersecurity requirements laid down in the Cyber Resilience Act (CRA) will apply as of 11 December 2027. Manufacturers of hardware and software products (‘products with digital elements’) will be required to implement security-by-design and ensure security support during the lifecycle of such products, including the remediation of vulnerabilities without delay.” concludes the Agency’s advisory. “In addition, entities to which the NIS2 Directive (Directive (EU) 2022/2555) applies must implement measures to manage the cybersecurity risks to their operations, and report significant incidents to their national CSIRT or authority. Furthermore, ENISA is actively contributing to strengthening cybersecurity across the EU by promoting secure-by-design and secure-by-default principles in the EU market.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, refrigeration systems)
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.
Blockchain analysis firm Chainalysis has revealed that its ongoing investigation into the agentic cyber attack targeting its systems also exposed names, usernames, password hashes and live tokens for all users. "While we investigated, we removed access to Reactor and Data Solutions," the company said. "At this time we continue to have no evidence that any investigations data has been accessed
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.
Attackers target IT service desks to bypass MFA by impersonating employees and convincing staff to reset passwords or register new authentication devices. Specops Software explains why traditional identity verification methods are no longer sufficient and how organizations can secure account recovery against social engineering risks.
A cybersecurity incident forced UNM Health to divert ambulances, cancel appointments, and pause care while it contained the threat. On Monday, October 26, the University of New Mexico Health System (UNM Health) faced the kind of security incident that healthcare leaders dread: one serious enough to change how patients could receive emergency care. A major hospital network in New Mexico worked urgently on Monday to fix a cybersecurity problem. The issue forced it to send ambulances to other hospitals and left the state without a hospital emergency department able to treat the most serious injuries. UNM Health operates New Mexico’s only Level 1 trauma center. These centers treat the most serious and complex injuries. Even a temporary closure can put extra pressure on other hospitals. UNM Health runs New Mexico’s only Level 1 trauma center. That matters because a Level 1 center handles the most complex injuries, and losing even temporary access to it puts pressure on every nearby hospital. The organization told patients not to come to its main Albuquerque hospital and canceled appointments across more than 30 clinics. “The University of New Mexico Health System is experiencing a cybersecurity issue at this time. UNM Health officials are actively working to resolve this issue. Currently, all ambulance traffic is being diverted to other hospitals and all appointments at all clinics today have been cancelled. UNM Health patients should not show up to UNM Health facilities on October 26. Emergencies should be handled by 911 and non-emergencies should be delayed until further notice.” reads the update published by the organization on October 26, 2026. “The cybersecurity threat is affecting the entire University of New Mexico Health Sciences Center. “ UNM said its IT security teams identified the threat around 11 a.m. and began containment work. They later said the event affected some end-user devices but did not reach core systems or servers. Leadership activated an Emergency Operations Center, brought in outside support, and notified state and federal law enforcement. That is the right sequence: isolate first, investigate second, communicate continuously. From 12:30 to 2:30 p.m., UN Health temporarily stopped accepting new patients while teams protected the network. “System outages also required the suspension of outpatient surgeries and appointments for the remainder of the day.” This was not an abstract IT problem. Patients arrived for care and were told to reschedule. Staff had to explain, repeatedly, why a hospital visit could not proceed as planned. UNM also canceled classes at its Health Sciences Center and sent nonessential employees home. Medical, nursing, pharmacy, and population health students lost a day of instruction because the institution had to protect its network. Other providers stepped in. Presbyterian Healthcare Services and Lovelace Health System coordinated with UNM and took additional patients, which is exactly what a functioning regional healthcare system should do. UNM Health began restoring its systems on Monday afternoon. By the following day, hospitals, ambulance services and clinics were back to normal. The incident is still under criminal investigation. Employees reported messages claiming that patient, student and staff data had been stolen, but UNM has not confirmed this. The hospital also warned people to watch out for phishing and fraud attempts by attackers exploiting the incident. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, UNM Health)
Attackers can force Android devices into a continuous boot loop using a specially crafted app that requires no permissions and only needs to be installed. To cause the persistent denial-of-service (DoS), the app triggers a vulnerability that researchers dubbed 'GhostMap' that makes Android map a file into an unallocated memory region. The affected process crashes when it attempts to read from that region. Romanian cybersecurity company Bitdefender discovered the flaw while analyzing an Android banking trojan that kept crashing its emulators when it tried to read an application resource. The researchers demonstrated the vulnerability by creating an app that contains no executable code, requests no permissions on installation, and does not need to be launched on the device. According to the company, Google has been aware of GhostMap since August but closed the issue without releasing a patch, classifying it as "not reproducible."
A Canadian man was extradited to the U.S. to face charges over hacking universities and hijacking their computers to mine cryptocurrency. A Canadian man, Ryan James Roach (35), has been extradicted to the United States to face charges tied to a hacking operation that targeted universities and other schools. Roach was extradited on October 28 and now faces federal charges alongside Mathiew James Stubbings, 41, of Ontario. The indictment alleges that, from June 2016 to December 2019, the two men hacked computers, stole login details, and used victims’ machines to mine cryptocurrency for themselves. “They used virtual private servers in multiple countries, which were registered under false names. These servers transmitted malware and mining software to victim computers and stored stolen login credentials.” DoJ states. “Victims of the scheme included educational institutions in New York, Tennessee, North Carolina, and Massachusetts. Some of the computers damaged by the defendants were located at an institution of higher learning in the Western District of New York.” The targets were not random home PCs. Prosecutors say the pair went after U.S. schools with supercomputers, including institutions in New York, Tennessee, North Carolina and Massachusetts. Some affected computers belonged to a higher-education institution in western New York. “To carry out the scheme, Roach and Stubbings surreptitiously accessed victim computers without authorization, deployed malware to gain control, stole victim login credentials, exfiltrated the data to servers that they controlled, and forcing victim computers to use their processing power to mine cryptocurrency for the financial benefit of the defendants.” DoJ continues. That is a lot of effort to turn someone else’s research hardware into a personal crypto rig. The alleged method was also more involved than a single phishing email. The indictment says they looked for weaknesses in victims’ networks, used servers and compromised machines from one victim to hide their tracks, and then moved through the network once inside. The duo used sophisticated techniques and tools to conduct reconnaissance and expand their access within the network. The charges include conspiracy to obtain information from and damage protected computers, obtaining information from a protected computer, and intentional damage to a protected computer. Each carries up to 10 years in prison and a $250,000 fine. Prosecutors also allege the pair damaged at least 10 protected computers in one year and caused at least $5,000 in losses. Roach appeared before U.S. Magistrate Judge Mark W. Pedersen and is being held pending a detention hearing. Extradition proceedings for Stubbings continue in Canada. The FBI, the Justice Department’s Computer Crime and Intellectual Property Section, and the Office of International Affairs worked on the case. For security teams, the useful part is not the alleged crypto-mining. It is the reminder that universities remain attractive targets because they hold powerful computing resources, broad networks, and plenty of people with access. Patch quickly, watch for unusual processing load, and treat credential theft as a serious incident rather than a nuisance. “The fact that a defendant has been charged with a crime is merely an accusation and the defendant is presumed innocent until and unless proven guilty.” DoJ concludes. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, University Supercomputers)
Confirm this action.
Leaving now will discard your changes.