Hosting provider FirstVDS confirmed hacking part of its infrastructure on October 17. Through a vulnerability in the VMmanager 6 virtualization system, attackers stole files from client servers, including passwords, access keys, and crypto wallets. The victims were called upon to protect their accounts and money urgently.
The attackers took advantage of the vulnerability in the virtualization management software and launched a special data theft program on the part of FirstVDS physical servers. The malicious tool connected the disks of client virtual machines in read-only mode, extracted the necessary files and sent the collected information to the external server of the attackers. The provider confirmed the transfer of data outside its infrastructure.
The main feature of the attack is that the attackers did not need to hack each client server separately. The program worked at the infrastructure level of the hosting provider, did not run inside virtual machines and did not change the contents of their disks. Therefore, the leased servers continued to operate as normal, and their owners could not detect the initial theft according to the standard operating system logs.
In personal notifications, FirstVDS indicated that on October 17, the files of the affected servers could be available to outsiders from 12:27 to 22:34 Moscow time. The potential access window was 10 hours 7 minutes. The company recommended that all the secrets that were on the affected machines be considered compromised, even if the specific fact of copying individual files has not yet been established.
The potentially stolen data includes SSH keys, system passwords, application configuration files, KeePass and GPG storage contents, saved browser passwords and cookies. .env files, Docker settings, PostgreSQL, MySQL, MongoDB and Redis connection strings, Restic and Borg backup system passwords were also threatened.
A particular danger is the possible compromise of cryptocurrency assets. On virtual servers, private wallet keys, validator keys and seed phrases could be stored, allowing you to restore access to cryptocurrency. FirstVDS recommends that owners of such wallets immediately transfer funds to new addresses created on another, knowingly secure device. A simple change of password from the old wallet will not eliminate the threat if the intruders have already received the original secrets.
The consequences can go far beyond the hosting itself. Among the potentially disclosed secrets, the provider named the accounts of AWS, Google Cloud, Microsoft Azure and OpenStack, the settings of Kubernetes and Terraform, as well as the tokens GitHub, GitLab and npm. The files could contain OpenAI and Anthropic API keys. Access to such data can allow attackers to penetrate other cloud environments, source code repositories and automatic program assembly systems. There is no evidence of such secondary attacks yet.
The vulnerability was found in VMmanager 6, a platform of the Russian company ISPsystem, part of the Astra Group. The product is designed for centralized management of virtual machines and allows administrators to work with several clusters of physical servers at once. Such architecture turns the management system into a particularly sensitive infrastructure point. Having access to the privileged components of the platform, the attacker can potentially reach the resources of several customers.
FirstVDS did not disclose the technical details of the vulnerability, the method of initial penetration and specific versions of VMmanager 6, which allowed the attack. There is also no public CVE ID for the error used. From the message of the provider it follows that the intruders compromised the virtualization management system, but the reason to claim that the isolation of the hypervisor KVM was hacked directly.
After the discovery of the invasion, FirstVDS disabled external access to the virtualization management system and blocked the IP address of the server to which the stolen files were sent in its network. The developer of VMmanager has released an interim correction, but it has not yet been possible to completely close the vulnerability. Until the final patch is released, the provider intends to maintain access restrictions in order to prevent re-enterence in the same way.
The work of administrative instruments also affected the work of administrative instruments. According to the FirstVDS status panel, on October 18 at 15:58 Moscow time, the authorization remained inaccessible in three VMmanager panels. At the same time, the personal account, DNS services and automatic backup were displayed as working staff. The inaccessibility of individual management functions does not mean that the virtual servers themselves have stopped serving sites and applications.
The exact number of affected customers and virtual machines has not yet been named. The owners of the servers, which found signs of attack, sent personal notifications by e-mail and through the personal cabinet. On the afternoon of October 18, at 15:25 GMT, FirstVDS reported on additional mailing to server owners on nodes with signs of possible compromise. The investigation is ongoing, so the final scale of the incident could still change.
Customers who have received a warning are advised not to be limited to changing the password from the VDS itself. It is necessary to replace all private keys, database passwords, cloud services tokens, repositories, payment systems and programming interfaces that were stored on the server. Older keys should be withdrawn, since the release of new credentials does not in itself deprive intruders of access through previously issued permits.
Special attention is required by the third-party services. FirstVDS advises checking logins to cloud accounts, repositories and crypto exchanges from unknown IP addresses after October 17. If the stolen keys have already been used for re-infiltration, someone else's records in authorized_keys, additional users, cron tasks or systemd services may appear on the virtual machine. Such traces refer to possible follow-up actions of intruders, rather than initial copying of virtual disks.
The provider also warned about the legal consequences for companies that placed their users' personal data on the affected servers. According to article 21 of Law No. 152-FZ, when establishing the fact of improper access to personal data, which caused a violation of the rights of their owners, the operator is obliged to notify Roskomnadzor within 24 hours from the moment of detection of the incident, and within 72 hours to provide the results of internal investigation. The applicability of claims depends on the circumstances of the case.
So far, FirstVDS has not reported how much information the attackers have managed to withdraw, how many customers have experienced confirmed data theft and whether penetration has led to financial losses. The company promises to publish the technical review after the completion of the investigation. Already established circumstances show how dangerous the hacking of the overall virtualization management system can be. Even a well-functioning and carefully protected client server is not able to independently stop the theft of files if the attackers have access to the infrastructure on which its drives are located.
The attackers took advantage of the vulnerability in the virtualization management software and launched a special data theft program on the part of FirstVDS physical servers. The malicious tool connected the disks of client virtual machines in read-only mode, extracted the necessary files and sent the collected information to the external server of the attackers. The provider confirmed the transfer of data outside its infrastructure.
The main feature of the attack is that the attackers did not need to hack each client server separately. The program worked at the infrastructure level of the hosting provider, did not run inside virtual machines and did not change the contents of their disks. Therefore, the leased servers continued to operate as normal, and their owners could not detect the initial theft according to the standard operating system logs.
In personal notifications, FirstVDS indicated that on October 17, the files of the affected servers could be available to outsiders from 12:27 to 22:34 Moscow time. The potential access window was 10 hours 7 minutes. The company recommended that all the secrets that were on the affected machines be considered compromised, even if the specific fact of copying individual files has not yet been established.
The potentially stolen data includes SSH keys, system passwords, application configuration files, KeePass and GPG storage contents, saved browser passwords and cookies. .env files, Docker settings, PostgreSQL, MySQL, MongoDB and Redis connection strings, Restic and Borg backup system passwords were also threatened.
A particular danger is the possible compromise of cryptocurrency assets. On virtual servers, private wallet keys, validator keys and seed phrases could be stored, allowing you to restore access to cryptocurrency. FirstVDS recommends that owners of such wallets immediately transfer funds to new addresses created on another, knowingly secure device. A simple change of password from the old wallet will not eliminate the threat if the intruders have already received the original secrets.
The consequences can go far beyond the hosting itself. Among the potentially disclosed secrets, the provider named the accounts of AWS, Google Cloud, Microsoft Azure and OpenStack, the settings of Kubernetes and Terraform, as well as the tokens GitHub, GitLab and npm. The files could contain OpenAI and Anthropic API keys. Access to such data can allow attackers to penetrate other cloud environments, source code repositories and automatic program assembly systems. There is no evidence of such secondary attacks yet.
The vulnerability was found in VMmanager 6, a platform of the Russian company ISPsystem, part of the Astra Group. The product is designed for centralized management of virtual machines and allows administrators to work with several clusters of physical servers at once. Such architecture turns the management system into a particularly sensitive infrastructure point. Having access to the privileged components of the platform, the attacker can potentially reach the resources of several customers.
FirstVDS did not disclose the technical details of the vulnerability, the method of initial penetration and specific versions of VMmanager 6, which allowed the attack. There is also no public CVE ID for the error used. From the message of the provider it follows that the intruders compromised the virtualization management system, but the reason to claim that the isolation of the hypervisor KVM was hacked directly.
After the discovery of the invasion, FirstVDS disabled external access to the virtualization management system and blocked the IP address of the server to which the stolen files were sent in its network. The developer of VMmanager has released an interim correction, but it has not yet been possible to completely close the vulnerability. Until the final patch is released, the provider intends to maintain access restrictions in order to prevent re-enterence in the same way.
The work of administrative instruments also affected the work of administrative instruments. According to the FirstVDS status panel, on October 18 at 15:58 Moscow time, the authorization remained inaccessible in three VMmanager panels. At the same time, the personal account, DNS services and automatic backup were displayed as working staff. The inaccessibility of individual management functions does not mean that the virtual servers themselves have stopped serving sites and applications.
The exact number of affected customers and virtual machines has not yet been named. The owners of the servers, which found signs of attack, sent personal notifications by e-mail and through the personal cabinet. On the afternoon of October 18, at 15:25 GMT, FirstVDS reported on additional mailing to server owners on nodes with signs of possible compromise. The investigation is ongoing, so the final scale of the incident could still change.
Customers who have received a warning are advised not to be limited to changing the password from the VDS itself. It is necessary to replace all private keys, database passwords, cloud services tokens, repositories, payment systems and programming interfaces that were stored on the server. Older keys should be withdrawn, since the release of new credentials does not in itself deprive intruders of access through previously issued permits.
Special attention is required by the third-party services. FirstVDS advises checking logins to cloud accounts, repositories and crypto exchanges from unknown IP addresses after October 17. If the stolen keys have already been used for re-infiltration, someone else's records in authorized_keys, additional users, cron tasks or systemd services may appear on the virtual machine. Such traces refer to possible follow-up actions of intruders, rather than initial copying of virtual disks.
The provider also warned about the legal consequences for companies that placed their users' personal data on the affected servers. According to article 21 of Law No. 152-FZ, when establishing the fact of improper access to personal data, which caused a violation of the rights of their owners, the operator is obliged to notify Roskomnadzor within 24 hours from the moment of detection of the incident, and within 72 hours to provide the results of internal investigation. The applicability of claims depends on the circumstances of the case.
So far, FirstVDS has not reported how much information the attackers have managed to withdraw, how many customers have experienced confirmed data theft and whether penetration has led to financial losses. The company promises to publish the technical review after the completion of the investigation. Already established circumstances show how dangerous the hacking of the overall virtualization management system can be. Even a well-functioning and carefully protected client server is not able to independently stop the theft of files if the attackers have access to the infrastructure on which its drives are located.
