Beyond good ol’ Run key, Part 88

September 8, 2018 in Anti-Forensics, Autostart (Persistence)

This is one more post to describe a case where I came across a Windows feature and then wanted to analyze how the whole thing works only to find out someone already did it before…

Windows Error Reporting allows the applications to register ‘custom runtime exception handler that is used to provide custom error reporting for crashes’ via WerRegisterRuntimeExceptionModule API.

In practice, the application needs to add a name of the DLL under this key:

  • HKLM\SOFTWARE\Microsoft\Windows\
    Windows Error Reporting\
    RuntimeExceptionHelperModules

and then call the WerRegisterRuntimeExceptionModule API.

When crash occurs the WER engine enumerates all the registered runtime exception handlers for the application and loads them via LoadLibrary and calls their functions exported allowing them to ‘claim’ this particular crash. It only loads the DLLs registered via WerRegisterRuntimeExceptionModule  though. This is a bit of a limitation, but one could discover the presences of such exception helper module and swap it so that next time the other application (the one that registered it) crashes, the swapped DLL will be loaded.

This allows to not only achieve a persistence (although not very reliable as it depends on a crash of some application), but also load the code into the space of WER process – most likely under the nose of many security applications/reversers. As such, it could be a potential sandbox/EDR evasion — register the DLL, call WerRegisterRuntimeExceptionModule, crash your app, the DLL will be loaded under WerFault.exe process. In another scenario one .exe could add the registry entry only, launch the second stage .exe and quit. The second stage would call WerRegisterRuntimeExceptionModule and crash. Both applications would do almost nothing while it’s the exception handler DLL that would do the main work under the Werfault.exe process.

You can see the full example here and an old article on the same topic.

A bit of a qUACkery – how to elevate… w/o doing a single thing ;)

September 7, 2018 in UAC Bypass

Update

After I posted it a number of helpful netizens tried to repro and they found issues, so unless we figure it out treat the below as a subject to unknown conditions that may render it useless a.k.a. non-working trick 🙂

You can follow the twitter convos here. I’ll update the post once I know more.

Old Post

I recently discovered a really funny way to bypass UAC and launch any process with High Mandatory Level.

This is how to reproduce it:

  • As a regular user launch cmd.exe.
  • Confirm the integrity level:

C:\test>WHOAMI /Groups | FIND "S-1-16"
Mandatory Label\Medium Mandatory Level Label S-1-16-8192

  • Launch: sdclt /configure

  • The sdclt.exe program is auto-elevated
  • Walk through the wizard and back up some files; in my case I created a dummy folder c:\test with a small number of files and backed it up
  • Let it finish

  • Now that we have a backup, let’s go to the list of Backups so we can restore some files

  • Choose the backup, then search for c:\test and tick it so you can restore it (it’s all about a small set so we can do it quickly, but you can choose any backup & restore really)

  • Restore files; you should be presented with a panel; it is important that at least _some_ files are restored so we can see the logs

  • Click View Log file
  • This will launch Notepad.exe with elevated privileges
  • In Notepad, go to menu File -> Open -> c:\windows\system32
  • Type cmd*.* so we can see cmd.exe on the list
  • Right click on cmd.exe, hit Open
  • cmd.exe will open –
  • it has S-1-16-12288/High Mandatory Level/A high integrity level.
    C:\Windows\System32>WHOAMI /Groups | FIND "S-1-16"
    Mandatory Label\High Mandatory Level Label S-1-16-12288
  • Launch any program you want – it will be on a High Mandatory integrity level