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.