We’ve been focusing a lot on logons lately to make Cyber Triage as powerful as possible and are pushing out content (such as our recent posts on LocalSessionManager and RemoteConnectionManager) to help spread knowledge about this sometimes confusing space. This blog post is all about the various types of sessions you will come across within Windows and Cyber Triage when dealing with logins.
Notably:
- Windows Logon Session – Focuses on security and access permissions.
- Windows Local Session – Focuses on desktop layout and logon sessions for interactive logons
- Cyber Triage Logon Session – Focuses on attempts at a user to gain local or remote access to a host.
We’re going to dive into each of these so that you understand why it exists and which event log files are referring to what kind of session.
What is a Windows Logon Session?
Let’s start with the session that most DFIR users are familiar with, logon sessions. Windows creates one or more logon sessions after a successful authentication and the logon session represents the identity and permissions of that authenticated user.
Microsoft defines “a logon session is a computing session that begins when a user authentication is successful and ends when the user logs off of the system.”
There are several types of logon sessions, notably:
- Interactive
- Network
- Service
Each session has a security token that is used when accessing files and other resources.
Here are some interesting facts about logon sessions to give some context about how they are used:
- Every Windows process runs within the context of a logon session. The process has the permissions associated with the security token from that session.
- A thread within a process can run with permissions from a different security token (retrieved from another logon session).
- When a user with administrator privileges logs in and UAC is enabled, two logon sessions are created. One with a security token that has administrator privileges and one that does not. The one without administrator privileges is used by default.
- When a user has an interactive login, a logon session is also created for SYSTEM-level services that run for as long as the user is logged in.
- When a user unlocks their computer, a lightweight “network logon session” is created to verify the correct password was entered, but the session is immediately closed because it is no longer needed. The session was created as a byproduct of verifying the password.
You can use the LogonSessions tool from Sysinternals to see how many logon sessions you have at a given time. Try it. You’ll be surprised at how many there are. On a random system with one interactive logon, there were 13 logon sessions.
For those of you who think in terms of event logs, a Security log 4624 event is created every time a logon session is created.
What is a Windows Local Session?
Local Sessions are more about user experience than security. When you log into a Windows computer and get a desktop displayed to you, the “Local Session” represents that experience. This includes the window layout and what logon sessions are running to support that interactive experience.
Local Sessions are how Microsoft supports Fast User Switching, which allows you to login in as a different account without logging out of the initial one. And it’s what allows you to locally log into a system, start some processes and move windows around, and then remotely log in and have the same setup.
The Local Session Manager is part of Remote Desktop Services (formally called Terminal Services) and is responsible for determining if a user already has a local session that should be reconnected or if a new one needs to be created. A new local session is created after a system start or after the user explicitly logs out. The same session is used across disconnects or screen locks.
There are far fewer local sessions that get created than logon sessions. Local sessions are created for all interactive logons, but not network logons.
Not much is explicitly defined about what is entailed with a local session, but we did find this Microsoft reference. The below quote uses “LSA logon session” to refer to the previous logon session and uses “terminal services (TS) session” to refer to “local session” (which is managed by what was previously known as terminal services):
“Note that these LSA logon sessions are orthogonal to terminal services (TS) sessions. TS sessions include interactive user sessions at the console and remote desktops, and “session 0”, in which all service processes run. A process’ access token identifies the LSA logon session from which it derived, and (separately) the TS session in which it is running. Although most processes running as System (logon session 0x3e7) are associated with session 0, there are two System processes running in every interactive TS session (an instance of Winlogon.exe and Csrss.exe). You can see these by selecting the Session column in Process Explorer.”
You can see these sessions getting created and reconnected in the TerminalServices-LocalSessionManager/operational log, such as Event 21 below. If the login was for a local interactive session, then the source address is “LOCAL”. Otherwise, it’s an IP address. You’ll notice the session IDs are much smaller numbers for local sessions than logon sessions.
What is a Cyber Triage Logon Session?
Cyber Triage parses several event logs to show you when a user accessed a system. To satisfy all of the DFIR use cases, we had to create our own definition of a session. The main difference is when it begins and ends.
A Cyber Triage Logon Session:
- Begins when a user attempts to gain access. The Cyber Triage Logon Session is created even if the authentication fails. This includes a new login or a reconnect.
- Ends when a user either logs off or disconnects.
Notable differences from the other types of sessions:
- The other sessions only start after a successful authentication, but Cyber Triage needs to show the user when failures occurred.
- The other sessions span reconnects, but each reconnect can come from a different IP. We want to show our users each unique IP that a remote connection came in from.
Cyber Triage makes its logon sessions by parsing various event log files, identifying which events overlap (such as 4624 events from Security, 21 from LocalSessionManager, and 1149 from RemoteConnectionManager), and correlating start and end events. It will then show you in the ‘Sources’ tab which events were used to define the session.
You can then use the application to start at a high-level and simply view all users who logged in. Or, view user and IP combinations to see outlier IP ranges. From those high-level groups, you can then dive into session details. Here’s an example where we can see the user coming in from both internal and external IPs:
Cyber Triage can also use the start and end times to map activity back to a logon session so that you can determine where the user was logging in from when the activity occurred. In this example, a Data Accessed artifact for a Word document is associated with a remote login.
Logins Are Complicated
Computers have to do a lot of work to enable interactive logins and there are lots of event logs that get created during that process. They can be complicated to parse manually and sometimes terminology is not always consistent.
Hopefully, this blog post helped to identify how all of these sessions have different life spans and purposes. If you’d like to see the Cyber Triage logon session in action, try the 7-day evaluation.
