Runas verb not elevating on specific Windows 10 machines

Question

I have a really odd issue, where some code that we have been running for years has stopped working on certain machines. There is no obvious pattern to the machines (in terms of Win10 build number or patch level).

The code is designed to run an application as the local administrator, and is as follows:

string strPwd = "MySecretPassword";

SecureString securePassword = new SecureString();
foreach (char ch in strPwd)
{
    securePassword.AppendChar(ch);
}

ProcessStartInfo processInfo = new ProcessStartInfo();
processInfo.UserName = "Administrator";
processInfo.Password = securePassword;
processInfo.Verb = "runas";
processInfo.FileName = "cmd.exe";
processInfo.WorkingDirectory = @"c:\windows\system32";
processInfo.UseShellExecute = false;
Process.Start(processInfo);

If I run this on a "working" machine, I see the following (note, the echo test > c:\test.txt is how I am testing whether it can perform a restricted task):

Note the "Administrator" on the CMD window. Also, note that creating a file at the root of c: is allowed.

In comparison, if I run the same on another machine I get the following:

Note that in this case (running exactly the same code) the window is not running elevated. Oddly, if I look at the process in Task Manager, the owner is Administrator.

On both machines:

1. I am using the default Administrator account
2. The password is correct
3. The account is in the Administrators group
4. The account is not disabled

Furthermore, on the "bad" machine, if I right-click and choose RunAs and enter the Administrator credentials - it works perfectly. (Same result as in the first picture above.)

As an additional test I've tried using the DOS runas command and this doesn't work on the "bad" machines either. The result is slightly different though:

Note in this case the "Running as Administrator" in the title bar. (The same test on a "good" machine gives the same result as in the first picture above, i.e.: Administrator: C:\windows\system32\cmd.exe)

Herries

Could you show us the users and their rights for c:\ or c:\windows\system32? In the working scenario you have one user using an admin cmd, but in not working scenario you have a different user (which is an administrator) running normal shell in my eyes. – Unfrequented

Yep - that’s the problem. Both users (both called administrator, the default local admin account) are being used. Both are in local admin group. However the behaviour is different on the two machines. – Herries

If you rename the administrator (the local admin account) into local_admin will it work? – Unfrequented

What’s the theory behind this? (I would be very surprised - it has always worked fine with administrator, which is the default.) – Herries

You don't have to actually rename the default account, you can create a new administrator account (with whatever name). The reasoning being, if a new administration account shows the same symptoms as the original one. Something had to change if it was always working. – Unfrequented

Ah - understood. Yes I have tested with another local admin account. Same issue. – Herries

I see :(. Well could you try it with small utility from Nirsoft - NirCmd elevate your_script (you can find it at - nirsoft.net/utils/nircmd.html) – Unfrequented

Thanks for that. Doesn’t help in this case, but useful to know. – Herries

Hmmm :(. If you run the local administrator account manually (on the bogus machine) and do a cmd and Run as Administrator does it work? – Unfrequented

@Herries Did you check Windows event log for any possible security/system errors/warning? – Schoolfellow

Nothing in the logs. :-( – Herries

@Herries Tell me the exact version numbers (With build) of the Windows 10 versions (Both "Good" machine and "Bad" machine) – Asteroid

Both are on version 1709 (Build 16299.726) – Herries

What happens if you disable UAC? Will it allow you to elevate a process with the runas verb? – Uprear

Did you ever resolve this? – Alfie

This is happening to me if I first launch a CMD with a token obtained from SaferComputeTokenFromLevel(SaferLevels.NormalUser) and then trigger uac from powershell -c Start-Process -FilePath cmd.exe -verb "RunAs". It the parent is a regular CMD, the UAC works and the elevated process is admin. So I think this is related to the token of the launching process. Try to compare priviledges between both machines whoami /priv /groups, I will check linked tokens are related. Also compare the Group Policy of both machines. – Yingyingkow