Application aware credentials

[dib]

Hi.

Have tried to find some guidance for application aware credentials handling. Does anybody know, if Guest OS credentials get cached on Windows server, so the credentials could get extracted from the system.

Think it could be an issue, if lots of servers in the same job, that uses the same Guest OS credentials. If 1 server gets hacked and the credentials gets extracted, there will be access to all other servers.

/Dennis

[Mildur]

Guest os credentials are stored in the veeam sql db. They are encrypted with the computer Key of the veeam Backup server.
Each hacker/admin with access to the vbr server can decrypt the guest os credentials.

Some other information about that:

https://helpcenter.veeam.com/docs/backu ... ml?ver=100

Particularly, backup proxies must be considered the target for compromise. During backup, proxies obtain from the backup server credentials required to access virtual infrastructure servers. A person having administrator privileges on a backup proxy can intercept the credentials and use them to access the virtual infrastructure.

Another security concern you must consider is protecting the Veeam Backup & Replication configuration database. The database stores credentials of user accounts required to connect to virtual servers and other systems in the backup infrastructure. All passwords stored in the database are encrypted. However, a user with administrator privileges on the backup server can decrypt the passwords, which presents a potential threat.

Some Guidelines to harden your backup enviroment:

https://bp.veeam.com/vbr/VBP/Security/

[dib]

Thank you for the reply, Mildur.

I know that Veeam saves the credentials in its database, that was not my concern. I try to explain better.

If we have a job which contains 30 VM's, we set the Guest OS credentials to an account, that has admin access to all 30 VM's.

Does this account get cached on every VM, so that if one of the VM's gets compromised, that admin account and password could be extracted. And with that account information, there is access to all the other VM's.

[Mildur]

ok, Sorry, I did't get your quostion right
I don't know myself about the caching.

[Seve CH]

If we have a job which contains 30 VM's, we set the Guest OS credentials to an account, that has admin access to all 30 VM's.

If you use NTLM instead of Kerberos, I suppose that an administrator could get your OS Interaction account's password hash and use pass-the-hash attacks to log in to other servers. This could also happen with your agentless monitoring tool if using WMI .

With Linux, if you aren't using user certificates, a local root with a modified SSH server might be able to read your password too.

That is why we have different jobs per environment (for some environments, IT is not always the only one with admin rights) and the possibility to map several guest credentials in the same job.
I.e. Job: EnvironmentA-Job1
Default credential: dummy account (invalid) -> We make sure that if we use an interaction account, it will be intentional.
vSphere label: Job1-AP1 -> user1
vSphere label: Job1-AP2 -> user2
...
This is also useful to interact with VMs in a DMZ/not domain-joined.

In the job settings, use "Customize guest OS credentials for individual machines and operating systems" and map labels to credentials.