What would be Windows without all these hidden, test, debugging features?

I loathe Windows 10 for many reasons and so far do not plan installing it on my computer, but I do welcome all its updates and changes as they provide a fertile soil for research of any sort. New persistence tricks are of course pretty high on my list and I especially welcome these ones that ‘break’ something new.

Such is the case of the persistence trick I am going to cover today: persistence within Metro Apps.

Despite the Metro Apps no longer being plain vanilla PE files they still need to be loaded.

The task of loading them is delegated to WWAhost.exe that launches respective Metro App when we click the app’s icon. For instance, loading and launching Netflix App that you install from the Microsoft Store leads to the following process being created:

• “C:\WINDOWS\system32\wwahost.exe” -ServerName:Netflix.App.wwa

and the current directory of the app is set to:

• C:\Program Files\WindowsApps\4DF9E0F8.Netflix_6.81.325.0_x86__mcm4njqhnhss8\

I am not that familiar with Metro App internals yet, so I got curious about their loading process and started poking around this particular host process. I quickly discovered that it leverages the good old IFEO key and tests for a presence of an entry called ‘WWAInject’.

Ah, how nice…  seeing IFEO and ‘inject’ in the same sentence (a.k.a. one Procmon log row) can only lead to one conclusion: this is probably a new persistence trick!

So…

I added:

• HKLM\SOFTWARE\Microsoft\Windows NT\
  CurrentVersion\Image File Execution Options\
  wwahost.exe\WWAInject=<DLL>

and pointed it to my test DLL.

Then I launched the test Metro App… and… nothing.

Not only it didn’t launch properly, it actually crashed.

Hmm…

Looking at the Procmon logs I discovered that the Access denied was reported for my DLL when the application was loaded. The fact it was accessed was a good sign. The fact it didn’t load… a bit of a disappointment. It then hit me. Metro App are sandboxed and use various mechanisms to restrict access of the protected apps to the local system.

After checking the OS libraries’ rights that are obviously loaded by the wwahost.exe without any problem I noticed that on a file system level they grant access to the following entities:

• APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)
• APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(RX)

I cheated and used icacls with its /save and /restore options to copy the OS library rights to my DLL:

• icacls C:\Windows\System32\rpcss.dll /save c:\test\foo

and then (after editing the name of the DLL) inside the ‘foo’ file to test.dll:

• icacls C:\test\ /restore c:\test\foo

Now the DLL file has all the rights identical with C:\Windows\System32\rpcss.dll and can be loaded via the WWAInject entry with no problem. No more crashes, and the DLL does whatever I want it to.