@AFH The OP states it should not spawn a new window, which when it comes to the Command Prompt excludes starting a new process.

Yes, you're right. The TCC-LE solution (start /elevate) has the same effect, as does my solution. The privileges appear to be attached to the window, rather than the process. So you're quite right when you say it can't be done in the same window, but if the program is native Windows a new window will be needed anyway.

This answer is exactly correct and very well referenced... and I'm glad to have the references for later use. Thanks, Twisty! (upvoted)

This is a good answer that explains the permissions issue. It might also be worth pointing out the other difference between Unix and Windows in this regard: the console window that Windows creates for a console program is not the same thing as a terminal in the Unix world. A new console command will get a new console to go with it, and also, if it's elevated, all the benefits of User Interface Privilege Isolation (UIPI).

If one were to start CMD.EXE and then type CMD.EXE inside the window, I would expect the newly created CMD.EXE process to be using the same window as the previous one. The question just is how to run the new process with different privileges.

@kasperd Not exactly. The OP requires that it should not spawn a new window or display UAC prompts. It's not possible to spawn a new instance of CMD.EXE with different permissions in the same window and without triggering UAC since for Command Prompt window = process.

@Twisty When did that happen? Last time I touched Windows it was possible to start another shell inside the current window.

@kasperd No, you're correct that you can start another shell, but it will inherit the permissions of the spawning process. If you start the new instance with different permissions (e.g. with runas) it will (indeed must) open in a new window.

@kasperd Looks like this behavior goes back to at least Windows XP. I used runas from a Command Prompt to start another instance of CMD.EXE with a different user account (i.e. a different access token) and the new Command Prompt opened in a new window.

@kasperd Console handles can be inherited if the initiating program (e.g. cmd.exe) allows it, but only if the security contexts are the same. The ways of starting new console applications with different permissions always create a new console window with the new permissions. See also User Interface Privilege Isolation (UIPI). If you're interested in the programming side, see Creation of a Console, and look into the documentation of the CreateProcess family of functions.

Not correct; there is a replace a process level token privilege. If you're willing to use one of the known UAC bypasses and go a crazy long way out of your way you can replace the token in the original process.

@Joshua I believe the privilege you're referring to is used by a parent process to start a child process with a different process level token than would otherwise be inherited from the parent process. Task Scheduler uses this privilege to start tasks using the token of the user specified in the task's "When running the task, use the following user account" setting. However, this token "replacement" is still done when the new process is created. If you can provide documentation showing this privilege can be used to replace the token of an already running process, I'm all ears!

@Twisty: undocumented.ntinternals.net/UserMode/Undocumented%20Functio‌​ns/…

Also see: stackoverflow.com/questions/5141997/…

@Joshua I'm confused. It says right in the top-voted answer of that SO post once the process has started running the process token is locked and can no longer be modified. That's not the same as changing the token of an already-running process.

Ah; my docs are way out of date. That restriction seems to have not always been true.

@Joshua You're quite correct. See the first quoted source in my answer...

Anyway, you can still use this to elevate a new cmd.exe in the same window as the original one which is what you want by creating it as CREATE_SUSPEND, going through the elevation path, and replacing the token, then resuming it.

Let us continue this discussion in chat.

May I recommend mentioning somewhere that your first sentence is also true in Linux? As noted in the comments, Linux is launching a new process when using sudo.

@jpmc26 Hmmm...I'm not a *nix user and couldn't vouch for this myself. Any chance you could point me to source I could reference?

@Joshua Wouldn't doing what you describe result in a new instance of CMD.EXE? And if so, wouldn't that spawn another window?