There is a relatively old, but well-known debugging mechanism called SilentProcessExit. It is documented on Microsoft site, and there are many blogs talking about it (@Oddvarmoe has a very good into post about it and you should have a glance before you continue reading below).

I was curious how it works under the hood, and this post is about it. What motivated me to look at it in a first place was the fact that I saw a potential to abuse it to spawn arbitrary processes via svchost.exe / werfault.exe combo – with them acting as ancestor/parent processes to our program of choice e.g.:

I was curious if I could do it _without_ setting up Registry Settings under HKLM. If it worked, we would have yet another evasion possibility.

The function triggering this activity is called RtlReportSilentProcessExit and it is called from ntdll.dll before programs terminate.

If SilentProcessExit Registry settings are set up properly for the exiting program (either via gflags.exe tool, or manually), the aforementioned API will ‘talk’ to WER Service. As a result, the latter will launch a predefined Monitoring program as per the SilentProcessExit Registry settings (if configured).

I speculated, that if I can find out how the RtlReportSilentProcessExit API works, and in particular, how it talks to the WER service, I will be able to either force it to launch my program of choice, or at least rip its code to ‘talk’ to the WER service myself, and most importantly (and hopefully) – w/o the SilentProcessExit Registry Settings in place.

After a lot of spelunking, I realized a few things:

• RtlReportSilentProcessExit is talking to WER services via ALPC; Alex Ionescu (no surprises here) covered (PDF Warning) this mechanism on a high level a few years ago.
• Th ALPC port is named \WindowsErrorReportingServicePort
• The ALPC interaction that RtlReportSilentProcessExit initiates just tells WER to handle the SilentProcessExit and provided the Process ID; I was really expecting to have more influence over this bit 🙁
• The WER Service that the RtlReportSilentProcessExit API talks to is hosted by svchost.exe:
  • WerSvc = C:\Windows\System32\svchost.exe -k WerSvcGroup
  • It loads the %SystemRoot%\System32\WerSvc.dll
• After looking at WerSvc.dll I confirmed that the HKLM Registry settings required for SilentProcessExit to work are mandatory 🙁
• The WerSvc.dll handler extracts a file name of an executable that is exiting, then checks an associated IFEO Registry key, and if GlobalFlag value name exists and has a flag 0x200 set, it will launch the werfault.exe – the latter will execute the predefined Monitoring Process

So… the conclusion is this: we can trigger execution of this mechanism via RtlReportSilentProcessExit without exiting the program, and the svchost.exe/werfault.exe combo will launch the Monitoring Program of your choice, but you do need these Registry settings in place (GlobalFlag and Monitoring Program).

At the moment I can’t think of any practical use for it, but I guess it’s good to know why the Monitoring Program process is spawn by the werfault.exe.