Tracking Administrator Sessions in Windows Environments

Tell Me MoreTracking users with privileged access is a critical task in your security policy (SANS Critical Security Control #12). If the key point is to restrict the number of “power users” to the lowest, it’s not always easy. Most of them will argue that they need administrator rights “to be able to perform their job in a convenient way“. Really? Tell me more… The goal of this blog post is not to discuss how to reduce the number of key users but to create an extra control to track them. Some Microsoft OS versions like Windows 7 or 2008 R2 have a tool called “Shutdown Event Tracker” that prompts for a reason why the admin needs to restart or shutdown the computer. My idea is to ask to administrators to explain why they start a privileged session on a workstation or a server via the same kind of tool. IMHO, this is complementary to tracking the sessions at a technical level.

I searched for existing solutions but, except commercial packages, I did not find any relevant (and simple!) stuff so, I wrote my own script. Written in PowerShell, it is quite simple. Executed as a logon script (deployed via a GPO or locally), it first checks if the user has administrative rights. If not, it exists silently. Otherwise, it builds a form and displays it to the user:

Admin Tracker Popup

The popup window will remain open while the administrator does not input some information about his session. The provided data will then be saved as a new Windows event log:

Event Log

By default, the script creates an event log with the following details:

  • Log name: Application
  • Source: AdminSessionTracker (created if required)
  • Event ID: 1

It can be changed to match your own environment but keep in mind that the “Security” log is not available from PowerShell – only the lsass.exe process can write to it! In the same way, PowerShell does not fill the User field. The script adds the user and domain in the message. I decided to create an eventlog because it makes it easily accessible from many third-party tool. Once the information stored in the EventLog, it’s easy to process it via your favorite log management or SIEM solution. Here are the messages collected via my OSSEC agent, the logon event and the corresponding tracking details:

2015 Sep 20 17:10:48 (virtual-desktop)>WinEvtLog 2015 Sep 20 17:11:17 WinEvtLog: Security: AUDIT_SUCCESS(4624): Microsoft-Windows-Security-Auditing: Xavier: virtual-desktop: virtual-desktop: An account was successfully logged on. Subject:  Security ID:  S-1-5-18  Account Name:  VIRTUAL-DESKTOP$  Account Domain:  xxxxxxx  Logon ID:  0x3e7  Logon Type:   10  New Logon:  Security ID:  S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx  Account Name:  Xavier  Account Domain:  virtual-desktop  Logon ID:  0x39eedcc  Logon GUID:  {00000000-0000-0000-0000-000000000000}  Process Information:  Process ID:  0xca8  Process Name:  C:\Windows\System32\winlogon.exe  Network Information:  Workstation Name: VIRTUAL-DESKTOP  Source Network Address:  Source Port:  50824  Detailed Authentication Information:  Logon Process:  User32   Authentication Package: Negotiate  Transited Services: -  Package Name (NTLM only): -  Key Length:  0  This event is generated when a logon session is created. It is generated on the computer that was accessed.
2015 Sep 20 17:11:25 (virtual-desktop)>WinEvtLog 2015 Sep 20 17:11:55 WinEvtLog: Application: INFORMATION(1): AdminSessionTracker: (no user): no domain: virtual-desktop: User:Xavier|Domain:virtual-desktop|Message:Testing the script. Redaction of blog post ongoing. Checking the event viewer.

Based on these events, it’s easy to generate an alert if the tracking message is empty (this is clearly a suspicious activity!) or to generate a report containing the following details:

Timestamp, Admin user, Host, Reason of the session

Keep in mind that the goal of the script is not to be bullet-proof. It can be killed, bypassed, etc… It is more a “security awareness” tools to remind the administrators that they are logged with privileged rights. The script is available here.


  1. Hi, have applied this, but it automatically closes and continues to load the desktop after 60 seconds. Is there something in group policy to fix this? I’ve tried Computer Configuration>Administrative Templates>System>Scripts>Maximum wait time for Group Policy scripts & Run logon scripts synchronously and it made no difference. Windows Server 2008 R2. Error noted inn Event Viewer is: The winlogon notification subscriber took 60 second(s) to handle the notification event (StartShell).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.