Windows 10 UAC username/password passing

[benthebear]

Howdy autohotkey community! have a bit of a quagmire for you. i have a small .ahk script but cant seem to get it working.
here is the deal, I'd like to have a .ahk script with a hotkey shortcut(like pressing crtl+w ) that will pass a username and password to the windows 10 UAC prompt.
I thought it'd be a simple coding but can not figure it out....It is okay if the password is stored in plain text for this small project.
Any help would be greatly appreciated.

I have attached a screenshot of the specific UAC windows that pops up when one tries to run a program as administrator.

Again thank you in advance for any advice or help you can provide.

[ManualColdLock]

you can try

Code: Select all

^w::
send,username{Tab}password{Enter}
return

no idea how it will react with a uac window though

[qwerty12]

Odd question, IMHO The dialog is not meant to be easily controlled, for obvious reasons.

Your options as I see them:

• If it's a hindrance, turn UAC off?
• Use the Task Scheduler to run an application elevated without prompting: http://winaero.com/blog/create-elevated ... indows-10/

If manipulating the dialog with AutoHotkey really is a must, then:

• Turn off the secure desktop option and the UAC dialog will be displayed with the rest of your windows, where you can easily manipulate it with AutoHotkey (and other applications can potentially read the password you type - and not to mention an unelevated application can easily press "Yes"): https://technet.microsoft.com/en-us/lib ... ureDesktop
• If that's not an option, you can use my LogonDesktop and Acc.ahk (get it from https://autohotkey.com/boards/viewtopic.php?f=6&t=26201, thanks jeeswg) to run AHK on the same desktop where UAC shows its secure prompt. For your case, it's not complete: I don't have a username prompt so I can't write code to fill that in (which speaks volumes about the fragility of this):

  Code: Select all

  #NoEnv	; Recommended for performance and compatibility with future AutoHotkey releases.
  ;#Warn	; Enable warnings to assist with detecting common errors.
  SendMode Input	; Recommended for new scripts due to its superior speed and reliability.
  SetWorkingDir %A_ScriptDir%	 ; Ensures a consistent starting directory.
  #SingleInstance Force
  #KeyHistory 0
  ListLines, Off
  SetBatchLines, -1
  #NoTrayIcon
  #UseHook Off
  DetectHiddenWindows On
  #Include %A_ScriptDir%\Lib\LogonDesktop.ahk
  #Include %A_ScriptDir%\Lib\Acc.ahk
  CoordMode, Mouse, Screen
  
  winlogonSessionIDs := []
  
  if (!A_IsUnicode)
  	ExitApp 1
  
  if (LogonDesktop_IsScriptProcessSYSTEM()) { 
  	if (!LogonDesktop_WaitForTermSrvInit()) ; Probably redundant since Task Scheduler starts this script so late, and probably checks itself...
  		ExitApp 1
  
  	LogonDesktop_OpenProcessToken(LogonDesktop_GetCurrentProcess(), TOKEN_QUERY := 0x0008, hToken)
  	if (!LogonDesktop_GetTokenSessionId(hToken, scriptSessionId))
  		ExitApp 1
  	LogonDesktop_CloseHandle(hToken)
  	if (!LogonDesktop_GetThreadDesktopName(desktopName))
  		ExitApp 1
  
  	if (scriptSessionId == 0) {
  		if (!(wtsHandle := LogonDesktop_LoadWtsApi()))
  		  ExitApp 1
  
  		EnumerateSessionsAndLaunchWinlogonClient()
  
  		if (DllCall("wtsapi32.dll\WTSRegisterSessionNotification", "Ptr", A_ScriptHwnd, "UInt", 1))
  			OnMessage(WM_WTSSESSION_CHANGE := 0x2B1, "WM_WTSSESSION_CHANGE")
  		
  		OnExit("AtExit")
  	} else {
  		if (desktopName == "Winlogon") {
  			Acc_Init()
  			Hotkey, ^w, sendPassword, UseErrorLevel On
  		}
  	}
  } else {
  	if (A_IsAdmin) {
  		LogonDesktop_AddTask(True, True)
  	} else {
  		Run *RunAs "%A_AhkPath%" "%A_ScriptFullPath%",, UseErrorLevel
  	}
  	ExitApp
  }
  
  sendPassword() {  
  	if ((loc := StrSplit(Acc_Get("Location", "4.3.8",, "ahk_class Credential Dialog Xaml Host"), " ", " xy`t"))) {
  		Click % loc[1] . ", " . loc[2]
  		SendEvent <password goes here>
  		Acc_Get("DoDefaultAction", "4.4",, "ahk_class Credential Dialog Xaml Host")
  	}
  }
  
  EnumerateSessionsAndLaunchWinlogonClient()
  {
  	global winlogonSessionIDs
  
  	if (DllCall("wtsapi32\WTSEnumerateSessionsExW", "Ptr", 0, "UInt*", 1, "UInt", 0, "Ptr*", pSessionInfo, "UInt*", wtsSessionCount)) {
  		cbWTS_SESSION_INFO_1 := A_PtrSize == 8 ? 56 : 32
  		Loop % wtsSessionCount {
  			currSessOffset := cbWTS_SESSION_INFO_1 * (A_Index - 1)
  			;if (StrGet(NumGet(pSessionInfo+0, currSessOffset+(A_PtrSize == 8 ? 32 : 20), "Ptr"),, "UTF-16")) ; Poor person's WTSActive check
  			if ((sessionId := NumGet(pSessionInfo+0, currSessOffset+8, "UInt"))) {
  				if (DllCall("wtsapi32\WTSQuerySessionInformationW", "Ptr", 0, "UInt", sessionId, "UInt", WTSConnectState := 8, "Ptr*", pBuffer, "Ptr*", BytesReturned)) {
  					if (BytesReturned == 4) {
  						state := NumGet(pBuffer+0,, "UInt")
  						if (state == 0 || state == 1) {
  							foundSessionId := False
  							for _, s in winlogonSessionIDs {
  							  if (s == sessionId) {
  								foundSessionId := True
  								break
  							   }
  							}
  							if (!foundSessionId) {
  								if (LogonDesktop_LaunchOnWinlogonDesktop(DllCall("GetCommandLineW", "WStr") . " /force", sessionId))
  									winlogonSessionIDs.Push(sessionId)
  							}
  						}
  					}
  					DllCall("wtsapi32\WTSFreeMemory", "Ptr", pBuffer)
  				}
  			}
  		}
  		DllCall("wtsapi32\WTSFreeMemoryExW", "UInt", 2, "Ptr", pSessionInfo, "UInt", wtsSessionCount)
  	}
  }
  
  WM_WTSSESSION_CHANGE(wParam, lParam)
  {
  	Critical
  	global winlogonSessionIDs, scriptSessionId
  	if (scriptSessionId == 0) {
  		if (wParam == 6) {
  			winlogonSessionIDs.Delete(lParam)
  		}
  		else if (wParam == 1) {
  			SetTimer, EnumerateSessionsAndLaunchWinlogonClient, -1000
  		}
  	}
  	Critical Off
  }
  
  AtExit()
  {
  	global WM_WTSSESSION_CHANGE, wtsHandle
  
  	OnExit(A_ThisFunc, 0)
  	if (wtsHandle)
  		OnMessage(WM_WTSSESSION_CHANGE, ""), DllCall("wtsapi32.dll\WTSUnRegisterSessionNotification", "Ptr", A_ScriptHwnd), LogonDesktop_UnloadWtsApi(wtsHandle), wtsHandle := 0
  	return 0
  }

[Rhino Cracker]

Dear qwerty12,

at first Thanks a lot for your masterpiece of work.
If I said I fully understood your code, I'd be lying (tbh I might understand 2% of it).
But I was trying around with it* and it looks to me that you've modified LogonDesktop.ahk without modifying the code in this post, so that the latter one cannot run anymore:

- At first run, in line 25 you're trying to execute LogonDesktop_OpenProcessToken(_GetCurrentProcess(), TOKEN_QUERY := 0x0008, hToken), while only LogonDesktop_GetCurrentProcess() is a function defined in LogonDesktop.ahk.
- After manipulting that line, the next error occurs at line 87, where it says if (LogonDesktop_RelaunchOnWinlogonDesktop(sessionId)). I cannot find the word "relaunch" in LogonDesktop.ahk, on your entire post about LogonDesktop or in the 3 files linked in the acc.ahk post.

Your post for LogonDesktop tells Last edited by qwerty12 on 18 Apr 2017, 19:30, edited 9 times in total., while the post in here is from 04 Feb 2017, 01:10, so might it be possible that you accidentally removed a function from LogonDesktop.ahk that is needed in the code you have written in here?

Best regards, Rhino


*Placed Acc.ahk, LogonDesktop.ahk and your code from this post in a directory together and doubleclick-executed the file with your code.

[qwerty12]

Dear qwerty12,

at first Thanks a lot for your masterpiece of work.
If I said I fully understood your code, I'd be lying (tbh I might understand 2% of it).
But I was trying around with it* and it looks to me that you've modified LogonDesktop.ahk without modifying the code in this post, so that the latter one cannot run anymore

Hi Rhino Cracker,

If you copy and paste the code from the post again, It should start now. Sorry about that. I make changes and break LogonDesktop.ahk all the time - nobody (understandably) actually uses it, so I change bits around if it makes things easier. Whether the UAC script actually works now is another matter - I don't have the password prompt enabled this time around so pressing Ctrl + W at the UAC screen just says no to the prompt...

[Rhino Cracker]

Thanks for fixing
Now it works so far.

But I cannot manipulate it so that it does what I want.

Code: Select all

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
; #Warn  ; Enable warnings to assist with detecting common errors.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.
p := 0

#p::
{
  if (p = 0) {
    InputBox, p , pTitle, pPrompt, HIDE, , , , , , 10, pDefault+
  }
  else {
	Send, {Down}%p%{Enter}
  }
}
Return

I didn't want to have my password written in plain text in a file on my desktop. So my idea was to only store it into ram. As long as my PC is bitlocked, it shouldn't be readable then without cracking memory access restrictions.
The code above is how I started before I stumbled over the SendToLogonScreen problems and your posts.

But I didn't manage to integrate this InputBox into your code, yet.

On one hand your hotkey defined in line 45 seems only to have an effect on the logonscreen itself. I don't know where you have defined that logon-screen-restriction (does the script restart itself when enter logon screen? This would kill my variable, right?) And so I don't really know where to place another hotkey definition to have an InputBox in normal screen mode (outside of the logon screen). The usual way (placing a line somewhere that starts with #p::) didn't work so far.
On the other hand an InputBox generated in the sendPassword() function doesn't appear for some reason...

Could you help me a little?

[qwerty12]

Now it works so far. I didn't want to have my password written in plain text in a file on my desktop. So my idea was to only store it into ram. As long as my PC is bitlocked, it shouldn't be readable then without cracking memory access restrictions.

BitLocker only stops somebody from reading the password from memory when the computer is off. There's absolutely nothing stopping a medium integrity process running in the same session from reading the memory of your AutoHotkey process by default, even if said AutoHotkey process is elevated. And password strings are easily found in an AutoHotkey process.

On one hand your hotkey defined in line 45 seems only to have an effect on the logonscreen itself. I don't know where you have defined that logon-screen-restriction

Understanding Windows at a deeper level - Sessions, Window Stations, and Desktops

In short, services run in session 0. Windows creates a new session to display the logon screen and to host the programs you start. Explorer, Chrome, Spotify and all the other programs you start run on the Default desktop. The lock screen, Windows Security, the UAC prompt appear on a different desktop, Winlogon. When the desktop is switched (like when a UAC prompt is shown), you cannot interact with the programs you started on the default desktop. Hotkeys are desktop-bound.

When you double-click the script to start it, it requests elevated privileges. Once the script has them, it uses the Task Scheduler service (already running as SYSTEM) to create a task that will start the script again but this time as SYSTEM in session 0. The instance of the script you explicitly started exits once this is done; there's nothing more for it to do. The session 0 instance of the script just listens for notifications regarding whether a new session has been created (and checks already existing sessions, of course), and if so, this S0 instance starts the script again but this time in your session on the Winlogon desktop. It's this process that has the ability to create hotkeys on the lock and UAC screens by virtue of the desktop the AutoHotkey process was told to start on.

(does the script restart itself when enter logon screen? This would kill my variable, right?)

Yes, the instance of the script running on the lock screen/UAC desktop will get killed when you log out. Absolutely nothing can be done about that - Windows destroys the session and everything in it (e.g. window stations with its desktops, and processes) and creates a new session complete with logon screen. The session 0 instance of the script will spawn the Winlogon instance of the script again when you login in again. Having to enter your password again when you log in again sounds OK to me. This could possibly be worked around by having the Winlogon instance of the script send the password to the session 0 instance, which would then summarily let new Winlogon instances of the script know what the password entered was, but even if I thought that was a good idea, I have no inclination to try implementing such a thing.

And so I don't really know where to place another hotkey definition to have an InputBox in normal screen mode (outside of the logon screen).

Knowing what you now may or may not know about desktops, the only way you get that is by getting the Winlogon script to start itself on your default desktop (there's another way, but I don't think it's particularly secure in this case and, besides, it's impossible to do in AutoHotkey anyway), like the original sample script for LogonDesktop does so that it can message the Spotify window when a hotkey is pressed on the logon screen desktop.

The usual way (placing a line somewhere that starts with #p::) didn't work so far.

Don't do that. Use Hotkey like I did to have the hotkeys conditionally created when appropriate. (In this script's case, when the session ID is not zero and the active desktop name is "Winlogon".)

On the other hand an InputBox generated in the sendPassword() function doesn't appear for some reason...

It's actually there, just behind the UAC window. If you hit Alt+Tab or drag the UAC window out of the way, you should be able to see it. Maybe the InputBox needs to be always on top or the credential window has a higher window band or something.

Could you help me a little?

Maybe. But before I expend any effort into this, I must know two things. Is there any reason why you can't simply have UAC set to ask you for consent instead of credentials?
And following on from that, do you have two user accounts, one an admin and the other a normal, unprivileged user? If so, I might not be able to help.

[Rhino Cracker]

Thank you I really appreciate your effort to explain things!

BitLocker only stops somebody from reading the password from memory when the computer is off. There's absolutely nothing stopping a medium integrity process running in the same session from reading the memory of your AutoHotKey process by default, even if said AutoHotkey process is elevated. And password strings are easily found in an AutoHotkey process.

Okay? I thought windows had some memory access restrictions. It would give a process a virtual amount of ram spread across physical memory and pagefile.sys with randomized and masked physical addresses mapped to one large connected block of virtual addresses that are shown to the process. And with an access restriction so one process cannot read or write outside of the virtual address space assigned to it.

But the origin of that knowledge I thought I had only is our computer scientists regulars' table.

In that way of thinking, I thought the only way to read the password from memory would be to bypass memory virtualization or to crash the system and read the memory dump (if set to complete dump before).
In case of a BitLocked pc, the second way might not work.

Is there any reason why you can't simply have UAC set to ask you for consent instead of credentials?

Those are my company's restrictions. They changed to that mode to disable another process from simply clicking on "yes".
I wanted to have this script as a feature for when I'm changing a lot on my pc. Sometimes I have to enter it every 20 seconds which is really annoying.

do you have two user accounts, one an admin and the other a normal, unprivileged user?

No, the account I'm using is an administrator account. There are other administrative accounts.


OK, if it is that complicated (one would have to implement window messages to exchange the password between the processes running at different sessions/desktops), I think I will just live with placing it as it is in an additional encrypted container (so someone with fileaccess to the running machine cannot access it easily), load it when needed and close it afterwards.
Maybe I will obfuscate the password a little and not place it as plain text in a function called "sendPassword()"

[qwerty12]

BitLocker only stops somebody from reading the password from memory when the computer is off. There's absolutely nothing stopping a medium integrity process running in the same session from reading the memory of your AutoHotKey process by default, even if said AutoHotkey process is elevated. And password strings are easily found in an AutoHotkey process.

Okay? I thought windows had some memory access restrictions. It would give a process a virtual amount of ram spread across physical memory and pagefile.sys with randomized and masked physical addresses mapped to one large connected block of virtual addresses that are shown to the process. And with an access restriction so one process cannot read or write outside of the virtual address space assigned to it.

I was wrong in saying an unelevated program can read the memory of an elevated program. I made some bad assumptions (my integrity level knowledge isn't great) looking at the permission list the task manager presented to me (and my task manager was also using its driver to bypass the DACL in the elevated process, even though I told said task manager not to use its driver when unelevated...). But if the process's DACL grants you rights to read the process's memory, a program can use ReadProcessMemory etc. to read the memory of a process. So this means if you put your password into an elevated process that doesn't clear its password strings from memory when done and run another elevated program, then yes by default, the second elevated process can read the memory of the first. But this isn't a problem (unless you use the same password for everything) because once a malicious program has full admin rights, it's over anyway.

Those are my company's restrictions. They changed to that mode to disable another process from simply clicking on "yes".
I wanted to have this script as a feature for when I'm changing a lot on my pc. Sometimes I have to enter it every 20 seconds which is really annoying.

While I don't know anything about group policy, especially where stuff like AD is involved, If you're an admin, I'm sure you can change it back. Hit Win + R and run secpol.msc. The UAC options are in the account/local policies somewhere. I think that might be a better option than running a series of scripts (and, I must be honest, security wasn't my number one concern - I just wanted to be able to control Spotify when the computer was locked).

OK, if it is that complicated (one would have to implement window messages to exchange the password between the processes running at different sessions/desktops), I think I will just live with placing it as it is in an additional encrypted container (so someone with fileaccess to the running machine cannot access it easily), load it when needed and close it afterwards.
Maybe I will obfuscate the password a little and not place it as plain text in a function called "sendPassword()"

Window messages won't work because of the different desktops, I think, but it would be possible to use pipes. I was thinking an elevated process, with a more hardened DACL, spawning another instance of itself on another desktop (this means you can't interact with anything else while the password prompt is active, but it also means it's much harder for someone to keylog you when you're entering the password) which then sends the entered password to the script running on winlogon. If I get it right, this would mean the only program that has your password in memory would be the AutoHotkey script running on the UAC desktop, but if a malicious program has enough rights to read the memory of that, you have bigger problems anyway (and even more so if, again, you use the same password for everything).

I can try and whip something up in a few days' time, but I'd only really try if changing your UAC security policy isn't an option...

[Rhino Cracker]

While I don't know anything about group policy, especially where stuff like AD is involved, If you're an admin, I'm sure you can change it back. Hit Win + R and run secpol.msc. The UAC options are in the account/local policies somewhere. I think that might be a better option than running a series of scripts (and, I must be honest, security wasn't my number one concern - I just wanted to be able to control Spotify when the computer was locked).

I'm using a German Windows, so I have to translate the following menu items and don't know if I hit their actual names accidentally:
I think the option is located in secpol.msc --> local policies (2nd) --> security options (3rd) --> UAC: switch to secure desktop on request for higher privileges to the user (4th). This option (and some more) are blocked to change.

I can try and whip something up in a few days' time, but I'd only really try if changing your UAC security policy isn't an option...

Please only put effort into it, if you want that script for your own or some more users to be available. I can live with the current state that it's inside of a TrueCrypt container and only available for reading from disk as long as this container is mounted, or from ram as long as the script is running.

[Jovannb]

Hi,

I had a similar problem and red a lot about different solutions. Then I tried that via Task-Scheduler an it works on Win7 and Win10 like a charm as follows:

a) I made a scheduler-task which is called "ahkcontrolled" which runs a cmd-File which is called "ahkcontrolled.cmd", it runs on highest privileges/priority

b) my ahk-script creates that ahkcontrolled.cmd dynamically as I need it

c) then my ahk-script starts (runs) that scheduler-taks "ahkcontrolled" by use of "schtasks /run /tn ahkcontrolled"

and the following things are for users comfort

d) my ahk-script waits till the process/program (called in ahkcontrolled.cmd) starts and stays then waiting, till the process/program ends

e) so the ahk-scripts ends, when the process/program is closed

later I extended it for

f) the ahk-script detects whether the "ahkcontrolled" scheduled-tasks exist or not, so that the user can inform the administrator (using "schtasks /query /tn ahkcontrolled")

It's simplier than it looks like.

When you have more computers to use that, you can export that scheduler-task on one computer (as XML) and import it on others - but then you have to change the relevant user in which's context that task will start.

We use that on 12 computers (mixed Win7 and Win10) without any troubles.

regards

J.B.

[qwerty12]

I'm using a German Windows, so I have to translate the following menu items and don't know if I hit their actual names accidentally:
I think the option is located in secpol.msc --> local policies (2nd) --> security options (3rd) --> UAC: switch to secure desktop on request for higher privileges to the user (4th). This option (and some more) are blocked to change.

On English Windows, it's "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" and you'd want it to say "Prompt for consent on the secure desktop". But you say that option can't be changed anyway, so I guess this is moot

Please only put effort into it, if you want that script for your own or some more users to be available. I can live with the current state that it's inside of a TrueCrypt container and only available for reading from disk as long as this container is mounted, or from ram as long as the script is running.

Thanks, I'll leave it then (the Acc stuff is too generalised for my liking and such a script would probably require quite a bit of maintance given the way MS are changing things left, right and center in 10). While I keep UAC at the highest level (even though doing so is pretty useless once you have one elevated program running as you), I'd never set it so that I had to enter my password each and every time (in Linux I used to go to the extreme of NOPASSWD sudoers entries and PolicyKit rules to allow everything, making that install less secure than my Windows ones...). But anyway, I'm glad you got something that works for you!