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.

WerFault – command line switches v0.1

Posted on by

I posted about werfault.exe a couple of times before. Some of the posts focused on persistence mechanisms, some on lolbinish behavior, but I thought it would be good to dedicate some time to describe the actual command line arguments this program accepts…

Why?

In my opinion werfault.exe accepts the most bizarre command line arguments combos on Windows platform ever. And despite werfault.exe process being executed so many times we are yet to see a comprehensive description of the switches it relies on. And what makes them stand out is that:

  • at a first glance, they look completely random
  • they use / rely on a bunch of weird, unusual and undocumented arguments, and finally,
  • many of them expect values in a numerical, often hexadecimal format that confuse every single analyst that ever put their eyes on it…

The below summary is my first attempt to take a stab at this topic so it may not be the most complete reference, BUT… we have to start somewhere.

The key to understanding werfault.exe command line arguments is to focus on the first switch being used. Yes, the very first thing werfault.exe is doing when it’s invoked it is checking the why:

  • -e: SQM Escalation
    • -e -p <num> -t <num> -r <num> -a <num> -f <num>
    • -e -p <num> -t <num> -r <num> -a <num> -f <num> -h <num>
  • -k : kernel-related
    • -k -lc <dump file name>
    • -k -lcq
    • -k -q
    • -k -rq
    • -k -l <string> <string> — live kernel
    • -k -lc <string> <string> — live kernel
  • -p: ?
    • -p <num> -h <num>
  • -pr: ?
  • -pss: ?
  • -s: process executed via SilentProcessExit mechanism
    • -s -t <num> -i <num> -e <num> -c <num>
  • -u : user mode
    • -u -p <num> -s <num>
  • /h – elevated hang reporting
    • /h /shared <shared>
    • /h /shared <shared> /t <num> /p <num>
  • /hc – ?
  • ??? -nonelevated – ??

The command line switch separator (- or /) that I listed above is actually important and its hardcoded form is what the program expects and compares against. This is somehow unusual and it escapes a typical pattern we are familiar with (either of these two characters – or / are commonly accepted as switch indicators).

I am aware of many other command line switches, but I am still browsing through the code, so I will update this post when I get more info.

What’s the lessons learned here?

If you see werfault.exe process in Sysmon or 4688 logs try to figure out what their execution is indicating. Sometimes, they may be an early warning of malware trying to do something that is prohibited on newer versions of Windows, but was fully acceptable on older. Also, if any program crashes, and it involves werfault.exe, you can use it to provide a feedback to the vendor/software developer…

There is literally a lot of goodness that can come out from looking at werfault.exe process invocations in general. Whatever crashes, hangs, breaks usual patterns is always an interesting thing to look at.