If you are using hosted backup with TSM there is one more step to cover when people leave the org
The protection for many hosted backups are
Protection against “rouge” TSM Administrator
Client Side Encryption
Protection against “rouge” Backup Administrator
Node ID
Node Password (separation of duties one for password one for encryption)
And the last one is the issue here as its often not rotated, default TSM is 90 days but looking at different hosted TSM password is often set to no expire
This is not a TSM problem but a problem with password rotation
In the perfect world, the NodeID password and the encryption is not known by the same person, but then nodeid / password / secret is in registry so an AD admin can access this
Scenario
TSM BA Client installed on demodc01.stackdemo.dk
Starting the TSM client , prompting for Node Password on first backup
Ready for Action
Starting the first backup , prompts for encryption key , and after a short while the backup is completed
On a rouge server, outside of the environment we install the TSM BA Client and reuse the nodeID and password from the disgruntled backup admin
Adding the nodeid and nodepassword
And we restore a dummy file to see that’s its working, and is prompted for the encryption key
dsmc q b “{DEMODC01\SystemState\NULL\System State\SystemState}\ntds.dit” -sub=y
If we can’t remember where ntds.dit is located we can search for it
rest “{DEMODC01\SystemState\NULL\System State\SystemState}\\DEMODC01\C$|\WINDOWS\ntds\*” C:\EVILDC\ -sub=y
And we can restore the files
And we now have something we can attack , if we boot up in a winPE enviroment we can follow the procedure for system state and have a working domain controller
If the attacker had access to the domain controller aka disgruntled former employee the password and encryption is available on the source node in registry , since TSM used both the password and the encryption to access TSM server and backup/restore data it needs to be stored somewhere that the service can access
It’s very hard to protect anything from a domain admin even with the assume breach state of mind
So, we can logon without getting prompted for credentials/encryption
So what can we do
First off , prevent people from being disgruntled
And since we can’t control human nature change the password on the nodes, either scheduled or when high privilege staff leaves or both, and again the default for a TSM node is that it will be changed
Single Node example, log on the TSM , change password
Something old Something New
And Success , and password change can be scripted so cycling the password shouldn’t be a big issue
And our EvilDC can’t access TSM anymore and everything is back to normal