Windows GUI Forensics-Session Objects, Window Stations, and Desktop
In this article series, we will take a look at the Windows GUI forensics which is often not discussed. We will take a look at the various structures and how they can be parsed using Volatility Plugins. As always I will try to bring in as much context as I can and will keep it as simple as possible.
Windows GUI subsystem handles user inputs, look and feel of the interface, isolation of different user environments, etc. From a forensics perspective, it becomes important to understand all the objects in GUI, their structure and what all information can be gathered from them while they are in memory. There are different types of windows stations in Windows for example stations that require user input like WinSta0 are interactive stations whereas those which operate at background are non-interactive stations. As stated earlier in this article series we will look at the various objects that reside in the subsystem.
The complete envelope type structure that relates objects like Session, Desktop, and Windows Station looks like below:
It is worth pointing that before Windows Vista, there was only Session 0 to handle services and user mode processes under Session 0 only. From Vista onwards, there are two session object created: Session 0 to handle services and Session 1 to handle user mode processes.
There are various ways for users to log into a system like Remote Desktop Protocol (RDP), console, etc. and for each of these, the kernel creates a session for each user. The session has a structure called as _MM_SESSION_SPACE, and its structure is as below.
This is being pointed from _EPROCESS structure member _EPROCESS.Session. For more information on _EPROCESS structure look at my earlier article here.
To parse these structures and to know which users log in over RDP, we will use Volatility’s ‘session’ plugin.
We can see the rdpclip.exe file in above screenshot. It is used to handle remote clipboard operation like copy, paste, etc. To map the interesting process back to the user, we will use Volatility’s getsids plugin. Plugin getsids will take process pid as input and will display the associated users SIDs.
To map the workflow of events around RDP usage, EventID does also help to build context.
A snip from my other article on RDP EventID’s
- The presence of EventID 4778 indicates the presence of an RDP session initiation. Note that this is just initiation; the user has not been authenticated yet. This EventId can show us IP address and hostname from where the request for an RDP has been initiated from
- After EventID 4778, look out for EventID 4624 which will mean that the authentication has been accepted. This EventId 4624 will be of what login type? Any Guesses. Yes, you got it right, it will Logon Type 10.
- Once the system is authenticated, all the steps mentioned in the previous section like network share mapping, schedule tasks can be seen to build the security context.
- For log off, we will see a similar 4634/4647 events followed by RDP session termination event 4779.
As stated earlier window stations can be interactive and non-interactive. Structure that represents them is tagWINDOWSTATION, and its members are listed below:
Now there are some members of the structure which are very important and worth noting
- dwSessionId: Represents the owing session ID
- iClipSequenceNumber: An incremental variable which represents a number of objects copied to the clipboard. It gets incremented by 1 for each successive copy.
- rpwinstaNext: Linked list is enumerating Window stations.
- dwWSF_Flags: Station is interactive or non-interactive.
- spwndClipViewer: Which process is currently viewing the clipboard contents
- spwndClipOnwer: Owner for process listed in spwndClipViewer
Now this structure can be parsed using Volatility’s winds can plugin. Below is a snippet of wndscan plugin for WinSta0.
As you can see the Name is WinSta0 for Session 2 and Interactive Flag is set to true here. Oher important things to note here are the Desktops listed: Default, Disconnect, and Winlogon(more on these shortly). Also, iClipSerialNumber is nine which mean that nine items have been copied to the clipboard so far. Though spwndClipViewer is not set it should be PID 2408 as it is rdpclip.exe and that process is used for clipboard operations over RDP.
The desktop object is the container for all user interface objects. As mentioned under Session object section, on login a user is assigned Winsta0. Under Winsta0 there are three types of desktop:
- Winlogon: This desktop represents the login screen to the user and is interactive since it accepts user inputs.
- Default: On logon, Winlogon desktop switches to Default login which is user desktop
Structure that represents desktop is tagDESKTOP and its members are listed below:
Some of the important members are:
- dwSessionId: Represents the owing session ID
- rpdesknext: All desktop station information in the current window station
- rpwinstaparent: Parent Window Station of the desktop.
The desktop structure can be parsed using Volatility’s plugin deskscan. Below is a sample snipped output from deskscan
As you can see above for Winlogon desktop there is only one window (although there can be more).Only winlogon.exe process threads belong under Winlogon Desktop.
Above is the Default desktop and it has 16 windows listed, which makes sense since a lot of windows are required for multiple processes.
Below is a screenshot of Disconnect desktop.
So in this article, we have taken a look at some important GUI objects: Session, Window Station and Desktop. In the next article of this series, we will take a look at some other important GUI objects.