What is the api to impersonate a local user account without providing the password? RRS feed

  • Question

  • In Windows Vista/7/8/8.1 the task scheduler can execute a task within the security context of a local user account without storing the local account user password.
    This is the case when the task has both the options "Run whether user is logged on or not" and "Do not store password" selected. The only constraint is that the task, with the above options selected, can't access to encrypted files or to network resources.

    I need to develop on a stand-alone machine an highly trusted application (executed as Local System) that executes some tasks within the security context of a local user account without storing the local account user password, the tasks don’t need access to network resources or to local encrypted files. Impersonation of the local user account already logged in is not an option, I need to run the application even when the system restarts and the user doesn’t login to the system.

    Since the task scheduler can do what I need, this means that there must be an api that is able to create a local user access token without providing the user password on disk.
    Does anyone know what this api is?

    Any help you can give will be greatly appreciated.

    P.s.: The machine is stand-alone, not domain joined.

    Thursday, October 24, 2013 5:39 PM

All replies

  • Hi,

    This requires, a Kernel Driver to patch MsvpPasswordValidate located in Msv1_0.dll, these are the functions for Windows NT kernel uses in order to identify the passwords on the logon screen and UAC (User Account Control). 

    To elaborate, more on patching - you need to patch the je instruction with jmp and this should give you the complete control over the function through your hook callback, in the callback you need to compare the cmp operands located above original je or jmp instruction, and to be more safe you need to get the 2nd operand of the cmp instruction and store it in a local variable located in either your callback or a global variable to your Kernel Driver (.SYS), the reason we need to do that is - solely because it provides use with the real password decrypted by Windows. Either we can now simply store it in a *.cab\*.txt file ready for ring3 applications to read or pass it through tunnel between ring3 application and you Kernel Driver. 

    When this is successful, either your ring3 application can either use the real password or use no password however you need to define a "rule" such as if the password is same as "dadada" give the application the elevation, however this is the difficult way - but can open a lot of possibility. 

    I prefer sticking to the token changing method which means you can easily gain Administrative privileges or SYSTEM privileges. 


    Rohan Vijjhalwar

    Sunday, November 3, 2013 10:52 AM