The trick used in ImpersonateInteractiveSid doesn't work in Windows 11

[ynwarcs]

Hello,

The trick used in ImpersonateInteractiveSid doesn't work in Windows 11. When calling LogonUser with LOGON32_LOGON_NEW_CREDENTIALS, the returned token will no longer have the interactive SID attached to it. This will make the CoGetInstanceFromIStorage call in UnmarshallIStorage fail with E_ACCESSDENIED because the impersonated fake user doesn't belong to the interactive group, hence they have no access to activate PrintNotify.

Speculatively, this is due to changes in LsapAuAddStandardIds within lsasrv.dll between Windows 10 and Windows 11:

Win 10

switch (logonType)
{
    ...
    case NewCredentials:
         outSids[outSidCount].SID = (*WellKnownSids)[WinInteractiveSid].SID;
    ...
}

Win 11

switch (logonType)
{
    ...
    case NewCredentials:
        if (TlsGetValue(dwCallInfo))
        {
            // Fetch caller's logon SID
            WELL_KNOWN_SID_TYPE callerLogonSid;
            DetectCallerLogonTypeSid(CallerToken, &callerLogonSid);
            outSids[outSidCount].SID = callerLogonSid.SID;
        }
    ...
}

Note that these code snippets are my interpretation of the decompiled code from lsasrv.dll. As can be seen above, the function will no longer blindly attach an interactive SID to the local token when logging in a user with LOGON32_LOGON_NEW_CREDENTIALS, but rather the caller's logon type SID will be attached.

Of course, this doesn't entirely ruin the exploit. As long as there is an interactive user logged on to the system, it's possible to take their token and use it to activate PrintNotify, via e.g. via WTSGetActiveConsoleSessionId. One can also call LogonUserExEx with pTokenGroups including the SID of the interactive group, but SE_TCB_NAME is required for this to succeed.

[antonioCoco]

Hi @ynwarcs

thanks for the detailed issue.

I cannot reproduce the behavior you have mentioned on my Win 11. Which specific version of Windows 11 have you tested?

[ynwarcs]

I tested on the latest Win 11 Insider build (v22623 - Pro) available here, as well as the latest official build (22H2 - Pro) available here.

The builds were clean, no tinkering done by me and booted only for the purpose of testing the behaviour of JuicyPotatoNG. I verified that the behaviour is reproducible both through Hyper-V and when the builds were installed locally. I also installed a clean Windows 10 build (Pro - 21H2) and confirmed that the behaviour is different from that observed on Win 11.

It might be down to the build flavor (ie Pro/Home/Enterprise) or the version of the build, I haven't checked anything except latest Pro builds, so there might be some variance.

[decoder-it]

weird, tested it on w11 pro 21h2 with latest update and worked, on w11 pro 22h2 no more working. But on server 2022 fully patched still works and there are 3 different lsasrv.dll versions. Thanks for pointing this out @ynwarcs

[decoder-it]

we need to dome some fix @antonioCoco , as long as there is an interactive user connected...

[antonioCoco]

@ynwarcs as a temporary workaround you can use the following CLSID:

{A9819296-E5B3-4E67-8226-5E72CE9E1FB7}

It's the Universal Print Management Service “McpManagementService” and is available on Windows 11 and Server 2022. It doesn't need the INTERACTIVE sid and Everyone can activate it. This is a temporary workaround as we don't have a better solution for this as of now.