You may have found yourself in a situation where you have access to a system through a limited user account, or could not or did not want to bypass UAC (AlwaysOn setting for example) and you needed to continue running code even when the account logged off and/or the system rebooted (and even if you don’t have the account’s password). For example, as a pentester you may need to set up persistent access after everyone has logged off for the day or as a software developer you may want to run background tasks for maintenance and update. However, most of the backdoors that I have seen that don’t require admin permissions typically use a registry value or a startup folder entry, or another method that will only run code once the current user logs in and will die once the user logs off. Every «legitimate» piece of software that runs code outside of a logon that I have looked into, such as software updaters, requires administrative permissions to install a service or scheduled task that runs as SYSTEM.
I don’t know whether this is due to ignorance on the part of the authors, or if so few systems run for any significant period of time without the main user being logged in that the authors don’t care, or maybe most limited user accounts don’t have the requisite permissions or administrative permissions are just too easy to get. But there are many UAC-protected or shared systems in many homes and businesses and a huge number of backdoors that are now written to run under limited user accounts.
So how do you do it? First, create a scheduled task to run your command with default options as the current user (this will by default create a scheduled task that only runs when you are logged in):
Then export the task as XML:
and delete the task:
Then open the xml file, and replace the line
This can be done with the following commands assuming powershell is on the system:
Now recreate the task from the modified XML file:
and remove your temp file:
Your task will now run in the background every hour regardless of whether you are logged on. Since it will not run interactively, it will not have the cached credentials that an interactive logon will have, so you may not be able to access all of the network resources you were able to before, but you will be running!
What this does is use the Service-for-User or S4U logon type (See http://technet.microsoft.com/en-us/library/cc722152.aspx and http://msdn.microsoft.com/en-us/magazine/cc188757.aspx for an in-depth discussion of S4U from the perspective of Kerberos). The system must be at least Windows Vista to schedule these types of tasks, and the «Logon as batch job policy» must be set for the user. On a Windows 7 Home Premium test system, this was the case for a non-UAC elevated admin, but not for a limited user by default. Of course every Windows domain could be different, so check first before you rely on it.
And enjoy running your scheduled scripts whenever you want, even if you cannot or do not want to elevate to administrative permissions. Also, if you make software that requires administrative permissions to install, please make it work as a limited user; there really are not many excuses left.