DEV Community

andreagomez
andreagomez

Posted on

The read-only disk mount that left no trace on the server

#security #zoomeye #vmmanager #hosting

The read-only disk mount that left no trace on the server

FirstVDS described an unusual detail in its 19 October 2026 disclosure. The intruder did not compromise the customer virtual machines directly. The malware mounted their disks in read-only mode, copied the contents, and left the servers running normally. The provider's own wording is that "there are no traces of the attack on the affected virtual servers".
That sentence moves the detection problem up a layer. A tenant who only monitors the guest operating system was never in a position to notice.

Where the evidence actually lives

A read-only attach of a virtual disk is a hypervisor operation. It appears in the management platform's audit trail, in the storage layer's access records, and in the hypervisor's own logs, not inside the guest. If those records are not collected, the operation leaves nothing behind that a guest-side agent can see.
The practical question for a hosting provider is therefore whether the management plane writes an audit record for each disk attach, who can read that record, and how long it is kept. These are configuration decisions made long before an incident, and they cannot be retrofitted afterwards.

Why read-only matters for the attacker

Mounting read-only avoids three problems at once. It does not change file contents, so integrity monitoring inside the guest stays quiet. It does not require the guest to reboot or the disk to be detached from the running instance. It also lets the attacker copy a disk that is in active use, because a read-only attach does not need exclusive access on most storage backends.
FirstVDS lists what the copied data included: passwords, cloud service credentials, configuration files, cryptocurrency wallets and other files. Those are the artefacts that sit in a server's filesystem rather than in a database, which is consistent with a bulk disk copy rather than a targeted application exploit.

Detection ideas that fit the mechanism

A provider can look for read-only attaches that were not initiated by a scheduled backup job, and for attach operations performed by an account that normally does not touch storage. Correlating the management-plane actor with the storage operation is the useful signal, because either record alone is ambiguous.
On the tenant side, the equivalent check is whether the provider exposes an audit feed for management actions affecting the tenant's instance. Many hosting contracts do not include one. Asking for it, and asking what retention applies, is a reasonable step for any customer whose server holds credentials.

The recovery gap

Copying a disk does not break the server, so nothing forces the tenant to act. That is the second half of the problem: the evidence of compromise sits with the provider, the affected credentials sit with the customer, and the customer may learn about it only through a breach notification. FirstVDS told customers who received notices to assume that data on their servers had been stolen, which is the correct instruction and also an admission that per-tenant attribution was not possible.
Rebuilding a server from a clean image does not help if the credentials are unchanged. The disk copy is a one-way disclosure: once a private key leaves the storage backend, only rotation closes it.

A measurement that does not answer this question

ZoomEye can count reachable management interfaces, and on 27 October 2026 the query title="VMmanager" returned 2,823 assets. It cannot tell you whether any of those platforms logs disk attaches, because that is an internal configuration fact. External scanning sizes the exposure; it says nothing about the audit trail that determines whether an attach would be noticed.
That gap is worth naming explicitly. Exposure measurement and detection capability are different questions, and the second one has to be answered from inside the platform.

References

Top comments (0)