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\jking (netonly)

The logon session created with LogonUserA has the same local identifier as the caller but the alternate credentials are used when accessing a remote resource.

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

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.

Last updated