What Is Backup Tampering?
Backup tampering is the unauthorized alteration, encryption or deletion of backup data, backup catalogs or backup configuration. It covers changes to the protected copies themselves and changes to the systems that schedule and describe them, since a modified retention setting can remove a recovery point as effectively as deleting the files.
Why backup tampering matters
Attackers worked out some years ago that encrypting production is only half the job. An organization that can restore has no reason to pay. Backup infrastructure is therefore attacked first, and quietly: jobs are disabled, retention windows shortened, repositories dropped from schedules, and the catalog edited so the console still reports success.
That quietness is what separates tampering from outright destruction. A deleted repository is obvious within a day. A retention policy cut from 90 days to three, or a job silently removed from its schedule, may not surface until someone attempts a restore weeks later and finds the recovery point gone. By then the tampering sits inside the backup history itself.
Detection depends on comparing what the backup system reports against what the storage actually holds, and on making sure the account that runs backups cannot rewrite the record of what it did.
Example: retention shortened, nothing deleted
An attacker obtains the service account Veeam uses to authenticate to its repository. Rather than deleting anything, they shorten retention on the daily job from 30 days to two and let the software's own housekeeping expire the older restore points over the following nights. Every job continues to report success and monitoring stays green. Six weeks later the organization needs a restore point from before the intrusion and finds the oldest available copy is two days old, created well after the attacker was already inside. Nothing was deleted by hand. The backup system was instructed to delete it.
How backup tampering relates to ARTESCA
Retention on ARTESCA is enforced by the storage layer through S3 Object Lock rather than by the backup application's configuration. Once an object version is written under a compliance-mode lock, shortening a retention setting in the backup software does not shorten the lock, and neither the backup service account nor a storage administrator can remove that version before its date passes.
That separation is the point. Tampering usually works by changing settings rather than by defeating storage, so the control that holds is the one living outside the software being tampered with. Storage identities are managed within ARTESCA rather than inherited from the production directory, which limits what a compromised backup account can reach to begin with.
Related terms
- S3 Object Lock — WORM retention applied to individual object versions by the storage layer.
- WORM (write once, read many) — data that can be written once and read often, but never modified.
- Administrative blast radius — how much one compromised identity can reach, change or destroy.
- Restore testing — periodically recovering data and verifying it is complete and usable.
- Safe copy isolation — keeping a known-good copy separated from the environment it protects.