You are browsing the archive for Anti-*.

Beyond good ol’ Run key, Part 89

October 7, 2018 in Anti-*, Autostart (Persistence)

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!


I added:

  • HKLM\SOFTWARE\Microsoft\Windows NT\
    CurrentVersion\Image File Execution Options\

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.


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:


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.

Reusigned Binaries – Living off the signed land, Part 3

August 4, 2018 in Anti-*, Anti-Forensics, Compromise Detection, Forensic Analysis, Living off the land, LOLBins, Reusigned Binaries

When I wrote two first parts of this series I used the title ‘reusigned binaries’. The title is of course very cheesy because it’s a portmanteau of ‘reuse’ and ‘signed’. How predictable…

Now… while in the meantime there was a lot going on in this space f.ex. the LOLBIN/LOLBAS ‘movement’ took off culminating in many cool Twitter posts and an excellent repo of LOLBin ideas and recipes collected by @Oddvarmoe, there is always… more.

Seasoned pentesters use reusigned binaries for a long time so it’s not a new concept.

The most obvious case scenarios are:

  • use native OS programs, and scripts that are signed and make them do something they are not supposed to (–> ‘traditional’ LOLBins helping to break detection rules focusing on process trees, offering various ways of side-loading, persistence, bypassing filters, etc.)
  • use popular, legitimate (and often signed) dual purpose tools and abuse them (e.g. nmap, netcat, psexec, etc.)
  • use common, legitimate non-OS software components (that are NOT dual purpose, and are very often signed) to do something they are not supposed to (–>LOLBins/Other sections e.g. NVidia’s nvuhda6.exe, PlugX abusing lots of legitimate apps for sideloading purposes; vulnerable /unpatched/ drivers that are signed, load beautifully and can be exploited, etc.)

The last item is very interesting. I believe this is potentially a part of the arsenal (and should be a subject of some serious research) of any futuristic offensive security team.

Let me give you an example…

While looking at a large corpora of driver installers (note: not drivers in a sense of kernel mode drivers, but more like drivers for peripherals like printer, scanner, etc.) I noticed the following

  • many of them reuse the same libraries/executables across many products of the same vendor
  • some of them do like using many modules that are often split across many files/libraries (atomic operations/library)
  • there are often no security checks in place – programmers write the modules in a context of their projects w/o thinking too much about security implications (why should they…, right?)
  • code is often ‘funny’ and includes debugging/verbose flags, test code, offensive, or anti-tampering code, etc. (if you need specific examples, just google ‘Conexant Keylogger’, ‘Sony rootkit’, ‘Denuvo protection’, etc.)
  • the code is SIGNED – let me repeat that!!!

So… when I first started thinking of this I did some poking around, combing through libraries and lots of code and I quickly found a number of signed DLL libraries that can be very easily abused to intercept keystrokes (i.e. build a foundation of a proper Keylogger!). Typically, one has to create a shared memory section named in a specific way, create a window receiving messages, sometimes create an event/mutex, sometimes prepare some structure in memory, call the API named something along the lines of ‘InstallHook’  and… a keylogger is born.

You know where it is heading…

I believe that further analysis of ‘clean’ software – no matter how popular as long as signed – will result in toolkits being developed that reduce the amount of ‘own’ offensive code and leveraging existing signed binaries to deliver the ‘bad’ part of the offensive work – one that modern blue teams try to find so much. Using signed binaries to do that is a really step forward as it may potentially fool many security products that so heavily rely on signing, reputation, whitelisting, and virustotaling. There is obviously a need to develop a binder code that makes it all work, but I guess this can be achieved either via VBS, VBA, mshta, msbuilder, powershell, c# snippets, or even instrumented execution of code that can be driven using signed binaries relying on scripts (e.g. windbg script, debugging via powershell, etc.). And of course, the opportunities of using unsigned plug-ins, documented and undocumented command line switches, etc.

It’s perhaps not a very practical post – I’ve been actually thinking a lot whether I should post a PoC of a keylogger based on one of the legitimate signed DLLs I found – but in the end I decided not to enter a dubious legal area I don’t have much experience with (I don’t’ want vendors to come after me, basically); still, I hope the post provides enough food for thought to carry on with your own experiments. All you need is a lot of clean signed samples (drivers, software), and some creative research ideas…