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.