I'm unsure under which thread I should post, so here is a new one.
Most responses look at one installation of keepass and that you already need to have access to a user. On the other hand in an enterprise environment it is most likely way easier to modify a configuration file than changing anything (without being monitored/alarmed) in the context of the user.
An possible attack scenario might be to change the default startup-script to generate (or manipulate) the xml and after a few minutes try to upload the exported file to a remote location. Sounds like a promising way to get passwords from many users without the need to do anything on a per user basis.
I'm not saying that with the same rights you might also have the right to do stuff as the user, but it might be less prone to detection this way.
A user needs to enter their "master password" before database is unlocked - after which the silent export can be triggered. Just changing values inside the XML does not expose the passwords.
Most responses look at one installation of keepass and that you already need to have access to a user. On the other hand in an enterprise environment it is most likely way easier to modify a configuration file than changing anything (without being monitored/alarmed) in the context of the user.
An possible attack scenario might be to change the default startup-script to generate (or manipulate) the xml and after a few minutes try to upload the exported file to a remote location. Sounds like a promising way to get passwords from many users without the need to do anything on a per user basis.
I'm not saying that with the same rights you might also have the right to do stuff as the user, but it might be less prone to detection this way.