A backup server is an ordinary Windows or Linux host with unusually broad reach. It holds credentials for the hypervisor, the storage target, the database estate and often the directory. When an attacker reaches it with administrative rights, the question is no longer whether the backup system is affected. The question is which parts of it can still be relied on during recovery, and which have to be treated as rebuilt from scratch.
The usual answer is that immutable storage solves this, and it does solve part of it. Objects under a retention lock cannot be deleted or overwritten by a client holding the backup server's credentials, because the storage platform enforces the lock independently of whoever is asking. That protects the data. It says nothing about whether the system that indexes, decrypts and restores that data can be trusted afterward, and most of what a restore actually needs is metadata, configuration and keys rather than the backup data itself.
What full control of the backup server actually grants
An attacker with SYSTEM or root on the backup server inherits every capability the backup software has at that moment. That includes job scheduling, repository management, restore operations, and in most products the ability to run code on protected machines through the backup agent, which typically runs with high privilege inside each guest. A backup server is not only a store of data about the estate, it is a distribution channel into it.
It also inherits deletion intent. The attacker can issue delete and retention change calls against every repository the server knows about. Whether those calls succeed is decided elsewhere. A repository presented as a file share complies, since the file system has no opinion about who is asking. A repository behind an object storage API with retention set at write time refuses.
The credentials stored on the host and the account behind them
Backup software stores credentials because jobs must run unattended. A typical server holds a hypervisor service account, guest operating system accounts used for application aware processing, database logins, share credentials, an S3 access key and secret for the object target, and frequently a domain account with more rights than anyone remembers granting. These are stored in a reversible form by necessity, encrypted at rest with a key available on the same machine, so after administrative compromise every one of them should be treated as disclosed.
The access key for the object target is the one that decides the outcome for the backup data. What matters is not that the attacker has it, since that is a given, but what that identity is permitted to do on the storage platform. An identity that can write objects and read them back is a different exposure from an identity that can also delete versions, shorten retention or mint new credentials. The same logic covers the platform's own administrative account, which stops being a separate control the moment it is stored on the backup server.
What immutable objects hold when the server is hostile
Objects that were written and locked before the compromise are the strongest thing in the estate, within limits worth stating precisely. Retention set in compliance mode cannot be shortened or removed by any identity for the duration of the lock. Retention set in governance mode can be lifted by an identity holding the specific bypass permission, which means the lock behaves differently depending on a choice made when the bucket was created.
The second limit is time. Immutability protects a window, not a history. If retention is fourteen days and the attacker was present for six weeks before acting, every restore point still under lock may already contain the intrusion, and the clean ones have aged out. Retention length is a security parameter rather than only a capacity one, and the arithmetic of when a lock expires deserves to be checked against a realistic dwell time.
Sorting the estate into rebuild and trust
The practical output is a short list that divides the environment into what must be rebuilt and what can be used. The division is not a judgment about how sophisticated the attacker was. It follows from where each component sits relative to the compromised host and from what enforces its integrity.
| Component | Position after full compromise | What decides it |
|---|---|---|
| Backup server operating system and application | Rebuild from installation media | Nothing running on the host can attest to its own integrity |
| Stored credentials and access keys | Disclosed, rotate all of them | They are recoverable by any process with administrative rights on that host |
| Catalog or configuration database | Useful but unverified | Whether an export exists outside the host, and how old it is |
| Locked objects in the repository | Intact inside the retention window | Lock mode, retention length, and whether the client identity can alter either |
| Secondary copy on a second target | Intact only if it does not trust the first | Whether the copy was pushed by the same server using the same credentials |
| Storage platform administrative account | Intact if it was never stored on the backup server | Where that credential is held and whether it is distinct from the backup identity |
The catalog deserves more attention than it usually gets. It records which restore point contains which machine at which moment, and without it the repository is a set of opaque objects. Most products can rebuild a catalog by rescanning, which works but runs slowly against a large target. A configuration export and a recent catalog backup, written somewhere the backup server cannot delete, turn a multi day rebuild into an afternoon.
The console itself is a separate question from the data. A rebuilt server with restored configuration is a server whose settings were authored inside an environment under someone else's control, so the console cannot be trusted on the strength of a configuration import alone. Retention settings, job targets, repository definitions and any added accounts are worth reading line by line rather than restoring wholesale.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, with immutability provided through S3 Object Lock and an S3 compatible API that backup products including Veeam address directly. The backup server authenticates to it with an access key belonging to an account defined on the storage side. Permissions for that account, and the retention applied at write time, are configured on the platform rather than in the backup application, so a client asking to remove a locked object is refused by the storage.
Because ARTESCA runs on infrastructure the customer operates, administrative access to the platform, the network boundary around it and the key material are all under the customer's control rather than a provider's. That makes the separation described above a deployment decision: the account used by the backup server and the account used to administer ARTESCA can be distinct identities, held by different people, reachable from different networks. It is far cheaper to set that at installation than to change it once jobs are running.
What to settle before an incident
Write down every credential stored on the backup server and what each one opens. The list is almost always longer than expected, and producing it is a useful exercise in itself. Beside it, record where the storage platform administrative credential is held and how it is retrieved when the directory is unavailable. A credential that only comes out of a domain joined password manager is not available on the day the domain is the problem.
Put configuration and catalog exports on a schedule that lands them somewhere the backup server has no permission to delete, and check the age of the most recent export monthly rather than assuming the job still runs. Record, per bucket or repository, the lock mode and the retention period, and verify once a quarter that the backup identity genuinely cannot shorten retention, by attempting the change and confirming that it fails.
Finally, rehearse the rebuild rather than the restore. Stand up a clean backup server, give it a freshly issued credential, point it at the repository, rescan or import the catalog, and restore a single machine. Time it. That number is the real recovery floor, since every other estimate quietly assumes a backup server that is still trustworthy.