Windows has a small set of privileges that bypass the ordinary security model instead of participating in it. Most of them adjust what an administrator can do. A few of them are more direct: they let a process read files it has no permission to read, or take ownership of objects it does not own. The backup privilege is the clearest example, and its presence on an account is a decision that is rarely made deliberately.

What the privilege does

SeBackupPrivilege, documented by Microsoft as "Back up files and directories", allows a process to traverse directories and read files regardless of the discretionary access control lists on them. The documented mechanism is a specific flag: an application that opens a file with FILE_FLAG_BACKUP_SEMANTICS while its token holds the privilege is granted read access that the file's ACL would otherwise deny.
SeRestorePrivilege is its counterpart. It allows writing to files regardless of their ACL, and it is the privilege that turns a backup operator into someone who can replace a system binary.
The intended use is obvious and legitimate: a backup agent must read everything, including files owned by users who are not the agent. The consequence is equally obvious once stated. Any process running with that privilege can read the registry hives, the SAM database, the local security authority secrets, and every user's documents — because that is what backing up a system requires.

Why it appears in escalation chains

An account with the backup privilege is worth more than it looks in a group listing. Backup Operators is a built-in group precisely because the privilege is granted to a role, not a person.
The escalation path is well trodden. A process holding SeBackupPrivilege can copy the registry hives and extract local credential material offline. With SeRestorePrivilege alongside it, the same process can drop a malicious binary into a directory it cannot normally write to and wait for a privileged execution path to pick it up. Neither step requires a vulnerability in Windows; both are the documented behaviour of a legitimate capability.
What makes this relevant to defenders rather than attackers is the assignment side. The privilege can be granted through group membership, through a local security policy, through a Group Policy object applied to a service account, or through a scheduled task configured to run with it. Those four paths have different owners and different change processes, and the inventory that matters has to cover all of them.

Where the reviews usually stop early

The first review gap is treating Backup Operators as a benign group. It is not a read-only role. On a domain controller, the privilege reaches the directory database; on a member server, it reaches cached credentials and service account material.
The second is assuming that a service account running backup software is only running backup software. A service account with the privilege is a credential that any process under that account inherits. If the account's password is stored in a scheduled task, a script, or an application configuration, the privilege travels with the password.
The third is the audit trail. Reading a file with the backup semantics flag is a read like any other, and whether it appears in object access auditing depends on audit policy that is frequently disabled because of its volume. The privilege does not leave a distinctive record.

Controls that reduce the exposure

Limit the assignment to the smallest account set that can perform the backup, and use a dedicated account rather than a general administrative one. A backup account that cannot log on interactively and cannot be reused elsewhere is worth the extra configuration.
Use a backup product that does not require standing privileges when one is available. Volume shadow copy and file-level backup services with delegated access narrow the scope considerably, though they do not remove it entirely.
Alert on the privilege being granted outside the change process. A local security policy change, a new group member, or a scheduled task created with the highest privileges is a discrete event with an audit record, and those records are the detection surface.
Treat SeRestorePrivilege as the higher-risk half. Reading files is disclosure; replacing them is execution. An account with restore rights should be narrower than the group that backs up.

The question for the asset owner

When this privilege appears on an account, the useful question is not whether it is needed. It is which files that account can now read that no person in the organisation can read, and what would happen if the account's credential were reused somewhere else. The answer is usually a longer list than the owner expects, and it is the reason the privilege belongs on a short inventory.

References

  • Microsoft, privilege constants: https://learn.microsoft.com/en-us/windows/win32/secauthz/privilege-constants

  • Microsoft, Back up files and directories policy setting: https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories

  • Microsoft, FILE_FLAG_BACKUP_SEMANTICS and file access: https://learn.microsoft.com/en-us/windows/win32/secauthz/privilege-constants