July 22, 2011

Elevate privileges using Task Scheduler 2.0

In this post I’ll describe how a standard user can run a pre-defined script or process with elevated rights, using the Task Scheduler 2.0.

Task Scheduler 2.0, built into Windows 7, provides great flexibility, but also presents challenges to enterprise I.T. departments. In managed, highly secure environments, a job scheduler is normally centralised, controlled and monitored. Having thousands of client-side schedulers is frankly a headache. While I.T. are trying to virtualise components to make the clients stateless, they may be unaware of critical batch processes that have become tied into the desktop estate – by developers or power users.

So why not just disable the service? Microsoft have made this difficult by moving important core OS actions that were previously background services into task scheduler actions, and encouraging ISVs to do the same. Refactoring the default task actions using alternative methods isn’t easy either. Many of the actions are hidden behind COM interfaces. Assuming we’re not disabling the Task Scheduler any time soon, let’s get back to making use of it.

So what if we need users to be able to perform an elevated task that cannot easily be delegated through an ACL change? A simple example is “IPCONFIG /release && "IPCONFIG /renew”. On Windows 7 this requires elevation.

At first glance the the Task Scheduler doesn’t seem to offer a solution. By default, a standard user cannot schedule a task with elevated rights. (Having said that, the Stuxnet worm was able to exploit a zero-day flaw in the Task Scheduler’s handling of its XML configuration files, allowing a standard user to elevate to SYSTEM. This has since been patched by MS10-092).

“Event triggers” provide the work-around we need.

As an administrator, pre-create a scheduled task that runs in the SYSTEM context. The task action is to run the IPCONFIG release/renew command. For the task trigger, set it to “on an event” and specify an existing Event Source with a custom Event id that won’t “clash” with a real event. For example, Log “Application”, Source "EventSystem”, Event ID “100”.


Finally, create a shortcut for the user that will log the “EventSystem” ID 100 event in the Application Log. When the non-admin user clicks on the shortcut, the event will be logged and will trigger the Scheduled Task to run the IPCONFIG command in the SYSTEM context.

The Powershell Write-EventLog command is one option to log the event. As long as an existing Event Source is used, the entry can be written without administrative privileges.


That’s all there is to elevating privileges using the Task Scheduler.

No comments:

Post a Comment