v111: Registry modifications / tiTkn.txt script not working

[drujd]

The tiTkn.txt script for modifying registry with TrustedInstaller credentials is not working for me. With debug on, the error is

Cannot convert argument "0", with value: "", for "OpenProcessToken" to type "System.IntPtr": "Cannot convert null to type "System.IntPtr"."
At line:9 char:1
+ [void]$Win32::OpenProcessToken($sysProc.Handle, 6, [ref]$sysTkn)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodException
    + FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument

I am not sure whether the error is the cause, but the script fails to acquire TrustedInstaller privileges.

The actual commands ARE still executed, so it actually works on older builds that allow modifying e.g. SideBySide\Configuration with standard administrator privileges, but fails on newer builds.

Could maybe something like PowerRun be used?

[abbodi1406]

The idea is not to use external binaries (AVs warning, and not easy to control from batch to launch specific commands)

$sysProc is the handle for winlogon.exe, which should work for any admin, unless DeviceGuard, or any other protection settings prevent that
what's your host OS?

[drujd]

Windows 11 24H2, current build. I do not use Device Guard.

[drujd]

This simply doesn't work for me. Tried on a completely clean install of Windows (just with Windows Defender and Device Guard disabled), same issue.

[abbodi1406]

Well, i have nothing in my mind, and i'm trying to avoid using NSudo or superuser (AVs flag them)

[drujd]

I have done some experimenting and I think Microsoft just considered this a security issue and fixed at some point or it only runs with non-default LSA protection settings (it for sure does not work on clean installs of 26100.1742 directly from official ISO).

Process objects belonging to protected processes have null handles, but I can get handles to SYSTEM non-protected processes. For instance (GetProcessByName('winlogon')[0]).Handle is not null. With e.g. Sysinyernals Process Explorer I can see lsass is protected ("PsProtectedSignerLsa-Light").

[drujd]

Ok, I have fixed it by replacing GetProcessById(([WMI]'Win32_Service.Name=''SamSs''').ProcessId) with GetProcessByName('winlogon')[0]. The script now acquires TrustedInstaller credentials properly and all registry entries apply.

That uses the actual winlogon token (not SamSs, which is a different thing). Winlogon is not protected, unlike SamSs/lsass ( https://itm4n.github.io/lsass-runasppl/ ) and it just works for me.

Probably there should be a more elegant way to get the handle (to avoid theoretical processes with the same name).

[abbodi1406]

Thanks for testing

i remember that winlogon didn't work always for me, that's why i chose samss
i'll check again

for reference:
https://posts.specterops.io/understanding-and-defending-against-access-token-theft-finding-alternatives-to-winlogon-exe-80696c8a73b

[drujd]

Interesting. It seems the article is slightly outdated today, as lsass.exe is now also Protected Process Light. I also think the loophole with Protected Process Light processes doesn't work anymore (but might be wrong).

But as long as there are some unprotected SYSTEM processes, we should be fine.

One thing of note is that when titkn script fails, it is completely silent, with or without debug mode on (-EA 0).