Make Token

The make_token command allows you to impersonate a user if you know their plaintext password. This works under the hood by calling the LogonUserA API, which takes several parameters including a username, password, domain name and logon type. In this instance, the LOGON32_LOGON_NEW_CREDENTIALS logon type is used, which allows the caller to clone its current token and specify new credentials for outbound network connections.

The API outputs a handle to a token which can then be passed to the ImpersonateLoggedOnUser API. This allows the calling thread to impersonate the context of token (i.e. the impersonated user's context).

beacon> make_token DEV\jking Qwerty123
[+] Impersonated DEV\bfarmer

\

The logon session created with LogonUserA has the same local identifier as the caller, which is why, somewhat confusingly, you see "impersonated <current user>" in the console output. But the alternate credentials are used when accessing a remote resource.

beacon> remote-exec winrm web.dev.cyberbotic.io whoami
dev\jking

\

The getuid command will also return the local identifier of the current process, and this does make it hard to track whether or not your Beacon is currently impersonating a user via make_token.

beacon> getuid
[*] You are DEV\bfarmer

\

When in doubt, use rev2self to drop any impersonation that may be in play. This also means that make_token is not applicable to anything you may want to run on the current machine. For that, spawnas may be a better solution.

These logon events can be found in Kibana with the following query:

event.code: 4624 AND winlog.event_data.LogonType: 9

\

Where 4624 is the "An account was successfully logged on" Event ID and LogonType 9 is LOGON32_LOGON_NEW_CREDENTIALS. The events will show who the caller was, what user they impersonated, the calling process name, ID, and more.

\

\

One unfortunate downside to detecting this technique is that runas /netonly behaves in the same way. So it may be difficult to distinguish legitimate and malicious events.