make-token always reports success

[audibleblink]

Describe the bug the make-token functionality always reports success, even when providing incorrect credentials

To Reproduce Steps to reproduce the behavior:

1. make-token -d bits.lan -u noone -p b4dp4ssw0rd
2. See [*] Successfully impersonated bits.lan\noone. Use rev2self to revert to your previous token

Expected behavior An error indicating that the user is not operating under the assumed token

Desktop (please complete the following information):

• OS: linux
• Version 1.5.8

Additional context Add any other context about the problem here.

[rkervella]

Looks like a bug in the syscalls.LogonUser definition. I'll have a look.

[audibleblink]

I changed logon type we're passing to LogonUser to LOGON_INTERACTIVE and appears to be working now.

According to MSDN re: LOGON_NEW_CREDENTIALS

This logon type allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identifier but uses different credentials for other network connections. This logon type is supported only by the LOGON32_PROVIDER_WINNT50 logon provider.

We're using PROVIDER_DEFAULT, that may be why?

Any thoughts on the INTERACTIVE logontype. Pros/cons?

[audibleblink]

fysa: LOGON_INTERACTIVE

This logon type is intended for users who will be interactively using the computer, such as a user being logged on by a terminal server, remote shell, or similar process. This logon type has the additional expense of caching logon information for disconnected operations; therefore, it is inappropriate for some client/server applications, such as a mail server.

[rkervella]

I think initially I only looked up at how Cobalt Strike did it, per this blog post. Looking up on LOGON_INTERACTIVE, it looks like you need a specific privilege on the box otherwise it won't work:

Interactive logon. Use of the Interactive logon type requires a Windows account to be granted the Windows security privilege to Log on locally.

That being said, I have not tested it.

We're using PROVIDER_DEFAULT, that may be why?

Well per MS docs, the default provider is set to negotiate, AKA LOGON32_PROVIDER_WINNT50, so it shouldn't be an issue:

LOGON32_PROVIDER_DEFAULT Use the standard logon provider for the system. The default security provider is negotiate, unless you pass NULL for the domain name and the user name is not in UPN format. In this case, the default provider is NTLM.

[rkervella]

Hm as an alternative, maybe we could let the user pass the LogonType, defaulting to either LOGIN_INTERACTIVE or LOGON_NEW_CREDENTIALS.

[audibleblink]

I wonder what the default is, if we're primarily talking about AD accounts, for interactive logons. If it's default allow for terminal logons, then interactive seems a safe bet. And I'm assuming if it's another local user, they have that priv as well.

This is the part I worry about w.r.t. new_credentials

The new logon session has the same local identifier but uses different credentials for other network connections What about non-networked actions or if I'm making a token because I want to use it for a runas type action locally.

[rkervella]

Well initially the idea was to kinda replicate the make_token feature of Cobalt Strike, which is strictly about network credentials. My solution to cover a broader scope for this command would be to either:

• let the user choose what LogonType they want to use
• implement/change the runas command to create a new process that uses CreateProcessWithLogon

I think the first one is a better solution short term, we can default the LogonType to LOGON_INTERACTIVE and let the user switch to LOGON_NEW_CREDENTIALS (or the reverse), that way we can cover all cases, and the user can also supply other LogonType.

[audibleblink]

Agree. I just the read the CS post. Now it makes sense why it always reports a success. When using LOGON_NEW_CREDENTIALS, it doesn't seem like they're checked until you go to use them over a network connection.

It also states id checks always return the luid owner when using logon_new_credentials. That sucks for my recently merged token-owner PR lol

[cmprmsd]

The first suggested solution sounds great. That way you could choose what's needed. Would this be a huge issue to be solved?