by Windows environments provide a group policy setting which allows a regular user to install a Microsoft Windows Installer Package (MSI) with system privileges. This can be discovered in environments where a standard user wants to install an application which requires system privileges and the administrator would like to avoid to give temporary local administrator access to a user.
From the security point of view this can be abused by an attacker in order to escalate his privileges to the box to SYSTEM.
Identification
Lets assume that we have already compromised a host inside the network and we have a Meterpreter session.
The easiest method to determine if this issue exist on the host is to query the following registry keys:
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
Privilege Escalation with Metasploit
The easiest and the fastest way to escalate privileges is via the Metasploit Framework which contains a module that can generate an MSI package with a simple payload that it will be executed as SYSTEM on the target host and it will be removed automatically to prevent the installation of being registered with the operating system.
Generate MSI Package with PowerSploit
PowerSploit framework contains a script that can discover whether this issue exist on the host by checking the registry entries and another one that can generate an MSI file that will add a user account into the local administrators group.
The verification that this user has been added into the local administrator group can be done by running the “net localgroup administrators” command from the command prompt.
Conclusion
Metasploit Framework can be used as well to generate MSI files however the payload will be executed under the privileges of the user running it which in most of the cases it shouldn’t be the administrator. Therefore the PowerSploit script was the only reliable solution to escalate privileges properly.
In order to mitigate this issue the following settings should be disabled from the GPO:
Computer Configuration\Administrative Templates\Windows Components\Windows Installer User Configuration\Administrative Templates\Windows Components\Windows Installer
Penetration Testing Lab 
Nice article. I would like to focus on this “Lets assume that we have already compromised a host inside the network and we have a Meterpreter session.”
The meterpreter shell has to be launched from an interactive session on remote computer otherwise it won’t work. For example, if you launch it from an xp_cmdshell obtained by an SQLi , you will get this message:
“The Windows Installer Service could not be accessed.
This can occur if the Windows Installer is not correctly installed.
Contact your support personnel for assistance.”
And the detailed log will tell you why:
“Client-side and UI is none or basic: Running entire install on the server.”
I wrote a similar article on my blog: https://decoder.cloud
Thank you for raising this limitation! I will keep an eye on your future blog posts. Good work!
thanks! take a look also at the older ones 😉
Thanks for the post again. I learnt a lot from this blog. However how would you configure a lab to test this vulnerability.
Thanks Emma! In a Windows Server enable the two settings in the GPO that you see in the Conclusion of this article.
Reblogged this on KNX Security – Practical Penetration Test.