{"id":5378,"date":"2018-10-07T22:47:42","date_gmt":"2018-10-07T22:47:42","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=5378"},"modified":"2018-10-07T23:04:23","modified_gmt":"2018-10-07T23:04:23","slug":"beyond-good-ol-run-key-part-89","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2018\/10\/07\/beyond-good-ol-run-key-part-89\/","title":{"rendered":"Beyond good ol\u2019 Run key, Part 89"},"content":{"rendered":"<p>What would be Windows without all these hidden, test, debugging features?<\/p>\n<p>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 &#8216;break&#8217; something new.<\/p>\n<p>Such is the case of the persistence trick I am going to cover today: persistence within Metro Apps.<\/p>\n<p>Despite the Metro Apps no longer being plain vanilla PE files they still need to be loaded.<\/p>\n<p>The task of loading them is delegated to WWAhost.exe that launches respective Metro App when we click the app&#8217;s icon. For instance, loading and launching Netflix App that you install from the Microsoft Store leads to the following process being created:<\/p>\n<ul>\n<li>&#8220;C:\\WINDOWS\\system32\\wwahost.exe&#8221; -ServerName:Netflix.App.wwa<\/li>\n<\/ul>\n<p>and the current directory of the app is set to:<\/p>\n<ul>\n<li>C:\\Program Files\\WindowsApps\\4DF9E0F8.Netflix_6.81.325.0_x86__mcm4njqhnhss8\\<\/li>\n<\/ul>\n<p>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 &#8216;WWAInject&#8217;.<\/p>\n<p>Ah, how nice&#8230;\u00a0 seeing IFEO and &#8216;inject&#8217; in the same sentence (a.k.a. one Procmon log row) can only lead to one conclusion: this is probably a new persistence trick!<\/p>\n<p>So&#8230;<\/p>\n<p>I added:<\/p>\n<ul>\n<li>HKLM\\SOFTWARE\\Microsoft\\Windows NT\\<br \/>\nCurrentVersion\\Image File Execution Options\\<br \/>\nwwahost.exe\\WWAInject=&lt;DLL&gt;<\/li>\n<\/ul>\n<p>and pointed it to my test DLL.<\/p>\n<p>Then I launched the test Metro App&#8230; and&#8230; nothing.<\/p>\n<p>Not only it didn&#8217;t launch properly, it actually crashed.<\/p>\n<p>Hmm&#8230;<\/p>\n<p>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&#8217;t load&#8230; 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.<\/p>\n<p>After checking the OS libraries&#8217; 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:<\/p>\n<ul>\n<li>APPLICATION PACKAGE AUTHORITY\\ALL APPLICATION PACKAGES:(RX)<\/li>\n<li>APPLICATION PACKAGE AUTHORITY\\ALL RESTRICTED APPLICATION PACKAGES:(RX)<\/li>\n<\/ul>\n<p>I cheated and used icacls with its \/save and \/restore options to copy the OS library rights to my DLL:<\/p>\n<ul>\n<li>icacls C:\\Windows\\System32\\rpcss.dll \/save c:\\test\\foo<\/li>\n<\/ul>\n<p>and then (after editing the name of the DLL) inside the &#8216;foo&#8217; file to test.dll:<\/p>\n<ul>\n<li>icacls C:\\test\\ \/restore c:\\test\\foo<\/li>\n<\/ul>\n<p>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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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 &hellip; <a href=\"https:\/\/www.hexacorn.com\/blog\/2018\/10\/07\/beyond-good-ol-run-key-part-89\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[43,35],"tags":[],"_links":{"self":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5378"}],"collection":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/comments?post=5378"}],"version-history":[{"count":2,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5378\/revisions"}],"predecessor-version":[{"id":5381,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/5378\/revisions\/5381"}],"wp:attachment":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/media?parent=5378"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/categories?post=5378"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/tags?post=5378"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}