Intro
When a privileged domain user (for example, a Domain Admin) is interactively logged on to a Windows server, a local administrator on that system can leverage the Windows Task Scheduler to achieve code execution inside the user’s logon session.
By creating a scheduled task configured to run only when the user is logged on, the attacker can reuse the existing interactive logon token, gaining access to the user’s Kerberos TGT, cached credentials, DPAPI secrets and domain resources, effectively impersonating the domain user without knowing their password.
This behavior is by design in Windows.
How Task Scheduler Enables This
Windows Task Scheduler supports running tasks under a specific user account. Relevant task logon types include:
| LogonType | Description |
|---|---|
| S4U | The task runs using a Service-for-User logon. No password is stored, and Microsoft documentation claims no access to network or encrypted resources. |
| InteractiveToken | The user must already be logged on. The task runs inside the existing interactive session. |
| Password | The task runs using stored credentials. |
| InteractiveTokenOrPassword | No longer in use; currently identical to Password. |
When a task is configured as “Run only when the user is logged on” (InteractiveToken) and the target user already has an interactive graphical session, Windows behaves as follows:
- The task runs inside the user’s logon session
- The existing logon token is reused
- That token already contains:
- The user’s Kerberos TGT
- Cached Kerberos credentials
- DPAPI master keys
- Access to network resources
👉 As a result, the task can request Kerberos Service Tickets (STs) using the user’s existing TGT and authenticate to domain services under the user’s identity.
Privilege Abuse Scenario
Even if a user does not normally have permission to create scheduled tasks, a local administrator who can obtain or reuse a HOST service ticket for the system may still be able to create or trigger such tasks.
The only strict requirement is that the target user must have logged on interactively, meaning they entered credentials at the Windows logon screen and established a graphical session.
From Microsoft’s perspective:
- Windows is behaving as designed
- Local administrators are assumed to be trusted
From a security architecture perspective:
- This is dangerous in Active Directory environments
- It enables credential reuse and lateral movement
- It is especially risky when Domain Admins log onto servers
In practice, this turns any compromised server where a Domain Admin logs
Prerequisites
- Local administrator privileges on the target system
- A privileged domain user already interactively logged on
- Ability to create or trigger a scheduled task
- Task configured as:
- Run only when the user is logged on
- Running under the target user account
No password, hash, or direct credential material is required.