Category Archives: Undocumented Windows Internals

ALPC Ports

Posted on by

In my post about SilentProcessExit I mentioned an ALPC interface. Programs (clients) using this mechanism usually connect to a specific port (addressed via a unique name), and then exchange messages with a server.

I was curious what other native ALPC ports exist out there apart from WindowsErrorReportingServicePort, and this post is an attempt to list as many of them as possible…

After looking at executables and libraries that reference ZwAlpcConnectPort and NtAlpcConnectPort functions, I came up with this list (port + list of files that references it):

  • \WindowsErrorReportingServicePort
    • Faultrep.dll
    • PsmServiceExtHost.dll
    • WerFault.exe
    • audiodg.exe
    • audiosrv.dll
    • daxexec.dll
    • dwmghost.dll
    • modernexecserver.dll
    • ntdll.dll
    • psmsrv.dll
    • wermgr.exe
    • werui.dll
    • win32kfull.sys
    • winsrvext.dll
  • \PdcPort
    • AzureSettingSyncProvider.dll
    • DeviceDirectoryClient.dll
    • DeviceEnroller.exe
    • InstallService.dll
    • LocationFramework.dll
    • LockController.dll
    • LockHostingFramework.dll
    • MusNotification.exe
    • NcaSvc.dll
    • NetEvtFwdr.exe
    • OneDriveSettingSyncProvider.dll
    • PsmServiceExtHost.dll
    • SensorService.dll
    • SettingSyncCore.dll
    • SettingSyncHost.exe
    • TpmCoreProvisioning.dll
    • WPTaskScheduler.dll
    • Windows.Cortana.OneCore.dll
    • Windows.Devices.Haptics.dll
    • Windows.System.SystemManagement.dll
    • audiosrv.dll
    • bisrv.dll
    • cdp.dll
    • dhcpcore.dll
    • dhcpcore6.dll
    • diagtrack.dll
    • dmcertinst.exe
    • gpsvc.dll
    • modernexecserver.dll
    • moshostcore.dll
    • ncsi.dll
    • networkhelper.dll
    • ngcrecovery.dll
    • omadmclient.exe
    • powrprof.dll
    • qmgr.dll
    • rdbui.dll
    • sysmain.dll
    • termsrv.dll
    • tetheringservice.dll
    • twinui.pcshell.dll
    • ubpm.dll
    • umpo.dll
    • updatehandlers.dll
    • usocore.dll
    • wbiosrvc.dll
    • wcmsvc.dll
    • wer.dll
    • wifinetworkmanager.dll
    • wifitask.exe
    • wpncore.dll
    • wpnprv.dll
    • wuaueng.dll
    • wwansvc.dll
  • \BaseNamedObjects\FontCachePort
    • DWrite.dll
  • \RPC Control\AutoRotationApiPort
    • RotMgr.dll
  • \ConsoleInputServerPort
    • conhost.exe
  • \BaseNamedObjects\msctf.server
    • msctf.dll
  • \SmApiPort
    • ntdll.dll
  • \PowerPort
    • umpo.dll
  • \SmSsWinStationApiPort
    • winsrvext.dll

I know there are a possibly a few more, but static analysis were not worth it to chase after names passed via complex set of arguments/structures and nested functions. We will eventually figure it out anyway.

There is an interesting bit I came across with regards to WER Port (\WindowsErrorReportingServicePort). It would seem that its name is configurable and specified by this Registry Entry:

HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ErrorPort=<Port name>

The thing tho is that some of the Windows components retrieve that name dynamically, and some rely on a hard-coded name…

Another ALPC server that is configured via Registry is WDI ALPC Server:

HKLM\SYSTEM\CurrentControlSet\Control\WDI\Config
ServerName =<Port name>

And that’s it… If anything, at least you can use these names in your further research. There is a possibility some of them don’t check the message data integrity and this could lead to some new vulnerabilities being discovered. And if not, it’s always a good thing to know which strings we come across are actually OS-native. I think ALPC needs a lot more research and we will hear about more of its issues in the future.

Adding some bits here after posting the main post:

The \PdcPort is very interesting as many components ‘talk to it’; quick check confirms that the Port is created by a kernel driver pdc.sys.

SilentProcessExit – quick look under the hood

Posted on by

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.