Der folgende Artikel wurde zunächst von mir in englischer Sprache verfasst und veröffentlicht. Dies ist nun die deutschsprachige Übersetzung und sie wirkt – wie so viele Texte aus dem englischen Original – stellenweise holprig. Der gesamte Bereich der Incident Response (sic! :-) ist sehr stark amerikanisch geprägt und für zahlreiche englische Fachbegriffe gibt es auf diesem Feld einfach keine gängige, fachlich korrekte Übersetzung in die deutsche Sprache. Sorry 🙂
Der Einfachheit halber habe ich für diesen Artikel den Benutzernamen USERNAME und als Name für die virtuelle Maschine HOSTNAME gewählt. Warum englische Namen? Weil dieser Artikel von mir im Original auf dem Blog von SANS, dem führenden US-amerikanischem Trainingsanbieter für IT-Sicherheit und IT-Forensik, unter
http://articles.forensicfocus.com/2015/08/06/standard-processes-in-windows-10/ veröffentlicht wurde.
Das Tool Process Hacker funktioniert auch unter Windows 10 und zeigt die altbekannten Namen von Prozessen, ihre parent-child Beziehungen und Beschreibungen aus vorherigen Windows Client- und Serverbetriebssystemen. Allerdings nur auf der ersten Blick. Einige Spieler sind neu auf dem Spielfeld, andere haben ihre Nummer geändert und Microsoft Edge sorgt für einige Überraschungen. Später mehr dazu.
System startet, wie gehabt, mit PID (Process Identifier) 4 und der Windows Session Manager stammt davon ab. Soll ich erwähnen, daß diese Prozesse aus %systemroot%\system32 mit ihren ausführbaren Dateien gestartet werden? Alle erwähnten Prozesse stammen – soweit nicht anders erwähnt – aus dem System32 Verzeichnis. Es gibt nach wie vor gleich nach dem Start zwei Client Server Runtime Prozesse names csrss.exe, einer der beiden Prozesse hat die gleiche PPID (Parent Process Identifier) wie wininit.exe, geerbt von einer wieder beendeten und nicht mehr sichtbaren smss.exe Instanz. Jeder weitere Benutzer auf diesem System, egal ob via Remote Desktop oder als paralleler Benutzer angemeldet, hat seinen eigenen Client Server Runtime Prozess. Seit Windows NT übrigens.
Ansicht der Prozesse eines Windows 10 Clients mittels Process Hacker
Einige neue und alte Änderungen
Der Super-Prozess wininit.exe startet die Prozesse services.exe, lsass.exe und … nein. Der Prozess lsm.exe, der Local Session Manager, fehlt. Bereits seit Windows 8 ist der Local Session Manager kein eigener, sichtbarer Prozess mehr, sondern wird durch den Service Host Process svchost.exe mit
%systemroot\system32\svchost.exe -k DcomLaunch
gestartet. In Windows 10 findet man diesen Service in der Services Konsole, allerdings sind darin alle Menüs, mit denen man das Verhalten des Local Session Manager ändern könnte, ausgegraut und unveränderbar, auch für einen Administrator.
Der Service Local Session Manager befindet sich nun in der Obhut von svchost.exe
Der Dienst WinLogon, der die angemeldeten Sitzungen unter Windows verwaltet, blieb unverändert und eine weitere Instanz wird für jede interaktive Benutzeranmeldung gestartet. Der oberste Screenshot zeigt, dass für einen Benutzer nunmehr nur winlogon.exe, dwm.exe (verwaltet die Darstellung des Desktops) und eine Instanz von explorer.exe gestartet werden.
Schon vom Sprung von Windows 7 zu Windows 8 wurde das Startverhalten des Desktop Window Managers geändert: lief dieser Dienst zuvor als Sub-Prozess unter dem Service Host mit den Rechten des angemeldeten Users, ist er jetzt ein Sub-Prozess von winlogon.exe. Seine Berechtigungen erhält er vom User Window Manager\DWM-1, wobei die -1 für jeden weiteren Benutzer, der auf dem Betriebssystem interaktiv angemeldet ist, hochgezählt wird.
Mal wieder ein neuer Name für den Task Host
Die Umbenennung von Prozessen ist ein weiterer interessanter Punkt. Der Client für OneDrive namens OneDrive.exe, gestartet aus %userprofile%\AppData\Local\Microsoft\OneDrive\ ist neu und wird für jede Nutzersitzung gestartet. Warum dies allerding der einzige 32-Bit Prozess auf einem 64-Bit Betriebssystem ist, kann nur von Microsoft selbst beantwortet werden. Warum die Entwicklung eines 64bittigen Office 365 Filesharing Clients nicht möglich sein soll, bleibt wohl deren Geheimnis. Zumindest wurde der Filesharing Client von Skydrive.exe zu Onedrive.exe umbenannt.
Und Microsoft hat den Dienst für Windows Aufgaben schon wieder umbenannt. In Windows 7 hieß er noch taskhost.exe, in Windows 8 war es taskhostex.exe und nun heisst dieser Dienst taskhostw.exe in Windows 10. Der eigentliche Zweck, als generischer Hostprozess für Windows Aufgaben (Tasks) zu dienen, bleibt unverändert. Ebenso sein Pfad aus %systemroot%\system32\.
Überraschung!
Öffnen wir nun einige typische Anwendungen und schauen uns an, was passiert. In diesem Fall habe ich cmd.exe aus dem Dialog Ausführen gestartet und das Kommando Pathping gegen meinen eigenen, virtuellen Host ausgeführt. Der „Console Windows Host“ conhost.exe läuft seit Windows 8 als Subprozess von cmd.exe und nicht länger als Subprozess von csrss.exe, dem Client – Server Runtime Prozess. Die ausgeführte Datei pathping.exe ist ebenso wie conhost.exe von cmd.exe abgeleitet. Die Anwendung pathping.exe wird nicht länger als Subprozess von explorer.exe ausgeführt. Jede weiter Anwendung, die innerhalb des Command Prompts cmd.exe ausgeführt wird, hat ihren eigenen conhost.exe Prozess. Damit unterscheiden sich die Abhängigkeiten deutlich gegenüber Windows 7 und älteren Betriebssystemen.
Die größte Überraschung wartet allerdings bei der Ausführung von Microsoft Edge, dem neuen Standardbrowser von Microsoft. Microsoft Edge startet vier Prozesse:
- Zwei Prozesse mit Namen MicrosoftEdgeCP.exe aus dem Pfad C:\Windows\SystemApps mit den Berechtigungen des angemeldeten Benutzers. Diese beiden Prozesse sind mit dem ersten Tab innerhalb des Browserfensters vorhanden. Für jeden weiteren Tab, der beim Browsen geöffnet wird, wird ein neuer MicrosoftEdgeCP.exe Prozess gestartet. All diese Prozesse sind Subprozesse des Dienstes RuntimeBroker.exe, der wiederum vom zentralen Service Host svchost.exe gestartet wird. Ganz nebenbei führt Microsoft hier den Pfad %systemroot%\SystemApps ein und bricht mit dieser Kopplung von Prozess und Dienst mit bisherigen Traditionen des Systemdesigns.
- Direkt von svchost.exe wird der Prozess MicrosoftEdge.exe gestartet (ohne „CP“ am Ende des Dateinamens), offensichtlich der eigentliche Prozess für den Webbrowser. Und auch hier liegt die ausgeführte Datei im Pfad %systemroot%\SystemApps
- Der Dienst svchost.exe startet die vierte und letzte Anwendung mit Namen browser_broker.exe, sobald der Webbrowser Edge ausgeführt wird. Dieses Mal allerdings folgt Microsoft dem bekannten Prozessdesign und speichert die Datei im Pfad %systemroot%\system32\
Der Webbrowser Microsoft Edge und seine abhängigen Prozesse
Was fehlt hier ganz offensichtlich? Gestartete Prozesse unterhalb der eigentlichen Desktop Anwendung explorer.exe. Üblicherweise ist explorer.exe der Elternprozess aller interaktiv genutzen Anwendungen auf einem Windows PC, doch Microsoft Edge startet davon keinen einzigen. Um eine fehlerhafte Anzeigt durch das Tool „Process Hacker“ auszuschließen, habe ich zu Microsofts Geheimwaffe gegriffen: WMIC.
Mit dem Befehl:
wmic process where "name like "%Edge%" OR name like "%broker%" OR ProcessID="832"" get name,ProcessID,ParentProcessId
Erhielt ich dieses Ergebnis:
In diesem Fall habe ich direkt nach dem Prozess mit der PID 832 gefragt, um die Eltern-Kind Beziehungen zwischen den erwähnten Prozessen auch auf der Kommandozeile aufzuzeigen. Die gezeigten PID (Process Identifier) und PPID (Parent Process Identifier) bestätigen das, was zuvor schon Process Hacker angezeigt hat.
Wie sieht es nun im Windows Task Manager aus?
MicrosoftEdge.exe, einfach durch seinen Namen und die PID identifizierbar, wird unter „Apps“ angezeigt, obwohl als Subprozess von svchost.exe gestartet und nicht von explorer.exe. Sobald man auf den Eintrag mit rechts klickt und die Eigenschaften anschaut, wird dafür eine Anwendung namens „COM Surrogate“ aus %systemroot%\system32\ mit Anwenderberechtigungen gestartet. Andere, benutzerspezifische Prozesse wie z.B. csrss.exe, werden im Windows Task Manager als „Background processes“ gezeigt.
Die Prozesse browser_broker.exe und MicrosoftEdgeCP.exe werden ebenfalls als Hitnergrundprozesse aufgeführt. Da MicrosoftEdgeCP.exe und MicrosoftEdge.exe identisch bezeichnet werden und beide aus %systemroot%\SystemApps gestartet wurden, können sie beide nur durch den Vergleich der Namen der ausgeführbaren Dateien identifiziert werden.
Fazit
Microsoft behält in Windows 10 zahlreiche, jahrelang bekannte Prozessstrukturen bei, hat an einigen Stellen allerdings sehr merkwürdige Designentscheidungen getroffen, besonders beim neuen Webbrowser Edge. Die für Edge notwendigen Prozesse durch den Service Host und davon abhängige Dienste zu starten, macht keinen logischen Eindruck. Durch die Einführung des Pfades %systemroot%\SystemApps für die ausführbaren Dateien von Diensten wird nur eine vollkommmen unnötige Verwirrung geschaffen. Verwirrung ist ein gutes Stichwort: die Umbenennung von taskhost.exe zu taskhostex.exe und nun taskhostw.exe ist eines der Beispiele, die es einem Incident Responder schwerer machen, Viren und Trojaner zu erkennen. Ich bin mir sicher, welche Namen ausgeführter Prozesse künftig durch Trojaner mißbraucht werden wird. Eines aber ändert sich auch mit Windows 10 nicht: es sind Apps von Drittanbietern notwendig, um zu erkennen, was wirklich auf dem System ausgeführt wird.
1