Standard Processes in Windows 10

On the 29th of June, Microsoft announced  the release of Windows 10, so it is time to have a deeper look at this new Operating System from the perspective of an Incident Responder. To make it easier for you to read the screenshots, I have chosen USERNAME and HOSTNAME as names for themselves.

The tool Process Hacker (http://processhacker.sourceforge.net) still functions in Windows 10 and shows well-known process names, parent-child relationships and familiar faces from former Windows Operating Systems. But the familiarity is short-lived. Some players are new and some players have changed their position on the playground.

System still has the PID 4 and is the parent of the Windows Session Manager. I will also mention that it still resides at %systemroot%\system32\. All services are started from executable files from their former locations, if not mentioned otherwise in this article.

There are still two Client Server Runtime Processes (csrss.exe), one of which has the same parent as wininit.exe from an ended smss.exe process. Every additional user on this host (either as a “Switched User” or via Remote Desktop Connection) has its own Client Server Runtime Process since Windows NT.

Process view on a Windows 10 virtual machine

Some old and new changes

The super-process winit.exe spawns services.exe, lsass.exe and the invisible lsm.exe process to start the Local Session Manager. Starting from Windows 8, lsm.exe is started inside a Service Host process from svchost.exe from the command line %systemroot\system32\svchost.exe -k DcomLaunch.

The Local Session Manager Service lsm.exe does not show up in your preferred Task Viewer any longer as its own entry, but in the Services console as an “unchangeable” service.

The Local Session Manager has moved under the hood of svchost.exe

The WinLogon Service, which is responsible for Interactive Logons on a Windows Operating System,  remains where it has always been for Session 1 and is started for every interactive user session. The screenshot above shows only winlogon.exe, dwm.exe (the Desktop Window Manager) and one instance of explorer.exe per user session started. As was already changed between Windows 7 and Windows 8, the Desktop Window Manager no longer exists as a child of svchost.exe, executed with the credentials of the current user. In Windows 8 and 10 it is spawned from the Windows Logon process as user Window Manager\DWM-1 with the start of the Operating System. For every new user on the Host the digits count from DWM-2 and up.

Another new name for the Task Host

Renaming is another interesting topic. The Microsoft OneDrive Client Application called OneDrive.exe, started from %userprofile%\AppData\Local\Microsoft\OneDrive\OneDrive.exe, is a new starter on the playground of Windows for every new session. But why this is a 32-bit process on a 64-bit machine can only be answered by Microsoft. It must be a real secret; why shouldn’t it be possible to develop their Office 365 file sharing client in a 64-bit flavor? At least they renamed the client from Skydrive.exe to OneDrive.exe.

And Microsoft has renamed the Host Process for Windows Tasks again. In Windows 7 it was named taskhost.exe, in Windows 8 it was called taskhostex.exe and the new name is taskhostw.exe in Windows 10. A look at the name of the Taskhost process is sufficient to recognize the OS version from now on.

The primary purpose, serving as a generic “Host Process”, remains unchanged, as does the location in %systemroot%\system32\.

Surprise, Surprise

Let’s open some typical built-in applications and see what happens. In this case, I was executing cmd.exe from the “Run” dialog and started a Pathping against my own virtualized host machine. The Console Windows Host conhost.exe has been running as a child of cmd.exe since Windows 8, and not as a child of csrss.exe as it was in Windows 7. The executable file for Pathping is a child of cmd.exe in the same way conhost.exe is. There is no longer any separation of conhost.exe under the user’s own Client Server Runtime Service csrss.exe and the cmd.exe process under explorer.exe. If you open a second or third Command Prompt, Windows 10 opens a Console Window Host for each of them.

But you can have a whole new experience if you start the new Microsoft Edge web browser, the successor of Internet Explorer. Microsoft Edge starts four processes:

• Two processes named MicrosoftEdgeCP.exe, started from C:\Windows\SystemApps\..\ with the permission of the current user. Microsoft Edge starts with two of them for the first visible tab inside the browser window. Both are child processes of RuntimeBroker.exe, which is a child of svchost.exe, the Host Process for Windows Services. Runtime Broker starts automatically with the Operating System.
  A new MicrosoftEdge process is started under the Runtime Broker Service for every new tab that is opened by the browser. Microsoft is also introducing the new path %systemroot%\SystemApps and starting a web browser as a sub-child of svchost.exe, which breaks traditions in the process design.
• Directly spawned from svchost.exe is the process MicrosoftEdge.exe (without “CP” at the end of the file name). This is the main browser application process. And again, the executable file is saved in a subfolder of C:\Windows\SystemApps.
• The Host Process svchost.exe starts a fourth executable file called browser_broker.exe.
  This time Microsoft is following its own design traditions and has stored the file in the well-known path %systemroot\system32\.

My personal Virtual Machine was a pre-release version, updated automatically to the RTM version of Windows 10. This might be the reason for the weird randomized-looking folder name for the Edge Browser.

A view of Edge and the corresponding processes

What is missing? Any process under the Explorer process. Despite MicrosoftEdge being a visible application on the Desktop, there are no processes spawned as a child of explorer.exe.

At first I thought there might be a problem with the Process Hacker tool I was using to enumerate the processes on this virtual Windows 10 machine. So I checked my findings locally on the virtualized host with Microsoft’s highly underestimated “Super Weapon”: WMIC.

My command was:

wmic process where “name like “%Edge%” OR name like “%broker%” OR ProcessID=”832″” get name,ProcessID,ParentProcessId

And this was the output:

In this case I queried for the PID 832 from svchost.exe to show you the relationship between all mentioned processes. If you follow all parent-child dependencies you can see the validation of the GUI-based output.

What does it look like if you use the Windows Task Manager?

MicrosoftEdge.exe, easily identified by the name of the executable file and the PID, shows up under “Apps” together with other foreground applications, despite it being started as a child of the svchost.exe process. As soon as you right click on this entry and check the properties for MicrosoftEdge.exe, a new dllhost.exe process called “COM Surrogate” is started from %systemroot%\system32\ with the permissions of the currently logged on user. Other user-specific services like csrss.exe are marked as Background processes.

The browser_broker process and the MicrosoftEdgeCP.exe instances are running under the tab “Background processes”, too. Since MicrosoftEdgeCP.exe and MicrosoftEdge.exe have the same shown description text and path from %systemroot%\SystemApps, they can only be identified on the Details pane by comparing the file names.

Conclusion

Microsoft maintains a lot of already known process structures, but has made some unusual decisions when it comes to the way their new web browser Edge is started. Hosting all related processes as a (sub-)child of an already shared Service Host instance doesn’t seem to be a logical decision. By introducing a new path for the stored executable files of Microsoft Edge under %systemroot%\SystemApps, the next needless confusion is created.

And confusion is a good topic to explore: renaming taskhost.exe to taskhostex.exe and then to taskhostw.exe is one example of something that makes it harder for Incident Responders to identify malware which tries to hide “in plain sight”. We can probably all hazard a guess at which names and similar-looking paths will be used in the near future by the creators of malware. But one thing did not change with the introduction of Windows 10: you need third-party tools to unveil what is really running on the Operating System.