– the child doesn’t inherit the privileges, it gets them from BeyondTrust, because it is a trusted application

– the launching process does not need to “take ownership” of the child process, because it already has it given the way the Windows security model is designed.

It may be possible (and in fact desirable) for BeyondTrust and other such solutions to disallow the running of privileged processes by unprivileged ones or at least close the handles very early on (although this solution may have race conditions in it depending on the way it is implemented). I don’t know if this is implemented in BeyondTrust or not because I couldn’t test it.

I would be happy to test this attack and report on it if anyone could provide me with installation instructions of a VM image of it.

In reply to the first comment: yes, a whitelisting applications (like the one you mentioned) would stop such attacks if they came in the form of separate binaries (ie. not arbitrary code exectution vulnerabilities in already trusted applications). A possible threat scenarion in that case would be the following:

– an employee knows that Word is not pached for the latest vulnerabilities
– it creates the above code as the code included in the exploit. The whitelisting application trusts Word, but in fact Word becomes a program which can execute anything after opening the specially crafted document.

While this requires a high level of knowledge, the idea is that most security measures are not perfect.

my name is Marco Peretti, and I am the CTO of BeyondTrust. I have read with interest your article and am writing to let you know that such a simple attack will not work. By default, we strip child processes from inherited privileges thereby reverting them to the default user privileges. Moreover, we protect our processes against fellow processes trying to take ownership and, for instance, inject a remote thread into a process running with elevated privileges.

cheers,

Marco