Impersonate command does not work as described

[senzee1984]

Describe the bug The description of Impersonate command says Sliver commands that run new processes (like shell or execute-command) will impersonate this user.. However, it does not work as expected.

To Reproduce Steps to reproduce the behavior:

1. Impersonate an logged in user.
2. Execute the shell command.

Expected behavior After the impersonation, a new process can be spawned as the impersonated user according to the description.

Screenshots

[server] sliver (VAST_KNIGHT) > help impersonate

Command: impersonate USERNAME
About: (Windows Only) Steal the token of a logged in user. Sliver commands that run new processes (like shell or execute-command) will impersonate this user.

Usage:
======
  impersonate [flags] username

Args:
=====
  username  string    name of the user account to impersonate

Flags:
======
  -h, --help           display help
  -t, --timeout int    command timeout in seconds (default: 30)

[server] sliver (VAST_KNIGHT) > impersonate CHILD\\Administrator

[*] Successfully impersonated CHILD\Administrator

[server] sliver (VAST_KNIGHT) > shell

? This action is bad OPSEC, are you an adult? Yes

[*] Wait approximately 10 seconds after exit, and press <enter> to continue
[*] Opening shell tunnel (EOF to exit) ...

[!] Error: fork/exec C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe: A required privilege is not held by the client.
Shell exited

Desktop (please complete the following information):

• OS: Kali
• Version 1.5.33

[rkervella]

I'll try to look into it.

[docsewell]

I'm having the same issue. I wonder if when executing the shell, the old token is being used rather than the one that was just created. I think meterpreter sometimes has a similar issue as well.

[jblandrum]

I'm actually having the same issue w/ make-token I've got a local Administrator password in a lab and make-token -d . -u Administrator -p -T LOGON_INTERACTIVE succeeds and the built-in whoami shows .\Administrator however - shell fails the same as above and execute -o fails with ERROR: Access is denied. However, logging in w/ local Admin via winrm and this password works fine...

Dropping privs to another user also allows me to successfully run execute -o whoami... very odd behavior

[rkervella]

@jblandrum that's expected: make-token is only supposed to be used to access remote resources as the user, not to start local processes impersonating this user. Use the runas command for that.

[Cyb3rC3lt]

I experienced the same issue as the OP today on a client site and nothing runs with the impersonated token. I had to run SharpImpersonation via execute-assembly to trigger a Sliver implant to call back to me as the impersonated elevated user and then go from there. Would be great if this issue could be prioritised please. Thanks

[C2Matr1x]

@jblandrum that's expected: make-token is only supposed to be used to access remote resources as the user, not to start local processes impersonating this user. Use the runas command for that.

Not sure this is the best alternative. Runas is when you have creds and what we need to do is to execute as the person whose token we've impersonated. Edit: I see now you were advising specifically about make_token but the below still would be great.

If you look at how Metrepeter works at the bottom you can kick off a shell as the impersonated user and Cobalt Strike has similar.

It's such a powerful attack vector it would be great if you could allow us to create new processes as the impersonated user.