Writing backups to a network share is one of the most common repository designs in small and mid-sized estates. A NAS is already on the network, it presents SMB or NFS, the backup software supports it as a target, and capacity is cheap. The design works well until someone other than the backup software decides to write to that share. In most ransomware incidents that reach the backups, that is exactly what happens, and the reason is almost always credentials.
The problem is not that SMB and NFS are insecure protocols. It is that they are file protocols designed for sharing, and a backup repository exposed through them inherits the access model of a file share: anyone with the right credentials, or the right network position, can modify or delete what is stored there.
How backup shares are usually accessed
An SMB backup share is typically mounted by the backup server using a service account. That account needs read, write and delete rights, because the backup software writes new restore points, merges chains and removes expired data. In many estates the account is a domain account, and in some it is a domain administrator or a member of a group with broad file rights, because that was the quickest way to get the backup working.
NFS shares work differently but end up in a similar place. Access is often controlled by client IP address and user ID mapping rather than by a password. Any host on an allowed address that can present the right user ID can write to the export. Where root squashing is disabled, root on any allowed client is effectively root on the share.
Why credentials are the weak point
An attacker who reaches the domain controller, or any server where the backup service account has logged on, can usually obtain that account's credentials. From there, the backup share is just another network drive. Encrypting it, deleting it or overwriting it requires no exploit and no special tooling, only the access the backup software itself was given.
The same is true of the backup server. If it is compromised, the share is reachable with whatever rights the backup software holds. What survives a compromised backup server depends on whether the repository enforces anything beyond those rights.
| Access path | What an attacker needs | What it allows |
|---|---|---|
| Domain service account on SMB | The account's credentials from any host it has used | Read, modify and delete every file the account can reach |
| Local NAS administrator | The NAS admin password, often reused or default | Delete shares, snapshots and the volumes beneath them |
| NFS export by client address | Control of a host on an allowed address | Write and delete as the mapped user, or as root without squashing |
| Backup server compromise | Administrative access to the backup server | Everything the backup software can do to the share |
| Mapped drive on an admin workstation | A session on that workstation | Direct file access as the logged-on user |
Measures that reduce the exposure
The first is separating the backup service account from the production directory. A local account on the NAS, or an account in a separate management domain, cannot be harvested from a compromised production domain. Separating backup admin accounts covers the wider principle.
The second is limiting where the share is reachable from. Firewall rules on the NAS, or network segmentation that allows only the backup server and its proxies to reach the share, shrink the number of hosts from which an attacker can use stolen credentials. The share should never be mapped as a drive on an administrator workstation.
The third is the NAS's own administrative access. Default passwords, administrative interfaces reachable from the production network and shared admin credentials undo everything else, since an attacker with NAS admin rights can delete snapshots and volumes regardless of share permissions.
None of these measures change the underlying model. They make the credentials harder to obtain and harder to use, but a share that the backup software can delete from is a share that anyone with the backup software's access can delete from.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target. Backup software writes to it through an S3 compatible API using access keys scoped to specific buckets, rather than through a file share mounted with a directory account. With S3 Object Lock enabled, objects written under a retention period cannot be deleted or overwritten until that period expires, including by the account that wrote them.
That changes what stolen credentials allow. An attacker holding the backup software's keys can still write new objects, but cannot remove the locked restore points already stored. It is deployed on servers the customer runs, from roughly 50 TB to 8.5 PB, and is used as a target for Veeam and other backup software. What Object Lock actually guarantees sets out where that protection begins and ends.
Reviewing an existing share-based repository
A short review covers most of the risk. List every account with write or delete rights on the backup share, and every host from which the share is reachable. Check whether the service account is a domain account and what else it can log on to. Confirm that NAS administrative access is restricted to a management network and uses unique credentials. Then ask what would remain if the backup service account were fully compromised tonight. If the answer is nothing, the repository needs a layer that does not depend on those credentials.